Unternehmen investieren mittlerweile viel Zeit und Geld darin, Ihre Softwarepakete so zu gestalten, dass nach der Installation eines Computers die Compliance in der DSMC eine reale Aussage über den Zustand der Software auf dem Computer widerspiegelt. Umso schlimmer ist die Tatsache, dass ich wiederholt auf das Problem stoße, dass die Compliance eines Computer der grade frisch installiert wurde, schlichtweg ignoriert und dieser Computer an den Kunden ausgeliefert wird. Konsequenzen sind erhöhte Kosten im Helpdesk durch Folgefehler und auch das (durchaus hohe) Investment in saubere und qualitative Paketierungsprozesse, ist nicht mehr ganz zu rechtfertigen.

Erste Maßnahme ist in diesem Fall Aufklärungsarbeit. Die Compliance Informationen müssen dem technischen Personal, welches für die Installation von Computern zuständig ist, zur Verfügung gestellt werden (in Form von DSM Web, Wimera oder einer Eigenentwicklung). Mehr als einmal habe ich erlebt, dass ein Mitarbeiter ohne Zugriff auf die Informationen in der DSM Datenbank gemahnt wurde, einen Computer mit einer fehlerhaften Installation doch nicht so an seine Kunden auszuliefern.

Weiterhin muss dieses Personal intensiv darin geschult werden, diese Compliance Informationen auch zu nutzen und mit einer ggfs. „roten“ Installation eines Softwarepaketes/Computers korrekt umzugehen. Auch hier bieten sich diverse Möglichkeiten:

•     Der Computer kann vollständig neu installiert werden (wenn z.B. ein Fehler im Backend während der ersten Installation des Computers aufgetreten ist)
•     Die betroffene Software kann durch den Mitarbeiter auf „Reinstall“ gesetzt werden (z.B. durch den Einsatz von Wimera)
•     Es kann ein Ticket eröffnet und an das Client Management Team geleitet werden.

Leider ist diese Art der Schulung nicht immer leicht durchzuführen. Speziell im 1st Level Bereich ist ein stetiger Personalwechsel und Outsourcing an IT Dienstleister an der Tagesordnung.

Eine weitere Maßnahme, die mein Kollege Michael Jeske und ich vor einiger Zeit entwickelt haben, ist mehr technischer Natur. Diese zusätzliche Möglichkeit besteht darin, im Falle eines Fehlers, den Anmeldebildschirm nach der Installation vollständig zu sperren. Hilfsmittel sind hier der NWC Credential Provider, die NWC Powershell Extensions für DSM und die NWC PSX ISAPI, die Sie auf Anfrage von uns erhalten können. Weitere Voraussetzung ist, dass in während der Installation eines Computers ein definitiv allerletztes Paket läuft (im folgenden "Finishing Paket" genannt), in dass die Steuerung zur Freigabe des Anmeldebildschirms implementiert wird.

Sperren des Bildschirms

Im ersten Schritt wird (wenn nicht sowieso schon geschehen) der NWC Credential Provider in das OS Configuration Package implementiert. Dadurch ist sichergestellt, dass während der Installation der Anmeldebildschirm gesperrt ist. Mit Hilfe eines Job-Paketes, (mit dem Trigger "While starting a package") kann unterHKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\Credential Providers\{6945E482-393E-4989-BBC3-012291FCDD4E}\Settings der Registry Key SmallTextMessage mit der Variable %project.name% befüllt werden, um den Benutzer am Anmeldebildschirm über das aktuell zu installierende Paket zu informieren. im Falle einer Job-Policy ist diese Variable mit dem Namen des Paktes gefüllt, das den Job-Trigger ausgelöst hat.

Einrichten des PSX Webservices

Nun werden auf einem beliebigen IIS Server (der aber den BLS erreichen können muss) die PSX ISAPI und die PSX CmdLet's installiert. Die PSX ISAPI erlaubt es, ein Powershell Script auf dem Webserver auszuführen. Der Vorteil hierbei ist, dass auf dem Client keine Credentials für den Zugriff auf dem DSM Umgebung hinterlegt werden müssen, es ist lediglich ein Webservice Request zu diesem IIS Webserver notwendig. Zu Einrichtung der PSX Website wird ein neues virtuelles Verzeichnis auf der default Website eingetragen oder eine neue Website eröffnet (im folgenden PsAdmin). Anschließend muss die ISAPI bekanntgegeben und die Zugriffsdaten für den BLS in der web.config hinterlegt werden. Weiterhin wird (via Filesystem Berechtigungen) nur dem DSM Runtime Service User Berechtigungen auf das Webverzeichnis erteilt.

Im Anschluss wird auf der PsAdmin Site das PSX Script chkComplianceState_all.ps1 abgelegt. Mit diesem Script wird die Compliance eines Rechners ermittelt, dessen Name über die URL übergeben wird. Diese URL kann wie folgt aussehen, wenn die PsAdmin Site unter Port 8867 eingerichtet ist: 

 http://servername:8867/chkComplianceState_all.ps1?Client=kngw701&SerNr=0&man=innotek GmbH&mod=VirtualBox

Dies URL kann nun von einem beliebigen Browser abgesetzt werden um die Funktionalität des Scriptes zu testen. Führt ein Client diese Abfrage durch, prüft das Powershell script die Compliance des Computers in der DSM Datenbank und sendet eine E-Mail an einen (im script definierbaren) Administrator. Diese E-Mail kann auch dazu verwendet werden, um über einen E-Mail Watcher im Servicemanagement Tool, abhängig vom Text, bei fehlerhafter Compliance Prüfung einen Incident zu eröffnen. Um die E-Mail etwas aussagekräftiger zu gestalten können beliebig weitere Informationen (wie in diesem Beispiel der Hersteller und die Seriennummer des Computers) über die URL mitgegeben werden. 

Über die Powershell Variable "$IgnoreID" können zudem GUIDs definiert werden, deren Compliance nicht überprüft werden soll. Hier sollte mind. die GUID des Paketes gelistet sein, in dem der URL Aufruf durchgeführt wird. 

Einrichten des Clientseitigen Scriptes

Nach Einrichtung der Website und erfolgreichen Test, wird das folgende DSM Snippet im Finishing Script implementiert: 

RegModifyDWord('HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Domains\%_zoneMapDomain%','*','1',mrdwSet+reUseX64Hive)/TS
RegModifyDWord('HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Domains\%_zoneMapDomain%','*','1',mrdwSet)/TS
RegModifyDWord('HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Domains\%_zoneMapDomain%','*','1',mrdwSet+reUseX64Hive)/TS
RegModifyDWord('HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Domains\%_zoneMapDomain%','*','1',mrdwSet)/TS
! 
! # Relax powershell security
Execute('%WINSYSDIR%\WindowsPowerShell\v1.0\powershell.exe -Command Set-ExecutionPolicy ByPass -Force -Scope LocalMachine')/?/TS
! 
! # Copy PS1 script to local disk to avoid Share Access errors
Copy('.\extern$\ComplianceChk.ps1','%windir%\ComplianceChk.ps1')/TS
! 
! # Set script variables
Set('_CliTmp','%computername%')
Set('_PSAdminServer','%_targetServer%')
! 
! # Initialize return code handler
Set('_psReturnStatus','9999')
Set('_psIsCompliant','0')
! 
! # Only Netinstall Service Account can execute the Script on WebServer!
CallScript('%windir%\ComplianceChk.ps1')/TS
! 
! # Set default security for Powershell scripts
Execute('%WINSYSDIR%\WindowsPowerShell\v1.0\powershell.exe -Command Set-ExecutionPolicy Default -Force -Scope LocalMachine')/?/TS
! 
RegDeleteKey('HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Domains\%_zoneMapDomain%','',reUseX64Hive)/TS
RegDeleteKey('HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Domains\%_zoneMapDomain%','',)/TS
RegDeleteKey('HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Domains\%_zoneMapDomain%','',reUseX64Hive)/TS
RegDeleteKey('HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Domains\%_zoneMapDomain%','',)/TS
! 
Delete('%windir%\ComplianceChk.ps1')/TS

Die Variablen "%_zoneMapDomain%" und "%_targetServer%" müssen dabei noch vorweg gefüllt werden, wobei "%_zoneMapDomain%" den FQDN der Domäne und "%_targetServer%" den IIS bezeichnet, auf dem die PsAdmin Site implementiert ist. Das aufgerufene Powershell Script ComplianceChk.ps1 ist dafür zuständig, die URL aufzurufen und DSM Variablen "%_psReturnStatus%" und "%_psIsCompliant%" zu befüllen. "%_psReturnStatus%" wird dabei den HTTP Returncode (also 200 bei Erfolg) enthalten, während "%_psIsCompliant%" die Werte 1|0 enthält. 

Verläuft die Prüfung positiv (der Computer ist compliant) kann der NWC Credential Provider über den Registry Wert "IsEnabled=0" deaktiviert werden. Andernfalls bleibt er aktiv und über die Werte "LargeTextMessage" und/oder "SmallTextmessage" kann der Benutzer über den Misserfolg der Compliance Prüfung informiert werden.