Torsten's Blog

Auf connect wurde ein “Refresh” von SCCM 2007 R3 Beta zu Verfügung gestellt:

Das ConfigMgr Toolkit gibt es jetzt in einer V2-Version: http://www.microsoft.com/downloads/details.aspx?FamilyID=5a47b972-95d2-46b1-ab14-5d0cbce54eb8&displaylang=en.

Neu dazu gekommen sind folgende Tools, die bereits aus dem SMS 2003 Toolkit 2 bekannt sind: sendsched, delgrp, MP Troubleshooter.

Die Beta-Version von R3 war ja ruck-zuck installiert, nur wo sind denn die schönen Reports?

Gar nicht einfach zu finden … Im Installationsverzeichnis von ConfigMgr gibt es im Unterordner \Reports\Power Management eine Datei names MicrosoftReportPack.cab. Doch wie importiert man diese? Der “Trick” hierbei ist der “Copy Reports Wizard”:

Damit kann dann ein .cab-File importiert werden:

Vor kurzen habe ich ja über die Verfügbarkeit von ConfigMgr 2007 R3 (Beta) berichtet.

Hier ein grober Überblick über die Neuerungen, die mit R3 kommen:

Der Beta-Download von R3 über connect lässt sich übrigens nur auf Trial-Versionen von ConfigMgr installieren.

Power Management: hier besteht die Möglichkeit, clientseitige Powermanagement-Einstellungen mittels ConfigMgr vorzunehmen. Dazu muss auf den SCCM-Clients ein Hotfix installiert werden: kb977384, der dem R3-Setup als Beta-Version beiliegt. Die R3-Setup-Routine bietet hier die Möglichkeit, das dazu nötige Package und Program automatisch erstellen zu lassen.

 OSD Verbesserungen: Pre-Stage von Bootimages und .wim-Dateien

Dynamic Collection Evaluation: schnelleres Aktualisieren der Mitgliedschaft von Collections. Dies gilt allerdings nur für

• neu ermittelte Resourcen
• OSD
• erstmalige Hardware-Inventur
• aktualisierte ConfigMgr Client-Versionen

und ersetzt den normalen Collection-Update-Zyklus nicht.

Active Directory Delta Discovery: ermittelt nur neue oder veränderte Resourcen (Computer, User, Security Groups, System Group)

Collections: hier gibt es einen Wizard, mit dem man einfach Mitglieder zu bestehenden Collections hinzufügen kann:

Performance: R3 unterstützt bis zu 300.000 Clients (bisher: “nur” 200.000)

Die Kooperation von Microsoft und Citrix bringt jetzt auch ConfigMgr und XenApp zusammen. Ab Juni 2010 soll es den “XenApp Connector for System Center Configuration Manager 2007″ geben. Weiterführende Informationen unter http://community.citrix.com/pages/viewpage.action?pageId=137954239.

Über den R3 Release von ConfigMgr habe ich ja bereits hier und hier geschrieben. Jetzt ist endlich die Beta1 auf connect verfügbar.

… dann können Sekunden wertvoll sein.

Was hat das mit ConfigMgr zu tun? Wer hat sich – nicht nur bei Tests - über folgendes Hinweisfenster während einer Betriebssystemverteilung (OSD) geärgert?

Bis das Betriebssystem fertig einsatzbereit sind können diese Countdowns einige Male auftauchen und die Gesamtzeit der Tasksequent unnötig verlängern. Doch es gibt eine Lösung – und die ist nicht einmal kompliziert.
Man muss nur die Tasksequenz-Variable SMSTSRebootDelay auf einen kleinen Wert setzen und schon ist der Countdown von 30s auf 1s reduziert:

Bei der Betriebssystemverteilung (OS Deployment / OSD) mit SCCM besteht die Möglichkeit, Clients per PXE zu booten. Zu diesem Zweck kommt ein PXE Servicepoint zum Einsatz, der auf einem WDS (Windows Deployment Service) Server aufsetzt.

Wie sieht dieser Boot-Prozeß nun clientseitig aus? Hier muss nach diversen Szenarien unterschieden werden.

Befinden sich die Clients in einem vom PXE-Server separatem Subnetz, so müssen die DHCP-Optionen 66 (Boot Server Host Name) und 67 (Bootfile Name; normalerweise SMSboot\x86\wdsnbp.com) zum Einsatz kommen:

Szenario 1: MAC-Adresse nicht in ConfigMgr bekannt (“unknown computer support” von SCCM 2007 R2 nicht aktiviert)

smspxe.log:

Executing LookupDevice(9045B3ED-4413-48C5-AFCE-B59A4136C9C6, 00:15:5D:B2:16:16) 
CDatabaseProxy :: LookupDevice succeeded: 0 0 0 0 
MAC=00:15:5D:B2:16:16 SMBIOS GUID=9045B3ED-4413-48C5-AFCE-B59A4136C9C6 > Device not found in the database.

 Der Rechner ist also nicht bekannt; entsprechend erfolgt auch keine Antwort vom PXE-Server (“No response from Windows Deployment Services server”). Wird an dieser Stelle kein F12 gedrückt, so bootet der Rechner ganz normal weiter (je nach Einstellung der Boot-Reihenfolge im BIOS).

Szenario 2: MAC-Adresse in ConfigMgr bekannt, aber Rechner befindet sich in keiner Collection (Sammlung), auf die es ein OS-Tasksequence-Advertisement (Ankündigung) gibt

smspxe.log:

Executing LookupDevice(9045B3ED-4413-48C5-AFCE-B59A4136C9C6, 00:15:5D:B2:16:16)
CDatabaseProxy :: LookupDevice succeeded: 0 0 114 1 [Anmerkung: "114" steht für die ResourceID, die für diese MAC-Adresse gefunden worden ist]
MAC=00:15:5D:B2:16:16 SMBIOS GUID=9045B3ED-4413-48C5-AFCE-B59A4136C9C6 > Device found in the database. MacCount=1 GuidCount=0
Executing GetBootAction(114, SCCM-SRV-2)
No Boot Action for Device (114) found
ProcessDatabaseReply: No Advertisement found in Db for device

Der Client erhält in diesen Fall ein abortpxe.com vom PXE-Server und bootet dann je nach Einstellungen im BIOS in der Bootreihenfolge weiter.

Szenario 3: MAC-Adresse in ConfigMgr bekannt; Rechner befindet sich in einer Collection (Sammlung), auf die es ein optionales OS-Tasksequence-Advertisement (Ankündigung) gibt

smspxe.log:

Executing GetBootAction(115, SCCM-SRV-2)
vLastPXEAdvertisementID is NULL
vLastPXEAdvertisementTime is NULL
GetBootAction: MAC:00:15:5D:B2:16:16 SMBIOS: SMSID:GUID:37FD4335-F4B7-47D0-9D8F-3779CF22F607 LastAdv:
Advertisement results: OfferId:TF22001E OfferTime:31/03/2010 22:48:00 PackageID:TF200055 BootImageID:TF200001 PackageVer: PackagePath:\\SCCM-SRV-2\SMSPXEIMAGES$\SMSPKG\TF200001\ Mandatory:0
ProcessDatabaseReply: Found optional advertisement(s): TF22001E
WARNING: _SMSTSSiteSigningCertificate Not Set. This might cause client failures in native mode.
WARNING: _SMSTSRootCACerts Not Set. This might cause client failures in native mode.
WARNING: _SMSTSCertStoreName Not Set. This might cause client failures in native mode.
WARNING: _SMSTSCertSelection Not Set. This might cause client failures in native mode.
Saving Media Variables to “C:\RemoteInstall\SMSTemp\2010.04.08.10.27.08.0014.{43245BDE-54C7-4226-8DE9-9137E81E6E31}.boot.var”

Es gibt ein optionales Advertisement. Der PXE-Server fordert deshalb zum Drücken von F12 auf (pxeboot.com). Wird F12 gedrückt, so startet Windows PE. Wird kein F12 gedrückt, so bootet der Rechner zum nächsten Device in der Bootreihenfolge.

Szenario 4: MAC-Adresse in ConfigMgr bekannt; Rechner befindet sich in einer Collection (Sammlung), auf die es ein mandatory OS-Tasksequence-Advertisement (Ankündigung) gibt, welches noch nicht ausgeführt worden ist

smspxe.log:

Executing GetBootAction(115, SCCM-SRV-2)
vLastPXEAdvertisementID is NULL
vLastPXEAdvertisementTime is NULL
GetBootAction: MAC:00:15:5D:B2:16:16 SMBIOS:9045B3ED-4413-48C5-AFCE-B59A4136C9C6 SMSID:GUID:37FD4335-F4B7-47D0-9D8F-3779CF22F607 LastAdv:
Advertisement results: OfferId:TF22001E OfferTime:31/03/2010 22:48:00 PackageID:TF200055 BootImageID:TF200001 PackageVer: PackagePath:\\SCCM-SRV-2\SMSPXEIMAGES$\SMSPKG\TF200001\ Mandatory:1
ProcessDatabaseReply: Device has not executed this advertisement: LastAdvDB: New:TF22001E

Es gibt ein mandatory Advertisement. Der PXE-Server liefert ein pxeboot.n12 aus, welches den Client direkt in das Windows PE booten lässt.

Szenario 5: MAC-Adresse in ConfigMgr bekannt; Rechner befindet sich in einer Collection (Sammlung), auf die es ein mandatory OS-Tasksequence-Advertisement (Ankündigung) gibt, welches bereits ausgeführt worden ist

smspxe.log:

Executing GetBootAction(115, SCCM-SRV-2)
vLastPXEAdvertisementTime: 08/04/2010 18:00:29
GetBootAction: MAC:00:15:5D:B2:16:16 SMBIOS:9045B3ED-4413-48C5-AFCE-B59A4136C9C6 SMSID:GUID:37FD4335-F4B7-47D0-9D8F-3779CF22F607 LastAdv:TF22001E
Advertisement results: OfferId:TF22001E OfferTime:31/03/2010 22:48:00 PackageID:TF200055 BootImageID:TF200001 PackageVer: PackagePath:\\SCCM-SRV-2\SMSPXEIMAGES$\SMSPKG\TF200001\ Mandatory:1
ProcessDatabaseReply: Device has executed this advertisement: CachedAdv:TF22001E

Der Client hat das mandatory Advertisement bereits ausgeführt, der PXE-Server liefert ein abortpxe.com aus, so dass der Client zum nächsten Device in der Bootreihenfolge geht.

Das SharePoint-Dashboard für ConfigMgr ist ab sofort unter http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=27fe0d80-38c6-464a-953a-1c2edcf35c2d verfügbar. Weitere Details inkl. einem Screenshot findet man hier: http://technet.microsoft.com/en-us/library/ff369719.aspx

 UPDATE: und schon ist ein Hotfix von Microsoft verfügbar: http://support.microsoft.com/kb/978757/en-us

Mit Service Pack 2 für ConfigMgr kann es unter gewissen Umständen beim Discovery zu einem Fehlverhalten kommen.

Welche Voraussetzung muss gegeben sein, damit dieser Fehler auftritt?

Gegeben sei folgende OU-Struktur im Active Directory:

Und AD System oder AD System Group Discovery mit folgender Konfiguration:

An dieser Stelle funktioniert das Discovery noch ohne Schwierigkeiten. OU1, OU2 und OU3 werden wie gewohnt in das Discovery einbezogen, was auch am korrespondierenden Logfile ersichtlich ist:

SMS_EXECUTIVE started SMS_AD_SYSTEM_DISCOVERY_AGENT as thread ID 3324 (0xCFC). SMS_AD_SYSTEM_DISCOVERY_AGENT 01.01.1601 00:00:00 2316 (0x090C)
** Service Thread is starting ** SMS_AD_SYSTEM_DISCOVERY_AGENT 01.01.1601 00:00:00 3324 (0x0CFC)
INFO: Component setting of ACTIVE was specified in the site control file. SMS_AD_SYSTEM_DISCOVERY_AGENT 01.01.1601 00:00:00 3324 (0x0CFC)
INFO: Removing redundant containers and validating them… SMS_AD_SYSTEM_DISCOVERY_AGENT 01.01.1601 00:00:00 3324 (0x0CFC)
The Run Count value in the site control file is 4. SMS_AD_SYSTEM_DISCOVERY_AGENT 01.01.1601 00:00:00 3324 (0x0CFC)
The Schedule token value in the site control file is 0001170000500008. SMS_AD_SYSTEM_DISCOVERY_AGENT 01.01.1601 00:00:00 3324 (0x0CFC)
Incremental synchronization is disabled. SMS_AD_SYSTEM_DISCOVERY_AGENT 01.01.1601 00:00:00 3324 (0x0CFC)
Optional attributes count = 0 SMS_AD_SYSTEM_DISCOVERY_AGENT 01.01.1601 00:00:00 3324 (0x0CFC)
!!!!Valid AD container 0: LDAP://OU=OU01,DC=MSSCCMFAQ,DC=TLD SMS_AD_SYSTEM_DISCOVERY_AGENT 01.01.1601 00:00:00 3324 (0x0CFC)
!!!!Valid AD container 1: LDAP://OU=OU02,DC=MSSCCMFAQ,DC=TLD SMS_AD_SYSTEM_DISCOVERY_AGENT 01.01.1601 00:00:00 3324 (0x0CFC)
!!!!Valid AD container 2: LDAP://OU=OU03,DC=MSSCCMFAQ,DC=TLD SMS_AD_SYSTEM_DISCOVERY_AGENT 01.01.1601 00:00:00 3324 (0x0CFC)
Starting the data discovery. SMS_AD_SYSTEM_DISCOVERY_AGENT 01.01.1601 00:00:00 3324 (0x0CFC)

Jetzt fügt man zusätzlich die OU “OU” (also eine OU, der Namen ähnlich den anderen ist) dem Discovery hinzu:

Was passiert? Es wird nur noch die OU “OU” in das Discovery einbezogen, die restlichen (OU01, OU02 und OU03)  ignoriert:

** Service Thread is starting ** SMS_AD_SYSTEM_DISCOVERY_AGENT 01.01.1601 00:00:00 936 (0x03A8)
INFO: Component setting of ACTIVE was specified in the site control file. SMS_AD_SYSTEM_DISCOVERY_AGENT 01.01.1601 00:00:00 936 (0x03A8)
INFO: Removing redundant containers and validating them… SMS_AD_SYSTEM_DISCOVERY_AGENT 01.01.1601 00:00:00 936 (0x03A8)
The Run Count value in the site control file is 6. SMS_AD_SYSTEM_DISCOVERY_AGENT 01.01.1601 00:00:00 936 (0x03A8)
The Schedule token value in the site control file is 0001170000500008. SMS_AD_SYSTEM_DISCOVERY_AGENT 01.01.1601 00:00:00 936 (0x03A8)
Incremental synchronization is disabled. SMS_AD_SYSTEM_DISCOVERY_AGENT 01.01.1601 00:00:00 936 (0x03A8)
Optional attributes count = 0 SMS_AD_SYSTEM_DISCOVERY_AGENT 01.01.1601 00:00:00 936 (0x03A8)
!!!!Valid AD container 0: LDAP://OU=OU,DC=MSSCCMFAQ,DC=TLD SMS_AD_SYSTEM_DISCOVERY_AGENT 01.01.1601 00:00:00 936 (0x03A8)
Starting the data discovery. SMS_AD_SYSTEM_DISCOVERY_AGENT 01.01.1601 00:00:00 936 (0x03A8)

Gleichzeitig wird eine Status Message erzeugt:
Status Message ID: 5204
Component: SMS_AD_SYSTEM_DISCOVERY_AGENT
Description: SMS Active Directory System Group Discovery failed to bind to container. Error: The parameter is incorrect.
Possible cause: The AD container specified earlier might be invalid now. The Domain Controller is inaccessible.

Workaround: Verschieben der OUs unter eine neue Toplevel-OU, da das Verhalten wohl nur auftritt, wenn ähnliche Toplevel OUs in das Discovery einbezogen sind:

SMS_EXECUTIVE started SMS_AD_SYSTEM_DISCOVERY_AGENT as thread ID 1576 (0×628). SMS_AD_SYSTEM_DISCOVERY_AGENT 01.01.1601 00:00:00 2316 (0x090C)
** Service Thread is starting ** SMS_AD_SYSTEM_DISCOVERY_AGENT 01.01.1601 00:00:00 1576 (0×0628)
INFO: Component setting of ACTIVE was specified in the site control file. SMS_AD_SYSTEM_DISCOVERY_AGENT 01.01.1601 00:00:00 1576 (0×0628)
INFO: Removing redundant containers and validating them… SMS_AD_SYSTEM_DISCOVERY_AGENT 01.01.1601 00:00:00 1576 (0×0628)
The Run Count value in the site control file is 7. SMS_AD_SYSTEM_DISCOVERY_AGENT 01.01.1601 00:00:00 1576 (0×0628)
The Schedule token value in the site control file is 0001170000500008. SMS_AD_SYSTEM_DISCOVERY_AGENT 01.01.1601 00:00:00 1576 (0×0628)
Incremental synchronization is disabled. SMS_AD_SYSTEM_DISCOVERY_AGENT 01.01.1601 00:00:00 1576 (0×0628)
Optional attributes count = 0 SMS_AD_SYSTEM_DISCOVERY_AGENT 01.01.1601 00:00:00 1576 (0×0628)
!!!!Valid AD container 0: LDAP://OU=OU,OU=TESTOU,DC=MSSCCMFAQ,DC=TLD SMS_AD_SYSTEM_DISCOVERY_AGENT 01.01.1601 00:00:00 1576 (0×0628)
!!!!Valid AD container 1: LDAP://OU=OU01,OU=TESTOU,DC=MSSCCMFAQ,DC=TLD SMS_AD_SYSTEM_DISCOVERY_AGENT 01.01.1601 00:00:00 1576 (0×0628)
!!!!Valid AD container 2: LDAP://OU=OU02,OU=TESTOU,DC=MSSCCMFAQ,DC=TLD SMS_AD_SYSTEM_DISCOVERY_AGENT 01.01.1601 00:00:00 1576 (0×0628)
!!!!Valid AD container 3: LDAP://OU=OU03,OU=TESTOU,DC=MSSCCMFAQ,DC=TLD SMS_AD_SYSTEM_DISCOVERY_AGENT 01.01.1601 00:00:00 1576 (0×0628)
Starting the data discovery. SMS_AD_SYSTEM_DISCOVERY_AGENT 01.01.1601 00:00:00 1576 (0×0628)