Category: Administration

SharePoint Administration related posts

Managing SharePoint Solutions and Extensions

One of the great things about SharePoint today is the incredible traction that the platform has gained. The depth and range of solutions now offered by vendors along with open source solutions offered by the community really is amazing. It was a different place when I first installed SharePoint Portal Server 2001 back in early 2002.

Browsing the CodePlex I often feel like a kid in a candy store. So many great solutions, I cannot wait to install them all! Well not so fast, it might be a good idea to take a step back and consider the consequences.

Deciding What to Install
One key to maintaining a well run environment is to have a process in place to review, approve, and manage customizations. This should be part of your formal governance plan, but if you do not have one do not let that stop you from looking at this particular topic and working out some plans.

Special care should be given to non-commercial solutions. They should always be tested in a non-production environment before being deployed to your production environment. When downloading community code, be sure to take notice of who is contributing it and what the official release is. CodePlex for example does a great job of showing build info and release notes. If an item is marked as Alpha or Beta it probably has not been put through rigorous testing yet. If you want to use it then make sure you are comfortable with the risks and test it in your environment.

Testing Environment
Your test environment should be as similar to your production environment as possible. You do not necessarily have to put it on the same quality of hardware, but the configuration should be similar. It is critical that the patch levels are the same. On this note, you should be testing any KB Patches, MS Cumulative Updates, or Service Packs anyway.

Make sure that the test environment also includes the full catalog of Solutions, Web Parts, and other customizations. This is important because it is possible that one might conflict with another. Unit Testing is not enough, you will want to see how it will react and interact with your environment.

Potential Problems or Conflicts
Depending on what functionality the solution provides, the problems or conflicts can range quite a bit. Knowing what is installed is a good start.

While there is a chance that something could break independently, most of the issues I have seen came from trying to migrate, patch, or upgrade a site.

Site Migration – When migrating a site from one environment to another, it can be a pain to find out half way through that you need to install additional site templates or web parts on the target server.

Patch – When completing the installation of a Patch, Cumulative Update, or Service Pack you normally have to finish the upgrade by running either the Configuration Wizard or the PSConfig command line app. This can be a pretty stressful exercise, and no fun comes from seeing it fail along the way. I have had customizations cause problems here, particularly when changes were made directly to the web.config file as some solutions require. Having your documentation on hand will help you get through the mess and cut down on the time it takes to complete the upgrade.

Future Versions – You also need to consider the likelihood that the solution will be maintained going forward. When I made the jump from WSS 2.0 and SPS 2003 to the current version WSS 3.0 and MOSS many of the solutions I had been using did not make the jump. Some of it was because of the code base changing from .NET version 1.1 to 2.0 and some of it was because Microsoft added parts of the functionality to the platform so vendor no longer wanted to support the products. End users are not necessarily going to care why they do what they used to do, they will only care that they cannot do it. Mitigate the risk by communicating to the stakeholders the potential problems.

It has already been noted that Service Pack 2 will include an upgrade readiness check to help identify any potential problems upgrade to the next version. I would recommend taking the time to go through this check after SP2 is installed, and then checking it again after you install any new solutions before making the jump to the new release.

Summary
By putting together a plan to review, test, and approve add-on solutions you will decrease the likelihood of problems in your environment and decrease the time it will take to respond to issues when they do come up.

Resolving the MySite File Exists Error

I have seen this error come up a few times, and reported frequently on the MSDN/TechNet Forums. Once the problem is understood, it is fairly easy to correct.

There are a few different pieces that come into play when a user clicks on the My Site link at the top of a MOSS page. The user goes through a centralized MySite.aspx page that acts as a redirect. A check is done to see if the user already has a My Site specified in their profile. If there is a site specified it sends them to the site, if the site is not specified it sends them through the site creation process.

Error
On a couple of occasions I have seen the following error:

The file exists. (Exception from HRESULT: 0x80070050)

Troubleshoot issues with Windows SharePoint Services.

This happens because the user’s profile does not contain a valid path in the Personal site field. The user is then pushed into the site provisioning process, but since the site paths have to be unique, the process is unable to create a new site.

For some reason the profile field was reset or corrupted leaving it blank or filled with something like an error code or invalid statement.

Resolution
To resolve this issue, you want to first validate the path to the user’s site. The path will vary depending on your setup and naming conventions, but it should be something like http://servername/personal/juser

Once you know what the valid path is, update the Personal site property to include the valid path. Ex. “/personal/juser”

To update the user’s profile:

  • Navigate to the Shared Service Provider
  • Click the User profiles and properties link
  • Click the View user profile link
  • Search for the user’s profile
  • Click the Edit option in the item’s menu
  • Update the Personal site property
  • Click the Save and close option in the toolbar

What causes the error?
On a few occasions the cause could not be determined. Since it was easy to fix we didn’t spend a whole lot of time looking into the cause. The majority of the instances happened after an Active Directory migration where the user’s profile was migrated incorrectly.

When going through an account migration either through Active Directory, or in switching to something like Forms Based Authentication (FBA), make sure you migrate the user profiles using Migrate User. Additional information can be found on that topic at the blog post titled SharePoint AD Migrations: Users and Servers.

Migrate a Site Collection with Different Patch Level and User Accounts

I was recently asked to restore a site collection that was being hosted on an external provider’s network without any SharePoint patches installed. There were also some custom templates installed that had to be tested internally.

Bringing this site in took a little extra work. We couldn’t just restore the site collection backup into the regular production farm.

Update: – When I originally wrote this post I thought both servers had to be at the exact same patch level, but this is incorrect. The target server needs to be the same or greater.

To handle this, I went through the following steps:

Step 1 – Create a new farm with matching revision level (or greater)
The system I configured was a basic one server install of MOSS.

You can find your version number by migrating to any SharePoint site’s settings page (i.e. Site Actions, Site Settings). Here is a resource for matching your version level to the installed patch level: http://www.mindsharpblogs.com/penny/articles/481.aspx

Step 2 – Install any Customizations
Next you need to install any customizations such as custom or third party web parts, site templates (i.e. Fabulous 40 Templates)

Step 3 – Restore the Site Collection
Restore the site collection using STSADM’s restore command.

Step 4 – Migrate the site collection’s users
Next you will want to migrate the site collection’s user accounts to your internal accounts. This will ensure that user security, content ownership, and historical changes are maintained.

To migrate the users simply run the STSADM’s migrateuser command for each user.

NOTE: I later experienced an unexpected issue. While the migrateuser command moved user profiles, it did not update the mappings for the site collection administrators. Before you continue make sure you review and update the Site Collection Administrators group with valid internal accounts. If you don’t you will not be able to export the site collection or even run commands like Enumsites. The tools will return an Unknown User error because there is no longer a valid Site Collection Administrator.

Step 5 – Validate the site
Make sure that everything is the way it should be. Test your sites, review the content, and make sure that there are no other templates or pieces missing.

Step 6 – Install Patches
If it is not at the same level as your production server, install all of the Service Packs, Cumulative Updates, and KB patches to match your production environment. Most of those will require running the configuration wizard or pscofig afterward.

Step 7 – Backup the site collection
Run the STSADM’s backup command to export the content.

Step 8 – Restore the site collection to the production server
Restore the site collection using STSADM’s restore command.

Admin Tool – SharePoint ULS Log Viewer

Recently while browsing CodePlex I came across a very useful tool that I wanted to bring to the attention to SharePoint administrators everywhere. The project is the SharePoint ULS Log Viewer which was built by Stefan Keir Gordon.

Here is an overview taken from the CodePlex info:

This is a WPF application powered by LINQ.

The current release (2.0) has the following features:

  • Parse and open multiple SharePoint ULS logs (will concatenate them if you select multiple)
  • Reorder and resize columns, sort on any column
  • Filter by Severity, Category, and Process or a custom text filter/search
  • Group multi-line stack traces into single log entries for easy viewing and copy/paste
  • View message easily in separate pane (No more scrolling in notepad)

I reluctantly admit that up until now I have relied on NotePad or TextPad to interact with my logs. I kept saying I would take the time to write something, but I just never got around to it. This tool is polished and full featured, so I definitely no longer have a need to develop anything.

Take a look; I’m sure you would agree. A big thank you to Stefan for contributing this to the community!

Using Site Columns to Reuse Data

During my time with SharePoint I have encountered a number of requests where users want to be able to reuse data between sites. Using the DataView or Content Query Web Part (CQWP) is pretty easy since it supports connecting to lists on other sites, but it does not help for situations where the requirement is to include a linked field within a list. Linked fields can only be configured to link to lists within the same site.

You can get around this limitation by using a Site Column to establish the link. The important thing to keep in mind is that the Site Column needs to be established at the same level as the column you want to link to. This means that the approach will only help with sites that are below the site that the Site Column is defined at.

For this example I have defined a contact list called CustomerContacts which is at the root of the site collection.

Then define a Site Column called MainCustomerContact that links to the Full Name field in the CustomerContacts list.

The next step is to add the new Site Column to a list on a sub-site.

After it has been setup you will now have the dropdown list when you go to add or edit a record in the list.

Fields with a value from the other site will display as a link, just like normal linked fields.

Clicking the link will lead you to the list’s item view with all of the details for that item record.

Using this method will help you reuse the data already being maintained in the system without having to duplicate the list or list data.

Impact of SharePoint Designer Free Distribution

This week it was announced that SharePoint Designer 2007 and future versions are now freely distributed.

Announcement

Download

The developer community was quick to applaud the news since this is a useful tool, but I assume also because getting software purchases approved in the current economy is difficult at best even in stable companies.

The news however brought a different set of comments from the system administrators and IT management folks who are worried about what the ramifications will be. They are right to be worried. Many companies are already struggling with governance and end user site ownership issues. With that in mind I think it gives them that much more incentive to get their policies, procedures, and training plans in order.

From a Program Management perspective, I think it is critical to the platform to enable end user groups to design, manage, and interact with their own content. That includes maintaining their own access control lists (ACLs), libraries, lists, and design their own workflows. I see SharePoint Designer as an extension of the platform, not much different than MS Word or Excel. Site Owners and Designers need to be able to manage this in most situations.

In a medium to large organization it would take an army of IT team members to manage this for every group, it is just not feasible and not the purpose of the SharePoint platform.

So how should you proceed?
Governance – Address custom design and development in your Governance plan. Determine who can have it, and what it can be used for.

Training – Address its use in your training plan, and make sure that Design and Developer resources are available. Perhaps you can pick up a copy or two of Professional Microsoft Office SharePoint Designer 2007 (Wrox Programmer to Programmer).

SharePoint Designer Collaboration Site – Provide site owners with a place to collaborate and provide guidance. You can include samples, links, and FAQs to help them.

Through proper governance you can help guide their decisions and enable their success. Their success and approval leads to the success of the platform in your organization.

What can be done to prevent use of Designer?
Installation – For now you can look at local computer policy and prevent installation of unapproved software. For people in companies that already do this, they know that it takes a lot to manage that.

Security – You can also review site security and make sure that the appropriate set of users have access to make changes.

Disable at the Site Level – There is some work in the community right now to come up with a solution to prevent specified sites from being changed or customized with SharePoint Designer.

UPDATED: John Ferringer and Brian Farnhill have posted a Beta for the project, setup as an HTTP Event Handler to block SP Access. It can be found here: No SPD HTTP Event Handler.

What is your response to the news? Excited, terrified? Post a comment!

SharePoint Active Directory Migrations: Users and Servers

I have been hearing more and more questions recently about Active Directory migrations with relation to SharePoint deployments. It could be from some organizational changes, or because business managers just like to keep people busy.

When I had to go through this process during the summer of 2008 I found much less information that I expected so I had to work through some of the problems myself. Here is the result of what I found. Hopefully it can assist other organizations in the process.

I have broken everything into five steps; Prep, Server Move, Service Updates, Migrating User Accounts, and Post-Migration Validation.

SharePoint Supports Multiple Domains
One thing I want to point out is that SharePoint works great in environments with multiple domains. The only prerequisite is that proper domain trust is in place to support authenticating users across the domains.

If the users will be migrated slowly over a period of time services should go uninterrupted. It is possible to keep the servers and services running on the old domain until all users are migrated, or move the servers and services early on and then run the user migrations in batches over time.

Preparation
Before any major system changes it is always a good idea to perform and validate a fully system and content backup. It is also essential to ensure that you have a non-domain account available on the server that you can use to access the server after it has been removed from the domain.

I would also make sure that all of your site profiles are currently up to date. To do this run the following command:

stsadm -o sync -excludewebapps {Web applications} -synctiming {schedule} -sweeptiming {schedule} -listolddatabases {days} -deleteolddatabases {days}

TechNet Documentation for STSADM –o sync: http://technet.microsoft.com/en-us/library/cc263196.aspx

Server Migration
Migrating the server from the old domain to the new domain is handled through regular computer settings and is not SharePoint specific. If you do this manually, keep in mind that you will need an administrator account on the server after it is removed from the domain in order to join it to the new domain.

There are some good Active Directory migration tools from vendors like Quest software that can automate the move process. In addition to the remove and joining to the new domain it can migrate the user profiles and add in a list of domain users to the local Administrators group.

Update Services
Migrating the farm services is pretty quick and easy. There are commands in the stsadm tool that allow you to update all of the accounts used within the services and IIS application pools.

Run the commands and then reboot the servers so that all services load under their new identities.

The following MS Support link provides an overview and examples. http://support.microsoft.com/kb/934838

Migrate User Accounts

stsadm -o migrateuser -oldlogin {domainname} -newlogin {domainname} [-ignoresidhistory]

The ignoresidhistory input at the end is optional. The SID is a guid for that user account, and a reference to it is stored in the SharePoint profile. If the accounts were migrated correctly the SID history should be maintained.

By default the migrateuser command will validate that the oldlogin and newlogin have the same SID. For cases where the SID history was not maintained, you will receive an error about the SID not matching, and you will need to supply this input.

The validation is helpful in preventing incorrect account migrations where there are two users with the same username. This happens frequently with common names like Smith, Johnson, or Garcia.

The command needs to be run for each user you need to migrate. This can be done user by user, or in large batches. However you run it, make sure that you have access to the results so that you can review and correct the exceptions.

TechNet Documentation for STSADM –o MigrateUser: http://technet.microsoft.com/en-us/library/cc262141.aspx

Post-Migration Validation
After the services are moved, standard test cases apply. Make sure that the main site collections load, user permissions are maintained, and that search queries return accurate results.

If you run MOSS you will want to setup the profile import to the new domain. This will ensure that updates are pulled in over time.

You can use the profile lookup form in the Shared Service Provider to search for profiles on the old server. Use a Wildcard “*” after the domain name to pull back all users for a given domain.

If you want to look at the site collections and see how many accounts are on the old domain user can query the Content Databases. You will need to run the query against each Content DB.

Disclaimer: Accessing production databases even just to query may not be a good idea. Do this at your own risk.

select distinct tp_login, tp_email, tp_title
from {ContentDBName}.dbo.userinfo
where tp_login like ‘{Old Domain}%’ order by tp_login

%d bloggers like this: