Torsten's Blog

Sicher ist es manchmal ganz hilfreich, eine Übersicht über alle Advertisements einer Site zu haben, die nach “optional” oder “mandatory” untergliedert ist.
Dies kann recht einfach über “Search Folders” innerhalb der Konsole erreicht werden.

Für die optionalen Advertisements wird ein neuer Search Folder mit folgenden Kriterien erstellt:

- einen Haken bei “Advertisement Flags” setzen
- in der Search List den Wert “0″ (inkl. Anführungszeichen!) eintragen
- einen Haken bei “Search all folders under this feature”
- einen Namen für den Search Folder vergeben (z.B. All optional advertisements)

 Analog geht man für die mandatory Advertisements vor:

- einen Haken bei “Advertisement Flags” setzen
- in der Search List die Werte 1 bis 9 jeweils separat eintragen
- einen Haken bei “Search all folders under this feature”
- einen Namen für den Search Folder vergeben (z.B. All mandatory advertisements)

Das wichtigste Log für Troubleshooting beim Operating System Deployment (OSD) mit ConfigMgr ist das smsts.log.
Dieses ist aber leider – je nach Situation – an unterschiedlichen Stellen zu finden:

- X:\windows\temp\smstslog\smsts.log: Boot von WindowsPE / vor dem Formatieren der HDD
- C:\_SMSTaskSequence\logs\smstslog\smsts.log: smsts.log wird nach dem Formatieren der HDD dorthin kopiert
- C:\_SMSTaskSequence\logs\smstslog\smsts.log: Ziel-OS bereits vorhanden, aber ConfigMgr-Client noch nicht installiert
- %windir%\system32\ccm\logs\smstslog\smsts.log: Ziel-OS bereits vorhanden, ConfigMgr-Client jedoch schon installiert
- %windir%\system32\ccm\logs\smsts.log: nach der Ausführung des Tasksequenz

(Vorausgesetzt es wurde kein abweichender Installations-Pfad angegeben. Bei x64 Betriebssystemen befindet sich der Client in %windir%\SysWoW64\ccm).

Ich habe ja bereits hier über die Neuerungen von R3 berichtet. Seit gestern gibt es den Release Candidate (RC) von R3 auf connect.microsoft.com zum Download:

Das Update 1 für MDT 2010 steht unter http://technet.microsoft.com/en-us/library/ee376932.aspx zum Download bereit.

Seit heute werden einige zusätzliche Produkte in Zusammenhang mit ConfigMgr offiziell unterstützt, darunter auch SQL 2008 R2. Eine gute Übersicht findet man hier.

Die Überschrift passt aktuell zur Fußball WM 2010, hat damit aber nichts zu tun. Heute kam (bereits zum insgesamt 6. Mal – wie die Zeit doch vergeht) eine Email die mit den Worten “Sehr geehrte(r) Torsten Meringer, herzlichen Glückwunsch! Wir freuen uns, Ihnen den Microsoft® MVP Award 2010 verleihen zu können!” begann. Ich freue mich natürlich riesig, für ein weiteres Jahr Teil der Community zu sein!

Diesmal etwas Werbung in eigener Sache. Seit kurzem habe ich einen weiteren Blog gestartet, der sich mit der Folgeversion von ConfigMgr (“v. Next”) befasst und unter www.vNext.de zu finden ist.

Es gibt ein neues Configuration Pack für ConfigMgr, diesmal für Exchange 2007: “Microsoft Exchange 2007 Operational Configuration Pack”. Download hier.

Das Warten hat ein Ende: Beta1 von vNext (der Folgeversion von ConfigMgr) steht auf connect zum Download zu Verfügung!

Kürzlich kam in einem Forum die Frage auf, ob es denn möglich sei, den WDS-Server (der gleichzeitig auch PXE-Servicepoint ist) weiterhin verwenden zu können, um alternative Boot-Images per PXE auszuliefern. Hintergrund war die Idee, den ERD Commander (Microsoft Diagnostics and Recovery Toolset (DaRT)) aus dem Microsoft Desktop Optimization Pack (MDOP) ebenfalls per PXE zu Verfügung zu stellen.

 Klar ist dieses Szenario umsetzbar. Dazu erst einmal zu den Vorarbeiten seitens DaRT. Nach dessen Installation findet sich im Startmenü ein Wizard namens “ERD Commander Boot Media Wizard”, mit dessen Hilfe eine bootfähige .iso-Datei erstellt werden kann.

Diese könnte man auf CD brennen und zu jeden defekten Rechner laufen, um eine Reparatur zu starten. Das hat dann aber noch wenig mit PXE-Boot zu tun. Im Gegensatz zum RIS-Server (dem Vorgänger des WDS) kann ein WDS-Server (zumindest im WDS native mode) mit .iso-Files nichts anfangen. Öffnet man allerdings das .iso-File so stellt man fest, dass im Ordner \Sources eine Datei namens boot.wim vorhanden ist. Bingo. Dieses .wim kann nun dem WDS-Server als neues Bootimage hinzugefügt werden:

Welche Situation liegt jetzt also vor? Auf dem WDS-Server gibt es ein Bootimage des ERD Commanders und gleichzeitig ist dieser WDS-Server auch PXE-Servicepoint.

Was hilft uns das bei unserem Problem? Dazu sollte man wissen, dass ein PXE-Servicepoint nichts weiter ist als ein Provider, der auf dem WDS aufsetzt:

PXE-Requests werden von diesem entgegengenommen und je nach Situation (gibt es die MAC-Adresse in der SCCM-Datenbank, gibt es ein Advertisement, ist dies optional oder mandatory etc.) beantwortet. Mögliche Szenarien wurden ja bereits hier aufgezeichnet: http://www.mssccmfaq.de/2010/04/08/pxe-boot-szenarien/.
Kann dieser Provider die Anfrage nicht beantworten (also weder ein Boot-Image noch ein abortpxe ausliefern), dann reicht dieser Provider die Anfrage einfach zum nächsten Provider weiter. Im Standard-Fall ist es dann der normale WDS-Server.

Je nach Konfiguration des WDS-Servers wird man dann zum Drücken von F12 aufgefordert

Und schon bootet der Client den ERD-Commander per PXE: