– 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 😀

13. September 2018

Citrix ADC Version 12.1 49.23 TLS1.3 support

Filed under: Citrix,Netscaler — Schlagwörter: , , , , , , , , , , — Jan Mischo @ 09:13

Der Citrix Netscaler bzw. der Citrix ADC (Application Delivery Controller), wie er nun heißt, bekommt mit der aktuellen Build 12.1 49.23 TLS1.3 Support.

Nachdem die aktuelle Firmware heruntergeladen und auf die beiden ADCs kopiert wurde, fangen wir, wie üblich, mit dem Update des ersten bzw. des Standby Citrix ADC an. Hier vorab noch der offizielle Citrix KB Artikel zum Update: https://support.citrix.com/article/CTX127455

save config
shell

cd /var/nsinstall/build-12.1-49.23_nc_64/
tar -zxvf build-12.1-49.23_nc_64.tgz
#hier wird entpackt
./installns
#hier wird installiert
Reboot NOW? [Y/N] Y

Nach dem Reboot wieder mit der Secondary Citrix ADC Appliance verbinden und überprüfen, ob es tatsächlich die Secondary Appliance ist. 😉 Sofern dies der Fall ist, wird die HA Synchronisation deaktiviert und ein Failover erzwungen.

show ha node
#hier werden die Nodes und der Status angezeigt
set ha node -hasync disabled
force failover
exit

Jetzt geht es mit dem zweiten Citrix Netscaler weiter, der sich nun im Status der Secondary Appliance befindet. Dort wird der obige Vorgang einfach wiederholt.

save config
shell

cd /var/nsinstall/build-12.1-49.23_nc_64/
tar -zxvf build-12.1-49.23_nc_64.tgz
#hier wird entpackt
./installns
#hier wird installiert
Reboot NOW? [Y/N] Y

Direkt nach dem Reboot erneut mit der jetzigen Secondary Citrix ADC Appliance verbinden und mit

show ha node
#hier werden die Nodes und der Status angezeigt
force failover
exit

den HA Status prüfen sowie zurück schwenken, sodass die (alte) Primary Appliance wieder den Status „primary“ hat. Weiter geht es auf die (alte) Secondary Appliance, um dort den HA Sync wieder zu aktivieren.

set ha node -hasync enabled
exit

Nachdem dann jetzt nach dem Update der langweilige „Business as usual“ Teil hinter uns ist, können wir uns dem spannenden und neuen TLS1.3 widmen – Yay! 🙂 Dazu muss im ersten Step die neue SSL Cipher Group „TLSv1.3“ an einen VServer gebunden werden. In meinem Fall nehme ich dazu einmal unseren Unified Gateway Content Switching VServer sowie einen https CS VServer für unsere Exchange Bereitstellung. Zum Abschluss muss dann in den SSL Parametern natürlich noch TLS1.3 aktiviert werden.

bind ssl vserver <Name des Unified Gateway VServers> -cipherName TLSv1.3
bind ssl vserver <Name des Content Switch VServers> -cipherName TLSv1.3

set ssl vserver <Name des Unified Gateway VServers> -ssl3 DISABLED -tls1 DISABLED -tls13 ENABLED
set ssl vserver <Name des Content Switch VServers> -ssl3 DISABLED -tls1 DISABLED -tls13 ENABLED

Notiz am Rande: Um in den Genuss von TLS1.3 am Client zu kommen wird mindestens Google Chrome in Version 65 oder der Mozilla Firefox 61 benötigt.

Und zu guter Letzt die Frage nach dem Warum bzw. welche Vorteile bringt TLS1.3 jetzt?

  • TLS1.3 ist dank „Zero Round Trip Time“ schneller im Verbindungsaufbau (TLS1.2: 2 Round Trips; TLS1.3: 1 Round Trip)
  • TLS1.3 nutzt per default PFS (Perfect Forward Secrecy)
  • TLS1.3 verzichtet auf veraltete und unsichere Features
    • SHA-1
    • RC4
    • DES
    • 3DES
    • AES-CBC
    • MD5
  • TLS1.3 ist „einfacher“. Dadurch ist es durchaus schwieriger etwas falsch zu konfigurieren. 😉

Jetzt klappts auch wieder mit einem A+ bei SSLLabs.com!

Citrix ADC TLS1.3 A+

Citrix ADC TLS1.3 A+

 

23. Juli 2018

Migration von Exchange 2010 zu 2016

Filed under: Exchange,Windows Server — Schlagwörter: , , , , — Jan Mischo @ 11:37

Das Ende von Exchange 2010 steht „kurz“ bevor, daher hier noch einmal ein kleines How-To für die Migration von Exchange 2010 zu Exchange 2016.

Wie hier bereits erwähnt, werden mit dem Exchange 2010 SP3 RollUp 22 (endlich) Windows Server 2016 Domain Controller in der Active Directory Gesamtstruktur (Forest) unterstützt. Daher ist es jetzt möglich, die alten DCs und Exchange Server in „einem Schritt“ abzulösen. Das ist insbesondere bei Small Business Servern 2011 sehr hilfreich. 🙂 Somit steht einer Migration von Exchange auf SBS 2011 zu Exchange 2016 auf Server 2016 nichts mehr im Weg.

Die Systemanforderungen hat jedermann / jedefrau natürlich gelesen / überflogen. Die Installation der Vorbereitungen sowie des eigentlichen Exchange Servers 2016 (mit dem aktuellesten CU!) setze ich hier an dieser Stelle einmal ganz dreist voraus, so dass direkt mit den Vorbereitungen des Updates der Exchange Organisation losgelegt werden kann. Dazu sollte als erstes am Exchange 2010, sofern noch möglich, eine weitere Mailboxdatenbank mit einem Proxy-Postfach für die öffentlichen Ordner angelegt werden.

$Ex2010 = Get-ExchangeServer | ? AdminDisplayVersion -like "Version 14.3*"
$Ex2016 = Get-ExchangeServer | ? AdminDisplayVersion -like "Version 15.1*"
New-MailboxDatabase -Server $Ex2010  -Name PFProxyDatabase -IsExcludedFromProvisioning $true
Set-MailboxDatabase PFProxyDatabase -CircularLoggingEnabled $true
Mount-Database PFProxyDatabase

# Hier könnte man mit Invoke-Command die Mailbox vom Exchange 2016 auf dem 2010 erstellen, oder einfach und schnell die EMC auf dem Exchange 2010 öffnen und die Befehle dort ausführen. 😉
New-Mailbox -Name PFProxyMailbox1 -Database PFProxyDatabase -UserPrincipalName PFProxyMailbox1@[Domain].[tld] -Password $(ConvertTo-SecureString G3he!mesPW -AsPlainText -Force)
Set-Mailbox -Identity PFProxyMailbox1 -HiddenFromAddressListsEnabled $true
Vorbereitung Exchange 2010 PFProxyMailbox

Vorbereitung Exchange 2010 PFProxyMailbox

 

 

 

 

Sollte es auf dem Exchange Server 2010 (Standard) bereits 5 Datenbanken (z.B. 4x Postfachdatenbank / 1x öffentliche Ordner Datenbank) geben, bleibt nicht viel anderes übrig, wie die PFProxyMailbox1 in einer bestehenden Datenbank zu erzeugen. Wer möchte, der darf natürlich eine Datenbank leer räumen, diese löschen und dann die PFProxyDatabase samt PFProxyMailbox1 erstellen.

Weiter geht die wilde Migration von Exchange am neuen Server, wo die eben erstellte öffentliche Ordner Proxy-Mailbox (PFProxyMailbox1) zum Einsatz kommt und später die Zugriffe auf den legacy Exchange Server ermöglicht bis die öffentlichen Ordner komplett in die neue modern Public Folder übertragen wurden. Da es bei vielen Migrationen immer mal wieder zu Problemen mit MAPI over HTTP gekommen ist, bin ich dazu übergegangen und habe es für die Dauer der Migration deaktiviert. Nach erfolgreicher Deinstallation des legacy Servers aktiviere ich es dann wieder.

Set-OrganizationConfig -MapiHttpEnabled $false
Set-OrganizationConfig -PublicFoldersEnabled Remote -RemotePublicFolderMailboxes PFProxyMailbox1

# Zum Prüfen:
Get-OrganizationConfig | fl *PublicFolder*
Exchange 2016 Remote Public Folder aktivieren

Exchange 2016 Remote Public Folder aktivieren

 

 

 

 

Im nächsten Schritt wäre es sehr hilfreich, wenn der Exchange 2010 bereits nach Best Practice konfiguriert ist und die internen URLs der virtuellen Verzeichnisse gleich denen der externen URLs sind (SplitDNS). Sollte dies nicht der Fall sein – Don’t Panic! Dann wird SplitDNS eben umgehend eingeführt: https://jans.cloud/2014/09/exchange-2007-2010-2013-2016-virtuelle-verzeichnisse-zertifikate-splitdns/

# Ggfs. noch die erste / einzige Datenbank umbenennen und verschieben
Dismount-Database -Identity "Mailbox Database *" -Confirm:$false
Get-MailboxDatabase | Set-MailboxDatabase -name "Exch2016DB01"
Move-Databasepath -Identity "Exch2016DB01" -edbfilepath "d:\ExchangeDBs\Exch2016DB01\Exch2016DB01.edb" -logfolderpath "d:\ExchangeLogs\Exch2016DB01" -Confirm:$False
# Je nach Speicherplatz evtl. Umlaufprotokollierung für die Dauer der Migration aktivieren
# Get-MailboxDatabase | Set-MailboxDatabase -CircularLoggingEnabled $true
Mount-Database -Identity "Exch2016DB01" -Confirm:$false

# Receive Connector für den Mail-Empfang erstellen
New-ReceiveConnector -Name "Internet" -Usage Custom  -TransportRole FrontendTransport -PermissionGroups AnonymousUsers -Bindings 0.0.0.0:25 -RemoteIpRanges [IP der Firewall / SPAM Filter]

# Offline Adressbuch setzen
$OAB = Get-OfflineAddressBook | ? Identity -like "*(Ex2013)"
foreach ($Ex in Get-ExchangeServer ) { Get-MailboxDatabase -Server $Ex.Name | Set-MailboxDatabase -OfflineAddressBook $OAB }    

# Exportiertes Zertifikat vom Exchange 2010 installieren
$Cert = Import-PFXCertificate -FilePath "[Pfad zum Zertifikat].pfx" -CertStoreLocation Cert:\LocalMachine\My -Password $(ConvertTo-SecureString G3he!mesPW -AsPlainText -Force)

Get-OwaVirtualDirectory -Server $Ex2016 | Set-OwaVirtualDirectory -InternalUrl 'https://owa.[Domain].[tld]/owa' -ExternalUrl 'https://owa.[Domain].[tld]/owa'
Get-EcpVirtualDirectory -Server $Ex2016 | Set-EcpVirtualDirectory -InternalUrl 'https://owa.[Domain].[tld]/ecp' -ExternalUrl 'https://owa.[Domain].[tld]/ecp'
Get-OABVirtualDirectory -Server $Ex2016 | Set-OABVirtualDirectory -InternalURL 'https://owa.[Domain].[tld]/OAB' -ExternalURL 'https://owa.[Domain].[tld]/OAB'
Get-ActiveSyncVirtualDirectory -Server $Ex2016 | Set-ActiveSyncVirtualDirectory -InternalURL 'https://owa.[Domain].[tld]/Microsoft-Server-ActiveSync' -ExternalURL 'https://owa.[Domain].[tld]/Microsoft-Server-ActiveSync'
Get-WEbServicesVirtualDirectory -Server $Ex2016 | Set-WEbServicesVirtualDirectory -InternalURL 'https://owa.[Domain].[tld]/EWS/Exchange.asmx' -ExternalURL 'https://owa.[Domain].[tld]/EWS/Exchange.asmx'
Get-MapiVirtualDirectory -Server $Ex2016 | Set-MapiVirtualDirectory -InternalURL 'https://owa.[Domain].[tld]/mapi' -ExternalURL 'https://owa.[Domain].[tld]/mapi'
Get-ClientAccessService -Identity $Ex2016.Name | Set-ClientAccessService -AutodiscoverServiceInternalUri https://owa.[Domain].[tld]/autodiscover/autodiscover.xml

Get-OutlookAnywhere -Server $Ex2016 | Set-OutlookAnywhere -ExternalHostname owa.[Domain].[tld] -InternalHostname owa.[Domain].[tld] -ExternalClientsRequireSsl:$true -InternalClientsRequireSsl:$true -ExternalClientAuthenticationMethod 'Ntlm'

Enable-ExchangeCertificate -Thumbprint $Cert.Thumbprint -Services IIS, POP, SMTP, IMAP -Confirm:$false -Force
SplitDNS virtuelle Verzeichnisse

SplitDNS virtuelle Verzeichnisse

 

 

 

 

 

 

 

Bevor die erste Mailbox verschoben werden kann, sollte der neue Exchange Server noch zum bestehenden Sende Connector hinzugefügt werden. Sobald das erledigt ist, wird die erste Test-Mailbox verschoben und an einem Test Client die Hostsdatei bearbeitet sowie Outlook gestartet.

Get-SendConnector | Set-SendConnector -SourceTransportServers $(Get-ExchangeServer)

$Ex2016MBX = Get-MailboxDatabase -Server $Ex2016
New-MoveRequest Test.User -TargetDatabase $Ex2016MBX

Am oben genannten Test Client kann jetzt vorsichtshalber einmal die HOSTS-Datei bearbeitet werden und um die Einträge

  • [IP des Exchange 2016] owa.[DOMAIN].[tld]
  • [IP des Exchange 2016] autodiscover.[DOMAIN].[tld]

ergänzt werden.

HOSTS Datei am Test Client

HOSTS Datei am Test Client

 

 

 

Meldet sich der auserkorene Test User jetzt am Test Client an und öffnet Outlook, so sollte er zum letzten Mal in seinem Leben die folgende Nachricht erhalten:

Migration von Exchange am Client

Migration von Exchange am Client

 

 

 

 

Nach Bestätigung eben dieser Nachricht öffnet Outlook die Mailbox auf dem neuen Server und proxied die öffentlichen Ordner per PFProxyMailbox1 auf den legacy Server. Sobald der Test User sich vom ordnungsgemäßen Funktionieren des neuen Exchanges überzeugt hat, sollten die für SplitDNS konfigurierten Einträge auf den neuen Exchange Server geändert werden. Es kann nicht schaden die DNS Server Dienste einmal neu zu starten. Danach können die restlichen Postfächer inkl. der Arbitration-Mailboxes (Systempostfächer) verschoben werden.

Get-Mailbox -Server $Ex2010 -Arbitration | New-MoveRequest -TargetDatabase $Ex2016MBX
Get-Mailbox -Server $Ex2010 | New-MoveRequest -TargetDatabase $Ex2016MBX

# Mit einer kleinen Schleife lässt sich jetzt z.B. automatisch prüfen, ob alle Move Requests fertig sind..
do { Start-Sleep -Seconds 60; Get-MoveRequest | ? Status -ne "Completed" | Get-MoveRequestStatistics } until (!$(Get-MoveRequest | ? Status -ne "Completed"))

Während die Postfächer verschoben werden, kann an der Firewall / am SPAM Filter der Mailflow bereits auf den neuen Exchange gelenkt werden. Ist dies geschehen, kann mit der Überführung der alten öffentlichen Ordner in die neue modern Public Folder Strukturen begonnen werden -> KLICK 🙂

P.S.: Am Test Client sollte ASAP nach dem Test die HOSTS Datei wieder in den Ursprungszustand zurückversetzt werden. Es ist ja nicht so, dass einem so eine HOSTS Datei noch nie auf die eigenen Füße gefallen ist. 😉

29. Juni 2018

Probleme beim Update von Storefront 3.14 auf 3.15

Filed under: Citrix,Storefront — Schlagwörter: , , , — Jan Mischo @ 09:09

„CitrixStorefront-x64.exe component failed to install with error 0x00000643“ beim Update von Storefront 3.14 auf 3.15

In nächster Zeit müssen ein paar XenApp Farmen auf dem Current Release auf 7.18 geupdatet werden. Dabei werden auch diverse Storefront Server von 3.14 auf 3.15 aktualisiert. Der Citrix RSS Feed informierte heute über einen neuen CTX Artikel (CTX236287) in der Knowledgebase, dass es unter Umständen zu Problemen mit dem Update kommt. Wurde ein Storefront Server über die Version 3.5 bis auf 3.14 geupdatet, so wird es Probleme mit dem Update geben.

Weitere Erklärungen und die Lösung finden sich in der Citrix Knowledgebase: https://support.citrix.com/article/CTX236287

Daher am besten vor dem Update den Artikel lesen und unter „C:\inetpub\wwwroot\Citrix\<Store>“ die web.config auf eine Sektion „sessionManager“ prüfen. Ansonsten Backup der web.config erstellen, den PowerShell Code anpassen und ausführen.

Sollte jemand das Script ausführen, obwohl der Eintrag „sessionManager“ bereits vorhanden ist, so kann einfach das vorher erstellte Backup eingespielt werden. Beim öffnen der Storefrontkonsole erscheint ansonsten lediglich die Meldung, dass kein Store auf diesem Server sei. Folgt man dem Link zur Ereignissanzeige des Servers wird schnell klar, wo das Problem liegt:

Storefront 3.14 SessionManager

Storefront 3.14 SessionManager

 

Update Storefront 3.14 auf 3.15

Update Storefront 3.14 auf 3.15

 

Bei der Aktualisierung ist ein Fehler aufgetreten.

Citrix.DeliveryServices.PowerShell.Command.RunnerInterfaces.Exceptions.PowerShellExecutionException: Beim Ausführen eines PowerShell-Befehls ist ein Fehler aufgetreten. —> System.Exception: An error occurred while searching for the Store service: Der Abschnitts- oder Gruppenname „sessionManager“ wurde bereits definiert. Dies kann nicht mehrfach definiert werden. (C:\inetpub\wwwroot\Citrix\<Store>\web.config line 49).
— Ende der internen Ausnahmestapelüberwachung —
bei Citrix.DeliveryServices.PowerShell.Command.Runner.PowerShellCommandRunner.InvokeCommand(IPowerShellCommand command, Command powerShellCommand)
bei Citrix.DeliveryServices.PowerShell.Command.Runner.PowerShellCommandRunner.RunCommand(IPowerShellCommand command)
bei Citrix.DeliveryServices.Admin.Stores.PowerShell.StoresBL.GetStores()
bei Citrix.DeliveryServices.Admin.Stores.Controllers.StoresController.RefreshStoreList()

Older Posts »

Powered by WordPress