Category: Administration

SharePoint Administration related posts

Learning SharePoint – Sys Admin

There is no question that the interest level for SharePoint right now is very high. The product has great penetration into the business application mix world wide. The downside to this in the current business climate is that there are an awful lot of people being put in charge of SharePoint farms that have limited understanding of what SharePoint is or how it works.

Below is a brief set of recommendations I would give to any System Administrators looking to really dig into SharePoint.

Where to start?
Get a book… There are some great books out there including the ones that are linked on the right side of this site. They do a great job of outlining the overall architecture of SharePoint and explain how the various layers and modules fit together. It is very important to understand the foundation.

Formal Training
If there is budget, then formal training is a great way to get a solid start. There are dozens of training providers, the top tier include: Critical Path Training, Mindsharp, and SharePoint Bootcamp.

Create a Sandbox
You need some place to dig in and interact with the system. For Power User training I will typically give the user a dedicated site collection on a non-production farm. For a Sys Admin though they really need to be able to go through the full setup and configuration and be allowed to experiment with farm wide changes. To do this they really need a dedicated environment. A one server farm is a good place to start, but it should be understood that with multi-server farms the security boundaries become a little more difficult. If it is a single server farm, I would not recommend doing a basic install because it changes the way the Personalization (MySites) and Shared Service Provider apps are configured.

Top Topics to concentrate on:
• View and understand “Servers in Farm” along with the server roles
• Understand the SharePoint databases and each database’s purpose
• Create and Extend an Application
• Create Site Collection
• Maintain Alternate Access Mappings
• Backup and Restore of Site Collections
• Patching Process with Configuration Wizard and PSConfig
• Deploying Solutions, Web Parts, and Templates

Participate in the Community
The SharePoint community is very strong. There are a number of great SharePoint user groups around the globe, as well as other community events like the SharePoint Saturday events and other regional conferences. This is a great way to meet other professionals and pick up on best practices.

Read the SharePoint Forums
There are some great forum resources like the MSDN/TechNet Forums, Stackoverflow, and the SharePoint University Forums. Reading the forums will give you a good idea of the types of common problems other people have in their farms. Reading through the problem and the solutions is a good way to get a solid understanding of how everything fits together and can also help you prepare when similar issues occur on your systems.

Get Certified
There are two MCTS exams available to SharePoint Administrators. While a certification is no replacement for experience it can help validate you knowledge of the platform.
Exam 70-631: TS: Windows SharePoint Services 3.0, Configuring
Exam 70-630: TS: Office SharePoint Server 2007, Configuring

Managing SharePoint Customizations and Change Log

In previous posts I wrote about SharePoint Customization Policies and Change Control. That post was pretty high level and at its root questioned the position of some environments that set a No Customization policy. It then gave a brief overview of the types of customizations and how they differ from content changes.

I wanted to follow up with a post that goes a bit more in detail how to manage an environment that does allow customizations along with some suggestions on how to document and manage those customizations.

Packaging Custom Code
Most SharePoint developers start out as regular .NET developers. It is a natural progression and there are a lot of similarities. One big difference comes in deploying solutions. Most try to manually deploy their solutions, not understanding all of the implications. In order to gain all of the benefits of the SharePoint platform code needs to be bundled into packages. Simple, stand-alone web parts can be packaged and deployed via cab files and more sophisticated apps, templates, and timer jobs can be deployed via SharePoint Solution files.

By packaging and deploying these customizations through supported interfaces they will be easier to manage during updates and when adding additional Web Front Ends to your farm.

Targeting Custom Code
Not all solutions or web parts have to be deployed globally throughout the farm. If your solution or web part is used to support a specific application then only deploy it to the site(s) that need it. That will reduce clutter in the solution listings or Web Part catalog.

Tracking Installations and Deployments
It is a very good idea to keep a running list of the patches, components, and customizations installed. This can make troubleshooting issues a lot easier, and help make migrations or farm changes easier. I keep a site within my SharePoint farms to manage the change log and documentation.

Some data elements that I would recommend tracking include:
• Title
• Description
• Requester
• SolType (WP, List Tmpl, Site Tmpl, WF Actions, Timer Jobs, Sys Patch)
• Source (Custom, Community, 3rd Party)
• Install Date
• Current Version
• Scope (Farm, Application, Site Collection)
• Scope Detail
• Additional Details

Related Articles
SharePoint Customization Policies and Change Control
Managing SharePoint Solutions and Extensions

Beginning SharePoint Troubleshooting

SharePoint can prove to be a pain to troubleshoot if you are new to the system, or do not have a good understanding of the system. I intend to give some basic info on how to get started. Use this as a springboard to build your knowledge of the system.

Event Viewer
I think it is safe to say that all admins know where the Event Viewer is and how to use it. The bad news is that I do not find the Event Viewer nearly as useful with SharePoint as with other apps. It definitely cannot be used alone to resolve most issues unless you have previously encountered the issue(s) and know the fix.

Universal Logging Service (ULS)
The ULS logs are vital to the troubleshooting effort. They contain all kinds of information for both success and failures relating to all of the SharePoint services. They can also be tuned to get additional data when troubleshooting.

Some things to know…

ULS versus Event Logs – The ULS logs will contain all of the SharePoint messages that bubble up to the event viewer and a whole lot more. This is why I believe it is difficult to troubleshoot based on the Event Viewer alone. What the Event Viewer will tell you that is not located here are non-SharePoint messages dealing things like general server health, connectivity, etc.

ULS Location – The logs are stored in the “logs” folder in what is commonly known as the 12 hive. The 12 hive has a default location of “c:Program FilesCommon FilesMicrosoft SharedWeb Server Extensions12”

Multiple Servers – It is important to note that these logs are stored on each server in the farm running a SharePoint service. If you have multiple Web Front Ends (WFEs) you will need to make sure that you check all instances of the logs to be sure that you have all of the information. For example if the user generates an error it will only show up in the logs for the server that user interacted with.

Log Viewer – I have previously written a review of Stefan Gordon’s ULS Viewer available on CodePlex. It really makes it easier to filter and read the logs.

Configuring Diagnostics – You can configure the diagnostic levels by navigating to the Central Administration website, Operations, Diagnostic logging.

Adjust the levels as appropriate to try and get the information you need. As the name implies, Verbose will give you the most detailed diagnostics. I would not recommend setting all services to Verbose though; I would try and target specific areas in order to reduce the amount of noise extra data creates.

How big are the logs? – The size of the logs will vary depending on the level of diagnostics set for each service, the amount of usage on the system, and of course what issues you are experiencing. I have for example seen a database server go offline generating over 1000 errors a minute until the db was available again.

Within the diagnostic configuration screen, there are settings to help manage both the number of files and the period of time each log will cover. By setting these two fields to an appropriate value you can help to minimize the storage requirements, and also make each log easier to read.

What to look for? – My first course of action is to look for the first error in the log relating to the issue I’m trying to resolve. I then try and look at the information directly preceding that to try and determine if it is related. In many instances the actual error reporting is sort of a generic dump that does not specify the condition or point where the failure occurred.

I also look for patterns throughout the file to try and see what might be related, what might be a symptom, and what else is going on that maybe is not related.

It should go without saying that if the databases are not available the system will not be as well. Errors like “Cannot connect to Configuration database” will ruin your day in a hurry.

Validate Connectivity – I normally start my db troubleshooting by validating connectivity using the main SharePoint service account. An over zealous dba may have made a change that prevents access to the db.

Automated Updates – In some rare cases, I believe primarily with WSS, I have seen Windows Update push a patch or update that requires further administration before the system is available again.

Basic Install – In cases were a basic install was originally done, you may experience some additional hurdles in maintaining and troubleshooting the database.

The WSS install uses what is called the Windows Internal Database which has some interesting limitations. The biggest limitation is that you cannot administer is using your regular toolset like the SQL Server Management Studio, you need to download and use a command line cool called SQL Cmd.;=en

The databases are located at C:WINDOWSSYSMSISSEEMSSQL.2005MSSQLData
Further info on the database and how to work with it is available here:

Roles and Services
Early on in your admin career you will probably start with broad moves like restarting the server(s) to clear up issues. As you get a better understanding of the system and when you start to relate the error with a specific server role or service you can start to zero in on the specific sub systems. At that point you can target restarting specific services instead of rebooting one or all of the servers in the farm.

One key to maintaining a healthy farm is early detection of issues, and being able to interpret the early symptoms before it leads to a real problem. One example of this that I struggled with for awhile pertained to issues doing a Full Crawl on a medium farm with about 150Gb of content. I started to see a pattern where a seemingly unimportant message in the logs would signal that the indexing service was going to lock up. It is good to know this early in the process, and not 5 hours into the process. Initially the fix included restarting the server, but in this case simply restarting the indexing service was enough to clear up the issue. We then setup a monitor to look for the initial warning message saving us time in getting updated content into the index.

Where to turn for SharePoint help?
There are a number of no cost community resources including:
MSDN/TechNet Forums
SharePoint University Forums

There are also a number of paid options
MS Support
Other Vendors – A number of other vendors offer per incident or contracted support

Other Considerations
Backup & Recovery needs to be thought about before you have any issues. I cannot count the number of times I have run into people that are trying to fix a major issue but have no current or meaningful backup. This should be a top priority.

Disaster Recovery is also vital, but it should be a different approach than normal Backup & Recovery since it includes the whole platform; features and content.

Patches and Maintenance should be handled with care and ideally should be tested in a non-production environment first. The time it takes and the issues that may result vary quite a bit. When issues arise, and they will at some point, you need to know how to proceed and/or you need to contact a qualified technician asap.

Stacking Managed Paths

Most SharePoint administrators are likely familiar with the Managed Paths feature that allows certain paths to be designated to hold site collections. The “sites” entry is added by default. Not everyone knows that those paths can be stacked to provide the same functionality at different levels.

Flat versus Deep
As part of any Taxonomy plan the team should always consider the appropriate depth to the site collections. Some might argue having a flat taxonomy with lots of siblings, while others will push for a traditional hierarchy.

Using single level Manage Paths help to provide fairly flat site collection taxonomy. That would give you a top-level site, and then site collections organized one level down. In most of the systems I have worked with there are more than one entry, typically separated by a general purpose (i.e. Projects, Team Sites, Applications, ECM Sites).

In some medium complex organizations that may not be enough. Perhaps there are multiple business units, and the sites could benefit from some BU level landing pages with the site collections below that. Stacking the managed paths will provide this.

For example:

Regular managed paths: http://myserver/units/

Stacked managed paths: http://myserver/units/euro/sites/

Note: In very large organizations it is likely that these sites would be in separate web applications or even separate farms. This technique may still offer value.

Landing Pages/Sites
To establish a landing area Site Collection above each of the managed path entries you will need to define a single level managed path and create the site collection as usually. Using the example above /units would be used for the managed paths and the site collection would be setup at http://myserver/units/euro. This would serve as the landing page for European Operations. The site collections underneath would be organized in the sites path.

When establishing the managed paths, the system does not check to see if a site exists at the path you supplied. If you were to setup a site collection at http://myserver/units and then establish /units as a managed path the site would no longer be accessible.

Site Collections versus Sub-Sites
There are a number of reasons why you might choose the isolation of Site Collections versus creating sub-sites. One big reason to require Site Collections would be for Quota Management which may be needed to support a chargeback system. Since quotas are set at the site collection level you will need isolation in order to manage that effectively and provide accurate notification and reporting.

Server 2008 and User Account Control

Recently while working with a Windows Server 2008 I found myself unable to run any STSADM commands. No matter who I was logged in as I kept receiving an “Access Denied” error which seemed awfully strange.

I proceeded to search the web for this issue and I found multiple sources identifying the issue as part of the User Account Control functionality. All of those sources recommended disabling the feature, which requires a reboot. The feature has value so I wasn’t too keen on disabling it, and having to reboot a production system during business hours is never fun. I proceeded with disabling the feature, but decided to follow up with it afterward.

I have since learned that getting past this block is quite easy. It simply requires that the user right click on the Cmd prompt and select “Run as administrator” in order to have the command complete.

MS Support has published a good overview explaining the User Account Control feature:

Hope this helps fellow administrators bringing up systems on Server 2008.

Search versus Information Architecture

At a recent Triangle SP User Group meeting an interesting debate broke out regarding the use of search to find information inside of a SharePoint system. One person went as far as to say that “search is a last resort” while another said “if a user has to search, you have failed.” Those are some pretty strong positions to say the least. I believe that Information Architecture and Taxonomy are incredibly important, but Search is as well and should not be a last resort. If proper planning is not done in both areas people are going to have trouble finding what they are looking for.

Preferred Method Depends on Context
First I think this debate requires context since the type and the amount of content to look through can range dramatically. Browsing a Wiki with 20 pages is not the same as browsing a Document Library filled with 100,000 invoices. For the former it would seem crazy to need to rely on search, but with the latter it is absolutely essential to most end users.

Users Think Differently
I have had the chance to do usability studies for large SharePoint implementations in a few organizations now. Early on I was amazed at some of the feedback I received with regards to organization and taxonomy. All users do not process thoughts the same way, so while you can work hard to cover all your bases some will still be left out. Put as much time into planning the Taxonomy as possible, and review it on a regular basis as the content and purpose evolves.

Search Needs Tuning
The search service with MOSS can be pretty powerful, but it isn’t something you just turn on and expect targeted search results to be delivered. Time should be spent planning the search system to take advantage of its powerful features including authoritative levels, keywords, best bets, scopes, etc.

As part of this planning effort you should try to identify which sections or sites could most benefit from custom search interaction. If the nature of the data is such that searching is likely to be needed, configure tools to make it as easy as possible to pull that specific set of data. In Mike Gannotti’s presentation, one of the things he suggested was creating a sub-site for each feature or type of list. The advantage of this is that when users search at the “This Site” scope, only data from that level will be returned. With the exception of Wiki configuration, this is not something I have typically done.

Learned Behavior – Browsing versus Searching
After the meeting I reflected on the topic quite a bit, and then a day or two later something occurred to me while working on my Vista machine. When I sent to go open a program I found myself using the desktop search feature to find the programs that were not pinned to the Start Menu. In the past, on previous computers, I had spent an insane amount of time building a system to help organize my program menu. Since I had too many things installed and the menu would wrap, I created a taxonomy with high level categories that led to the program folders (i.e. Dev Tools, Sys Tools, Office). Everyone agrees that browsing to something when you know its exact location is very quick. However, it is quicker still to type in a name and then double click the result returned. Reaching the Event Viewer for example has never been so easy. Without realizing it, my behavior in this OS has changed. While I am not a typical end-user, I believe that I am not unique in being able to adapt to new ways of finding information.

End User Ownership and Evolving Content
Some of the biggest Information Architecture challenges I have seen come from the fact that in most organizations many of the site collections are owned and managed by business units. You can try to educate them on proper planning and maintenance, but in most cases it is far from their top priority even as people complain about usability.

In many cases the purpose of the system changes leaving it out of sync with the taxonomy or navigation design. This is a sure fire thing that pushes users to rely on search.

Best Way Forward
I think the best way to tackle all of these challenges starts with proper planning and site owner education up front followed by periodic reviews of existing sites after the fact. If you can schedule reviews either quarterly or semi-annually as part of the overall service offering it will help you limit some of the issues of End user Ownership and Evolving Content. By keeping the system tuned, users will be more productive, and therefore more interested in using the system which increases end user buy in.

Where Do You Stand?
Where do you stand on the debate? Do you have anything to contribute to the discussion? Is Search a last resort? Is developing a maintainable taxonomy even possible?

%d bloggers like this: