Zentraler Punkt in dem Script ist die Erkennung in welchem status die Installation gerade ist. Folgende Status sind möglich:

• Installation noch nicht eingeplant
• Installation eingeplant aber noch nicht gestartet
• Installation ist angelaufen aber noch nicht beendet
• Installation ist durchgelaufen

Zur Ermittlung dierer Status greifen wir wieder auf das Auslesen von PolicyInstancen zurück. Dazu werden am Anfang einige Policy-IDs definiert, die die verschiedene Status beschreiben:

Eine häufig bemängelte Einschränkung des SCCM 2007 ist es, dass die darin enthaltene Updateverteilung keine Updates automatisch freigeben kann. In größeren Umgebungen ist dies im Allgemeinen auch nicht wünschenswert, da neue Microsoft Updates zuerst getestet und dann erst verteilt werden sollten.

Bei Antivirendefinitionen macht ein solches Vorgehen keinen Sinn. Tests gegen alte und neue Viren oder gegen bestimmte Clients, um False-Positives zu erkennen kann man ein paar Mal machen, sobald Updates mehrfach am Tag kommen ist dies nicht mehr sinnvoll.

Diesmal gibt es ein paar interessante neue Management Packs (MP). Dazu zählt das MP für das BitLocker Administration  and Monitoring (MBAM) aus dem Microsoft Desktop Optimization Pack (MDOP) und das MP für das CRM 2011.

Auch das Self Service Portal 2.0 hat jetzt ein MP bekommen:

Neue Management Packs im Zeitraum zwischen 26.06.2011 und 16.07.2011

• Microsoft.BitLocker.Administration.And.Monitoring.ConnectorRules 1.0.3.1
• Microsoft.BitLocker.Administration.And.Monitoring 1.0.3.1

Jetzt wo wir einen Rechner per Powershell aufwecken können kommt als nächstes die Funktion um eine Neuinstallation anzustossen und sie wieder abzubrechen.

Der Abbruch ist deswegen relevant, da u.U. das WoL nicht funktioniert. Startet der Benutzer am nächsten Morgen den PC wieder ganz normal an, so würde die Installation direkt startet und er könnte ein paar Stunden nicht arbeiten. Daher stoppt das Script die Installation automatisch, falls sie nicht innerhalb eines bestimmten Zeitfenster gestartet werden konnte.

Hier ein kurzer Abriss wie PXE und unknown Computer in SCCM 2007 R2/R3 funktioniert:

1. Client bootet per PXE
2. Client holt sich per Broadcast eine DHCP Adresse vom DHCP Server, steht dieser nicht im gleichen Subnetz, dann muss er per IP Helper Adresse bekannt gemacht worden sein (Achtung: keine Bootoptionen notwendig)
3. Client sendet ein weiteres PXE Broadcast Paket um seinen Installationsserver zu finden (auch hier: IP Helper Eintrag!)
4. Der Dienst WDSServer auf dem SCCM erhält diese Nachricht und leitet sie an den integrierten PXE Filter von SCCM weiter
5. der SCCM Thread wertet die Anfrage aus (Logs zu finden unter SMS_CCM\Logs\smspxe.log, das SMS_CCM Verzeichnis liegt parallel zum “Microsoft Configuration Manager” Verzeichnis)
6. Er überprüft, ob die MAC bzw. GUID des Rechners in der Anfrage in der SCCM Datenbank bekannt ist
7. Falls ja, überprüft er, ob eine Tasksequenze für eine Neuinstallation zugeordnet ist und kein letzte PXE-Boot eingetragen ist (Auf dem Client in der MMC Console einen Rechten Mausklick und “Clear Last PXE Advertisement” auswählen um dieses Flag zu entfernen)
8. Falls nein, überprüft er, ob “Unkown Computer Support” in den Einstellungen aktiv ist (Site Systems\Servername\ConfigMgr PXE Service Point Eigenschaften und “Enable unknown computer support”). Ist dies der Fall sucht er sich die Collections heraus, in denen das “Unknown Computer” Objekt in der entsprechenden Prozessorarchitektur (x64, x86) vorhanden ist. Liegt auf einer eine erzwungene Task Sequence, dann sendet er dem Client das darin hinterlegte Win PE Boot Image und eine normale SCCM OS Installation startet.

Die System Center Cross Platform Solutions wurde von Microsoft als Open Source Produkt auf Codeplex bereitgestellt. Dies hat den Vorteil, dass man die SCX an andere Linux Systeme anpassen und selber nachschauen kann, wie Microsoft programmiert. Bei einer Recherche ist mir folgender Codeausschnitt aufgefallen:

#elif defined(sun)
// According to the Pegasus Solaris implementation they don't know how
// to determine this number, but they still return 0 for unlimited.
nolu = 0;
return true;
#else
// Thanks to the glory of free software there is no limit on the number of users!
nolu = 0;
return true;
#endif

Gefunden in osinstance.cpp unter http://scx.codeplex.com/SourceControl/changeset/view/32074#

In diesem Teil werden die Code Schnippchen zusammengebaut. Als Input benötigt das Script eine CSV Datei mit folgendem Header:

client,OU,User,Mac,OS,Softwareliste

• Client: Name des neuen Computers
• OU: Abteilungsname (wird als OrganisationalUnit abgebildet)
• User: Benutzername (wird in Description hinterlegt)
• Mac: MAC-Adresse des Computers (wird in InitialMacAddress hinterlegt)
• OS: Gruppe, in der der Computer für die OS-Installation eingeordnet werden muss
• Softwareliste: CSV Liste der zuzuordnenden Software (muss in ” stehen)

Somit sieht das Powershell Script so aus:

Kommen wir nun zum dritten Teil der Powershell Beispiele. Nach diesem Teil haben wir alle wesentlichen Bausteine für die automatisierte Rechnervorbereitung zusammen.

In diesem Teil wird die Software zu dem neu angelegten Computer zugeordnet. Dabei wird davon ausgegangen, dass die Software über statische Gruppen verteilt wird.

Als Input wird das fertige Programm eine CSV Datei erhalten, in der pro Zeile ein Computer steht. In der letzten Spalte mit dem Namen Softwareliste steht eine Liste der zuzuordnenden Software, die wiederum per Komma getrennt ist.

Bei einigen Automatisierungen ist es notwendig den Profilpfad eines Benutzers auszulesen und einen eventuellen DFS Pfad in einen physikalischen Pfad aufzulösen.

Hierfür habe ich eine kleine Batch-Datei geschrieben:

@echo off
set samaccountname=%~1
for /f "tokens=* usebackq" %%a in (`AdFind.exe -f "samaccountname=%samaccountname%" profilePath /list`) do (
set profilePath=%%a
)

for /f "delims=<> usebackq tokens=1,2,3,4,5" %%a in (`dfsutil diag viewdfspath %profilepath%`) do (
     if NOT %%e.==. set profilePath=%%e
)

echo %profilePath%

Der Profilpfad wird in Zeile 3 mit Hilfe von adfind anhand des Benutzernamens ermittelt, per for ausgewertet und an eine Umgebungsvariable übergeben.
Diese wird in Zeile 7 an dfsutil übergeben, dass mit dem Befehl diag den physikalischen Pfad anzeigt (ermittelt mit dem aktuellen Standort). Die Ausgabe wird erneut mittels for ausgewertet, wobei die Zeilen an den Größer- und Kleinerzeichen getrennt werden. An fünfter Stelle steht dabei der physikalische Pfad. Handelt es sich bei dem Profilpfad um keinen DFS basierten, dann ist die fünfte Stelle leer und wird daher nicht an die Variable übergeben.

In den letzten 14 Tagen kam das Management Pack für Duet Enterprise hinzu:

Neue Management Packs im Zeitraum zwischen 17.06.2011 und 26.06.2011

• Duet Enterprise 1.0 Management Pack 1.0.0.0
• MP Guide Duet Enterprise