\\tsclient\x: shares in XP Mode started failing

[dkorsmo]

We run a small MS Network with six Windows 7 Pro workstations that all run an XP Mode virtual environment so that they can access a legacy DOS application. The application has a database that we keep on the Windows 2012 Server, and each workstation has a persistent share of that folder as it's J: drive. This is automatically available in the XP Mode environment as \\tsclient\J:, but those re-directed drives are not available within a DOS environment. So from within the XP Mode environment we run a Net Use J: \\tsclient\J: /persistent:yes so that the J: drive of our Win7 environment becomes available in the XP Mode environment as J:, which makes it available to our old DOS application. Over the past year, it was not uncommon for the share to fail on a given workstation, but all we had to do was to delete and re-establish the share. Last month, we had a workstation where the share would appear to re-connect, but the data was not available. In the XP Explorer, we see both the \\tsclient\J: drive, which works fine, but it would say that the J: drive is either not available or has become corrupted. In the Win7 Explorer, the share was viewable and useable, so I presume there is something that has recently changed in Windows 7 that has made the Windows Terminal Services Network unstable. This past week, a second workstation has succumbed to this issue. Our work-around has been to create a BAT file that does a "Net Use J: \\<server IP Addr.>\<folder> /user:<userid> <password> /persistent:no". We put this BAT file in the Startup folder of the XP Mode environment to establish the share at startup. This works, but requires placing the user's network password in the clear in the BAT file, and also requires us to change the BAT file every time the user changes their password. Has anyone else seen this behavior? Does anyone know how to correct it?

 

[torchwood]

Hi DK,

shot in the dark- after effects of the MS patch for Wannacry which played around with SMB1 permissions
KB4012212

Roy

 

[dkorsmo]

So I either expose the machine to wannacry or continue using my workaround? I am not familiar with SMB1 permissions, is there something I could change that might allow me to go back to the original configuration? Perhaps give XPMUser some specific permissions?