sachathomet.ch

Anwendungsvirtualisierung, Internet der Dinge und Cloud Computing, Blog von Sacha Thomet

Fatal error during installation (1603) beim StoreFront upgrade auf 3.12

Heute habe ich meine Citrix StoreFront Server von 3.9 auf 3.12 aktualisiert

wie immer habe ich zuerst die folgenden Dienste gestoppt:

net stop W3SVC
net stop CitrixConfigurationReplication
net stop CitrixCredentialWallet
net stop CitrixDefaultDomainService
net stop “Citrix Subscriptions Store”
net stop “Citrix Peer Resolution Service”
net stop CitrixServiceMonitor
net stop CitrixTelemetryService

dann käme dann das Ausführen vom CitrixStoreFront-x64.msi, ein reboot des Servers und danach der zweite StoreFront Server. Bisher ging das meistens Problemlos.

Jedoch dieses mal schlug mein Update fehl mit dem Error 1604:

CitrixStoreFront-x64.msi’ failed with error code 1603. Fatal error during installation”

Ich mag mich erinnern dass ich das schon mal hatte …. und habe dann dies gefunden:

https://discussions.citrix.com/topic/371535-storefront-upgrade-to-301-from-300-fails

Na gut, ich bin nun auf StoreFront 3.9 und wenn ich in “C:\Program Files\Citrix\Receiver StoreFront\Services\ProtocolTransitionService\Citrix.DeliveryServices.ProtocolTransition.ServiceHost.exe.config” schaue sehe ich auf einigen Zeilen “Version=3.8.0.0” – aber ich habe ja aktuell 3.9, also ersetze ich alle “Version=3.8.0.0” zu “Version=3.9.0.0”

Resultat: Nun klappts auch mit dem StoreFront upgrade auf 3.12 – Ende gut, alles gut.

Der SOAP Serivce kann auf einem PVS Server nicht mehr gestartet werden

Nach den letzten monatlichen Microsoft Security Updates war einer meiner PVS Server nicht mehr in der Lade den SOAP Service zu starten. Ich kriegte einen Event 7000 mit der Meldung:

The Citrix PVS Soap Server service failed to start due to the following error: The service did not respond the the start or control request in a timely fashion.

Ich lebe in Bern, und wir Berner sind dafür bekannt alles etwas ruhig wenn nicht sogar langsam anzugehen und uns nicht stressen zu lassen. Wahrscheinlich liegt dies an unserem Dialekt der einen gewissen ruhigen Klang ausstrahlt.

Jedenfalls war meine Idee aus der Meldung, wenn der Service sich gestresst fühlt, geben wir ihm doch einfach mehr Zeit:

Ich habe ein DWORD names ServicesPipeTimeout  mit dem Wert 120000 in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control erstellt, dies bedeutet das nun die Services auf diesem Server 2 minuten Zeit haben um zu starten. Nach einem Reboot war die Einstellung aktiv und mein SOAP war wieder da.

Übrigens, der SOAP ist ein zickiges Ding und ich empfehle den Service so zu konfigurieren dass dieser nach einem Absturz automatisch wieder startet.

XenApp & XenDesktop CEIP (nach Hause telefonieren) verhinden

Bereits im Februar als ich meine Citrix Umgebung auf 7.13 aktualiserte, sah ich das es nicht ganz einfach ist das nach Hause telefonieren zu deaktivieren. Ich habe dann diesen kurzen Tweet gemacht:

Nun beim Update nach 7.14, hatte ich diese Problematik wieder, denn die Einstellung wurde auf meinem Lizenzserver wieder zurückgesetzt. Nun dachte ich mir das es eventuell doch ein kurze Post wert wäre.

Ich bin nicht Paranoid, aber weil alle meine Server kein Internet-Zugang haben kriege ich im Studio auch diese unschöne Meldung:

 

Es ist ziehmlich einfach das Verbraucher Customer Experience Improvement Program (CEIP) zu deaktieren, es muss nur diese Zeile in’s Citrix.opt auf dem Lizenzserver:

#CITRIX CEIP NONE

 

Wie sein Netzwerk innerhalb Minuten wieder online bringen mit Ubiquiti UniFi Geräten

Vor weniger als einem Monat hatte ich die Idee ein neuer WLAN Access-Point zu kaufen um die Qualität und Möglichkeiten meines Heimdrahtlosnetzwerks zu verbessern. Bis jetzt hatte ich eine Fritzbox welche für den Hausgebrauch schon sehr gut ist. Fritz macht alles, schnelles Drahtlosnetzwerk, DSL Modem, Router, Voice-over-IP, Anrufbeantworter und DECT-Basisstation. Fritz war einfach zum konfigurieren und stabil. Natürlich hätte ich mir noch paar Enterprise Features gewünscht, besonders weil ich in meinem Netz noch meine EUC Spielwiese betreiben und diverse IoT Geräte habe. Aber ehrlich gesagt waren alle mir bekannten professionellen Netzwerkgeräte ausserhalb meines Budgets.

Also war es der Plan einfach das Wifi zu verbessern, ich habe den Ubiquiti UniFi AP-AC-Pro ohne weitere Hintergedanken gekauft. Aber ganz ehrlich, es war eine Einstiegsdroge. Ich sah alle die Möglichkeiten zu einem bezahlbaren Preis und ohne zusätzliche Lizenzkosten. Ich will hier aber kein Bericht über die Ubiquiti Geräte schreiben, dazu gibt es schon einige Posts. Ein guter Post ist der von meinem CTP Kollegen Jason Samuel (englisch): Building a secure high visibility WiFi network using Ubiquiti Networks UniFi gear

Ich kann nun nur sagen dass ich mittlerweile einen Router (UniFi Security Gateway 3P) einen managed Switch (UniFi Switch 16 POE-150W) und zwei Access Points (UniFi AP-AC-Pro and UniFi AP-AC-LR) von Ubiquiti in meinem Netzwerk betreibe. Endlich kann ich mein Netzwerk segmentieren und in mehrere virtuelle Netze unterteilen (VLANs). Für mich macht es das ganze transparenter und hoffentlich sicherer, ganz sicher ist es aber einfacher zu verwalten. Aktuell habe ich 3 Drahtlos-SSIDs und 4 VLANs. Software definiertes Netzwerk ist grossartig und lässt mich dinger tun von welchen ich bisher nur träumen konnte. Wenn ich über alle die Möglichkeiten nachdenke die man machen kann, bin ich mir immer mehr sicher das man sich mehr Sorgen über die Netzwerksicherheit machen sollte … aber das ist eine andere Geschichte …

Der USG 3P, UniFi Security Gateway, kommt mit 3 Anschlüssen. WAN, LAN und Voip. Die Software wird ständig weiter entwickelt und einen Neuheiten kommen erst als Beta-Funktion rein. So auch die Möglichkeit das der Voip-Port als WAN2 definiert werden kann:

Diese Funktion macht es möglich wie der Name sagt den Voip Anschluss als zweiten WAN Link zu benutzen, entweder als Ausfallsicherung (Failover) oder als ausgewogenes LoadBalancing (Weighted LB). Natürlich ist dies für den Heimgebraucht nicht der gewöhnliche Fall, kann aber für kleinere Firmen oder Aussenbüros eine interessante Option sein.

Ich habe momentan nur eine Verbindung in’s Internet, eine Verbindung über das TV-Kabel vom Anbieter Quickline mit 250M down- und 25M Upload. Wenn das Internet mal ausfällt kann ich mir mit einem 4G Hotspot von Huawei aushelfen auf welchen ich mit meinem Laptop verbinde.

 

Letzten Samstag, genau als ich mit meiner Spielwiese “rumgebastelt” habe, ist meine Kabelinternet-Verbindung unterbrochen. Ein Neustart des Routers brachte nichts. Dann habe ich entschieden mir nun dieses oben genannte Feature genauer anzuschauen, ich hatte zwar keine zweiter Internetleitung aber eben mein 4G Router und dann kam mir in den Sinn das ich doch noch ein Zyxel Reise RouterNBG2105 in der Schublade habe. So habe ich den 4G-Wifi Router eingeschaltet, den Reise-Router darauf verbunden und diesen anschliessen mit einem Cat5-Kabel an den freien Port des USG gehängt welches ich von Voip auf WAN2 umstellte. Innerhalb 30 Minuten war ich wieder mit meinem gesamten Netzwerk zurück online.

Auf WAN2 kann also irgendwas rein kommen das Internet bietet, in meinem Fall wird eine IP per DHCP vom WiFi router zugewiesen. Natürlich musste ich die um die Verbindung vom Zyxel NBG2105 zum 4G-Wifi herzustellen das NBG2105 zuest kurz per Kabel an mein Laptop hängen. Das wichtigste bei diesem Konstrukt ist es beim NBG2105 den Schalter auf Client zu stellen.

Statt des Zyxel NBG2105 könnte hier natürlich jedes Gerät sein das aus WLAN das Internet auf LAN bringt, also auch ein RaspberryPi oder ein alter Comptuer. Oder wer es richtig machen will für eine dauernde Installation mit einer Mobile Simkarte nimmt gleich ein 4G-Router mit Kabelanschluss.

Natürlich ist die Geschwindigkeit von 4G nicht annähernd so schnell wie mein Kabelinternet, aber definitiv besser als Offline zu sein:

Auch Netflix schauen am AppleTv war kein Problem!

Und nun habe ich nicht nur die Lösung “Wie innerhalb Minuten wieder online zu sein” sondern kann es auch für ein “bleib immer online” verwenden.

Sacha’s blog nun auch in Deutsch

Im Jahre 2013 habe ich mein Blog gestartet und um ein breites, weltweites Publikum zu erreichen dies in Englisch. Nun nach 4 Jahren und steigender Zahl von Lesern habe ich entschieden meine Artikel neu ebenfalls in Deutsch zu verfassen. Somit kann ich die Leser in Deutschland, Österreich und natürlich meinem Heimatland Schweiz besser berücksichtigen. Die Hauptsprache des Blogs bleibt aber Englisch, darum werden Kommentare in Scripts oder auch die Videos weiterhin englisch sein.

Von Windows 10 zu Windows 10 mit installiertem Citrix Virtual Desktop Agenten

Einführung, meine Beziehung zu Windows 10

Die Firma für welche ich arbeite, Die Mobiliar, hat bereits sehr früh mit der Integration von Windows 10 gestartet.  Bereits im Frühling 2016 wurde Windows 10 sowohl auf physischen Geräten wie auch den virtuellen Desktops ausgerollt. Wir stellen unseren Citrix XenDestkop User zwei verschiedene Typen von VDIs zur Verfügung, einerseits nicht-persistente gepoolte Desktops, andererseits dedizierte persistente Desktops. Beide Typen werden mit Citrix XenDesktop 7.x zu Verfügung gestellt.

Die Arbeit als Ealry-Adopter mit so neuen Betriebssystemen ist zwar äusserst interessant, kann aber an gewissen Tagen einem den letzten Nerv rauben. Windows 10 zum laufen bringen ist eines, aber jede spezielle Komponente die man hinzufügt mach das ganze Komplexer. So wird es schwieriger wenn oben auf Windows 10 noch Citrix XenDesktop kommt und zum ganzen am Ende eventuell noch eine spezielle authentisierung mit Smart Cards.
Ich durfte bereits an der E2EVC in Rome über dieses Thema berichten:  The stony road of a VDI migration from Win7 to Win10

Neues Kapitel

Nun geht die Geschichte in die nächste Runde, die erste Version von Windows 10 die wir ausgerollt haben war der Build 1511, nun ist das aktuelle Projekt der Upgrade zum  anniversary update (1607). Für die gepoolten desktops ist es fraglos das wir auf grüner Wiese beginnen. Einen Neubau für die dedizierten Desktops wird aber nicht akzeptiert.

Ich war gespannt wer im gleichen Boot sitzt und habe somit diesen Twitter Poll erstellt:


36% installieren einfach Neu … Mutig? Oder einfach der neue Ansatz?

Ich verrate hier mal 2 Geheimnisse:

  • Der Upgrade von Windows 10 z.B. 1511 nach 1607 lässt sich mit einem Installierten Citrix Virtual Desktop Agent (VDA) nicht durchführen! 
  • Die Deinstallation des Citrix VDA schlägt in den meisten Fällen fehl  …

    Zuerst die guteNachricht:
    Citrix ist sich bewusst das die Deinstallation des VDA’s problematisch ist, sonst würde es wohl kein VDA Cleanup Utility geben:
    VDACleanupUtility.exe (https://support.citrix.com/article/CTX209255)
    dann die schlechte Nachricht: Das VDACleanupUtility.exe (VCU) muss als Benutzer laufen, es benötigt einen Neustart und eine Nachfolgende Anmeldung mit dem vorangehenden Benutzernamen.
    Diese Tatsache macht die Automatisierung nicht ganz so einfach.

Mit der Hilfe von meinem CTP Kollegen Stephane Thirion und meinen Kollegen bei der Mobiliar war ich in der Lage folgenden Guide zu erstellen, wie ein Weg zur Automatisierung  des Windows 10 Build updates aussehen kann.
Das wichtigste daran ist das automatisierte entfernen des Virtual Desktop Agents.

Task Sequence für SCCM

Diese Anleitung bildet die Task Sequenz in Microsoft System Center ab, aber die folgenden Schritte lassen sich selbstverständlich auf mit anderen Enterprise Softwareverteilungen bewerkstelligen.

Upgrade Steps – Overview 
Die Citrix VDI spezifischen teile sind in gelb markiert, in diesem Guide wird nur auf diese fokussiert.

Die abgebildete Tasksequenz wird zur Aktualisierung aller unserer Windows 10 Installationen verwendet darum wird in der Sequenz entschieden ob es sich um eine VDI handelt oder nicht.

Nach der Betriebssystemaktualisierung wird der VDA mittels dem existierenden Softwarepaket wieder installiert.

Weil der Windows Update auch die Citrix Receiver Installation verschiesse wird auch dieser zum Schluss neu installiert.

Der schwierigste Teil am ganzen ist die saubere Deinstallation des VDAs, worum es hier in der Tiefe geht.

VDI sein oder nicht sein – das ist hier die Frage
Weil nur eine Task Sequenz für den Update aller Geräte verwendet wird, checken wir zu begin ob der VDI Teil nötig ist. Dazu fragen wir einen Key ab der nur vorhanden ist wenn der VDA installiert ist.
Ein reboot tut immer gut

Manchmal fordert das VDACleanupUtility zu beginn  einen Reboot, darum machen wir diesen bevor wir wirklich mit dem Cleanup starten.

Erster Schritt der VDA Entfernung 

Das VDACleanupUtility soll im stillen Modus gestartet werden und der Neustart soll unterdrückt werden:

cmd /c VDACleanupUtility.exe /silent /noreboot

Das zu auf dem Screenshot sichtbare “Paket” ist nur die “Verpackung” der  VDACleanupUtility.exe

Nun muss die Post-Neustart-Aktion aus der Registry geputzt werden:

cmd.exe /c REG DELETE HKLM\Software\Microsoft
\Windows\CurrentVersion
\RunOnce /v CitrixVdaCleanup /f

Nun darf der Neustart gemacht werden

Cleanup Tool wieder starten

diesmal wieder im stillen Modus (/silent) aber auch mit dem Parameter dass der Reboot nun passiert ist (/reboot). Es ist etwas verwirrend, aber der /reboot löst keinen Reboot aus! Es gibt dem Cleanup-Tool nur die Phase an!  

cmd /c VDACleanupUtility.exe /silent /reboot

 Nun kommen alle Update Schritte die man machen will,
zu diesem Zeitpunkt sollte man auch Treiber installieren, also bei virtualisierten Umgebungen Hypervisor Tools wie XenTools, VMwareTools, etc. 
Nun wird der VDA wieder installiert
Und der Citrix Receiver re-installiert

Wie schon erwähnt verschiesst das Update den Receiver, darum wird dieser hier neu Installiert, selbstverständlich mit einem vorrangigen Cleanup

Ich möchte hier nochmals Stephane Thirion  (https://www.archy.net) für die Tipps betreffend der deinstallation des VDAs danken. Weiter möchte ich an dieser Stelle aber auch meine Kollegen Stefan Moser und Thomas Hahnel der Mobiliar erwähnen welche für die Erstellung dieses Artikels mit ihrem SCCM Knowhow und Ihrer Geduld zum testen unverzichtbar waren.

IoT – schöne neue Technologiewert | neue MyStrom Smart Devices

Wer mich kennt weiss das es in meinem Leben mehr gibt als nur Citrix Zeugs, ich bin auch ein Fan von IoT oder Enthusiast der Heimautomatisierung.

Seit schon einigen Jahren nutze ich Philips Hue, Netatmo und auch andere Gadgets welche mein Leben vereinfachen sollen. Oder anders gesagt Probleme lösen welche ich ohne die Technik nicht hätte. Einige meiner Nachbaren denken auch schon ich hätte eine Geliebte die Alexa heisst und ich sei manchmal ziemlich grob zu ihr …

In der Vergangenheit habe ich mich schon mal über den MyStrom Wifi Switch gebloggt im Artikel Steure ein MyStrom Wifi Switch mit einem Schalter oder Ein weiteres LaMetric IoT Script – Stromsteuerung.

Das spezielle bei den MyStrom Wifi Switches ist dass dieses für die Schweiz funktionieren. Wir haben hier in der Schweiz nicht die sonst in Europa gebräuchlichen Steckdosen. Aus diesem Grund ist MyStrom wohl auch eher ein Nischenprodukt mit einem relativ kleinen Markt, ich finde dies sehr Schade weil die Produkte von MyStrom echt gut sind!

Da ich eben etwas mehr raushole stehe ich ab und zu auch in Kontakt mit Personen hinter MyStrom. Und WOW, heute habe ich ein Paket von MyStrom erhalten dass es in sich hat. Die MyStrom Glühbirne und der MyStrom WiFi Button darf ich, ziemlich exklusiv, vor allen anderen antesten. Ich finde dies besonders spannend, da ich bereits ähnliche Produkte bei mir im Einsatz habe. Als Glühbirne leuchten bei mir bereits einige Philips Hue und in der Garage, wo ich zwar WLAN habe aber die Hue-Bridge nicht hin reicht spendet eine SengLed Boost Licht.
Auch als universeller Button habe ich bereits ein Amazon IoT Button im Einsatz, diesen benutze ich nach etwas basteln als Trigger für IFTTT.

In diesem Artikel möchte ich also die neuen Geräte von MyStrom geben das testen was schon auf dem Markt ist.

Vergleich Smarte  Glühbirne:

myStrom WiFi Bulb

  • 39.- CHF (Farbig)
  • Color
  • E27

+ Hat eine  REST API die via HTTP erreichbar ist
+ Zeigt Stromverbrauch
+ sehr echte, schöne Farben!
–  Nur 600 lm
– Die Glühbirne wird ziemlich heiss, 52,9°C nach einem 30min test.

Philips Hue

  • 69.- CHF (Farbig)
  • 20.- CHF (Weiss)
  • E27 and GU10 verfügbar

+ Verwendet das universelle ZigBee Protokoll
+ Gibt bis 806 lm von sich
– Ein zusätzliches Gerät, names “Bridge” ist nötig
– Farben sind nicht so satt
– ZigBee Brücke hat eine eher limitierte Reichweite, somit kann ich in meiner Garage keine Hue betreiben
– Die “Glühbirne” wird ziemlich heiss, 62,5°C nach einem 30min test.

SengLed Boost

  • 59.- CHF (Weiss)
  • E27

+ Funktioniert zusätzlich als Wireless Wifi Repeater
–  nur 470 lm

IKEA TRÅDFRI
LED-Lampe E27 1000 lm Weiss

  • 14.95 CHF (Weiss)
  • Farbig ebenfalls erhältlich aber nicht mit 1000lm
  • Nimmt 12,4 Watt
  • Ist kompatibel mit der Hue-Bridge und der neusten Firmware und eventuell Drittsoftware.

+ hellste und günstigste LED-Lampe
– Die “Glühbirne” wird ziemlich heiss, 84,9°C nach einem 30min test.

 

Fazit: Es gibt nicht DIE beste smarte Glühbirne, es hängt immer vom Anwendungsfall ab. Was ist wichtig, wie viel darf es sein und was soll es kosten. Falls schon ein Philips Hue Ökosystem existiert macht es wahrscheinlich Sinn weiterhin darauf zu setzen. Eine MyStrom Glühbirne kann falls WLAN vorhanden ist, ein Hue-System ergänzen. Wenn man nur eine einzelne smarte Glühbirne braucht wird MyStrom das richtige sein. Die Sengled Boost bietet keine APIs und es war nur mit etwas reverse Engineering möglich diese in die Hausautomation aufzunehmen .

Vergleich Smart Button:

MyStorm WiFi Button

  • 25.- CHF

+ Verfügbar in der Schweiz
+ Battery aufladbar
+ Von Haus aus IFTTT kompatibel
+ 3 Drück Patterns
+ Schnelle Reaktionszeit (< 2sec to toggle a Switch) Amazon IoT Button

  • 19.90$

– Nur für Amazon Prime customers
– Batterie nicht austauschbar
– Reaktionszeit relativ lange
+ IFTTT nur mit etwas basteln möglich
+ 3 Drück Patterns

Hue Tap

  • 69.-
    NICHT GETESTET!

– braucht eine Brigde
+ Brauch keine Batterie
+ 3 Knöpfe

Hue Dimmer Switch

  • 29.-

– braucht eine Brigde
– reagiert sehr schnell
– nur für die Steuerung von Geräten im Hue-Ecosystem (Glühbirnen) zu verwenden, kein IFTTT.

Conclusion: Für die meisten Heimautomatisierer ist der MyStrom Wifi button die beste Wahl, das Konfigurieren des AWS IoT button ist eher “advanced”. Mir persönlich passt es nicht dass der Amazon IoT Button keine austauschbare Batterie hat. Für grössere Hue Installationen sind diese Switches sicher gut geeginet.

StoreFront – Erneut einloggen ohne schliessen des Browsers

Mit Citrix StoreFront ist es möglich sich per Smart Card an dem Web Receiver anzumelden, jedoch ist es ein Sicherheitsfeature dass man nach dem Abmelden von der StoreFront Webseite der Browser geschlossen werden muss.
Ärgerlich für Leute, zum Beispiel Admins, die sich mit verschiedenen Konten an und abmelden wollen. Noch mehr ärgerlich wenn man viele Tab’s im Browser offen hat die man nicht schliessen möchte.

Nach der Abmeldung vom StoreFront sieht man diese Meldung:

You have logged off successfully. Please close your browser to protect your account. Sie haben sich erfolgreich abgemeldet. Schliessen Sie den Browser, um Ihr Konto zu schützen.

Sie haben sich erfolgreich abgemeldet. Schliessen Sie den Browser, um Ihr Konto zu schützen.

Wie die Meldung sagt handelt es sich um eine Sicherheitsfunktion und nicht um eine Fehler… Aber nicht in jedem Fall ist ein wieder anmelden ein Sicherheitsproblem. Beispielsweise wenn Smart Cards zwingend auch zum anmelden an der VDI nötig sind, ist ein wieder anmelden an der Webseite durchaus unproblematisch.

Im Rahmen des CTP Programms habe ich angefragt diese Funktion zu verbessern und dem StoreFront Administrator die Möglichkeit zu geben diese Funktion zu deaktivieren. Mein Wunsch wurde erhört und mit StoreFront 3.8 wurde das das Feature implementiert, jedoch vorerst nur “unter der Haube” und ohne ein Punkt im GUI.

Feng Huang, Principal Software Architect bei Citrix und Verantwortlich für StoreFront hat mir nun die Information gegeben wie es konfiguriert wird. Diese Info darf ich nun auch hier publizieren:

Alles was gemacht werden muss, ist die Zeile  CTXS.allowReloginWithoutBrowserClose = true in die Datei  C:\inetpub\wwwroot\Citrix\YOURSTORE\custom\script.js einzufügen.

DANKE Citrix das ihr auf uns hört und spezielle Wünsche umsetzt.

PowerManagement für dedizierte Citrix desktops? Klar mit Tags!

Habt ihr Tags bereits für XenApp & XenDesktop im Einsatz? Vielleicht gäbe es den einen oder anderen guten Anwendungsfall. Tags zu Resourcen, in meinem Fall virtuellen Desktops, können sehr mächtig sein speziell in Kombination mit Power Shell scripts. Es ist möglich Aktionen abhängig der Tags zu machen. Natürlich können Tags auch verwendet werden als Filter für Citrix Richtlinien (Policies) was ich auch als sehr hilfreich erachte.

Ich hatte das Problem das ich eine Bereitstellungsgruppe hatte mit dedizierten Windows 10 desktops und für dedizierte Desktops gibt es bekannter weise kein Power Management. Eigentlich ist ein Power Management dazu auch obsolet da herunter gefahrene Maschine beim anklicken im StoreFront wieder gestartet werden. Das Problem in unserer Umgebung ist jedoch das gewisse Desktops auch anders als über StoreFront angegangen werden und somit ausgeschaltete Maschinen ein Problem sind.
Wird eine Maschine somit herunter gefahren endet das in einem Incident Ticket.

Meine Lösung zu diesem Problem ist es, das ich diese speziellem Maschine mit einem tag “AlwaysOnline” im Studio versehe. Weiter habe ich dann das nachfolgende kleine Script geschrieben welches auf dem Delivery Controller alle 15 Minuten per Scheduled Task gestartet wird:

param([string]$tags=$(throw "Tag parameter is required"), [string]$poweroperation=$(throw "Power operaton parameter is required"))
#==============================================================================================
# Created on: 09.2016 Version: 0.2
# Created by: Sacha Thomet
# File name: PowerOperation-DependingMachineTags.ps1
#
# Description:  This is a Powershell to change the PowerState of VDI's or XenApp Servers in
#               a PowerManaged XenDesktop 7.x environment accodring to Tags.
#
# Prerequisite: None, a XenDesktop Controller with according privileges necessary
#
# Call by : Manual  or Scheduled Task
#==============================================================================================
# Load only the snap-ins, which are used
if ((Get-PSSnapin "Citrix.Broker.Admin.*" -EA silentlycontinue) -eq $null) {
try { Add-PSSnapin Citrix.Broker.Admin.* -ErrorAction Stop }
catch { write-error "Error Get-PSSnapin Citrix.Broker.Admin.* Powershell snapin"; Return }
}
# Change the below variables to suit your environment
#==============================================================================================

$maxmachines = "1000" # as default only 250 records, this increase it to 1000
#$tags = "AlwaysOnline" # if you comment out the param line you can have the tag here
#$poweroperation = "TurnOn"  # if you comment out the param line you can have the poweroperation here


$machines = Get-BrokerMachine -MaxRecordCount $maxmachines | Where-Object {$_.tags -eq $tags }


foreach($machine in $machines)
{
$machinename = $machine | %{ $_.MachineName }
Write-Host "Action $poweroperation will be performed for $machinename  "
New-BrokerHostingPowerAction  -Action $poweroperation -MachineName $machinename
}

Ich weiss ich weiss … dies ist ein sehr ungewöhnlicher Anwendungsfall, aber das Script Konstrukt soll in erster Linie aufzeigen was mit Tags möglich ist, die Möglichkeiten sind fast unbegrenzt!

Mein Beispielscript auf GitHub: PowerOperation-DependingMachineTags.ps1

Endlich 1.0 – aber noch lange nicht fertig!

Im November 2014 habe ich ein Artikel geschrieben über die Übernahme des HealthCheckScripts für XenApp & XenDesktop 7.x:
XenDesktop & XenApp FMA (7.x) HealthCheck – Oops!… I Did It Again

sheepsJetzt nach fast 2 Jahren fortlaufender Entwicklung dieses Scripts präsentiere ich die Version 1.0 des XenApp & XenDesktop HeathChecks.

Gestartet bin ich mit einer ziemlich rudimentären Version des Scripts und mittlerweile habe ich einige Tester und Mitwirkende bei diesem Script. Zwischenzeitlich ist das Script auch auf GitHub zu finden und es ist positiv überraschend wie viele Leute aus der Community bereits mit helfen das Script zu erweitern und verbessern.

Nachdem viele 0.xVersionen released wurden, ist jetzt neu auch die XML Konfigurationsdatei mit dabei. Diese Änderung, welche wir vor allem Stefan Beckmann zu verdanken haben, ist es Wert die Version nun 1.0 zu nennen.

xaxd-xml

Der grosse Vorteil der XML-Datei ist es, dass das Script und die Konfiguration von einander getrennt sind. Somit ist sowohl der Austausch des Scripts wie auch die Pflege von vielen verschiedenen Umgebungen kein Problem. Vorher musste nach dem Austausch des Scripts immer noch der Header angepasst werden.  Jetzt wird einfach nur das Script aktualisiert, sofern nichts im XML geändert hat bleibt dieses genau so bestehen.

 

Die XML Datei muss sich im gleichen Verzeichnis befinden wie das Script und der gleiche Namen haben, wie hier dieses Beispiel:

XA-and-XD-HealthCheck.ps1
XA-and-XD-HealthCheck_Parameters.xml

Wie bereits erwähnt wurde die XML Datei von Stefan Beckmann (Twitter: @alphasteff) integriert.

github

Die neuste Version des Scripts kann jeweils auf GitHub gefunden werden:
https://github.com/sacha81/XA-and-XD-HealthCheck 

html script output

Die HTML Ausgabe gewinnt von Version zu Version mehr Inhalt, schwierig ist es natürlich zu entscheiden welche Funktionserweiterungsanfragen berücksichtig werden und welche nicht. Jede weitere Funktion kann das Script unübersichtlicher machen und erhöht die Laufzeit des Scripts. Einige Funktionen können deshalb im XML ein und ausgeschaltet werden.

Aktuell wird von den Delivery Controller und den Worker Maschinen (XenApp Server und virtuelle Desktops) der Prozessor, der Festplattenplatz und der Ram Speicher gecheckt. Da in einer Umgebung mit der FMA Architektur problemlos unterschiedliche Versionen von VDAs im Einsatz stehen können, wird nun auch dies geprüft und ausgegeben. Weiter sind für die Störungssuche auch Informationen zu den Hypervisor Hosts in den Worker-Tabellen enthalten.

Dieser Code ist auf GitHub:

https://github.com/sacha81/XA-and-XD-HealthCheck/

Für Fehlermeldungen oder Funktionserweiterungsanfragen benutzt bitte direkt GitHub, natürlich freue mich auch über die Mitarbeit an den Scripts in GitHub!

Follow me on Twitter