Server migration ... clients still connecting to old shares

[Cazale]

Hey.

 

We did a server migration over summer from 2012 to 2019. All the shares were copied across, the policies look okay, the FSMO roles are transferred. DNS and DHCP are copied over, etc.

 

All the other server migrations we've done previously have gone okay, but this time, it's 50/50 if a user connects to a network share on the old server or the new server.

 

I inherited the old server, and for some reason, whoever put it in used a VBS script for network shares rather than a GPO or a bat file. The script is kind of as follows:

 

On Error Resume next

Dim WshNetwork

 

Set WshNetwork = WScript.CreateObject("WScript.Network")

Set objSysInfo = CreateObject("ADSystemInfo")

Set objNetwork = CreateObject("Wscript.Network")

 

strUserPath = "LDAP://" & objSysInfo.UserName

Set objUser = GetObject(strUserPath)

 

WshNetwork.RemoveNetworkDrive "M:"

WshNetwork.RemoveNetworkDrive "W:"

 

objNetwork.MapNetworkDrive "W:", "\\newserver\Workspace"

objNetwork.MapNetworkDrive "M:", "\\newserver\simsroot"

 

I've obviously manually changed \\oldserver to \\newserver in the above script (I've searched for the script server wide and changed every copy, on both servers). This is then called by a GPO for each group of users in User Config, Scripts, Logon.

 

 

But, like I said above, I can have two users, in exactly the same OU, have them both log on at exactly the same time, and one user will have W: pointed at \\newserver\Workspace and one user pointed at \\oldserver\Workspace.

 

With limited testing, a gpupdate /force does seem to fix the issue, but of course that's PC dependent (i.e. if the user then logs onto another machine it's 50/50 again). If a machine decides to connect to \\oldserver leaving it 15 minutes+ and rebooting does not seem to force the change.

 

Am I missing something obvious? Thanks in advance.

Edited September 4, 2020 by Cazale

[FN-GM]

Could you scrap the VBS script and use group policy preferences?

[HPlum78]

Sounds like a profile issue?

[Cazale]

Could you scrap the VBS script and use group policy preferences?

 

That's definitely what I'd like to do. It's how we do it elsewhere.

 

I think what put me off is that the network share already exists and I was afraid of a conflict when the GPO tried to use the same drive. I guess I was just being lazy by using the existing solution. I'll do some testing

[Davit2005]

Have you tried removing network drives as part of the script before recreating, we used to do that?

 

But I'd seriously consider the Group Policy Preferences option.

[djm968]

DNS conflict? - flush DNS on a client and check again. Edited September 4, 2020 by djm968

[HPlum78]

I thought DNS initially but the script is using a hard coded path.

[bald_pig]

Run a gpresult on a machine pointing to the old server and see what policies it's using.

[Katy]

If the user's profile is remembering the old connection then the lines in the script mapping the drive letters to the new path will fail. You'll need to delete the drive mapping first (can't remember how to do this in VBS off the top of my head but it'd be "net use n: /del" in command prompt).

 

Otherwise if you use Group Policy Preferences and remove the script it should overwrite the remembered old mapping, in theory.

[Cazale]

We're definitely moving to group policy from Monday, but I think I might have sussed this (information just supplied in case anyone else chances on this thread):

 

It seems to be a local profile caching issue. I'm guessing this is some oddity of using a VBS script (?), but for the users with issues; I've noticed they have a cached copy of the vbs script (still pointing to \\oldserver) in C:\users\\AppData\Local\GroupPolicy\DataStore\0\SysVol\domain.local\Policies\\User\Scripts\Logon on their local machine.

 

I'm not going to do much testing, because as I said, we're moving to GPOs, but deleting that file does seem to fix the issue.

Edited September 4, 2020 by Cazale