SharePoint Resources and Knowledge Management

Lack of “proper” training is a common end user complaint in many SharePoint environments. Hopefully training plans have been developed, but in addition to formal training I have also focused on providing online resources for task and audience based training.

Going through this exercise can also provide a great introduction to Knowledge Management concepts that can be applied to other aspects of your business and processes. SharePoint includes many core features that are very well suited for Knowledge Management and that can be easily configured to match your requirements.

Microsoft has many good resources available on their Office Online website. I’ll frequently identify specific content that is especially helpful and provide links to that content.

A good place to start is to include the following content:
• SharePoint Contacts
• Video Tutorials
• Task Based Instructions
• Training and Event Calendar
• Helpful Links
• Frequently Asked Questions
• General Discussions

When identifying content, try adding custom properties to help organize it based on the Audience (User, Power User, Site Owner, Developer, Administrator) and maybe some categories (Documents, Lists, Wikis, Blogs, Security, etc).

Identifying the content is a good start, but in the second phase look for ways to deliver that content targeted to the specific audiences or categories. For example if you provide a filter web part with the list of Audiences you can connect the filter to each of the list views. It is also a good idea to try and keep the content fresh. Add additional information as needs arise and try and get involvement from the user base.

I would like to thank Laura Rogers a.k.a. @WonderLaura for inspiring this post after a brief tweet this week about updating a SharePoint Resources site in her org. The mere mention of this topic opened the creative floodgates.

Supporting Multiple Active Directory Domains

In many environments there is more than one Active Directory forest with users that need access to the SharePoint farm. Setting up support for users on multiple domains is pretty easy and can provide new collaborative features for users throughout the extended organization.

Trust Relationship
The only prerequisite is that there has to be a trust relationship between the forests. Users from the other domain(s) will need to be able to authenticate and access resources on the host domain.

If that trust is not in place, here is a good resource: Support for Cross-forest deployments

Setting up the Import
The Profile import settings are in the Shared Service Provider’s User Profile section. Setting up the primary domain, the domain the server is on, is pretty straight forward and the default settings should be fine.

To setup an import for additional domains click on the “View import connections” link from the main User Profiles and Properties page followed by the Add Connection item in the toolbar. Fill in the domain information and click the Auto Fill Root Search Base button. If the SharePoint Administration account does not have access to read from the target domain you will need to supply an account to read the directory.

People Picker Control
If there is a one way trust, or there are duplicate accounts (display names) on different domains it may be a good idea to set some additional properties. In the article Select user from multiple forest domains it provides a path to specify which forests to search, and allows the passing of credentials if the SharePoint Administration account does not have the required privileges.

The platform does a good job of supporting cross domain collaboration, and it is a lot easier to setup than many enterprise systems. In one environment I had to support over thirty domains so the information included above really came in handy.

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.

SharePoint Saturday – Charlotte

Registration for SharePoint Saturday – Charlotte has opened and is available here.

The list of speakers has also been announced and is packed with some great SharePoint professionals.

Sessions normally run from 9am until 5pm with a break for lunch in the middle. After the event a SharePint event will be available at a local establishment for additional networking and discussions.

If you are interested in attending, be sure to sign up early since seating is limited and has resulted in a long waiting list in most cities.

Hope to see a bunch of old friends, and meet some new SharePoint people!

You can find the event on twitter @SPSaturday_CLT

or by following the tag #spsclt

%d bloggers like this: