Kalenderdetails eines Ressourcenpostfaches anzeigen (Exchange 2016/Online)

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

Windows EventID: 36888 – Quelle: Schannel – Warnung 10 – Fehlerstatus: 1203

Problem

Seit „einer Weile“ tauchen im Ereignisprotokoll ständig diese Meldungen auf:

Quelle: Schannel

Ereignis-ID: 36888

Ebene: Fehler

Es wurde eine schwerwiegende Warnug generiert: 10. Der interne Fehlerstatus lautet 1203.

Lösung

Das passiert gerne auf Maschinen mit installierten IIS oder Apps mit ausgehenden TLS-Verbindungen. Der Status 10 bedeutet: „TLS1_ALERT_UNEXPECTED_MESSAGE (10)“. Man kann das nachstellen, indem man ein nicht-TLS-Verbindung auf einen TLS-Port öffnet, z.B. mit http://SERVER:443/foo.

Das ist in aller Regel nicht schlimm und nervt nur. Die Verbindung wird auf jeden Fall beendet.

Man kann die Protokollierung des Fehlers in der Cryptoapi einfach deaktivieren, dann ist der Eintrag weg. Den Wert von „EventLogging“ in HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL einfach von „1“ auf „0“ umstellen.

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL]
"EventLogging"=dword:00000000

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

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

Windows Server 2003 RDP funktioniert nicht „Der RPC Server steht nicht zur Verfügung“

Problem

Es soll „da draußen“ noch einige Windows Server 2003 Altlasten geben. Nachdem solche Maschinen jahrelang herumgeschleppt, konvertiert und verschoben wurden, wollen die Windows-Server manchmal nicht  mehr so recht. Das ist uns heute auch passiert.

Bei dieser Maschine scheiterte jeder RDP (oder „Terminalsitzungs“-) Anemldeversuch mit der Fehlermeldung „Der RPC-Server steht nicht zur Verfügung“.

Lösung

Da diese Maschine nicht mehr lange leben wird, hilft der altbekannte RDP-Quick-Fix. Achtung, das löst das eigentlich Problem nicht (das meisten tiefer liegt), aber behebt dieses Symptom zuverlässig.

Einfach einen DWORD-Wert „IgnoreRegUserConfigErrors“ im Schlüssel „HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server“ erstellen, diesem den Wert „1“ verpassen, fertig. Die anmeldung tut es sofort wieder.

REGEDIT4

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server]

"IgnoreRegUserConfigErrors"=dword:00000001

SQL Server Management Studio „Das Ausfuerungstimeout ist abgelaufen“

Problem

Beim dem Versuch eine relativ große Tabelle im SQL Server Management Studio zu bearbeiten tritt der Fehler „Das Timeout ist abgelaufen.“ auf. Das gibt für Opetrationen wie auflisten, Index hinzufügen, Schlüssel ändern und ähnliches.

Die ganze Fehlermeldung lautet:

– Die Tabelle kann nicht geändert werden.
Das Timeout ist abgelaufen. Das Zeitlimit wurde überschritten, bevor der Vorgang beendet wurde, oder der Server antwortet nicht.

Lösung

Das Verhalten tritt aufgrund der Einstellung für Transaktionstimeouts für den Tabellen-Designer und den Datenbank-Designer in SQL Server Management Studio auf. Zum Glück ist das im Feld „Transaktionstimeout“ konfiguriertbar. Das Default ist mit 30Sekunden auch recht knapp bemessen. Man kann den Haken auch rausnehmen, dann wir das Remote-Timeout (Default: 10 Minuten) genommen. Eklrärung der anderen Optionen: https://msdn.microsoft.com/de-de/library/ms188490.aspx

Extras > optionen > Designer > Tabellen- und Datenbankdesigner