VMware Horizon Community
pchapman
Hot Shot
Hot Shot
Jump to solution

App Volumes Invalid Session Cookie

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:

pastedImage_0.png

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?

Reply
0 Kudos
1 Solution

Accepted Solutions
himcrucified
Enthusiast
Enthusiast
Jump to solution

One of the VMware support techs changed something in our database: disable_agent_session_cookie = 1

You might call in and ask about it. So far it has worked for us.

View solution in original post

26 Replies
Lakshman
Champion
Champion
Jump to solution

Could you check if this error occurs for Domain users or Non-domain users?

If it occurs only for Non-domain users, turn on the setting ""Allow non-domain entities" under the Configuration > AD Domain page and check if that helps.

Reply
0 Kudos
pchapman
Hot Shot
Hot Shot
Jump to solution

Hmm, I don't really have any non-domain users to test with, aside from the local admin (which I've never seen the error on)

Could it be because these desktops exist in one domain, but the users exist in a different domain? (There is a two-way trust between them)

Example: Desktops computer accounts exist in Domain A, but users from Domain B login to the desktops in Domain A.  Both domains are configured in AppVolumes manager.

It happens very infrequently but it is enough to be worried.

Reply
0 Kudos
Lakshman
Champion
Champion
Jump to solution

As you mentioned that both domains are configured in App Volumes, I don't think it could be a domain or trust issue.

Next time when you hit this issue, please collect manager and agent logs and post it here.

Reply
0 Kudos
Tyson_Then
VMware Employee
VMware Employee
Jump to solution

I'm also seeing this issue. Am going to gather the logs and upload when possible.  Raising an SR and will return when more is known.

Reply
0 Kudos
jmatz135
Hot Shot
Hot Shot
Jump to solution

I see this issue too occasionally.  Only one domain.  All domain users.  Seems to be happening after updating everything to 2.14.  I'll have to try to get logs when it happens.

Oddly, all appstacks seems to attach even when the error occurs and it doesn't seem to cause issues, but I can't be sure everything is working properly.

Reply
0 Kudos
Hofkicks
Enthusiast
Enthusiast
Jump to solution

Same issue, although I do use F5 for Load Balancing Appvolumes. Setup is done according to https://www.f5.com/pdf/solution-center/f5-big-ip-vmware-app-volumes-integration-guide.pdf

Load Balancing persistence is set to Source Address Affinity as stated in the configuration guide.

Reply
0 Kudos
Kevinvdi
Contributor
Contributor
Jump to solution

Hello,

If you are using a LB, you can check request sent to it with year-day-hour.

Kevin

Reply
0 Kudos
cgrubbe
Enthusiast
Enthusiast
Jump to solution

Ran into the same error.  In our environment it looks like it was something to do with the AppVol Manager connecting to DC's in a separate site from where the VM's were running. Updated AD config to point to specific DC's at same site as VM's and error cleared up.

Reply
0 Kudos
JohnFLi
Enthusiast
Enthusiast
Jump to solution

I am having this same issue.

I am only testing horizon and app volumes, as a result, I tried calling support, but they said that since I didn't buy it yet, they aren't going to help at all.  

Anyway...... in the app volumes/activity/system messages i get the message saying  "[Session Auth] Invalid session cookie: Session key does not match any active sessions"

On the clone, I get a different errors.   for example:

"error from Manager  <FQDN here>" [error code 400]   Unable to locate the machine making this request on the hypervisor"

client log:

[2018-09-17 17:53:26.869 UTC] [svservice:P1136:T3440] ReadOutVolsFromString: NewVolumes 1 TotalVolumes 1

[2018-09-17 17:53:26.869 UTC] [svservice:P1136:T3440] ReadOutVolsFromString: Manager has asynchronous loading of volumes turned on

[2018-09-17 17:53:26.869 UTC] [svservice:P1136:T3440] ReadOutVolsFromString: volume path:"g1ptesx14-localstorage-1\cloudvolumes\apps\Notepad_7.5.8.vmdk" guid:"{1bf47220-e928-4ece-a1d7-c4a6aa9aaa1e}" type:"MOUNTED-READ"

[2018-09-17 17:53:26.869 UTC] [svservice:P1136:T3440] SvdPushReorderEntry: Sent reorder entry to filter {1bf47220-e928-4ece-a1d7-c4a6aa9aaa1e} (UserVolume: 1; Writable: 0)

[2018-09-17 17:53:26.869 UTC] [svservice:P1136:T3440] ReadOutVolsFromString: add AppStack to load order list:"{1bf47220-e928-4ece-a1d7-c4a6aa9aaa1e}"(1)

[2018-09-17 17:53:26.869 UTC] [svservice:P1136:T3440] ReadOutVolsFromString: invalid command:"ASYNC"

[2018-09-17 17:53:26.869 UTC] [svservice:P1136:T3440] LogonMount: agent:0 manager:1 volume(s) to attach

[2018-09-17 17:53:26.900 UTC] [svservice:P1136:T3440] Activate filtering (called by WaitVolumesLoading)

[2018-09-17 17:53:26.900 UTC] [svservice:P1136:T3440] WaitVolumesLoading: waiting for 1 total volume(s), 0 processed, max wait 180

[2018-09-17 17:53:26.900 UTC] [svservice:P1136:T3440] WaitVolumesLoading: Wait for first volume only is 1

[2018-09-17 17:53:26.900 UTC] [svservice:P1136:T3440] Releasing user logon, (Writable present: 0; Writable processed: 0)

[2018-09-17 17:53:26.900 UTC] [svservice:P1136:T3440] SvdSetReorderCounter: set to 0

[2018-09-17 17:53:26.900 UTC] [svservice:P1136:T3440] HttpUserLogin: succeeded (user login)

[2018-09-17 17:53:26.900 UTC] [svservice:P1136:T3440] OnLogon : succeeded

[2018-09-17 17:53:26.900 UTC] [svservice:P1136:T1408] MeasureTime::RecordCenter: Start recording  GUID:{52877c63-0000-0000-0000-501f00000000} Type:0

[2018-09-17 17:53:26.900 UTC] [svservice:P1136:T1408] Preload volume event (startup): "\Device\HarddiskVolume2" GUID {52877c63-0000-0000-0000-501f00000000} Hive  (0 logged in, SystemVolume 1, VolumeType 0)

[2018-09-17 17:53:26.900 UTC] [svservice:P1136:T1408] Sending reply to SVCMD_ID_NEW_VOLUME_PRE (Message 3, Size 24)

[2018-09-17 17:53:26.900 UTC] [svservice:P1136:T1860] WaitVolumesLoadingWorker: waiting for 1 total volume(s), 0 processed, max wait 180

[2018-09-17 17:53:27.916 UTC] [svservice:P1136:T1860] Waiting for 1 new volumes before resetting order (0 processed, waited 1 second(s) so far)

[2018-09-17 17:53:28.932 UTC] [svservice:P1136:T1860] Waiting for 1 new volumes before resetting order (0 processed, waited 2 second(s) so far)

[2018-09-17 17:53:29.947 UTC] [svservice:P1136:T1860] Waiting for 1 new volumes before resetting order (0 processed, waited 3 second(s) so far)

[2018-09-17 17:53:30.963 UTC] [svservice:P1136:T1860] Waiting for 1 new volumes before resetting order (0 processed, waited 4 second(s) so far)

[2018-09-17 17:53:31.979 UTC] [svservice:P1136:T1860] Waiting for 1 new volumes before resetting order (0 processed, waited 5 second(s) so far)

[2018-09-17 17:53:32.338 UTC] [svservice:P1136:T3440] OnStartShell called (Session ID 1, Handle 0000029AB3D67D90, Params 000000F313EFE798, Context 0000000000000000)

[2018-09-17 17:53:32.338 UTC] [svservice:P1136:T3440] OnStartShell: FIREMOUNTAIN\litsterj.test (NameSamCompatible)

[2018-09-17 17:53:32.338 UTC] [svservice:P1136:T3440] HttpFileShareRequest WinHttp over SSL is disabled. Log collection to file share not supported.

[2018-09-17 17:53:32.338 UTC] [svservice:P1136:T3440] handleFileShareStr: File share info received from manager is empty.

[2018-09-17 17:53:32.338 UTC] [svservice:P1136:T3440] OnStartShell: Error Failed to Start DCT Logger

[2018-09-17 17:53:32.994 UTC] [svservice:P1136:T1860] Waiting for 1 new volumes before resetting order (0 processed, waited 6 second(s) so far)

[2018-09-17 17:53:34.010 UTC] [svservice:P1136:T1860] Waiting for 1 new volumes before resetting order (0 processed, waited 7 second(s) so far)

[2018-09-17 17:53:35.041 UTC] [svservice:P1136:T1860] Waiting for 1 new volumes before resetting order (0 processed, waited 8 second(s) so far)

[2018-09-17 17:53:36.057 UTC] [svservice:P1136:T1860] Waiting for 1 new volumes before resetting order (0 processed, waited 9 second(s) so far)

[2018-09-17 17:53:37.072 UTC] [svservice:P1136:T1860] Waiting for 1 new volumes before resetting order (0 processed, waited 10 second(s) so far)

[2018-09-17 17:53:38.104 UTC] [svservice:P1136:T1860] Waiting for 1 new volumes before resetting order (0 processed, waited 11 second(s) so far)

[2018-09-17 17:53:39.119 UTC] [svservice:P1136:T1860] Waiting for 1 new volumes before resetting order (0 processed, waited 12 second(s) so far)

[2018-09-17 17:53:40.135 UTC] [svservice:P1136:T1860] Waiting for 1 new volumes before resetting order (0 processed, waited 13 second(s) so far)

[2018-09-17 17:53:41.150 UTC] [svservice:P1136:T1860] Waiting for 1 new volumes before resetting order (0 processed, waited 14 second(s) so far)

[2018-09-17 17:53:42.213 UTC] [svservice:P1136:T1860] Waiting for 1 new volumes before resetting order (0 processed, waited 15 second(s) so far)

[2018-09-17 17:53:43.244 UTC] [svservice:P1136:T1860] Waiting for 1 new volumes before resetting order (0 processed, waited 16 second(s) so far)

[2018-09-17 17:53:44.260 UTC] [svservice:P1136:T1860] Waiting for 1 new volumes before resetting order (0 processed, waited 17 second(s) so far)

[2018-09-17 17:53:45.275 UTC] [svservice:P1136:T1860] Waiting for 1 new volumes before resetting order (0 processed, waited 18 second(s) so far)

[2018-09-17 17:53:46.291 UTC] [svservice:P1136:T1860] Waiting for 1 new volumes before resetting order (0 processed, waited 19 second(s) so far)

[2018-09-17 17:53:47.307 UTC] [svservice:P1136:T1860] Waiting for 1 new volumes before resetting order (0 processed, waited 20 second(s) so far)

[2018-09-17 17:53:48.322 UTC] [svservice:P1136:T1860] Waiting for 1 new volumes before resetting order (0 processed, waited 21 second(s) so far)

[2018-09-17 17:53:49.338 UTC] [svservice:P1136:T1860] Waiting for 1 new volumes before resetting order (0 processed, waited 22 second(s) so far)

[2018-09-17 17:53:50.354 UTC] [svservice:P1136:T1860] Waiting for 1 new volumes before resetting order (0 processed, waited 23 second(s) so far)

[2018-09-17 17:53:51.369 UTC] [svservice:P1136:T1860] Waiting for 1 new volumes before resetting order (0 processed, waited 24 second(s) so far)

[2018-09-17 17:53:52.385 UTC] [svservice:P1136:T1860] Waiting for 1 new volumes before resetting order (0 processed, waited 25 second(s) so far)

[2018-09-17 17:53:53.400 UTC] [svservice:P1136:T1860] Waiting for 1 new volumes before resetting order (0 processed, waited 26 second(s) so far)

[2018-09-17 17:53:54.416 UTC] [svservice:P1136:T1860] Waiting for 1 new volumes before resetting order (0 processed, waited 27 second(s) so far)

[2018-09-17 17:53:55.432 UTC] [svservice:P1136:T1860] Waiting for 1 new volumes before resetting order (0 processed, waited 28 second(s) so far)

[2018-09-17 17:53:56.447 UTC] [svservice:P1136:T1860] Waiting for 1 new volumes before resetting order (0 processed, waited 29 second(s) so far)

[2018-09-17 17:53:57.463 UTC] [svservice:P1136:T1860] Waiting for 1 new volumes before resetting order (0 processed, waited 30 second(s) so far)

[2018-09-17 17:53:57.463 UTC] [svservice:P1136:T1860] [0] Connecting to g1vtgbi02.firemountain.local:80 using HTTP (attempt 1)

[2018-09-17 17:53:57.463 UTC] [svservice:P1136:T1860] WinHttpSendRequestWithSSLCertValidation: SSL certificate validation is disabled.

[2018-09-17 17:53:57.463 UTC] [svservice:P1136:T1860] WinHttpSendRequestWithSSLCertValidation: WinHttpSetOption(WINHTTP_OPTION_SECURITY_FLAGS) succeeded.

[2018-09-17 17:53:57.525 UTC] [svservice:P1136:T1860] WinHttpSendRequestWithSSLCertValidation: WinHttpSendRequest succeeded.

[2018-09-17 17:53:57.525 UTC] [svservice:P1136:T1860] HttpReadAllAvailableData: Error 0 in WinHttpQueryDataAvailable: dwSize 0

[2018-09-17 17:53:57.525 UTC] [svservice:P1136:T1860] HttpInitializeRequest: Manager status 200 response (9 bytes): !FAILURE!

[2018-09-17 17:53:57.525 UTC] [svservice:P1136:T1860] SendMountConfirmationRequest: Volume mount-confirmation failed. Volumes will not be mounted.

Reply
0 Kudos
dkhillman
Contributor
Contributor
Jump to solution

We are in a trial and having the same issue as well.  Has anybody found a solution yet?  Thanks

Reply
0 Kudos
JohnFLi
Enthusiast
Enthusiast
Jump to solution

I hope that I am able to help...Yesterday I got it working.

First...I had to uninstall App Volumes.
Upon re-install, I had it choose to talk directly with vsphere....before I had it talking with 1 specific host.

ALSO

when setting up the storage (during app vol install) I had selected the volume to have the templates etc on, {that was fine} BUT...on that page there is also a drop down box.   I was selecting a host in that drop down box becasue I thought it was nessesary(why else would it be there?)   leave that drop down box blank.

What had been happening (it could be 1 or more than one of these reasons) becasue I had set it up for everything to be on 1 host, and originally set it to use the local storage on the same host.....the VDI clone machines would ONLY work if they happened to be residing on that host as well.   (I didn't think about looking to see where the clone was residing.)

And for the client, when you install it...use the FQDN and port 443, even if on the app vol manager you selected 443 AND 80.

Hope that helps.

Reply
0 Kudos
aperez140
Contributor
Contributor
Jump to solution

I also have two domains, and just recently started receiving the errors. Found that my virtual desktops DHCP was getting set to other domain DCs. I manually updated the domain controllers in the virtual desktop network properties to point to the preferred domain controllers ip addresses and the horizon agents were reachable again and the error messages cleared in app vol logs. This is just a pilot though. I wouldn't want to do this for a greater amount. More troubleshooting on the back end!

Reply
0 Kudos
MartinHLarsen
Contributor
Contributor
Jump to solution

Same issue here "Invalid session cookie", The strange thing is that it only happens in our 4 vGPU pools. (nvidia Kepler & Pascal)

The first workaround we made was not to "Allow reuse of pre-existing computer accounts". You need to go directly into the ADAM DB and disable this setting, as the checkmark in the "edit -> guest customization" in horizon admin does not work for instant clone pools! Follow this KB VMware Knowledge Bas

Another workaround is Disabling  "Disable Token AD query"  Found in appvolumes manager -> configuration -> Disable Token AD Query and disable NTLM in appvolumes by using this guide Disable Microsoft Windows NTLM Authentication

We have been working with Support for three weeks, and so far no real solutions from vmware.

It all worked before upgrading to appvol 2.14 and Horizon 7.5

Reply
0 Kudos
himcrucified
Enthusiast
Enthusiast
Jump to solution

One of the VMware support techs changed something in our database: disable_agent_session_cookie = 1

You might call in and ask about it. So far it has worked for us.

Hocshop
VMware Employee
VMware Employee
Jump to solution

Hi JohnFLi,

Just in case you never heard anything back regarding this, I too have seen the same errors.

I have the multi-site set-up so 2 AppVol Mgrs in both sites.

The priority is always to connect to the 2 AppVol Mgrs in the primary site first and only go to the 2 AppVol Mgrs in the secondary site if the ones in the primary site are not responding.

So my redundancy test was to shutdown the 2 AppVol Mgrs in the primary site.

I was getting the above errors.

To solve the "error from Manager  <FQDN here>" [error code 400]   Unable to locate the machine making this request on the hypervisor" error, I just added the vCenter of the other site as an additional Machine Manager in each AppVol Mgr i.e. in site 1 I added the vCenter from site 2 as an additional Machine Manager and vice-versa.

Then I could do the test successfully but with one strange behavior.

If I now log on to a standalone (not part of a pool) desktop that points to the LB IP of the AppVol Mgrs then the appstacks connect without any problems.

However if I try to do the same test using the same configurations, same subnet etc from a Horizon desktop pool desktop, I see the err about the session cookie.

I believe it to be something related to AD or a cache in the AppVol Mgr however I will keep troubleshooting.

Hopefully my tip about the Machine Managers helps someone.

Cheers

Reply
0 Kudos
JohnFLi
Enthusiast
Enthusiast
Jump to solution

Thank you for the suggestion.

I thought I had already posted the solution for my issue, but in case I didn't....

I had my Vol Manager installed on a local host store (which i hadn't noticed) and the VM's that were on shared storage couldn't talk to it.

found out that it was only working when the VM's happened to be residing on the same host that manager was on.

After removing and re-installing everything related to appVol on shared storage, everythign started working as expected.

Reply
0 Kudos
Natestack
Enthusiast
Enthusiast
Jump to solution

Hi All,

Sorry, for reviving an old thread

We are experiencing this issue as well.
It is strange I can log on 20 times no worries and you get the odd 401-error invalid session cookie.

Note we using Appvolumes 2.16
Fresh Appvol install

Any ideas ?

Thanks,

Reply
0 Kudos
jmatz135
Hot Shot
Hot Shot
Jump to solution

I don't know if it fully solved it but I noticed a decrease when I changed the vCenter Settings from within App Volumes Manager to uncheck the Use local copies of volumes and use queues for mount operations.

Reply
0 Kudos
vdi2777
Enthusiast
Enthusiast
Jump to solution

Hi Natestack,

we have the same problem since we upgraded our AppVolumes Manager in a test environment. I'm currently testing if this occurs only when you upgrade the AppVolumes Manager and also when you you are using an existing database.

I will post my results here.

Kind regards,

Markus

Reply
0 Kudos