We are in the midst of migrating to a XenApp 7.9 environment from a 6.5 environment. There are many pain points associated with this sort of transition:
Lack of Worker Groups (similar functionality returns in XenApp 7.12)
Organizing your existing application deployment around Machine and Delivery groups
Revisiting every published application in relation to user access and how Delivery groups are leveraged
Recreating all your published applications
In my current 6.5 environment we have over 240 published applications. Recreating these in the new 7.9 farm is nightmarish. Luckily, Shaun Ritchie (from EUC Consulting) has provided the Citrix community a great script that migrates (with icons and user accounts) XenApp 6.5 published applications to a XenApp 7.x farm. You can see the script on his blog post “XenApp 6.x to XenApp 7.x App Migration Script“.
This script does a lot of heavy lifting and makes a migration much easier. What do you do if you have multiple 7.x farms? I thought it would be trivial to copy the newly migrated 6.5 applications from one 7.x farm to another, but this was not the case. I used Shaun’s script as a base and re-worked it to allow the copying of apps from one XenApp 7.x farm to another.
One of the signs of a successful IT team is to have clearly defined environments for development, testing, and production. To actually put this into practice however, requires enough head count and enough resources (real and virtual) to maintain it. Many Citrix shops don’t have these luxuries. In this post, we will look at a script I wrote to help cleanup the users/groups assigned to Published Applications in a XenApp 6.5 farm that was used for development, testing, and production.
Hey, we need to test an app…
This phrase is met with trepidation by many Citrix Admins. Your co-worker has just sent an email with scant details and many assurances that this application test is just a POC and won’t have many users or require many resources. So you (being awesome) get the application installed and working and the POC starts.
First, you add one or two users, then more and more, then a group that holds most of the department that wanted to test this application to being with. Within a month, you’re told the POC was wildly successful and they already purchased the software. Now you have an application with a “Configured Users” section that is out of control
So, if you have a number of applications like this how can you clean things up or at least get some feedback on what should change?
Putting It Together
Loops and loops
We save all the active applications to a variable and just keep the application name and assigned accounts. Then we start looping through the accounts for each application. If the account matches the regular expression (see the $accountpattern variable in the full script below) for user accounts, then it is added to the $isUser variable. Otherwise, we add the AD Group to the $isGroup variable (skipping the “Citrix Admins” group as it is already added to every application).
Act on the information
Keep in mind that we are still in the second account foreach loop. Review the $isUser and $isGroup variables. If a user is a member of one of the groups already assigned to the application, make a note in a text file to remove the user from the application. If a user is not a member of any groups, then recommend that a new AD group be created for this application and add those users to it. Otherwise, if there are no groups associated with the application, recommend that one get created. You can step through the if..else logic with some test applications and add actual active directory actions to further automate the script.
At the end you will end up with a text file (two if you use the $addADGroupList switch variable). The xaappfixes_datetimestamp.txt file has a list of users to remove from groups and suggested AD (Active Directory) groups that should be created. The xaappgroups_datetimestamp.txt just lists suggested AD groups that you could run through a AD script or hand over to your AD team.
In my new job, I get to work on a dedicated Citrix team again and I’m really enjoying it. I get the opportunity to work collaboratively with a group of experienced Citrix Admins/Engineers and also get the chance to do a lot of PowerShell. Recently, we had to run Helge Klein’s excellent Delprof2 against a set of servers because of space issues. After fixing the issue, I thought it would be a good chance to stretch my PowerShell skills and enhance a tool the team uses.
The original script runs fine, it just runs against the entire farm which in this case is over 700 servers. I wanted to create a script for our XenApp 6.5 environment and leverage Worker Groups to group our servers. I also wanted to try a graphical interface for the script.
PowerShell…GUI…what’s wrong with you?
I know, I know. Using a GUI with a PowerShell script is not typical, but I felt it was the best way to present a list of Worker Groups. Your Citrix environment may be smaller or not using that many worker groups, so displaying a list in the console may make more sense. I found this post which outlined how to do a list box in PowerShell.
First, I modified the dimensions of the parts of the list box so it would display all my worker groups.
Then, I populated the list box with worker groups using get-xaworkergroup
Finally, I display the List box and wait for the user to select a Worker Group and click OK or Cancel and stop the script.
If the user does pick a worker group and clicks OK, then we iterate through the servers in the Work Group and run delprof2.exe against them. This is where you could implement your own tool or procedure.
Here’s the list box:
Selecting a Worker group and clicking OK, will run delprof2.exe against all the servers in the WG.