AppVols upgrade to 2.10 "NTLM Authentication failed for: Domain\user. Virtualization is disabled"

[PeteJohns]

Hi,

Last night we upgraded from 2.9 to 2.10, tested and tested as much as we could and were happy so went live. This morning users (and myself!) are reporting that upon login you receive the error and no stacks get attached. Logging out and back in again occasionally fixes the issue but at the moment it is not consistent at all. Very close to rolling back but I'd rather go forwards!

Error:

App Volumes Message

Error from Manager <dns name> (error code 401):

NTLM Authentication failed for: <Domain\user>

Virtualization is disabled

Horizon View 6.2.

5 domain controllers on Server 2012 R2

ESXi 6

Any ideas?

[Jason_Marshall]

2.9 does not support Win 10.

[hahaU812]

Thanks for the update Raymond.

Matt

[HariRajan]

HI All ,

This what I did as  a workaround .

Provisioning machine created and added to domain (tried with Windows 7 -64 bit)

added same service account which is used for logging to the appvolume manager in provisioning machine local administrative group.

then enabled windows authentication feature (NTLM) in the machine .  which is mentioned below

WINDOWS VISTA OR WINDOWS 7

1. On the taskbar, click Start, and then click Control Panel.
2. In Control Panel, click Programs and Features, and then click Turn Windows Features on or off.
3. Expand Internet Information Services, then World Wide Web Services, then Security.
4. Select Windows Authentication, and then click OK.
   

Restart the VM and login as local admin or service account which is added to the machine , in my case service account login is not working , suspecting it as a issue .

but login as local admin account is fine , check whether the virtualization disabled warning is there or not ? .  

Please check and let me know if it is working for you .

Other OS below steps will work,

WINDOWS SERVER 2012 OR WINDOWS SERVER 2012 R2

1. On the taskbar, click Server Manager.
2. In Server Manager, click the Manage menu, and then click Add Roles and Features.
3. In the Add Roles and Features wizard, click Next. Select the installation type and click Next. Select the destination server and click Next.
4. On the Server Roles page, expand Web Server (IIS), expand Web Server, expand Security, and then select Windows Authentication. Click Next.
   .
5. On the Select features page, click Next.
6. On the Confirm installation selections page, click Install.
7. On the Results page, click Close.

WINDOWS 8 OR WINDOWS 8.1

1. On the Start screen, move the pointer all the way to the lower left corner, right-click the Start button, and then clickControl Panel.
2. In Control Panel, click Programs and Features, and then click Turn Windows features on or off.
3. Expand Internet Information Services, expand World Wide Web Services, expand Security, and then select Windows Authentication.
   
4. Click OK.
5. Click Close.

WINDOWS SERVER 2008 OR WINDOWS SERVER 2008 R2

1. On the taskbar, click Start, point to Administrative Tools, and then click Server Manager.
2. In the Server Manager hierarchy pane, expand Roles, and then click Web Server (IIS).
3. In the Web Server (IIS) pane, scroll to the Role Services section, and then click Add Role Services.
4. On the Select Role Services page of the Add Role Services Wizard, select Windows Authentication, and then click Next.
   
5. On the Confirm Installation Selections page, click Install.
6. On the Results page, click Close.

[LikeABrandit]

I wanted to add a simple workaround I found to work when I ran into this issue on a new VDI installation using AppVolumes 2.10. We tried several of the mentioned workarounds in this thread with mixed success, but in the end, all we needed to do to was simply give AD time to replicate (depending on your infrastructure, this amount of time could vary), then reboot the VMs. This fixed the issue consistently for us.

Hope there's a fix coming up soon, thanks all for the helpful info!

~LikeABrandit

[nuberaldhoore]

As suggested by Support I did the following:

Step 1

pointed all VDIs to the central Domain Controller

==> problem disappeared for about a week, but then magically appeared again

Step 2:

downgraded the Appvolumes agent to version 2.9.

==> No NTLM authentication errors anymore

==> New error: Appstacks created with AppVolumes Agent version 2.10 do not work anymore (in our case Office 2013 Pro). So now we have to downgrade the appvolumes agent on our provisioning machine to version 2.9 and re-create the Windows 2013 Pro appstack.

Very messy situation!

[PeteJohns]

Apologies for not responding to this thread since first posting it.

A few hours after logging the issue was resolved by VMware using the following fix:

From the console, go to Configuration, Machine Managers.

Expand your Machine Manager, and untick Mount On Host

VMware claim this resolved the issue....

...

HOWEVER....the problem came back, and that 'fix' doesn't do anything. This means we are not sure what fixed it the first time, or even if it was completely fixed.

Since Friday we've been getting the same NTLM issue. Last night we recomposed the desktop again and now we get a slightly different error (attached - no NTLM error but Virtualization is still disabled), however the result is the same for the end user - no apps. Our project is going to get completely stopped if this doesn't get resolved so I've had to escalate it where ever possible.

Thanks for the info about rolling back to 2.9 - we really don't want to do that!

[Kirry]

Hi all,

I've also had this same error:

"NTLM Authentication failed for: Domain\user. Virtualization is disabled"

and I finally managed to fix it.

in my environment I have set the "VM" used for "App Volumes Manager V.2.10", with two network adapters, one for Internet and the other one for my local network.

Unplugging the internet network adapter from the "App Volumes Manager V.2.10", the error has gone, giving to the end users their applications.

I do not know if this is the same situation in which you find yourself, but this is my case and this is how i finally fixed fhe error.

Hope this helps.

BR

[szilagyic]

FYI, I had this same problem on a brand new install of 2.10.  I applied the fix from HariRajan, by installing the "Windows authentication" component on our Win 7 clients and they authenticate now just fine.  Hopefully VMware provides are permanent fix for this soon.

Thank you!

[szilagyic]

I also found another indicator of the underlying issue and workaround.  In the cases where we had the issue, the Windows Domain Trust Relationship was broken for the VMs that had the NTLM error.  When we fixed the trust relationship (removing and adding the computer to the domain), I then re-installed the App Volumes agent and then it was able to connect to the manager and showed up under the inventory without having to add the "Windows Authentication" component.  So it seems that the computer account definitely needs to be good in AD for the agent to check in with the manager.

[joshopper]

I am having a similar issue but rather than the username in the NTLM its the machine name. The issue seems very sporadic and is not occurring on machines that are not on the domain.

Anyone have any additional updates on this?

[matteoabrile]

Also on my side I have same issue with machine name and not with domain\user. On my side occur after recompose VM, maybe when Composer add it to domain, not sync with secondary DC. If agent ask it, it reply with error.

Someone has workaround ? Thanks

M.

[matteoabrile]

Hello,

I solve problem change name of App Manager with IP. I hope this change help someone.

Thanks

M.

[miz_ringier]

We had the same issue after upgrading to appvolumes 2.10.

We've resolved the issue!!!!

the issue was: Our Parent-Image didn't had the same hostname like it had in vcenter. For example: machinename in vcenter: PIW7-Office-10-210      windows hostname: PIW7-Office-2

Now to resolve the issue:

1. unjoin the machine from AD

2. delete the computer object in AD

3. uninstall the appvol agent

4. reboot and give a better name

5. rename it with the same name in Vcenter

6. vmotion to another storage(to change the name to folders and vmdks)

7. join machine to domain and install the Appvol Agent.

So far, this worked for us. I hope it helps you guys.

Thank you

[matteoabrile]

I think solve with IP instead DNS name but today after some recompose occur again. Only solve reset VM after recompose.

I have already VM DNS name same vCenter name. But I have problem with same VM.

Thanks

M.

[MSMorgan12345]

Any word from VMware when they think that they will have this squared away.  I am getting this issue very randomly and not on all of my desktop pools

[joshopper]

From what I understand the only way to thoroughly do away with this is to have the app vol manager pointed at a specific domain controller and have your Virtual Desktops only register with that one domain controller. Not a great solution. I am going through the paces with support just in case one of the other suggested solutions work for us but I am guessing that is a no. AppVolumes 3.0 is set to be released soon and I would hope with all the attention this issue has gotten that they have resolved it for that upcoming release.  

[nunya8814]

I'd bet once 3.0 releases!

[nuberaldhoore]

As far as I understood it from VMware Support, this will not be included in the 3.0 release.

Maybe someone from VMware can give us an official answer on this.

[joshopper]

Here is the latest fix I received from VMware support:

On the AppVolume Manager edit the svmanager_server.bat and set the DEMO value to 1 and restart the management service. This is supposed to disable the NTLM check but has the downside of making the Dashboard charts inaccurate. (a small price to pay)

c:\program files (x86)\clouvolumes\manager\svmanager_server.bat: set DEMO=1

[CPhelix]

Got the same info from a VMWare Tech. "DEMO=1"

Worked!!

It was also noted that this is fixed in 3.0