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.

In diesem Blog-Post werden zwei weitere Komponenten des Scripts vorgestellt: Ping und somit den Status eines Rechners ermitteln und die Ermittlung ob ein Benutzer angemeldet ist.

Je nach dem Status des Systems kann ein Rechner sofort neuinstalliert werden (wenn er aus ist, oder er läuft aber an einem Client kein Benutzer angemeldet ist). Sollte ein Benutzer angemeldet sein, dann darf eine Neuinstallation nur nach einer gewissen Uhrzeit erzwungen werden (z.B. ausserhalb der normalen Arbeitszeit).

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.

Wie versprochen geht es weiter mit der Automatisierung von Enteo durch Powershell. In diesem Blog Eintrag nehme ich mir die Funktion für das Aufwecken eines PCs vor. Leider funktioniert hier die WoL Funktion von Enteo nicht immer. Das liegt u.a. daran, dass bei einem neuen PC nicht alle Informationen vorliegen. In den meisten Netzen wird ein normales WoL Paket (ein Broadcast Paket) nicht an alle Subnetze verteilt. Der Enteo Server und der zu weckende Client sind im Allgemeinen in unterschiedlichen Subnetzen beheimatet. Daher muss mit einem directed Broadcast gearbeitet werden. Dazu wird das Broadcast Paket direkt an die Broadcast Adresse des Zielsubnetzes geschickt. Dazu ist aber die IP Adresse und die Subnetzmaske zur Ermittlung der Broadcast Adresse notwendig. Diese Information liegt Enteo nicht immer vor und ich habe noch keinen Weg gefunden, diese Info beim Erstellen des Computerkontos mitzugeben.

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.