Exchange

Ich hatte bei einem Exchange 2013 das Problem, dass Umlaute in Abwesenheitsnachrichten (Out of Office) bzw. Automatischen Antworten nicht dargestellt wurden – diese wurden mit einem ? ersetzt. Das sah dann so aus:

Ich habe das Problem damit behoben, dass ich den ContentType der RemoteDomain auf dem Exchange von MimeText auf MimeHTMLText mittels der Exchange Management Shell umgestellt habe:

get-remotedomain | set-remotedomain -ContentType MimeHtmlText

Danach waren alle Umlaute in den Automatischen Antworten und Abwesenheitsnotizen (OOF halt 😉 ) wieder richtig

Quelle: TechNET

Nach der Installation von Exchange 2013 CU11 hatte ich das Problem, dass z.B. bei der Powershell-Abfrage Get-ExchangeServer nur noch alle alten Server mit Exchange 2010 angezeigt werden. Auch Server mit Exchange 2013 die noch keinen CU11 installiert hatten wurden nicht mehr angezeigt. Somit war die Exchange-Verwaltungsshell ziemlich nutzlos….

In der ECP (Exchange Administrative Center) auf dem Exchange 2013 mit CU11 jedoch wurden alle Server richtig angezeigt und man konnte auch Einstellungen, etc bearbeiten und auch ändern.

Um das Problem zu beheben und wieder muss folgendes ausgeführt werden:

1) Im Exchange Administrative Center das Postfach des Administrators auf den neuen Exchange 2013 CU11 verschieben

2) Auf dem Exchange 2013 CU11 in der Regisry unter HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\ WSMAN\Client\ConnectionCookies die Einträge löschen (falls dort welche vorhanden sind)

Danach geht wieder alles in der Exchange-Verwaltungsshell 🙂

Quelle: TechNet

Ich hatte den Fall, dass ein Kunden mit Exchange Server 2013 und Outlook 2013 darüber geklagt hat, dass immer wieder im Outlook die Meldung kommt „Der Microsoft Exchange Administrator hat eine Änderung durchgeführt, die einen Neustart von Outlook erfordert“.

Das kommt von einem falschen Eintrag der Exchange-Datenbank im Active-Directory.

Mit dem ADSI Edit (adsiedit.msc) macht man folgendes:

Configuration >> CN=Services >> CN=Microsoft Exchange >> CN=OrganisatonsNname >> CN=Administrative Groups >> CN=Exchange Administrative Group >> CN=Databases

dort auf der Datenbank bzw. den Datenbanken das Attribut MSEXCHHomePublicMDB überprüfen. Vor allem nach Migrationen verweist es noch auf falsche oder nicht mehr Vorhandene Datenbanken. Diesen Wert dann einfach leeren.

Falls der Wert schon auf nicht gesetzt steht – also leer ist – kann man auch einfach eine leere PublicFolder-Datenbank anlegen.

Spätestens jetzt sollte Outlook ohne die Meldung seinen Dienst tun.

Quelle: TechNet

Neben dem NGINX kann natürlich auch der Apache2 für einen ReverseProxy für die Exchange-Dienste EAS (Exchange ActiveSync) und OWA (OutlookWebAccess) verwendet werden – und zusätzlich seit einiger Zeit auch (wieder) für OutlookAnywhere (RPCoverHTTP)! I

Folgende Konfiguration hat bei mir unter Ubuntu 14.04 einwandfrei funktioniert:

1) Apache2 installieren

apt-get install apache2 apache2-doc

2) Modul für OutlookAnywhere installieren

apt-get install libapache2-mod-proxy-msrpc

3) Module aktivieren

a2enmod headers
a2enmod rewrite
a2enmod proxy_http
a2enmod ssl
a2enmod proxy_msrpc

3) Zertifikat erstellen

Jetzt sollte das Zertifikat für die externe Domäne erzeugt werden. Als erstes erzeugen wir die Key-Datei:

openssl genrsa -out server.key 2048

Jetzt erstellen wir eine Zertifikatsanforderung:

openssl req -new -key server.key -out server.csr

Hier ein Beispiel:

Country Name (2 letter code) [AU]: DE
State or Province Name (full name) [Some-State]: Bayern
Locality Name (eg, city) []:Testhausen
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Testfirma
Organizational Unit Name (eg, section) []:EDV
Common Name (eg, YOUR name) []:mobile.test.extern
Email Address []:edv@test.extern

Please enter the following ‚extra‘ attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

Wichtig ist der Common Name -> das ist die externe Domain – hier im Beispiel mobile.test.extern. Challenge Password und optional company name kann leer gelassen werden.

Falls man auch die Autodiscover-Adresse für OutlookAnywhere mit einem Zertifikat absichern will braucht ein SAN-Zertifikat: http://stefan.ploing.de/2014-01-22-san-zertifikat-mit-openssl/

Danach hat man zwei Dateien – die server.key und die server.csr. Jetzt muss nur die Anforderung in die CA eingereicht werden. Ich mache dies immer über die Webschnittstelle der Zertifizierungsstelle. Über http(s)://cert-server/certsrv kann man die csr eingeben und ein Webserver-Zertifikat erstellen. Wichtig hierbei ist das man die csr-Datei nicht in Windows öffnet. Ich empfehle über einen SSH-Client wie Putty auf dem Linux-Server:

cat server.csr

auszuführen und die Ausgabe dann zu kopieren. So stellt man sicher das die Formatierung richtig ist. Ansonsten kann es zu Zertifikatsfehlern kommen. Die Ausgabe sieht dann so aus:

—–BEGIN CERTIFICATE REQUEST—–
MIIBzzCCATgCAQAwgY4xCzAJBgNVBAYTAkRFMQ8wDQYDVQQIDAZCYXllcm4xEzAR
BgNVBAcMClRlc3RoYXVzZW4xDTALBgNVBAoMBFRlc3QxDDAKBgNVBAsMA0VEVjEb
MBkGA1UEAwwSbW9iaWxlLnRlc3QuZXh0ZXJuMR8wHQYJKoZIhvcNAQkBFhB0ZXN0
QHRlc3QuZXh0ZXJuMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDn015lJMsY
N/KvYrV0wNjzZh+82wJY10xliBpg3p63JbUDA3bjL6bv5+Jcas2c0bgZwyNQl6oB
e/1y/fjDAaFXfpBLk/ZQyoJ/c2DFfOloZdoMEJN7veVzU+2m3I6306ADxx8y52MQ
+xD//0zPtasX2ZEdtghS4Arn+fsPQPS+UQIDAQABoAAwDQYJKoZIhvcNAQEFBQAD
gYEAyDDgPv1fTpweDk+N9JKEBgpdlONv2ZHJJ/upxXMW2aUMNXgLNR0IvNC6Q2/K
Bm1oGvtNyqiTDN0VqIfNvnzzSSlYZN85a3G0psHMdybc8TQ2N+RwIqz49+Rw3qrQ
W6c9kruyn17XFCgRC7rxgwIC/T1uWNOxyO28U00pNVJvgjc=
—–END CERTIFICATE REQUEST—–

Das so erstellt Webserver-Zertifikat (als BASE64/DER speichern) kopiert man dann auf den ReverseProxy – z.B. per SCP mit WinSCP. Am Besten ins HomeDirectory des Root-Users – denn dort liegen auch die beiden anderen Dateien (die key- und die csr-Datei).

Danach muss das Zertifikat konvertiert werden:

openssl x509 -inform PEM -in server.cer > server.pem

und kopiert werden:

cp server.pem /etc/ssl/certs/mobile.test.extern.pem
cp server.key /etc/ssl/private/mobile.test.extern.key

4) Apache2 konfigurieren

Wir erstellen jetzt die Exchange-Config-File

vim /etc/apache2/sites-available/exchange.conf

<VirtualHost *:80>

ServerName mobile.test.extern
ServerAlias autodiscover.test.extern
ServerAdmin webmaster@test.extern

ErrorLog /var/log/apache2/error.log
CustomLog /var/log/apache2/access.log combined

Header always set X-Frame-Options SAMEORIGIN

Header set Server Apache

RequestHeader unset Expect early

Header unset X-AspNet-Version
Header unset X-OWA-Version
Header unset X-Powered-By

ProxyRequests Off

RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^/owa(.*) https://mobile.test.extern/owa$1 [R,L]
RewriteRule ^/ecp(.*) https://mobile.test.extern/ecp$1 [R,L]
RewriteRule ^/Microsoft-Server-ActiveSync(.*) https://mobile.test.extern/Microsoft-Server-ActiveSync$1 [R,L]

DocumentRoot /var/www

<Directory />
    Order deny,allow
    Deny from all
</Directory>

<Directory /var/www>
    DirectoryIndex index.php index.html
    Options -Indexes +FollowSymLinks
    Order allow,deny
    Allow from all
</Directory>

<Proxy *>
        Order deny,allow
        Allow from all
</Proxy>

</VirtualHost>

### SSL Host ###
<VirtualHost *:443>

ServerName mobile.test.extern
ServerAlias autodiscover.test.extern
ServerAdmin webmaster@test.extern

ErrorLog /var/log/apache2/error.log
CustomLog /var/log/apache2/access.log combined

Header always set X-Frame-Options SAMEORIGIN

Header set Server Apache

Header unset X-AspNet-Version
Header unset X-OWA-Version
Header unset X-Powered-By

RequestHeader unset Expect early

ProxyRequests Off
ProxyPreserveHost On

SSLProxyEngine on
SSLProxyVerify none
SSLProxyCheckPeerCN off
SSLProxyCheckPeerName off
SSLProxyCheckPeerExpire off

# owa
ProxyPass /owa https://10.10.10.1/owa
ProxyPassReverse /owa https://10.10.10.1/owa

# ecp
ProxyPass /ecp https://10.10.10.1/ecp
ProxyPassReverse /ecp https://10.10.10.1/ecp

# Microsoft-Server-ActiveSync
ProxyPass /Microsoft-Server-ActiveSync https://10.10.10.1/Microsoft-Server-ActiveSync
ProxyPassReverse /Microsoft-Server-ActiveSync https://10.10.10.1/Microsoft-Server-ActiveSync

# RPC over http(s) / Outlook Anywhere
OutlookAnywherePassthrough On
ProxyPass /rpc https://10.10.10.1/rpc
ProxyPassReverse /rpc https://10.10.10.1/rpc

DocumentRoot /var/www

<Directory />
    Order deny,allow
    Deny from all
</Directory>

<Directory /var/www>
    DirectoryIndex index.php index.html
    Options -Indexes +FollowSymLinks
    Order allow,deny
    Allow from all
</Directory>

<Proxy *>
        SetEnv proxy-nokeepalive 1
        SetEnv force-proxy-request-1.0 1
        Order deny,allow
        Allow from all
</Proxy>

  SSLEngine on
        SSLCertificateFile    /etc/ssl/certs/mobile.test.extern.pem
        SSLCertificateKeyFile /etc/ssl/private/mobile.test.extern.key

  BrowserMatch "MSIE [2-6]" \
    nokeepalive ssl-unclean-shutdown \
    downgrade-1.0 force-response-1.0
  # MSIE 7 and newer should be able to use keepalive
  BrowserMatch "MSIE [17-9]" ssl-unclean-shutdown

</VirtualHost>

Die IP 10.10.10.1 ist hier der lokale Exchange-Server.

Wer lieber mit Hostname arbeitet muss man unter Umständen den lokale Exchange Server noch in die hosts-Datei eingetragen werden, damit die Namensauflösung funktioniert.

vi /etc/hosts

und dort die Zeile für die IP-Adresse des lokalen Exchange ergänzen:

10.10.10.1 exch2013.test.local

zum Testen kann man einen Ping auf dem Fully-Qualified Domain Name (FQDN) des Exchange absetzten:

ping exch2013.test.local

Jetzt muss nur noch die Konfigurationsdatei „scharf“ geschaltet werden.

Dazu löschen wir die Default-Konfiguration

rm /etc/apache2/sites-enabled/000-default.conf

und linken unsere Exchange-Konfiguration in den sites-enabled-Ordner

ln -s /etc/apache2/sites-enablede/exchange.confg /etc/apache2/sites-enabled/exchange.conf

Jetzt muss nur noch der Apache2-Dienst neugestartet zu werden:

service apache2 restart

fertig 🙂

5) Testen

Unter https://www.testexchangeconnectivity.com kann man die ActiveSync-Funktion testen.

Quellen: www.sturbi.de, znil.net

Ich stoße öfters auf den Fehler, dass Outlook beim Einrichten des Profils beim Punkt „Am Server anmelden“ scheitert und sich nicht am Exchange anmelden kann.

Das Exchange Autodiscover funktioniert einwandfrei (Outlook konfiguriert sich sauber selbst) – nur beim letzten Punkt – eben der Anmeldung – scheitert der Einrichtungsvorgang mit folgender Meldung:

„Der Name kann nicht aufgelöst werden. Es steht keine Verbindung mit Microsoft Exchange zur Verfügung. Outlook muss im Onlinemodus oder verbunden sein, um diesen Vorgang abzuschließen.“

Das komische hierbei ist, dass dieses Problem oft nicht alle Benutzer betrifft sondern nur einzelne Benutzer. Auch können z.B. andere Benutzer an dem Rechner sich ohne Problem mit Outlook an dem Exchange anmelden.

Das Problem liegt hier an der Anmeldung von Outlook am Globalen Katalog im Active Directorys.

Man kann über einen Registry-Schlüssel den Globalen-Katalog-Server für Outlook bei diesen Benutzern vorgeben.

Dazu erstellt man für die betroffenen Benutzer unter

HKEY_CURRENT_USER\Software\Microsoft\Exchange\Exchange Provider

eine Zeichenfolge (REG_SZ) mit dem Namen DS Server

und gibt als Wert den bzw. einen Domänencontroller an (als FQDN-Namen), der den Globalen Katalog hat.

Hier in meinen Beispiel also dc.test.local.

Danach führt man die Profilerstellung neu durch – und dann sollte es sauber durchlaufen 🙂

Quelle: Microsoft

Wenn man bei einem Exchange 2013 bestimmte Benutzer bearbeiten will, kommt es unter Umständen zu folgendem Fehler:

„Die angegebene Organisationseinheit wurde nicht gefunden. Stellen Sie sicher, dass Sie die Identität der Organisationseinheiten korrekt eingegeben haben.“

und in der Ereignisanzeige taucht der Fehler MSExchange CmdletLogs mit der Event-ID 6 (Cmdlet fehlgeschlagen. Cmdlet Get-UserPrincipalNamesSuffix, Parameter {OrganizationalUnit=domain.tld/OU}) auf:

Der Grund für den Fehler liegt darin, dass in der Domain der User-Container vom Default-Wert abweicht. Das kann z.B. bei einer Migration von einem Small Business Server sein, da hier der Standard-Container der Benutzer verschachtelt unter der MyBusiness-OU liegt. Oder der Admin hat den Pfad manuell wie hier beschrieben geändert.

Man kann den Wert am einfachsten in der Powershell mit Get-ADDomain überprüfen:

Wenn dieser nicht dem Standard-Wert „CN=Users,DC=Domainname,DC=tld“ entspricht (also in meinem Beispiel CN=Users,DC=test,DC=local) – kommt es zu dem beschriebenen Fehler.

Wenn man den Standard-Container für die Benutzer wieder auf den Standardwert setzt funktioniert alles wieder.

Am einfachsten geht es mit folgendem Befehl:

redirusr „CN=Users,DC=Domainname,DC=tld“

also z.B.: redirusr „CN=Users,DC=test,DC=local“

Ohne Neustart von Servern oder Dienste funktioniert die Bearbeitung der User sofort wieder 🙂

Ich habe schon einige Exchange 2013 gesehen die Probleme mit dem Mailempfang hatten. Die Symptome waren folgende:

– Port 25 war sporadisch nicht verfügbar bzw. keine Verbindung möglich
– Mails bleiben in der Transport Queue auf beiden Seiten (Exchange 2013 und SMTP-Server der Gegenseite) hängen
– NDR´s (Non Delivery Reports) werden erstellt

Das ist ein typisches Fehlerbild wenn ein Empfangsconnector falsch erstellt wurde und somit zwei Dienste von Exchange 2013 (Microsoft Exchange FrontEnd Transport Service und Microsoft Exchange Transport Service) auf dem Port 25 laufen. Wie es richtig geht steht übrigens hier 😉

Um zu überprüfen ob dies zutrifft kann man folgendes tun:

In der Exchange Management Shell folgenden Befehl absetzten:

Get-ReceiveConnector | Where-Object {$_.Bindings -like „*:25“} | fl Identity, Bindings, TransportRole

Hier ist schön zu sehen, dass der „Default Frontend Exch2013“ auf dem Port 25 und unter dem Dienst FrontendTransport läuft – aber der „Relay“ unter dem Dienst HubTransport lauft. Somit teilen sich 2 Dienste die komplett andere Aufgaben haben den gleichen Port -> Beide streiten sich um den Port 25.

Jetzt muss nur der Connector „Relay“ auch auf den richtigen Dienst gemappt weden:

Set-ReceiveConnector Relay –TransportRole FrontEndTransport

Danach vielleicht noch den die beiden Dienste neustarten

restart-service MSExchangeFrontEndTransport
restart-service MSExchangeTransport

– und schon funktioniert der Email-Empfang wieder problemlos!

Quelle: exchangemaster.wordpress.com

Ich habe ja schon hier beschrieben wie man unter Exchange 2007/2010 ein anonymes Relay erstellt.

Unter Exchange 2013 unterscheidet sich dieses Vorgehen aufgrund der geänderten Architektur ein bisschen:

Man legt den Empfangsconnector am einfachsten per Powershell an:

New-ReceiveConnector -Name “Relay” -Usage Custom -PermissionGroups AnonymousUsers -Bindings 10.20.30.1:25 -RemoteIpRanges 10.20.30.243 –TransportRole FrontEndTransport

Dabei ist “Relay” der Name des Connectors, AnonymousUsers die Berechtigungsgruppe auf den Connector (eben anonym), Bindings die IP-Adresse und der Port auf den der Connector “hört” und RemoteIpRanges die Geräte die senden dürfen (es können natürlich auch mehr angegeben werden). Es sollte vermeidet werden, dass ein komplettes Netz anonym mailen darf – Stichwort SPAM ;-). Durch den Bindung der Empfangsconnectors auf die Transportrolle FrontEndTransport weist man es dem für „Clientverkehr“ zuständigen Dienst bzw. Rolle zu.

Jetzt muss noch eine Berechtigung für die AnonymousUsers gesetzt werden:

Bei einem deutschen Server:

Get-ReceiveConnector “Relay” | Add-ADPermission -User “NT-AUTORITÄT\ANONYMOUS-ANMELDUNG” -ExtendedRights “Ms-Exch-SMTP-Accept-Any-Recipient”

Bei einem englischen Server:

Get-ReceiveConnector “Relay” | Add-ADPermission -User “NT AUTHORITY\ANONYMOUS LOGON” -ExtendedRights “Ms-Exch-SMTP-Accept-Any-Recipient”

Jetzt sollte das anonyme Mailen funtkionieren 🙂