Citrix XenApp users complain that when trying to launch an application in Storefront, the Citrix receiver starts the process only to end with a Windows message saying ‘Access is Denied’.
When checking in Citrix studio, you notice that the user has an active session with no applications running. When you check the XenApp server, you do not see that user having an actual session. However, you see a session(s) with the status down. When you try to end the process that is running under that session ID, you fail to end it.
Reinstall the VDA on your image. Many large Citrix customers concluded that any time you apply Windows updates or hypervisor tool upgrades, it is best to reinstall your VDA on your golden image as the last thing to do before sealing the image.
In the meantime, you can apply the workaround below to get your folks working.
The following workaround applies only when you have Citrix Studio registering sessions as active on XenApp servers that no longer exist on the XenApp servers themselves. For instance, you may see that the delivery controller states that user1 has an active session on XAServer1 but no application is running. When you go to XAServer1 and run query session /server:XAServer1, you find out that there is no session associated with user1 (maybe multiple session with the state down). If that’s the case for you, there are two immediate workarounds:
- Reboot the XenApp server, or
- Remove the session entry in the site’s database
Remove session entry in the site’s database
Make sure you have a working backup and restore procedure. Follow the steps below at your own risk:
- Login to your SQL server where your Citrix site database is located
- Run the following SQL query on that database (replace nameOf User and siteDatabaseName)
Use [siteDatabaseName] SELECT * FROM [chb_State].[Sessions] WHERE [chb_State].[Sessions].BrokeredSessionUid is NULL AND [chb_State].[Sessions].UntrustedUserSAMName like '%nameOfUser%'
3. Once you confirm that the user’s session exists in the database, proceed with deleting that row by running the following SQL query (replace domain\nameOf User and siteDatabaseName):
Use [siteDatabaseName] Delete from chb_State.Sessions WHERE chb_State.Sessions.UntrustedUserSAMName like 'domain\nameOfUser '
4. Confirm that you no longer see that session record in Citrix Studio
5. Ask the user to try to login again
6. You will still need to reboot the server to get rid of the down session later.
When you see sessions with down as their state, you may have a problem with your logoffs. TS sessions go through 5 stages:
- ConnectQuery (ConnQ)
- Connect (Conn)
- Disconnected (Disc)
The down stage is the last one before the session is destroyed. Sometimes, Windows fails to end a process (for example csrss.exe). Thus, the session stays in the down state. However, the VDA thinks that the session is still there and keeps the record alive when the user tries to get his or her session brokered again. Once that happens, the delivery controller redirects the user to the ‘faulty’ XenApp server, Windows interprets the action as if a user is trying to access a session that does not belong to them. Hence, the ‘access is denied’ message.
You should also check the process name lingering behind and add it to the CheckSysLogoffModule registry published under Citrix support page CTX891671.