SharePoint System Administration

Patch Tuesday – January 2014

A few quick bits of information for today that might be of interest to those of you working with the Microsoft Stack.

If you dig into the KB2916605, it’s labelled as important, not critical but probably something you’ll still want to address. This impacts impacts Microsoft Word across several versions as well as the Word Automation Services and Office Web Apps of SharePoint 2010 and 2013.

Also new today, Power BI is now available for purchase for your Office 365 SharePoint Online tenants. If you have an E3/E4 subscription you’ll see a heft discount.

This past weekend I mentioned during a presentation on getting started with Office 365 that there are service updates that are pushed regularly. To get more information as to what’s being pushed each month, check out the Services Updates for Office 365 for enterprises, mid-size businesses and Education (English) here:

And if you’re interested in learning more pertaining to the Office 365 Service Upgrades that are ongoing for the Enterprise, more information is available here:

Looking for the latest and greatest when it comes to new content for SharePoint 2013?

Nothing really of note, the last update was back on 16 December 2013 with:

  • Deactivated controls in SharePoint Designer 2013 (new)
  • The building blocks of SharePoint hybrid (new)
  • Set-SPAuthenticationRealm (updated)

If you’re looking for updates for MSDN related SharePoint articles, you can find that content here – New and updated content for SharePoint 2013

Infrastructure System Administration

December 2010 Cumulative Updates for SharePoint

This one goes out to my friend and SharePoint colleague, Mark Rackley, also known to many of you as @MRackley. Gotta help my Dev friends that wonder at times why the underlying infrastructure doesn’t work properly – hopefully these bits will help.

Seem like you just got the good bits for the October 2010 Cumulative Update for SharePoint 2010? Just like that *snap* the December 2010 Cumulative Update is available.

The cumulative updates contain several fixes that go across the entirety of the platform from REST to Search to e-mail notifications that should be sent to task assignee’s.

Information Articles for December 2010 Cumulative Updates:

SharePoint Foundation Server 2010 –
SharePoint Server 2010 –
Project Server 2010 –

Windows SharePoint Services v3 –
Microsoft Office SharePoint Server 2007 –

Full server downloads from the automated hotfix system available at:

SharePoint Foundation Server 2010 (x64 – 50.5 MB) –
SharePoint Server 2010 (x64 – 325 MB) –
Project Server 2010 (x64 – 330 MB) –

Windows SharePoint Services v3 (x86 – 29.5 MB, x64 – 33.4 MB) –
Microsoft Office SharePoint Server 2010 (x86 – 63.7 MB, x64 – 60.5 MB)

Please be aware that there are some known issues with the SharePoint 2010 Cumulative Updates which may incur issues with some functionality, namely this:

Important notes about the cumulative update package

  • The Microsoft Office 2010 hotfixes are now multilingual. This cumulative update package contains updates for all languages.
  • This cumulative update package includes all the server component packages. Additionally, this cumulative update package updates only those components that are installed on the system.

Known issue 1
Consider the following scenario:

  • You install the Cumulative Update in this KB article on a SharePoint 2010 server.
  • You restart the server as it prompts you at the end of the installation.
  • You run the Psconfig.exe tool after the server restarts.

In this scenario, you see an error page when you access the Manage User Profile page in Central Administration.


To work around this issue, follow these steps:

  1. Open the Central Administration page.
  2. Click Manage Services on the Server link.
  3. Find the User Profile Synchronization service, and then restart the service on the Server.aspx page.
  4. Perform iisreset after the service restarts successfully.

Known issue 2

2490381 ( ) You cannot create an AD DS synchronization connection that has multiple domains selected after you install the Cumulative Update in either KB 2459257 or KB 2459258


As always, be sure to install cumulative updates in a testing environment prior to implementation on a production system.

Lastly remember that for SharePoint 2010, you only need to download the patch for the product you’re working with whereas with Microsoft Office SharePoint Server 2007 you’ll need both the WSS v3 patch and the MOSS 2007 patch.

Administration System Administration

SharePoint 2010 – Drive Space Conundrum

One of the new capabilities of SharePoint 2010 that comes in handy is the Health Monitoring alerts that pop up on the front page of Central Admin. One thing you might run into is when you start to run out of disk space.  You’ll probably see something similar to this:

Always something that you want to see while you’re working on your environment right? Not so much.

For some reason it always seems that just when things are going well, profiles are synchronizing, users are starting to engage the SharePoint platform, and boom, whammo, the file system fills up with log files, trace logs and event logs. So just a gentle reminder to examine where your log files are and consider moving them to an alternate drive than the core OS drive.

How do I do this you ask?  Pretty simply…

First off, decide what your disk plan is for your SharePoint Servers – hopefully you’ve got more than just a single drive in your system, if not slap on an extra drive (either physical or virtual) for log files, or if you’ve got a SAN handy, request an extra drive on separate spindles from where your data is stored and have them zone it for your SharePoint server to be added for offloading.

Next, for your IIS logs, simply open up IIS and go to the server name (in my case SP2010WFE-01) and then in the main information pane of IIS, scroll down to Logging underneath IIS.

Locate the Directory location and modify it to the location that you’ve setup for log files, in my case I’ve added an additional drive to my SharePoint server with the logical volume “E:”

Once IIS creates the structure, you’ll want to copy over old log files from your core OS drive (C:inetpublogs) to your new location.

Next up, Trace Logs for the Unified Logging System…

Within SharePoint Central Admin, navigate to Monitoring, within Reporting select “Configure Diagnostic Logging”.

Direct Link – http://<NetBiosNameOfSharePointServer&gt;:<CentralAdminPort>/_admin/metrics.aspx

Scroll down to the Trace Log section where you’ll see something like this:

Simply input the drive that you’d prefer to use, in my case replacing %CommonProgramFiles% with “E:Program Filescommon files”, and you end up with something like this:

Go ahead and copy over the contents of the Logs file on the original instance to the new instance to consolidate your log files.

Lastly, moving your event logs to the log drive is definitely a consideration to make – especially the Security Log file as this will grow quickly once you’ve implemented Kerberos and opened your system to your user base (NTLM spawns quite a few security events too). Out of the box you’ll see your event logs like this:

Application Event Logs

Security Event Logs

System Event Logs

Simply modify the “File” location to the new location where you are looking to store your files, in my case I use “E:Windows EventsLogs” as the directory followed by the appropriate event log file name. This is documented in:

Further, to ensure that log files don’t explode, leverage the “AutoBackupLogFiles” property within the Application Events (you’ll have to add this to the Security and System Event Logs, simple DWORD property). Setting the value to “1” or any value other than “0” will create backup files in the file location specified.

This is documented in (though it’s specific to 2000/2003 server, it works for 2008).

These three simple changes should assist in keeping your core OS drive lighter weight and prevent your system from a hiccup caused by a disk filling up.

System Administration Troubleshooting

TaxonomyPicker.ascx bug (SP2010 RTM)

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=, 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 FilesCommon FilesMicrosoft SharedWeb Server Extensions14TEMPLATECONTROLTEMPLATES 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.

System Administration

SPDiag v1 – First Impressions

So as a follow up to mentioning of the tool, my first impressions to the SPDiag tool are essentially – holy guacamole, this is awesome!  It’s nothing super flashy, though you can download the .net 3.5 Microsoft Charts plugin to provide for additionally graphical views of information.  It sports the plain jane simple minimalistic UI that we’ve become accustomed to as infrastructure engineers, but hey, it’s the content that counts!


The tool is fairly simple to setup and out of the box requires very little configuration, though if you’re interested in configuring it to meet a specific case where specific traffic is being filtered or merged, the configuration guide is available at:

The more interesting information from my perspective that provides for quick and simple analysis of a farm are the solutions and timer job definitions information that can quickly be glanced at.


Lastly though, this tool also brings together trends that show up in the monitoring metrics with a little bit of graphing capability using the aforementioned .net 3.5 Microsoft Charts plugin.  Granted, what you see below isn’t all that interesting, but that’s also because there’s not much configured or utilized in this dev farm…yet.


Props to the SharePoint Product Team for developing this tool as a part of the upgraded toolkit suite!  Stay tuned in for future updates and to see some pretty data streaming through the Trends section.

System Administration

Microsoft SharePoint Administration Toolkit v3 Available

For those of you that read the recent article pertaining to the SharePoint Diagnostics v1 tool for SharePoint 2007 and were slightly confused and left wondering where it was buried in the v2 release of the toolkit, Microsoft has answered the question.

Downloads available at:

Microsoft SharePoint Administration Toolkit v3.0 x86

Microsoft SharePoint Administration Toolkit v3.0 x64

“The SharePoint diagnostics tool provides administrators with a unified interface for troubleshooting SharePoint Server performance issues…”

To read the documentation available…

Now Playing: The Goo Goo Dolls – Let Love In – Stay With You

System Administration User Permissions Web Parts

Have you clustered your users yet?

Yes, you read the title correctly.  I’m not referring to clustering SQL servers, nor am I referring to your clustered ISA servers, or Microsoft Clustering Services.  Rather I’m talking about clustering your users to see what their permissions are and if they’re similar to the permissions of anyone else in your farm.

What are you talking about?

AvePoint has released as a part of their DocAve suite, a free tool that “clusters” your users with like permissions into a visualization to provide you with the ability to look at a user and see users with similar permissions.  It’s proper title – “User Clustering Web Part for SharePoint”.

This is definitely different than what other companies have put together in terms of permissions related capabilities in tool suites like Barracuda Tool’s DeliverPoint or iDevFactory’s Universal SharePoint Manager 2007, and actually could be very helpful.  One of the things mentioned in the demonstration video is the ability to see the outliers.  This could be very beneficial in situations where you have someone that has far more permissions than you meant for them to have.

I’ve yet to pull down a copy for myself and try it out, but I thought it was a neat idea nonetheless… I’m curious if it shows permissions of users that have access to sites that are in web application level security groups… something to find out.

Architecture System Administration

Contextual Considerations of Technical Planning

On 10 January 2009, I attended the SharePoint Saturday – Virginia Beach event with a friend of mine, looking to see SharePoint from a different angle and take in new perspectives and perhaps learn a thing or two while being refreshed by others in the "community".  It was great to meet Paul Galvin, Dan Lewis, Becky Isserman and John Miller.

The first session that I attended was led by Dean Halsted of Microsoft. Dean’s session was entitled, "Technical Best Practices". I cringed. Why did I cringe? Primarily because I’ve learned that the words we use unintentionally influence the thoughts of those that we’re speaking to significantly. If we mention the buzz words "best practice" then regardless of what is said down the line, there is no going back, the "best practice" is essentially canon – there can be no deviation.  Lesson Learned – try not to call something a best practice unless it applies regardless of context.

So does that mean? No "best practices"? By no means… there are definitely core things to think about from a technical and functional perspective. There is however the distinction that while keeping things in context and consideration of the technical problem at hand, the solution may not always be the same. Design recipes, patterns and practices are approaches for problems, not necessarily pre-baked cookie batter waiting to be dished out.

Needless to say this got my brain cooking on contextual considerations and is the melding of Dean’s thoughts, those of others and my own, intertwined with commentary.  For this post, the primary focus will be just on the “Pre-Deployment Considerations”.

Overall, Dean’s session was informative as he provided information that while common sense to the seasoned SharePoint engineer (though still a good reminder and refresher) a key set of starting points and considerations for the rookies and novices in the crowd.

Prior to the deployment of a SharePoint system in the context of enterprise systems that are rigorous and require change management processes be in place to assist the information worker, several key things should be considered to include:

  • System Quotas
  • Information Policy
  • User and Server Network
  • System User Base
  • Authentication Mechanisms

Each of these should be planned out so as to ensure that the deployment of SharePoint is seamless and that there are no surprises. As an engineer, we might like surprises and problems that require elegant solutions, but for clients, the preference really should be that we find them out prior to deployment in a test bed.  One decent example to make note of in terms of overlooked planning is the use of quotas. Without a quota in place, there is no way to keep a site collection from grow rapidly without oversight. In some instances sprawling uncontrollably causing system failures due to hard disks filling up (you’ll see this often if you’re not using a SAN or DAS). By applying quotas when a system first deploys it provides for greater flexibility and allows all sites with the quotas applied to quickly be updated should you decide to increase the size allowed – similar to the way gMail has a quota for your mailbox.  With quotas initially enforced they can be increased dynamically across your entire web application rather than having to go site to site to site.  For more on this topic, check out Dan Lewis’ recent post on “Managing and Administering Site Quotas in SharePoint”.

Information policy, while not typically touched upon by the novice administrator can come in quite handy when creating internal and external access boundaries. This additionally comes into use when the need for certain personnel within an organization require access to all items within a particular web application, or when it is required that a specific user cannot access a site, regardless of what permissions a site administrator may attempt to grant the user.

Defining and designing the user and server networks within an organization are never trivial unless working with an organization that resides completely on a single network segment without firewalls or any other boundary. For smaller organizations, it might even be ideal to host the environment on something like Amazon EC2, Microsoft SharePoint Services Cloud, or through a hosting company like 1 and 1. Perhaps your organization is looking to have a centralized deployment with a significantly large farm to provide a high performance end user experience – has the farm been load tested from several systems sitting within the network to ensure that the circuits don’t be come saturated?  For most large organizations additional planning and consideration must be taken to ensure that latency is minimal, availability is high and that integration is not degraded.

Defining the System User Base is also a necessary step that should be investigated. Knowing where the users reside, what levels of access they require and the overarching permissions model provides for to include security groups will provide for a more seamless and palatable deployment across an organization. This will cut down on the confusion of how users access sites and what user has permissions which will make your system administrator’s will to live increase significantly 🙂

Authentication mechanisms… figuring out how your users are going to come into the system is key. Are you using ISA server as a proxy in a DMZ to allow for external users or forms authentication? Are you merely using SharePoint on an intranet and don’t require anything fancy so you settle for NTLM? Are you working with integrated systems that require a double hop to occur for credential passing and therefore have to go through the tedious task of setting up Kerberos? All considerations that require diligent investigation based on the context of the environment.

Overall, there are several other factors that should be considered prior to deployment, but I’ll save those for another day.  What are some of the key things that were planned prior to your organizations deployment?

Now Playing: Paco De LuciaPaco De Lucia, John McLaughlin, Al Di MeolaManha De Carnaval

System Administration Troubleshooting

Expiring Service Accounts…

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?