SharePoint Dan

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:\inetpub\logs) 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>:<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 Files\common 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 Events\Logs\” as the directory followed by the appropriate event log file name. This is documented in: http://support.microsoft.com/kb/216169

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 http://support.microsoft.com/kb/312571 (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.

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&#44;” made it through quality assurance testing, but alas, not a huge detail right? Simply replace the “&#44;” 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.

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:

http://www.microsoft.com/downloads/details.aspx?FamilyID=1c222804-51c7-4bb5-ae3d-89c68ad27a78&DisplayLang=en

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.

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…

http://www.microsoft.com/downloads/details.aspx?FamilyID=1c222804-51c7-4bb5-ae3d-89c68ad27a78&displaylang=en

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

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.

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 Lucia – Paco De Lucia, John McLaughlin, Al Di Meola – Manha De Carnaval

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?