Aus gegeben Anlass, ein shoutout auf spontane „schnellmaleben“ Bauarbeiten 👷🏼🏗️🚜
🤦
ugg.li Schnelle Hilfe für schnelle Admins
Nicht immer schön, aber effektiv. Schnelle Hilfe für schnelle Admins.
Aus gegeben Anlass, ein shoutout auf spontane „schnellmaleben“ Bauarbeiten 👷🏼🏗️🚜
🤦
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.
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
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
%programdata%\Veeam\backup365\config.xml
„Als Administrator“ bearbeiten <Archiver>
diesen Tag hinzufügen:<Proxy SkipTeamsMessagesDataFolders="True" />
Restart-Service -Name "Veeam.Archiver.Service"
Wenn Microsoft eine neue Version des SQL Servers released, bleiben neue Funktionen in der Regel der neuesten „Kompatibilitätsstufe“ vorbehalten. Beispielsweise ist die „Parameter Sensitive Plan Optimization (PSPO)“ aus dem SQL Server 2022 nur in Datenbanken verfügbar, die unter der Kompatibilitätsstufe („Level“) SQL Server 2022 ausgeführt werden.
Datenbanken behalten ihr Kompatibilitätslevel auch bei einem Upgrade des Servers, jeder SQL kann Datenbanken jeder älteren Version ausführen. Grundsätzlich eine gute Idee. Das bedeutet aber, ein [DB]Admin muss je nach Software ab und zu die Datenbanken aktualisieren. Manchmal wegen der neuen Features, manchmal weil Software das benötigt.
Wichtig: Die Versionsnummern für SQL Server und Azure SQL-Datenbank sind nicht so richtig miteinander vergleichbar. Azure SQL basiert zwar auf dem gleichen Code, aber die SQL Engine in Azure ist „immer“ die neueste. Zum Beispiel ist v12 von Azure SQL „neuer“ als v15 von einem lokalen SQL Server.
80 | SQL Server 2000 |
90 | SQL Server 2005 |
100 | SQL Server 2008 |
110 | SQL Server 2012 |
120 | SQL Server 2014 |
130 | SQL Server 2016 |
140 | SQL Server 2017 |
150 | SQL Server 2019 (+Azure SQL) |
160 | SQL Server 2022 |
Es gibt zwei Möglichkeiten, das Upgrade für eine Datenbank auszuführen.
Im SMSS geht das in der grafischen Oberfläche sehr komfortabel:
An einer SQL Shell, einer beliebigen – solange mit DBO-Rechten verbunden, kann man das mit diesem Einzeiler erledigen:
ALTER DATABASE <DB-NAME>
SET COMPATIBILITY_LEVEL = 150
Seit Juli 2023 plagt dieser Fehler einen Großteil der DATEV „Rechnungswesen“ Anwender. Während andere Hersteller das Problem längst behoben haben, verweist DATEV nur immer wieder auf „Microsoft“ 🤦
Die Fehlermeldung lautet:
Die Datei oder Assembly "office, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" oder eine Abhängigkeit davon wurde nicht gefunden. Zugriff verweigert
Natürlich kann Microsoft nichts dafür, wenn Softwarehersteller sich nicht an die vorgesehene Vorgehensweise halten, Office-Tools zu referenzieren.
Diese Lösung ist nur ein Workaround, aber schnell und einfach. Das Vorgehen setzt administrative Rechte voraus. Die DATEV-Software (bzw. deren Dienste) laufen zwar mit passenden Rechten, aber die Behebung des Fehlers bleibt dem Benutzer überlassen.
Das Tool setzt die Dateiberechtigungen zur Maximierung der Kompatibilität auf den Stand von .NET4 zurück, den DATEV benötigt.
Nachdem das Tool durchgelaufen ist, funktioniert Rechnungswesen wider, bis ein Update oder eine .NET FrameWork Erweiterung die Rechte wieder korrigiert. WQenn das der Fall sein sollte, einfach die Schritte wieder und wieder wiederholen. Bis DATEV den Fehler endgültig behebt.
Die referenzierte office.dll
(15.x) war lange für Abwärtskompatibilität von Add-Ins zu Office 2007/2010/2013 da. Alle diese Office-Versionen sind EOL – wenn aber der Support noch wichtig ist, sollte man einfach die korrekte COM-Referenz anstelle der „harten“ Datei-Referenz auf ein .NET4-Assembly (EOL 2022) verwenden.
Die „richtige“ Lösung (ironischerweise geliefert vom Microsoft Support, auf den DATEV verweist) ist einschliesslich Beispiel hier zu finden: https://github.com/dotnet/project-system/issues/5735