Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I'm currently having a hell of a time with what seems like it should be a fairly simple project.

Basically, $employer has a bunch of remote sites with ancient hardware impersonating real servers, and they're replacing them with real servers. Or, more accurately, they're buying new servers and having me do the work of replacing them. The sites are generally small, so nothing too complex - we're basically just providing a file server, print services, and a Domain Controller/DHCP server for all the sites.

The problem, of course, comes from doing user profile redirection. All our users have their My Documents directory redirected to the fileserver, for example to: \\[crappy-old-server]\users\%username%. Since we're trying to do things right, we're setting up DFS on the new servers and changing that to: \\[not-crappy-DFS-root]\[sitename]\users\%username%.

That part's working pretty well, and after migrating the file server with the Microsoft file server migration toolkit, we run csccmd to point the share on the client machines to the new location, change some things in Active Directory and Group Policy (mapped drives, printers, etc.) and call it a day.

The problem, however, is that while the csccmd tool moves some of the registry references to the old server, the client registry is still lousy with the bad links (MRUs, Bit Bucket Recycler path, printers, application defaults, mount points, Shell folders, Net Cache, etc.) and as a result, the users can't even open up the start menu without getting network timeouts because some setting is looking for something at \\[crappy-old-server]\users\%username% instead of \\[not-crappy-DFS-root]\[sitename]\users\%username%. It literally takes at least 30 seconds to do almost anything, which is not acceptable.

To resolve this, I've been manually, at each client machine, opening regedit, searching on the old server string, and when found, either deleting the key or replacing the old server name with the new DFS path. This, obviously, sucks, and I'm thinking there simply has to be a better way, because my current solution just doesn't scale at all, and larger user migrations must have used a more automated approach to this problem.

So, what's the better way to do this that doesn't involve manually searching client registries?

share|improve this question
add comment

1 Answer

up vote 3 down vote accepted

You could put up a machine in each site that answers for \\[crappy-old-server]\users as a standalone DFS root with users being a DFS link to the new \\[not-crappy-DFS-root]\[sitename]\users folder. You may be able to use the server you're deploying in each site using OptionalNames, assuming that you don't already have a share named users.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.