Blog durchsuchen

Montag, 23. Mai 2016

Load Balancer Health URLs

Um die ClientAccess-Rolle auf einem Exchange Server 2013 oder 2016 Hochverfügbar zu machen, ist es erforderlich einen seperaten Load-Balancer einzusetzen. (Die Möglichkeiten über DNS-RoundRobin oder Windows NLB, blende ich hier bewußt aus)

Damit ein eingesetzter LoadBalancer auch mitbekommt, dass die unterschiedlichen Dienste auf den jeweiligen CAS-Servern verfügbar sind, und keine Daten auf inaktive Server schickt, ist es wichtig dies auch regelmässig zu überprüfen.

Seit Exchange Server 2013 gibt es "Managed Availability" welche es für LoadBalancer einfach macht dies festzustellen. Exchange erstellt für jeden der Dienste ein eigenes virtuelles Verzeichnis welches ein LoadBalancer (oder natürlich auch andere Monitoring Tools) lediglich abfragen muß.

Man kann einen Dienst auch einfach mittels Web-Browser auf seine Verfügbarkeit hin überprüfen
Es kommt als Antwort lediglich eine Seite mit "200 OK" und dem abgefragten Servernamen:


Folgende Liste der Healtchecks ist verfügbar:

OWA - Outlook Web App
https://Servername.domain.local/owa/healthcheck.htm

ECP - Exchange Control Panel
https://Servername.domain.local/ecp/healthcheck.htm

OAB - Offline Addressbook
https://Servername.domain.local/oab/healthcheck.htm

RPC - RPC Zugriffe
https://Servername.domain.local/rpc/healthcheck.htm

MAPI
https://Servername.domain.local/mapi/healthcheck.htm

Autodiscover
https://Servername.domain.local/autodiscover/healthcheck.htm

Active Sync
https://Servername.domain.local/Microsoft-Server-ActiveSync/healthcheck.htm


Wichtig dabei ist natürlich die FQDN des abzufragenden Servers einzutragen anstatt "Servername.domain.local"

Donnerstag, 19. Mai 2016

"451 4.7.0 Temporary server error" in Test Environment

Eine Exchange Testumgebung ist eine tolle Sache um Dinge auszuprobieren. 
Zeitweise hat man damit jedoch auch Probleme welche man in einer normal installierten Umgebung nicht hätte. 

So zum Beispiel auch der Fehler:
"451 4.7.0 Temporary Server error. Please try again later. PRX2"

Eine kurze Recherche ergab, dass das Problem wieder mal mit DNS zu tun hat. 
Das Problem tritt nämlich dann auf, wenn bei der Netzwerk-Konfiguration als zweiter DNS-Server ein "Router" angegeben wird.

Einfach den zweiten DNS-Server von der Netzwerkkarte rausgelöscht und siehe da: keine Fehlermeldung mehr :-)


Update:
Sollte das nichts bringen, kann es auch helfen die Einstellung "Register this connection's addresses in DNS" und "Use this connection's DNS suffix in DNS registration" anzuhaken.

 

Mittwoch, 18. Mai 2016

Hierarchisches Adressbuch

Ein hierarchisches Adressbuch (kurz: HAB), ist eine "zusätzliche" Ansicht im Outlook-Adressbuch bei der die Empfänger analog zu den Abteilungen im Firmen-Organigramm sortiert sind.



Freitag, 13. Mai 2016

Powershell 5 und Exchange - keine gute Idee


Das Windows Management Framework 5.0 oder auch kurz gesagt "Powershell 5" ist eine tolle Sache. Viele nette Neuerungen wie CopyPaste mit den Windowstastaturkürzeln, Verwendung von ZIP-Archiven, Pakete aus Internet-repositorys importieren usw...

Donnerstag, 12. Mai 2016

Langer Zeitraum für NDR-Meldung


Zeitraum für NDR 550 5.1.1 User unknown


Seit Exchange 2013 arbeiten Empfängerfilter anders als früher. Wenn ein Email mit einem "Tippfehler" in der Adresse oder an eine nicht vorhandene Adresse verschickt wird, dauert es dadurch meist recht lange bis eine Entsprechende Fehlermeldung beim Absender ankommt.

Freitag, 6. Mai 2016

DNS Error bei Mailversand



Sollte beim Mailversand ein Fehler wie "451 4.4.0 DNS query failed" auftauchen, kann man dem Problem auf 2 Arten begegnen.

Zuerst sollte man natürlich mal den Fehler eingrenzen.

In diesem Fall ist festzustellen, ob der Fehler nur bestimmte Domains, oder alle ausgehenden Mails betrifft.

 

Kein Mail an eine bestimmte Domain

Sollte es sich nur um eine bestimmte Domain handeln, kann man (temporär - bis das DNS-Problem behoben ist) einen expliziten Send Connector erstellen.

 

Dazu einfach unter Mail Flow / Send Connectors mit dem "+" einen neuen Connector erstellen.

 

Und in diesem als Smart-Host die IP des jeweiligen Empfänger-Servers eintragen.



Als SourceServer dann noch den oder die eigenen Server auswählen und mit Finish den Connector erstellen.

Mails für diese Domain sollten damit direkt zugestellt werden.
 


Überhaupt keine Mails nach Extern


Wenn an überhaupt keinen externen Empfänger verschickt werden kann, sollte mal überprüft werden ob mittels Ping, nslookup etc die jeweiligen Domains überhaupt aufgelöst werden. Exchange verwendet standardmäßig die DNS-Einstellungen der Netzwerkkarte. Sollte die Namensauflösung nicht erfolgreich sein, oder es mehrere Netzwerkkarten mit unterschiedlichen DNS-Settings geben, sollte man am  für den/die Exchange Server explizit angeben welchen DNS-Server Exchange verwenden soll. In diesem Fall habe ich die Server 8.8.8.8 u. 8.8.4.4 (Google DNS-Server) genommen.

 

Danach werden die Mails wieder erfolgreich verschickt. Mails in der Warteschlange (Queue) brauchen ein paar Minuten oder man stösst das ganze mittel dem Cmdlet Retry-Queue an.

Donnerstag, 5. Mai 2016

Fehleranalyse: Verschwundene Kalendereinträge



Auf unerklärliche Weise sind immer wieder Termine zwischen 2 Usern verschwunden.

Problemstellung:


User A hat eine Einladung an mehrere User verfasst welche dann auch angenommen wurde.
Alle (oder zumindest mehrere) User haben die Einladung angenommen und der Termin scheint im kalender der jeweiligen Benutzer auf. Nach mehreren Minuten/Stunden, verschwindet der Eintrag jedoch aus dem Kalender von User A und 1 weiteren Benutzer (User B). Die anderen haben den Eintrag noch im Kalender stehen.

 

Analyse:


Zuerst wurden alle Outlook-PlugIns deaktiviert. Weiters wurde auch überprüft ob es Inbox-Rules in den Mailboxen gab und dann wurden auch noch die Mobilgeräte als Verursacher ausgeschlossen.
 
Danach wurde das "Mailbox Audit Log Search" für die 2 betroffenen Mailboxen aufgedreht.

Dies kann am besten über die Shell erfolgen:
Set-Mailbox -Identity "Vorname Nachname" -AuditEnabled $true
siehe dazu auch https://technet.microsoft.com/en-us/library/ff461937%28v=exchg.160%29.aspx

Kurz vor Dienstschluss der Mitarbeiter wurde noch eine Test-Einladung von dem Benutzer mit der Problem-Mailbox verschickt um sicherzugehen, dass die Einladung auch dann verschwand, wenn keiner der Benutzer Outlook geöffnet hat.

Ergebnis:


Die Logs können mittels Exchange Admin Center einfach exportiert werden.
 
Danach bekommt man ein XML-File welches man mit einem x-beliebigen Editor ansehen kann.
Ich habe dazu einfach mal Notepad++ verwendet.

Das Ergebnis sah dann folgendermaßen aus:


 <Event MailboxGuid="4d9e36ca-1d1e-40ee-92dd-fe6e5740671b" Owner="Vorname Nachname" LastAccessed="2016-04-28T17:33:41+02:00" Operation="HardDelete" OperationResult="Succeeded" LogonType="Admin" FolderId="LgAAAABV5Gs0nfPsRqWTLmX3wbUoAQDDErzhrPTHTbQDBLYqsdv1AAAAAAEOAAAC" FolderPathName="\Calendar" ClientInfoString="Client=WebServices;ExchangeServicesClient/15.00.0516.014;" ClientIPAddress="10.2.36.18" InternalLogonType="Owner" MailboxOwnerUPN="Vorname.nachname@domain.com" MailboxOwnerSid="S-1-5-21-3475737579-2923169912-4130912164-2264" CrossMailboxOperation="false" LogonUserDisplayName="svcCRMCorp" LogonUserSid="S-1-5-21-7563437579-2923166392-4130993384-87952" OriginatingServer="Exchange1 (15.00.1104.002)">
    <SourceItems>
      <Item Id="RgAAAABV5Gs0nfPsRqWTLmX3wbUoBwDDErzhrPTHTbQDBLYqsdv1AAAAAAEOAADDErzhrPTHTbQDBLYqsdv1AAFeq/6MAAAP" Subject="TEST 2" FolderPathName="\Calendar" />
    </SourceItems>
  </Event>
  <Event MailboxGuid="5d8b10ca-2c1f-41fe-97dd-fe6f6529671c" Owner="Vorname Nachname" LastAccessed="2016-04-28T17:33:41+02:00" Operation="SendAs" ItemId="RgAAAABV5Gs0nfPsRqWTLmX3wbUoBwDDErzhrPTHTbQDBLYqsdv1AAAAAAEQAADDErzhrPTHTbQDBLYqsdv1AAFerAccAAAN" ItemSubject="Canceled: TEST 2" OperationResult="Succeeded" LogonType="Admin"
Die relevanten Stellen habe ich zur Übersichtlichkeit mal gelb markiert.

Wie sich hier zeigt, handelt es sich um die Einladung "TEST 2"
 
 
Diese ist um 17:33 vom User svcCRMCorp gelöscht (siehe Marker "HardDelete" und LogonUserDisplayName=svcCRMCorp) worden.


Wie sich in weiterer Folge herausgestellt hat, handelte es sich hier bei dem User um einen Service-Account mit administrativen Rechten, welcher in regelmässigem Intervall die Kalender der Mitarbeiter mit dem CRM-System synchronisierte.
Die weitere Fehlerbehandlung erfolgte danach auf dem CRM-Server.

Nicht vergessen:
Das Logging für die Mailbox sollte wieder deaktiviert werden.
 
Set-Mailbox -Identity "Vorname Nachname" -AuditEnabled $false