Windows Server 2019/2022 RRAS (VPN) Fehler „8007042a“

Microsoft hat mit einem der Updates aus 2023 eine mehr oder weniger folgenschwere Änderung eingeführt. Auf die Änderung an der Protokollierungsschnittstelle geht dieser Artikel nicht ein – aber auf die Folge.

Nach einem Reboot eines RRAS Servers funktioniert die VPN-Einwahl plötzlich nicht mehr. Auf dem Server ist der „Routing und RAS“ Dienst seltsamerweise nicht mehr gestartet und lässt sich auch nicht mehr starten. Das Ereignisprotokoll sowie die Fehlermeldung beim manuell Start zeigen den Fehler 8007042a an.

Lösung

Es liegt an der Startreihenfolge. Zuerst muss der RRAS-Dienst gestartet sein, dann darf der NPS (Netzwerkrichtlinienserver) folgen.

Quick-Fix: Beide Dienste beenden, Routing und RAS starten, dann NPS:

sc stop rasman
sc stop IAS
sc start rasman
timeout /t 3
sc start IAS

Eine dauerhafte Lösung, die auch beim nächsten Reboot funktioniert, ist die Abhängigkeit des NPS vom RRAS hinzuzufügen:

sc config IAS depend= RpcSS/RemoteAccess 

Dann klappt’s auch mit dem nächsten Neustart.

Vielleicht hätte Nadella bei Microsoft die QS-Abteilung für Updates doch nicht komplett hinauswerfen sollen …

Windows Notepad (Editor) zeigt Text plötzlich rechts an (Lesererichtung Rechts-nach-Links (RTL))

Wenn notepad.exe plötzlich „Allen Text rechts anzeigt“ ist etwas schiefgelaufen. Ich hatte grade so einen Fall und musste erst schmunzeln, weil das lustig aussah und dann etwas länger suchen, bis die Lösung dafür gefunden war.

Auf einmal ist „Alles nur noch rechts“

Lösung: Tastenkombination zum Umschalten

Die Lösung sind die STRG+Umschalt Tastenkombinationen zur Umschaltung der RTL/LTR Leserichtung:

[Strg] + [Umschalt rechts] Leserichtung von „rechts nach links“
[Strg] + [Umschalt links] Standard (DE): Leserichtung von „links nach rechts“

Man kann unterschiedliche Tabs sogar in unterschiedlichen Richtungen benutzt. Die Umschaltung ist on-the-fly.

SSD und HDD Modellnummern und Seriennummern unter Windows auslesen

Per Zufall grade gefunden: Man kann unter Windows schnell mal eben die Seriennummer(n) der angeschlossenen Festplatte(n) und SSDs herausfinden.

Der Windows Gerätemanager zeigt solche Gerätedaten (irritierenderweise) nicht an, aber zum Glück kann WMI das und die PowerShells spricht ja bekanntlich auch WMI.

Lösung

PowerShell

Get-PhysicalDisk | Select-Object FriendlyName,SerialNumber

CMD

wmic diskdrive get model,serialNumber,size

Microsoft Office 365 Apps auf RDS (RD-Sessionhosts) oder VDI Fehler „Da hat etwas nicht geklappt, [1001]“

Auf RDS oder in VDI-Umgebungen, auch mit FSLogix, sehen wir schon mal diesen Fehler, wenn ein Benutzer sein Office (meit Outlook) öffnen möchte:

Fehler: Es ist ein Fehler aufgetreten. [1001] 

oder auch

Fehler: Da hat etwas nicht geklappt. [1001] 

Der Effekt ist nicht wirklich persistent und scheint nicht immer aufzutreten. Manchmal geht es auch „Vormittags“ und „Nachmittags“ aber nicht mehr.

Lösung

Es gibt ein paar Pfade, die eigentlich nicht roamingfähig sind, aber in Szenarien mit FSLogix-Profilcontainern trotzdem unfreiwillig umgezogen werden. Die Ordner (und Registry-Schlüssel) werden somit zwischen RDS oder VDI Hosts „geroamt“ge-roamed“. Das macht die Schlüssel und Host-Zertifikate aber ungültig.

Am einfachsten ist es, die betreffenden Pfade und Registry-Schlüssel einfach zu löschen. Nach einem ab- und wieder anmelden tritt der Fehler dann nicht mehr auf, bis es wieder zu einem Hostwechsel kommt. Dann kann das Script aber einfach wieder ausgeführt werden.

@echo off
REM /*
REM	Office (Outlook) Fehler "1001" beheben
REM	https://support.microsoft.com/en-us/office/6f63238d-d83c-437c-a929-de72fe819793
REM	10.04.2024 Admins auf ugg.li
REM */

if exist "%localappdata%\Packages\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy" rd /s /q "%localappdata%\Packages\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy"
if exist "%localappdata%\Packages\Microsoft.Windows.CloudExperienceHost_cw5n1h2txyewy" rd /s /q "%localappdata%\Packages\Microsoft.Windows.CloudExperienceHost_cw5n1h2txyewy"

for /d %%i in ("%localappdata%\Packages\*") do (
	if exist %%i\AC\TokenBroker echo rd /s /q %%i\AC\TokenBroker
)

reg delete "HKEY_CURRENT_USER\SOFTWARE\Microsoft\IdentityCRL" /f
reg delete "HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\AAD" /f
reg delete "HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows NT\CurrentVersion\WorkplaceJoin" /f

Die „richtige“ Lösung wäre eine Anpassung von FSLogix, oder einfach ein Fix von Microsoft das roamed-certificates einfach einbezieht …

Veeam für Office 365 sichert nicht mehr richtig „Failed to get folder properties. Not allowed to access Non IPM folder“

Seit einer Weile™️ schlagen Veeam für Office 365 Sichrungsjobs fehl. Nach und nach sind immer mehr Unternehmen betroffen. Ein Job sichert dann praktisch keine Mailbox mehr, oder zumindest erweckt die Meldung den Anschein.

Die neue Fehlermeldung lautet:

Failed to get folder properties. Not allowed to access Non IPM folder

Lösung

Die Ursache: Microsoft rollt changes aus. Es geht um die Neuigkeit „Microsoft will restrict access via EWS to Teams message data starting on January 31, 2023„.

Das bedeutet natürlich nicht, das alle Tenants der ganzen Welt das „Update“ gleichzeitig bekommen. Mein Fall für heute ist auch genau von heute. Also vom 9.4.2024 (!). Wenn sich also jemand wundert, wie lange Updates manchmal zum ausrollen brauchen 😎

Der Fix ist zum Glück einfach

  1. Veeam-Config Datei %programdata%\Veeam\backup365\config.xml „Als Administrator“ bearbeiten
  2. In der Sektion <Archiver> diesen Tag hinzufügen:
    <Proxy SkipTeamsMessagesDataFolders="True" />
  3. Veeam Dienste neu starten, zum Beispiel an der PowerShell:
Restart-Service -Name "Veeam.Archiver.Service"