Stichwort Suche

Monat: Dezember 2017

Sophos UTM One Time Password – 2 Faktor Auth – Exchange OWA und ECP

Die Sophos UTM bietet die Möglichkeit eine 2 Faktor Authentifizierung Einzurichten, diese dann u.a. für Exchange OWA und ECP genutzt werden kann.

Die OTP Einrichtung und weitere Anwendungmöglichkeiten findet ihr hier:

Der Grundaufbau

Es gibt einen CAS Server und die Sophos fungiert als Reverse Authentication Gateway mit OTP (One Time Password) und Reverse Proxy.

Als OTP Generator wird der Google Authenticator genutzt. Es gibt von Sophos auch einen eigenen. Der Google Authenticator kann aktuell in Verbindung mit der Sophos nur SHA1.

Damit die Authentifizierung zwischen der Sophos und dem Exchange in einem durchläuft und der User sich nur einmal am Sophos Frontend anmelden muss, muss die Anmeldung für OWA und ECP auf Basic ( Standard ) Authentifizerung umgestellt werden. Da ich aber für die User im internen Netzwerk weiterhin die Formular Basierte Authentifizierung für OWA und ECP nutzen möchte habe ich eine weitere Website im IIS definiert und ein neues ECP und OWA virtual directory erstellt und nur auf diesem die Authentifizierung angepasst.

Zu beachten dabei – wenn ein CU installiert wird, wird diese neu erstelle Website nicht geupdatet, sie muss also einmal entfernt und wieder eingerichtet werden.

Alternativ, wenn intern auf die Formular Basierte Anmeldung verzichtet werden kann, kann für die Default virtual directorys auch direkt Standard Authentifizierung genutzt werden. Dann muss keine sepearte Website erstellt werden.

 

OWA / ECP mit OTP

Ist OTP aktiviert muss der User um auf OWA zugreifen zu können sich an dem Sophos Front End Authentifizieren.

Dazu muss er seinen Benutzernamen eingeben und als Kennwort sein Windows Kennwort + dahinter die Authenticator PIN

Also ist sein Passwort normalerweise “Geheim” muss er nun z.B. “Geheim989778” eingeben.

Danach wird er zur OWA Seite weitergeleitet:

 

Das Doing

Ich Empfehle vor der Einrichtung sich mit dem Thema IIS, Authentifierzung etc. auseinander zu setzen. Einrichtung auf eigene Gefahr.

  • Exchange zusätzliche IP Adresse zuweisen
  • IIS Website erstellen
  • Secondary OWA und ECP erstellen
  • Authentifizierung anpassen
  • Sophos einrichten

IP Adresse:

Dem Exchange Server weise ich keine seperate NIC zu, sondern ergänz die vorhandene um eine weitere IP Adresse.

Damit sich diese aber NICHT im DNS registriert muss ich das ganze über die Powershell machen.

Zum nachlesen gerne hier https://blogs.technet.microsoft.com/rmilne/2012/02/08/fine-grained-control-when-registering-multiple-ip-addresses-on-a-network-card/

Netsh Int IPv4 Add Address <Interface Name> <IP Address> SkipAsSource=True

“Interface Name” is the name of the interface for which you want to add a new IP address.

“IP Address” is the IP address you want to add to this interface.

z.B:

Netsh Int IPv4 Add Address Ethernet 172.16.20.4 255.255.255.0  SkipAsSource=True

Mit diesem Befehl wird die DNS Registrierung dann für diese IP nicht durch geführt.

Zusätzliche Directorys erstellen

Zum nachlesen gerne hier:

Configuring Multiple OWA/ECP Virtual Directories on the Exchange 2013 Client Access Server Role

  1. Add a secondary IP address to the server– this could be with another NIC, or done just by adding an IP to an existing NIC.
  2. If you added a NIC, in the network properties, uncheck ‘register this connection in DNS’ in IPv4 for the NIC (this also prevents IPv6 from registering too as it happens).
  3. Create the additional website in IIS in a new root folder (C:\inetpub\OWA_SECONDARY) and bind it to the new IP. Enable for SSL, choose whatever certificate you want to use for this site.
  4. Give the local IIS_IUSRS group Read and Execute permission to the C:\inetpub\OWA_SECONDARY folder.
  5. Copy the Default Web Site root folder contents in its entirety including any subfolders to the new site root folder (i.e. copy %SystemDrive%\inetpub\wwwroot\ contents to C:\inetpub\OWA_SECONDARY).
  6. Create new OWA and ECP subfolders in your new web site’s root folder (C:\inetpub\OWA_SECONDARY\OWA, C:\inetpub\OWA_SECONDARY\ECP).
  7. Copy the entire contents of the Default Web Site OWA and ECP folders including any subfolders to the new subfolders for new web site. (Copied from /…/FrontEnd/HttpProxy).
  8. Run the following (substituting <Server> for the server hosting the CAS role);
    1. New-OwaVirtualDirectory -Server <Server> -Role ClientAccess -WebSiteName OWA_SECONDARY -Path “C:\inetpub\OWA_SECONDARY\OWA”
    2. New-EcpVirtualDirectory -Server <Server> -Role ClientAccess -WebSiteName OWA_SECONDARY -Path “C:\inetpub\OWA_SECONDARY\ECP”owa2
  9. Run the following to set the default site to IWA only (this is optional, but provided in case you want to do this);
    1. Set-OwaVirtualDirectory -Identity “<server>\owa (Default Web Site)” -FormsAuthentication $false -WindowsAuthentication $true
    2. Set-EcpVirtualDirectory -Identity “<server>\ecp (Default Web Site)” -FormsAuthentication $false -WindowsAuthentication $true
  10. Perform an IISReset.
  11. Test! Really, make sure you do.

Danach sind die Verzeichnisse erstellt:

(SecondaryOwaBasic)

Authentifizierung anpassen

Für die erstellten Verzeichnisse OWA und ECP

Sophos Anpassung

Zuerst muss ein Reverse Proxy für den Exchange angelegt werden. Dieser wird dann um die Reverse Authentication und Site Path Routing Regeln erweitert, sodass für OWA und ECP das OTP genutzt werden muss.

Reverse Authentication Profile erstellen:

ACHTUNG bei dem Prefix ist der Backslash WICHTIG. ( Ohne geht es nicht – scheinbar ein Bug 😛 )

Site Path Routing für /ecp und /owa anpassen damit dafür die Reverse Authentication genutzt werden muss.

Ziel ist die zweite IP Adresse des Exchange Servers !

 

 

Die Site Path Routen sind nun in der Übersicht sichtbar.

Eigener Mailserver mit Dynamischer IP Adresse

Zuhase den eigenen Exchange Server hosten ist was feines. Einige werden sich Fragen, warum man sowas braucht, aber wenn der Beruf das Hobby ist – oder das Hobby der Beruf 🙂 – braucht man sowas.

Die große Hürde Zuhause:

  • Private DSL Anschlüsse haben keine feste IP Adresse
  • Es kann kein PTR Eintrag gesetzt werden
  • Dyn DNS und MX Records….

Nun könnte man einfach einen POP3 Connector nutzen, aber das ist ja langweilig. Zudem möchte man ja Active Sync etc. nutzen.

 

Dyn DNS Anbieter

Dyn  DNS Anbieter gibt es viele, aber ich habe mich für eine Domäne von Strato entschieden. Bei Strato gibt es die Möglichkeit die Domain DNS Einstellung auf Dyn DNS abzuändern.

Nun kann aber wenn DynDNS aktiviert ist für diese Domain keine weiteren A-Records o.ä. mehr erstellt werden, bzw. der MX Eintrag abgeändert werden.

Ist aber nicht schlimm, für die A-Records werden einfach Subdomains angelget, welche auch auf die DNS Einstellung “DynDNS aktiviert” umgestellt werden:

IP Updater Tool

Um das Update für alle Domains ausführen zu können kann das Tool “DirectUpdate” genutzt werden.

 

Und für das Problem mit dem MX-Record kann das Tool auch abhilfe schaffen.

 

So wird dann auch der MX Record angepasst 🙂

 

Fehlender PTR Eintrag

Bei der Strato Domain ist ein Email Postfach inklusive. Somit kann man die Email über Strato verschicken, indem man den Strato SMTP Server als Smart Host nutzt.

 

Der Test

Als SMTP Proxy und Reverse Proxy nutze ich eine Sophos UTM als virtuelle Appliance, welche in der Home Version kostenlos ist.

Microsoft Connectivity Analyzer ist erfolgreich.

 

 

Sophos WebProtection – Office365 Exceptions

Damit Office365 korrekt funktioniert, wenn eine Sophos WebProtection als Proxy dazwischen hängt sind folgende Ausnahmen nötig. ( STAND 01.03.2018 )

^https?://([A-Za-z0-9.-]*\.)?office365\.com/
^https?://([A-Za-z0-9.-]*\.)?office\.com/
^https?://([A-Za-z0-9.-]*\.)?skype\.com/
^https?://([A-Za-z0-9.-]*\.)?skypeforbusiness\.com/
^https?://([A-Za-z0-9.-]*\.)?signup.microsoft\.com/
^https?://([A-Za-z0-9.-]*\.)?home.office\.com/
^https?://([A-Za-z0-9.-]*\.)?portal.office\.com/
^https?://([A-Za-z0-9.-]*\.)?agent.office\.com/
^https?://([A-Za-z0-9.-]*\.)?outlook.office365\.com/
^https?://([A-Za-z0-9.-]*\.)?login.microsoft\.com/
^https?://([A-Za-z0-9.-]*\.)?portal.microsoftonline\.com/
^https?://([A-Za-z0-9.-]*\.)?graph.microsoft\.com/
^https?://([A-Za-z0-9.-]*\.)?onmicrosoft\.com/
^https?://([A-Za-z0-9.-]*\.)?live\.com/
^https?://([A-Za-z0-9.-]*\.)?smtp.office365\.com/
^https?://([A-Za-z0-9.-]*\.)?login.windows\.net/
^https?://([A-Za-z0-9.-]*\.)?outlook\.com/
^https?://([A-Za-z0-9.-]*\.)?ceipmsn\.com/
^https?://([A-Za-z0-9.-]*\.)?edgesuite\.net/
^https?://([A-Za-z0-9.-]*\.)?microsoft\.com/

Skype for Business – Polycom CX600 daily logoff

Bei einem Kunden ist plötzlich das Phänomen aufgetreten, dass morgens alle Telefone ausgeloggt waren.
Auf dem Display wurde als Fehler “Anmeldefehler” Melden Sie sich bei einem anderen Ort ab, und versuchen Sie es erneut. Sie haben die maximale Anzahl zulässiger Computer oder Geräte erreicht.” angezeigt.

Der Skype Client von intern und extern war nicht betroffen..

Nach dem Überprüfen der Einstellungen, Konfiguration, DHCP Server Logs/Optionen, Netzwerkeinstellungen und den Telefon Logs gab es erstmal keine Auffäligkeiten. Man hat noch zusätzlich festgestellt das, dass Problem auftritt sobald Abends das Veeam Backup läuft.

Komisch? Veeam? Hä!

Nach weiterer Suche ist mir aufgefallen, dass es auf diversen Servern ( ein Domäne Controller und dem Skype for Business Frontend ) zwar keine “Fehler” im Event Log angzeigt werden, aber eine ganz unauffälige Warnung.

Time-Service ID 50

Und zwar wird diese Warnung immer generiert – na? , genau – nachdem das Backup fertig ist -spannend.

Also habe ich mal geschaut auf welchem Host die VMs liegen und tada, beide auf dem gleichen.

Bei allen anderen VMs die auf zwei andern Hosts liefen gab es den Fehler nicht.

Also die Einstellungen von dem Host überprüft und festgestellt, das der NTP Dienst angehalten ist.

 

So lief der Host mal schön fünf Minuten vorraus..

Was ist nun passiert?
Veeam nimmt sich nachdem der Snapshot entfernt wurde die Uhrzeit vom Host und setzt diese in der VM als Uhrzeit. Bis sich nun die VM über den PDC im Netzwerk wieder die Richtige Uhrzeit gezogen hat ist der delay so groß, das sich alle Telefone ausgeloggt haben…

NTP aktiviert > Veeam Backup > alles Gut > Kunde glücklich

 

Exchange 2016 – Neue Mailbox – Error Load balancing failed to find a valid mailbox database

Wenn ein neues Exchange Postfach angelegt wird, und keine Datenbank explizit als Ziel ausgewählt wird kommt der Fehler:

“Load balancing failed to find a valid mailbox database.” error creating new mailbox.

In diesem Fall einmal die Eigenschaften der einzelnen Datenbanken überprüfen.

Wenn der Wert “IsExcludedFromProvisioning” auf “true” steht, wird die Datenbank von der Provisionierung ausgenommen.

Damit die Datenbank trotzdem dafür genutzt werden kann muss der Wert auf “false” geändert werden.

Exchange 2016 / Skype for Business – MSExchange OAuth Error

Auf dem Exchange Server sind im Eventlog Fehlermeldungen:

MSExchange OAuth Event ID: 2008. When retrieving metadata from the url ‘https://ldomain.com/metadata/json/1’, different certificate(s) have been found.

Das kann passieren, wenn auf dem Skype for Business Server neue Zertifikate eingespielt wurden und dem Exchange Admin keiner Bescheid gesagt hat.

Um den Fehler zu beseitigen muss man die Partner Application auf dem Exchange Server entfernen und neu registrieren.

Partner Applikation anzeigen lassen:

Get-PartnerApplication

Die Betroffene Applikation entfernen:

Remove-PartnerApplication LyncEnterprise-ba4dd*

 

Und danach wieder neu erstellen:

Dazu in den Ordner “exscripts” wechseln.

.\Configure-EnterprisePartnerApplication.ps1 -AuthMetadataUrl ‘https://sf4b.domain.com/metadata/json/1’ -ApplicationType Lync

Migration Exchange 2010 to 2016 Client Connectivity

Bevor ihr den Beitrag hier lest, empfehle ich euch die Beiträge aus der Kategorie “Microsoft Exchange Server Basics“.

Vor der Migration

Die Zeichnung zeigt den internen Verbindungsaufbau bei einer Exchange 2010 Umgebung mit einem Exchange Server ( HUB, Mailbox und CAS Rolle ) vor dem Migrations beginn.

 

Es gibt einen Exchange 2010 Server ( Name “jr-legacy-ex01” mit der IP 172.16.20.11 ). Der Exchange 2010 Server muss für eine Co Existenz mit Exchange 2016 mindestens SP3 Updaterollup 11 installiert haben.

Der Exchange Server nutzt für die virtuellen Verzeichnisse als -internalurl und -externalurl den gleichen DNS Namen. Im SCP ( -internaluri ist “autodiscover.rehbergerold.de” hinterlegt )

Als RpcClientAccessServer ist der FQDN vom Exchange Server hinterlegt. Ein ClientAccessArray ist nicht definiert.

Achtung! Dieser Name darf extern im DNS nicht auflösbar sein. Mehr Infos dazu hier: https://blogs.technet.microsoft.com/exchange/2013/05/23/ambiguous-urls-and-their-effect-on-exchange-2010-to-exchange-2013-migrations/

Auf dem DNS Server ist ein Split DNS angelegt. Die URL “mail.rehbergerold.de” und “autodiscover.rehbergerold.de” zeigen auf den Exchange 2010 ( jr-legacy-ex01)

 

Auf den Exchange ist ein Zertifikat von der internen Zertfizierungsstelle hinterlegt.

Der CAS Server ist der internen Active Directory Site zugwiesen.

 

Installation Exchange 2016

Nachdem das Schema und Domäne für den Exchange 2016 vorbereitet wurde, kann man mit der Installation beginnen.

Was passiert nun?

Der Exchange Server wird der Exchange Organisation hinzugefügt und direkt wie ein Familien Mitglied behandelt, es wird also fleißig untereinander kommuniziert.

Die Installation erstellt einen SCP für den Exchange 2016, definiert die virtuellen Verzeichnisse mit den FQDN des Exchange 2016 und hinterlegt ein selbstsigniertes Zertifikat.

Nun kann es passieren, dass der Outlook Client in ein Autodiscover Update Interval läuft, oder gerade jemand Outlook startet und dadurch der SCP von dem Exchange 2016 genutzt wird – “graue Striche”, anstelle dem des Exchange 2010 ( eigentlich soll der Outlook Client den ältestens SCP nutzen – sprich der von dem Exchange 2010 – aber so wirklich 100%tig bestätigen konnte ich das noch nicht 🙂 ).

Das ist blöd, da der User dann eine Zertifikats Warnung bekommt, da er dem Selbstsignierten Zertifikat nicht traut.

Dies lässt sich aber verhindern. Ich habe schon Blog Einträge gelesen, die empfohlen haben währen der Installation den erstellen SCP händisch im Active Directory zu löschen. Das würde ich jetzt nicht bevorzugen scheint aber wohl zu funktionieren..

Man könnte auch eine eigene Site im Active Directory definieren, aber am einfachsten finde ich immer noch -> vorbereitet sein und direkt nachdem die installation fertig ist den SCP abzuändern, sodass er die gleiche URL nutzt wie der Exchange 2010 – siehe Bild unten “graue Striche”.

So frägt der Client zwar den SCP von dem Exchange 2016 an, aber dieser hat nun “autodiscover.rehbergerold.de” hinterlegt, sodass der Client diesen Namen auflöst und dieser hat ja noch als Ziel den Exchange 2010 im DNS hinterlegt.

Man kann nun also in Ruhe auf dem Exchange 2016 die -internalUrl´s und -externalUrl´s definieren und ein neues Zertifikat einspielen ohne das die User etwas davon mitbekommen.

 

Test Verbindung zu Exchange 2016

Nun kann man die Verbindungen von einem Test Client einmal zu dem Exchange 2016 lenken.

Dazu einfach die Host Datei anpassen und die Adressen umleiten – in diesem Beispiel “mail.rehbergerold.de” und “autodiscover.rehbergerold.de” auf die 172.16.20.12 abändern.

Autodisocover etc. sollte keine Zertifikatswarnungen geben und EX2016 OWA Zugriff sollte auf das Postfach welches noch auf dem EX2010 liegt funktionieren.

Solange das Postfach noch auf dem Exchange 2010 liegt wird weiterhin die RPC/TCP Verbindung direkt zum RpcClientAccessServer / CasArray aufgebaut.

RPC/HTTP ( Outlook Anywhere ) wird also noch nicht genutzt.

Desweiteren kann man auf dem Exchange 2016 ein Postfach erstellen, das direkt in der neuen EX2016 Datenbank platziert wird. Mit dem Testclient kann man dann testen, ob RPC/HTTP ( Outlook Anywhere ) funktioniert.

Funktioniert soweit alles wie gewohnt, kann das DNS für alle angepasst werden.

Zudem kann die Verbindung von extern auch auf den Exchange 2016 geleitet werden.

 

Erster Mailbox Move

Exchange 2016 ( oder auch 2013 ) können keine RPC/TCP Verbindungen mehr aufbauen. Daher wird der Outlook Client, wenn das Postfach verschoben ist RPC/HTTP ( Outlook Anywhere ) nutzen. Outlook Client Voraussetzungen / Update Anforderungen beachten!!

Was passiert nun bei dem Move?
Der Outlook Client merkt, das sich etwas verändert hat und bringt eine Meldung, das er neugestartet werden muss.

Nach dem Neustart ist in dem Outlook Profil nicht mehr der Exchange 2010 “RpcClientAccessServer” oder “ClientAccessArray” in den Einstellungen hinterlegt, sondern die Benutzer Postfach GUID ( Benutzer die PostfachGUID@domaine.com )

Wichtig! Es können nur Postfächer verschoben werden, wenn die DNS Einträge auf den EX2016 verweisen! Intern und Extern!

Danach mit dieser Mailbox Email Empfang und Email Versand testen, sowie ggf. Email Signatur o.ä. Anbindungen.

Allgemeiner Move

Ist der Test in Ordnung können alle weiteren Postfächer verschoben werden.

 

Exchange 2013 – Basis Verbindungsaufbau

-InternalUrl und -ExternalUrl wurden zu besseren veranschaulichung mit unterschiedlichen FQDN´s dargestellt.

,

Exchange 2013 unterstützt kein RPC/TCP mehr. Statdessen kommt RPC/HTTP ( Outlook Anywhere ) oder MAPI/HTTP zum Einsatz.

 

Intern:

Der Outlook Client hat sich über Autodiscover das Profil eingerichtet.

In dem Profil ist kein “RpcClientAccessServer” oder “ClientAccessArray” mehr hinterlegt, stattdessen ist von dem jeweiligen Benutzer die PostfachGUID@domaine. hinterlegt.

Ob Outlook nun RPC/HTTP oder MAPI/HTTP verwendet hängt von folgenden Faktoren ab:

  • Organisationseinstellung (MapiHttpEnabled-Wert) – Was in der Exchange Organistation Konfiguration unter “MapiHttpEnabled” eingestellt ist ( $true oder $false )
  • Benutzer- oder Postfacheinstellung (MapiHttpEnabled-Wert) – Was auf der Userpostfach Ebene unter “MailEnabled” eingestellt ist ( $true oder $false )
  • Benutzer- oder Postfacheinstellung (MapiBlockOutlookExternalConnectivity-Einstellung) – ..

Für Outlook Anywhere werden die -InternalURL und -ExternalURL Werte von Get-Outlookanywhere verwendet.

Für MAPI/HTTP werden die -InternalURL und -ExternalURL Werte von Get-MapiVirtualDirectory verwendet.

 

RPC/HTTP:

Interner Client über Outlook Anywhere. Schön zu sehen ist über welchen “Proxyserver” ( CAS Server ) die Verbindung aufgbaut wird.

 

MAPI/HTTP:

Ist MAPI/HTTP aktiviert:

Der Client bekommt per Autodiscover die Angaben zu MAPI/HTTP mitgeteilt:

Outlook verbindet sich darüber:

Anfrage zur im MAPI Verzeichnis hinterlegten URL:

 

Der Reiter von Outlook Anywhere verschwindet:

 

Extern:

RPC/HTTP – identisch zu Exchange 2010….

 

MAPI/HTTP:

Client versucht sich zum -InternalURL Pfad vom MAPI Verzeichnis zu verbinden.

Da dies nicht gelingt schwenkt Outlook zur -ExternalURL vom MAPI Verzeichnis ” mail.rehberger.de” um.

Darüber kann sich Outlook dann verbinden:

 

 

Exchange 2010 – Basis Verbindungsaufbau

Nachdem Outlook mithilfe des SCP o.a. eingerichtet worden ist stellt Outlook die Verbindung zum Exchange CAS Server her.

Dieses Bild soll vereinfacht die Verbindung von einer internen LAN und externen WAN Verbindung veranschaulichen. Die Virtual Directorys URLs ( -InternalUrl / -ExternalUrl ) sind zur besseren veranschaulichung extra getrennt.

 

 

Intern:

Die Postfachdatenbanken von Exchange 2010 verfügen über die Eigenschaft “RpcClientAccessServer” oder “ClientAccessArray”, die angeben wo der MAPI Endpunkt ( CAS Server ) zu finden ist. Nach der Grundinstallation von Exchange 2010 gibt es nur den Eintrag RPCClientAccessServer. Ein ClientAccessArray muss explizit erstellt werden.

In dem Outlook Profil ist einmal der “RpcClientAccessServer” oder das “ClientAccessArray” hinterlegt.

Outlook verbindet sich mit RPC/TCP zu dem CAS Server.

(Diese Anzeige in Outlook 2010 sieht erst so aus ab SP2 KB2687521 und Oktober 2015 PU KB3085604 )

Die restlichen Services werden über die URLs welche von der XML File geliefert werden angesteuert. Desweiteren führt Outlook bei jedem start und alle 60 Minuten ein Autodiscover durch um ggf. zwischenzeitliche Änderungen in den Einstellungen zu übernehmen.

 

Outlook wird gestartet und es wir direkt der RPC Punkt angesprochen ( Zeile 8.. )

 

 

Extern:

Damit sich ein Client von extern ohne VPN Verbinden kann, muss Outlook Anywhere in der Organisation aktiviert werden.

Der Client versucht sich über RPC/TCP mit dem im Outlook Profil hinterlegten “RpcClientAccessServer” oder “ClientAccessArray” zu verbinden. Da dies von extern nicht möglich ist wechselt er zu RPC/HTTP     ( Outlook Anywhere ) über. Damit werden die RPC Packete in das HTTP Protokoll verpackt.

Die Einstellungen hierzu erhält er auch der Autodiscover.xml, welche hier definiert werden:

 

Hier habe ich bei dem Client einmal den “RpcClientAccessServer” IP in der Host Datei abgeändert, damit der Client den CAS Server nicht mehr erreichen kann.

Nach dem start von Outlook versucht der Client sich zu dem RPC Server zu verbinden ( Zeile 13 .. – 172.16.21.222 – ausgedachte fake IP.. )

Nachdem dies nicht gelingt versucht er es über Outlook Anyhwhere ( Zeile 21 .. – mail.rehbergerold.de )

Dies klappt und er baut dann eine Verbindung auf ( Zeile 40.. )

Outlook ist nun über RPC/HTTP ( Outlook Anywhere ) verbunden

Exchange Migration Vorbereitung

Bevor man mit der Installation und Migration beginnt, ist es empfehlenswert sich vorher einige Punkte anzuschauen:

  • Coexistenz Vorrausetzungen überprüfen

https://technet.microsoft.com/de-de/library/aa996719(v=exchg.160).aspx

  • Source Exchange Server Build Numbers überprüfen

https://technet.microsoft.com/de-de/library/hh135098(v=exchg.150).aspx

z.B. für Exchange 2010

Get-Command ExSetup | ForEach {$_.FileVersionInfo}

Output:

ProductVersion FileVersion FileName
————– ———– ——–
14.03.0266.001 14.03.0266.001 C:\Program Files\Microsoft\Exchange Server\V14\bin\ExSetup.exe

 

  • vorhandene Domänencontroller Betriebssystem Version
  • vorhandenes Active Directory Gesamtstruktur Funktionsebene
  • Vorhandene Outlook Client Versionen ( oder andere E-Mail Programme )
  • Exchange Anbindung von extern ( reverse Proxy vorhanden ? )
  • E-Mail routing ( SMTP Proxy vorhanden ? )
  • Vorhandenes Zertifikat(e)
  • Aktueller Namespace aufbau der Exchange Verzeichnisse ( internalurl / externalurl entscheident )

get-webservicesvirtualdirectory -Server Servername

get-oabvirtualdirectory -Server Servername

get-owavirtualdirectory -Server Servername

get-ecpvirtualdirectory -Server Servername

get-activesyncvirtualdirectory -Server Servername

get-OutlookAnywhere -Server Servername

( get-MapiVirtualDirectory -Server Servername – erst ab EX 2013 interessant 🙂 )

Get-ClientAccessServer Servername   ( hier ist AutoDiscoverServiceInternalUri interessant und ggf. auch der AutoDiscoverSiteScope )

  • Fax Anbindung
  • E-Mail Archivierung
  • E-Mail Signatur
  • UM Funktionen
  • Datenbank Anzahl und Größe, Postfächer Anzahl
  • Öffentliche Ordner ( ab 2013 nicht mehr so dramatisch 🙂 )
Nächste Seite »