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!
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
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
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 .
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!
As suggested by Support I did the following:
pointed all VDIs to the central Domain Controller
==> problem disappeared for about a week, but then magically appeared again
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!
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!
I've also had this same error:
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.
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.
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.
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?
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
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.
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.
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.
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