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).