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.
Bei fast allen PDF-Dateien Dateien druckt der Adobe Reader (PCL6-Drucker) auf einmal ungewohnt langsam. Der Umgang mit PDFs, wie verschieben, Drag & Drop, Vorschau im Explorer und ähnliches sind ebenfalls langsam.
Lösung
Es gibt einen schnellen Registry-Fix, der dieses Problem mit „irritierenden“ (für den Adobe reader irritieren 🙂 Feature-States im schnell löst:
HKLM\SOFTWARE\Adobe\Acrobat Reader\DC\FeatureState
"FeatureState" (DWORD) auf "4033257" setzen (oder erstellen)
In 32bit-Installationen lautet der Pfad zu dem Schlüssel folgerichtig:
Nach einem Neustart des Readers, ist der Umgang mit PDF Dateien sofort wieder schnell. Der Explorer benötigt manchmal jedoch einen zusätzlichen Windows-Neustart.
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 …
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 😎