Citrix Receiver icons disappear from the Receiver application

[J.R. van Doornik]

A curious problem that is occurring with one user on our network, and we're not really sure why it's happening.

 

When opening the Citrix Receiver application, you get the screen with the big circle, pointing to the '+' sign to add an application.

 

If the user hits that '+', and adds an icon, normally the icon is placed on the 'desktop' within the application.

 

In the case of this one user however, the icon is grayed out as it's placed on that 'desktop' and then disappears before it solidifies. Leaving the user with the same screen as he started with.

 

Wat we've done to troubleshoot this

• The user can log into the web interface, and start programs that way. So the Receiver is able to properly communicate with Citrix.
• We updated the Citrix Receiver to the last version (4.8 / 14.8.0)
• Removed the local user profile of the user (the user does not use a roaming profile)
• Let someone else log on to the users PC, and test this. The problem does not occur.
• Let the user log on to another PC that has no issues. The problem follows the user.

 

Based on the above, we're no longer looking at the profile of the user. There isn't a roaming profile, and even after removing and recreating the local profile the problem persists.

 

What we did find was that in the C:\Users\username\appdata\Local\Citrix\SelfService folder, there is a propagation of icons that persists even in a clean/new profile for the user. Of what I managed to track this is apparently coming from StoreFront (we have 2.5 active at the moment), but there is very little to no real information on what is happening here. Apparently StoreFront somehow provides the Citrix Receiver with information that trancends the Windows profile, and thus we're suspecting that this might have some cause in the original problem, tho we're guessing here.

 

While we did find a means to make an export of the subscription database in StoreFront, and I can find the SID of the user in there with a heap of references, it seems the only means to get rind of his data in the database is apparently to export the database, edit the export to remove the user, wipe the whole database from the server, let it recreate a completely new one, and import the edited export back in. Seeing we're not even sure this is the actual cause of the issue, to do this for one user and potentially hit the whole organisation is going a bit too far in my book.

 

If anyone has any thoughts on the matter, I would appreciate hearing them.

[J.R. van Doornik]

Found a solution for thos. And only because my colleague has some major debug logging (https://support.citrix.com/article/CTX132883) still going on another client for testing purposes regarding other issues.

 

We have a startmenu on the network for computers so we can control what application anyone gets in their start menu per workstation. This menu is located on a share that is read-only for all, except administrative users. Since the problem machine is a desktop, the GPO saw to it that the user did have the redirect in place.

 

In the logging it turned out the Receiver was doing three steps to get the icon in:

 

1) Subscription issued (which probably prods StoreFront to do it's thing in the database).

2) ICO file created in the %AppData% folder of the user, which is (I assume) the actual icon in the Receiver application.

3) Start menu is accessed and an icon/tile is created in there (to make the expirience seamless for the user).

 

Since step 3 (which in the Receiver application is not specifically setup, so this seems a default action) tries to write to a location on the netwerk which does not allow for writing, it fails. And Receiver apparently solves this by making the icon disappear instead of ignoring the seamless integration, and just allowing the icon to be shown.

 

Once we moved the user to a separate OU which took away GPO's that influenced this, and manually altered the registry to replace the redirection location with the local C:\Users\,usernam.\Desktop, the issue disappeared.

 

We by now have also managed to implement this on a more sustainable GPO based solution, and I've tried this on the workstation without any issues cropping up. So this is in our book the actual solution. Tho I'm not sure if this could be considered a bug in the Receiver application.

[J.R. van Doornik]

Nobody having any ideas as to the cause of this?

[J.R. van Doornik]

It remains quiet... Does that mean to entail nobody has any ideas what may be going on here, or how to go about resolving the issue?

[Sukhpreet Singh]

Hi J.R

 

A published app icon is only visible if the user is added to all two levels.

 

Delivery Group (Users page)- If the user is not assigned to the Delivery Group, then the user won’t see any application or desktop icon published from that Delivery Group. 

 

Limit Visibility – You can use the published app’s Limit Visibility page to restrict an icon to a subset of Delivery Group users.

[J.R. van Doornik]

That's just it. The user can start the app fine from the web interface, so he has the appropriate rights.

 

The user is even able to add the app in the Citrix Receiver (indicating the rights are supposedly the way they need to be), at which point it moves to be placed on the receiver desktop, and once in place you'd expect the icon to loose it's transparancy and become available for the user.

 

What happens however is that the icon disappears and the user is once again shown the Citrix Receiver screen with the big circle pointing to the '+' sign to the left.

 

As stated, just for this one user. His direct colleague (with the same rights) does not have the problem.

[Sukhpreet Singh]

HI J.R

 

looks like the subscription DB of store has corrupted for one user. Could you please follow the below:

 

1) Please create a new store, add this store to the receiver (Please clean up the receiver and install the latest version 4.9, before adding the store) and test the behavior with the user. 

(https://support.citrix.com/article/CTX137494) 

 

2) If still the issue is not resolved I would need the contents of Self Service folder for working and non- working user.

[J.R. van Doornik]

Sorry it took a couple of days to get back to this. Since the user is able to use the web interface to utilize Citrix, the urgency was somewhat lower, and I had a couple of things going on that needed my more immidiate attention.

 

That said, today I created a new store on StoreFront (as said before, our current version is 2.5), specifically for this user. I made it the same as the store used by the main-stream users, in so far the controllers and whatnot are involved.

 

Logged in as an administrator on the local users workstation, looked through the registry to see if I could change the store that way (and forego an update to 4.9 right off the bat), but couldn't find that. So went ahead, deinstalled the 4.8 receiver, ran the cleanup utility twice, rebooted, and ran the cleanup utility again just to make sure.

 

Despite some trouble (and multiple reinstalls being needed since the receiver wasn't behaving as I'd expect it to), I managed to curb the commandline that installed the receiver 4.9 properly, and allowed me to connect to the StoreFront server. Upon restarting I could start the desktop app, and it required me to logon as the user. After logon all my icons were shown under the left-hand '+' sign.

 

Clicking one of the icons (therefore adding it to the receiver-desktop) seemed to work, but turns out that this did nothing for the behavior of the issue. The icon gets moved onto the receiver desktop transparently, but rather than solidify, it fades off the desktop again.

 

So a new store, and the 4.9 version of the receiver have NOT had any noticable impact on the issue.

[Sukhpreet Singh]

Could you please share contents of Self Service folder for working and non- working user ?

 

Also, given the nature of issue and for quicker resolution, I would suggest to open a tech support case as well. 

[J.R. van Doornik]

Dropped a mail towards you...

[Sukhpreet Singh]

Hi J.R 

 

First of all, it is very strange that you are facing the issue with new store also. (It could be a bug, since you are using way too old storefront version 2.5 and there is a lot has been fixed since then).

 

Shared folders looks absolutely fine, however the below might help :

 

1) Export the DB, upgrade the Storefront to 3.x , clean the Database, and import back. 

 

2) What you could do is run a procmon on the client.  When you add the icon, look for any access denied file operations. 

 

3) Receiver Diag and storefront verbose logging. 

 

A technical support case is strongly advised for log analysis.  

[J.R. van Doornik]

Oh, believe me... I know version 2.5 is an old one. We're currently looking into builing a new XenApp environment (which is gonna take a while still), which includes a new StoreFront server. As such, we just want to keep the existing situation intact as much as possible.

 

1) This was already mentioned as a solution which we found at the start of this: https://docs.citrix.com/en-us/storefront/2-6/dws-manage/dws-manage-subscription-data.html

 

That's basically the same as you're proposing with the only difference being the upgrade to a newer version of StoreFront. The way we see this, this would down the database, and eventho we could wipe the offending entries for the problem user prior to importing again, this procedure has the potential to affect ALL the users. Which considering we only have 1 user expiriencing this problem at the moment seems like overkill.

 

I doubt it's a bug in 2.5, since I'd expect it to happen with more users, or sort itself out after a reboot of the StoreFront server. And this isn't the case. I concur it _might_ be the database records within the StoreFront database that are causing the issue, but the fact that you'd need to fully export/wipre/import seems like a huge oversight at Citrix in their product. Moreso, since it seemed to me that the latest versions of StoreFront still do not allow for any other method to clean stuff up.

 

And again, for one single user having issues, it seems like wiping and reimporting the database is somewhat overkill.

 

2) This might give some insight in what might happen under the hood. I'll have a go at that, and see what that dredges up.

 

3) Not familiar with that one... Any elaboration?

 

And as for the tech-support case... Already talked to Citrix support. Seems our contract does not include tech support (which we only found out after years of using the product and sorting just about everything about it out on our own), not even for the free-to--download Citrix Receiver (well, they will, if you have any XenDesktop/XenApp support).

 

Citrix is poised to change it's license structure come next year, forcing support on the customers, so as of that moment I shouldn't have an issue reporting the case in. But until then, I am not at liberty to pay for anything.

[J.R. van Doornik]

Opened Citrix Receiver, cleared the capture, the started it as I added an icon, which disappeared, before I closed the capture.

 

Filtered on 'Receiver.exe' as the process, and ended up with a list of events. Saved that one as a PML file.

 

Then added a new filter to remove all 'Success' notifications, and ended up with some 1600 events. Saved that file too. Most of those seemed to refer registry keys for Tcpip, so I added a filter to kill those as well, and ended up with 4 results.

 

c:\program Files\Citrix\Access Gateway\cltapi.dll

c:\program files (x86)\citrix\Access Gateway\cltapi.dll

c:\program files\citrix\secure access client\nscltapi.dll

c:\program files (x86)\citrix\secure access client\nscltapi.dll

 

All three have the same result (Path not found), and all three have the same detail error (Desired Access: Generic Read, Disposition: Open, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: N, ShareMode: None, AllocationSize: n/a

Logfile.zip

[J.R. van Doornik]

Based on your mailreply, got the ReceiverDiag application.

 

Started the Citrix Receiver, then the Diag application, initiated a start trace, duplicated the issue, and stopped the trace. Good for 10 seconds of logging.

 

Saved the file, and once at my workplace, opened https://cis.citrix.com/  - Said page logged me in with my Citrix account, and I was able to upload the log which was then auto-diagnosed and reported as having no issues. Not sure if you have a means to look into that log from your end, but I'm not sure what further to do with it.

 

As to the StoreFront logging... that's a bit more involved and will impact the users as I briefly recycle the applicable services. Which means I can't do this during the day, and will have to confer with my colleague to see if it's attainable to do that on short notice.

[J.R. van Doornik]

Based on the feedback from the Citrix Receiver application logging (which seems fine), and the fact that apparently running a debug on the provided log data from both the Receiver and StoreFront can only be done by a Citrix engineer (for which we are unable to raise a case, and thus have no access to), added to the fact that the StoreFront logging would be intrusive to the users at this time, we're not really convinced it might yield much. Even if it yields data in the log, it seems there is no real means for us to actually tease out this data without support from Citrix which is not attainable.

 

If you feel this assumption to be in error, please let me know, so we can see about proceeding with the StoreFront logging.

[Nalin Uduwawala]

Hi,

 

This is not an answer to your question (sorry), but we are having a similar sort of issue ( for which a call in logged with Citrix but they are just dragging their feet on it). So all admin level users get their icons populated to Desktop ( or a folder within desktop) and start menu. For non admin users, this doesn't happen. they have access to their apps within the workspace app but no icons are created. I can see the icons being created in the appdata\ roaming \citrix\.... folder as mentioned elsewhere in this discussion. We use windows 10 with GPOs to redirect folders etc.

 

So above is the behaviour with workspace 1912 LTSR and 2012 and 2103 versions. If we use Citrix receiver 3.3 and point to the new  cloud url, Citrix receiver faithfully creates the icons for users irrespective if they are admin / non admin users. In my opinion this is a workspace issue, but Citrix support Engineer seems to think it's a permissions issue.

 

I have not been able to find a single document that tell me how to tweak the Windows folder redirection engine to cater for this requirement.  

 

Any ideas from anyone here please?