Könnten sich die Hersteller von Hardware mal bitte auf die eigentliche Funktion der Hardware besinnen… Das Überfrachten mit allen möglichen Features mag zwar verkaufsfördernd wirken, führt aber bei fehlerhafter Software/Treibern zu Fehlerbildern, die wirklich kein Mensch braucht.

In diesem Fall hatte ich im Rahmen einer Exchange 2003/2010 Migration das Problem, dass auf einem Rechner zusätzlich in Outlook 2003 eingebundene Postfächer als cached Postfächer dargestellt wurden. Das heißt, dass beim Klick auf dem Posteingang des zusätzlichen Postfaches dieses als “Verbunden” und nicht als "Online” angezeigt wurde.

Jedoch kann Outlook 2003 zusätzliche Postfächer noch gar nicht zwischen speichern. Diese Funktion kam erst in höheren Versionen dazu. Damit konnte dann halt auch nicht auf den Inhalt des Postfaches zugegriffen werden. Da dies besonders im Sekretariatsumfeld eine must have Funktion ist, eskaliert so etwas natürlich sofort.

Beim einem neu angelegten Mapi Profil war noch alles ok, nach dem Neustart von Outlook war das Profil im Eimer.

Nach drei Tagen Fehlersuche war der Übeltäter gefunden. “SetPoint” wurde über den Autostart Folder des AllUsers Profiles gestartet und hat das Mapi Profil zerlegt. Ich habe mir die Analyse des Mapi Profiles gespart…

Die Maus für die SetPoint die Konfiguration erledigen soll, hat wohl eine LED, die eingehende Mails signalisiert. Die Implementierung dafür, ist wohl in einer Unternehmensinfrastuktur nicht zu gebrauchen.

Entgegen einer weit verbreiteten Meinung, kann man sehr wohl Wildcard Zertifikate in Exchange 2007 bzw. Exchange 2010 für POP3 und IMAP4 einsetzten. Voraussetzung dafür ist mindestens Exchange 2007 SP1 Rollup 4.

Um das Zertifikat zu aktivieren muss nur der FQDN des CAS Servers bzw. des CAS-Arrays mit den folgenden Befehlen konfiguriert werden:

Set-ImapSettings -X509CertificateName FQDN

Set-PopSettings -X509CertificateName FQDN

Es müssen keine Services mit Enable-ExchangeCertificate für POP3 bzw. IMAP4 konfiguriert werden.

Es gibt zwei neue Hotfixe für die Zusammenarbeit von Exchange 2010 mit Outlook 2003 und 2007. Diese beheben unter anderem Probleme mit den Besprechungsanfragen in einer Exchange 2010 Umgebung.

Outlook 2003 – KB 2212002

Outlook 2007 – KB 983316

Immer wieder gibt es Probleme beim Entfernen eines Public Folder Stores. Deshalb schreibe ich hier mal die Erfahrungen beim Entfernen des Exchange 2007 PF Stores zusammen.

Bei der Deinstallation des verbleibenden MXS 2007 Server sagt der im Hintergrund laufende BPA, dass der Exchange Server nicht deinstalliert werden kann, da noch ein PF Store vorhanden ist.

Das Entfernen des PF Stores scheitert meistens daran, das noch irgendwelche Ordnerreplikate auf dem zu entfernenden Store festhängen. Ich gehe mal davon aus, dass die öffentlichen Ordner bereits auf den Exchange 2010 Server verschoben wurden. Ansonsten kann dies mit folgendem Powershell Befehl erfolgen:

MoveAllReplicas.ps1 -Server MXS2007 -NewServer MXS2010

Nach dem Abwarten der Replikation kontrolliert man die Replikate der Standardfolder mit:

Get-publicfolder \ -recurse |ft Name,Replicas

und die Replikate der Systemfolder mit:

Get-publicfolder \NON_IPM_SUBTREE -recurse |ft Name,Replicas

Keiner der Ordner sollte ein Replikat auf dem MXS 2007 Server haben!

Der Befehl:

Get-PublicFolderStatistics -Server MXS2007

gibt zusammenfassend Auskunft, über die Anzahl von Ordnern, die sich eventuell noch auf dem alten Server befinden.

Ich hatte außerdem dem Fall, dass sich das offline Adressbuch (OAB) unbedingt in den alten PF Store kopieren wollte. Der folgende Befehl zeigt die Datenbank an in die das OAB kopiert wird.

Get-OfflineAddressBook | fl *database*

Dies lies sich nur durch Löschen und Neuerstellung des OAB lösen.

Vor dem Löschen des PF Store muss auch der MXS2010 PS Store in den Client Eigenschaften der Datenbanken eingetragen werden.

image

Ebenso muss dort ein eventuell neu erstelltes OAB eingetragen werden.

Nach dem man es geschafft hat alle Ordnerreplikate auf dem MXS2007 Server zu löschen kann man noch vor dem folgenden Problem stehen:

Remove-PublicFolderDatabase : Object is read only because it was created by a future version of Exchange: 0.10 (14.0.100.0). Current supported version is 0.1 (8.0.535.0)

Der PF Store lässt sich nicht vom MXS2007 Server aus löschen. Dies kann man aber problemlos vom MXS2010 Server erledigen.

Der Befehl dafür lautet:

remove-publicfolderdatabase -identity “MXS2007\second storage group\public folder database”

Ich denke das ist der bessere Weg als, wie oftmals empfohlen und von einander abgeschrieben, den PF Store mit ADSI Edit zu löschen. Diese Lösung krankt z.B. daran, dass dabei der “SiteFolderName” nicht mehr richtig gesetzt ist.

Nun kann der MXS2007 Server deinstalliert werden.

Nachdem ich die Proxy Einstellungen des IE mit Netsh auf auf lokal System kopiert hatte,

image

bekam ich beim Starten der Verwaltungskonsole jedes Mal diese Fehlermeldung.

image

Die Lösung ist recht einfach. Man muss die lokale Domäne in den Proxyausnahmen konfigurieren und die Einstellungen wieder auf den lokal System Account kopieren.

image

Hintergrund Infos dazu gibt es bei Frank unter dem Stichpunkt WinRM.

image

Diese Fehlerbeschreibung kann sehr irreführend sein, da der Fehler möglicherweise nichts mit der Migration zu tun hat.

Bei einem Kunden trat genau dieses Problem nach dem Verschieben des Postfaches auf MXS 2010 auf. Wer würde da nicht erst einmal auf Exchange Seite nach dem Problem suchen…

Die eigentliche Ursache war der fehlende Haken auf dem Benutzerkonto, der für das Erben der übergeordneten Berechtigungen sorgt. Es ist schon erschreckend an wie vielen verschiedenen Stellen, dass fehlende Vererben der Berechtigungen für Ärger sorgt ;-)

image

Dieser Fehler wird von der Exchange Management Console (EMC) von Exchange 2010 zyklisch ausgegeben, nach dem Domänencontroller in der Domäne promoted oder demoted wurden. Um diesen Fehler loszuwerden muss die folgende Datei gelöscht und anschließend die EMC neu gestartet werden:

c:\users\<specific user>\appdata\roaming\microsoft\mmc\Exchange Management Console

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

Nächste Seite »