SCCM – Powershell Erkennungsmethode schlägt fehl – Error 0x87D00327

Schon mal im SCCM eine Anwendung erstellt und dann auf die Idee gekommen, die Erkennungsmethode als PowerShell Skript zu implementieren? Und dann daran verzweifelt das, trotz korrekter Signatur, der blöde Skript nicht laufen wollte? Immer wieder die Fehlermeldung „Error 0x87D00327 (-2016410841) Script is not signed“ kommt?

Aber mit der Signatur ist natürlich alles in Ordnung, funktioniert ohne Probleme. Ich kenne das Problem jetzt seit SCCM 2012R2, konnte es bisher nicht zum Laufen bringen (nein, ich will die Execution Policy nicht auf „bypass“ stellen).

Letzte Woche habe ich es dann endlich gefunden. Es ist ein Encoding Problem. Ich erstelle meine Skripte meist mit Visual Studio Code, signiere sie dann und importiere dann in der SCCM Konsole. VSCode erstellt die Datei mit UTF-8:

Das ist leider falsch. SCCM braucht eine Datei mit „UTF-16 LE“- Encoding. Also auf UTF-8 klicken, dann Auswählen „Save with Encoding“:

Und dann das richtige Encoding auswählen:

Dann signieren und ab ins SCCM damit.

Bleibt die Frage: Warum, Microsoft, warum???

Mehr

Firewall Regeln in unbeaufsichtigter Windows Installation aktivieren

Aus dem Leben: Aufgabe war, eine automatisierte Installation eines Windows 2016 Servers zu generieren, bei der sofort RDP aktiv ist. Sieht einfach aus, ist auch überall dokumentiert, z.B. hier.

Funktioniert auch soweit, bis auf das Aktivieren der nötigen Firewall Regeln. Meine erste Idee war, das es ein Problem mit der deutschen Serverversion ist, weil die Regelgruppe, die aktiviert werden soll, im Deutschen „Remotedesktop“ heißt (statt „Remote Desktop“ im Englischen). War es aber nicht. Nach insgesamt 9! Versuchen habe ich dann das hier gefunden:

<FirewallGroups>
      <FirewallGroup wcm:action="add" wcm:keyValue="RemoteDesktop">
      <Active>true</Active>
      <Group>@FirewallAPI.dll,-28752</Group>
      <Profile>all</Profile>
   </FirewallGroup>
</FirewallGroups>

Zu beachten die Zeile „@FirewallAPI.dll,-28752“. Ich war also schon auf der richtigen Spur. Aber das die Abfrage beim Setup nicht auf den übersetzten Namen, sondern auf den Link in die DLL zur Ressource prüft, darauf bin ich dann doch nicht gekommen.
Die komplette Sektion in der unattended.txt für das Aktivieren von RDP sieht für den Windows Server 2016 wie folgt aus:

<settings pass="specialize">
    <component name="Microsoft-Windows-TerminalServices-LocalSessionManager" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS"
        xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" 
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
        <fDenyTSConnections>false</fDenyTSConnections>
    </component>
    <component name="Microsoft-Windows-TerminalServices-RDP-WinStationExtensions" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS"
        xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" 
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
        <UserAuthentication>0</UserAuthentication>
    </component>
    <component name="Networking-MPSSVC-Svc" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS"
        xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" 
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
        <FirewallGroups>
                    <FirewallGroup wcm:action="add" wcm:keyValue="RemoteDesktop">
                    <Active>true</Active>
                    <Group>@FirewallAPI.dll,-28752</Group>
                    <Profile>all</Profile>
                </FirewallGroup>
        </FirewallGroups>
    </component>
</settings>
Mehr

PRTG per Powershell bedienen

PRTG (https://www.de.paessler.com/prtg), mein Lieblingstool zur Netzwerküberwachung, hatte für mich bisher immer den Nachteil, das man es nicht so richtig auf der Kommandozeile bedienen konnte. Immer mal wieder kam die Aufgabe eine bestimmten Sensor zu allen bestehenden Server- Objekten hinzuzufügen. Kann man von Hand machen. Ist aber bei vielen Servern echt lästig.

Kurze Suche fördert das Projekt PrtgApi bei GitHub zu Tage. Gut gepflegt und aktuell lässt es praktisch keine Wünsche offen und mir das Herz höher schlagen.
Nachdem ich mir die richtigen Dateien zu einem Powershell- Modul zusammen kopiert und installiert hatte war das hinzufügen eines Sensors zu allen Servern eine Sache von ein paar Minuten:

import-module prtgapi 
connect-prtgserver servername

# Quelle
$quellSensor = get-device quellServer | get-sensor Quelle

# Und auf ein anderes Device klonen
get-device zielServer | clone-object -SourceID $quellSensor.id

# jetzt noch starten:
get-device zielServer | get-sensor Quelle | Resume-Object

Das geht natürlich auch mit einem Array an Zielservern…. sehr cool.
Die API kann noch viel mehr und es lohnt sich da mal etwas tiefer zu graben.

Mehr

PDFs aus Worddateien im Explorer erstellen

Microsoft Word hat ja seit einiger Zeit eine Möglichkeit direkt aus der Anwendung ein PDF zu erzeugen. Das ist praktisch und macht Adobe Acrobat für meine Zwecke komplett überflüssig. Ich hatte jedoch heute das Problem, das ich aus einer großen Anzahl von Dokumenten PDFs erzeugen wollte. Alle nacheinander öffnen und als PDF speichern kam mir so 90er vor. 😉

Nach kurzer Suche im Internet bin ich auf einen coolen Artikel hier gestoßen. Ist nichts weiter als ein kleines Makro in der „normal.dotx“ des Benutzers und ein Registry Key der über „HKEY_Classes_Root“ einen Eintrag in das Rechts- Klick- Menu einer Word- Datei zaubert. Der ruft dann das Makro auf, welches die Datei als PDF speichert. Sehr elegant. Man kann auch mehrere Dateien selektieren und sie konvertieren. Fast genau was ich wollte, bis auf zwei Kleinigkeiten:

  1. ich habe Office 2016 (nicht 2013 wie im Beispiel)
  2. ich will das pro Benutzer haben und nicht pro Rechner

Hier die korrigierten Dateien um meine Problem zu lösen:

Makro in der „normal.dotx“ des Benutzers:

Sub ExportToPDFext()
ChangeFileOpenDirectory ThisDocument.Path
ActiveDocument.ExportAsFixedFormat _
OutputFileName:=Left(ActiveDocument.FullName, InStrRev(ActiveDocument.FullName, ".")) + "pdf", _
ExportFormat:=wdExportFormatPDF, _
OpenAfterExport:=False, _
OptimizeFor:=wdExportOptimizeForPrint, _
Range:=wdExportAllDocument, _
From:=1, _
To:=1, _
Item:=wdExportDocumentContent, _
IncludeDocProps:=True, _
KeepIRM:=True, _
CreateBookmarks:=wdExportCreateNoBookmarks, _
DocStructureTags:=True, _
BitmapMissingFonts:=True, _
UseISO19005_1:=False
Application.Quit SaveChanges:=wdDoNotSaveChanges
End Sub

Registry- Einträge für „Als PDF speichern“ pro Benutzer:

Windows Registry Editor Version 5.00
 
[HKEY_CURRENT_USER\Software\Classes\Word.Document.8\shell\SavePDFhere]
@="Als PDF speichern"
 
[HKEY_CURRENT_USER\Software\Classes\Word.Document.8\shell\SavePDFhere\command]
@="\"C:\\Program Files\\Microsoft Office\\Office16\\WINWORD.EXE\" /mExportToPDFext /q \"%1\""
 
[HKEY_CURRENT_USER\Software\Classes\Word.Document.12\shell\SavePDFhere]
@="Als PDF speichern"
 
[HKEY_CURRENT_USER\Software\Classes\Word.Document.12\shell\SavePDFhere\command]
@="\"C:\\Program Files\\Microsoft Office\\Office16\\WINWORD.EXE\" /mExportToPDFext /q \"%1\""

Achtung: Das ist für die 64-Bit Version von Office 2016, für die 32-Bit Version die Pfade in der Registry entsprechend anpassen.

Mehr

Windows 10 Startmenu geht nicht…

oder genauer gesagt: Es funktioniert KEINE EINZIGE der „Modern“- Apps mehr. Das Startmenu ist nichts anderes. So geschehen, bei einem meiner Kunden beim Windows 10 Rollout. Passiert ist das nach der Installation einer bestimmten Anwendung. Welche, ist völlig egal. Wichtig ist, das das System nach der Installation unbrauchbar ist.
Es gibt echt viele Beschreibungen des Problems und auch einige Lösungen, nur leider funktionierten die alle nicht.

Schlussendlich, nach langen procmon– Sitzungen hab ich dann den Übeltäter gefunden:

HKLM\Software\Microsoft\Ole\DefaultAccessPermission

löschen per „regedit.exe“ (oder zum Test umbenennen, ihr wisst schon: Zu Risiken und Nebenwirkungen von Änderungen in der Registry fragen Sie vertrauensvoll…). Danach funktionierten sofort alle Apps wieder. Neustart war nicht nötig. Und, oh Wunder, die Anwendung die das Problem verursacht hat läuft auch noch.

Ende gut, alles gut.

Mehr