My organization has been working to prepare our Horizon environment for several months and begin pushing the product into production. To give you some background, we are sticking with mainly instant-clone sessions and are running version 7.9 of the Horizon Agent and Connection Server. Testing so far has been great, and we are nearly ready to roll out to production. The final issue I am facing revolves around instant-clone desktop sessions and Cisco Jabber. For the past several weeks I have struggled to get Jabber to retain any login data once a user's session is terminated and they start a new one. The user is always prompted to log back in again when starting a brand new session. I have searched all over for answers, but can't seem to find anything conclusive. My golden image is running v.12.7 of Cisco Jabber (have tried multiple different older versions, still with no luck). In UEM (v.9.8), I have configured the following settings:
For troubleshooting purposes, I have also configured a Folder Redirection rule for <AppData>\Cisco\Unified Communications\Jabber even though this folder is already being referenced in the above screenshot:
After configuring these settings, I start a new session, log into Jabber with a test user's account, then log out of the desktop session. I check to make sure the redirection settings are available at the remote path I specified above and can confirm that they are:
I log back into a new desktop session to find that the above folder is not actually being redirected, though the rules I set seem to be working (not sure if UEM is supposed to redirect the data or if it just reference it real time from the remote path specified in the rule? Just thought it was odd that I'm not seeing it being pulled down locally, as I thought that was the entire point of redirection in UEM):
Can anyone confirm that this is normal behavior in UEM? Or should I be seeing "\Unified Communications\Jabber\CSF" directories under this path based off the redirection rule I have set above?
Also, we confirmed with further troubleshooting that everything is configured correctly via CUCM and CUPS with Jabber. We've been using it in our environment for the last several years with no issues. Any local machine in our environment not currently using Horizon logs in automatically as expected. This issue only presents itself in the Horizon environment when using an instant-clone desktop pool. Which leads me to believe that this is something I'm missing in UEM.
To add to the confusion even more, when I log in with my AD credentials into the exact same desktop pool and launch Jabber, I am logged in automatically and everything works without issue. All of the same conditions above apply, including not seeing any of the Unified Communications\Jabber\CSF under the AppData\Roaming folder. I have tested this with several other users in our IT department, all of which belong to similar AD groups and they are logged in automatically as well with no issue. This also leads me to believe that this could be due to some sort of permissions problem. Does Jabber require specific read/write permissions on any of the Appdata folders it creates? As far as I can see though, every user that logs in has full permission to those folders...
Any advice / help is greatly appreciated!
This is our DEM (UEM) Config for Jabber:
HKCU\Software\Cisco Systems, Inc.
DirectFlex is not enabled.
We have no Folder Redirections configured.
Same result, but you can see where UEM is capturing the settings for .sav file you're talking about. Launching Jabber after log in shows they are being modified (note the file time stamps and the system clock). It just doesn't make sense as to why Jabber isn't caching them.
We are Experiencing the same issues in our environment. Horizon 7.8 and UEM 9.7. Below is our UEM config for Jabber.
HKCU\Software\Cisco Systems, Inc.
Sorry, should have updated the article after finding the fix. Strange enough, I completely removed the Personalization settings I had for Jabber and started from scratch. Our environment currently looks like this:
HKCU\Software\Cisco Systems Inc.
Everything has been working fine ever since recreating the config, but I'm still unsure of why the problem happened in the first place.