– Jan's Cloud – online Gedankenstütze ;)

8. November 2018

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 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/).

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

10. Februar 2018

Storefront Server 3.13 Synchronisierung schlägt fehl

Hinzufügen eines Storefront Server 3.13 auf Windows Server 2016 schlägt fehl „Fehler bei der Synchronisierung“

Bei einem Kunden sollte die Storefront Bereitstellung auf Storefront Server 3.13 upgedatet werden und gleichzeitig ein Upgrade der Betriebssysteme auf Windows Server 2016 stattfinden. Die vorhandenen Windows Server 2008 R2 Betriebssysteme mit Storefront 2.5 wurden über Storefront Server 2.6 zu 3.0 und schließlich auf 3.13 geupdated. Beim abschließenden Hinzufügen des neuen Storefront zur Bereitstellungsgruppe gab es den „Fehler bei der Synchronisierung“.

Storefront Server 3.13 Fehler bei Synchronisierung

Storefront Server 3.13 Fehler bei Synchronisierung

 

 

 

Ein Blick in die Ereignisanzeige des verteilenden Servers brachte Licht ins Dunkel:

Ein Fehler ist aufgetreten beim Konfigurationsaktualisierungsprozess für alle Server.
Citrix.DeliveryServices.ConfigurationReplication.Exceptions.ServerUpdateConfigurationException, Citrix.DeliveryServices.ConfigurationReplication, Version=3.13.0.0, Culture=neutral, PublicKeyToken=e8b77d454fa2a856
Beim Ausführen des folgenden Befehls ist ein Fehler aufgetreten: ‚Install-DSFeatureClasses‘
File ‚C:\Program Files\Citrix\Receiver StoreFront\PowerShellSDK\Modules\Citrix.StoreFront.Authentication.CitrixAGBasic\Citrix.StoreFront.Authentication.CitrixAGBasic.psd1‘ already exists (attempted to copy from ‚C:\Program Files\Citrix\Receiver StoreFront\Features\CitrixAGBasicAuthentication\Modules\Citrix.StoreFront.Authentication.CitrixAGBasic\Citrix.StoreFront.Authentication.CitrixAGBasic.psd1‘)
In C:\Program Files\Citrix\Receiver StoreFront\Services\ConfigurationReplicationService\Cmdlets\ConfigurationReplicationServiceModule.psm1:86 Zeichen:9
+ Install-DSFeatureClass „$($installPath)$($featurePackage)“
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
RemoteEndpoint: net.tcp://<Neuer Knoten>/Citrix/ConfigurationReplication

Storefront Server 3.13 Ereignis-ID 31 (2801)

Storefront Server 3.13 Ereignis-ID 31 (2801)

 

 

 

 

 

 

 

 

Der nächste Blick nach der Ereignisanzeige ging in Richtung Logfiles. Diese finden sich unter „C:\Program Files\Citrix\Receiver StoreFront\Admin\logs\“. Hier empfiehlt es sich in das letzte geschriebene Log nach dem Fehler zu gucken. In diesem Fall ist es InstallClass CitrixAGBasicAuthentication_<Datums- und Zeitstempel>.txt. Dort findet sich Ähnliches wie im Ereignis mit der ID 31 (2801) aus der Ereignisquelle Citrix Konfigurationsreplikation:

CopyTemplateFiles Attempting to install files and folders for feature to C:\Program Files\Citrix\Receiver StoreFront\PowerShellSDK\CopyTemplateFiles failed: Citrix.DeliveryServices.Framework.Install.Exceptions.FileOverwriteException: File ‚C:\Program Files\Citrix\Receiver StoreFront\PowerShellSDK\Modules\Citrix.StoreFront.Authentication.CitrixAGBasic\Citrix.StoreFront.Authentication.CitrixAGBasic.psd1‘ already exists (attempted to copy from ‚C:\Program Files\Citrix\Receiver StoreFront\Features\CitrixAGBasicAuthentication\Modules\Citrix.StoreFront.Authentication.CitrixAGBasic\Citrix.StoreFront.Authentication.CitrixAGBasic.psd1‘)

Die Ereignisanzeige meldet hier „nur“ ein Problem, dass die Datei bereits vorhanden ist. Im Log findet sich dann allerdings der Hinweis, dass die bereits vorhandene Datei „Citrix.StoreFront.Authentication.CitrixAGBasic.psd1“ im Verzeichnis „C:\Program Files\Citrix\Receiver StoreFront\PowerShellSDK\Modules\Citrix.StoreFront.Authentication.CitrixAGBasic\“ nicht überschrieben werden kann.

Damit der Storefront Server 3.13 in die bestehende Gruppe aufgenommen werden kann reicht es jetzt aus, den Ordner „Citrix.StoreFront.Authentication.CitrixAGBasic“ im Verzeichnis „C:\Program Files\Citrix\Receiver StoreFront\PowerShellSDK\Modules“ umzubenennen und die Synchronisierung erneut anzustoßen.

Storefront Server 3.13 Ordner umbenannt

Storefront Server 3.13 Ordner umbenannt

 

 

 

 

 

 

 

Nach diesem kleinen Eingriff ist der erste Windows Server 2016 in die Storefront Server Gruppe aufgenommen. Im nächsten Schritt die Service Group am Netscaler um den neuen Storefront ergänzen, mindestens einen weiteren Storefront unter Server 2016 aufnehmen und die Server 2008 R2 deinstallieren.

17. August 2017

Get-ADPrincipalGroupMembership Fehler bei Gruppen mit Slash

Fehler beim Auslesen von Gruppenmitgliedschaften mit Get-ADPrincipalGroupMembership bei Gruppen mit „/“ (Slash) im Namen

Bei der Erstellung eines PowerShell Scriptes welches basierend auf Gruppenmitgliedschaften verschiedene Exchange-Eigentschaften der User setzen sollte ergab sich ein Problem mit dem CMDLet Get-ADPrincipalGroupMembership:

Get-ADPrincipalGroupMembership Fehler

Get-ADPrincipalGroupMembership Fehler

 

 

 

 

 

Get-ADPrincipalGroupMembership: Der Client konnte die Anforderung aufgrund ein es internen Fehler nicht verarbeiten. Wenn Sie weitere Informationen zum Fehler erhalten möchten, aktivieren Sie entweder IncludeExceptionDetailInFaults (entweder über das ServiceBehaviorAttribute oder das <serviceDebug>-Konfigurationsverhalten) für den Client, um die Ausnahmeinformationen zurück an den Server zu senden, oder aktivieren Sie die Ablaufverfolgung gemäß der Microsoft .NET Framework 3.0 SDK-Dokumentation, und prüfen Sie die Serverablaufverfolgungsprotokolle.
Bei xxxxx Zeichen:41
+ if ( (Get-ADPrincipalGroupMembership <<<< $User.DistinguishedName) xxxxx ) {
+ CategoryInfo: NotSpecified: (CN=xxxxx\,…xxxxx,DC=xxxxx :ADPrincipal) [Get-ADPrincipalGroupMembership], ADException
+ FullyQualifiedErrorId: Der Client konnte die Anforderung aufgrund eines internen Fehler nicht verarbeiten. Wenn Sie weitere Informationen zum Fehler erhalten möchten, aktivieren Sie entweder IncludeExceptionDetailInFaults (entweder über das ServiceBehaviorAttribute oder das <serviceDebug>-Konfigurationsverhalten) für den Client, um die Ausnahmeinformationen zurück an den Server zu senden, oder aktivieren Sie die Ablaufverfolgung gemäß der Microsoft .NET Framework 3.0 SDK-Dokumentation, und prüfen Sie die Serverablaufverfolgungsprotokolle.,Microsoft.ActiveDirectory.Management.Commands.GetADPrincipalGroupMembership

Dieser Fehler tritt scheinbar auf, sobald der User Mitglied einer Gruppe mit einem „/“ ist. In diesem Fall hieß die Gruppe „02 Lohn / FiBu“. Nach der Umbenennung der Gruppe in „02 Lohn FiBu“ ließ sich das PowerShell Script mit CMDLet Get-ADPrincipalGroupMembership problemlos ausführen.

 

21. Juni 2017

Citrix VDA Update 7.x Error

Filed under: Citrix,Windows Server,XenApp — Schlagwörter: , , , , , , , , — Jan Mischo @ 09:38

Berechtigungsfehler in der Registry beim VDA Update auf 7.14.1

So.. Nach langer Zeit der Pause bzw. des Arbeitens in mehreren Projekten und dem ein und anderen Urlaub gibt es hier endlich nochmal etwas Neues zu lesen! 🙂

Bei uns im Rechenzentrum stand das Update einer Menge XenApp Server VDAs von Version 7.x auf 7.14 an. Die Vorbereitungen und Tests dazu hielten mich in den letzten sonnigen und heißen Tagen am Arbeiten. Vereinzelt kamen dabei noch Windows Server 2008 R2 sowie überwiegend Windows Server 2012 R2 in den Genuss des Updates. Wie so häufig lief der erste Schwung der Updates vollkommen problemlos ab und es gab keinerlei Komplikationen.

Im zweiten Schwung gab es dann aber, wie sollte es auch anders sein, 3 rebellierende Server (2x Windows Server 2008 R2 / VDA 7.6.3 sowie 1x Windows Server 2012 R2 / VDA 7.11). Im XenDesktop Installer Log (%LocalAppData%\Temp\Citrix\XenDesktop Installer\XenDesktop Installation.log) gab es dann die ersten Hinweise (Zeilen mit $ERR$) auf die verursachende Komponente:

06:38:59.1015 $ERR$ : XenDesktopSetup:Failed to load cached objects System.InvalidOperationException: Die Auflistung wurde geändert. Der Enumerationsvorgang kann möglicherweise nicht ausgeführt werden.
bei System.ThrowHelper.ThrowInvalidOperationException(ExceptionResource resource)
bei System.Collections.Generic.List`1.Enumerator.MoveNextRare()
bei Citrix.MetaInstaller.InstallationManager.CalculateComponentInstallOrder(IInstallableComponentGroup group, List`1& prereqs, List`1& downloads, List`1& components, Dictionary`2& hasBeenAdded, ICollection`1 groupsToInstall)
bei Citrix.MetaInstaller.InstallationManager.CalculateComponentInstallOrder(ICollection`1 groupsToInstall)

06:41:44.0170 $ERR$ : XenDesktopSetup:Installation von MSI-Datei ‚IcaTS_x64.msi‘ mit Fehlercode ‚InstallFailure‘ fehlgeschlagen (1603).
06:41:44.0180 $ERR$ : XenDesktopSetup:InstallComponent: Failed to install component ‚ICA für Remotedesktopdienste‘. Installation von MSI-Datei ‚IcaTS_x64.msi‘ mit Fehlercode ‚InstallFailure‘ fehlgeschlagen (1603).
06:41:44.0190 $ERR$ : XenDesktopSetup:Recording installation failure. Installation of the ICA für Remotedesktopdienste failed with error code 1603. Log Path: C:\Users\<der VDA installierende User>\AppData\Local\Temp\Citrix\XenDesktop Installer\MSI Log Files\IcaTS_x64516922318.txt

Das im Logfile aufgeführte Logfile IcaTS_x64 ist leider ziemlich unübersichtlich. Daher habe ich hier erst einmal aufgehört zu forschen und im EventLog mein Glück versucht. Dazu aber gleich mehr. Im oben genannten Log zur VDA Installation findet sich zum Zeitpunkt des Fehlers folgendes:

MSI (s) (B8:08) [06:41:22:197]: Product: Citrix HDX TS (retail) — Error 1402. Could not open key: HKEY_LOCAL_MACHINE32\SOFTWARE\Citrix\EUEM\LoggedEvents. System error 5. Verify that you have sufficient access to that key, or contact your support personnel.

Im Eventlog findet sich zeitgleich und zum Glück etwas übersichtlicher wie im MSI VDA Log:

VDA Installation Fehler Registry

VDA Installation Fehler Registry

 

 

 

 

 

 

Wem der Eventlog ebenfalls zu unübersichtlich ist, der darf auch gerne im Anwendungs-Log nach der Quelle „MsiInstaller“ und „Fehler“ filtern. Da sollte es nicht allzuviel zu finden geben.

Schnell in die Registry und dem <VDA installierenden User> Vollzugriff auf den ENUM Key sowie den LoggedEvents Key jeweils unter HKLM\SOFTWARE\Wow6432Node\Citrix\ erteilen. Als nächstes die Ica_TS_x64.msi von der Installations DVD aus <LW>:\x64\Virtual Desktop Components\TS installieren. Nach dem erforderlichen Reboot kann dann der Rest der Server VDA installiert werden.

Older Posts »

Powered by WordPress