Ressourcenpostfach Kalenderbuchungen automatisch akzeptieren um Konflikte zu vermeiden

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)

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

Windows Store-Apps gehen nicht auf, Ereignis 5973 im Eventlog

Problem

Auf einem Windows 8/8.1/10 öffnen sich nicht (mehr) alle Windows Store Apps. Zudem wird (in etwa) dieser Fehler im Eventlog („Anwendung“) protokolliert:

Quelle: Microsoft-Windows-Power-Shell  (Oder unter Windows 10: Apps)
Ereignis-ID: 5973
Aufgabenkategorie: (5973)
Ebene: Fehler
Beschreibung
Fehler bei der Aktivierung der app AppID : Diese Anwendung unterstützt den angegebenen Vertrag nicht oder ist nicht installiert.
Weitere Informationen finden Sie im Protokoll „Microsoft-Windows-TWinUI/Betriebsbereit“.

Lösung

Spontanes Herunterfahren kann den Appcache in C:\Users\ < Benutzername > \AppData\Local\Packages beschädigen. Meistens hilft es, ein neues Benutzerkonto zu estellen und alle Daten zu migrieren. Den doofen Appcache kann man (unseres Wissens nach) leider nicht leeren ohne ihn zu zerstören.

  1. Neues Benutzerkonto (1) anlegen
  2. Neues Benutzerkonto (2) anlegen
  3. Windows NEU STARTEN (!) und mit (1) anmelden.
  4. Windows NEU STARTEN (!) und mit (2) anmelden.
  5. Alle Dateien aus dem alten (kaputten) Profilverzeichnis in das neue (1) kopieren (ausser NTUser.*)
  6. Neu starten und mit (1) anmelden und testen.

Meistens klappt dann schon wieder alles. Eventuell fehlen ein paar Einstellungen und Registry-Kram, aber die apps klappen wieder.

Windows Server 2012/2012R2 Windows Internal Database (WID) mit dem SQL Management Studio nutzen

Die Windows Internal Database (WID) ist ein ganz normaler SQL-Server (Express Edition), der sehr verschlossen konfiguriert ist. In der Regel benötigt man auch keinen direkten Zugriff darauf, außer es treten Fehler wie zum Beispiel der WSUS „Serverknoten zurücksetzen“ Effekt auf.

Es auch weiterhin möglich, sich mit dem SQL Management Studio (ab SMSS 2012 aufwärts) oder einer anderen SQL-Konsole der Wahl mit der WID-Instanz zu verbinden. Es gibt keinen TCP/IP listern mehr, daher man muß sich auf die entsprechende WID-Instanz mit dem passenden Memory-Pipe Verbindungsalias (Connection String) verbinden.

Die aktuellen Connectionstrings für WID

  • Windows Server 2008 und höher
    \\.\pipe\mssql$Microsoft##SSEE\sql\query
  • Windows Server 2012 und höher
    \\.\pipe\Microsoft##WID\tsql\query