App Volumes Invalid Session Cookie

[pchapman]

Hi,

I am working on a new implementation of AppVol 2.14 on an instant clone desktop pool.

Occasionally while logging in, I get the following message:

Invalid session cookie:

Can anyone tell me what this means? 

It is a fairly simple setup.  floating instant clone pool with the 2.14 agent on it.  There are two AppVolumes managers on the network, which are not load balanced.  Instead, for this environment multiple AppVolumes managers are defined in the registry under Manager1 and Manager2 reg keys.

Is this related to the instant clone refresh process?  Is there any way to fix it?

[pchapman]

I can confirm that this fixed the issue (disable_agent_session_cookie = 1 in the database), I opened a support case and they provided the instructions.  They said it is due to using Instant Clones with vGPU, since there is an extra reboot involved in that specific use case, it throws off App Volumes manager.  It's too bad this isn't documented in the KB anywhere, since I imagine it's a fairly common scenario.  Still applies to 2.16...

[vdi2777]

Hi pchapman,

we are also using m10 graphics so it would match but we got the error after upgrading to 2.16. The versions before are working fine..

Is there any impact by disabling the session cookie in the database?

Thanks,

Kind regards,

Markus

[pchapman]

Vmware didn’t mention the implications of configuring the setting.  i would suggest opening a support ticket and asking.  It’s interesting that you didn’t see the issue before 2.16 though.

[vdi2777]

Ok i will do that, thanks. That's the point because we wanted to upgrade our productive appvolumes manager to 2.16 in 2 weeks so i need to clarify the issue.

Kind regards,

Markus

[vdi2777]

I got an answer from VMware and wanted to let you guys know:

"Yes that article is correct, you can avoid the 'Invalid Session Cookie' issue by utilizing NTLM authentication for Agent-Manager communications. To do so:

- Access the 'settings' table in the App Volumes database
- Add a row with the following values (or update the row if the key already exists):
key: "disable_agent_session_cookie"
value: "1"

The reason it's failing in 2.16 and not the older version you're using, is because the session cookie is a new feature of 2.14.

No there won't be an impact from disabling it. When it's disabled your users will be using NTLM to authenticate.

NTLM is recommended and it is how AV authenticates the VMs connecting to it. The fix mentioned above, which involved setting "disable_agent_session_cookie" to 1 in the SQL DB, does not disable the use of NTLM.

It disables the use of the session cookie. That means every connection between the VM and AV will go through an NTLM handshake process. The cookie is an optimization that can be disabled if there are problems like what you were seeing.

We create an authorized session for each computer based on a triplet of computer info (ex: computer name), VM info, and a unique session key. Only one unique session key is allowed to be valid at a time.

I've seen this issue previously, and the problem was caused by a combination of two behaviors in an environment:

1) vGPU use requiring a power cycle which, in turn, on AV side triggers generating a new session key
2) re-using the computer name which causes naming collisions with the newly generated session key (since only one can be valid at a time per computer name)."

Kind regards,

Markus

[jmatz135]

2) re-using the computer name which causes naming collisions with the newly generated session key (since only one can be valid at a time per computer name)."

Like every non-persistent VDI desktop pool that ever existed.  The exact thing in which App Volumes was designed to deploy applications to.  This is just mind boggling  how they don't seem to see this as a possible issue.

[Barker2015]

Agreed jmatz135.

This is completely ridiculous that their "fix" for it requires modifying the underlying database structure.  I'm just rolling back to a previous version.

[EDIT] I just tested this "fix" and while my app volumes are now stacking, now I can't launch any programs that require GPU acceleration.  I don't even understand how this is related, particularly since the applications I'm trying to launch aren't even on appvols (they are installed on the instant clone directly).  Rolling back to version 2.15.0.41 fixes both the issues for us.  I'm not sure if there is a later version that would fix this as that was the previous version we were on, but I can't waste anymore time on this.  The newest version is already pretty old, and these comments go back a while, I'm guessing they aren't fixing it at this point.