image

image

Dieser nette Fehler tritt auf, wenn man sich in einer RDP Sitzung mit dem MXS 2010 Server verbindet und dabei die IP-Adresse und nicht den Namen des Servers verwendet. Ärgerlich, aber einfach zu vermeiden.

Danke an meinen Kollegen Sven für den Hinweis!

Es ist ja schon seit langen bekannt das die Service Pack Rollups nicht über Microsoft Update installiert werden sollen. Heute habe ich bei einem Kunden auch erleben dürfen warum ;-) Das Rollup 1 für das SP2 wurde auf diesem Weg installiert. Anschließend funktionierte OWA nicht mehr. Es gab einen leeren Anmeldebildschirm und einen Fehler in der flogon.js. Anscheinend hat der Windows Update Service unter W2K8 nicht die notwendigen Rechte, um alle Files aus dem Rollup zu kopieren.

Nach dem Deinstallieren des Rollups und dem anschließenden manuellen Reinstall war alles ok.

Microsoft sollte die Rollups auf jeden Fall aus dem Update Katalog der automatischen Updates entfernen. Das ist ein dicker Bug.

Manchmal könnte ich mich ins Flugzeug setzen, nach Redmond fliegen und da jemanden… MS hat es in Rollup 1 für das Exchange SP2 geschafft die Dateinamen ins Deutsche zu übersetzten. Wer sich erinnert – das gab es beim Erscheinen von Exchange 2007 schon einmal. Das für dazu, dass bei einem deutschen Exchange 2007 SP2 die Plugins auf der Seite “Toolbox” nicht geladen werden können.

Aufzeichnen

Um das zu fixen, müssen die Dateinamen in der Registry wieder in ihre englischen Originale umbenannt werden.

Da nicht jeder einen englischen Server zur Hand hat, habe ich den relevanten Registry Zweig exportiert. Dort kann man die Schreibweise nachschlagen. Relevant ist der Eintrage “Name”.

Registry Zweig – Toolbox

Dieses Problem habe ich bis jetzt schon mehrfach auf 2008 Member Servern erlebt. In einem Fall betraf es sogar den Build-In Administrator Account. Ich kann leider nicht mehr nachvollziehen was der eigentliche Auslöser des Problems war, aber die Lösung ist unter folgender URL beschrieben.

http://support.microsoft.com/default.aspx/kb/947242/en-us

Wer kennt die nervigen 9554 Meldungen nicht ;-) KB555433 beschreibt ja Wege den Benutzeraccount mit den fehlerhaften Berechtigungen zu finden und die Berechtigungen neu zu vererben. Allerdings ist es trotz Community Tool immer noch recht mühsam. Richtig einfach wird es bei Exchange 2007 durch Einsatz der Powershell. Nur die GUID des Eventlog Eintrages einfügen –

Get-MailboxStatistics | where { $_.MailboxGuid -eq ’6aa51785-0bf7-4f45-8c2c-88e9bcc79c01′ } |ft displayname,mailboxguid

und schon hat man den Übeltäter gefunden.

Seit dem SP1 unterstützt der ISA Server 2006 auch "subject alternate name" (SAN) Zertifikate. Dies macht das Veröffentlichen des Exchange 2007 Servers zum Internet wesentlich einfacher. Auf einigen Seiten ist erklärt, wie man ein SAN Zertifikat in der WEB Oberfläche der Windows 200x Zertifizierungsstelle beantragen kann. Ich meinen Tests wurde dies auch fehlerfrei ausgestellt und am Zertifikat waren keine Fehler zu erkennen. Jedoch hat der WEB-Listener des ISA Servers ein so ausgestelltes Zertifikat nicht als gültig akzeptiert. Eine Ursache habe ich nicht gefunden. Deshalb möchte ich kurz erklären wie man ein SAN Zertifikat für den ISA Server mit der Powershell des Exchange 2007 Server beantragen kann.

  1. Beantragen des Zertifikates

    New-ExchangeCertificate -generaterequest -subjectname "C=DE,DC=Kossert,O=kossert,CN=owa.kossert.com" -domainname owa.kossert.com,autodiscover.kossert.com –PrivateKeyExportable:$True –IncludeAutodiscover –IncludeAcceptedDomains -path c:\certrequest_4isa.txt

    Die Schalter "IncludeAutodiscover" und "IncludeAcceptedDomains" sind optional und sorgen dafür das alle akzeptierten E-Mails Domains in das Zertifikat aufgenommen werden.

  2. Eingabe des Inhaltes der c:\certrequest_4isa.txt Datei in das Webinterface der Zerfizierungsstelle. Das Template für die Zertifikatsausstellung ist "Webserver".
  3. Abspeichern des ausgestellten Zertifikates und Import in den Zertifikasspeicher des Exchange Servers.
  4. Export des Zertikates als *.PFX Datei. Hierbei muss der private Schlüssel mit exportiert werden.
  5. Kopieren der Datei auf den ISA Server und Import des Zertifikats in den Zertifkasspeicher des ISA Servers. Überprüfen das das Zertifikat auch vorhanden ist und nicht versehentlich in den Zertifikatspeicher des angemeldeten Benutzers importiert wurde.
  6. Auswahl des Zertifikats auf dem WEB Listener des ISA Servers.

Beim Verschieben von Postfächern von Exchange 2003 auf Exchange 2007 kommt es gelegentlich vor, dass nach dem erfolgreichen Verschieben des Postfaches und dem Durchlauf des "Cleanup Agents" auf MXS 2003er Seite das Postfach mit einem roten X angezeigt wird. Das Postfach lässt sich auch nicht leeren, da die Meldung kommt, dass es bereits wieder mit einem anderen Benutzer verbunden wurde.

Dies läst sich mit den Anweisungen aus KB940012 oder mit dem darin beschriebenen Hotfix beseitigen.

Da man auf einem zu migrierenden Server ungerne noch einen Hotfix einspielt, hier der Auszug des KB Artikels zur Umgehung des Problem:

To work around this problem, use one of the following methods:

  • Move the mailbox back to original mailbox store.
    Note This operation will fail. However, the stub object will be deleted. (bevorzugte Lösung da sofort durchführbar)
  • Wait for maintenance to clean the stub.

Immer wieder kommt die Frage auf, warum man an einen e-Mail aktivierten, öffentlichen Ordner keine e-Mails von extern schreiben kann.

Dies liegt an der fehlenden Authentifizierung. Wie soll sich jemand im Internet am öffentlichen Ordner authentifizieren? Damit dies Empfangen von externen e-Mails möglich ist, muss man dem Benutzer "Anonymous" das Recht geben, in diesem Ordner Elemente zu erstellen. Dies wird mit folgendem Powershell Befehl erledigt:

Add-PublicFolderClientPermission -Identity "\Ordnername" -User Anonymous -AccessRights CreateItems

image

Diese Fehlermeldung durfte man vor allem in Testumgebungen sehen, wenn man mit dem "Domänenname\Administrator" Account ein authentifiziertes Relaying testet. Dabei spielt es keine Rolle um es sich um Basic Authentifizierung im Klartext oder per TLS gesichert handelt.

Im Eventlog sieht das dann folgendermaßen aus:

image

Der Administrator Account ist ein “Well Known” security identifier (SID) und diesem Account ist es per default nicht erlaubt, Mails unter Angabe dieser Authentifizierung zu senden und zu empfangen.

image

Das Ganze mit einem Domänen Benutzer funktioniert problemlos. Also nicht verzweifeln und Fehler suchen die gar nicht existieren :-)

Unter Windows 2008 kann man bei der Überprüfung der Cluster Konfiguration auf den Fehler laufen, dass es eine doppelte IP V6 Adresse im Systemm gibt. Dies wird meistens durch das "Teredo Tunneling Pseudo-Interface" verursacht. Das Problem kann durch das Deaktivieren dieses Interfaces beseitigt werden. Man braucht das nicht auf dem Server.

  1. Open Device Manager

  2. Click View, then Show Hidden Devices

  3. Under Network Adapters find "Teredo Tunneling Pseudo-Interface"

  4. Right Click and select Disable

« Vorherige SeiteNächste Seite »