Error 500

[R_Scheer]

Hi,

after a new Installation (Manager and DB) we get an error 500, when we assign an appstack over a AD-Group. After the user login the following error appears: Connection Error (Manager ... error code 500): Unable to contact App Volumes Manager. Virtualization is disabled.

This error appears only by assigning over a AD-Group. Assigning over a user or a computer works fine.

any ideas?

[Ray_handels]

@JHT: There is a max of security groups a user can be member of. I though that it was something in the line of 250 groups and i mean all groups, so not only direct member but also nested group member. We have had our fare share of crap with this issue with people not seeing folders on file shares due to being a member of to many groups and using ABE.

Because we had this issue already we take great care in the number of groups users are member of. So if they do have more than 250 groups memberships it is not an AppVolumes/VMware issue but a Windows/AD issue because Windows cannot enumerate all permissions.

@Yorrick: This is what indeed was stated officially when updating from 2.5.2 to 2.6 i thought. If you have groups that have non ASCII code signs in it change this group name, update and change it back again. This would imply that after updating all would be well and you should be able to use the umlaut again. I also saw some posts from Jason statign that no all languages were applied to AppVolumes. Still, an umlaut IMHO is quite commonly used so this should be possible.

P.S. We are now running on 2.6 (newly build) with VSphere 6.0 and view 6.1, works like charm up until now.

[R_Scheer]

I have looked again and noticed that our test users have some securite groups or distribution lists with umlauts for example "domänen-admins" (default group of the domain), Führungskreis erweitert" , etc.

If I remove this group memberships, I get no error 500. The App Volumes Agent appears at login to check all the groups. If the check of a group fails, it stops further execution and displays the above error 500.

I have no idea how to handle this problem. I've checked our AD and we have more than 500 groups with umlauts.

Vmware explained in the release notes for App Volumes 2.6.0 a better internationalization support*. Does this mean the elimination of the umlaut support? In version 2.5.0 this was not really a problem.

* Improved Internationalization Support - Product can run on an English and non-English OS and can accept non English input/output.

[whibr]

Ray_handels:  Have you found any issues or problems with the vSphere 6.0 or vCenter 6.0 and AppVols 2.6?

[Ray_handels]

I'm not quite sure if this will help in any way but still i'l just mention it.

We had an issue with adding applications to a group allthough it was listed. What we did was move AD groups around and it looks like AppVolumes doesn't like that.

When you go to Directory --> Groups and click the group you have these issues with, do you actually see a number behind members other than 0?

If not it seems like, for some reason, Appvolumes cannot find or use the group. What i had to do is change this setting in the database (groups table) and changed the [distinguished_name] in the database for this group.

[R_Scheer]

Reply from the VMware Technical Support:

Just to inform you that this issue is being investigated by our engineering team and they have scheduled a fix for this in an upcoming release.
At the moment, I don't have an exact date for the release but I will pass it to you once we have confirmed it.

[JHT_Seattle]

Funny - the note I got a few days back on my open ticket said the issue is resolved and will be included in the next release.  My ticket is open pending that release, so I'm hoping for very soon.

[Ray_handels]

I'm very sorry but i've only noticed your reply just now whibr.

To be honest we do have an issue with VSphere 6.0. What we see happening is when a user has more than 1 appstack login takes quite some time because the reconfigure action in VCenter takles quite some time (over 20 seconds) while if you only have 1 appstack reconfigure is done within a second.

To be honest i'm not quite sure if it is indeed related to Vsphere 6.0. Also, imho VSphere 6.0 should be something that's already is supported due to 2.6 being released together with Horizon 6.1 and Vsphere 6.0.

Anyone else using Vsphere 6.0 and having these issues??

[JHT_Seattle]

At least your login only takes 20 seconds!  We were seeing a similar issue after moving to v6, but when we got to 4 stacks (3 or less were fine).  We cutover to a new v6 Server, having exported our parent images and imported them to new storage.  I had uninstalled the App Volumes Agent, View Agent, VMTools, then reinstalled the newer ones in the reverse order (VMTools for v6, View Agent 6.1.0, App Volumes Agent 2.6.0).  Nothing we looked at made any difference to the logon issues with stacks until we recreated a parent image from scratch.

We did the same thing with our stacks, copying them to new storage and importing them into a new App Volumes Manager, but 15% of them just plain didn't work.  The telling sign seemed to be stacks that could not report what applications were in them.  We could "update" those stacks and close them out immediately so that they would appear to be working (the applications were reporting once again), but when attached they would close the session at launch, or just plain not work.  Those stacks had to be recreated from scratch as well.

We're waiting for the 2.7 release (soon, I'm told) to resolve the Error 500 of this thread so that we can move forward.  As it is now, not being able to move to 2.6.0, even, we had to put our plans for App Volumes on hold because we can't tolerate the issues in 2.5.2 when it comes to maintenance of the server disconnecting all of the stacks.

[Ray_handels]

Hey JHT,

We decided to build all up from scratch (which in this case wasn't that bad because we are of the PoC and going into pilot/production).

Unfortenately our logon time isn't 20 seconds when having more than 1 appstack it is more in the range of 1 minute .

We do see a lot of gaps in logging from Appvolumes when reconfiguring and i really hoped it will be fixed. Loooks like communication from Appvolumes server to VCenter is somewhat different in 6.0

So we are still going strong but have stepped up a bit in trying to get issues out of the way .

[JHT_Seattle]

I'm not sure what you mean when you say "We do see a lot of gaps in logging from Appvolumes when reconfiguring".

Our login times were normal-ish with 3 stacks  after migrating parent images and our stacks to new LUNs, but attaching any 4th stack would invoke a built-in timeout, leading to a 5 1/2 min logon, consistently.  We only just found out about one pool of users yesterday where we had multiple stacks applied, that were seeing logon times of 15-20 minutes!  In both/every case, replacing our previously working image with one we built natively in the v6 environment cut logon times back down to <30 seconds. 

Some of the slowness in just getting to a VM we've seen since moving to v6 doesn't have to do with App Volumes, I think, but with the Cloud Pod configuration and Global Entitlements.  As opposed to local entitlements, the GE has to evaluate conditions for each user logon request, adding a few (5-7 seconds) when the Client is requesting a VM.

[Ray_handels]

What we mean by this is when you look at the svservice.log file you see the following thing happening. First Cloudvolumes Agent sees the logon, then contacts the manager to reconfigure the VDI and attach appstacks and writable volume. It then waits for over 30 seconds for the manager to respond and say that indeed appstacks are attached to the VDI. When we look at the VCenter server it takes up to 25 seconds to reconfigure the machine. [2015-04-24 06:11:30.889 UTC] [svservice:P944:T252] [0] Connecting to :443 using HTTPS (attempt 1) [2015-04-24 06:12:06.733 UTC] [svservice:P944:T252] HttpInitializeRequest: Manager status 200 response (909 bytes): *7*#7#LOGIN DOMAINNAME\USERNAME We did however took an "old" W7 golden image from a VSPhere 5.1 environment and copied it into the new environment. Could be that this is what's causing the issue. I might just give it a testrun to see if it resolves anything. But it still is strange that it does work when having only 1 appstack but fails to configure in a timely manner if you have multiple appstacks.

[JHT_Seattle]

Sounds too similar to the behavior we saw for it to be coincidence

How did you copy over your old image?  I did it by exporting the VM locally (from a 5.5 U2 server) and then uploading it to the new datastore and importing into vCenter (6.0).  I don't know if it would have been any different had I used Veeam or vCenter Converter, but now I wonder.  I'll have a chance soon enough to test it with Veeam, but that copy will be from a v6 environment to another v6 environment.

When I built my new image to test, I just installed the OS, fully patched, and the VMTools, View Agent, and App Volumes Agent.  That was enough to tell the difference right away.

[JHT_Seattle]

"Error 500" is truly resolved in the 2.7.0 release.  Now this thread should be marked as resolved.

[R_Scheer]

Today I received an email from the support:

...

Thank you for your patience in this matter.

It seems that this issue "Connection Error (Manager ... error code 500): Unable to contact App Volumes Manager. Virtualization is disabled."
Has been resolved in an upcoming release of VMware App Volumes.

The version containing the fix is App Volumes 2.9 and is scheduled for release in mid June.
Please note that this date is subject to change depending on other features / issues which may be resolved by this version.

App Volumes version 2.7 was just released today but the fix did not make it into this build unfortunately.

Please let me know if you need anything further from me at this point?

[JHT_Seattle]

I guess not all 500 Errors are created equal, but for us we had the issue and it wasn't related to the character issues that others saw (with umlauts, etc).  So there may be some more official fix in the 2.9 release, but I'd encourage you to spin up 2.7 somewhere and test.

[R_Scheer]

Yes, your are right. With version 2.7.0 we no longer have the problem with the umlauts.

[matthiasFF]

Wow, this is unbelievable. Like you mentioned in your last post though, assigning security groups works in v2.7 with german umlauts.

[kclinden]

I am seeing this issue as well with vSphere 6.0. Were you able to find a fix for it?