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

16. Juli 2018

Exchange und Remotedesktopgateway über eine IP veröffentlichen

Mit dem Netscaler VPX Express (Freemium) Exchange und Remotedekstopgateway bzw. Outlook WebApp, Outlook Anywhere, Exchange ActiveSync, Remotedesktopgateway und die Remotedesktop Web Services über eine öffentliche IP betreiben

Ich komme häufig in Kundenumgebungen, in denen es nur noch eine freie externe IP Adresse gibt, und dennoch die Exchange- sowie Remotedesktopdienste nach außen veröffentlicht werden sollen. Hier kann man jetzt „unschön“ ansetzen und die Ports für Exchange oder RDS auf z.B. 10443 verbiegen und damit in diverse andere Probleme laufen oder man bedient sich dem kostenlosen Netscaler VPX Freemium (formerly known as Netscaler VPX Express) und größtenteils dem Content Switching.

Ich würde an dieser Stelle einfach mal voraussetzen, dass der Exchange Server entsprechend sauber mit Split DNS konfiguriert ist, die Remotedesktopdienste ebenfalls funktionstüchtig sind und der Netscaler grundkonfiguriert ist. Ebenfalls sollte es ein vertrauenswürdiges SAN Zertifikat mit den passenden FQDNs geben. In meinem Beispiel:

  • „app.<domain>.<tld>“
  • „autodiscover.<domain>.<tld>“
  • „outlook.<domain>.<tld>“

Dieses Zertifikat muss im ersten Step auf dem Netscaler installiert werden. Dazu kann man sich zum Beispiel dem Citrix Knowledge Center bedienen: https://support.citrix.com/article/CTX205404

Der Einfachheit halber starte ich direkt mal mit dem Weg über das Command Line Interface bzw. per SSH. Evtl. wird der Beitrag ja später noch um eine GUI Variante erweitert. 🙂 Also legen wir als erstes die Server im Load Balancing an, erstellen die Dienste sowie die Load Balancing Virtual Servers (GUI: Traffic Management -> Server bzw. -> Services bzw. -> Virtual Servers):

add server SRV_EXCHSRV <IP ADRESSE DES EXCHANGES>
add server SRV_CBSRV <IP ADRESSE DES RDGW / RDWEB>

add service SVC_Exchange_SSL SRV_EXCHSRV SSL 443 -gslb NONE -maxClient 0 -maxReq 0 -cip DISABLED -usip NO -useproxyport YES -sp OFF -cltTimeout 180 -svrTimeout 360 -CKA YES -TCPB YES -CMP NO
add service SVC_RDWeb-RDGW_SSL SRV_CBSRV SSL 443 -gslb NONE -maxClient 0 -maxReq 0 -cip DISABLED -usip NO -useproxyport YES -sp OFF -cltTimeout 180 -svrTimeout 360 -CKA YES -TCPB YES -CMP NO
add service SVC_RDWeb-RDGW_UDP-3391 SRV_CBSRV UDP 3391 -gslb NONE -maxClient 0 -maxReq 0 -cip DISABLED -usip NO -useproxyport NO -sp OFF -cltTimeout 120 -svrTimeout 120 -CKA YES -TCPB YES -CMP NO

add lb vserver LB_VS_Exchange SSL 0.0.0.0 0 -persistenceType NONE -cltTimeout 180
add lb vserver LB_VS_RDWeb-RDGW SSL 0.0.0.0 0 -persistenceType SOURCEIP -cltTimeout 180
add lb vserver LB_VS_RDWeb-RDGW-UDP UDP 0.0.0.0 0 -persistenceType SOURCEIP -cltTimeout 120
bind lb vserver LB_VS_Exchange SVC_Exchange_SSL
bind lb vserver LB_VS_RDWeb-RDGW SVC_RDWeb-RDGW_SSL
bind lb vserver LB_VS_RDWeb-RDGW-UDP SVC_RDWeb-RDGW_UDP-3391

set ssl vserver LB_VS_Exchange -ssl3 DISABLED
set ssl vserver LB_VS_RDWeb-RDGW -ssl3 DISABLED
bind ssl vserver LB_VS_Exchange -certkeyName <NAME DES IMPORTIERTEN ZERTIFIKATES>
bind ssl vserver LB_VS_RDWeb-RDGW -certkeyName <NAME DES IMPORTIERTEN ZERTIFIKATES>

Damit die Server nicht „blank“ per http(s) erreichbar sind, schränke ich den Zugriff auf die gewollten Verzeichnisse des WebServer (IIS) ein (GUI: AppExpert -> Pattern Sets bzw. -> Rewrite -> Actions / Policies):

add policy patset patt_set_rdweb_path
add policy patset patt_set_exchange_path

bind policy patset patt_set_rdweb_path "/" -index 4
bind policy patset patt_set_rdweb_path "/rpcwithcert" -index 1
bind policy patset patt_set_rdweb_path "/rpc" -index 2
bind policy patset patt_set_rdweb_path "/rdweb" -index 3
bind policy patset patt_set_exchange_path "/mapi" -index 1
bind policy patset patt_set_exchange_path "/ecp" -index 2
bind policy patset patt_set_exchange_path "/owa" -index 3
bind policy patset patt_set_exchange_path "/oab" -index 4
bind policy patset patt_set_exchange_path "/ews" -index 5
bind policy patset patt_set_exchange_path "/autodiscover" -index 6
bind policy patset patt_set_exchange_path "/rpcwithcert" -index 7
bind policy patset patt_set_exchange_path "/rpc" -index 8
bind policy patset patt_set_exchange_path "/microsoft-server-activesync" -index 9

add rewrite action rew_act_exchange_invalid_path replace http.REQ.URL.PATH "\"/owa\""
add rewrite action rew_act_rdweb_invalid_path replace http.REQ.URL.PATH "\"/rdweb\""

add rewrite policy rew_pol_exchange_invalid_path "!http.REQ.URL.PATH.TO_LOWER.CONTAINS_ANY(\"patt_set_exchange_path\")" rew_act_exchange_invalid_path
add rewrite policy rew_pol_rdweb_invalid_path "!http.REQ.URL.PATH.TO_LOWER.CONTAINS_ANY(\"patt_set_rdweb_path\")" rew_act_rdweb_invalid_path

bind lb vserver LB_VS_Exchange -policyName rew_pol_exchange_invalid_path -priority 100 -gotoPriorityExpression END -type REQUEST
bind lb vserver LB_VS_RDWeb-RDGW -policyName rew_pol_rdweb_invalid_path -priority 100 -gotoPriorityExpression END -type REQUEST

In der GUI müssen die letzten beiden Schritte natürlich unter Traffic Management -> Load Balancing -> Virtual Servers und dann den entsprechenden LB VServern vorgenommen werden. Damit wären die Vorbereitungen der Load Balancing Objekte (Server, Dienste, virtuelle Server) fertig und es geht nahtlos über zum Conten Switching (Traffic Management -> Content Switching -> Policies bzw. Virtual Servers).

add cs policy CS_POL_Exchange -rule "http.REQ.HOSTNAME.TO_LOWER.STARTSWITH(\"outlook.<domain>.<tld>\") || http.REQ.HOSTNAME.TO_LOWER.STARTSWITH(\"autodiscover.<domain>.<tld>.de\")"
add cs policy CS_POL_RDWeb-RDGW1 -rule "http.REQ.HOSTNAME.TO_LOWER.STARTSWITH(\"app.<domain>.<tld>\") && http.REQ.HEADER(\"User-Agent\").SET_TEXT_MODE(IGNORECASE).CONTAINS(\"MS-RDGateway/1.0\")"
add cs policy CS_POL_RDWeb-RDGW2 -rule "http.REQ.HOSTNAME.TO_LOWER.STARTSWITH(\"app.<domain>.<tld>\") && http.REQ.HEADER(\"User-Agent\").SET_TEXT_MODE(IGNORECASE).CONTAINS(\"MSRPC\")"
add cs policy CS_POL_RDWeb-RDGW3 -rule "http.REQ.HOSTNAME.TO_LOWER.STARTSWITH(\"app.<domain>.<tld>\") && http.REQ.URL.REGEX_MATCH(re-^/RDWeb/*-)"

add ns httpProfile nshttp_profile_websocket -webSocket ENABLED

add responder action res_act_http_redirect respondwith q{"HTTP/1.1 301 Moved Permanently\r\nLocation: https://" + HTTP.REQ.HOSTNAME.HTTP_URL_SAFE + "/\r\n\r\n"}
add responder policy res_pol_http_redirect true res_act_http_redirect

add cs vserver cs_EXCH_RDS-SSL SSL <IP ADRESSE DES CONTENT SWITCH VSERVERS> 443 -cltTimeout 180 -caseSensitive OFF -httpProfileName nshttp_profile_websocket
add cs vserver cs_EXCH_RDS-SSL_HTTP_redirect HTTP <IP ADRESSE DES CONTENT SWITCH VSERVERS> 80 -cltTimeout 180
add cs vserver cs_RDS-UDP UDP <IP ADRESSE DES CONTENT SWITCH VSERVERS> 3391 -cltTimeout 120

bind cs vserver cs_EXCH_RDS-SSL -policyName CS_POL_Exchange -targetLBVserver LB_VS_Exchange -priority 5
bind cs vserver cs_EXCH_RDS-SSL -policyName CS_POL_RDWeb-RDGW1 -targetLBVserver LB_VS_RDWeb-RDGW -priority 10
bind cs vserver cs_EXCH_RDS-SSL -policyName CS_POL_RDWeb-RDGW2 -targetLBVserver LB_VS_RDWeb-RDGW -priority 11
bind cs vserver cs_EXCH_RDS-SSL -policyName CS_POL_RDWeb-RDGW3 -targetLBVserver LB_VS_RDWeb-RDGW -priority 12
bind cs vserver cs_EXCH_RDS-SSL_HTTP_redirect -policyName res_pol_http_redirect -priority 100 -gotoPriorityExpression END -type REQUEST
bind cs vserver cs_RDS-UDP -lbvserver LB_VS_RDWeb-RDGW-UDP

set ssl vserver cs_EXCH_RDS-SSL -ssl3 DISABLED
bind ssl vserver cs_EXCH_RDS-SSL -certkeyName <NAME DES IMPORTIERTEN ZERTIFIKATES>

Damit wären wir in der Theorie auch schon fertig. An der Firewall müssten jetzt noch die Ports tcp 80, tcp 443 sowie udp 3391 auf die <IP ADRESSE DES CONTENT SWITCH VSERVERS> genatted werden. Falls es jemanden aufgefallen ist: Ich erstelle ein neues httpProfile und aktiviere dort webSocket. Warum? Ohne aktivierte Web Sockets im http Profil lässt sich von einem „normalen“ Client über die mstsc.exe oder auch über RDWeb problemlos eine Verbindung herstellen. Sollte es Macs oder Clients mit der Microsoft Remotedesktop App geben, so wird man feststellen, dass eine Verbindung über die „modernen“ Clients (Windows 10 mit o.g. App, macOS, iPhone, iPad) nicht zustande kommt, da diese über eine Web Socket Verbindung gehen.

29. Januar 2016

Citrix Receiver und Outlook Anywhere vs. Telekom Navigationshilfe

DNS Probleme durch Telekom Navigationshilfe

An einem neuen Remote-Standort mit einem Telekom DSL Anschluss gab es das „Phänomen“, dass sich Outlook nicht mit dem Exchange Server und der Citrix Receiver sich nicht mit dem Netscaler verbinden lassen wollte. Kurz gesagt, das Problem liegt an der Telekom Navigationshilfe. Diese lässt sich nur im T-DSL Kundencenter deaktivieren:

Telekom Navigationshilfe

Telekom Navigationshilfe

 

 

 

 

 

Das Problem besteht im Fall des Citrix Receivers in der Beacon-Prüfung, ob er sich intern oder extern befindet und somit eine Verbindung über das Netscaler Gateway oder die Load Balancer VIP des Netscalers direkt auf den / die Storefront Server verbindet. Ein guter Beitrag zum Thema Beaconing: http://adamgamble.org/2013/12/09/citrix-storefront-beacons-explained/

Beim Exchange Server / Outlook Anywhere erfolgt die Prüfung intern oder extern durch einen Verbindungsversuch zum internen Exchange Server. Wird dieser nicht gefunden, nutzt Outlook den RPC Proxy. Da die Telekom Navigationshilfe jetzt den internen Host (falsch) auflösen kann, versucht Outlook erst gar nicht den RPC Proxy zu erreichen. Auch hier ein Link zum Thema Exchange und Outlook Anywhere: https://www.msxfaq.de/clients/oaclient.htm

 

 

Powered by WordPress