Mass remap of drives to new server share

[cjolley]

We have a bunch of users (about 50) who have drive mappings, not all the same, to folders on a share on server1.
We have a new file server, server2, we want to re-map their drives to.
The problem is that there are a lot of shared documents, spreadsheets passed around etc, and scanning going on all the time. So going through the office from user to user re-mapping drives while people are working is pretty much out of the question.

Come to think of it, it's not just mapped drives, there are shortcuts too. sigh...

Would a regedit search and replace "\\server1\share" with "\\server2\share" work?
That would be off hours and then turn off the share on server1 to catch anything that got missed.

Is there a better way of doing this?

[Jammrock]

If server1 is going offline you can create a static DNS entry for server1 to server2's IP address. As long as the share name is the same all of the traffic will route over to the new server no problem. Assuming permissions and whatnot are all setup correctly. That's the easiest way.

Though you may have to disable strict name checking.

http://support.microsoft.com/kb/281308/en-us

If server1 needs to stay online it gets tricky. If you can, rename the server, then do the DNS trick.

Though you're best option is to take the time to move everyone to a domain DFS share if you are using a MS AD domain. It's a pain now, but future changes will be a breeze. Just update the UNC path in DFS and you're done.

[cjolley]

Thanks
Unfortunately server1 has a BUNCH of shares used by different departments on it, so we can only turn off or rename our share on it.
I don't think our AD system is functionally complete.
But I will get with the organization wide network guys with your suggestions.

Also, server1 is, I think, win2k server (gulp) and server2 is win2008 server if that makes any difference.
I copy the new/changed files from share1 to share2 (they actually have the same name) pretty regularly and work on making sure the permissions are correct on the new copy. The permissions thing seems to be WAY more troublesome than it should be.
The new share is also already on our backup schedule.
That way the new share will be ready as soon I figure out a viable switchover plan.

Chuck

[Dilitante1]

umm

Is DFS an option?

or logon scripts to create new mappings......

where you copied the data over already, then you can remap shares at logon, and instruct how to edit the shortcuts.... then no desktop visits

[UtwigMU]

You can do it with a log-on script the way it is usually done.

Create a log-on script, save it in netlogon share on domain controller as bat file:

net use j: /delete
net use j: \\server2\shares


Then in User properties add log-on script.

If you have a lot of users use group policy:

1. Click Start, point to Administrative Tools, and select Active Directory Users and Computers.
2. Right click your domain and select Properties.
3. Select Open from the Group Policy tab.
4. Double click the Default Domain Policy.
5. Right click the Default Domain Policy and select Edit.
6. Expand User Configuration | Windows Settings | Scripts (Logon/Logoff).
7. Double click Logon.
8. Click the Add button.
9. Type in the name of the script and Click OK.
10. Click OK.


This is a good time to standardize mappings with logon scripts. At one small place I manage as my side-business, I have 4 groups each with different log-on script (finance group gets finance share mapped, other groups do not). Also use high drive letters for shares as on new desktops you get integrated card readers, which go all the way to K: If a share is mapped to K: and K: is already used by SD reader it will not map and users will come to you with pitchfork and torches because they "no longer have access" to K:

You should also divide your users in as few as possible groups (finance, design, engineering...), create shares, then set appropriate NTFS and share permissions (you can add domain users to NTFS and just do share permissions per group to simplify management). I suggest you copy data over to new server over night. then next day sort it out, simplify shares, set permissions, write log-on scripts. After everyone goes home sync changed files to new server (use total commander with compare folders). Then assign logonscripts to groups, make log-on scripts delete all possible old drive letters and assign new shares. Next day when everyone logs in they will get new shares mapped, it will be slightly different and more organized and users will slowly realize the benefits. Write an email with picture step by step instructions on renaming shortcuts and visit those with problems.

[cjolley]

...and instruct how to edit the shortcuts.... then no desktop visits

Don't say things like that in the morning.
I laughed so hard I almost snorted coffee out of my nose and on to my keyboard.

I'm still pondering the suggestions.
Thanks guys.

[Jammrock]

If your domain is 2003 SP2/R2 or greater then it doesn't matter where the DFS shares are. To AD it's just a UNC path, the OS is irrelevant. You can have DFS shares on Linux or a NAS and it won't matter, as long as it's an SMB compatible UNC share.

Since a DNS change isn't an option I vote with the logon script option. If the shortcuts point to J:\Sales\Porn, or whatever, remapping the drive to server2 at logon will work even for shotcuts. If shortcuts point to \\server1\sales\porn you'll just have to put up with pissed off clients who don't read emails from IT until all the drives are manually fixed.

Though I would still use DFS to make future changes smoother. With DFS you point to the domain share, not a specific server, and the domain share takes you to the right spot. When that spot changes it is transparent to the client because they still access the same domain share no matter what server is actually used.

[cjolley]

... you'll just have to put up with pissed off clients who don't read emails from IT until all the drives are manually fixed.
...

Luckily, no one will get pissed off. I work with the nicest group of people you can imagine. Not a grump in the bunch. Very unusual.

OTOH They read the emails, they just don't understand them.

Typical conversation:
USER: ALL MY DOCUMENTS ARE GONE FOREVER! I MUST HAVE DELETED THEM BY MISTAKE!

ME: Tell me exactly what happened.

USER: I WAS WORKING ON THIS FORM AND WHEN I SAVED IT ALL MY OTHER FORMS DISAPPEARED!

ME: Show me.

USER: clicks the open menu and there is a folder containing only the one form
of course there is also a folder next to it called "My Forms"

I drag the new form over to the "My Forms" folder and open that folder.
And there everything is
They treat it like an amazing magic trick!

Mind you, these are people who can understand the ins and outs of Oklahoma's byzantine property tax law.

Add to this the fact that I am a programmer, all this support stuff is just side work for me.
So I never quite get used to it.

[UtwigMU]

So, how did the remap go?

[cjolley]

So, how did the remap go?

Did? Lol

Got distracted by other projects.
The new server is still a great big backup to disk device

[MultimediaMan]

I'm surprised I missed this one.

I had to do something similar at a remote site without the benefit of AD.

It was done in several stages... about three weeks apart.

Stage 1)
a. I migrated the files to the new server using Robocopy (preserving permissions and ownership) after-hours
b. I ran the Robocopy to update only on a file delta for about three weeks.
c. The job was a scheduled task on the new server.

Stage 2)
a. Sent an email warning users about a nightly logoff.
b. I created a package to create local scheduled task on the workstations to log off the local console user.
c. The script had a "kill me" date built into it (deleting the scheduled task).

Stage 3)
a. Ran one final re-sync in Stage one, and deleted the scheduled task on the new server. The shares were stopped on the old server prevent users from going back to the old server.
b. I deployed a substitution/migration package:
c: Logged off the console user, and rebooted the system (to release any locked registries)
d: Auto-logged in as admin.
e: Locked the Desktop (to prevent users from logging-in).
f: Ran a recursive search of the registry hives for the mappings for each user.
g. Noted the drive letter and the share path
h. Verified the old drive mapping was on the list for migration.
i. Backed up drive mapping registry keys for each user instance encountered.
j. If the mapping was on the list, the drive mapping was changed from old to new.
k. Checked all local profile desktops for shortcuts drive to letter mappings in *.lnk files
l. Replaced all local profile desktop shortcuts for drive letter mappings (if found previously)
m. Logged results locally and to a remote server.
n. Dynamically built a backout script based on all logging above.
o. Deleted the logoff script in Stage 2.
p. Removed Autologin
q. Logged-off the system.
r. Emailed all users the migration was done.

I didn't receive a single call on the initial parts of the migration. When this stage of the migration was done, we were able to decommission the old server very quickly.

[cjolley]

Well, I have the first part covered. It copies the diffs just after close of business every day using RichCopy.

What is step 2 for?

And I wish I knew how to do step 3.