Upgrade Citrix Virtual Apps & Desktops auf 1903

Hier mal ein kleiner Bildband zum Upgrade eines Deployment auf Citrix Virtual Apps & Desktops 1903.

Die passenden Worte zum Upgrade CVAD 1903 Bildband gibt es hier: https://docs.citrix.com/en-us/citrix-virtual-apps-desktops/upgrade-migrate/upgrade.html

Da der Lizenzserver immer noch in der Version 11.15.0.0 Build 26000 aus Dezember 2018 vorliegt und somit keine Aktualisierung benötigt, ging es direkt mit dem ersten der beiden Storefront Server und dem Update von Storefront 1811auf die Version 1903 los. Dabei entstand auch dieser Artikel. 😉

An dieser Stelle kann der erste Storefront Server aus der Wartung und der zweite Storefront in Wartung genommen werden. Mit dem zweiten Storefront Server geht es dann nach einem Test beim ersten Bild wieder los. Im nächsten Step wird der erste bzw. die hälfte der vorhandenen Delivery Controller geupdated.

Sobald der erste Delivery Controller (samt ggfs. weiterer Komponenten auf diesem System) aktualisiert wurde, muss das Siteupgrade auf die Citrix Virtual Apps & Desktops 1903 durchgeführt werden.

Nach dem (hoffentlich) erfolgreichen Siteupgrade können die weiteren Delivery Controller registriert bzw. erst aktualisiert und dann entsprechend registriert werden. Ggfs. bietet es sich an vor dem Update der weiteren Desktop Delivery Controller einen kurzen Site-Test durchzuführen.

Wie im Ergebnis des Site-Tests zu sehen, wird „bemängelt“, dass im Active-Directory der „Administrator“ ‚NT-AUTORITÄT\SYSTEM‘ nicht gefunden werden kann. Irgendwie auch logisch. 😉 An dieser Stelle sollte man auch nicht auf die Idee kommen, einfach einen Account für den Dienst zu nutzen, der im Active Directory gefunden wird: https://docs.citrix.com/en-us/citrix-virtual-apps-desktops/secure/best-practices.html#configure-service-settings

Da es in diesem Deployment weder PVS noch MCS gibt, geht es in meinem Fall jetzt mit einer bzw. mehreren VDA(s) weiter.

An dieser Stelle: Herzlich willkommen in der wunderbaren Welt von Citrix Virtual Apps & Desktop 1903! 🙂

Storefront Update 1903 Fehler 0x000003E5 – Error Id: XDMI:D8924408

Das erste Update auf dem ersten Storefront Server der Gruppe stand an und begrüßte mich doch gleich mit einem Fehler:

Komponente ‚CitrixStoreFront-x64.exe‘ konnte nicht installiert werden und gab Fehler ‚0x000003E5‘ zurück.

Citrix Virtual Apps & Desktop Storefront 1903 Setup

Error Id: XDMI:D8924408
Ausnahme:
Citrix.MetaInstaller.Exceptions.MetaInstallerException Komponente ‚CitrixStoreFront-x64.exe‘ konnte nicht installiert werden und gab Fehler ‚0x000003E5‘ zurück.
bei Citrix.MetaInstaller.Server.Components.StoreFrontComponent.Install(InstallationContext context)
bei Citrix.MetaInstaller.InstallationManager.InstallComponent(IInstallableComponent component, InstallationContext installContext)

Fehlerdetails

In den Installationsprotokollen konnte leider wenig zum Fehler gefunden werden. Startete man allerdings die „CitrixStoreFront-x64.exe“ direkt aus dem Verzeichnis „D:\x64\Storefront“, so erhielt man den erneuten Übeltäter.

Nach einem „net stop CitrixTelemetryService“ in einer administrativen Commandline lief das Storefront Update auf die Version 1903 ohne Probleme durch.

Koexistenz Probleme mit Exchange 2010 und 2013 bis 2016

Verschiedene Konstellationen die zu Problemen beim Clientzugriff während der Koexistenz von Exchange 2010 und 2013 bis 2016 führen können.

Da ein Großteil unserer (Neu) Kunden jetzt so langsam anfängt Ihre Exchange Server 2010 in den wohlverdienten Ruhestand zu schicken stolpern diese, oder auch ich, immer mal wieder über entsprechende Konfigurationsfehler. Hier mal ein Überblick, was wie zu Problemen führt und wie diese beseitigt werden:

Client Access Array zeigt auf OWA, ECP, EWS URLs und / oder Outlook Anywhere Host (https://blogs.technet.microsoft.com/exchange/2013/05/23/ambiguous-urls-and-their-effect-on-exchange-2010-to-exchange-2013-migrations/):

  1. Den Link bitte aufmerksam lesen! Wer möchte darf auch noch das und das lesen. 🙂
  2. Die Lösung umsetzen und intern sowie extern per Outlook Anywhere mit dem Exchange verbinden
Set-OutlookProvider EXPR -OutlookProviderFlags:ServerExclusiveConnect
Set-OutlookProvider EXCH -OutlookProviderFlags:ServerExclusiveConnect

Sollte das, warum auch immer, nicht möglich sein, wäre ein anderer Schritt eine weitere Datenbank anzulegen und dort den RpcClientAccessServer auf den Exchange selber zeigen zu lassen sowie im Anschluss die Postfächer in die neue Datenbank zu verschieben. Sobald die User sich mit Outlook in der neuen DB verbunden haben, können diese weiter auf den neuen Exchange Server verschoben werden.

New-MailboxDatabase "Name_der_Datenbank"
Set-MailboxDatabase "Name_der_Datenbank" -RpcClientAccessServer Name_des_Exchange_2010
Get-Mailbox -Server Exchange_2010 | New-MoveRequest -TargetDatabase "Name_der_Datenbank"

Achtung: Speicherplatz beachten! Bzw. vorher gründlich planen. 😉

Die nächste Alternative wäre das ClientAccessArray aus den bestehenden Datenbanken zu entfernen und zu löschen. Sollte Autodiscover nicht funktionieren, müssen alle Outlook Profile von Hand neu eingerichtet werden. Aber Achtung: Auch wenn Autodiscover funktioniert, ist die Chance sehr hoch, dass viele Outlook Profile von Hand neu konfiguriert werden müssen!

Outlook Web App (OWA) Proxy von Exchange Server 2016 / 2013 zu Exchange 2010 ohne Funktion (:-( Da hat etwas nicht geklappt.):

Outlook Web App Koexistenz 2010 2016 Da hat etwas nicht geklappt.
Outlook Web App Koexistenz 2010 2016 Da hat etwas nicht geklappt.

Hier ist mir eben grade noch eine HTTP -> HTTPS Weiterleitung bzw. eine Umleitung auf /owa auf die Füße gefallen. Entsprechende Umleitungen können an diversen Stellen konfiguriert sein:

  1. In C:\inetpub\wwwroot\ die „iisstart.htm“ macht ein <META> Redirect.
    Lösung: Am besten die Standard iisstart.htm wieder bereitstellen oder eine leere.
  2. Eine „web.config“ mit entsprechende Umleitung / entsprechenden Umleitungen in C:\inetpub\wwwroot
    Lösung: web.config aus dem Verzeichnis verschieben. Bzw. Backup erstellen und löschen.
  3. HTTP-Umleitung im Internetinformationsdienste (IIS)-Manager (inetmgr)
    Lösung: HTTP-Umleitung im „inetmgr“ deaktivieren

Neben dem Umleitungs-Problem kann es ebenfalls noch ein Berechtigugnsproblem auf dem virtullen Verzeichnis für ECP und / oder OWA sein:

  1. Internetinformationsdienste (IIS)-Manager (inetmgr) starten und unter der „Default Web Site“ im „ecp“ und „owa“ Verzeichnis prüfen, ob die Windows-Authentifizierung aktiviert ist. Falls nicht, diese aktivieren und im rechten Teil in den „Aktionen“ unter „Anbieter…“ sicherstellen, dass „NTLM“ und „Negotiate“ ausgewählt sind. Siehe Bilder:

Kein Zugriff auf Verschobene Mailboxen (Der Informationsspeicher steht zurzeit nicht zur Verfügung) :

Die beschriebenen OWA (Outlook Web App) Probleme können ebenfalls die Ursache dafür sein, dass ein Zugriff mit Outlook auf ein bereits verschobenes Postfach per MAPI over HTTP bzw. Outlook Anywhere nicht möglich ist. Sollte es hier zu einem „komischen“ und „unerklärlichem“ Verhalten kommen, ggfs. die o.g. Schritte prüfen und durchführen. 🙂

Eine Weitere potenzielle Fehlerquelle könnten komplett vergessene öffentliche Ordner (Public Folders) oder eine nicht erstellte PFProxyMailbox sein (Siehe dazu: https://jans.cloud/2018/07/migration-von-exchange-2010-zu-2016/).

Kein Zugriff auf die öffentlichen Ordner auf dem Exchange 2010 (legacy Public Folder) mit Postfach auf einem Exchange Server 2016:

  1. Autodiscover für die Proxy Mailbox funktioniert nicht -> Der Proxy Mailbox eine SMTP Adresse konfigurieren, für die die passenden Autodiscover Records existieren. Aus PFProxyMailbox@domain.local würde dann PFProxyMailbox@jans.cloud werden.
  2. Bei Postfächern mit Problemen die DefaultPublicFolderMailbox konfigurieren:  
Set-Mailbox Ali.Gator -DefaultPublicFolderMailbox PFProxyMailbox

Bei weiteren Problemen / Fehler, die mir über den Weg laufen, werde ich den Beitrag updaten. Generell kann es natürlich nie schaden -> RTFM! 🙂