Update 10/10/13: Since I was handed two more factors; it had to be run for users on VPN; and it had to be absolutely bulletproof, I revised the script to do the following:
– Check for installed version, so it doesn’t mess up allready installed Receivers.
– Files are copied locally to computers, so it doesn’t run over the network.
– I’m also running it as a scheduled task, since startup scripts don’t run well when using VPN.
Original post:
This has been one of my peeves with Citrix for quite some time. They retired Program Neighborhood, and left us with the PNAgent. Now they’re retiring the PNAgent and pushing Storefront with the unified Receiver.
I get what they’re trying to do, but they could put in a bit more effort to make the transition seamless.
Those reading this probably know that you can’t go from Receiver Enterprise; which has been the legacy version up until 3.4, to the regular Receiver.
In 4.0; you have no choice; there is no more Enterprise, so you’ll have to convert to the regular Receiver. And count to ten.
Because, if you’ve tried, you know how flawed this all is. In order for Single Sign-on (SSON) to work, you pretty much have to wipe the old Receiver off the computer before reinstalling.
If you have SCCM, this is pretty straight forward. For those who don’t; like me (or a few of my customers to be precise), I’ve capitulated and done a script. This is kind of a beta-version of it, and I haven’t tried it in production thus far, but testing looks promising.
This is; BTW; based on my Clean-Java script. I told you it could be put to different uses!
Now keep in mind the following:
- The new Receiver does not support adding apps directly to the users desktop. It just doesn’t. It is possible to work around that by copying shortcuts from the users AppData\Roaming\Citrix\SelfService folder. Or from the users start menu. But that might be a bit tricky. Especially if you have tons of applications and don’t know what people might want on their desktop.
Your best bet is informing the users that their apps are in the start menu, and they can make shortcuts to the desktop if they want to.Or start the Receiver and launch apps from there. What ever tickles you. - As an added bonus; old shortcuts aren’t necessarily removed, if you’ve enabled the option that they stay for the old receiver; they will stay. The old shortcuts are just .lnk files.
- This script installs the plugin with SSON.
- It also does TWO reboots. One after the uninstall and one after the install (SSON needs a reboot to kick in). It also makes folders/txt files in c:\temp to track the progress during reboots. I’m not a big fan of that, so I might re-do it with reg keys instead.
- I’ve done this as a logon-script, as it needs to run two times to do both uninstall and install.
- It also adds Citrix Receiver to the start-up folder for all users, to ensure that icons show up in the start menu as I wanted them to.
- And as a final bonus; the new Receiver doesn’t give a fudge about your XenApp apps wanting to run in full-screen. That’s a user thing, so what ever the users wants, it remembers. Default is windowed for everything.
If you want to force fullscreen (like I do, for my XA desktop users); follow this post: Default fullscreen in XenDesktop. - Files are copied over using GPP, and the script is run as a scheduled task which is also deployed with GPP. Ask if you need the details.
- My colleague, over on XenApp Blog, made a tutorial covering the StoreFront side of things: Citrix Receiver 4 with Domain Pass-through
Without further ado:
And the full script. No plagerizing!
##Initial version 05.06.2013; Kristoffer Birkenes
##Revised 03.10.2013#Set path to Installers
$uninstaller = “C:\Install\CitrixReceiverEnterprise.exe”
$installer = “C:\Install\CitrixReceiver.exe”if ((Get-WmiObject -Class Win32_OperatingSystem -ea 0).OSArchitecture -eq “64-bit”) {
$architechture = “x64”
}
else {
$architechture = “x86”
}if (((test-path “c:\program files (x86)\Citrix\Selfserviceplugin”) -like “false”) -AND ($architechture -like “x64”)){
$installed = “False”
}if (((test-path “c:\program files\Citrix\Selfserviceplugin”) -like “false”) -AND ($architechture -like “x86”)){
$installed = “False”
}if ($installed -like “false”) {
##UNINSTALL##
if ((test-path c:\temp\CitrixUninstalled.txt) -like “false”) {
#Reg-paths to clean up
$RegPath = “HKLM:\SOFTWARE\Citrix”
$RegPath64 = “HKLM:\SOFTWARE\Wow6432Node\Citrix”
New-PSDrive -Name HKCR -PSProvider Registry -Root HKEY_CLASSES_ROOT -ErrorAction SilentlyContinue
$ClassesRootPath = “HKCR:\Installer\Products”
#Kill all Citrix-processes
get-process | where {$_.company -like “*citrix*”} | Stop-Process -Force -ErrorAction SilentlyContinue#Execute uninstall-command
start-process $uninstaller -args “/uninstall /silent” -wait#Clean up remaining registry settings
if ((test-path $RegPath) -like “true”) {
remove-item $_.pspath -force -recurse -ErrorAction SilentlyContinue
}
if ((test-path $RegPath64) -like “true”) {
remove-item $_.pspath -force -recurse -ErrorAction SilentlyContinue
}
#Clean out Citrix entries from Classes_Root
$CRResults = Get-ChildItem $ClassesRootPath -Recurse -ErrorAction SilentlyContinue | foreach {gp ($_.pspath)}
$CRResults | where {$_.ProductName -like “*Citrix*”} | foreach {
remove-item $_.pspath -force -recurse -ErrorAction SilentlyContinue
}#Remove local files 32- and 64-bit
remove-item -recurse -path $env:Programfiles\Citrix\ -force -ErrorAction SilentlyContinueif ($architecture -like “x64”) {
remove-item -recurse -path ${env:ProgramFiles(x86)}\Citrix -force -ErrorAction SilentlyContinue
}New-Item c:\Temp\CitrixUninstalled.txt -type file
#Reboot
shutdown /r /t 00
}##INSTALLATION##
if (((test-path c:\temp\CitrixInstalled.txt) -like “false”) -and ((test-path c:\temp\CitrixUnInstalled.txt) -like “true”)) {
#Install new version
Start-Process $installer -Arg “/includeSSON STORE0=Noah;https://web01.noah.corp/Citrix/Noah/discovery;on;Noah Apps /silent” -Wait -Verb ‘Runas’
New-Item c:\Temp\CitrixInstalled.txt -type file#Reboot
shutdown /r /t 00
}##POST-INSTALLATION
if (((test-path c:\temp\CitrixInstalled.txt) -like “true”) -and ((test-path c:\temp\CitrixFinalized.txt) -like “False”)) {
# Create shortcut in startup
$WshShell = New-Object -ComObject WScript.Shell
$Shortcut = $WshShell.CreateShortcut(“C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup\Citrix Receiver.lnk”)
if ($architechture -like “x64”) {
$Shortcut.TargetPath = “C:\Program Files (x86)\Citrix\SelfServicePlugin\SelfService.exe”}
else {
$Shortcut.TargetPath = “C:\Program Files\Citrix\SelfServicePlugin\SelfService.exe”}
$Shortcut.Save()New-Item c:\Temp\CitrixFinalized.txt -type file
}
}
else {
write-host “Citrix Already Installed”
}
Desktop icons have been an issue for me as well.
I crafted an (albeit ugly) workaround via a vbscript that will synchronize the desktop by creating symbolic links to the start menu shortcuts. It polls the Windows WMI service to be told whenever a file is added/removed from the Start Menu\Programs folder and perform a sync at that time. If you put a link to run the vbscript file at startup it may be a solution in lieu of Citrix actually giving us this functionality back.
http://www.tdonline.com/download/receiver-desktop-sync.vbs
Seems to work, but I have only done limited testing with it so far.
Yeah I was thinking of doing that myself, but I couldn’t find a good angle. I’d have to be able to separate ‘desktop icons’ from ‘non-desktop icons’; but it really is a ridiculous restriction by Citrix. Doing it just to do it, there’s no reason for it.
I’ll give it a whirl, thanks 🙂
I tried to build a “little” bit of intelligence into it. It only synchronizes the shortcut from the start menu if the target of the shortcut points to the AppData\Roaming\Citrix\SelfService directory.
Still nowhere as elegant as the automatic behavior of the PNAgent integration that Citrix obliterated. No-one uses their desktop anymore, right? 😉
Yeah, Citrix isn’t really in touch with their users. But you have to roll with the punches I guess.
I’ll be rolling out this in production for a customer next week; I’ll try out your script then (and update the article if we use it :))
I am trying to run a computer startup script using powershell to install the Citrix Receiver version 4 and enable SSON. The issue I am having is that to enable the SSON it has to be installed as an administrator. The behaviour I am experiencing is that the Citrix Receiver is being installed by the startup script and on reviewing the network Adapter>Advanced Settings it is showing the SSON on the network binding order. However the ssonsrv.exe process is not running for any user logging onto the PC and hence on connecting to storefront it prompts for credentials. I have the GPO in place to enable ICA pass-through authentication, storefront is configured to enable pass through authentication and the storefront server is in IE trusted sites. I reckon the cause is that the computer startup script is failing to install the Citrix Receiver in administrative mode. Do you have a way of forcing the install in admin mode to ensure the ssonsrv.exe is running for all users of the PC. I need to roll out Receiver to a load of PCs and do not have the luxury of SCCM and not impressed with merchandising server or it’s future development. Thanks
You’re not seeing the ssonsrv.exe at all? It’s supposed to run in system-context, not user; so it won’t show as a user-process. That said, I’ve had plenty of issues with ssonsrv.exe (that’s why I decided to whipe the old receiver before installing the new one). Are you using the commandline I’m using for installing it?
Ssonsrv.exe, not showing at all when logged in as admin under show all processes in task manager. Citrix edocs advises to enable SSON must be installed as admin, elevated privileges
Tried same command line, no joy with install on clean machine. Have you tried your script as a computer startup script successfully
Ssonsrv.exe will appear if you run the command line manually when logged in as an admin
Thanks
Ther’es nothing like the relief of finding what you’re looking for.
This is the motive why i – Phone apps development
and i – Phone game development gathers the momentum of such gravity.
Many thanks as we hoped for a longeterm business relationships.
The easiest way to understand this is that YOU as the buyer are completely protected by an independent organisation that looks after the payments.
One way to do this is by offering a sincere
compliment to someone.
My webpage … youtube
Hi at all,
i am searching for a hint to complete the following tasks if the user log in:
Enviroment XenDesktop 7.1, Storefront, ICA-Client 4.1
receiver 4.1 /selfservice plugin is installed (Win 7), thr store configuration would pre configured based on the group-membership via powershell/c# if the User login, than nowaday the citrix selfservice ui is shown and the user has one icon for a published desktop. this seems not to be really userfriendly, because the user has before only one icon and the session was starting. The shortcuts created in %apdata% are also not helpfull, because the groupmembership can change and then the shortcuts are not helpfull (Storefront is running in multitalent mode for different kinds of authentication (smartcard, explicit logon, passthrough). Maybe somebody here has an idea how i can query the availability of the default publishd desktop and start this desktop for the user without showing the selfservice ui or the shortcut in appdata via powershell or c#? Thanks a lot for any hint, i found nothing suitable by citrix at this time. regards Blue
So! I really like your script, had a few things to add, and they are completely open to criticism. I’m very much an amateur at Powershell….
I wanted it to also clean out:
1) HKU:\Software\Citrix
2) C:\Users\*\Appdata\Local\Citrix
3) Nuke the “Published Apps” folder from the Start Menu.
What do you think of this? Obviously remove the -WhatIf
Get-ChildItem -Force -Directory C:\Users\*\AppData -Recurse -Include “Published Apps” -ErrorAction SilentlyContinue | Remove-Item -Recurse -ErrorAction SilentlyContinue -WhatIf
Get-ChildItem -Force -Directory C:\Users\*\AppData\Local\ -Recurse -Include “Citrix” -ErrorAction SilentlyContinue | Remove-Item -Recurse -ErrorAction SilentlyContinue -WhatIf
$null = New-PSDrive -Name HKU -PSProvider Registry -Root Registry::HKEY_USERS -ErrorAction SilentlyContinue
Get-ChildItem -Path HKU:\*\Software\Citrix -ErrorAction SilentlyContinue | Remove-Item -Recurse -ErrorAction SilentlyContinue -WhatIf
As I swiftly discovered, Powershell 2 doesn’t like -Directory.
These are v2 Compatible. Aimed a little more finely since it returns files and not just directories it seems.
Get-ChildItem “c:\Users\*\Appdata” -recurse -force -ErrorAction SilentlyContinue | Where-Object {{$_.Attributes -match ‘Directory’} -and $_.Name -match ‘Published App’} | Remove-Item -Recurse -WhatIf
Get-ChildItem “c:\Users\*\Appdata\Local” -recurse -force -ErrorAction SilentlyContinue | Where-Object {{$_.Attributes -match ‘Directory’} -and $_.Name -match ‘Citrix’} | Remove-Item -Recurse -WhatIf
Looks like they fixed this in Citrix Receiver 4.2.
I’m upgrading from 3.4 Enterprise to 4.4 LTSR. When I upgrade, specifying “PlaceShortcutsInStartMenu”, the old ones remain, and are broken. There are then duplicates from the 4.4 install that work. Is there an easy way to remove the old ones?