szilagyic
Hot Shot
Hot Shot

AppVol agent error code 500 after upgrading to 2.12 from 2.11

Jump to solution

Hello:

We just upgraded from AppVol 2.11 to 2.12, because of the bugs in 2.11 related to Windows 10 1607.  It appears that 2.12 forces SSL (port 443) now.  Not a big deal, however after upgrading none of our agents will connect to the AppVol manager now.  They get the error "Connection Error... error code 500... Unable to contact App Volumes Manager.  Virtualization is disabled".

In the AppVol manager, I can see the PCs connecting, but the AppStacks and Writable Volumes are not attaching in the VMs.

Has anybody seen this issue?  I am opening a ticket with VMware as there doesn't seem to be any information on this error.

Thank you.

1 Solution

Accepted Solutions
Ray_handels
Virtuoso
Virtuoso

Right now we're trying to work around the 500 error on the VMs that we use for capturing apps for AppStacks.  We had been installing those apps as the local administrator account.  My thought was so that the AppStack doesn't contain other user profile folders in them.  I am hoping that it does NOT capture the user's profile folder but I will have to test this more and I will post back my findings, unless somebody else knows what the best practice is for creating AppStacks.

Nail -- Hammer -- Head Smiley Happy Smiley Happy.

I saw the exact same thing but we already had a few applications that needed to be packaged as a domain account so we just have to make sure to use an account that doesn't have any assignments and we are good to go. And just so you know, Appstacks DO NOT contain any profile information. It doesn't contain any user related settings or files for that matter. All and everything that is created in c:\Users or HKCU is not being stored in the Appstack. For as far as I'm concerned looking at it as a packager this is good news. You get clean application installations. Only downside is that you still have those occasional developing idiots that store the application in the %APPDATA% "because a user has permissions there"..

Regarding the writable volume. Normally the only thing that changes in the writable template is the snapvol.cfg which only holds info on what to store and what not to store in the writable and the version number (which is a txt file Smiley Happy). We did test with my very old 2.6 template (yes, we still have some of those Smiley Happy) and it worked quite well to be honest. svservice however is a different thing. It could be that filter drivers changed and the snapvol.cfg needs to be changed. If this is the case you can still update the writable by using the manager. If so, could you please let us know? Looking at upgrading to 2.12 in a few weeks Smiley Happy.

View solution in original post

0 Kudos
13 Replies
Ray_handels
Virtuoso
Virtuoso

Did you use the same name in the Agent installer than the name of the official certificate? And do you have a correct certificate?

What happens when you browse to the Appvolumes manager when on the golden image machine?

0 Kudos
JMHarris
Contributor
Contributor

I was getting the same message when logging in with local admin. after logging in with a domain admin account the message did not pop up.

0 Kudos
Ray_handels
Virtuoso
Virtuoso

Oke, you meant in the golden image.. In the new version if you don;t have a domain account that you log in with it can;t authenticate against Appvolumes and thus disables the client. I have seen the error multiple times but never new it was the 500 error.

Because machines you log onto are domain members it should work in production with the pooled machines.

0 Kudos
JMHarris
Contributor
Contributor

Also Check the firewall on your App Volumes Management server.

0 Kudos
szilagyic
Hot Shot
Hot Shot

Yes I have used the exact FQDN as used during the installation of AppVol Manager. We are using the default certificate with the manager.  I am also selecting the option during the agent installation to disable certificate validation.  We would prefer to use the default certificate if that is possible.

I am not sure what you mean about "browsing" to the AppVol Manager from the golden image machine, I can connect and log in via a web browser just fine.  I do get the cert warning in IE but continue past that.

0 Kudos
szilagyic
Hot Shot
Hot Shot

Thank you for the replies.

I am able to connect to the AppVol manager admin via port 443/SSL from a browser so the services and firewall seem to be OK on the manager server.

OK I have found that when logging in as a domain user, I no longer am getting the 500 error.  Interesting.  We would prefer to use the local Administrator account if possible from a capturing VM (creating AppStacks).  It has always worked in the past.  To me that would seem the cleanest way to do it but I guess we can work around it if needed.

Now that we are no longer getting the 500 error with a domain account, I tried recomposing a test pool with the new AppVol 2.12 agent.  When the domain user is logging in to their VDI session, the connection to the VM is terminated while it is logging in to Windows 10.  The user sees the login process start, but during it, the connection is terminated and the user cannot connect to it after that.  If I remove the AppVol agent and recompose, the login works just fine.  So it appears there is still an issue with the AppVol agent and whatever it is doing at logon.  I'm now looking at this issue.

Thanks again for the help.

0 Kudos
Ray_handels
Virtuoso
Virtuoso

I'm not 100% sure about this to be honest but my guess is that Appvolumes Agent checks to see if the certificate is correct when it connects. So if you browse to the manager from your golden image it should not give you the warning message.

That being said. As said, we use a local administrator account to create the golden image and I just ignore the error and leave it be.

When I then create the pool and the machines are in the domain and I use a domain account I don't get the message everything works as intended.

0 Kudos
szilagyic
Hot Shot
Hot Shot

Thanks for the reply.  Yes, I think the appvol agent does check the cert if you don't uncheck the certificate validation checkbox that now shows up during the agent installation.  I checked that box, and I have not been experiencing any certificate issues at all.  The agent is able to connect to the manager just fine.

I found yesterday after many hours of testing, that the disconnect issue we were seeing was being caused by something with the user's Writable Volume.  When we deleted the Writable Volume, and re-created it, things are now working.  In fact, this solved some other issues we were having with Office 2016 also.  I'm not sure if they updated the templates with 2.12, but it seems to have fixed a few things.

Right now we're trying to work around the 500 error on the VMs that we use for capturing apps for AppStacks.  We had been installing those apps as the local administrator account.  My thought was so that the AppStack doesn't contain other user profile folders in them.  I am hoping that it does NOT capture the user's profile folder but I will have to test this more and I will post back my findings, unless somebody else knows what the best practice is for creating AppStacks.

Ray_handels
Virtuoso
Virtuoso

Right now we're trying to work around the 500 error on the VMs that we use for capturing apps for AppStacks.  We had been installing those apps as the local administrator account.  My thought was so that the AppStack doesn't contain other user profile folders in them.  I am hoping that it does NOT capture the user's profile folder but I will have to test this more and I will post back my findings, unless somebody else knows what the best practice is for creating AppStacks.

Nail -- Hammer -- Head Smiley Happy Smiley Happy.

I saw the exact same thing but we already had a few applications that needed to be packaged as a domain account so we just have to make sure to use an account that doesn't have any assignments and we are good to go. And just so you know, Appstacks DO NOT contain any profile information. It doesn't contain any user related settings or files for that matter. All and everything that is created in c:\Users or HKCU is not being stored in the Appstack. For as far as I'm concerned looking at it as a packager this is good news. You get clean application installations. Only downside is that you still have those occasional developing idiots that store the application in the %APPDATA% "because a user has permissions there"..

Regarding the writable volume. Normally the only thing that changes in the writable template is the snapvol.cfg which only holds info on what to store and what not to store in the writable and the version number (which is a txt file Smiley Happy). We did test with my very old 2.6 template (yes, we still have some of those Smiley Happy) and it worked quite well to be honest. svservice however is a different thing. It could be that filter drivers changed and the snapvol.cfg needs to be changed. If this is the case you can still update the writable by using the manager. If so, could you please let us know? Looking at upgrading to 2.12 in a few weeks Smiley Happy.

View solution in original post

0 Kudos
szilagyic
Hot Shot
Hot Shot

I saw the exact same thing but we already had a few applications that needed to be packaged as a domain account so we just have to make sure to use an account that doesn't have any assignments and we are good to go. And just so you know, Appstacks DO NOT contain any profile information. It doesn't contain any user related settings or files for that matter. All and everything that is created in c:\Users or HKCU is not being stored in the Appstack. For as far as I'm concerned looking at it as a packager this is good news. You get clean application installations. Only downside is that you still have those occasional developing idiots that store the application in the %APPDATA% "because a user has permissions there"..

Thank you for the clarification.

My co-worker tried capturing apps yesterday as the local Administrator account and confirmed that it still works, despite the 500 error message that comes up.  so I think we are good to go.

I also had a ticket open with VMware on this issue and they said engineering is looking at reverting the agent back to the old behavior of allowing the local accounts to log in without the error.

thanks!

VDIMega
Enthusiast
Enthusiast

I see the 500 error when I log in as a local user account instead of domain, but nothing actually seems broken.  We're ignoring it for now unless it starts happening for domain users.

0 Kudos
etamir
Enthusiast
Enthusiast

Hi,

Well I have bumped into this today as well...error 500 with Virtualization Disabled...

Opened a support case with VMware...they told me that this is a known issue and being worked on by Engineering.

In the meantime, the suggested to add a registry value to suppress this message...(basically ignore for now)

========================================================

Before or after Agent 2.12 installation, ensure VM's are joined to the Domain.

  • Once 2.12 agent is installed go to regedit>HKLM\System\CurrentControlSet\services\svservice\Parameters.
  • Set the following key EnforceSSLCertificateValidation - to a value of 0
  • Restart the VM

   

  • Login as a user with apstacks assigned and see if applications appear as normal.
  • If error message is still present at this point go to regedit>HKLM\System\CurrentControlSet\services\svservice\Parameters.
  • Create a new DWORD key and name it HidePopups and set it to a value of 1

========================================================

Hope this helped...

etamir
Enthusiast
Enthusiast

Hi,

Well I have bumped into this today as well...error 500 with Virtualization Disabled...

Opened a support case with VMware...they told me that this is a known issue and being worked on by Engineering.

In the meantime, the suggested to add a registry value to suppress this message...(basically ignore for now)

========================================================

Before or after Agent 2.12 installation, ensure VM's are joined to the Domain.

  • Once 2.12 agent is installed go to regedit>HKLM\System\CurrentControlSet\services\svservice\Parameters.
  • Set the following key EnforceSSLCertificateValidation - to a value of 0
  • Restart the VM

   

  • Login as a user with apstacks assigned and see if applications appear as normal.
  • If error message is still present at this point go to regedit>HKLM\System\CurrentControlSet\services\svservice\Parameters.
  • Create a new DWORD key and name it HidePopups and set it to a value of 1

========================================================

Hope this helped...