• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 867
  • Last Modified:

SBS2003 STD. TO SBS2008STD. MIGRATION - gpupdate /force?

Hi,
we are in the process of carrying out a SBS2003 STANDARD. TO SBS2008 STANDARD.  MIGRATION. Microsoft comment on their instructions that both Source and Destination Servers must be connected to the Network and the gpupdate /force command run on each Client PC BEFORE the source Server is demoted and disconnected - if the Client PC's are connected AFTER demotion of the Source Server  can we still run the gpupdate /force command? - and what issues will we have on the Client PC's if we run this command after the Source Server has been demoted?

Basically, we have a ghost copy of the Clients Server in our offices, not currently connected to most of the Client PC's,  from which we are carrying out the migration, and need to confirm the above before we issue the Demotion commands and install the SBS2008 box into the Clients premises..

Thank You.

0
ja-notes
Asked:
ja-notes
1 Solution
 
Cliff GaliherCommented:
Several things will happen if the client machines do not have access to both the source and destination servers simultaneously. The gpupdate /force, by the way, just expedites the process, but is not actually required....leave a machine long enough,or reboot often enough, and the group policies will update without needing to be forced.
A couple of key problems I can think of just off the top of my head:
1) User's outlook profiles will still be looking for the old Exchange server. When both machines are present, Outlook connects to the old Exchange server, the old Exchange server notifies outlook of the existence of the new Exchange server, outlook automatically connects to the new Exchange server, and the Outlook profile is updated. All of this happens transparently so the user never sees an interruption.
If, however, the source server is not present then the Outlook connection will fail, will never be notified that the mailbox moved, and the outlook profile will have to be updated manually This will be unavoidable. To transparently update profiles, both servers must be present.
2) Folder redirection. This is primarily where group policies come into play. In order for folder redirection to copy data from the old server to the new (if folder redirection was set up on the old server and is being migrated), both servers must be online in order for the group policy to copy the data. Manually copying the data does not address this because the client machine will not be notified of the manual copy and will still *attempt* to connect to the source server to copy the data itself. When the source server cannot be found, an error will be reported, folder redirection will not be applied, thus the manually copied data will not be accessible.
Manually resolving this situation will also require resetting some group policies (not just a matter of running gpupdate) and will not be done through the wizards. The chance of data loss is somewhat high.
In short, the documentation was written the way it was for a reason. Attempting to do things outside of the documented process, while possible, is strongly discouraged and can be very messy unless you know exactly what *and why* a certain configuratoin and setup is done the way it is.
HTH,
-Cliff
 
0
 
ja-notesAuthor Commented:
Thanks for the help !
0

Featured Post

Get free NFR key for Veeam Availability Suite 9.5

Veeam is happy to provide a free NFR license (1 year, 2 sockets) to all certified IT Pros. The license allows for the non-production use of Veeam Availability Suite v9.5 in your home lab, without any feature limitations. It works for both VMware and Hyper-V environments

Tackle projects and never again get stuck behind a technical roadblock.
Join Now