SCCM Verständnisfrage bzw. Vorgehensweise
André Heublein
in einem Rollout sollen mehrere 100 Clients mit XP versorgt und verschiedene
Applikationen installiert werden.
Nun ist es so, dass ich bereits ein Image besitze, in dem alle Einstellungen
etc. vorgenommen wurden, das ganze ge-sysprep-t ist und aus dem Image heraus
wird der Computer korrekt benannt, in die Domäne aufgenommen und zum Schluß
der CCM Client installiert.
Die Methode mit: der SCCM rollt das Image aus und macht in einem Rutsch den
Rest war wohl zu einfach für die Entscheider; somit werden die Clients mit
dem obigen Image vorbetankt und, so meine Idee, die melden sich anschließend
beim SCCM, bekommen eine TaskSequence und die macht den Rest (Treiber, BIOS,
weitere Applikationen...)
Hierzu habe ich eine neue Collection erstellt, dieser die obige Task
Sequence zugewiesen und per "Computer Association/Import Computers using a
file" meine Liste mit den Namen/MAC Adressen der Computer importiert.
Jetzt hätte ich erwartet, dass die Computer, die dort in der Collection drin
sind, die TaskSequence beim Kontakt mit dem SCCM ausführen.
Leider ist dem jedoch nicht so; der Client wird durch einen Network
Discovery/DHCP Server Scan erkannt (als weiteres System mit gleichem Namen)
und die Collection AllSystems geschoben. (Logisch: Durch den CCM Client
bekommt dieser eine eindeutige ID und unterscheidet sich somit vom den
händisch angelegten Client)
Somit habe ich nun 2 Clients mit dem gleichen Namen (was ja nicht das
Problem ist, ich kann mit ja eine Collection bauen und nach NoClient
Filtern; jedoch bekomme ich da ev. auch Clients, die in der Rollout Liste
garnicht vorgesehen sind, und das wäre unschön.
Somit ist meine Frage: Wie kann ich die obige Aufgabenstellung korrekt
umsetzen? Wenn ich manuell einen Client im CCM angelege, wie kann ich
sicherstellen, dass dieser nicht doppelt erkannt wird?
André
Torsten [MVP]
wieso denn einen "manual machine entry" erstellen, wenn die Rechner sowieso
schon per Discovery ermittelt worden sind? Erstelle doch einfach eine
Collection, die die (per Discovery ermittelten) Rechner enth�lt.
Gru�,
Torsten
"Andr� Heublein" <andre.heublein.@t-online.de> schrieb im Newsbeitrag
news:uCh247#zKHA...@TK2MSFTNGP05.phx.gbl...
> Hallo,
>
> in einem Rollout sollen mehrere 100 Clients mit XP versorgt und
> verschiedene Applikationen installiert werden.
> Nun ist es so, dass ich bereits ein Image besitze, in dem alle
> Einstellungen etc. vorgenommen wurden, das ganze ge-sysprep-t ist und aus
> dem Image heraus wird der Computer korrekt benannt, in die Dom�ne
> aufgenommen und zum Schlu� der CCM Client installiert.
>
> Die Methode mit: der SCCM rollt das Image aus und macht in einem Rutsch
> den Rest war wohl zu einfach f�r die Entscheider; somit werden die Clients
> mit dem obigen Image vorbetankt und, so meine Idee, die melden sich
> anschlie�end beim SCCM, bekommen eine TaskSequence und die macht den Rest
> (Treiber, BIOS, weitere Applikationen...)
>
> Hierzu habe ich eine neue Collection erstellt, dieser die obige Task
> Sequence zugewiesen und per "Computer Association/Import Computers using a
> file" meine Liste mit den Namen/MAC Adressen der Computer importiert.
> Jetzt h�tte ich erwartet, dass die Computer, die dort in der Collection
> drin sind, die TaskSequence beim Kontakt mit dem SCCM ausf�hren.
>
> Leider ist dem jedoch nicht so; der Client wird durch einen Network
> Discovery/DHCP Server Scan erkannt (als weiteres System mit gleichem
> Namen) und die Collection AllSystems geschoben. (Logisch: Durch den CCM
> Client bekommt dieser eine eindeutige ID und unterscheidet sich somit vom
> den h�ndisch angelegten Client)
> Somit habe ich nun 2 Clients mit dem gleichen Namen (was ja nicht das
> Problem ist, ich kann mit ja eine Collection bauen und nach NoClient
> Filtern; jedoch bekomme ich da ev. auch Clients, die in der Rollout Liste
> garnicht vorgesehen sind, und das w�re unsch�n.
>
> Somit ist meine Frage: Wie kann ich die obige Aufgabenstellung korrekt
> umsetzen? Wenn ich manuell einen Client im CCM angelege, wie kann ich
> sicherstellen, dass dieser nicht doppelt erkannt wird?
>
> Andr�
>
>
Andr� Heublein
> wieso denn einen "manual machine entry" erstellen, wenn die Rechner
> sowieso schon per Discovery ermittelt worden sind? Erstelle doch einfach
> eine Collection, die die (per Discovery ermittelten) Rechner enth�lt.
das "Problem" ist folgendes:
Ich habe ein Image, dass verschiedene Dinge macht (Computer umbenennen, in
Dom�ne aufnehmen), bevor der CCM Client installiert wird und dieser per an
eine bestimmte Sammlung angebundene Tasksequence den Rest durchf�hrt
(Treiber, BIOS, verschiedene weitere Apps)
Es sollen nur bestimmte PC diese Task Sequence erhalten.
Somit habe ich die PC�s, von denen ich eine csv Datei mit MAC und Namen
habe, imporiert, der einen Sammlung zugewiesen und dort sollte nun die
Tasksequence den Rest erledigen. So hatte ich es mir zumindest vorgestellt.
Was ich erreichen soll: Die PC�s kommen hier vorbetankt an, werden gestartet
und zeitnah, nachdem das Image mit seinem Minisetup fertig ist, soll die
Tasksequence den Rest machen, so dass der PC fertig wird und ausgeliefert
werden kann.
Das Discovery sollte einige Zeitr�ume nicht unterschreiten, ich glaube, ich
hab 1Tag f�r AD Discovery gelesen. Dies klingt jedoch nicht zeinah.
Deshalb der Entschlu�, die Sammlung manuell zu bef�llen.
Die Frage ist: Weshalb macht der SCCM keinen Push auf die dort hinterlegten
Rechner, dies erscheinen doch als Assigned, also die Voraussetzung f�r
Push.
Andr�
Torsten [MVP]
siehe im Text:
"André Heublein" <andre.heublein.@t-online.de> schrieb im Newsbeitrag
news:u0FAS4C0...@TK2MSFTNGP02.phx.gbl...
>
> Es sollen nur bestimmte PC diese Task Sequence erhalten.
>
> Somit habe ich die PC´s, von denen ich eine csv Datei mit MAC und Namen
> habe, imporiert, der einen Sammlung zugewiesen und dort sollte nun die
> Tasksequence den Rest erledigen. So hatte ich es mir zumindest
> vorgestellt.
also hast Du schon Rechnernamen, mit denen etwas passieren soll. Also kannst
Du eine Collection anhand der Rechnernamen erstellen (auch wenn die Rechner
zu diesem Zeitpunkt noch gar nicht in SCCM vorhanden sind).
> Was ich erreichen soll: Die PC´s kommen hier vorbetankt an, werden
> gestartet und zeitnah, nachdem das Image mit seinem Minisetup fertig ist,
> soll die Tasksequence den Rest machen, so dass der PC fertig wird und
> ausgeliefert werden kann.
Ist der Client denn schon im Image enthalten? Ich denke nicht, wenn ich das
mit dem Push weiter unten lese ... Wieso ist der denn nicht mit im Image
enthalten?
> Das Discovery sollte einige Zeiträume nicht unterschreiten, ich glaube,
> ich hab 1Tag für AD Discovery gelesen. Dies klingt jedoch nicht zeinah.
> Deshalb der Entschluß, die Sammlung manuell zu befüllen.
Das kommt auf die Größe der Umgebung an.
> Die Frage ist: Weshalb macht der SCCM keinen Push auf die dort
> hinterlegten Rechner, dies erscheinen doch als Assigned, also die
> Voraussetzung für Push.
Push passiert hauptsächlich nur, wenn die Clients durch eine Discovery
Method ermittelt worden sind (noch keine Clients sind) und der automatische
Push aktiviert ist.
Das Problem hier ist, dass es meiner Meinung nach kein Standard-Szenario ist
und man deshalb insgesamt nicht sehr viel dazu sagen kann.
Wieso wird denn zB "dem Image heraus wird der Computer korrekt benannt, in
die Domäne aufgenommen und zum Schluß der CCM Client installiert"? Wieso
keine Standard-ConfigMgr-Tasksequence, die das macht? Ist also der Client im
Image oder nicht? Discovery + Push => Zeitverzögerung.
Also irgendwie klingt's für mich in Summe so, als könnte man an dem ganzen
Prozeß noch das eine oder andere optimieren ;-)
> André
Gruß,
Torsten
André Heublein
> also hast Du schon Rechnernamen, mit denen etwas passieren soll. Also
> kannst Du eine Collection anhand der Rechnernamen erstellen (auch wenn die
> Rechner zu diesem Zeitpunkt noch gar nicht in SCCM vorhanden sind).
Das hab ich ja gemacht. Eine Collection erstellt und per mport die Rechner
in diese Collection importiert.
> Ist der Client denn schon im Image enthalten? Ich denke nicht, wenn ich
> das mit dem Push weiter unten lese ... Wieso ist der denn nicht mit im
> Image enthalten?
Nein, dass war zwar mein ursprünglicher Plan (das enthalten sein bzw. die
Installation nach dem Minisetup), jedoch bekomme ich dann 2 Systeme im SCCM;
einmal die manuell importierten und einmal den, der durch eine Discovery als
CCM Client erkannt wurde.
Deshalb bin ich dazu übergegangen, den Client da rauszunehmen, so dass der
CCM die manuell importierten Clients diese per Push betankt.
> Push passiert hauptsächlich nur, wenn die Clients durch eine Discovery
> Method ermittelt worden sind (noch keine Clients sind) und der
> automatische Push aktiviert ist.
>
> Das Problem hier ist, dass es meiner Meinung nach kein Standard-Szenario
> ist und man deshalb insgesamt nicht sehr viel dazu sagen kann.
OK, wenn mir jedoch das Programm die Mgl bietet (ja, ich weiss, nur, nur
weil mein Auto die Mgl bietet, im 1. Gang 40kmh zu fahren, sollte ich es
nicht tun...) und ich (meiner Meinung nach) mit dem manuellen Import das
gleiche erreiche, als wenn die Clients discoverd in einer Collection stehen,
verstehe ich grad nicht, weshalb dies nicht so funktionieren soll.
Die dort importierten Clients werden zb. durch eine komplette OSD Task
Sequence inkl PXE_Boot und Image Rollout ohne Probleme erkannt und
verarbeitet.
> Wieso wird denn zB "dem Image heraus wird der Computer korrekt benannt, in
> die Domäne aufgenommen und zum Schluß der CCM Client installiert"? Wieso
> keine Standard-ConfigMgr-Tasksequence, die das macht? Ist also der Client
> im Image oder nicht?
Ja, ist ein Image, jedoch wurde durch das Management entschieden, dass die
Clients durch einen Dienstleister vorbetankt werden mit einem Image inkl
Applikationen und den Rest, nachdem der Client hier im Haus hochgefahren
ist, soll der SCCM machen (das war dann mein Plan, nachdem ich den ersten
Teil so fest vorgegeben bekommen habe).
Leider muss ich den OSD Task nun aufdrösseln, das Image kann nicht durch den
SCCM bereit gestellt werden, also kein PXE Boot inkl des Aufrufs der
Tasksequence + Imageaufspielung inkl der Anpassung der sysprep-Einstellungen
für das Minisetup durch die Tasksequence... etc
Discovery + Push => Zeitverzögerung.
> Also irgendwie klingt's für mich in Summe so, als könnte man an dem ganzen
> Prozeß noch das eine oder andere optimieren ;-)
Mit der Zeitverzögerung kann mein Chef mittlerweile leben.
Ja, gerne nehme ich Optimierungen an, nur kann ich in den 1.Teil nicht
eingreifen, muss also mit dem vorgefertigten Image leben, also mit einem
vorbetankten Client.
André
Torsten [MVP]
nochmal im Text ...
"André Heublein" <andre.heublein.@t-online.de> schrieb im Newsbeitrag
news:uUDqvQK...@TK2MSFTNGP04.phx.gbl...
>
> Das hab ich ja gemacht. Eine Collection erstellt und per mport die Rechner
> in diese Collection importiert.
Ich dachte, die Einträge kommen per Network Discovery? Hab ich das falsch
verstanden?
> Mit der Zeitverzögerung kann mein Chef mittlerweile leben.
> Ja, gerne nehme ich Optimierungen an, nur kann ich in den 1.Teil nicht
> eingreifen, muss also mit dem vorgefertigten Image leben, also mit einem
> vorbetankten Client.
Ah ok. Wieso installierst Du dann den Client nicht per GPO? Dazu muss er
nicht in SCCM bekannt sein, damit das klappt. Sind denn damit nicht alle
Deine Probleme gelöst?
Gruß,
Torsten
Andr� Heublein
>> Das hab ich ja gemacht. Eine Collection erstellt und per mport die
>> Rechner in diese Collection importiert.
>
> Ich dachte, die Eintr�ge kommen per Network Discovery? Hab ich das falsch
> verstanden?
Als erstes habe ich die Clients manuell importiert, somit hatte ich gedacht,
ja, die sind assigned und werden durch die Pushinstallation mit den Client
vorsorgt.
Dem war jedoch nicht so.
Zwischenzeitlich ist ein Network Discovery gelaufen und ich hatte den
CCMClient manuell installiert, um zu schauen, wie ich es sonst machen kann,
dass die Clients in der richtigen Collection landen und die TaskSequence
ausf�hren.
Nun hatte ich 2 Systeme, den einen in der richtigen Collection, den anderen
eben noch nicht. Dieses Poblem habe ich nun nicht mehr, da ich den CCM
Client per Push installieren lasse, nachdem der Client per AD Discovery
entdeckt wurde.
>
>> Mit der Zeitverz�gerung kann mein Chef mittlerweile leben.
>> Ja, gerne nehme ich Optimierungen an, nur kann ich in den 1.Teil nicht
>> eingreifen, muss also mit dem vorgefertigten Image leben, also mit einem
>> vorbetankten Client.
>
> Ah ok. Wieso installierst Du dann den Client nicht per GPO? Dazu muss er
> nicht in SCCM bekannt sein, damit das klappt. Sind denn damit nicht alle
> Deine Probleme gel�st?
Aktuell ist es nun so:
Das Image machtr den Domain Join, im SCCM l�uft eine AD Discovery l�uft alle
30 Minuten (Dom�ne nicht nicht allzu gro� und die Abfrage auf OU�s
beschr�nkt), so dass ich den Client relativ zeitnah finde.
�ber einen Push wird der Client nun auch sauber installiert.
Nun habe ich die Collection erstellt, welche nun auch eine Abfrage nach
einem Reg-Wert enth�lt, um diese neuen Clients von den anderen zu
unterscheiden.
Hierzu habe ich die sms_dev sowie configuration.mof wie folgt erweitert:
configuration.mof:
#pragma namespace ("\\\\.\\root\\cimv2")
#pragma deleteclass("NewClientGeneration", NOFAIL)
[DYNPROPS]
Class NewClientGeneration
{
[key] string KeyName;
Uint32 Enable;
};
[DYNPROPS]
Instance of NewClientGeneration
{
keyname="WDNewClientGeneration";
[PropertyContext("Local|HKEY_LOCAL_MACHINE\\SOFTWARE\\MeineCompany\\NewClientGeneration\\YES|Enable"),Dynamic,Provider("RegPropProv")]
Enable;
};
sms_dev.mof:
#pragma namespace ("\\\\.\\root\\cimv2\\SMS")
#pragma deleteclass("NewClientGeneration", NOFAIL)
[SMS_Report(TRUE),SMS_Group_Name("NewClientGeneration"),SMS_Class_ID("CompanyClass|NewClientGeneration|1.0")]
Class NewClientGeneration: SMS_Class_Template
{
[SMS_Report(TRUE),key] string KeyName;
[SMS_Report(TRUE)] Uint32 Enable;
};
Der zugeh�rige Reg-Eintrag sieht wie folgt aus:
[HKEY_LOCAL_MACHINE\SOFTWARE\MeineCompany\NewClientGeneration\YES]
"Enable"=dword:00000001
Der Syntaxcheck lief sauber durch, die Tabelleneintr�ge wurde nach einem
Kompilieren und einem Hardwareinventory Scan eines neues Clients mit diesem
Reg-Wert in der Datenbank erstellt.
Gestern Abend aktualisierte ich die Collection, und siehe da, da war ein
Client in der Collection zu sehen
Doch nicht der, den ich erwartet h�tte, sondern einer, der diesen
Registrierungswert nicht hat (definitiv nicht, hab nochmals nachgeschaut)
Die Abfrage in der Collection sind wie folgt aus:
select
SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client
from SMS_R_System inner join
SMS_G_System_CompanyClass_NEWCLIENTGENERATION_1_0 on
SMS_G_System_CompanyClass_NEWCLIENTGENERATION_1_0.ResourceId =
SMS_R_System.ResourceId where
SMS_G_System_CompanyClass_NEWCLIENTGENERATION_1_0.KeyName is not null
Ich pr�fe also, ob die Schl�ssel nicht Null ist, also nicht existiert (so
mein Verst�ndnis)
Im Resourceexplorer f�r den eigentlich betroffenen Client sehe ich den neuen
Eintrag NewClientGeneraration, im nun in der neuen Collection liegenden
"falschen" Client, der den Reg-rag nicht hat, jedoch schon.
Nach einer Aktualisierung der Collection tauchen nun auch mehrere Clients
auf, die den Schl�ssel jedoch nicht haben.
Ich vermute, an meiner Abfrage ist etwas falsch, jedoch bin ich bisher noch
nicht dahinter gestiegen, wo denn mein (?) Fehler liegt.
Andr�
Torsten [MVP]
schau Dir mal http://www.mssccmfaq.de/2009/12/14/subselect-not-in-abfragen/
an. Du müsstest die Collection auf diese Weise (sinngemäß) erstellen.
Gruß,
Torsten
"André Heublein" wrote:
> Hi Torsten,
>
>
> >> Das hab ich ja gemacht. Eine Collection erstellt und per mport die
> >> Rechner in diese Collection importiert.
> >
> > Ich dachte, die Einträge kommen per Network Discovery? Hab ich das falsch
> > verstanden?
>
> Als erstes habe ich die Clients manuell importiert, somit hatte ich gedacht,
> ja, die sind assigned und werden durch die Pushinstallation mit den Client
> vorsorgt.
> Dem war jedoch nicht so.
> Zwischenzeitlich ist ein Network Discovery gelaufen und ich hatte den
> CCMClient manuell installiert, um zu schauen, wie ich es sonst machen kann,
> dass die Clients in der richtigen Collection landen und die TaskSequence
> ausführen.
>
> Nun hatte ich 2 Systeme, den einen in der richtigen Collection, den anderen
> eben noch nicht. Dieses Poblem habe ich nun nicht mehr, da ich den CCM
> Client per Push installieren lasse, nachdem der Client per AD Discovery
> entdeckt wurde.
>
> >
> >> Mit der Zeitverzögerung kann mein Chef mittlerweile leben.
> >> Ja, gerne nehme ich Optimierungen an, nur kann ich in den 1.Teil nicht
> >> eingreifen, muss also mit dem vorgefertigten Image leben, also mit einem
> >> vorbetankten Client.
> >
> > Ah ok. Wieso installierst Du dann den Client nicht per GPO? Dazu muss er
> > nicht in SCCM bekannt sein, damit das klappt. Sind denn damit nicht alle
> > Deine Probleme gelöst?
>
> Aktuell ist es nun so:
> Das Image machtr den Domain Join, im SCCM läuft eine AD Discovery läuft alle
> 30 Minuten (Domäne nicht nicht allzu groß und die Abfrage auf OU´s
> beschränkt), so dass ich den Client relativ zeitnah finde.
> Über einen Push wird der Client nun auch sauber installiert.
>
> Nun habe ich die Collection erstellt, welche nun auch eine Abfrage nach
> einem Reg-Wert enthält, um diese neuen Clients von den anderen zu
> unterscheiden.
> Hierzu habe ich die sms_dev sowie configuration.mof wie folgt erweitert:
>
> configuration.mof:
>
> #pragma namespace ("\\\\.\\root\\cimv2")
> #pragma deleteclass("NewClientGeneration", NOFAIL)
> [DYNPROPS]
> Class NewClientGeneration
> {
> [key] string KeyName;
> Uint32 Enable;
> };
> [DYNPROPS]
> Instance of NewClientGeneration
> {
> keyname="WDNewClientGeneration";
> [PropertyContext("Local|HKEY_LOCAL_MACHINE\\SOFTWARE\\MeineCompany\\NewClientGeneration\\YES|Enable"),Dynamic,Provider("RegPropProv")]
> Enable;
> };
>
>
>
> sms_dev.mof:
> #pragma namespace ("\\\\.\\root\\cimv2\\SMS")
> #pragma deleteclass("NewClientGeneration", NOFAIL)
> [SMS_Report(TRUE),SMS_Group_Name("NewClientGeneration"),SMS_Class_ID("CompanyClass|NewClientGeneration|1.0")]
> Class NewClientGeneration: SMS_Class_Template
> {
> [SMS_Report(TRUE),key] string KeyName;
> [SMS_Report(TRUE)] Uint32 Enable;
> };
>
>
>
> Der zugehörige Reg-Eintrag sieht wie folgt aus:
> [HKEY_LOCAL_MACHINE\SOFTWARE\MeineCompany\NewClientGeneration\YES]
> "Enable"=dword:00000001
>
>
> Der Syntaxcheck lief sauber durch, die Tabelleneinträge wurde nach einem
> Kompilieren und einem Hardwareinventory Scan eines neues Clients mit diesem
> Reg-Wert in der Datenbank erstellt.
> Gestern Abend aktualisierte ich die Collection, und siehe da, da war ein
> Client in der Collection zu sehen
>
> Doch nicht der, den ich erwartet hätte, sondern einer, der diesen
> Registrierungswert nicht hat (definitiv nicht, hab nochmals nachgeschaut)
>
> Die Abfrage in der Collection sind wie folgt aus:
>
> select
> SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client
> from SMS_R_System inner join
> SMS_G_System_CompanyClass_NEWCLIENTGENERATION_1_0 on
> SMS_G_System_CompanyClass_NEWCLIENTGENERATION_1_0.ResourceId =
> SMS_R_System.ResourceId where
> SMS_G_System_CompanyClass_NEWCLIENTGENERATION_1_0.KeyName is not null
>
>
> Ich prüfe also, ob die Schlüssel nicht Null ist, also nicht existiert (so
> mein Verständnis)
>
> Im Resourceexplorer für den eigentlich betroffenen Client sehe ich den neuen
> Eintrag NewClientGeneraration, im nun in der neuen Collection liegenden
> "falschen" Client, der den Reg-rag nicht hat, jedoch schon.
> Nach einer Aktualisierung der Collection tauchen nun auch mehrere Clients
> auf, die den Schlüssel jedoch nicht haben.
>
> Ich vermute, an meiner Abfrage ist etwas falsch, jedoch bin ich bisher noch
> nicht dahinter gestiegen, wo denn mein (?) Fehler liegt.
>
> André
>
>
>
>
> .
>
Andr� Heublein
> schau Dir mal
> http://www.mssccmfaq.de/2009/12/14/subselect-not-in-abfragen/
> an. Du m�sstest die Collection auf diese Weise (sinngem��) erstellen.
So, nach dem Studium des Artikels funktioniert es nun, wie ich erwartet
habe.
Dabke f�r die Hilfe!
Andr�