Office365 Exchange Synchronisationsfehler bei einer Shared-Mailbox

Folgendes Problem taucht in sehr vielen Office365-Accountsauf; interessanterweise nicht nur da, sondern auch in Exchange2010 on-premise Clustern.

  • Office365 Exchange Online (oder Exchange 2010)
  • Ein Benutzerpostfach als „Öffentliche Ordner“ ersatz erstellt (http://help.outlook.com/en-us/140/ee441202.aspx)
  • Outlook 2010 mit eingeschaltetem Cachemode
  • E-Mail und Exchange funktionieren soweit fehlerfrei
  • Dann tritt dieser Synchronisationsfehler mit enervierender Regelmäßigkeit auf:
17:46:42 Synchronisiererversion 14.0.6117
17:46:42 Postfach "Chuck Norris" wird synchronisiert
17:46:42 Änderungen im Ordner 'öffentlicher Ordner - Posteingang' auf dem Server werden synchronisiert
17:46:42 Download von Server "GNGNAMSTYLE0411.mailbox.outlook.com"
17:46:42 Fehler bei der Synchronisierung des Ordners.
17:46:42                  [80070005-508-80070005-560]
17:46:42                  Sie besitzen nicht die erforderlichen Berechtigungen, um diesen Vorgang auszuführen. Wenden Sie sich an die Kontaktperson dieses Ordners oder an Ihren Administrator.
17:46:42                  Microsoft Exchange-Informationsspeicher
17:46:42                  Weitere Informationen zu diesem Fehler erhalten Sie unter der folgenden URL:
...
17:46:42 Vorgang abgeschlossen

 

Manchmal hilft es den Cachemode abzuschalten. aber da Outlook 2010 ja oft grade wegen diesem Features genutzt wird, ist das natürlich keine Alternative.

Lösung

(Veröffentlicht von Marcus Strehlow [MSFT Support] am 12. September 2012)

es ist so dass wenn [man] Änderungen an einer Shared Mailbox vornimmt, im Sinne von Mails verschieben, oder auch dorthin senden, wird ein solcher Fehler generiert. Dieser Fehler verschwindet normalerweise wenn die Änderungen im Exchange Cluster propagiert wurden. Wenn jedoch die Mailbox laufend modifiziert wird, ist es momentan leider unumgänglich diese Meldungen zu bekommen.

Sprich: Ignorieren. Microsoft has confirmed this to be a problem but this Behavior is By Design. Fragt sich nur warum das immer alles so geheim ist.

Der Öffentliche Ordner „“ wurde auf Server nicht gefunden. (Get-PublicFolderStatistics InvalidOperationException)

Der Durchschnittsadministrator erhofft sich auf ein

Get-PublicFolder | Get-PublicFolderStatistics

in der Regel eine Liste der Öffentlichen Ordner und die zugehörige Statistik der Inhalte. Exchange 2010 quittiert diesen Versuch in der Regel mit einem Fehler:

Get-PublicFolder | Get-PublicFolderStatistics
Der Öffentliche Ordner "" wurde auf Server "<foobar>" nicht gefunden.<
    + CategoryInfo          : InvalidData: (:PublicFolderIdParameter) [Get-PublicFolderStatistics], InvalidOperationE
   xception
    + FullyQualifiedErrorId : 73C4D20B,Microsoft.Exchange.Management.MapiTasks.GetPublicFolderStatistics

Die Lösung lautet: das Ergebnis dieser Abfrage könnte ja theoretisch groß sein und daher … wird die Abfrage nicht ausgeführt. Das aufheben der Default-beschränkung (ob sie zuschlägt oder nicht) führt sofort zum gewünschten Ergebnis:

Get-PublicFolder "" -Recurse | Get-PublicFolderStatistics -ResultSize unlimited

Und weil wir grade dabei sind, diesen Schnipsel benutze ich öfter um mir eine grafische Übersicht über alle Öffentlichen Ordner, deren Inhalt und Eckdaten zu erstellen (erfordert das ISE):

Get-PublicFolder "" -Recurse | Get-PublicFolderStatistics -ResultSize unlimited | Select-Object FolderPath,AdminDisplayName,ItemCount,TotalItemSize,LastAccessTime | Out-GridView

Pullmail Download (direct download Mirror)

Unbezahlbar: ein direkter, schneller und zuverlässiger Download. Manchmal ist das Internet ganz schön nervig. Da gibt es ein cooles kleines Tool namens Pullmail, das E-Mails von einem POP3-Server abholen und auf einen SMTP zustellen kann; kaum ist der Autor (Mark Woollard) nicht mehr zu kriegen (hat bei SWSoft angefangen) ist auch der Download weg.

Ganz google ist Überfüllt von nervtötenden Spammern wie Softonic, Softpedia und dergleichen (Abfall) mehr, die einen Sysadmin gerne in diesen überflüssigen download-Kreisel-Tunnel verhungern lassen. Zum Glück gibt es aber ugg.li.

Hier ist der direkte, ungefilterte und unverseuchte Download von Pullmail 1.05 »

Achtung, das Tool ist nicht mehr ganz frisch, wird nicht weiter entwickelt und hat auch den einen oder anderen Bug. MAPI-Adressierte Mails mit Sonderzeichen im Absendernamen bleiben beispielsweise gerne mal hängen.

Ich persönlich nutze das allerdings gerne bei lokalen Mailserver Umstellungen um nachträglich nach der MX-Änderung eingetrudelte Mails noch in die passenden Postfächer abzuholen. Kann auch bestens Multithreaded gestartet werden, wenn der MTA schnell genug ist.

Exchange 2010 will Datenbank nicht verschieben „MapiExceptionNetworkError“

Exchange 2010 (SP1) möchte seine Datenbanken schon mal nicht freiwillig verschieben, wenn man die interne URL der OWA/OAB Dienste auf http umgestellt hat (um Zertifikatsfehler|kosten|Umstand zu vermeiden). Die Fehlermeldungen dazu sind auch recht kreativ, vor allem in EMC und EMS unterscheidlich.

Meist liesst man solche netten Dinge:

Der Status von Datenbank "Mailbox Database 0110421406" konnte nicht abgerufen werden.
    + CategoryInfo          : InvalidOperation: (Mailbox Database 0110421406:DatabaseIdParameter) [Move-DatabasePath],
    InvalidOperationException
    + FullyQualifiedErrorId : 79FDD20B,Microsoft.Exchange.Management.SystemConfigurationTasks.MoveDatabasePath

In diesem Fall reicht es aus, den SSL-erzwingen Haken von der ECP-zugehörgien  IIS-Site zu entfernen:

IIS-Manager -> Site -> SSL-Einstellungen -> SSL Erzwingen Haken entfernen -> Übernehmen.

Dann eine Rauchen gehen oder anders etwa 5 Minuten Zeit vertrödeln. EMC neu starten und schon geht wieder alles. Das das NATÜRLICH nicht die goldene Lösung ist dürfte dem Lokalen Administrator klar sein, aber wer will schon für seine internen Sitehostheader extra Zertifikate beantragen oder eine extra-PKI bauen?

WordPress und Word 2010 („Der Beitrag konnte nicht veröffentlicht werden“)

Wenn man einen Blogbeitrag aus Word veröffentlichen möchte und sich wundert warum trotz erfolgreicher Registrierung des WordPress-Kontos in Microsoft Word das Ganze nicht so recht funktionieren will („Der Beitrag konnte nicht veröffentlicht werden“) sollte man sich seine Office Templates in den Gruppenrichtlinien (GPO) nochmal genau anschauen. Die verursachende Einstellung dafür befindet sich unter Microsoft Word 2010 -> Word-Optionen -> Speichern ->Standarddateiformat. Word 2010 kann nur in WordPress veröffentlichen, wenn das Standard-Dateiformat nicht auf das alte Office-format geändert wurde. Ist das Standarddateiformat auf „*.doc“ eingestellt, wird in der lokalen Registry ein Eintrag gesetzt: REG_SZ „DefaultFormat“ mit dem Wert „doc“. Dieser befindet sich entweder unter: HKCUSoftwareMicrosoftOffice14.0WordOptions oder HKCUSoftwarePoliciesMicrosoftoffice14.0wordoptions Die Lösung: Entweder ändert man den Wert auf „*.docx“ direkt in der Registry (und schaltet die entsprechende Richtlinie ab), oder ändert seine GPO dementsprechend. Nach dem nächsten Word-Start passt schon alles. Danke an den Dariusz G. für den Schnipsel und die aufwändige Recherche dazu. Wir hoffen das dieser Artikel anderen Administratoren bei diesem fies zu suchenden Fehler weiterhilft.