Bill Baer

Senior Product Marketing Manager (SharePoint), Microsoft Certified Master for SharePoint, Microsoft Corporation

Renaming a Resource Forest on SharePoint Servers

Renaming a Resource Forest on SharePoint Servers

  • Comments 3
  • Likes

* I haven't revisted this post in awhile and thought I would include some additional information on the topic; in response to dkbobe's questions surrounding updating the user information; you can use the SPUserUtility to update the tp_Login column to reflect the new domain - more information on this tool can be found at Keith Richie's blog @ http://blogs.msdn.com/krichie.

I was pleased to see my mention in Joel Oleson's SharePoint Blog on the Impacts of Renaming a Resource Forest on SharePoint Servers; I'm hoping to elaborate more here as there is little documentation on this topic; at least from the perspective of impacts to SharePoint services.  The good news is that SharePoint services can be recovered after renaming the resource forest without a great deal of configuration management and member server preperation.  One item to note, do NOT run rendom /clean on the SharePoint servers; otherwise, as opposed to only having to reboot the members twice to learn the domain name changes you will be required to disjoin the server from its current forest and rejoin the new forest.  Rebooting twice ensures that each member computer learns of the domain name changes (LSA policy changes) and propagates them to all applications and services running on the member computer. Note that each computer must be restarted by logging into the computer and using the Shutdown/Restart administrative option. Computers must not be restarted by turning off the machine power and then turning it back on, as a result of this you may experience the same behavior as have you run the rendom /clean tool.  As far as the recovery aspect is concerned; recover the servers in the order of (assuming a typical topology), active Microsoft SQL Server node, passive SQL Server node, primary SharePoint Portal Server Web/Search server, SharePoint Portal Server Index server, secondary SharePoint Portal Server Web/Search server.  This will ensure the most rapid restoration of services.  As a prerequisite it is recommended that you collect each member servers IP address and local Administrator credentials in the event the machine is renamed or their are issues impacting name resolution that may prevent access by name.  Assuming the machines have successfully learned of the domain name changes; you will need to reestablish the password used for the service, appication pool, and access accounts for the following service, appication pool, and access accounts  in this order:

  1. Active SQL Server Node:  Cluster Service, SQL Server Agent and MSSQLServer
  2. Passive SQL Server Node:  SQL Server Agent and MSSQLServer
  3. Primary Front-End Web Server:  MSSharePointPortalAppPool and CentralAdminAppPool (NOTE IISRESET when complete)
  4. Primary Front-End Web Server:  SharePoint Timer, SharePoint Portal Administration, Microsoft SharePointPS Search, and SharePoint Portal Alert services
  5. Primary Front-End Web Server:  Configuration Database Administration Account, Default Content Access Account, and SharePoint Central Administration Account (NOTE IISRESET when complete)
  6. Repeat steps 3-5 on the Index/Job Server
  7. Repeat steps 3-5 on the Secondary Front-End Web Server
Comments
  • I believe permissions per url are stored in SQL DB portal_site.dbo.userdata and post rename will leave the permissions with the old domain name.

    Do you know of any steps needed to rename theses permissions?

    Many Thanks

    Bob E

  • "I believe permissions per url are stored in SQL DB portal_site.dbo.userdata and post rename will leave the permissions with the old domain name.

    Do you know of any steps needed to rename theses permissions? "

    The per site permissions should resolve under the domain rename; otherwise SQL sp's can be leveraged to locate and repair instances where the previous domain name remains.

  • In response to Bob E's question, you can use the spuser utility in the SharePoint Utility Suite to ensure that the tp_Login columns are updated for all users.  A back-end solution is unsupported.

    dkbobe said:
    I believe permissions per url are stored in SQL DB portal_site.dbo.userdata and post rename will leave the permissions with the old domain name.

    Do you know of any steps needed to rename theses permissions?

    Many Thanks

    Bob E

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment