SharePoint Dan

Please note the update!

So apparently others have stumbled upon this but when doing my rebuild of RTM over the weekend I noticed a nifty little error popping up in the event log that raised a little concern with regard to the TaxonomyPicker user control.

Looking at the error, you’ll notice that it states the TaxonomyPicker.ascx user control can’t register an assembly ‘Microsoft.SharePoint.Portal.WebControls.TaxonomyPicker’ from assembly ‘Microsoft.SharePoint.Portal, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c’.

If you’ve seen something like this before it’s typically because either a user control was edited incorrectly such that a character was incorrectly added to the assembly register string, or someone removed the assembly from the server and the user control is “freaking out” (never a good thing).  In this case it’s just a typo in the user control – but wait, this is out of the release to manufacturing right? Yeah, about that…

So the fix, simply navigate to the 14 root at: %systemroot%\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\CONTROLTEMPLATES where you’ll find the TaxonomyPicker.ascx user control.

If you haven’t created a short cut to the 14 root yet, you may want to as I’m sure you’ll be visiting there often

First – make a copy of the file and save it as perhaps TaxonomyPicker.ascx_backup or something along those lines – what works for you, run with it.

Next using your favourite text editor (TextPad for me), open the user control and observe in the first line the error.

Interesting that “TaxonomyPicker,” made it through quality assurance testing, but alas, not a huge detail right? Simply replace the “,” with a “,”

Save the user control and restart the app pool and presto, the error should be no more.

Permissions still as they should be? Should look like this…

Also, check to ensure that you’re still inheriting permissions properly by opening the file properties -> security -> advanced

And with that, you’re done. Happy tuning.

Update – Apparently the error will continue to persist even after making the correction to the file.

Looking in the Microsoft.SharePoint.Portal Assembly it looks like there is no actual TaxonomyPicker class, so in reality you can just keep the copied file (TaxonomyPicker.ascx_broken) and remove the fixed version. That being said, until the TaxonomyPicker class is implemented within the Microsoft.SharePoint.Portal assembly, you’re safe in not worrying about this user control.

Recently I read an article regarding service accounts and how they should never be set to expire.  Bold statement that in some respects I agree with.  In the context of the author, I completely understand their frustration with the identity management system not properly alerting the end user that their account was about to be disabled and in turn bringing their development system to a screeching halt. 

In the context of an enterprise environments, password and user account expiration are standard obligations that not only ever system administrator must adhere to, but every user on the domain.  From an information assurance traceability perspective, without an account sponsor for each and every domain user object, there runs a risk of information loss and accessibility to information by individuals that should not have such access.

By and far I would see the majority of user account responsibilities and issues falling on the shoulders of the system administrator.  From an availability perspective, they are the engineer that ensures the system continues to operate properly.  While they may not be the face of a system, without their diligent caretaking, the other engineers and analysts are unable to perform their duties.

One core responsibility of a system administrator is to keep a running list of user accounts that are used in their Microsoft Windows Networking Infrastructure to include the service accounts used for MOSS, SQL and any other third party software that is operating which may have adverse effects on the availability of the system if disabled.  As a part of the technical governance, one of the responsibilities of the system administrator should clearly state and define that they track user accounts used within the system (some might even call this a best practice).

An appropriate checklist to ensure user account availability would potentially include (but not be limited to):

• Listing of all service accounts (display name, UPN, sAMAccountName, POC, etc.)
• Where each of the accounts reside in the OU structure
• What security groups each of the accounts belong to at the local server level, the domain level, and the enterprise level
• If there are any DCOM modifications required for a service account to operate properly on a server
• What the operating period for the service account is (i.e. does it have a definitive expiration date)
• GPO policy on the particular set of service accounts
• Password change policy timeline
• …

In my experience, I’d say that the majority of system outages and incidents that have occurred when either a service account expires, the password aging that is required catches the administrator off guard when they forget to change it, the core network switches that provide for general connectivity go offline, or a new GPO is pushed down and inadvertently modifies security groups or other domain user object properties.  Three of these four issues can be easily mitigated by the system administrator with proper notifications and alerts.  Networks are networks and you never know when your core switch is going to have a board go bad or worse melt due to over processing (I’ve not seen the latter, but I have seen the former).

Based on the context of the environment, a system administrator should have a maintenance calendar in SharePoint linked to Outlook that users are subscribed to and receive alerts which provide pertinent information.  Such information could potentially include when the next maintenance period is and what will be accomplished during the system outage. Additionally, and maybe it’s wishful thinking on my behalf, the System Administrator hopefully has a relationship of some sort with the Domain Admins or help desk and knows what the policy states in terms of how many days an account is valid for before expiration.

Should user accounts expire or passwords age?  It depends on the context.  How you approach the issue and handle it is a separate story.  Working in the context of an enterprise system requires a higher specification of diligence to properly ensure system availability.  In a small environment or dev system, rarely do I find password aging or expiration enabled, thereby reducing the risk of availability due to AD issues.

What works for your organization?

If you’ve ever had to troubleshoot a SharePoint issue within the realm of the third iteration of SharePoint’s platform, then you know that there’s more than just what you’ll find in Central Admin that sometimes requires tinkering to resolve problems.

I’ve dealt with everything from timer jobs not firing off due to daylight savings time patches not being applied, to workflows not working properly due to network latency and message traffic not arriving when it was supposed to, to the joys of sAMAccountNames being modified after a user accessed a site, to the glories of psconfig failing to provision and deprovision web applications properly during an upgrade and leaving a cloud of dust within the ULS logs.

I’m not here to tell war stories, but rather to provide a few ideas and suggestions when attempting to troubleshoot a problem.

1 – Document everything – How is this troubleshooting?  It’s not really, it’s more the preventive medicine for when you’re going to have to troubleshoot… consider it a part of the Boy Scout Motto "Be Prepared".  Knowing your interfaces to other systems, your taxonomies (security, site and features), and your architecture (both physical and logical of everything) will save you hours and hours of time when you’re attempting to troubleshoot an issue.  Otherwise, troubleshooting becomes a blind analysis, feeling along the walls hoping to find the issue.  I’d recommend keeping a OneNote journal with configuration settings and changes for your systems so as to consolidate information to a single source (or if you want to use Google Sites, Notebook or Docs, that’s cool too ).

2 – Know your AD environment – do you have custom domain security policies that are being applied to a specific organizational unit?  Did someone inadvertently move your server where they shouldn’t have within an OU structure while they were performing directory maintenance and now regardless of what you do to try to reconfigure your server the domain policy continues to lock it down?  Knowing your AD environment and providing relevant data to your domain administrator will at least allow you to rule out the possibility that it’s something outside your immediate control.

3 – Plan your system appropriately – this goes back to #1.  If you aren’t planning things out appropriately in a technical sense and haven’t put forth a plan of how you’re going to implement a system, it’s going to be a while, get a Snickers bar.  I’d recommend by starting with the planning worksheets as defined in the SharePoint 2007 Deployment Guide and Checklists – better yet, build a project plan so that you’re able to be sure you’ve thought through everything.  If you’ve got your system planned appropriately and you have your documentation handy which shows how you configured Kerberos and the affiliated SPNs in your domain schema troubleshooting should be too easy, right?

4 – Be prepared to hit the logs for troubleshooting.  There are two logs that you should probably be acutely familiar with – the IIS logs for the associated web applications in your SharePoint enclave, as well as the Unified Logging System (ULS) logs for SharePoint.  If you’re familiar with web applications and how to read IIS logs, then you should be fine and not have any issues.  ULS logs for SharePoint on the other hand can be somewhat cryptic in nature.  I would highly recommend using something like the SharePoint Logging Spy from CodePlex to provide insight into what is truly going on within your SharePoint instance.

5 – Did you check to make sure your interfaces were still connected?  It’s always embarrassing when you realize after the fact that your data communications problems with SQL server weren’t necessarily a password change or a malicious DOS attack to down your data sources, but just a lose HBA or Ethernet connection.  As my CCNA instructor mentioned five years ago, start at the bottom of the OSI model and work your way up.

Are these the only five things you need to know and consider when troubleshooting?  By all means no.  I would recommend having a few other resources handy when troubleshooting as well (e.g. Google, Live Search, TechNet, me) near by to diagnose an issue and work toward a solid solution to fix the problem in the most elegant way possible (and remember to document the fix should it ever pop up).