DFS Migration 2003 to 2008 R2

Helping out a client with a medium data migration this weekend and running into issues with DFS from their file server.

Server 'DATA04' was Server 2003, hosting all network drives at DFS Namespace '\\client.ads\shares' (domain in the format 'client.ads'
Using Robocopy all user data was copied to external (keeping all NTFS Permissions intact)
Wiped server 'DATA04'
Reorganized disks
Installed Server 2008 R2
Installed File Services Role with DFS (Namespace & Replication)
Robocopied data back
Removed the existing DFS Root from AD as per http://support2.microsoft.com/?id=224384 
Have setup the same Namespace on 2008 DFS Namespace on the newly built DATA04 server - which worked
Setup first Target, exactly the same as the Target on 2003 server

When testing this target (which is the 'userdata' share (which hosts all users redirected Desktops & My Documents) user computers are getting:
"[Window Title]
Open Folder
\\clientads\shares\udata\mark.galvin\V2\Desktop refers to a location that is unavailable. It could be on a hard drive on this computer, or on a network. Check to make sure that the disk is properly inserted, or that you are connected to the Internet or your network, and then try again. If it still cannot be located, the information might have been moved to a different location.

This seems to indicate that the system is trying to access "\\clientads\shares" and not "\\client.ads\shares"

I have checked their Drive Maps in GPO and they are all setup with "\\clientads\shares".

Any idea folks?
Need an answer before end of the day today!

LVL 13
Mark GalvinManaging Director / Principal ConsultantAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

I am trying to understand the original situation. There was a server called DATA04. Was it also a domain controller? Are there any other domain controllers? What is the NETBIOS name of the domain, and what is the DNS name of the domain?

From what it sounds from what you have previously described that maybe the NETBIOS name of the domain is/was clientads. When you recreated the DFS namespace, did you do it as a standalone namespace or a domain namespace? It should have been a domain based namespace. All of my domain based namespaces are served by domain controllers, though my understanding is that domain members can host them too. If you setup the domain based namespace called shares on one or more domain controller, and then create a folder target under shares called udata and point that to a share on DATA04, you should be able to get things to go.

So, if you had a domain controller called DC01 create the DFS namespace called shares. You would then have \\DC01\shares AND \\domainname\shares AND \\domainname.suffix\shares.

Create a folder target under \shares called udata and point that to \\data04\udata. You would then have \\dc01\shares\udata which would take you to \\data04\udata, and presumably \\data04\udata\mak.galvin would be available. Since \\dc01 and \\domain are both available from the domain controller, the entire path of \\domain\shares\udata\mark.galvin should work.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Totally agree with above comment

It seems that your domain NetBIOS name is clientads and not only "client", this is changed from default to custom during domain deployment.
Your earlier name space must be created on domain controller
Other wise it would not possible to get path like clientads\path
In new environment, when you run \\client.ads, it should show you "shares" dfs name space as well, then only it can resolve \\clientads\Shares, for that you need to install name space on DC servers
Also it is required to add this DFS name space on every DC server, otherwise some times it will create resolution issue, because \\clientads points to any random DC server in that AD site and if DFS name space is not installed on that DC, probably you will run in issues
Mark GalvinManaging Director / Principal ConsultantAuthor Commented:
Hi both

This is a client domain which I have inherited as a client so was not involved in the setup of domain.

Sounds like you are both correct. DATA04 was not a DC. Interestingly, when I tried to add the DFS Namespace to the rebuilt DATA04 it could see the Domain DFS Namespace from before and added it but when trying to expand it the error “The namespace cannot be queried. Element not found” appeared.

To work around the issue (and given time constraints) I deleted the DFS root from AD and recreated as domain namespace and recreated all the folders in there. Then went through all the GPOs that referenced “\\clientads” and updated to \\client.ads which has done the trick. Now we can see the DFS Namespace on other, non dc, based storage servers.

If you have multiple DCs hosting the namespace in the future this should be a non-issue as the namespace will survive the loss of any server. Actually, you probably could have just added a different server to be the namespace server and it would have been okay, since the namespace configuration is stored in AD. Glad you got it all working.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Windows Server 2008

From novice to tech pro — start learning today.