Sep 252014

A while back I wrote a script to quickly update a XenServer host or pool with all the hotfixes placed in a directory. I got tired of doing it through the gui, and having to do each update one at a time… waiting for reboots in-between.
This script will look for .xsupdate files in the directory you specify in the script. Each one will be uploaded to the pool master (or single host), and applied. After that it will reboot each XenServer one at a time.
The reboot process will disable HA and WLB (if you have it) – otherwise it will just throw an error and continue. Then one at a time starting with the pool master they will switch to maintenance mode, migrate vms off, and reboot. Once the host that rebooted is back up and enabled it will move to the next.  At the end it will re-enable HA and WLB.

The only requirement is that you have XenCenter installed on your workstation (and of course powershell with an execution policy that allows scripts to run).

The only “issue” is the last host to reboot will remain without VMs until you move them back manually, or a load balancing function moves them.

As always… test before trying this in a production environment.

function checkconnect {
Write-Host "Waiting for $item to reboot and exit maintenance mode."
$check = &$xe -s $master -u root -pw $pass host-list name-label=$item params=enabled --minimal
if ($check -eq $true) {
write-host "$item is online"
} else {
Start-Sleep -s 10

$xe = “c:\program files (x86)\citrix\xencenter\xe.exe” # if a x86 machine it will be c:\program files
$pass = “ROOT PASSWORD” # password to connect to the pool master
$master = “IP or Hostname” # ipaddress or hostname of the pool master
$patchpath = “C:\XSUPDATES” # path to the .xsupdate file(s)
$patches = gci $patchpath | where {$ -like “*.xsupdate”} | select -expand fullname
$pool = &$xe host-list -s $master -u root -pw $pass params=name-label –minimal
$puuid = &$xe -s $master -u root -pw $pass pool-list –minimal
$hosts = $pool -split “,”
foreach ($patch in $patches) {
$uuid = &$xe patch-upload -s $master -u root -pw $pass file-name=$patch
&$xe patch-pool-apply -s $master -u root -pw $pass uuid=$uuid
write-host “Disabling HA and WLB.”
&$xe -s $master -u root -pw $pass pool-param-set wlb-enabled=false uuid=$puuid
&$xe -s $master -u root -pw $pass pool-ha-disable
foreach ($item in $hosts) {
$hostuuid = &$xe -s $master -u root -pw $pass host-list name-label=$item –minimal
write-host “Placing $item in maintenance mode.”
&$xe -s $master -u root -pw $pass host-disable uuid=$hostuuid
write-host “Migrating VMs off of $item”
&$xe -s $master -u root -pw $pass host-evacuate uuid=$hostuuid
write-host “Rebooting $item”
&$xe -s $master -u root -pw $pass host-reboot host=$item –force
write-host “Enabling HA and WLB.”
&$xe -s $master -u root -pw $pass pool-ha-enable
&$xe -s $master -u root -pw $pass pool-param-set wlb-enabled=true uuid=$puuid
write-host “Pool update complete.”


Sep 182014

I recently ran into an issue where Citrix Profile Manager was not catching all the files from a user installed Office Add-in. I found the path to the files and they were in %localappdata%\Apps\2.0. Even if I specifically added a policy to sync that folder it still did not get every file needed for the Add-in to work. After banging my head against the wall trying to get profile manager to handle it I decided to write a logoff script to “backup” that folder to the user’s home share at logoff, and a logon script to “restore” it at logon. That worked, but it delayed logon/logoff as those files were copied to/from the user profile.

On top of that issue, I also had the need to redirect Chrome and Firefox cache directories to user home shares as they were soon to be installed on our VDI image. Of course, you can do both without the script you are about to see (GPO in the case of Chrome, and an .ini file with Firefox). I just figured kill three birds with one stone.

The answer ended up being very simple. Junction points! For those of you who may not know a junction point (aka reparse point or symbolic link) is basically a shortcut that Windows treats as a folder. A normal shortcut to “\\server\share\path” on your desktop would show that path in the address bar if you clicked on it. A symbolic link would show C:\Users\<username>\Desktop\<name of the link>. This allows you to basically “redirect” a specific folder. For those of you who have a “crappy app” that points its data to %userprofile%\AppData\<path> instead of %AppData% and prevents you from redirecting AppData this may help you as well.

Now all I need is a logon script (powershell) to create these junction points.

Requirements for this script:
1. Users must have the “Create symbolic links” right (set in GPO)

2. Users must have a Home Folder (if they don’t you could simply rewrite the script to create a folder somewhere using $env:username in the path).

Detailed explanation of what this script does:
1. Sets the location to C:\ so when it calls cmd it won’t complain about the path (assuming the script is going to run from a network share)

2. Imports a .csv file with the information
This .csv file has headers “localpath”, “homepath”, and “LorR”
localpath = the folder within local or roaming appdata. If the path is down inside somewhere make sure you include the whole path. In my case I want to get %localappdata%\Apps\2.0, so the localpath would be “Apps\2.0”
homepath = the path in the users home directory where you want the files located. Same as localpath you don’t include the entire share path… just the path you want it to create inside the share.
LorR = local or roam – so the script knows where to put the junction points.

3. For each line in the .csv file calls a function that will:
a. Decide if the path is in local or roaming appdata (LorR)
b. Create the folder structure on the user’s home folder
c. Checks if the local folder already exists. If so, checks to see if it is already a junction (which it shouldn’t be). If the path is *2.0 (path to the Office Add-ins) it moves those files to the home folder, and creates the junction. If it is anything else it deletes the folder (would be user installed chrome/firefox cache directories), and creates the junction.

After running this at logon my user now shows this in %appdata%

If I open Mozilla it shows to be local, but it is actually pointing to my home folder


The only “issue” I have seen thus far is Chrome will warn that the cache is on a network share the first time it is launched.

Below is the powershell script. Feel free to edit it to fit your needs, and make sure you test thoroughly before implementing into any production environment.