Add-PSSnapin Citrix.XenApp.Commands
$apps = Get-XAApplication
$mode = "Debug" #Change to Real to make changes
$count = 0
foreach($app in $apps)
{
if($app.ClientFolder -match "AGLNG\\")
{
$original = $app.ClientFolder
$temp = $original -replace "AGLNG\\", ""
$count +=1
if($mode -eq "Debug")
{
Write-Host $app.DisplayName "would have " $original " changed to " $temp
}
elseif($mode -eq "Real")
{
Write-Host "Changing " $app " to " $temp
Set-XAApplication $app -ClientFolder $temp
}
}
if($app.ClientFolder -match "ECA\\")
{
$original = $app.ClientFolder
$temp = $original -replace "ECA\\", ""
$count +=1
if($mode -eq "Debug")
{
Write-Host $app.DisplayName "would have " $original " changed to " $temp
}
elseif($mode -eq "Real")
{
Write-Host "Changing " $app " to " $temp
Set-XAApplication $app -ClientFolder $temp
}
}
if($app.ClientFolder -match "APAC\\")
{
$original = $app.ClientFolder
$temp = $original -replace "APAC\\", ""
$count +=1
if($mode -eq "Debug")
{
Write-Host $app.DisplayName "would have " $original " changed to " $temp
}
elseif($mode -eq "Real")
{
Write-Host "Changing " $app " to " $temp
Set-XAApplication $app -ClientFolder $temp
}
}
}
Write-Host "Total of" $count "applications effected by the PN Folder change."
Here you will find different solutions, designs, and findings from different projects I've worked on.
Friday, August 31, 2012
Powershell script to rename XenApp Program Neighborhood Paths
Recently there was a organizational change in a company I was working at that required us to change all the program neighborhood paths for all the apps in the XenApp environment. The script below iterates through all the apps in the farm and examines their initial folder in the path for the "Client Folder" aka Program Neighborhood folder and removes the folder from their path. You may edit the different fields that we were inspecting for to suite changes you may need to make in your farm. This script should work for XenApp 6.0+.
Wednesday, August 8, 2012
Uninstall IE9 and install IE8 on Windows Server 2008 R2
I had to do this recently on a XenApp server to publish IE8 for compatibility support for legacy web apps and found out that this was not the most straight forward thing to do, however I found a really simple solution for it.
Simply go to Control Panel -> Windows Update -> Installed Updates -> and scroll down to find the IE9 update and click remove, it's as easy as that, reboot and IE8 is back.
Hope this saves someone the headache.
Simply go to Control Panel -> Windows Update -> Installed Updates -> and scroll down to find the IE9 update and click remove, it's as easy as that, reboot and IE8 is back.
Hope this saves someone the headache.
Monday, August 6, 2012
XenApp 6.5 Load Balancing Policies applied to specific applications
I spent some time working with XenApp 6.x's feature of application load balancing that allows you to route users based on certain filters to specific worker groups of servers. The interface is fairly simple and it that allows you to first pick how you want to filter the users, which is done by either Access Control, Client IP Address, Client Name, or User. After you've chosen your filter you simply pick the Load Balancing Policies you want to set, which is either by Worker Group Preference or Streamed App Delivery. All of this is managed via a node in AppCenter called Load Balancing Policies. There are some benefits and some disadvantages I've found through using this feature which I will explain through my implementation scenario.
In my scenario I was working to implement a Global Office 2010 Silo distributed over 3 data centers, for this post I'll just name them worker groups DC1, DC2, and DC3 which are all servers containing office 2010. I setup the policies as follows:
Policy 1
Name: DC1 Priority
Filter: Filter based on user, with user location based AD groups with fastest connection to DC1
Policy: Worker Group Preference, with priority in order lowest to highest DC1, DC2, DC3 (based on link speeds between the three).
Policy 2
Name: DC2 Priority
Filter: Filter based on user, with user location based AD groups with fastest connection to DC2
Policy: Worker Group Preference, with priority in order lowest to highest DC2, DC1, DC3.
Policy 3
Name: DC3 Priority
Filter: Filter based on user, with user location based AD groups with fastest connection to DC3
Policy: Worker Group Preference, with priority in order lowest to highest DC3, DC2, DC1.
After getting everything setup I quickly found out that the Application Load Balancing had no way to apply the policy to specific applications, meaning that it affected all applications that were published. So if a user's account was in a AD Group "DC1 Employees" he was subject to Policy 1 and XenApp would try to search the Office 2010 worker groups even if he was trying to run something like FireFox, this was causing applications to fail that were processing these policies. This was going to be a problem because I wanted to get away from having to publish different applications for different regions which makes administration a nightmare. Digging around on google I found this which Citrix gives mention of the idea to add a Worker Group with all the servers added at the last priority for the apps, this way if the application is not contained as part of the load balancing worker group set it will still launch where it is available. After making the "All Servers" worker group and adding that as last priority on all the LB Policies, everything was working just as planned.
In my scenario I was working to implement a Global Office 2010 Silo distributed over 3 data centers, for this post I'll just name them worker groups DC1, DC2, and DC3 which are all servers containing office 2010. I setup the policies as follows:
Policy 1
Name: DC1 Priority
Filter: Filter based on user, with user location based AD groups with fastest connection to DC1
Policy: Worker Group Preference, with priority in order lowest to highest DC1, DC2, DC3 (based on link speeds between the three).
Policy 2
Name: DC2 Priority
Filter: Filter based on user, with user location based AD groups with fastest connection to DC2
Policy: Worker Group Preference, with priority in order lowest to highest DC2, DC1, DC3.
Policy 3
Name: DC3 Priority
Filter: Filter based on user, with user location based AD groups with fastest connection to DC3
Policy: Worker Group Preference, with priority in order lowest to highest DC3, DC2, DC1.
After getting everything setup I quickly found out that the Application Load Balancing had no way to apply the policy to specific applications, meaning that it affected all applications that were published. So if a user's account was in a AD Group "DC1 Employees" he was subject to Policy 1 and XenApp would try to search the Office 2010 worker groups even if he was trying to run something like FireFox, this was causing applications to fail that were processing these policies. This was going to be a problem because I wanted to get away from having to publish different applications for different regions which makes administration a nightmare. Digging around on google I found this which Citrix gives mention of the idea to add a Worker Group with all the servers added at the last priority for the apps, this way if the application is not contained as part of the load balancing worker group set it will still launch where it is available. After making the "All Servers" worker group and adding that as last priority on all the LB Policies, everything was working just as planned.
Subscribe to:
Posts (Atom)