Kategorie-Archiv: Exchange

Ressourcenpostfach Kalenderbuchungen automatisch akzeptieren um Konflikte zu vermeiden

Veröffentlicht am von — Keine Kommentare ↓

Problem:

Ein Ressourcenpostfach (Gerätepostfach) soll Kalenderbuchungen automatisch akzeptieren. In der Standardeinstellung sind Konflikte bei der Buchung möglich.

Lösung:

Standardmäßig werden bei Gerätepostfächern Kalenderbuchungen zwar als „Mit Vorbehalt“ im Kalender eingetragen, allerdings nicht automatisch bestätigt. Somit sind auch doppelte Buchungen möglich.

Diese Einstellung lässt sich relativ schnell via Exchange-Management-Shell ändern:

Set-CalendarProcessing -Identity "POSTFACH" -AutomateProcessing AutoAccept

Kalenderdetails eines Ressourcenpostfaches anzeigen (Exchange 2016/Online)

Veröffentlicht am von — Keine Kommentare ↓

Problem:

Benutzer sehen im Kalender eines Ressourcenpostfaches standardmäßig lediglich den Frei-/Gebucht-Status und können Termine auch nicht zum anzeigen von Details öffnen.

Lösung:

Es gibt mehrere Möglichkeiten dies zu ändern:

  1. Einem Benutzer Vollzugriff auf das Ressourcenpostfach geben (via EMC). Mit diesem Benutzer können dann die Berechtigungen des Kalenders vom betroffenen Postfach angepasst werden. Oder:
  2. Die Kalenderberechtigungen für den „Default“-Benutzer via Exchange-Management-Shell anpassen:
Set-MailboxFolderPermission "POSTFACH-ID:\Kalender" -AccessRights Reviewer -User Default

Die Rolle „Reviewer“ behinhaltet die Berechtigungen „FolderVisible, ReadItems“, somit also auch das Anzeigen der Termindetails.
Die anderen möglichen Berechtigungen bzw. Rollen finden sich unter https://technet.microsoft.com/de-de/library/dd298062(v=exchg.160).aspx

Mapi session /o=Erste Organisation/ou=Erste administrative Gruppe/cn=Recipients/cn=benutzername with client type MoMT exceeded the maximum of 500 objects of type FolderView

Veröffentlicht am von — Keine Kommentare ↓

Problem

Bei einem (oder mehreren) Benutzer reagiert Outlook nicht mehr. Outlook sagt „Die Anwendung reagiert nicht“ und wird blass. Außerdem möchte sich das Outlook selbst nach einem Neustart nicht so richtig am Server anmelden und fragt ständig nach Benutzername und Kennwort. Nach einer Stunde geht wieder alles.

Zudem wird auf dem Exchange-Server diese Fehlermeldung im Anwendungsprotokoll protokolliert:

Mapi session /o=Erste Organisation/ou=Erste administrative Gruppe/cn=Recipients/cn=benutzername
with client type MoMT exceeded the maximum of 500 objects of type FolderView

Quelle: MSExchangeIS   Ereignis: 9646 (Event 9646)

Lösung

Das Exchange-Throtteling hat mal wieder zugeschlagen. Das passiert gerne mal, wenn ein Benutzer mehrere Mailboxen hgeöffnet hat.

Das FolderView-Objekt kann man in der Registry konfigurieren, unter HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\MaxObjsPerMapiSession. Wenn der Schlüssel „MaxObjsPerMapiSession“ noch nicht existiert, einfach anlegen.

In diesem Fall wird der FolderVie-Wert von 500 auf 2000 erhöht:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\MaxObjsPerMapiSession]
"objtFolder"=dword:000007d0
"objtFolderView"=dword:000007d0

E-Mails die in Outlook von einem gemeinsamen Postfach aus versendet werden, landen nicht im gemeinsamen „Gesendete Objekte“ Ordner

Veröffentlicht am von — Keine Kommentare ↓

Seit Office 2010 ist die Standardeinstellung von Outlook-Ablageobjekten nicht immer optimal. Neue Nachrichten, die von einem gemeinsamen (ob fremdgeöffnet oder als shared Mailbox angelegt ist egal) Postfach gesendet werden, werden nicht im Ordner „Gesendete Objekte“ des freigegebenen Postfachs abgelegt, sondern im Postfach des absendenden Benutzers. Das sorgt oft für Verwirrung.

Das liegt daran, das in Exchange 2010+ und Office 365 freigegebene Postfächer keine Lizenz mehr benötigen und man Outlook nicht mehr als „unabhängiges“ Postfach verbinden kann. In so einem Fall meldet man sich konsequenterweise aber beim eigenen Postfach an und öffnen das freigegebene Postfach zusätzlich. Beim Senden nimmt Outlook dann standartmäßig das Konto des Absenders. Daher werden Nachrichten – im Prinzip folgerichtig – auch immer im Ordner „Gesendete Objekte“ das Postfach des Absenders (also angemeldeten Nutzers) gespeichert.

Dieses Verhalten ist reine Outlook-Sache (nicht Exchange) und lässt sich schnell in der Registry anpassen:

HKCU\Software\Microsoft\Office\<VERSION>\Outlook\Preferences
DWORD: DelegateSentItemsStyle
Wert: 1 (für Ablage in geöffnetem Postfach)
Wert: 0 (für Ablage in eigenem Postfach, Standard)

certutil 0x80090005 (-2146893819 NTE_BAD_DATA)

Veröffentlicht am von — Keine Kommentare ↓

Wenn man unter Windows mit dem MMC Zertifikats-SnapIn einen frischen CSR erstellt („REQ“ im Windows-Jargon), wird standartmäßig der aktuelle „Microsoft Strong Crytographic Provider“ als Kryptoanbieter ausgewählt. Das ist im Prinzip auch gut so, denn das ist der aktuellste und vom Umfang her größte CSP (Certificate Storage Provider) den Windows mitbringt. Die meisten Windows-Features können damit auch problemlos umgehen – der IIS, der SMTP, RDS und so weiter.

Nicht jedoch Exchange (bis einschliesslich 2016 CU3). Exchange FBA unterstütz keine CNG Zertifikate. Nutzt man diese doch, kommt es zu dem berüchtigten Exchange OWA und Exchange EAC Anmeldeloop.

Folgt man dem im Blog angegebenen Anweisungen zum austausch der Zertifikates und erstellt ein neues passendes Zertifikat, kommt es beim Import der neuen Zertifikate (ob CER oder PFX spielt keine Rolle) oftmal zu dem Fehler

certutil 0x80090005 (-2146893819 NTE_BAD_DATA)

Ursache hierfür ist, das der im CSR angegebene CSP nicht korrekt ist. Wenn man den CSR unter Windows erstellt, versteckt sich das zugehörige Häkchen unter Neue Anforderung erstellen > Eigenschaften > Privater Schlüssel > Kryptografiedienstanbieter. Der für den CSR ausgewählte CSP lässt sich mit certutil an der Kommandozeile selbstverständlich nicht nachschauen …