VMware Converter ‘Unable to Connect to the Network Share’

KB ID 0001583

Problem

I don’t think, Ive ever run the VMware Standalone Converter, without at least one error message or popup complaining about something! Today I was trying to convert a clients old Windows Server 2003 document management server, when trying to deploy the agent this happened;

Unable to connect to the network share ‘{Sever-name-or-IP} \ADMIN$’.

Solution

It’s a pretty descriptive error, can you map a drive to this machine and open a network share manually? Is the ‘server service’ running? In my case the problem was easily diagnosed;

As I wasn’t about to start enabling SMBv1 on the clients Windows 2019 server! So I simply installed the VMware Standalone converter on one of their existing 2008 members servers instead, and ran it from there.

Related Articles, References, Credits, or External Links

SMB1 Is Dead? (Unfortunately Not Yet)

VMware Converter – Unable to Deploy Agent

SMB1 Is Dead? (Unfortunately Not Yet)

KB ID 0001461

Problem

I recently did a migration for an engineering company, about a week later I got an email from them to say, “We have a new Windows 10 PC, and it can’t connect to the ‘N’ Drive?” I asked them to send me a screenshot, the error was;

You can’t connect to the file share because it’s not secure. This share requires the obsolete SMB1 protocol, which is unsafe and could expose your system to attack.
Your system requires SMB2 or higher. For more info on resolving this issue, see: https://go.microsoft.com/fwlink/?linkid=852747

Some Googling told me that windows 10 (build 1803) had removed SMB1, and like most people who see this for the first time, I got thePowerShell to turn it on, client was happy end of problem right?

Well yes and no, ‘SMB1 is Bad‘, very bad in fact, enabling SMB1 is a bit like removing the windows from your house because your too hot, yes it solves the problem, but now anyone who wants to jump into your house can do so, at any time of the day!

OK What’s Changed?

With Windows 10 (Build 1803) SMB1 has been completely disabled. If you try and connect to a device/share that’s using it you will see the same error my client did.

However if you have an earlier build of Windows 10, and you simply let it update, (Including the 1803 July Security update), that will continue to work.

I tried to replicate this on my test network, like the client I had a 2008 R2 file server, and connected to it from a new Windows 10 and an old(er) updated Windows 10 machine. Everything worked? In fact to replicate the clients error, I had to manually disable SMB2 and force SMB1? That’s strange I thought, so I checked the clients server;

As you will discover (below) the DWORD highlighted disables SMB2 and forces the server to use SMB1. Now the server does not ship like this, and I doubt very much anyone did this manually, so where did it come from? Well as an educated guess, the software that runs on this server needs SMB1. (They have some older Linux machines and machinery that logs are collected from).

Solution

As Microsoft says;

Warning: We do not recommend that you disable SMBv2 or SMBv3. Disable SMBv2 or SMBv3 only as a temporary troubleshooting measure. Do not leave SMBv2 or SMBv3 disabled.

So the steps I outline below, are so you can actually do some troubleshooting, to see what’s wrong. The third law of engineering states ‘Just because you can do something, does not necessarily mean you should‘ That being said, I appreciate we operate in the real world. If your line of business software needs SMB1 you cant shut down production while the vendor fixes their ‘poorly written, and relying on 30 year old protocol‘ code. Or, what you are connecting to might not be a Windows machine at all! It might be an appliance tha’ts old, with no firmware to update it to SMB2/3, and there’s no budget to replace it.

Windows 10 Enable SMB1

Use the following PowerShell;

[box]

Get-WindowsOptionalFeature -Online –FeatureName smb1protocol
Enable-WindowsOptionalFeature -Online –FeatureName smb1protocol

[/box]

Again this is a temporary fix! As soon as possible disable it again.

[box]

Disable-WindowsOptionalFeature -Online –FeatureName smb1protocol

[/box]

Windows Server (Enabling/Disabling SMB1 & SMB2)

As with most things, SMB status is set in the registry (see above).

Enable or disable SMBv1 on the SMB server;

Registry subkey: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
Registry entry: SMB1
REG_DWORD: 0 = Disabled
REG_DWORD: 1 = Enabled
Default: 1 = Enabled (No registry key is created)

Enable or disable SMBv2 on the SMB server;

Registry subkey:HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
Registry entry: SMB2
REG_DWORD: 0 = Disabled
REG_DWORD: 1 = Enabled
Default: 1 = Enabled (No registry key is created)

Note:  You must restart the computer after you make these changes.

But things are much easier done with PowerShell, to see the settings;

[box]Get-ItemProperty HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters | ForEach-Object {Get-ItemProperty $_.pspath}[/box]

Note: Above SMB1 is enabled SMB2 is Disabled.

WARNING: To test this properly, I’d suggest converting this server to a VM and testing on a copy, or cloning the server, (if it’s already virtualised), then you can try out some non-destructive testing, to make sure your applications still work. Ideally start by enabling SMB2 and disabling SMB1 to test.

[box]Set-ItemProperty -Path “HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters” SMB2 -Type DWORD -Value 1 –Force
Set-ItemProperty -Path “HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters” SMB1 -Type DWORD -Value 0 –Force[/box]

Remember to reboot!

 

If your application still works great, ‘you didn’t need SMB1 anyway‘, sit back, light your pipe, and admire your handiwork!

If not, try with both Protocols enabled. (To be fair, security-wise this is just as bad as having SMB1 only, as all the ‘good bits’ in SMB2 can still be bypassed by using SMB1!) But at least (from a user perspective) your new Windows machines will connect via SMB2.

Remember to reboot!

 

Related Articles, References, Credits, or External Links

NA

VMware View – Using Persona Management

KB ID 0000615 

Problem

Persona Management, is the VMware version of “Roaming Profiles” and “Redirected Folders” rolled into one. Though the redirected folders bit is a lot easier to set up and less problematic than the Microsoft Folder Redirection policy.

Its handy if you using floating pools but still want your users to have a persistent user interface. Having these files centrally makes them easier to backup, and the more your users can customise their desktops and settings the better their level of equipment husbandry.

Solution

Create a “Roaming Profile” Network share with the correct permissions

1. On a network accessible server, create a folder and set the SHARE permissions as follows;

Share Permissions

Everyone = Read. Domain Users = Full Control.

Note: You may also want to DISABLE Caching on this folder.

2. Stop inheritable permissions from propagating to the folders and set the security permissions as follows;

Security / NTFS Permissions

Creator Owner (Subfolders and Files Only) = Full Control. Domain Users (This folder Only) = List Folder/Read Data and Create Folders/Append Data. System (This Folder, Subfolders and files) = Full Control. Creator Owner (Subfolders and Files Only) = Full Control. Everyone = No Permissions.

Note: I’m using domain users, you might have a different security group that you want to substitute.

3. Make sure that the machines that you will be using as view targets, have the View Persona Management option selected (this is selected by default).

Configure Windows 7 to be a VMware View Desktop

4. You need to get the administrative template for Persona Management. You will find it on your VMware Connection Server in the following location;

[box] C:Program FilesVMwareVMware ViewServerextrasGroupPolicyFiles [/box]

Locate the ViewPM.adm file and copy it to a domain controller.

5. Create a new group policy that is linked to the OU containing your View machines.

6. Edit the policy > Expand Computer Configuration > Policies >Administrative Templates > Right Click > add/Remove Administrative Temple > Add in the ViewPM.adm template.

7. Navigate to;

[box] Computer Configuration > Polices > Administrative Templates > Classic Administrative Templates > VMware View Agent Configuration > Persona Management [/box]

8. In the roaming and Synchronisation Section > Manage user persona > Set to Enabled > Next Setting.

9. Enable > Enter the shared folder you created earlier > Next Setting.

10. Enabled (to remove local cached copies of the profile).

11. Enabled to roam the local folder > That’s all I’m going to configure in this branch of the policy.

Persona Management Folder Redirection

12. Navigate to;

[box] Computer Configuration > Polices > Administrative Templates > Classic Administrative Templates > VMware View Agent Configuration > Persona Management > Folder Redirection [/box]

Here you will find the folders that can be redirected to a central location.

13. For example, here I’m redirecting the users “My Documents” folder.

14. And their “My Pictures” folder.

15. Make sure you have a pool created, and your users are have an ‘entitlement’ to them. These machines will also HAVE TO be in the OU your policy is applying to.

Creating a ‘Manual Pool’ and Connecting a View Client

Deploying Linked Clone View Desktops

16. Now when your users connect to their View Desktops.

17. Their user profile will be persistent.

18. Because their settings are stored in your profile shared folder.

Note: Persona Management will store the profile in username.domainname format. The reason there is a V2 on the end of it, denotes the profile is for Windows 7 or Vista. If users swap between these OS’s and any older Windows OS’s, then they will get a separate profile for those as well. If this is the case rely on the folder redirection rather than the profile.

Related Articles, References, Credits, or External Links

NA