App Volumes 2.12 - Error Unable to determine domain dns for "NetBIOSDomainName" from "NetBIOSDomainName\username" - Agent receives 400 Error

[techguy129]

Since upgrading to 2.12, our users are randomly receiving a 400 error. Its not consistent and is wide spread. We have both appstacks and writable volumes.  We are on version 2.12.0.70.

Agent log

[2017-01-25 13:43:25.911 UTC] [svservice:P1480:T1892] Message: "Error from Manager "appvolmanagr" (error code 400): LOGIN NetBIOSDomainName\username Virtualization is disabled" (hToken 00000000000003A8)

On Server

Jan 27 2017 07:22AM

Unable to save user "NetBIOSDomainName\rhugg":

Jan 27 2017 07:22AM

Unable to locate LDAP entry for "NetBIOSDomainName\rhugg"

Jan 27 2017 07:22AM

Unable to determine domain dns for "NetBIOSDomainName" from "NetBIOSDomainName\username "

Jan 27 2017 07:22AM

Error getting naming_contexts: An existing connection was forcibly closed by the remote host.

Anyone else seeing this?

[Lakshman]

Are you using multiple DCs? Are you seeing the error for users in the same domain or different domain? 

What is the value mentioned in the Domain Controller setting in App Volumes Manager?

SSL or SAN certificate?

[techguy129]

We have multiple DCs. The users are in the same domain. We only have one domain. the Netbiosname matches the netbios name in domain settings. I turn off ssl on the ldap connection. We are only using 389. Login to the desktop works 9 out of 10 of the times so its not consistent..

[Automatt1c]

Do you have any Azure DC's? Our Appvolume Managers were hitting the Azure DC and causing issues with the ldap requests. We ended up setting up all the other DCs on a load balancer and fixed the issue. This was on the 2.11 though. 

[techguy129]

We are not using Azure DC's. Our DC's are behind a load balancer. I received a hotfix from support and 2.12.1 included this hotfix. I'm in the process of verify that the update fixed my issue.

[JHT_Seattle]

I have this exact same issue since we updated managers to 2.12 awhile back.  I have a SR open for it, but have not received a hotfix... instead my logs were sent to engineering.  Can you give me your SR number so I can send it to my support engineer?

[Ray_handels]

We upgraded from 2.6 to 2.9 and after that to 2.12 and had issues with inconsistent databases after both upgrades. First time we were able to fix it manually but this time we ended up recreating the database because we saw to many issues with it.

Recreating the database was quite easy and straightforward though, just took us about half an hour imports not taken into account .

[JHT_Seattle]

Can you outline your process?  I feel like I'm overthinking how complicated this would be, considering you said it only took you a half hour

[Ray_handels]

We do have 2 Appvolumes servers behind an F5 which makes it a lot more easy.

We removed 1 of the servers from our F5 (you can install a new server but because your golden image points to a certain name it is easier to do it like this) and removed the old manager. Then we installed the new manager and created a new database in the process. After that we set up the configuration (which is farely easy as you still have the production one, it is just a copy paste thing) and imported all writables and appstacks.

If you used a specific prefix for the writable it will also import this into the new database. We even found out that a writable that we disabled actually was created as disabled in the new database. Keep in mind that importing takes quite some time. About 500 writables per hour I guess.

We did the exact same thing with the appstacks. Only thing we needed to do manually was to assign the appstacks. This was done in about 2 hours as we had a total of 300 assignments. You can export this information from the old database though, makes it a lot more easy And you can check and double check against the same query on the old database.

The only thing you need to do after that is to uninstall the active Appvolumes production server, make sure no one is logged in and then switch the active Appvolumes server in F5. After that you install manager on this server and point it to the new database and your back up and running.

[techguy129]

SR 17359172601

[Erossman]

Hi techguy129,

do you have any new information regarding this issue?

[techguy129]

I was told that I will need to wait for the next update or if a hotfix becomes available I will get it. I'm still having the issue but its not as wide spread.

A note was added in the release notes for 2.12.1 about this, it says:

• After a user provisions a large instant clone pool, a few machines are seen to be offline in App Volumes Manager. When the user tries to connect to one of these "offline" machines, a virtualization is disabled message is displayed.
  Workaround: Log out of the desktop and log back in; the AppStacks and Writable Volumes are available again.
• Recycle bin may show multiple copies of deleted items

VMware App Volumes 2.12.1 Release Notes

[Automatt1c]

Have you tried disabling NTLM authentication? That seemed to fix some problem we had.

[Erossman]

Thanks for the quick answer.

Yes we use instant clone but it's not a large one at the moment.

It would be great a find a way to delete this VMs automaticaly before a user logs in.

Maybe it's possible with a script which runs as a post-script after the provisioning of the instant clone.

[Automatt1c]

If you restart the Appvolumes service on the VDI desktop they will check into the Appvolumes Manager and go from offline to online.  I used to have an issue with the machines showing offline and not getting Appstacks. I created a script for the View composer to restart the service after making the clone. I needed it on appvolume 2.11 but the problem seemed to resolve itself on 2.12 with linked clones at least. We have around 3000 machines in the Pod.

[Automatt1c · Accepted solution]

So to give an update on this. I have a ticket opened with the same issue 17505719607. I have gotten with one of the Appvolumes Developers and he found the issue and is working on including the fix on the next Appvolumes release. It seems like the workaround in the mean time is to remove the Ldap load balancer VIP and enter the DC manually.  This is on 2.12.1 of appvolumes.

[techguy129]

I'm glad you got somewhere with support. I was left in the dust on this issue. I am using a VIP for LDAP. Hopefully this fixes this dreaded issue.

[Automatt1c]

So i have an update to this. I removed the VIP load balancer and still had some issues. The only way i fixed my LDAP and appstacks attachment issues was to clear out all of the setting in the active directory domain and only include the domain and the service account and leave all other fields blank. After that its working great now on 2.12.1. 100% attachment rate now.

Even just adding the LDAP base settings caused issues on our App Volumes. I talked with one of the programmers for App Volumes and it has a algorithm and health check to find the DC's and priorities the DCs with the lowest latency. So you should just leave everything blank to enable the auto features.

[howde]

To be honest...I deleted my post because I didn't expect to see anything back...so thanks for the quick reply. Couple extra questions...

When you say only you cleared settings and only set domain and username, does that mean you left Netbios blank as well? Are you using LDAPS?

[Automatt1c]

We are just using regular LDAP. I believe on  Appvolumes 2.12 it has AD integration so it no lo longer asks for the Netbios just The LDAP base(which i really the same things from what i can see).  Which i have left blank. As i was having LDAP query issues with the LDAP base added.