Nienkamper
asked on
Multiple NetBIOS Names for a Server when using Persistent Drive Mappings
I know what I am going to ask is gonna seem a little silly, but before you ask yourself "Why is he doing that?", know that this is just a temporary fix.
We have 2 Windows 2003 SP2 boxes, 1 is to be decommissioned (box A), the other is our new storage server (box B).
We have a bunch of users connecting to box A right now using local drive mappings (persistent). The data they are connecting to needs to be moved to box B ASAP as box A has to go back to Dell. The plan is create login scripts and have all users connect to box B after we have taken the time to create a new directory structure for departmental drives, setup group policies, etc.
But for the mean time, we just want to get the data off box A. The idea is to move the data tonight after hours, decommission box A and then create a second NetBIOS name for box B, using box A's old name. This way we don't have to change the drive mappings until later, and can do it all by script.
We found this Microsoft KB article:
http://support.microsoft.com/kb/829885
This is the closest we got to accomplishing what we need to do in a pinch. However, it says it won't work for persistent drive mappings. If we were doing it all by script, it wouldn't be an issue to begin with....
Does anyone have any ideas on how to make this work? With or without DFS?
We have 2 Windows 2003 SP2 boxes, 1 is to be decommissioned (box A), the other is our new storage server (box B).
We have a bunch of users connecting to box A right now using local drive mappings (persistent). The data they are connecting to needs to be moved to box B ASAP as box A has to go back to Dell. The plan is create login scripts and have all users connect to box B after we have taken the time to create a new directory structure for departmental drives, setup group policies, etc.
But for the mean time, we just want to get the data off box A. The idea is to move the data tonight after hours, decommission box A and then create a second NetBIOS name for box B, using box A's old name. This way we don't have to change the drive mappings until later, and can do it all by script.
We found this Microsoft KB article:
http://support.microsoft.com/kb/829885
This is the closest we got to accomplishing what we need to do in a pinch. However, it says it won't work for persistent drive mappings. If we were doing it all by script, it wouldn't be an issue to begin with....
Does anyone have any ideas on how to make this work? With or without DFS?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
oBdA: Already implemented that registry fix. my apologies, should have mentioned that already. Here is what i did: I used our new storage server (box B), and one of our development servers (box C). I created a CNAME for box B (\\storagetest). It works fine after the reg fix. Then I mapped a drive (persistent) on my machine to that CNAME using a test share (\\storagetest\test) and that works. I then changed where the CNAME points to then i get the error:
Microsoft Windows Network: The local device name is already in use.
Am i going about this the wrong way? Should it be with A records instead of CNAMEs?
LauraEHunterMVP: Yes, we figured it would be useful in the future anyways, so we did plan to deploy it. But in the mean time....we are left with the Microsoft KB article telling us that it won't work with persistent drive mappings, which is kind of useless. Have you had any luck getting it to work that way?
Microsoft Windows Network: The local device name is already in use.
Am i going about this the wrong way? Should it be with A records instead of CNAMEs?
LauraEHunterMVP: Yes, we figured it would be useful in the future anyways, so we did plan to deploy it. But in the mean time....we are left with the Microsoft KB article telling us that it won't work with persistent drive mappings, which is kind of useless. Have you had any luck getting it to work that way?
I have never had luck in that regard, unfortunately, I wish I had better news for you. NetBIOS name resolution doesn't truly understand the notion of a CNAME, so any hack to that effect is a bit of a hit-or-miss thing.
Potentially silly question, and I apologize if you explained this in your original post and I missed it: if the plan is to do a hard cut-over, where you migrate the data off of BoxA onto BoxB and then turn off BoxA, why not rename BoxB to BoxA after you turn off BoxA? Fix up the share names to be the same, update WINS and DNS so that the name BoxA corresponds to the new IP (heck, you could even re-IP BoxB to BoxA's old IP after you decom BoxA), everyone goes on their way until you move things forward with DFS the way you want to.
Potentially silly question, and I apologize if you explained this in your original post and I missed it: if the plan is to do a hard cut-over, where you migrate the data off of BoxA onto BoxB and then turn off BoxA, why not rename BoxB to BoxA after you turn off BoxA? Fix up the share names to be the same, update WINS and DNS so that the name BoxA corresponds to the new IP (heck, you could even re-IP BoxB to BoxA's old IP after you decom BoxA), everyone goes on their way until you move things forward with DFS the way you want to.
ASKER
Not a silly question at all. I was debating on a rename before, however, this storage server is also our backup server. It is connected via SCSI to our autoloader. Since it has most of the data that is backed up on it, and it is on a fast connection to the autoloader (rather than over the network), we installed backup Exec on there. We are currently running version 10d. but we do have remote agents installed on several other servers for the remaining info that is backed up. I don't know how much a name change would affect things...
Plus we did start to host some shares on the new server (box B) as well. So no matter how we look at it, there would be some changes to be made...
Another Question: when a client connects via UNC, what exactly is stored on the local machine besides the UNC name, IP, etc. ie. Does it store a type of secure identifier at all?
Laura: So otherwise though, you've never made a situation like mine work with persistent connections then?
Plus we did start to host some shares on the new server (box B) as well. So no matter how we look at it, there would be some changes to be made...
Another Question: when a client connects via UNC, what exactly is stored on the local machine besides the UNC name, IP, etc. ie. Does it store a type of secure identifier at all?
Laura: So otherwise though, you've never made a situation like mine work with persistent connections then?
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Thanks for the answer to that Laura as it was a little off topic. I will definitely award partial points for your help. But i would like to hold out for a bit longer to see if anyone else has found a workaround for my particular scenario.....just in case.
No worries at all, I wish that I had an actual solution to offer you for the problem at hand.
What client OSs are you running?
ASKER
All XP SP2
Do you have the possibility to run a user logon script that would check for persistent connections, delete them, and reestablish them with the same name (then again, at this point, the server name could also be swapped)?
ASKER
I am not that great with scripting, so i'm not exactly sure how to go about doing that.
However, it may not matter at this point. Although I had said I already tried using Microsoft KB81308, it would appear as though I messed up. My colleague happened to catch it actually.....i placed the registry key on in the lanman folder, instead of the parameters folder by accident. I did this reg fix on 2 servers to test with: one as the original, one as the destination server. I messed up the registry key on the destination server.
So when i did a simulated environment, and used a CNAME to point a workstation to the "new" destination server, it didnt work. But after fixing the registry entry everything seems to be working. We did multiple tests and it seems to not know that the mapped drive is pointing to a different server from a workstation.
We are about to do this in our production environment by moving the data from server to server. I will let you know how it goes on Monday when users try to access the shares. I'll then award points accordingly.
Thanks,
Ryan
However, it may not matter at this point. Although I had said I already tried using Microsoft KB81308, it would appear as though I messed up. My colleague happened to catch it actually.....i placed the registry key on in the lanman folder, instead of the parameters folder by accident. I did this reg fix on 2 servers to test with: one as the original, one as the destination server. I messed up the registry key on the destination server.
So when i did a simulated environment, and used a CNAME to point a workstation to the "new" destination server, it didnt work. But after fixing the registry entry everything seems to be working. We did multiple tests and it seems to not know that the mapped drive is pointing to a different server from a workstation.
We are about to do this in our production environment by moving the data from server to server. I will let you know how it goes on Monday when users try to access the shares. I'll then award points accordingly.
Thanks,
Ryan
ASKER
just to fully clarify on this, oDbA: as mentioned, the link you gave was one that i had already found, but gave u the points as this proved to be the only way to make this work.
the only prob was, this type of modification wasn't 100% reliable. did have to go around and remap some client machines manually.....
but all in all, it did the trick to get us by.
the only prob was, this type of modification wasn't 100% reliable. did have to go around and remap some client machines manually.....
but all in all, it did the trick to get us by.
Might not be specifically useful for your current predicament, but you should consider deploying DFS for the replacement server for when (not if) the issue comes up again.