I’ve posted similar information before, but my colleague Lakshmana Rao (Laksh) has come up with a great document on the steps required when you want to move Project Server 2007 between domains. As Laksh points out at the end – please make sure you test this process in a non-production environment first – Hyper-V is perfect for these kind of tests. On with the document…
How to Move Project Server 2007 from one domain to another:
Considerations in this Article:
1. In this setup, the Project Server 2007 Farm has two servers (One Project Server 2007 SP2 Server box and one SQL Server 2005 SP3 Server box.) For multiple servers set up, please see the Note at the end of this article.
2. Current domain name is APAC and new domain name is NORTHAMERICA.
3. In the current set up, user account used for installing Project Server 2007 and as service account where ever is required is APAC\PsvrSrvcAcct
Prior to changing the Servers to the New Domain:
1. In the new domain, ensure that you have same account IDs and names as that of the domain account IDs and names in Project Server and the service accounts used for Project Server 2007.
Otherwise, after migration; we experience issues with user mappings and unknown issues related to resource assignments/ work/Actual work etc.
2. Take Full Farm back up from SharePoint Central Admin, Operations, Perform a back up. (For more details ,please refer to “Back up and restore the Project Server 2007 farm” at http://technet.microsoft.com/en-us/library/dd207295.aspx
3. Create a user in PWA using the Local Administrator ID or any local User and add to Project Server Administrators group.
For example, if Application Server host name is PSVRPROD, create a user (PSVRPROD\Administrator) in PWA, Server Settings, Manage Users, New User and assign to Administrator group. (After domain migration, we use this account to login to PWA and perform administrative tasks).
4. Stop the WWW service in Project Server.
5. In SQL Server 2005, note the permissions of Service Accounts used on the SharePoint and Project Server databases. (Note the Server roles and User Mappings of the Service Accounts)
Steps to Move the Servers to New Domain:
Moving SQL Server 2005 box:
1. Join the SQL Server to the new domain.
2. Restart the Server.
3. Login to the server with Admin Privileges and add the respective service accounts to the Local Admin group.
In this scenario, I have added NORTHAMERICA\PsvrSrvcAcct. (Before domain change, APAC\PsvrSrvcAcct was present in Admin group.)
4. Open Services.msc and ensure that the MS SQL Server service is running. You may need to change the ‘Log on’ Account name if the service is using a domain account. Specify the correct service account and start the service.
5. Connect to the SQL Server using SQL Server Management Studio.
6. Expand the Security. Click on Logins.
7. Create Service accounts used in Project Server and provide proper permissions to the SharePoint and Project Server databases. (You need to refer to notes in step 5 in section “Prior to changing the Servers to the New Domain:” and give the same permissions ( Server roles and User mappings to the new service accounts)
In this scenario, I have created NORTHAMERICA\PsvrSrvcAcct in SQL Server and provided the same server roles and user mappings as that of APAC\ PsvrSrvcAcct
8. In MSP_RESOURCES table of Published database, change the domain name of the users.
Use the following query
SET WRES_ACCOUNT = REPLACE(LTRIM(WRES_ACCOUNT), '<Current Domain Name>', '<New Domain Name>');
In this scenario, I used,
SET WRES_ACCOUNT = REPLACE (LTRIM(WRES_ACCOUNT), 'APAC', 'NORTHAMERICA');
Moving Project Server 2007 box:
1. Join the Project Server to the new domain.
3. Login as local Administrator and add the respective service accounts to the Local Admin group.
4. Ensure that you are able to connect to SQL Server box. (You can use UDL connection test).
5. Follow the KB article, http://support.microsoft.com/kb/934838 and change the farm service accounts and passwords.
6. Ensure that the Project Server Queue, Event, SharePoint Timer services are using the new domain service account. These should have been set by the actions in step 5 so should not need changing manually (worth noting just in case they didn't do step 5 right and think manually changing will put things right),
7. Open IIS Manager and ensure that all the service accounts are changed to the new domain service accounts. If not change them and restart the IIS.
8. Login to SharePoint Central Admin site.
9. Click on Operations, Service Accounts.
10. Select Web Application pool. For Web Service, select “Windows SharePoint Services Web Application”.
11. For each Web Application pool, verify whether the user name is correct. If not update them and restart IIS.
In this scenario, I have checked whether it is NORTHAMERICA\PsvrSrvcAcct.
(Steps 8 -11 are to make sure that the SharePoint reflects the changes)
12. Log in to PWA using local Administrator ID ( created in step 3 of section “Prior to changing the Servers to the New Domain:” )
13. To initiate “User Synchronization for Project Web Access App Root Site and Project WSS Workspaces”, create a new Category (say “TestSync”) from on Server Settings, Manage Groups add users to this group ( do not add the currently logged in user ) and click save. Again, revert back the changes. Delete the newly created category.
14. Once, “User Synchronization for Project Web Access App Root Site and Project WSS Workspaces” is succeeded, synchronize the Project Workspaces from Server Settings, Project Workspaces.
15. Test the server by publishing a new project and existing project as well.
16. Ask users to access the PWA and Project workspaces and test.
Note: If that farm has multiple Application Servers and WFEs, you have to detach all the servers from the farm, except the server that host Central Admin site. Follow the above steps. The, move other servers to new domain and then connect to the farm one after another.
You can also use PSI functions “SynchronizeMembershipForPwaAppRootSite ()” to update PWA WSS Root Site information and “QueueSynchronizeMembershipForWssSite “to update each WSS Workspace. This requires writing a custom code.
As with any major changes, please test in your own environment to ensure these steps work for you before moving a production system.
Thanks again Laksh!
Export All deployed sollution. (when you restore full backkup sollutions will not be restored ). And deploy them on restored server.
Install at least SP2 and check out if you are able restore backup on another server.(there is 50% chance that you will not be able restore backup on server with infrastrucure update)
Don't synchropnize membership,(WSS do not support SID history) sou you have to change user SID & LOGIN in all content databases.
I am preparing to undergo a migration of a customer's
In step 8 of the "Moving SQL Server 2005 box" section, you provided a sql query to update resource table. Since Microsoft does not allow manual SQL update queries to any MOSS databases, is this migration process supported by Microsoft?
Yes, this would be supported. The only other option would be to use the local administrator account and then manually go in to manage Users and update each user. This is one of the few occasions when direct database interaction via a query makes sense and is supported.
I need to extract the project schedules and project workspaces content from one server on one domain and use it to refresh a server of same config, but on our QA domain.
Do you know where I could find info on how to do this pelase?
I thought the article you had commented on did just that - or am I missing something? Perhaps the 'refresh' word means you don't want to move everyting but just the changes? You could export the sites, and save mpp files and import to the QA domain - but assuming the QA domain is just for testing taking everything might be best.
I made a migration of moss 2007 and project server 2007 to another domain on the same server. Everythins works fine but when the users go to the "MY TASKS" on the PWA home page, the project server send me a error...Unexpected Error, go to the webpart maitence page...blabla...
I have tried remove the web part e put again, but no success. In the Event Log show me that de error occor in the procedure a função MSP_WEB_SP_QRY_Statusing_ReadStatus, something like "much more arguments....". So I went to the procedure in DataBase but is much difficult to debug what is happening.
Did you know, one approach to fallow....one suggest...iam troubble!
Thanks at all!
Does this procedure also cover the migration of accounts? (in my projected scenario we would be moving a fully loaded project server from one domain to another across a trust).
Users would also have migrated domain accounts that would hopefully sync back up with task assignments and project-related data.
Is this the case?
Hello Brain, recently, i asked the consultant to migrate the MicroSoft EPM between domains, they asked for 14 days downtime, which i cannot accept such long time to migrate project, workspase, resource and reconfigue the permission. We have about 400 projects and 700 ID account on the application. Do we really need so much time?
Waiting for your reply. Thank you.
Recently, I asked the consultants to migrate the EPM 2007 between Domains. They asked for at least 14 days downtime which is i cannot accept, to migrate all the project, workspace, resource and recnfigue the permission. Do you think it is really need such long time? We have about 400 projects and 700 accounts on that Application. As consultant said, 2007 doesn't support backup and restore, so they have to export and import manually one by one. and meanwhile they have to reconfigure the permission in new domain which is mosty time costly. Do you have some advice to speed up this operation to minimum the migration time and downtime? I appriate your reply. thank you.
Hi Stephen, it can be a slow process but wouldn't think 14 days downtime would be necessary - but this very much depends on what other constraints you have in place in terms of extra hardware for testing before the go-live migration. The steps outlined above are a good way to migrate and do include some backup and restore steps and avoid individual export/import. Worth asking your consultant why these steps would not work for you.
in the procedure you mentions that domain account IDs and names need to be the same between old and new domain. The account ID, is it referring to login (olddomain\jeff) or is referring to an AD related SID or GUID?
Hi JF - only the piece after the DOMAIN\ and the display name need be the same - So I could move Domain1\BriSmith - Brian Smith - to Domain2\BriSmith - Brian Smith. In reality there may even be some flexibility here - but to make things straightforward and avoid conflicts this is a good way to plan it.
If i have project server and SQL server on the same VM the steps will be the same?
After move servers to new domain it's work.I'm run sharepoint configuration wizard after that not work.