Recently I upgraded Citrix Workspace Environment Management from v4.2 > 4.7.
The environment for this WEM installation is on-prem and is used across multiple forests (trusts in place), to apply the same settings to multiple different XenApp hosts.
At the beginning everything seemed to work as normal, brokering etc, agent comm etc, but the following issues soon appeared:
Issue 1:
In the admin console, going to Active Directory Objects, to add or edit users and groups for WEM, only the Group/user SID’s where showing.
Now that makes administration a somewhat bad experience for any person not walking around remembering the SID for everything around in AD.
The fun part was that editing any SID by opening, and clicking OK, got the name back.
Editing a SID, clicking Yes on the warning:
Clicking OK without changing anything on the editet Group/user:
After OK, the name is resolved:
So, for the console to show correct, I had to do this to every SID not resolving the name – boring – but then everything was ok, until the console got closed and opened again…
So this became somewhat I more irritating issue.
I logged a case with Citrix support to get them to investigate the issue and collecting some logs for them to look at. (For locations for WEM logs: https://support.citrix.com/article/CTX228742 )
(Only thing clearly showing in one of the logs was that WEM got an error regarding some Domain trust that had not been cleaned away when that domain had been taken out of production).
After some back and forth in the ticket dialog, we got together and decided to take a look via GoToMeeting, where I got to share my screen with the technician at Citrix.
Of course, that day, the issue was gone, so I logged the following changes that had been made from my part, since the last time the issue showed itself, and the following had been done in the backend.:
– Old trust had been removed – no longer generating that error.
– WEM broker moved from 2012r2 > 2016 server – issue still persists.
– An extra WEM 2016 Broker was set up, and Load Balancing via NetScaler was setup.
Still not certain which one solved the issue, but the technician took the information back with him – most likely its logical that there is a connection between the error and the “old” trusts.
Issue 2:
Memory leakage for the Wem Broker service on the WEM server.
This caused the WEM server to eat all available RAM on the Broker server.
Worked around this by Scheduling a restart of the Broker service with regular intervals – for the beginning.
Investigating the big World Wide Web for the issue, lead me to the following post on the Citrix forum.:
https://discussions.citrix.com/topic/394754-norskale-broker-service-is-eating-my-memory/
This talked about a private hotfix for the issue.
When talking with the Citrix Technician I got this, it’s a DLL to replace on two locations for the WEM broker, everything seems ok after this.
So, for those struggling with that one, log a ticket with Citrix, and request the hotfix for the issue, hotfix has the name “LC9623-47”
It is a known issue for Citrix, and will probably be addressed in a later update.
Hope someone finds this useful.
Consultant manager & SME @ iteam, localized in Kristiansund, Norway.
Focused on EUC, security, mobility, virtualization, management and a modern workplace. Highly specialized around RDS/Citrix/EUC/Mobility.
The issue with the SIDs in your case could be likely related to this:
https://docs.citrix.com/en-us/workspace-environment-management/current-release/system-requirements.html
Note:
External trust relationships are not supported by WEM’s global catalog, which stores a copy of all Active Directory objects in a forest. Instead you must use other relationship types, such as forest trust relationships.
Hi Hugo,
Yes, am aware of that requirement that came in the docs after 4.2, (on 4.7 and all after to be exact) – dont remember if the docs reflected this at the time of writing that post, seeam to remember the docs was checked at that time:)
https://docs.citrix.com/en-us/legacy-archive/downloads/workspace-environment-management-4-2.pdf
In the case for this post, no external trusts were beeing used, only forest trusts – but the issue still came.
What we did find was evidence of other trusts that had noe been removed correctly – although these trusts never had been used inside WEM).
When these got removed, things seem to fall in place – and have not had issues after.
The funny thing is that this issue never showed itself on 4.2, only on 4.7.
(went straight from 4.2 to 4.7, so cannot verify i.e, if it came on the 4.3 release where the agent handling and such got a major change for the config set handling etc)
But this makes an important note for people to properly handle trusts and removal of trusts and objects inside the WEM site accordingly.
If you remove the trust agains a forest that has objects mapped inside WEM, you may get problems logging into the WEM console – giving you the “could not connect to infrastructure service” error at logon. Removing the the dead trust that has objects inside WEM will get this gone, from what i have seen.
This gives you the cheklist to do the following when removing connections to trusted forests and WEM:
1 – Remove the AD objects (machines and users/groups from the domain beeing removed), and assignments inside WEM
2 – remove the actual trust from the AD level
3 – Ensure logon to console.
If not you can get foregin objects over time just showing SID’s aswell as login issues and slowness from the WEM side.