Recently a friend asked me if a Worker Group based on an Organization Unit (OU) would contain servers contained in sub OUs. I had no idea, so I had to test it to see for myself. What I found surprised me.
Worker Groups are supposed to make administering published resources easier on XenApp farm administrators. Before Worker Groups, if you added five new XenApp servers, you had to go and update every published resource that would now be served by the new servers. With a Worker Group, you base the published resource on a Worker Group and as servers are added or removed from the Worker Group nothing needs to be changed on the published resource.
To see what happens with Worker Groups and nested OUs, I created an OU structure four levels deep (Figure 1).
Each OU contains one XenApp 6.5 server (Figures 2 through 5).
Next I went into Citrix AppCenter and created a Worker Group based on the TopOU OU (Figure 6).
My JR Test Worker Group now shows all four servers from all four OUs (Figure 7).
When I click on each server in a lower level OU, the Location shows as being in the TopOU OU (Figure 8).
Next I wondered what would happen if I created a Worker Group based on the third level OU (Figure 9)?
The Third Level OU Worker Group contains the servers from the third and fourth level OUs (Figure 10).
There is extremely little information on Worker Groups based on OU. BTW, Citrix, why do you use the term “Active Directory Container” in your GUI when creating a Worker Group but the Type shows as Organizational Unit in Figure 10? Active Directory Containers are different than Active Directory OUs! Even in edocs you are confusing: “Select Active Directory Containers to add servers based on organizational unit membership”.
I have no idea why a Worker Group based on one OU would contain servers from lower level OUs. If you don’t want servers from lower level OUs to be in a Worker Group then you will have to redesign your OU structure. Thanks Citrix (implied sarcasm intended).
















April 15, 2013 at 3:54 am
Hi,
a server reboot isnt really nessecary. It is enough to perform a gpupdate and afterwards to restart IMA.
Jörn
April 15, 2013 at 6:33 am
Jörn,
That is not 100% accurate. If a XenApp server has been moved into a new OU, the server will not get any new computer based AD GPOs unless the server is restarted. And if the Citrix Policies are AD based then those computer based policy settings will not be retrieved until a server reboot. So while you may be able to do a gpupdate and restart the IMA service to affect the Worker Group stuff, you are not getting everything you need in an AD environment unless you reboot the server.
Webster
January 28, 2013 at 8:22 am
I try to organize my policies and apps with worker groups. I have a strange issue. I don’t know if you encounter this…
When I add an OU in a worker group, the console does not add all the servers of the OU and it is shown as “unknown item : SID_of_the_OU_object”
January 28, 2013 at 3:21 pm
Are you talking about adding a new OU to an existing Worker Group already based on an OU?
I have had some people report issues after moving a XenApp server into an OU forgetting that after you move a server into a new OU, the server MUST be rebooted. That way the server gets the GPOs assigned to the new OU and the data store database gets updated with the new information.
Thanks
Webster
May 9, 2013 at 1:24 pm
check this hotfix:
http://support.citrix.com/article/CTX135516
January 9, 2013 at 6:51 am
I’ve noticed this too, had to do a redesign of the XA OU structure. I noticed that a server remains a member of a workergroup based on AD, even if you move it to another OU. A server reboot is needed to ‘switch’ the workergroup.
Cheers,
Kees
January 9, 2013 at 6:53 am
If you move any server in Active Directory to another OU, a server reboot is required so the server picks up any GPO changes required by the OU change.
Webster