Die häufigsten Fehler des Administrators

Im Laufe der Jahre habe ich eine Listen von "häufigen" Fehlern gesammelt, die Administratoren mit Exchange gerne machen. Zu jedem Punkt finden Sie eine kurze Beschreibung der Auswirkung und Abhilfe. Haben Sie alles bedacht ?

Management

  1. Empfängerrichtlinien und X400 Adressen
    Exchange 2003 benötigt eine X.400 Adresse, ansonsten laufen einige Dienste gar nicht mehr an. Dummerweise kann es bei der Übernahme der Empfängerrichtlinien nach Exchange 2007/2010 passieren, dass die X400 Adresse nicht mit genommen wird. Das stört aber nicht nur neue Exchange Server sondern auch alte Server, wenn der RUS oder die Commandlets hier die Adressen entfernen.
  2. Arbeiten als Domänen Administrator
    Es ist immer eine schlechte Idee die tägliche Arbeit mit zu vielen "Rechten" zu erledigen. Aber es gibt auch handfeste Gründe, nicht als Administrator oder mit einem Konto, welches Mitglied in einer administrativen Gruppe ist, zu arbeiten. So haben "Domänen Administratoren" per default ein "DENY"-Recht auf die Postfachinhalte. Als Administrator haben Sie diesbezüglich also vielleicht weniger Rechte als ein Benutzer, der kein Admin ist. Zudem "schützt" das Active Directory "seine Administratoren" vor anderen Anwendern, indem es die Vererbung auf diese Benutzerkonten deaktiviert und anhand einer Vorlage (Stichwort AdminSDHolder) immer wieder setzt. Selbst wenn Sie jemandem Rechte auf den Benutzer geben, so sind diese nach einigen Minuten wieder auf den Standard Zurück gesetzt. Halten Sie sich daher einfach daran, dass Administratoren kein Postfach benötigen, da Sie nur Funktionskonten und keine Arbeitskonten für Mitarbeiter sind.
  3. Keine Mailboxlimits gesetzt
    Exchange hat per Default kein Limit auf Mailboxen. So kann es immer wieder passieren, dass ein Server quasi durch eine große Mail oder eine Mail in einer Schleife richtig an die Wand gedrückt wird. Beschränken Sie daher den Maximalplatz, den eine Mailbox haben darf. Es ist immer besser wenn ein Benutzer (auch wenn es der Chef ist) kurzfristig nicht arbeiten kann als  wenn der komplette Server ausfällt. Siehe auch Limits, oder wir kann ich Grenzen setzen.
  4. Message Limit
    Das gleiche gilt für die Maximalgröße der Mails innerhalb ihrer Organisation. Exchange 2003 setzt hier ein Limit von 10 Megabyte an. Frühere Versionen haben aber kein Limit. Dies sollten Sie ändern. Übrigens weist sie auch ExBPA darauf hin.
  5. Falsche Verwaltungstools
    Wer in einer reinen Exchange 2007+ Umgebung (ohne RUS) noch mit den Exchange 2003 Verwaltungstools arbeitet, wird Effekte und Probleme haben. So können Sie weiter mit AD Users & Computer einen Benutzer ein Postfach zuweisen, aber er wird nie eine Mailadresse bekommen. Es bleibt aus Exchange 2007+-Sicht ein "LegacyPostfach" und ohne RUS tut sich da auch nichts mehr mit den Proxy Adresses.

SMTP-Server und Routing

  1. Smarthost im virtuellen SMTP-Server
    Viele Administratoren tragen irrtümlich einen Smarthost beim virtuellen SMTP-Server ein, weil Sie damit den ausgehenden Mailverkehr über den Provider steuern wollen. Das ist definitiv falsch. Konfigurieren sie statt dessen einen SMTP-Connector mit einem Smarthost Eintrag. Ein Smarthost im virtuellen SMTP-Server stört fast immer die AD-Replikation über SMTP aber auch die Kommunikation der Exchange Server innerhalb einer Routing Group.
  2. Abweichender Hostname im virtuellen SMTP-Server
    Einige Firmen stört es, dass der echte Servernamen bei der Kommunikation per SMTP teilweise auch von extern sichtbar ist (z.B.: beim "TELNET Mailserver 25"). Man kann im virtuellen SMTP-Server den Namen des Servers ändern, so dass er auch beim Telnet auf den Mailserver angezeigt wird. Dies kann aber in Umgebungen mit mehreren Mailservern auch nach hinten losgehen, wie Sie auf Exchange 2000 MTA und Routing nachlesen können.
  3. Limits aus dem virtuellen SMTP-Server
    Im Gegensatz dazu ist es aber gefährlich auf dem virtuellen SMTP-Server Beschränkungen zu setzen. Diese greifen nämlich IMMER und betreffen dann auch die Replikationsnachrichten für öffentliche Ordner und für ein eventuell über SMTP repliziertes Active Directory. Nutzen Sie besser die Beschränkungen auf dem SMTP-Connector, der Organisation und den Postfächern. Siehe auch Limits, oder wir kann ich Grenzen setzen.
  4. Nicht autoritative SMTP-Domain
    Exchange lernt über die  Empfängerrichtlinien, welche Domains es bedient und welches es ausschließlich bedient. Die Default SMTP-Domain muss aber immer autoritativ sein. Wenn Sie ihre Default Domain mit einem anderen Mailsystem teilen wollen,  dann müssen Sie eine neue Default Domäne, z.B. "firma.local" wählen. Siehe RUS und Empfängerrichtlinien

Active Directory

  1. DC umkonfiguration
    Sehr oft werden Domain Controller nach einiger Zeit abgebaut oder verlagert. Beachten Sie bitte, dass Exchange selbst zwar eine automatische Erkennung durchführt und funktionstüchtige DCs meist alleine findet aber Dienste wie der ADC und der RUS nutzen fest konfigurierte DCs, die beim umbau entsprechend angepasst werden. Beide Dienste melden natürlich im Eventlog die Fehlfunktion. Überwachen Sie ihre Eventlogs ? (siehe  Überwachung von Exchange - Eventlog)
  2. DNS Eintrag verweist zuerst auf eigenen DNS-Server
    Wenn Sie mehrere DCs haben, und jeder DC zuerst sich selbst fragt und dann trägt dieser natürlich auch seine Adressen in seiner eigenen Zone ein. Nur wie "findet" der DC dann die anderen DCs, die sich auch alle bei sich selbst eintragen ?. Ohne diese Information kann sich aber das AD auch nicht replizieren und damit die im AD hinterlegten DNS-Zonendaten. Oder verlassen Sie sich auf die Daten, die beim DCPromo erstmalig im anderen DNS-Server eingetragen wurden ?. Meine Empfehlung lautet daher, dass zumindest ein DC einer Site einen DNS-Server in Richtung der der Zentrale nutzen sollte, damit z.B. Änderungen der lokalen IP-Adresse in den anderen Sites bekannt werden. Siehe auch DNS.
  3. Deaktivierte Vererbung
    Bei der Vergabe von Berechtigungen stören manchmal "zu viele" Rechte einiger Personen oder Gruppen. Man ist dann leicht versucht, die Vererbung abzuschalten, um die Rechte frisch zu vergeben. Leider verhindert dies auch, dass neue Rechte auf der Wurzel durch eine weitere Softwareinstallation (z.B. Exchange 2007) auf eben diese Objekte ebenfalls vererbt werden. Die Folgen sind manchmal dramatisch, wenn z.B.: der neue Exchange Server plötzlich nicht alle Benutzer sehen und bearbeiten kann. OWA funktioniert nicht, eine Anmeldung mit Outlook geht ebenfalls nicht. Also achten Sie genau darauf, wenn Sie eine Vererbung auf OUs abschalten.
  4. Vorsicht mit primären Gruppen
    Eine zweite Baustelle bei der der Vererbung ist der "Owner". Das Konto, welches z.B.: beim Exchange Setup OUs anlegt, ist zugleich auch "Besitzer". Aber auch die primäre Gruppe des Benutzers wird zum "Owner". Ist die primäre Gruppe dieses Benutzers nun "Domänen Benutzer", dann führt dies dazu, dass zukünftig alle Domänen Benutzer  viel zu viel Berechtigungen hat. Daher sollten administrative Benutzer niemals eine solche Gruppe als "primäre Gruppen" haben.
  5. Vererbung und DENY auf Domain Administrator
    Im Exchange System Manager werden viele Rechte vererbt. Nun kann es sein, dass jemand nicht möchte, dass sein Kollege mehr darf. ein DENY hilft aber sehr viel häufiger wird die Vererbung abgeschaltet, um z.B.:  bei den  Domänen Administratoren das Verbotsrecht auf  die  Postfächer zu entfernen. Auf Mailboxrechte steht, wie es besser geht.
  6. Fehlende Standorte in AD Sites & Services
    Diese Einstellung im AD ist wichtig, wenn Sie mehrere Standorte betreiben. Aber nicht nur die DC's wissen dann, wie sie effektiv eine Replikation aufbauen, sondern auch Exchange befragt die GC's und muss dazu natürlich wissen, in welchem Standort es selbst steht und welche Server wie weit netztechnisch entfernt stehen. Leider gibt es keinen Assistenten bei der Installation, der Sie auf diese kleine aber wichtige Konfiguration hinweist.
  7. M-Laufwerk
    Seit Exchange 2000 gibt es das Laufwerk M: auf dem Server. Früher wurde das WebstorageSystem als die wichtige Komponente der Zukunft gesehen und Exchange als Mittelpunkt. Allerdings hat sich bald gezeigt, dass Kompatibilität und Moderne nicht zueinander passen. Das Laufwerk M: ist aber auf vielen Exchange 2000 Servern noch aktiv obwohl es nicht benutzt wird oder benutzt werden sollte. Es ist sogar eher ein Risiko für den Server, weil z.B. einige Virenscanner auch diese virtuelle Laufwerk durchsuchen. Auf Laufwerk M: steht, wie Sie M: Ausblenden. Exchange 2003 zeigt es per Default nicht mehr an.

Webserver/IIS

  1. SSL auf Webserver
    Wer OWA betreibt, möchte OWA auch sicher machen. Der erste Schritt ist dabei die Aktivierung von SSL, damit alle Pakete verschlüsselt werden. Es  ist aber ein Fehler, wenn Sie dann SSL "erzwingen" wollen, weil dann der Exchange System Manager sehr oft z.B. keine öffentlichen Ordner mehr administrieren kann. Wenn Sie SSL erzwingen wollen, dann sollten Sie einen zweiten virtuellen HTTP-Server  dazu einrichten und diesen aus dem Internet erreichbar machen oder solche Zertifikate nutzen, dass auch der ESM damit umgehen  kann.
  2. IIS nicht abgesichert
    Auch wenn Sie ihren Server nicht aus  dem Internet über OWA zugänglich machen, sollten Sie unbedingt IISLOCKDown durchführen. Die größte Gefahr eines Servers kommt von innen über schnelle lokale Verbindungen. Sie glauben gar nicht, wie schnell ein PC einen Schädling  einfängt. Sei es, weil er zuhause ungesichert am Internet angeschlossen ist oder per Mail den Schädling erhalten hat. Virenscanner können keinen verschlüsselten Nachrichten oder Anlagen prüfen.

Infrastruktur

  1. Fehlendes Online Backup
    Viele Exchange Server werden aus unwissenheit nicht richtig gesichert. Das zeigt sich dadurch,  dass Transaktionsprotokolle voll laufen (Siehe  Exchange NOTFALL - Festplatte voll) oder im schlimmsten Falle erst beim Restore, dass doch nichts gesichert wurde. Dann ist guter Rat teuer und der Einsatz von ESEUTIL und ESEFILE oder Ontrack PowerControls 2.0 oft der einzige weg überhaupt etwas zu retten.
  2. Fehlendes Know-how
    Als Consultant kann ich ja einfach sagen, dass viele Firmen mangels Wissen und Schulung ihren Exchange Server gar nicht richtig nutzen oder manchmal blindlings in das Abenteuer Migration stürzen. Auch wenn es heute für vieles Assistenten und Anleitungen gibt, so  können diese keine Erfahrung und das Denken in Zusammenhängen ersetzen. Gerade die Umstellung von NT4 auf Active Directory und von Exchange 5.x auf Exchange 2000/2003 hat gezeigt, dass Sie nie zu viel wissen können und ein Erfahrungsaustausch über Newsgroups, Usergroups, Schulungen oder Einkaufen externer Unterstützung sich immer positiv auswirkt.
  3. Kein WINS-Server
    Sowohl Exchange 2000 als auch Exchange 2003 benötigen beide eine funktionierende NetBIOS-Namensauflösung. Wenn Sie daher im Vertrauten auf die Werbung und irreführende Versprechen auf die Installation und die Konfiguration eines WINS-Servers verzichtet haben, dann kann dies die Funktion von Exchange beeinflussen. Ohne WINS werden kurze Namen per Broadcast aufgelöst, was zum einen für eine höhere Netzwerklast und langsamere Namensauflösung sorgt und speziell bei Weitverkehrsnetzwerken mit Routern meist nicht funktioniert. Sie auch Namensauflösung im LAN und Internet.
    837391 Exchange Server 2003 and Exchange 2000 Server require NetBIOS name resolution für full functionality
    294222 Recipient Update Service does not process Users in remote Windows 2000 Domains
  4. Outlook auf dem Exchange Server
    Mit Exchange 5.5 war es mit bestimmten Versionen sogar noch problemlos möglich, Outlook auf den Exchange Server zu installieren, aber spätestens seit Exchange 2003 ist es nicht nur nicht mehr erlaubt, sondern es stört den Serverbetrieb. (Siehe auch Fakten: Outlook Client) Die Störungen sind z.B.: nicht mehr zugestellt Nachrichten, seltsame Fehlermeldungen im Exchange Administrator, Probleme mit dem EventService und weitere. Wenn allerdings Outlook schon installiert worden ist, dann ist es sehr schwer wieder retour zu gehen. Eine Deinstallation macht sehr oft Exchange unbrauchbar und erfordert eine Reinstallation. Aber auch dann wird die neuere MAPI von Outlook nicht immer durch das Exchange Setup überschrieben. Hier hilft es manchmal, die MAPI.DLL und MAPI32.DLL und alle weitere Kopien auf dem Server ebenfalls zu löschen oder den Namen zu ändern und dann eine Reparaturinstallation zu starten.
  5. ExBPA
    Es gibt seit einiger Zeit mit ExBPA ein ultimatives Tool, um die Gesundheit einer Exchange Umgebung zumindest zu bewerten und grobe Fehler einfach zu erkennen. Starten Sie EXBPA ruhig mehrmals im Monat. Es gibt sogar ein Managementpack für MOM2005, um dies zu automatisieren.
  6. Falsche Festplattenaufteilung
    Exchange nutzt neben der Datenbank auch Transaktionsprotokolle zur Sicherung gegen Ausfälle. Damit dies funktionieren kann, sollten beide Bereiche nie auf der gleichen Partition oder Festplatte zu liegen kommen. Ein anderer wichtiger Faktor ist aber die Geschwindigkeit. Richtig schnell wird Exchange, wenn Transaktionsprotokolle schnell geschrieben werden können. Hier können Sie optimieren. Siehe auch Exchange Sizing<br> Wie dimensioniere ich die Hardware ?

Dies sind die bislang mir ab häufigsten ausgefallenen Fehler in Exchange Umgebungen. Die Liste wird fortgesetzt.

Die häufigsten Fehler der Anwender

Aber auch die Outlook-Bediener haben ihre Macken und können den ein oder anderen Administrator zur Verzweiflung treiben. Wenn Sie sich über schlechte Performance beklagen und eigentlich selbst dafür verantwortlich sind. Dies gilt um so mehr, wenn Outlook nicht im Outlook 2003 Cached Mode betrieben wird und daher alle Elemente immer wieder vom Server geladen werden. Auch wenn Exchange einen Cache nutzt, so gibt es einige "Hammerabfragen", die einfach dauern, z.B.

  1. Terminansicht mit vielen Terminen
    Wenn Sie nicht nur ihren Termin, sondern auch andere Kalender mit einblenden, dann führt das dazu, dass Outlook von jedem Terminkalender alle Termine der fraglichen Zeit anlesen muss. Bei z.B. vier Kalendern mit 20 Terminen in der Monatsansicht bedeutet das so viel Last, als wenn Sie 80 Mails lesen möchten. Und das bitte gleichzeitig.
  2. Desktopsuche
    Google, Copernic, MSN Search und andere sind immer wieder Schreckgespenste für Administratoren, da diese Programme nicht nur den lokalen Desktop, sondern auch ihre Mailbox durchsuchbar machen. Dazu müssen diese Programme aber erst einmal alle Inhalte auch in ihren Index aufnehmen und jeden neuen Eintrag ebenfalls lesen. Entsprechend belastet wird natürlich das System. Denken Sie hier vielleicht einmal über eine Firmenrichtlinie nach, denn real verhindern können Sie es nicht. Allerdings gibt es Tools wie EXMON um solche Überbelastungen zumindest bei Verdacht zu erkennen. Exchange 2003 protokolliert auch im Eventlog, wenn ein Anwender mehr als 100 ausstehende RPC-Verbindungen hat, was auf eine solche Verwendung hinweist.
  3. Outlook Journal
    Sie können Outlook dazu nutzen, alle Tätigkeiten in einem Journal festzuhalten. Outlook protokolliert dann aber alle Tätigkeiten, z.B. das Bearbeiten von Dokumenten etc. mit. Da Sie diese Werte in der Regel doch nicht auswerten, sollten Sie diese Funktion einfach deaktivieren.
  4. Alles rund um Termine
    Einladungen zu gemeinsamen Terminen können jeden Admin den letzten Nerv rauben. Daher gibt es dazu eine eigene Seite TerminFAQ
  5. Ansichten, Regeln und Schnellansicht
    ...

Wird fortgesetzt