Kategorie: Exchange

SBS 2011 Exchange, AD und DNS funktionieren nicht mehr, Fehler: Zugriff verweigert

Ich hatte dass Problem bei einem Kunden, das nach einem Neustart der Exchange Server nicht mehr startete.

Bei der Fehlersuche fand ich heraus, das das auch kein Zugriff auf DNS Management Konsole mehr möglich war, ich bekam die Fehlermeldung „Zugriff verweigert“ und in der Ereignissanzeige fand ich mehrere Meldungen, die Anmeldeprobleme bestätigten.

Weiterhin seltsam war, das der Server nicht mehr einem „Domänennetzwerk“ zugeordnet war, sondern nur noch einem Öffentlichen Netzwerk – man konnte zwar diesen in einem „Arbeitsplatznetzwerk“ zuordnen, jedoch nicht mehr einem Domänennetzwerk.

Neustarts halfen nichts und dauerten ewig (ca. 40 Minuten bis die GUI komplett geladen war).

Recherchen zeigten, das wohl intern die „interdomain trustrelationship“ beschädigt war.

Nach einem Neustart habe ich dann den folgende Befehlt eingeben:

nltest /sc_change_pwd:domainname.local

Als Antwort erhielt ich folgende Meldung:

Kennzeichen: 0
Verbindung Status = 0 0x0 NERR_Success
Der Befehl wurde ausgeführt.

Danach habe ich denn Server neugestartet und siehe da, wie von Zauberhand war das Problem behoben.

Der Server startete wieder schneller, Exchange funktionierte, der Zugriff auf die DNS Management Konsole war ohne Probleme möglich und in den Netzwerkeinstellungen war der Server wieder einem Domänennetzwerk zugeordnet.

Quelle: https://davidatkin.com/blog/server-2008-r2-sbs2011-dns-access-denied-network-unauthenticated/


Exchange 2010: Leere Seite oder Fehlermeldung nach Anmelden am OWA

Sollte nach einem Anmelden ans OWA nur eine Leere Seite erscheinen oder eine Seite mit dem Hinweis das die Seite nicht geladen werden konnte so sollte man wie folgt vorgehen:

  • Prüfen ob alle Exchange Updates installiert sind (Stand 11.12.15 SP3 RU 11), wenn nicht diese installieren
  • Dann Updatecas.ps1 ausführen (C:\Programme\Microsoft\Exchange Server\V14\Bin in Exchange Powershell, beim Starten aus dem selben Verzeichnis noch .\ vor dem  Befehl setzen)
  • Nach Erfolg noch einen IISReset (CMD mit Administratorrechten)

 


Exchange 2010 ohne SAN Zertifikat betreiben

Sollte man von einem SAN Zertifikat umsteigen auf ein herkömmliches Zertifikat, so muss man auch noch einige Einstellungen im Exchange vornehmen, damit keine Fehlermeldungen mehr erscheinen beim öffnen von Outlook usw.

Dazu müssen in der Exchange Management Shell folgende Änderungen vorgenommen werden:

Set-ClientAccessServer -Identity servername -AutoDiscoverServiceInternalUri “https://exchange.domain.de/Autodiscover/Autodiscover.xml”

Set-AutodiscoverVirtualDirectory -Identity “servername\Autodiscover (Default Web Site)” -InternalUrl “https://exchange.domain.de/Autodiscover/Autodiscover.xml” -ExternalUrl “https://exchange.domain.de/Autodiscover/Autodiscover.xml”

Set-WebServicesVirtualDirectory -Identity “servername\EWS (Default Web Site)” -InternalUrl “https://exchange.domain.de/EWS/Exchange.asmx” -ExternalUrl “https://exchange.domain.de/EWS/Exchange.asmx”

Set-OWAVirtualDirectory -Identity “servername\OWA (Default Web Site)” -InternalUrl “https://exchange.domain.de/owa” -ExternalUrl “https://exchange.domain.de/owa”
 
Set-ECPVirtualDirectory -Identity “servername\ECP (Default Web Site)” -InternalUrl “https://exchange.domain.de/ecp” -ExternalUrl “https://exchange.domain.de/ecp”
 
Set-ActiveSyncVirtualDirectory -Identity “servername\Microsoft-Server-ActiveSync (Default Web Site)” -InternalUrl “https://exchange.domain.de/Microsoft-Server-Activesync” -ExternalUrl “https://exchange.domain.de/Microsoft-Server-Activesync”
 
Set-OABVirtualDirectory -Identity “servername\OAB (Default Web Site)” -InternalUrl “https://exchange.domain.de/OAB” -ExternalUrl “https://exchange.domain.de/OAB”
 
Enable-OutlookAnywhere -Server servername -ExternalHostname “exchange.domain.de” -ClientAuthenticationMethod “Basic”-SSLOffloading:$False

Weitere Infos: http://www.it-dienstleistungen.de/ms-exchange-problem-servername-und-name-im-zertifikat-stimmen-nicht-ueberein

 

 


outlook.com bzw. Office365 Server whitelisten

Ich hatte das Problem bei einem Kunden, das dieser keine Emails von Empfängern erhalten konnten, die outlook.com bzw. Office 365 nutzten.

Laut mxtoolbox.com war jedoch alles ok.

In den Logs der Sophos fand ich jedoch folgende Zeilen:

2015:08:12-22:37:59 gateway exim-in[16769]: 2015-08-12 22:37:59 TLS error on connection from mail-db3on0121.outbound.protection.outlook.com (emea01-db3-obe.outbound.protection.outlook.com) [157.55.234.121]:2048 (SSL_accept): error:00000000:lib(0):func(0):reason(0)
2015:08:12-22:37:59 gateway exim-in[16769]: 2015-08-12 22:37:59 TLS client disconnected cleanly (rejected our certificate?)
2015:08:12-22:37:59 gateway exim-in[16769]: 2015-08-12 22:37:59 SMTP connection from mail-db3on0121.outbound.protection.outlook.com (emea01-db3-obe.outbound.protection.outlook.com) [157.55.234.121]:2048 closed by EOF

Nachdem ich das TLS Zertifikat der Firewall noch mal ausgetauscht hatte, funktionierte die Kommunikation einwandfrei:

2015:08:14-13:27:03 gateway exim-out[23820]: 2015-08-14 13:27:03 1ZQD8W-0006C6-Ip => absender@url.com P=<empfaenger@ulr.org> R=dnslookup T=remote_smtp H=xxxx.mail.protection.outlook.com [213.199.04.0]:25 X=TLSv1.2:ECDHE-RSA-AES256-SHA384:256 C="250 2.6.0 <9101E7B53B7D6E40AF7D0311DBxxxxxxxx@server> [InternalId=126186139xxxx"
2015:08:14-13:27:03 gateway exim-out[23820]: 2015-08-14 13:27:03 1ZQD8W-0006C6-Ip Completed

Dennoch habe ich die Mailserver von Outlook.com whitegelistet (zumindest bezüglich der Kommunikation, nicht in der inhaltlichen Prüfung bezüglich Spam oder Viren).

Die Adressen findet man hier: https://technet.microsoft.com/en-us/library/dn163583(v=exchg.150).aspx

 


Kostenlose Microsoft Schulungen

Es gibt auch kostenlose Möglichkeiten sich weiterzubilden.

Eine davon stammt sogar von Microsoft selber – die Microsoft virtual Academy.

Dort findet man massenweise Videos mit Informationen und späteren Testen – sozusagen, wie ein virtuelles Klassenzimmer.

Leider sind diese Videos und Teste nur auf Englisch.


Exchange: Autodiscover-Umleitung

Versucht Outlook per HTTPS zu verbinden, nutzt es dazu Autodiscover. Hierbei kann es zu Fehlermeldungen kommen.

Damit dies nicht geschieht, kann man über DNS eine Umleitung einrichten.

Dazu erstellt man einen sogenannten SRV Eintrag im DNS.

Z.b. im lokalen Active Directory auf dem DC per Remote anmelden und dann wie folgt einrichten:

  • Start > ausführen > dnsmgmt.msc
  • Forward-lookup-Zone > AD auswählen
  • Rechte Maustaste > weitere Einträge erstellen > Dienstidentifizierung (SRV) > Eintrag erstellen
  • Dienst: _autodiscover
  • Protokoll: _tcp
  • Port: 443
  • Host: URL des Servers

Sobald Outlook die Umleitung bemerkt, fragt es nach ob man die Umleitung erlauben möchte – dies muss man natürlich Zulassen. Es empfiehlt sich hier auch einen Hacken zu setzen bei „Zukünftig nicht mehr zu dieser Website fragen„.

autodiscover



Exchange: „Senden als“ Beiträge im „richtigem“ Postfach

Wenn ein Benutzer ein weiteres Postfach geöffnet hat, und Mails mit „Senden als“ versendet – werden diese im Postfach des Versenders abgespeichert.

Damit dies nicht geschieht kann man folgendes Einstellen in der Registry:

HKEY_CURRENT_USER\Software\Microsoft\Office\11.0\Outlook\Preferences
Die “11.0” steht für die Office-Version (2003) –> demnach könnte es auch z. B. “14.0” bei euch lauten (Office 2010)
Hier muss ein neuer Wert erstellt werden:
Typ: Dword(32)
Name: DelegateSentItemsStyle
Wert: 1

Andere Alternative wäre, dies auch im OWA einzustellen (siehe Link unten) – erfordert Exchange 2010 SP2 RU4.

 

Alternativ ab Exchange 2010 SP3 geht dies auch mit einem Befehl Serverseitig:

Set-MailboxSentItemsConfiguration "Customer Support Feedback" -SendAsItemsCopiedTo SenderAndFrom

Quellen:

https://technet.microsoft.com/en-us/library/jj884078(v=exchg.141).aspx

http://www.olliv.de/office/senden-als-gesendete-objekte-in-richtigem-postfach-ablegen/

http://www.msoutlook.info/question/278

http://www.slipstick.com/exchange/sending-email-from-a-secondary-exchange-mailbox/


Exchange 2013: OWA unsichere Anlagen nicht mehr blockieren

Standardmäßig werden im Exchange 2013 unsichere Anlangen wie EXE, CRT usw. nicht freigegeben zum Download.

Sollen diese nun doch freigegeben werden, so kann man dies im ECP einstellen.

  • Logen Sie sich im ECP ein.
  • Gehen Sie nach Berechtigungen > Outlook Web App – Richtlinien.
  • Editieren Sie die Default-Richtlinie.
  • Unter dem Punkt Dateizugriff können Sie die Freigaben erlauben.

Exchange 2010/SBS 2011: Relay über TLS/SSL (z.B. 1und1)

Da viele Mailserver nur noch per TLS/SSL Mails entgegenehmen, muss man dies im Exchange Verwaltungsconsole im Sendeconnector einstellen (Exchange > Microsoft Exchange lokal > Organisationskofniguration > Sendekonnektor > Sendekonnektor doppelklick > Register Netzwerk > Email über Smarthost senden > Ändern > Hacken bei Standardauthentifizierung über TLS senden).

Weiterhin muss man dann in der Verwaltungsshell noch folgenden Befehl eingeben:

Set-SendConnector –Identity “Windows SBS Internet Send SERVERNAME” -Port 587