Archiv für den Monat: Dezember 2013

Netscaler: Lange Wartezeiten bei cgi/setclient?wica nach Anmeldung

Dieser Fehler tauchte bei einer meiner Demoumgebungen auf. Nach dem Einloggen über die AccessGateway-Seite bekam man für ca. 20 Sekunden einen Ladebildschirm ohne Text. In der Url stand die AG-URL, jedoch mit dem Ende „/cgi/setclient?wica“. Die Citrix-Anwendungen gingen zwar auf, jedoch waren 20 Sekunden viel zu lange. Nach längerer Internet-Recherche bin ich zu dieser KB-Eintrag gestolpert von Citrix

http://support.citrix.com/article/CTX133946

In diesem KB-Eintrag ging es zwar um den Apple-Internet-Explorer „Safari“, jedoch half die Lösung. Mittels Putty auf den NetScaler verbinden und folgenden Text „Copy&Paste“:

add rewrite action close_conn_act insert_http_header Connection „\“close\““
add rewrite action retry_setclient_act insert_after_all „HTTP.RES.BODY(10000)“ q{„<script language=\“javascript\“ type=\“text/javascript\“>location.replace(‚/cgi/setclient\?wica‘);</script>“} -search „text(\“</head>\“)“
add rewrite policy conn_close_pol „HTTP.REQ.URL.CONTAINS(\“setclient\?wica\“) && HTTP.RES.STATUS.EQ(404)“ close_conn_act
add rewrite policy retry_setclient_pol „HTTP.REQ.URL.CONTAINS(\“setclient\?wica\“) && HTTP.RES.STATUS.EQ(404)“ retry_setclient_act
bind rewrite global conn_close_pol 1 NEXT -type RES_DEFAULT
bind rewrite global retry_setclient_pol 2 end -type RES_DEFAULT

Error: Unable to launch as the application is not currently available

Mein Problem: Bei meinen Tests mit den Citrix Machine Creation Services (kurz gesagt: MCS) bin ich über diesen Fehler gestolpert.

Dieser Fehler deutete auf eine nicht-registrierte VM hin. Jedoch waren alle VMs richtig registriert am DeliveryController.

Ebenso fand sich folgender EventEntry im EventLog:

nach etwas Recherche konnte dann auch die Lösung gefunden werden:

mittels Powershell-Kommando „Get-BrokerMachine“ konnte festgestellt werden, dass der Logon auf „Disabled“ war.

mittels Registry kann hier der Wert schnell Enabled werden:

HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\fDenyTSConnections

Diesen Wert entsprechend setzen und das Problem sollte gelöst sein: „0“ = Enable Connections, „1“ = Disable Connections

 

Citrix Storefront DNS Alias CNAME funktioniert nicht mit Domain-Passthrough

Aufgrund der meist kryptischen Computernamen verwendet man gerne CNAME’s (bzw. Alias-Adressen) um auf Ressourcen zugreifen zu können. Leider funktioniert dies beim Storefront nur bedingt, da bei der Verwendung von einem DNS-Alias es an der Authentifizierung scheitert. Fehlermeldungen wie „Unable to Launch Application“ seien meistens die Folge.

Grund: Um die Authentifizierung über Domain-Passthrough mit einem DNS-Alias gewährleisten zu können, muss auf dem Storefront-Server ein SPN (Principal-Name)-Eintrag erstellt werden.

Die Umgebung: Der Server-Name ist vm-dc-ctx01.newdesktop.local und ist über https aufrufbar. Als Base-Url ist https://vm-dc-ctx01.newdesktop.local hinterlegt. Es wurde ein Domain-Zertifikat für *.newdesktop.local verwendet um generell kein Problem mit der Namensverwendung zu haben.

Nun möchte man aber gerne die URL https://storefront.newdesktop.local verwenden.

Hierzu muss folgender eintrag beim Storefront-Server hinzugefügt werden:

setspn -a HOST/<FQDN Alias> <Servername>

Bsp: setspn -a HOST/storefront.newdesktop.local vm-dc-ctx01

Nach einem Computerneustart sollte nun alles funktionieren (mit „setspn -L“ kann überprüft werden ob der gewünschte Eintrag enthalten ist)

Wenn nun beim DNS-Server die TTL niedrig gehalten wird, kann hier auch schnell ein kleiner Failover gemacht werden wenn man 2 Storefront-Server hat. Somit gibt es auch keine Auswirkungen bei einem Neustart (natürlich noch besser: NetScaler 😉 )

Migrieren eines Datastores mithilfe von Software RAID

Grundsätzlich möchte ich euch hierzu ein bisschen mehr erzählen: Grund hierfür war nicht das Verschieben der VMs auf einen neuen Datastore sondern ein Alignment-Problem zwischen einer Netapp-Storage und eines XenServers. Die Systeme liefen stabil, jedoch war die Performance nicht die, die es sein sollte. Nach näherer Analyse seitens NetApp/XenServer wurde das Problem durch falsches Alignment festgestellt, jedoch waren die VMs alle auf Basis Server 2008 R2, also kann das grundsätzlich nicht stimmen (dieses Phänomen tritt nur unter Windows 2003 und kleiner auf). Es wurde weitergeforscht und schlussendlich konnte man auch den Auslöser finden: Das Anlegen der VMs – Linked Clones (hier gibt es ein Basis-Image und alle anderen VMs hatten dieses Image als verlinkt).  Grundsätzlich keine schlechte Sache, die VMs sind so schnell angelegt, aber die Performance die dabei verloren geht ist leider nicht tragbar.

Was kann man dagegen tun?

Grundsätzlich sind „LInked Clones“ unbedingt zu vermeiden da meistens das Storage schon derartige Deployment-Prozedere bietet (Bsp NetApp: XenServer Virtual Storage Console). Aber was tun mit den Bestehenden?

Hierfür gibt es eine schnelle Abhilfe: Software-RAID1!

Man bindet dem Hypervisor eine 2. HDD ein, gleichgroß wie die bestehende. Danach muss die Datenträgerverwaltung gestartet werden und der „Mirror“ kann beginnen. Dies muss Partition für Partition geschehen (Rechtsklick -> Mirror – ja so einfach kanns sein)

Nach erfolgreicher Synchronisierung der Platten kann der Server niedergefahren und die Disk „abgehängt“ werden. Im Boot-Menü erscheint nun das Auswahlfenster, wobei hier nun von der 2. HDD gebootet werden muss.

Nun kann der Mirror unter der Datenträgerverwaltung wieder aufgehoben werden.

Sollte dies die Systempartition gewesen sein kann der BootManager nun wieder deaktiviert werden mit folgendem Befehl (Auszuführen als Admin-CMD):

bcdedit /default  {current}

bcdedit /displayorder {current}

Das wars. Mit einer minimalen Downtime von einem Reboot können die VMs kopiert und verschoben werden wie es beliebt.

 

Netscaler 10.1 GUI Java Problem JRE 7.45

Die NetScaler-GUI ist ja Java-basierend. Da ja Java regelmäßig und in eher kurzen Intervallen Updates freigibt, habe ich für gewöhnlich das „automatische Update“ aktiviert. Nach dem Update von JRE 7.25 auf 7.45 jedoch dann das Problem: Das Java-Applet lässt sich nicht mehr laden und stoppt bei 1%.

Ursache: Die Netscaler-GUI ist nicht für Java 7.45 freigegeben.

http://support.citrix.com/proddocs/topic/ns-faq-map/ns-faq-config-utility-ref.html

Abhilfe: Update auf die aktuelle Version (10.1.e, build 120.1316.e) oder durch deaktivieren der Temporären Internet-Files von Java (General -> Temporary Internet Files -> Settings)

Danach bekommt man zwar immer die lästige Meldung „Do you want to run this application“, aber immer noch besser als gar nicht reinzukommen 😉