Heute hatten wir mal wieder ein ganz mysteriöses Problem mit unserem Citrix XenDesktop 5 Server. Bei den externen Clients, die sich bei uns in der Firma mit Ihren Desktop´s verbinden kam es immer wieder dazu, dass sich die ICA-Sitzungen nach einigen Minuten komplett eingefroren haben.

Das hat sich so geäußert, dass der virtuelle Desktop zwar für den Anwender noch sichtbar war, aber es ließ sich nicht mehr damit arbeiten bzw. anklicken. Es konnten keine Programme geschlossen werden, aber die Session war immer noch aktiv und sichtbar.

Erst wenn der Anwender das Citrix Fenster geschlossen hat und sich neu verbunden hat, so konnte er an der gleichen Stelle weiterarbeiten. Da passierte allerdings immer nach unterschiedlichen Zeitabständen, mal nach 4 Minuten, nach 10 Minuten, nach 20 Minuten usw.

Es war einfach keine Regelmäßigkeit zu erkennen. Es wurden auch nicht alle Sitzungen gleichzeitig eingefroren sondern immer abwechselnd. Ein Arbeiten war so fast nicht möglich.

Aber warum? Wir hatten am Citrix XenDesktop 5 Server nichts verändert! Weder Windows Updates noch irgendwelche Citrix Hotfixe eingespielt. Daran konnte es nicht liegen!

Dann hatten wir die Internetleitungen im Verdacht, dass diese evtl. kurz wegbrechen. Auch nicht. Dann haben wir die Netzwerkswitche untersucht, ebenfalls nicht. Auch das Neustarten des XenDesktop Servers brachte nichts, auch nicht des vorgeschalteten Citrix Access Gateways. Dort haben wir die Logfiles untersucht, aber auch hier war nichts zu finden.

Als letztes hatten wir dann versucht, die durchgeführte Änderung der Netzwerkmasken im Netzwerk wieder rückgängig zu machen, die wir vor einigen Tagen durchgeführt hatten. Aber warum sollte dies eigentlich den gewünschten Erfolg bringen, wenn es letzte Woche noch einwandfrei lief und die Änderung aber schon länger zurückliegt.

Also haben wir die Netzwerkmaske an die Clients angepaßt und siehe da, das war die Lösung. Warum auch immer muss die Netzwerkmaske des Citrix Access Gateways mit den XenDesktop Clients übereinstimmen, auch wenn die Verbindung mit verschiedenen Netzwerkmasken einwandfrei hergestellt werden konnte.

Ok, Hauptsache es läuft wieder! Solltet Ihr mal das gleiche Problem haben so schaut bitte Eure Netzwerkmasken durch – vielleicht habt Ihr ja das gleiche Problem!

Ähnliche Beiträge:

1. Citrix Session ID aus Druckername entfernen
2. Inconsistent server host ID – Citrix XenApp6 Lizenzserver Probleme
3. Citrix Event ID 9017 im Ereignisprotokoll eines XenApp Servers

Vor einigen Monaten habe ich schon einmal darüber berichtet (Citrix XenApp Probleme mit dem SP1 für Windows Server 2008 R2), dass es scheinbar noch massive Probleme gibt, wenn man auf einem bestehenden Citrix XenApp6 Server das Service Pack 1 für den Windows Server 2008 R2 installiert.

Dieses scheint nun endlich vorbei zu sein. Nachfolgend habe ich Euch mal zusammengeschrieben wie es zumindest mir gelungen ist, das SP1, den Internet Explorer 9  (IE9) und auch alle sonstigen Windows Updates einzuspielen, ohne das der XenApp Server Schaden nimmt.

Wichtig ist natürlich dass Ihr unbedingt vorher eine aktuelle Datensicherung des Servers habt, damit Ihr im Problemfall das System wieder in den Ausgangszustand zurückversetzen könnt. Bei mir war dies kein Problem, da die Server virtuell laufen und ich einfach eine Kopie der virtuelle Maschine angelegt habe.

Zunächst habe ich folgende Windows Updates installiert:

• Windows6.1-KB975777-x64.msu
• Neustart des Servers
• Windows6.1-KB979530-x64.msu
• Windows6.1-KB980663-x64.msu
• Windows6.1-KB2265716-x64.msu
• Windows6.1-KB2383928-x64.msu
• Windows6.1-KB2388142-x64.msu
• Windows6.1-KB2444328-v2-x64.msu
• Windows6.1-KB2465772-x64.msu
• Neustart des Servers

• XA600W2K8R2X64010.msp
• XA600W2K8R2X64012.msp
• XA600W2K8R2X64017.msp
• Neustart des Servers
• XA600W2K8R2X64021.msp
• XA600W2K8R2X64026.msp
• XA600W2K8R2X64029.msp
• Neustart des Servers
• XA600W2K8R2X64046.msp
• XA600W2K8R2X64060.msp
• XA600W2K8R2X64062.msp
• Neustart des Servers
• XA600W2K8R2X64068.msp
• Neustart des Servers

Ähnliche Beiträge:

1. Citrix XenApp Probleme mit dem SP1 für Windows Server 2008 R2
2. Inconsistent server host ID – Citrix XenApp6 Lizenzserver Probleme
3. Citrix Event ID 9017 im Ereignisprotokoll eines XenApp Servers

Das Service Pack 1 für Windows Server 2008 R2 ist ja bereits seit einigen Monaten auf dem Markt und macht eigentlich auf den normalen Windows Server 2008 R2 Servern keinerlei Probleme - bis heute.

Ich habe versucht auf einen Server unserer Citrix XenApp 6 Farm das Service Pack 1 (SP1) für Windows Server 2008 R2 zu installieren. Die Installation war kein Problem, nach 30 Minuten war das durch.

Danach ein Neustart und dann kam die Ernüchterung. Der Server lief zwar, nimmt aber keine Sessions mehr an. Aber liegt das wirklich am SP1??

Nach einiger Recherche stellte ich fest, dass XenApp 6 derzeit noch große Probleme mit dem Service Pack 1 für Windows Server 2008 R2 hat. Es gibt diverse Anleitungen, die das Problem evtl. beheben sollen.

Darunter auch das Citrix Hotfix XA600W2K8R2X64001, welches am besten vor der Installation des SP1 installiert werden sollte. Denn bei einer nachträgliche Installation des Hotfixes läuft die Installation des Updates nicht einwandfrei durch und dadurch ist ein Reset des Servers notwendig. Das Update ist allerdings trotzdem installiert.

Bei mir hat es nichts geholfen und ich kann derzeit jedem nur abraten, das SP1 für Windows Server 2008 R2 auf einem Citrix XenApp6 Server zu installieren. Sobald ich einen genauen Workaround kenne werde ich diesen hier veröffentlichen.

Ähnliche Beiträge:

1. Server 2008 R2 SP1 Installation auf Citrix XenApp6
2. Citrix XenApp 5.0 Installation Erfahrungsbericht Teil 1
3. Citrix Event ID 9017 im Ereignisprotokoll eines XenApp Servers

Vor einiger Zeit habe ich bereits Teil 1 der XenApp 6 Server Installation veröffentlicht und heute möchte ich nun mit Teil 2 fortfahren.

Im ersten Teil war ich fertig mit der Auswahl der XenApp 6 Serverrollen. Weiter geht es nun mit der Auswahl der Unterkomponenten:

Als optionale Komponenten ist der XML Dienst IIS Integration, der EdgeSight Agent und das Single Sign On Plug In auszuwählen. Ich habe in diesem Fall keine der 3 Komponenten mitinstalliert.

Danach erfolgt eine Anzeige, in der nochmals alles zusammengefaßt wird. Als ersten Punkt erkennt man auch gleich dass ein Neustart des Servers nun notwendig ist.

Danach geht es dann weiter mit der Installation des Lizenzserver. Dieser Lizenzserver hat mich bei meiner Installation ziemlich geärgert, ich bin in einem separaten Artikel (Inconsistent Server Host ID) bereits ausführlich darauf eingegangen.

Ich hoffe dass Ihr die Probleme nicht habt, die bei mir aufgetreten sind.

Nachdem der Lizenzserver und die Remotedesktopdienste-Rolle erfolgreich installiert wurden weist das XenApp Installationsprogramm darauf hin, dass ein unbedingter Neustart erforderlich ist. Erst danach wird die Installation der weiteren Komponenten fortgesetzt.

Es werden dabei u.a. folgende Komponenten installiert:

• Microsoft Visual C++ 2005 SP1 Redistributable (x64)
• Microsoft Visual C++ 2008 SP1 Redistributable (x64)
• Windows-Prozessaktivierungsdienst-Rolle
• Internetinformationdienste (IIS)-Rolle
• Microsoft Visual J# Version 2.0
• Webinterface

Nachdem die fehlenden Komponenten installiert wurden erscheint danach ein weiteres Fenster, dass die XenApp Serverrollen erfolgreich aktualisiert wurden.

Danach ist das System soweit installiert, es geht nun weiter mit der Konfiguration der 3 vorhandenen Serverrollen (XenApp, Webinterface und Lizenzserver).

Zunächst beginnen wir mit der Konfiguration des XenApp Servers und dem Erstellen einer neuen Serverfarm. Da ich in diesem Fall nur 1 XenApp 6 Server einrichte, erstelle ich eine neue Serverfarm. Es ist auf keinen Fall ratsam oder möglich, einen XenApp 6 Server zu einer bestehenden Citrix Farm mit einem Citrix Presentation Server 4.5 hinzuzufügen.

Nun ist der Name der neuen XenApp Farm einzugeben. Auch hier ist es absolut ratsam, als Farmname niemals den Namen des XenApp 6 Servers zu verwenden. Farmname und Servername sollten sich auf jeden Fall unterscheiden.

Desweiteren muss der Citrix Administrator Account angegeben werden in Form Domainname\Username.

Das Konfigurationsprogramm fragt nun nach den Citrix License Server Informationen. Hier könnt Ihr bereits einen existierenden Lizenzserver angeben oder die Informationen später definieren. Ich habe mich dazu entschlossen diese Informationen später zu hinterlegen.

Für die neue Serverfarm muss eine entsprechende Datenbank angelegt werden. Dies ist möglich auf einem bestehenden Microsoft SQL Server, falls Ihr bereits einen im Einsatz habt. Ich habe mich allerdings dazu entschlossen eine neue Datenbank anzulegen auf Basis einer Microsoft SQL Server Express Version.

Bei großen XenApp 6 Farmen sollte aber auf jeden Fall eine echte Microsoft SQL Server Datenbank erstellt werden, die Express Variante reicht dann nicht mehr aus.

Zusätzlich müssen dann noch die notwendigen Datenbank Eigenschaften und Zugriffsrechte für die Datenbank vergeben werden. Diese können bereits während des Konfigurationsvorgang getestet werden um zu prüfen, ob alles korrekt hinterlegt wurde.

Weiter geht es danach mit der Festlegung der Shadowing Einstellungen. Ich habe hier ausgewählt, dass die Shadowing Funktion auf dem XenApp 6 Server aktiviert wird.

Danach können weitere Einstellungen vorgenommen werden für den Bereich “Zone”, “XML-Service”, “Online Plug In” und “Remote Desktop Users”. Ich habe diese Einstellungen auf Standard belassen und bin mit der Konfiguration fortgefahren.

Nun wird der XenApp 6 Server entsprechend den Vorgaben konfiguriert. Dieser Vorgang dauert nur wenige Sekunden.

Nun wurde der XenApp 6 Server erfolgreich konfiguriert und abschließend steht ein erneuter Neustart des Servers aus.

Im Teil 3 der XenApp 6 Installation befasse ich mich dann mit der Konfiguration des Webinterfaces und des Lizenzservers. Hierzu in ein paar Tagen mehr.

Ähnliche Beiträge:

1. XenApp 6 Server – Installation Teil 1
2. Citrix XenApp 5.0 Installation Erfahrungsbericht Teil 3
3. Citrix XenApp 5.0 Installation Erfahrungsbericht Teil 2

Bei der Einrichtung eines XenApp6 Citrix Servers habe ich das Problem gehabt, dass immer wieder die Event ID 9017 im Ereignisprotokoll des Windows 2008 R2 Servers stand.

Der genaue Wortlaut der Fehlermeldung lautet:

Ereignis 9017, Metaframe:
Dieser Computer mit Citrix XenApp nimmt nun keine Verbindungen mehr an. Der
Lizenzierungskulanzzeitraum für diesen Server ist abgelaufen oder konnte nicht aktiviert werden.

Daraufhin habe ich das gesamte System untersucht und besonders den Citrix Lizenzserver betrachtet, der ebenfalls auf diesem Server installiert ist. Es konnte aber kein Problem festgestellt werden, der Lizenzserver lief einwandfrei und die eingespielten Citrix Lizenzen waren auch korrekt eingestellt.

Danach habe ich stundenlang eine Lösung im Internet gesucht, ohne Erfolg. Auch diverse Neustarts brachten keinen Erfolg, es kam immer wieder zu der gleichen Fehlermeldung.

Schließlich habe ich den “Citrix XenApp Server Role Manager” erneut aufgerufen und die XenApp Konfiguration nochmals überarbeitet. Entscheidend aber war, dass ich die vorhandene Serverfarm, in der nur dieser eine Server vorhanden war, nochmals gelöscht und neu aufgebaut habe.

Anschließend ist ein Serverneustart von Nöten gewesen und der Fehler 9017 im Ereignisprotokoll war verschwunden, warum auch immer.

Anschließend nahm der Server auch endlich die Verbindungen an.

Ähnliche Beiträge:

1. Citrix XenApp 5.0 Installation Erfahrungsbericht Teil 3
2. Citrix XenApp Probleme mit dem SP1 für Windows Server 2008 R2
3. Server 2008 R2 SP1 Installation auf Citrix XenApp6

Viele Anwender erhalten bei der Einspielung Ihrer Citrix XenApp6 Lizenzen in den Citrix Lizenzmanager (Citrix License Administration Console) die Fehlermeldung, dass die Einspielung der Lizenzen aufgrund einer inkonsistenten Server Host-ID abbricht.

Der genaue Fehlertext lautet:

Importinformationen
Lizenzdatei wurde erfolgreich auf C:\Program Files (x86)\Citrix\Licensing\MyFiles\license_20100611044256.lic hochgeladen.

Importfehler
Inkonsistente Serverhost-ID: C:\Program Files (x86)\Citrix\Licensing\MyFiles\license_20100611044256.lic.

Anscheinend gibt es Probleme im Lizenzmanager, der diese korrekt ausgestellten Lizenzen nicht erkennt. Ihr könnt dieses Problem aber umgehen, indem Ihr Eure Lizenzdatei in das Verzeichnis

“C:\Program Files (x86)\Citrix\Licensing\MyFiles\”

kopiert und anschließend den Dienst “Citrix Lizensierung” per Hand einmal neu startet. Dann werden die Lizenzen erfolgreich übernommen und Ihr könnt diese im Lizenzmanager hinterher einsehen.

Ähnliche Beiträge:

1. Server 2008 R2 SP1 Installation auf Citrix XenApp6
2. Citrix XenApp Probleme mit dem SP1 für Windows Server 2008 R2
3. Citrix Session ID aus Druckername entfernen

Heute möchte ich nach einiger Zeit mal wieder über die Installation eines Citrix-Servers berichten, aktuell handelt es sich um den XenApp 6 Server. Ich habe bereits vor einiger Zeit über die XenApp 5 Installation berichtet, die durchaus Ihre Probleme hatte.

Aus einem aktuellen Grund werden wir auf XenApp6 wechseln und ich möchte Euch heute kurz meine ersten Erfahrungen bekanntgeben.

Zunächst steht der Download der Installationsdatei an, eine ISO-Datei mit 4,5GB. Dieses habe ich zunächst auf eine DVD gebrannt. Installiert werden soll der XenApp6 Server auf einem Dell PowerEdge 710R werden mit Windows Server 2008 R2.

Der Start des Installationsprogramms von der DVD klappt problemlos und das Installationsprogramm stellte gleich fest, dass das “.Net Framework 3.5 SP1” auf dem System nicht installiert ist.

Daraufhin wurde das Service Pack 1 für .Net Framework 3.5 automatisch installiert. Dieses ist schon ein ganz klarer Fortschritt zu der Installation zum XenApp5, denn dort musste jede fehlende Komponente, und das waren nicht wenige, manuell installiert werden.

Leider gab es auch dieses Mal ein Problem, denn das Programm hing sich immer wieder auf. Ich habe den Vorgang mehrere Male durchgeführt und es lang letztendlich an der gebrannten DVD. Anscheinend hatte das Laufwerk Probleme beim Leser der DVD. Anschließend habe ich die gesamte DVD auf ein Installationsverzeichnis des Servers kopiert und von dort die Installation erneut angestartet.

In diesem Fall lief das Installationsprogramm einwandfrei durch.

Nach der Installation des SP1 für das .Net Framework dauerte es einige Zeit bis das erste Installationsfenster angezeigt wurde.

Zunächst ist es notwendig die fehlenden Serverrollen hinzuzufügen. Einfach auf “Serverrollen hinzufügen” klicken und das Installationsprogramm fragt die entsprechenden Komponenten nach und nach ab.

Es muss die gewünschte XenApp6 Serverversion gewählt werden. In meinem Fall handelt es sich um eine “Advanced Edtition“. Es steht aber auch die “Platinum Edition” und die “Enterprise Edition” zur Auswahl.

Anschließend muss der Citrix Lizenzvereinbarung zugestimmt werden.

Nun erfolgt die Auswahl der notwendigen Rollen. Es kann zwischen

- Lizenzserver
- XenApp
-  Webinterface
- Secure Gateway
- EdgeSight Server

gewählt werden.

Morgen werden ich dann vom 2. Teil der XenApp6 Installation berichten!

Ähnliche Beiträge:

1. XenApp 6 Server – Installation Teil 2
2. Citrix XenApp 5.0 Installation Erfahrungsbericht Teil 3
3. Citrix XenApp 5.0 Installation Erfahrungsbericht Teil 2

Standardmäßig sind in allen Citrix-Sessions, in den Druckernamen die Citrix Session ID (Sitzungs-Nummer) integriert.

Zum Beispiel:
“HP LaserJet 2055 auf DC (von Computername) in Sitzung: 5″

Damit können leider besonders ältere Programme, die auf dem Citrix Server installiert sind, nicht korrekt zusammenarbeiten. In den Programmen müssen teilweise die Druckernamen komplett hinterlegt werden, z.B. als Standarddrucker. Da aber bei jeder Neuanmeldung am Citrix Server die Session ID wechselt, müssen die Einstellungen täglich neu vorgenommen werden.

Die einzige Lösung ist, die Session ID aus dem Druckernamen zu entfernen. Nach einiger Recherche bin ich auf folgende Lösung gekommen.

Auf dem Citrix Server muss eine neue Policy angelegt werden, in meinem Fall habe ich sie “Legacy Printer” genannt.

In dieser Policy muss im Bereich “Printing / Client Printers” die Option “Legacy client printers” auf “Enable” gesetzt werden. Desweiteren muss die Option “When auto-creating client printers” auf “Create old-style client printers” aktiviert werden, so wie Ihr auf obigen Bild erkennen könnt.

Diese Policy ist dann noch den entsprechenden Usern bzw. Gruppen zuzuordnen. Desweiteren müßt Ihr darauf achten dass die Policy in der Rangfolge so hoch steht, dass diese Option nicht durch eine höhere Policy evtl. überschrieben wird.

Nachdem sich die entsprechenden User einmal neu am Citrix-Server angemeldet haben sind die Session ID Nummern aus dem Drucker Namen verschwunden.

Ähnliche Beiträge:

1. Inconsistent server host ID – Citrix XenApp6 Lizenzserver Probleme
2. Internet-Seiten (URL) über Citrix Server mit lokalem Browser öffnen
3. Citrix Event ID 9017 im Ereignisprotokoll eines XenApp Servers

Heute möchte ich über ein aktuelle Problembehebung berichtet, die mich schon länger beschäftigte. Es gibt teilweise massive Probleme, wenn sich Windows XP oder Windows Vista Clients mit einem Citrix Access Gateway über eine SSL Verbindung konnekten möchten. Warum auch immer kommt es nur bei bestimmten PC´s zu den nachfolgend beschriebenen Problemen. Es liegt definitiv nicht an unterschiedlichen Windows Versionen bzw. an der Hardware.

Nach der Anmeldung über das Webinterface des CAG´s und der Start einer Citrix Applikation kommt es zu der Meldung:

SSL/TLS Fehler:
Sie stufen den Aussteller “Verisign Class 3 Secure Server CA” des Sicherheitszertifikats des Servers nicht als vertrauenswürdig an.

Anschließend wird der Programmstart abgebrochen. Alle Maßnahmen, wie z.B. das Zertifikat lokal auf dem Client zu installieren usw., schlugen fehl. Ich hab mich dann mit Verisign in Verbindung gesetzt und bin zu folgender, erstaunlicher, Erkenntnis gekommen.

Es liegt an einem sogenannten Zwischen Zertifikat. Dieses Zwischenzertifikat wird von diversen Clients einfach manchmal nicht überprüft. Worum dass so ist kann ich derzeit nicht beantwortet, es ist aber definitiv so. Diese Fragen sollten wir mal an Microsoft, Mozilla oder Opera stellen.

Die Lösung dazu ist in diesem Fall allerdings relativ einfach. Einfach das korrekt “Zwischenzertifikat” auf dem “Citrix Access Gateway” installieren und dann sollte es funktionieren. Dies funktioniert wie folgt:

• Das korrekte Zwischenzertifikat von folgende Seite downloaden:
  http://www.verisign.com/support/verisign-intermediate-ca/secure-site-intermediate/index.html
• Das Zertifikat über die Zwischenablage in eine Datei kopieren und diese z.B. “intermediate.crt” nennen.
• Danach in der CAG Administrationskonsole das Zwischenzertifikat einspielen über
  - Administration
  - Secure Certificate Management
  - Manage trustet root certificates
  - Manage
  - Update Trusted Root Certificate
  - Dort die intermediate.crt importieren
• Die CAG neu booten

Danach kann die CAG mit allen Vista und XP Clients korrekt umgehen, egal ob die Clients Probleme mit dem Zwischenzertifikat haben oder nicht.

Bei mir lief es anschließend problemlos, alle Clients konnten sich korrekt auf die CAG verbinden.

Ähnliche Beiträge:

1. Fehler Datenausführungsverhinderung vom Windows Explorer beheben
2. Crypt32 – Ereignis ID 8 – Erklärung und Fehler beheben
3. Fehler 0x800703eb in WindowsUpdate.log beheben

Weiter geht es heute mit dem 3. Teil meines Erfahrungsberichtes über die Citrix XenApp 5.0 Installation. Wer Interesse hat kann hier den 1. Teil des Beitrages und auch den 2. Teil lesen.

Nach der Installation der XenApp Komponenten steht nun die Entscheidung an, diese Citrix Installation in eine bestehende Farm einzubinden oder eine neue Farm zu erstellen. Da ich dieses in diesem Fall in unserer Farm testen möchte, wähle ich “Bestehender Farm beitreten” aus.

Anschließend erfolgen dann noch einige Abfragen zum Citrix Lizenzserver und ob die Spiegelungsfunktion aktiviert werden soll oder nicht und inwieweit dieses beim Anwender nachgefragt werden soll und ob jeder Spiegelungsvorgang protokolliert werden soll.

Als Port für den Citrix XML-Dienst wähle ich den bereits vorgeschlagenen Port 80.

Anschließend sind die Benutzer der Gruppe “Remotedesktopbenutzer” hinzufügen.

Abschließend werden die gesamten Eingaben nochmals in einer Übersicht angezeigt. Das Fenster wird dann mit “Fertigstellen” beantwortet.

Nun erfolgt die Aktualisierung des Systems und die Produktkomponenten werden installiert. Dieser Vorgang dauert mehrere Minuten.

Man glaubt es kaum, aber nach einigen Minuten erscheint dann das erlösende Fenster “Citrix XenApp 5.0 wurde erfolgreich installiert”.

Ja, denkste. Das war´s dann immer noch nicht!!!

Ich habe mich schon gewundert, denn das Installationsfenster lag immer noch im Hintergrund. Nun startete ein weiterer Dialog, welcher mit herlich begrüßte mit

“Willkommen beim Installationsassistenten für die Erweiterte XenApp-Konfiguration”.

Schauen wir mal was uns da erwartet!

Zunächst ist das Installations Zielverzeichnis auszuwählen!

Danach erscheint ein weiteres Fenster “Bereit für die Installation der Anwendung“.

Danach erfolgt ein weiterer Kopiervorgang, der allerdings innerhalb von wenigen Sekunden durchgelaufen war. Dann erscheint mal wieder ein Fenster mit dem Inhalt “Die Erweiterte XenApp-Konfiguration wurde erfolgreich installiert“. Was zum Teufel hat er denn da nun installiert?

Ich hoffe jetzt ist endlich Schluß und ich habe die Installation erfolgreich durchlaufen. Aber kurze Zeit später erscheint ein weiterer Dialog.

Mir reicht´s jetzt mal wieder, ich höre auf für heute und mache evtl. morgen weiter. Ich melde mich dann mit dem Erfahrungsbericht Teil 4.

Ähnliche Beiträge:

1. Citrix XenApp 5.0 Installation Erfahrungsbericht Teil 2
2. Citrix XenApp 5.0 Installation Erfahrungsbericht Teil 1
3. Citrix XenApp 5.0 Installation Erfahrungsbericht Teil 4