XenDesktop: Eigene Icons im Storefront

Es ist im XenDesktop natürlich möglich, die recht langweiligen Standard-Icons, welche für die Desktops im Storefront angezeigt werden, auszutauschen. Dies wird allerdings nicht im Storefront gemacht sondern via PowerShell auf dem DDC.

sf_icon

Voraussetzung hierfür ist es eine Icon-Datei zu haben, in welcher die Größen 256, 128, 64, 48, 32 und 24 Pixel, jeweils Lang und Breit, vorhanden sind. Hierfür gibt es diverse Websites die diese Convertierung aus einer Bilddatei heraus ermöglichen wie z.B. http://converticon.com/.

Diese .ico Datei wird dann auf einem DDC abgelegt und mittels der PowerShell importiert:
Add-PSSnapin Citrix.*
Get-CtxIcon -FileName 'C:\Temp\Win8.ico' | New-BrokerIcon
Set-BrokerDesktopGroup -Name Win7Group -IconUid 1004

Die IconUid ist natürlich durch die nach dem vorherigen Befehl angezeigt zu ersetzen. Dieses Icon ist dann in der Datenbank zuhause und steht allen DDCs und natürlich auch Storefronts zur Verfügung, eine Wiederholung pro DDC ist nicht nötig.

Auf diese Weise lässt sich schnell und leicht etwas Abwechslung in die Umgebung bringen.

Exchange 2010 SP2 Installation – AuthorizationManager Fehler

Bei der Installation von Exchange 2010 SP2 kann es vorkommeen das das Exchange Setup – natürlich nachdem die Exchange Daten entfernt wurden – einen Fehler auswirft wonach der „AutorizationManager Check“ fehlgeschlagen ist: „$error.Clear(); & $RoleBinPath\ServiceControl.ps1 EnableServices Critical “ was run: „AuthorizationManager check failed.“. Hier ist ein vor der Installation durchgeführter Snapshot oder ähnliches hilfreich, an sonsten geht es mit dem Desaster Recovery weiter.

Um das Problem zu beheben müssen alle PowerShell Execution Policys die per GPO verteilt werden (MachinePolicy und UserPolicy) auf „undefined“ stehen, in diesem Beispiel ist es nicht der Fall:

PS H:\> Get-ExecutionPolicy -list

Scope ExecutionPolicy
----- ---------------
MachinePolicy Unrestricted
UserPolicy Undefined
Process Undefined
CurrentUser Undefined
LocalMachine RemoteSigned

Ist dies nicht der Fall den Exchange entweder in eine OU verschieben in welcher die GPO nicht angewendet wird oder die Einstellung in der GPO (Computerkonfiguration – Administrative Vorlagen – Windows-Komponenten – Windows PowerShell) deaktivieren und per „gpupdate /force“ angewendet. Daraufhin folgenden Befehl ausführen:

PS H:\> Set-ExecutionPolicy undefined

Hiermit werden die Policys entsprechend zurückgesetzt und sollten wie folgt aussehen:

PS H:\> Get-ExecutionPolicy -list

Scope ExecutionPolicy
----- ---------------
MachinePolicy Undefined
UserPolicy Undefined
Process Undefined
CurrentUser Undefined
LocalMachine Undefined

Nun lässt sich das Setup problemlos durchführen.

Sollte jetzt ein Fehler auftauchen wonach Skripte garnicht mehr ausgeführt werden können lassen sich diese wie folgt genehmigen:

PS H:\> Set-ExecutionPolicy Unrestricted
PS H:\> Get-ExecutionPolicy -list

Scope ExecutionPolicy
----- ---------------
MachinePolicy Undefined
UserPolicy Undefined
Process Undefined
CurrentUser Undefined
LocalMachine Unrestricted

Damit sollte die Installation letztendlich gelingen. Hintergrund scheint hierbei das beenden der WMI Dienste während der Installation zu sein. Sind diese deaktiviert lassen sich GPO Einstellungen nicht mehr anwenden und das Setup fällt bei der bestimmung der anzuwendenden Policy auf die Nase.

Bei dem Upgrade einer DAG ist außerdem dieser Microsoft Artikel zu beachten.