Windows Eventlog CAPI2 Event 513 „AddLegacyDriverFiles: Unable to back up image of binary“

Problem

Bei jedem Backup das einen externen VSS-Agenten benutzt, beispielsweise Veeam B&R mit Application Awareness, werden diese Fehler vom Kryptografiedienst (CAPI2 steht für „Windows CryptoAPI v2“) gemeldet. In der Meldung steht „Zugriff zudem verweigert“, was auf fehlenden Zugriffsrechte hindeutet.

Fehler beim Kryptografiedienst während der Verarbeitung des „OnIdentity()“-Aufrufobjekts „System Writer“.

Lösung

Das Dienstobjekt „Microsoft Link-Layer Discovery Protocol“ hat tatsächlich nicht die korrekten Berechtigungen, um vom VSS System Writer gelesen zu werden.

Man kann die Berechtiugung manuell hinzufügen, oder das die Kommandozeile erledigen lassen:

C:\> sc sdset mslldp D:(D;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BG)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SY)(A;;CCDCLCSWRPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWRPWPDTLOCRRC;;;SO)(A;;CCLCSWLOCRRC;;;SU)(A;;LCRPWP;;;S-1-5-80-3141615172-2057878085-1754447212-2405740020-3916490453)

Danach ist die Meldung sofort verschwunden 🙂

Update: Microsoft hat dazu einen KB-Artikel veröffentlicht https://support.microsoft.com/en-us/help/3209092/event-id-513-when-running-vss-in-windows-server

Outlook Programmgesteuerter Zugriff per GPO

Problem:

Ein externes Programm greift (automatisiert) auf Outlook zu. Dabei kommt es (sofern kein aktueller Virenscanner verfügbar) oft zu Bestätigungsmeldungen. (Meist kann man den Zugriff dann für bis zu 10 Minuten gewähren.)

In diesem fall soll auf einem Windows Server mit installiertem Outlook ein Prozess automatisiert werden. Dazu muss die automatisierungssoftware aber auf Outlook zugreifen können, ohne dass ein Benutzer aktiv diese Berechtigung vergeben kann.

Die Optionen im Trust Center („Programmgesteuerter Zugriff“) sind allerdings ausgegraut.

Lösung:

Die Steuerung der Trust Center Optionen ist (sogar noch etwas detaillierter) via GPO (ADMX-Vorlage) möglich.

Dazu werden die ADMX-Templates für die entsprechende Office-Version benötigt (Hier gibt’s die für Office 2016/2019 und Office365)

Nachdem selbige installiert wurden, findet man die passenden Einstellungen in den Gruppenrichtlinien hier:

Benutzerkonfiguration > Richtlinien > Administrative Vorlagen > Microsoft Outlook 2016 > Sicherheit > Sicherheitsformulareinstellungen

Zunächst muss hier die Einstellung „Outlook Sicherheitsmodus“ Aktiviert und als „Outlook-Sicherheitsrichtlinie: Outlook-Sicherheitsgruppenrichtlinie verwenden“ ausgewählt werden.

Danach lassen sich im Bereich „Programmatische Sicherheit“ die entsprechenden Meldungen konfigurieren. Die meisten externen Anwendungen benötigen hier „Eingabeaufforderung für Outlook-Objektmodell beim Lesen von Adressinformationen konfigurieren“ und „Eingabeaufforderung für Outlook-Objektmodell beim Senden von E-Mail konfigurieren“ Aktiv und „Schutzverhalten: Automatisch genehmigen„.

Microsoft „Teams“ mittels Gruppenrichtlinie aus dem Autostart entfernen oder hinzufügen

Teams ist der neue Hauptclient für eine schnelle und intelligente Kommunikation in Office 365 und ersetzt grade mit Lichtgeschwindigkeit Skype for Business (Online). Leider setzt Microsoft das grade etwas ungeschickt um und verteilt den Teams Client in Office-Updates mit konfigurierter Autostart-Option.

Teams aus Autostart entfernen (GPO)

Notwendig ist die Erstellung und Verknüpfung einer Gruppenrichtlinie, die den unerwünschten RUN-Eintrag aus der Registry der Benutzern entfernt.

GPO erstellen, dann unter Benutzerkonfiguration > Einstellungen > Windows-Einstellungen > Registrierung > Neu:

Aktion:         Löschen 
Struktur:       HKEY_CURRENT_USER 
Schlüsselpfad:  SOFTWARE\Microsoft\Windows\CurrentVersion\Run 
Wertname:       com.squirrel.Teams.Teams 

Teams zu Autostart hinzufügen

Das Hinzufügen funktioniert genauso – nur mit der Aktion „Erstellen“. Der zugehörige Befehl lautet allerdings anders als das original.

Original (funktioniert NICHT)
C:\Users\%username%\AppData\Local\Microsoft\Teams\Update.exe --processStart "Teams.exe" --process-start-args "--system-initiated"
So funktioniert es:

C:\Users\%username%\AppData\Local\Microsoft\Teams\Update.exe --processStart "Teams.exe" --process-start-args "--user-initiated" 

Set-RDCertificate cert.PFX ist keine PFX-Datei

Problem

Ich hatte gerade bei einem RDS-Deployment einen interessanten WTF-Moment. Es wurde ein ganz frisches SSL-Zertifikat von einer öffentlichen CA bestellt und installiert. Blieb also nur noch, dieses in der RDS-Bereitstellung einzurichten. Sobald das Zertifikat als .PFX exportiert wurde, sollte das per Powershell auch ganz einfach gehen (z.B. für die Gateway-Rolle):

PS C:\> $pfxPassword = Read-Host -AsSecureString
*************
PS C:\> Set-RDCertificate -Role RDGateway -ImportPath C:\install\cert.PFX -Password $pfxPassword

Und schon begrüßt mich der rote Text auf schwarzem Hintergrund:

Set-RDCertificate : ImportPath-Wert "C:\install\cert.PFX" ist keine PFX-Datei.
In Zeile:1 Zeichen:1
...

Lösung

Scheinbar ist das Cmdlet bezüglich der PFX-Dateiendung Case-Sensitive:

PS C:\> Set-RDCertificate -Role RDGateway -ImportPath C:\install\cert.pfx -Password $pfxPassword

funktioniert sofort. Und ja, es reicht wenn man „pfx“ im Cmdlet-Aufruf klein schreibt – der eigentliche Dateiname ist hier nicht relevant (zumindest was Groß-Kleinschreibung angeht).

Dem Server-Manager ist das übrigens auch egal. Über die GUI klappt’s ebenfalls sofort.

Windows 10 .Net Framework 3.5 Installation Fehler 0x080240438

Problem

Unter Windows 10 soll das .NET Framework 3.5 installiert werden. In der Systemsteuerung > Windows Funktionen lässt sich das Paket auch anwählen, aber die Installation schlägt mit dem Fehler 0x080240438 fehl.

Lösung

Die Ursache für 0x080240438 ist vermutlich eine fehlerhafte Verbindung zu ienem WSUS Server. „Fehlerhaft“ meint an dieser Stelle, das entweder der WSUS-Server das .NET Framework Paket nicht ausliefert (weil er es nicht hat), nicht kontaktiert werden konnte (anderes Netz) oder ein anderer Effekt vorliegt. Der Trick ist oft, den WSUS für dieses Paket einfach zu umgehen.

Die Frage „Von Windows Update herunterladen“ impliziert zwar den Download über eine Internet (und somit Microsoft Update) Verbindung – das ist aber nicht der Fall.

In der Registry UseWUServer auf ‚0‘ (und somit ‚online‘) umstellen:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU

 UseWUServer = "0"

Danach den Dienst Windows Installer, sofern noch gestartet, neu starten das selbe mit dem Windows-Update Dienst tun. Dann sollte die Installation sofort fehlerfrei (mit Download) durchlaufen.

HPE Server unbekanntes GErät „PCI\VEN_103C&DEV_3307&SUBSYS_3381103C“

Dies ist wieder so ein klarer Fall von „Notiz an mich selbst“ 🙂

Das Gerät „PCI\VEN_103C&DEV_3307&SUBSYS_3381103C“ in HPE ProLiant Servern, zum Beispiel „PCI\VEN_103C&DEV_3307&SUBSYS_3381103C&REV_05“ ist das HPE iLO Channel Interface. Man benötigt den „iLO 4 Channel Interface Driver“ dazu – notwendig um das iLO aus dem laufenden Betriebssystem heraus zu konfigurieren.

Download für Windows Server 2016/2019: https://support.hpe.com/hpsc/swd/public/detail?swItemId=MTX_eecbb80142984ad287ada4140d

Continue Microsoft Azure?

Beim Anpassen des „Azure SQL Database automatic tuning Plans“ für eine einzelne Datenbank scheint Azure *ganz* sicher gehen zu wollen.