It is important to understand that migrating the data and moving the users is broken down into three major steps:
1) Move the data initially, verify security rights moved over, test applications moved the new drive letter.
2) The night of cutover, perform a delta move. This means moving just the files that have changed or have been created on old production side. Beyond Compare is excellent for this (and many other things)
3) Change drive mappings (logon scripts) and remove the old shares. I insist on removing old shares so that users can’t get to the old data. You never ever want to find yourself with most users migrated, but some users still updating info on the old server.
In this lesson, we identify the logon scripts used by the end users, and change the drive mappings from the old server share to the new server share.
Some logon scripts are assigned on the user account. This is the old NT 4.0 way before group policy existed, and is seen on the Profile Tab of the user.
If the path is not specified, like in the above example, it implies the NETLOGON share on any domain controller. This entry is typically populated with a batch file (.bat)
To provide more flexibility, you can use group policy to assign logon scripts to users. In fact, you can assign logout scripts too, but it seems rare to be used. Group policy also allows you to assign “logon” scripts to computer ojbects. These are called Startup and Shutdown scripts, and as you probably guessed, they run on startup of the workstation before anyone logs on, and when the workstation shuts down.
This is where you should use the Group Policy Management utility to browse group policy objects and look for scripts that might be assigned. I have found that most people (admins) drop the scripts in the NETLOGON share and point to them in group policy.
The one thing nice about group policy is that it supports .vbs, .exe, and a wide range of other extensions.
For this client example, looking inside the default small business server logon script (SBS_LOGIN_SCRIPT.bat) reveals the following code:
Interesting… in this case, the batch file runs a vb script.
Take note here that the unc path does not reference server but instead uses the active directory domain name. That way the client uses the current domain controller that it’s authenticating off of, not a specific one.
Inside the logon.vbs file we see this snipit of code:
DriveMapper "H:","\\s1\home\" & fuser
It should be obvious that you change the “s1” from the old server’s name to the new server’s name. This is not the place to endulge in all the ways to map drives, and make logon scripts. We can cover that in another lesson.
The BIGGEST problem you are going to run into is PERSISTANT Drive mappings. A persistant drive mapping is one that is tied to the profile, when you map a drive and check the “Reconnect at logon” using explorer as seen here:
If the logon script was just a batch file that used the command: net use k: \\server\share, the user would get a popup saying something to the effect “Do you want to map to the new server, you have this drive mapped to the old server”. Most people say no to such changes, but that would be incorrect. Now the users is screwed, the old shares are removed, but the user said “no” to re-mapping the drive letters, so now the user has no drive mappings. Uggg..
If you modify the batch file and perform a net use k: /delete for each drive letter, then the user won’t get questions like that. Again, this problem only exists when users have persistent drive mappings.