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