Quick and Easy way to change all IP's for several Maped drives

[questorfla]

I know this is easy to do for anyone with decent tech savvy.  But trying to walk several people through the process over the phone (or worse by email) only ends up with me having to do a remote connect and do it for them.
It does not happen often but when it does, it is a real pain. 

We use several mapped drives on a single server which are mapped to the IP rather than the FQDN.  Mostly because everything is run on a simple workgroup.  With the people in the office, it still results in me having to do  it for them,  right click, map network drive, bring up the old route, change to the new IP, save etc..  Then repeat for about 5 mapped drives.
Then find the next person who could not follow those simple instructions

I got to wondering if there was a utility that could be programmed to simply change all occurrences of xxx.xxx.xxx in the registry under mount points to the new IP.  I'm not even sure it could be done that way.  But since Windows has the option to save the Wi-Fi connections to a flash drive and transfer them to another laptop,  I figure there must be a way to just change the IP used for drive mapping.  Nothing else changes, they have the same username, same password, same everything.  Only happens when the server has to be moved to another IP, usually due to a change in ISP bit sometimes due to reallocation of storage space.

[Ath]

Write a bat file that does the net use k: /d and net use k: \\x.y.z.n\share /persist=y for all drives.

But you should really consider to start using the server's name instead of the ip, as windows is perfectly capable of resolving that, even in a workgroup.
When replacing a server, just turn off the old server, and give the new server the same name.

[40hz]

When you say "server" I'm guessing it's a workstation running as a central share point using a Windows workgroup rather than a 'server server' such as Windows Server?

+1 with Ath. Look at the documentation for the NET USE command and write a batch file the users can just run when needed or the shares get changed. Ditto on using the server name rather than the IP address. Enter NET VIEW to see the names of the computers on your network. If the server name is there, you should be able to use it instead of the IP address.

[questorfla]

thanks.  been there and done that.  It used to work just fine too.

The problems are all in the registry and deletion of the mountpoints2 locations using fixes part of it.
This has been an issue in Windows for a long time.  If you map through use of Net Use instead of the GUI, it does not always work as it should.
Especially with Windows 8.

I have found that if I "clean house" in the registry all things go swimmingly.

But I don't want to send someone I have never even met off deleting registry entries.
These are usually employees I have to support remotely.

The Server itself isn't the issue.  The sever-name is not a problem.  The problem seems to be something in their copy of windows that insists on using the IP after the VPN connects to that IP rather than using the QDN of the server..  These systems are not "on the local network:" they are all logging in through a VPN.

Also, we have no Domain  and no AD Server.  This is a simple Workgroup setup.

[Shades]

Creating your own network topology could help you. See this link.

[questorfla]

THAT  looked interesting.  I will read the whole thing shortly.
What I was hoping for was some utility that would do automatically what I am doing manually,
like Net Use * /delete.
But that does not always work

Worse, if you run as admin in windows 8,  for some odd reason the drives you create with net use as admin can then only be accessed when logged in as admin  
windows 8 seems to have changed a lot of the way mapped network drives are configured

PLUS  I have a suspicion that they have exempted Server 2008 R1.  I ran into a similar thing with Server 2003 a while back several years) in an office where most people had XP, one person had Windows 7 and one had Windows 7 Ultimate.  

It turned out (after a LOT of head scratching and a lot of Nobody knew why) that Windows XP and Server 2003 were fine,  Windows 7 Ultimate and Server 2003 was fine,  But windows 7 anything else other than Ultimate was NOT fine.  They were upgrading the whole office to Windows 7 and did not want to buy ULTIMATE for a workstation.  I ended up having to upgrade the Server it was cheaper.
This was only a simple workgroup, not a Domain setup.  I never did find out what was IN the ULTIMATE version that was not in the Regular Version but it sure as heck worked that way.

And now I see a similar pattern with Windows 8.1 (Which should have been called Windows 9 as it is completely different, needs different drivers for almost everything)
We are (as is everyone) having drive mapping issues.  Can't figure out what they changed this time.

While I'm at it, tell me this.  Do you know of any way to set a router such that all traffic originating on port 445 is re routed to another port so that people whose ISP's block 445 can connect their VPN and map to a servers sshared folders?  The SMB protocols require port 445 which many ISP's block.  Supposedly to give you better "security"  yet the same ISP does not bother to be so "protective" if you have a business account.  Then the port is NOT blocked.  What it mostly does is prevent people from working at home on their Home internet unless they pay extra to get Business Internet (or rather pay extra to Unblock those ports)

[questorfla]

This would be nice but I have a question.  I used to always use the persist= /y but found that it compounded my later problems of changing the links.  Once set with persist, we had a dickens of a time getting them to release the mapping to a new setup for either the same folder or a different drive letter.

Write a bat file that does the net use k: /d and net use k: \\x.y.z.n\share /persist=y for all drives.

But you should really consider to start using the server's name instead of the ip, as windows is perfectly capable of resolving that, even in a workgroup.
When replacing a server, just turn off the old server, and give the new server the same name.

[Stoic Joker]

Worse, if you run as admin in windows 8,  for some odd reason the drives you create with net use as admin can then only be accessed when logged in as admin 
windows 8 seems to have changed a lot of the way mapped network drives are configured

That's what session isolation does. Running as Admin (or an admin users acct) loads and modifies that users profile only. And drive mappings are of course profile specific, not system global. But you really shouldn't need admin rights to map a drive. Typically use of a login (not start up) script would be the easiest way out. Have the script first delete the mappings and then create them in a non-persistent fashion so any issues that arise can be resolved by simply rebooting.

Another thing to consider is do you really need 5 separate mapped drives?? IIRC and assuming you do have a server server DFS does work in a workgroup and is an excellent way of bringing discontiguous storage locations into a single target.

...This was only a simple workgroup, not a Domain setup.  I never did find out what was IN the ULTIMATE version that was not in the Regular Version but it sure as heck worked that way.

I always laugh before cringing when I hear this. While workgroups are "simple" to setup, they are a complete and total nightmare to maintain because everything has to be done again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again, and again... (infinity) ...Even for the most tiny and trivial changes. Which is why they are typically not done. Actually nothing is ever done after this "simple" configuration is tossed out of the box until something goes horribly and catastrophically wrong.

Less than 10% if all the workgroup networks I've encountered in the field had properly working NetBIOS name resolution.

While I'm at it, tell me this.  Do you know of any way to set a router such that all traffic originating on port 445 is re routed to another port so that people whose ISP's block 445 can connect their VPN and map to a servers sshared folders?  The SMB protocols require port 445 which many ISP's block.  Supposedly to give you better "security"  yet the same ISP does not bother to be so "protective" if you have a business account.  Then the port is NOT blocked.  What it mostly does is prevent people from working at home on their Home internet unless they pay extra to get Business Internet (or rather pay extra to Unblock those ports)

If this is a gateway to gateway VPN there should be static routes that send all LAN protocols through the tunnel. If this is a client to gateway VPN - you have my sincerest sympathy - it should be a gateway to gateway VPN.

[questorfla]

client to gateway, of course.  Otherwise it would not be blocked.    ISP's just want to be paid for Business se even if it is only occasionally
As stated:  Users is at HOME.  That is why the issue.  If they were on a business internet, no problem.
As for the WDN, I haven't had any problems with it lately.  Like for 4 or 5 years?  Should I have?  Of course, I did add the referenced QDN to the matching IP in the Hosts file correctly in both the server and the client systems (I have never known why the Server would need to know its own name but I was told to do that once a long time ago and it solved the problem once and for all).  As for all the mapped drives, that has always been a complaint of my own.  Technically hese could all be subfolders of the main USERS folder with permissions mapped.  I inherited this mess running on Server 2008 R1 and am just trying not to rock the boat too hard.

Thanks for the help though.

[Stoic Joker]

client to gateway, of course.  Otherwise it would not be blocked.    ISP's just want to be paid for Business se even if it is only occasionally
As stated:  Users is at HOME.  That is why the issue.  If they were on a business internet, no problem.

Crap, totally missed that bit. Still it shouldn't matter what the ISP blocks with a VPN, as all the LAN protocol requests should be router through the tunnel...not raw through the internet where it could be blocked.

As for the WDN, I haven't had any problems with it lately.  Like for 4 or 5 years?  Should I have?  Of course, I did add the referenced QDN to the matching IP in the Hosts file correctly in both the server and the client systems (I have never known why the Server would need to know its own name but I was told to do that once a long time ago and it solved the problem once and for all).

It's rather sadly common for people to botch the name resolution on a WDN configuration. If AD can't properly identify itself, it can't authenticate its own activities...and tends to self destruct in very creative ways. constant replication errors (even with a single DC), difficulty joining machines to the domain, and slow client logins are common signs of a bad DNS configuration. I've seen workstations take 20min from login to desktop due to improperly configured DNS on a WDN.

As for all the mapped drives, that has always been a complaint of my own.  Technically hese could all be subfolders of the main USERS folder with permissions mapped.  I inherited this mess running on Server 2008 R1 and am just trying not to rock the boat too hard.

File sharing is a very bandwidth intensive activity (lots of status and file information going back and forth) that was designed with a 100Mb LAN in mind. So multiple mappings through a tunnel is a huge performance killer. If the VPN clients are configured properly (e.g. share access is going through tunnel) you may actually be having timeout issue due to the excessive share access traffic. In the past I've used an internal access only FTP to allow access to a file server through a VPN to avoid bottlenecks (but that too has its drawbacks).

[40hz]

@SJ - Just thinkin'...Samba 4 now has the ability to act as a basic AD DC...

Never tried it personally. Have you? 

[Stoic Joker]

@SJ - Just thinkin'...Samba 4 now has the ability to act as a basic AD DC...

Never tried it personally. Have you? 

Might be fun to play with, but I'm still trying to get Samba installed on something in a VM so I can play with it properly. I tried getting TinyCore TCL installed in a VM at lunch today...but never did find an install button in the damn thing. CD.iso booted fine, right to DT ... But the VM's HDD is raw and the install shortcut isn't where the instructions said it should be.  Derp!

[40hz]

@SJ - Try this or this.