"What's In a Name?"

The recent turmoil in the financial industry has got me to thinking. (And no, this isn't an article about the finance industry, or the turmoil.) What happens when something really foundational changes? How will you adapt your SharePoint environment to the new situation? How can you adapt it to the new situation?

When you are planning and configuring a SharePoint Server farm, you often take certain things for granted, or at least, have certain things pre-ordained. For example, most companies have standards in place for things like machine names and service accounts, and especially for the domain the servers live in. You follow your standards, configure your SharePoint portal with a site URL that users will know it by, and go on your way.

Well, things change. Companies merge, divisions re-align, and suddenly, you may find that your company, WidgetCo, now belongs to GizmoCorp. Reality dictates that you won't be asked to bring things into compliance overnight; however, you will eventually have to integrate your SharePoint sites with the GizmoCorp way of life.

Fortunately, most of the changes you might be expected to make can be accomplished with minimal disruption. Others will take a bit more effort. Here are the things likely to be impacted, and the probable order in which they will probably need to be addressed.

1. Branding
2. URLs
3. User Accounts
4. Windows Domain
5. Server Names

Of course, this assumes that GizmoCorp likes the WidgetCo intranet and Internet presence well enough to want to keep them. You of course have made this a foregone conclusion by making them indispensable resources to your users and clients... :)

Branding

Most acquiring or reorganized companies want to stamp their new identity on things right away. In the beginning, it might just be adding "a GizmoCorp company" to the banner, but eventually they are going to want things to match the marketing department's standards. Fortunately, if you have followed best-practices in designing your site, re-branding SharePoint while leaving the content intact is pretty easy, and very well documented. You shouldn't have any problem here.

URLs

This is almost a subset of branding. If you've rebranded WidgetWize to GizmoZone, having your users type http://widgetwize to get there isn't going to earn you any points with the management. Again, SharePoint's native functionality comes to the rescue. You can easily make your site respond to any name you like with "Alternate Access Mappings". Or any set of names.

That last is important. Even once you have changed your site's primary URL to http://gizmozone, you will probably find that people have created lots of "hard coded" links to pages in http://widgetwize. To just change the name without leaving the old URL would break all of those links. At some point after the conversion, you will want to search for pages that still have links to http://widgetwize and have them updated to the new namespace - or better yet, make them root-relative (i.e. start with just a slash "/", rather than the site name.)

Don't forget, you need to have your internal DNS configured to direct all appropriate site names to your SharePoint Web front end server's (or load balancer's) IP.

Long-term Maintenance Tip: Whenever possible, advise your users to make manual links within a site relative to the current page, or the site root, rather than using the full absolute URL.

User Accounts

Once the information is flowing between the "old" and the "new" organizations, a tighter integration of user management is likely. The networks will be connected, and "Trusts" will be established between the companies' domains. But that's just the first step. Eventually, there will probably be an account consolidation into a single domain. Unfortunately, all of your users will have their permissions assigned in SharePoint via their original accounts. Once they get moved onto their new account, how will they access their SharePoint content?

You need to make sure that, as part of the domain migration process, you take SharePoint into account. SharePoint has an API that allows you to rename a user's account, and have all of their permissions remain intact under the new name. You can access it through custom code, or via an STSADM operation. operation is called "migrateuser", and has the following form:

stsadm.exe -o migrateuser
           -oldlogin <DOMAIN\name>
           -newlogin <DOMAIN\name>
           [-ignoresidhistory]

This command ONLY changes the windows user account associated with the SharePoint account. It does not change any of the metadata or profile information associated with the user. If that also is changed as part of the domain move, you will need to do a crawl of AD to retrieve the updates (for MOSS).

Service Accounts and Windows Domain

Once your users are moved, or possibly even before, you will probably be asked to move the SharePoint farm into the new domain. This is where things get a little complicated. Not because it is hard, but because it is tedious. There are (potentially) lots of accounts used by the various SharePoint services. If you do things in the wrong order, you can potentially end up with major headache trying to straighten things out. In general, here's how you should prepare to move SharePoint into a new domain:

1. Establish a two-way trust between the old and new domains.
2. Test. Make sure users in the new domain can see SharePoint, and users in the old domain can see resources in the new one.
3. Create service accounts in the new domain with permissions to match the accounts currently used by SharePoint.
4. Assign the new accounts to their respective services in SharePoint. (SharePoint MVP, Eli Robillard, has an excellent article on that process, and cross-references a good Microsoft KB article which includes a script to automate the process...)
5. Test. Making sure everything still works. Do it after each account change in Step 4.
6. Make sure any other services on the servers also have accounts in the new domain! (This is an easy step to forget...)
7. Join the SharePoint servers to the new domain.
8. Test again.

Now, if the two-way trust is fully functional, it is possible to change the domain before you reassign the accounts, but that opens you up to a more difficult situation. That's because if the old domain's service accounts can't be reached for some reason, the whole thing comes tumbling down. On the other hand, if you are changing your accounts one a time as described, it is easy to revert to troubleshoot the problem.

Server Names

If you are lucky, you won't ever be asked to rename production application servers - of any kind, not just SharePoint. There are just way too many (sometimes surprising) things that can get messed up. Unfortunately, sometimes "rules are rules", and you must rename your SharePoint servers to comply with some policy. If the worst happens, and you must do so, there is a relatively straightforward STSADM operation that can tell SharePoint about it - "renameserver". Like migrateuser, the syntax is quite simple:

stsadm.exe -o renameserver
           -oldservername <oldServerName>
           -newservername <newServerName>

This makes the appropriate updates to the Configuration Database. You should run this command immediately before performing the actual server rename operation in Windows. Of course, nothing is that easy. While this command updates the Configuration Database, it doesn't make any other changes to your system. For example, you may have other services on the server that need to be updated, or there may be references on other machines to the old name. These are beyond the control of SharePoint.

In addition, this does not affect any links in your Start menu, or within SharePoint's content databases. If you rename the server Central Administration is hosted on, for example, you may have trouble accessing the site. Make sure you set up Alternate Access Mappings (just like setting URLs for the content sites) to the Central Administration web application (also for Shared Services, if appropriate for your environment) for both the old and new server names before you begin the rename process. In addition, you will need to manually edit the link to Central Administration within the Start menu to reflect the new URL.

Conclusion - Planning for Change

The only constant in life is change. Even the most stable company can decide to rename itself for a new generation. There are many reasons you may be asked to make fundamental changes to an existing SharePoint environment. In addition, the information you gather to prepare for an environment migration can also be used in a Disaster Recovery scenario. In a worst-case situation, you may find you have to bring your configuration back online in a new domain, or restore into an environment where your names will conflict with with existing servers.

By understanding the things that may need to change, and how these changes work, you can have a head start, and avoid the panic that can strike the unprepared.