Outlook Abwesenheitsassistent Automatische Antworten – Server nicht verfügbar

Problem

Man möchte in seinem Outlook den Autoresponder aktivieren (Automatische Antworten / Abwesenheitsassistent), allerdings bekommt man lediglich folgenden Hinweis:

Ihre Einstellungen für automatische Antworten können nicht angezeigt werden, da der Server zurzeit nicht verfügbar ist.

oder englisch:
Your automatic reply settings cannot be displayed, because the server is currently unavailable. Try again later.

Lösung

Häufig liegt dies an falsch konfigurierten Autodiscover-Einstellungen, Proxys (bzw. fehlende Ausnahmen) vor dem Exchange-Server oder falschen Zertifikaten.

In einigen Fällen, kann es allerdings auch mit Authentifizierungsfehlern zu tun haben (der erste Hinweis in diese Richtung war: https://support.microsoft.com/en-us/help/2596516/your-out-of-office-settings-cannot-be-displayed-because-the-server-is)

In unserem Fall waren die Anmeldedaten an sich allerdings korrekt (das Profil wurde auch via SSO eingerichtet, alles super). Schuld waren letztendlich gespeicherte Windows-Anmeldedaten in der Anmeldeinformationsverwaltung. Sobald diese entfernt wurden klappen auch die Automatischen Antworten wieder.

Vermutlich sind die Anmeldedaten dort gelandet, da vorher ein weiteres Postfach im Outlook eingerichtet war. Sobald hier die Zugangsdaten einmal gespeichert werden, kommt der genannte Fehler wieder zustande.

Windows Server 2019 RRAS startet nicht (8007042a) – NPS Event 4405

Problem

Ein Frisch installierter Windows Server 2019 mit konfigurierter Routing & RAS Rolle möchte den RRAS Dienst nicht starten – „Dienstspezifischer Fehler 8007042a“

Das System-Eventlog zeigt ein paar Events des Netzwerkrichtlinienservers (NPS) – unter Anderem Event-ID 4405

NPS kann die Kontoinformationen nicht im primären Datenspeicher (C:\Windows\system32\LogFiles\IN1906.log) protokollieren. Aufgrund dieses Protokollierungsfehlers verwirft NPS alle Verbindungsanforderungen. Fehlerinformationen: 22.

Lösung

Der RRAS-Dienst muss vor dem NPS starten. Dazu einfach den Starttyp von „Routing und RAS“ auf Automatisch und den vom „Netzwerkrichtlinienserver“ auf Automatisch (Verzögerter Start) stellen und schon funktionieren beide korrekt.

Sollte es noch nicht klappen, könnte auch noch die Windows Defender Firewall schuld sein:

Der Fehler ist mehr oder weniger bekannt (siehe https://windowsserver.uservoice.com/forums/295059-networking/suggestions/35724043-fix-default-nps-firewall-rules-for-server-2019 )

Das Problem sind fehlerhafte Standard-Firewallregeln für den NPS. Fügt man manuell eine Regel hinzu, welche die beiden UDP Ports 1812 und 1813 eingehend erlaubt (das deaktivieren der Firewall hilft hier nicht), reicht ein Neustart des NPS und anschließend klappt auch das starten des RRAS-Dienstes.

Windows 10 1809 Websuche im Startmenü abschalten

Diese blöde unnütze Websuche im Windows 10 Startmenü ist deutlich häufiger lästig als hilfreich. Natürlich gibt es keine Möglichkeit, diese in der Systemsteuerung auszuschalten.

So gehts:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Search]
"BingSearchEnabled"=dword:00000000

Veeam Update „Warning 1327.Invalid Drive D:\“

Normalerweise sind Veeam Backup&Replication Updates dank der extensiven Q&A-Kultur von Veeam äußerst stressfrei und unter Berücksichtung der neuen Features/Funktionen schnell erledigt. Es gibt aber ein Problem im Setup der aktuellen Versionen (hier: Update 4a) wenn der „Veeam Backup Catalog“ irgendwann einmal verschoben wurde. Das Update-Setup

Warning 1327.Invalid Drive: D:\

Lösung

Der VBRCatalog wurde offensichtlich irgendwann einmal verschoben. Das Setup liesst bei der Installation einmal den Pfad aus der Windows-Freigabe aus, wenn die Installation lokal ist, und versucht diesen veralteten Pfad dann erfolglos zu nutzen.

  1. In der Computerverwaltung unter den Freigaben die Freigabe „VBRCatalog“ prüfen und den Pfad korrigieren (auf die Berechtigungen achten!)
  2. In der Registry diesen Pfad ebenfalls korrigieren: HKEY_LOCAL_MACHINE\SOFTWARE\Veeam\Veeam Backup Catalog (Zeichenfolge: „CatalogPath“ auf den richtigen Pfad ändern, zum Beispel „C:\VBRCatalog“)

Danach das Setup neu starten und schon läuft es wie gewohnt stressfrei durch.

Powershell Scripts starten in der Aufgabenplanung nicht (Ergebnis 0x1)

Problem

Im Taskplaner (Aufgabenplanung) angelegte Powershell-Scripte (*.ps1) starten trotz „richtigem“ Aufruf (%System32%\WindowsPowerShell\v1.0\powershell.exe …) nicht und geben das Ergebis 0x1 zurück

Lösung

Meistens ist die ExecutionPolicy schuld. Mal ist es der 32bit-Powershell-Interpreter, dann wieder 64bit. Die Aufgabenplanung startet per Default x64, aber beide Interpreter haben eigene Policys. Es kann auch eine lokale- oder nichtlokale Profileinstellung sein oder Policy-Changes nach einem Update Es gibt viele Ursachen. Es hat sich daher bewährt, die Policy pro Script zu umgehen:

powershell.exe -NoProfile -NoLogo -NonInteractive -ExecutionPolicy Bypass -File \\<SERVER>\<FREIGABE>\<SCRIPT>.ps1

-NoProfile Stell sicher, das das Script ohne ein lokales Profil ausgeführt wird und somit immer „kollisionsfrei“ bleibt. Außerdem vermeidet man so den langsamen Overhead sämtlichen Profilcodes/aliases/Snipplets/Imports.
-NoLogo Lässt das Startlogo weg. Hilfreich wenn man den vollständigen Output umleitet. Und total gut fürs Admin-Gefühl.
-NonInteractive Umgeht Wartezeiten für Benutzereingaben, indem es letztere weglässt; genauer: durch ein ‚exit 100‘ ersetzt. Das Script hängt also nicht mehr bei Prompts, sondern beendt siche selbst mit dem Fehler 0x100.
-ExecutionPolicy Bypass Umgehen die lokale Executionpolicy. ‚unrestricted‘ ist natürlich ebenfalls möglich. Wir empfehlen aber ‚Bypass‘, weil das Probleme mit globalen Konfigurationsänderungen der Policys (jetzt und in Zukunft) umgeht.

Swyx Server Line Manager kollidiert mit Windows DNS Server Ports

Problem

Auf einem Swyx Server werden nach einem Reboot oder Dienstneustart des SwyxLinkManager die angelegten SIP-Trunks nicht mehr korrekt (oder nicht mehr alle) angemeldet. Manchmal funktioniert die Bereitstellung der Trunks auch scheinbar fehlerfrei, aber es kann nur in eine „Richtung“ telefoniert werden. Beispielsweise ist eine eingehende Rufsignalisierung kein Problem, die ausgehende funktioniert aber nicht. Dieses Verhalten scheint nicht reproduzierbar, sondern stellt sich „mal so mal so“ dar. Das passiert hauptsächlich auf Maschinen mit Windows DNS-Server.

Lösung

Der „SwyxLinkmanger“ benötigt für die einwandfreie Funktion folgende (UDP-)Ports:

SwyxServer 51000-51499
LinkManager55000-56000

Verbindungen unterteilen sich dabei in „Callcontrol“ (für den Verbindungsauf- und Verbindungsabbau) sowie die „Payload-“ oder „Datenphase“ in der der eigentlich Versand der Datenpakete mit Audio- oder Faxinhalten stattfindet.

Audiodaten werden immer per UDP Protokoll übertragen. Faxdaten hingegen können per UDP (überwiegend) oder TCP übertragen werden. Die Voreinstellung ist, zumindest bis SwyxWare v4.10, UDP. Sowohl die Quell- als auch die UDP/TCP-Zielports kommen aus den oben aufgeführten Bereichen.

Diese werden nun gerne beim starten des Windows DNS Dienstes belegt; dieser belegt eine ganze Menge an listener-Sockets im guten Glauben an viel DNS-Traffic. Man kann (und sollte) diese Ports einfach im DNS Server blockieren, dann entstehen keine Konflikte und die Telefonie funktioniert auch nach einen Reboot.

c:\> dnscmd /Config /SocketPoolExcludedPortRanges 51000-51490 55000-56000
c:\> sc stop dns & timeout 3 & sc start dns

Windows Server 2012/2012R2 RDS und/oder Windows 8/8.1/10 hängen bei „abmelden“ ewig fest

Problem

Wir sehen öfter den Fehler, das ein Windows Server 2012 RDS Session Host beim abmelden hängenbleibt. Das auch gerne ausdauernd lange. Dieses Verhalten lässt sich reproduzieren, wenn das Kennwort des angemeldeten Benutzers geändert wird.

Lösung

Das liegt (meist) an dem fehlenden Fix KB3132080, der diesen Effekt zwar behebt, aber andere Probleme mitbringt.

Es geht für den schnellen Admin aber auch manuell und flott, wenn man einfach die hängenden RDP-Sessions manuell beendet.

CMD-Session auf dem betroffenen Host öffnen:
C:\> psexec \\<MEINSERVER> cmd

offene RDP-Sessions auflisten:
C:\Windows> query session

offene RDP- Session beenden
logoff <ID>