VMware Horizon Community
R_Scheer
Contributor
Contributor
Jump to solution

Error 500

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?

1 Solution

Accepted Solutions
Yorick1
Contributor
Contributor
Jump to solution

Hi,

We had the same issue. We could figure out what's the Problem was in our Environment. We have all Systems (AD, Server OS, etc) in German. One Group of our test-user had a Umlaut "ä" inside. When we logged in we got the Error 500. Without this Group it's working. The user's Primary Group has also a Umlaut "ä" Domänen-Benutzer inside. But that's not really a Problem, than the Primary Group wouldn't be checked.

View solution in original post

Reply
0 Kudos
37 Replies
Ray_handels
Virtuoso
Virtuoso
Jump to solution

The error you are discribing means that the machine with the agent is unable to access the manager.

Is there some sort of firewall setting within the appstack you are assigning (sounds far fetched to be honest)? But this doesn't seem to be an assigning issue tbh.

Reply
0 Kudos
R_Scheer
Contributor
Contributor
Jump to solution

No. In the LAN we have no firewall turned on.

The allocation of Appstacks about individual users or computer works without problems. Only the allocation of Appstacks about security groups shows the error above. I also have the problem when logging on to Manager. After a successful login, I get also the server error 500. If I then refresh the page (F5 ) the management interface appears to view and managing Appstacks .

Environment: Windows Server 2012 R2 German , MS SQL Server 2012 German. With App volumes 2.6.0 language should not be a problem, right?

Reply
0 Kudos
Ray_handels
Virtuoso
Virtuoso
Jump to solution

Appvolumes 2.6 and Horizon supports 2012 and also the language shouldn't be an issue if you ask me.

This is one of the known issues of 2.6, might this be an issue? That u are using other charaters than ASCII??

•If the ActiveDirectory group specified on the Configuration->Administrator Groups page contains UTF-8 characters, it is possible users will not be able to login after upgrading to 2.6. Change the the Active Directory group with UTF-8 characters to a group that only contains ASCII characters before upgrading to 2.6. After upgrade is complete the group configuration can be reverted to the original group containing UTF-8 characters.

Also, maybe a dumb question but did you restart the manager server? Is it quite strange that at first you can't login and when pressing F5 it works. Sounds like a failing web server on the managers site.

Reply
0 Kudos
CNovak
Contributor
Contributor
Jump to solution

I'm also seeing this exact issue after updating to 2.6.  App stacks were attaching correctly to security groups in 2.5 but now I receive the same 500 error when logging in to a desktop.  No names or settings have changed since the update and I can reach the manager FQDN successfully from the desktop.  Like R_Scheer, app stacks assigned to users or computers work just fine.  I'm not having an issue with the management web portal though.

Win 7 SP1 desktops, Server 2012 R2 for the manager, SQL 2012, App Volumes 2.6, etc.

Reply
0 Kudos
R_Scheer
Contributor
Contributor
Jump to solution

Great, we are not alone . We have tested many things: New server with another operating system ( Windows Server 2008 R2 English) for Appvolumes manager , new database ( SQLExpress installed on the Appvolumes Manager server), with and without broker service on the connection server. We have built new Appstacks, on the basis of the new templates. Accordingly, we have made a completely new installation. But still the same error 500 when logging in to a desktop.

btw: In Windows Server 2008 R2 English and SQLExpress we no longer have a problem with logging in to the management web portal, although we use the same admin group in the configuration. Perhaps this error was due to the language of the operating system or database.

Does anyone have an idea?

Reply
0 Kudos
Jason_Marshall
VMware Employee
VMware Employee
Jump to solution

For everyone on this thread upgrading from 2.5.x. and seeing this issue;

For backwards comparability the 2.5.2 agent is recommended if still using 2.5.x AppStacks. It is fully compatible and supported in this configuration With 2.6 Manager.

For or those using a non-English langue please ensure all characters in paths that are used by applications and the Manager are all ASCII characters.

If neither of those resolves the issue, please post back here.

Reply
0 Kudos
R_Scheer
Contributor
Contributor
Jump to solution

As already described , I get the error even with a complete new installation on an English operating system with an English SQLEXPRESS . I built a new Appstack with the new template ( 2.6.0 ) . All paths are standard : for example C:\Program Files ( x86)\Google\Chrome. Same error 500 when assigning Appstacks an AD security group.

In same constellation the allocation of Appstacks to users and computers works fine, so all paths should be correct.

Ok, the client operating system is still German (Windows 7 Enterprise).

What I can test:

2.6.0 app volume manager

2.5.2 app volume agent .

just take a look

Reply
0 Kudos
JHT_Seattle
Hot Shot
Hot Shot
Jump to solution

I updated the Manager to 2.6.0.  I left the Agent in my linked clones at 2.5.2.  I updated my provisioning machine with the 2.6.0 Agent and updated the templates.  I created a new stack with the updated template.  Installed the app, everything good so far.  Assigned the app to a single user.  Put a VM with the 2.5.2 Agent into maintenance mode, logged in via vCenter console as the user that was assigned the app.  Error 500.  I uninstalled the 2.5.2 Agent, rebooted, installed the 2.6.0 Agent, rebooted.  Error 500.

So even with a 2.6.0 Manager and Agent, and an app stack built on the 2.6.0 template with a 2.6.0 Agent, I'm getting Error 500.  Now I have no idea what options I have, but this is very scary, as it's only the 2nd real release.  It feels like more than any other feature that could be added, the upgrade mechanisms and procedures need to be addressed first.  I LOVE the technology, but can't afford to break everything by updating or be stuck on an older version just because I happened to build my stacks at a given point in time.

Reply
0 Kudos
R_Scheer
Contributor
Contributor
Jump to solution

Ok, tests finished:

With 2.6.0 Manger and all versions of the agents (2.5.0, 2.5.2, 2.6.0) we get the error 500, if we assign appstack a security group.

I have rolled back the complete environment to version 2.5.0 . The assignment of appstacks to security groups working again. We will open a support ticket.

Reply
0 Kudos
Ray_handels
Virtuoso
Virtuoso
Jump to solution

I do find it a bit strange to be honest. We are also using 2.6.0 manager with a 2.6.0 agent the appstacks being made with 2.5.0 (not even the 2.5.1 template) and we are not seeing this issue./

We are able to assign appstacks to AD groups. We are using VSphere 5.1 though, might this be the issue?

The only issue we are having is when logging into a 2.6.0 agent/manager desktop with a 2.5.0 or 2.5.1 Writable volume template the wtritable volume doesn't get attached and login takes more than 3 minute s(in logging we see a timeout on the assignment of exactly this 3 minutes and login without a profile takes over 1 minute which is normal behaviour).

I'm not quite sure but it seems there are a few loose ends on the 2.6.0 version. As Seattle said, i love the technology and are a very happy user but it seems this version has been pushed out to fast due to 6.1 view being released and Appvolumes needed to be ready for that.

James. Could it be that best setup is View 6.1 with VSphere 6.0? Do you know what the new version is tested with?? And yes i know thet VSphere 6.0 isn't even officially supported..

Reply
0 Kudos
CNovak
Contributor
Contributor
Jump to solution

We're all English language here for what it's worth.  Today I removed all App Volumes installs including the database and started fresh with 2.6 - templates, agents, manager, new app stacks, etc.  I still receive error code 500 at login when assigning stacks to security groups.  We're using vSphere 5.5u2 in a multi-domain AD forest but the same environment with 2.5 was working just fine.  The VM used for provisioning the app stacks talks back to the manager no problem and assignments to computers are still working.  Definitely interested in hearing a solution if someone finds out what might be going on.

Reply
0 Kudos
R_Scheer
Contributor
Contributor
Jump to solution

Exactly the same environment here. vSphere 5.5u2 in a multi-domain AD forest...

We will update our view environment to vsphere 6.0 tomorrow (we need the vsan 6.0 functionalities). Then I can test again with appvolumes 2.6.0 .

Reply
0 Kudos
JHT_Seattle
Hot Shot
Hot Shot
Jump to solution

Same setup here as well. I Tried switching the agent communication with the Manager to SSL but it made no difference.

I saw the other post about trying after updating to vSphere 6.0, but I doubt that improves the situation, since App Volumes 2.6 doesn't officially support that version.

Anyone look at Agent logs or run wireshark yet?  I know I can ping back and forth between agents and managers, and my provisioning machine works as expected, as others have mentioned.

Reply
0 Kudos
JHT_Seattle
Hot Shot
Hot Shot
Jump to solution

Are you guys close to any kind of workaround or solution?  Any closer to understanding the issue at least?  I'm trying to hold out, just in case, but unless we hear something soon, it looks like I'll be rolling back to 2.5.2. Some kind of progress note would be much appreciated.

Reply
0 Kudos
JHT_Seattle
Hot Shot
Hot Shot
Jump to solution

One new bit of information...  I assigned the stack I built on the 2.6 template in the 2.6 manager with the 2.6 agent to my user logged into a 2.6 agent workstation.  When I navigate to my username in the App Volumes Manager, it is unable to show me any assigned stacks (there's only the one) and I get a red "Server Error" message box in the top right of the page.  Nothing in the logging to indicate what it is, though.

Update:  Even with no app stacks assigned, looking up my user in the directory results in the "Server Error" message.  The same message appears when I looked up another user that reported the error 500 message and no stacks attaching.  An issue with the database, perhaps?  Time to re-index or reboot?

2nd Update:  I removed my username from the SQL database (db_owner.users) and confirmed I did not exist in the Manager.  I assigned myself a stack, watched the AD sync happen, then navigated to the username in the Directory tab.  Same "Server Error".

3rd Update:  After downgrading to 2.5.2 I navigated to my username in the Directory tab without any error.  The attachments section takes a little time to load (even with nothing attached), but it does work.

Reply
0 Kudos
Ray_handels
Virtuoso
Virtuoso
Jump to solution

Do you guys happen to use the override precedence option in the user properties?

As said, we are using the 2.6.0 agent/manager with writable volumes that are both 2.6.0 and 2.5.0 templates and it works correctly.

We don't have multiple domains though, might this be the issue??

Reply
0 Kudos
JHT_Seattle
Hot Shot
Hot Shot
Jump to solution

I'm not using any override options, and only testing with a single stack, no writeable volumes.

Reply
0 Kudos
JHT_Seattle
Hot Shot
Hot Shot
Jump to solution

Looking at the /log page, I have an idea as to what is the root cause...

My user (and several others) are in a LOT of security groups.  My theory is that looking up my user in 2.6.0 is trying to enumerate all of the groups I’m in, in order to determine what apps are attached based on the groups, etc.  Interestingly, we only see this issue present with some users in our environment.  I’m speculating now that for the users that are not affected it’s because they are in far fewer security groups.

Unrelated, there’s also a message in the /log page noting a SQL error where it can’t write the actual error into the system_messages table due to an ASCII-8BIT to UTF-8 conversion issue.

Yorick1
Contributor
Contributor
Jump to solution

Hi,

We had the same issue. We could figure out what's the Problem was in our Environment. We have all Systems (AD, Server OS, etc) in German. One Group of our test-user had a Umlaut "ä" inside. When we logged in we got the Error 500. Without this Group it's working. The user's Primary Group has also a Umlaut "ä" Domänen-Benutzer inside. But that's not really a Problem, than the Primary Group wouldn't be checked.

Reply
0 Kudos