Category: Top Posts

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.

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: