Betriebssystemverteilung mit SCCM 2007 SP2 per PXE Boot: Komme nicht weiter !

[neochrome 0]

Super Danke !
 

Hab mir jetzt auch ein Script erstellt um den WDS zu durchzustarten und die Bootfiles neu anzulegen. Komischerweise stimmen jetzt auch die Pfade im DHCP wieder (Macht mir bisschen Angst  :schreck: )

Leider legt der den Ordner im temp auch neu an und zwar hat der User "TrustedInstaller" die vollen Rechte und kann nur mit der Besitzübernahme da raus gekickt werden.

 

Dennoch jetzt folgende Zeile: Applying image 1 to volume C:\Windows\TEMP\PXEBootFiles smspxe 14.03.2014 14:27:51 2356 (0x0934)

Scheint also zu passen.

 

Bootet leider jedoch immer noch in den abortpxe  :mad:

bearbeitet 14. März 2014 von neochrome

[neochrome 0]

Closing image file E:\RemoteInstall\SMSImages\SMSPKG\APU00019\sources\install.wim smspxe 17.03.2014 10:21:11 4468 (0x1174)

Leider kommt der oben genannte Eintrag nach dem kopieren in den Temp hoch. Danach läuft der dann wieder in die abortpxe und zeigt im log wieder folgende Zeile an:
 

MAC=FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF SMBIOS GUID=46746E94-D140-497A-8C46-5463A8F006FD > Device not found in the database. smspxe 17.03.2014 10:21:43 4764 (0x129C)

 

 

Warum findet der das blöde Teil nicht ?

[TorstenM 20]

MAC=FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF SMBIOS GUID=46746E94-D140-497A-8C46-5463A8F006FD > Device not found in the database. smspxe 17.03.2014 10:21:43 4764 (0x129C)

 

 

Diese Zeilen kannst komplett ignorieren. Das sind nur die PXE-Checks, die der Server selbst durchführt.

[neochrome 0]

Ok, dann kann ich das auch ausschließen, Danke dir  :thumb1: 

:) 

Ich versteh immer noch nicht wieso der in den abortpxe springt ......

Danke und Gruß

neochrome

 

 

PS: Wenn sich jemand anderes auskennt oder eine Idee hat wär das nett wenn er sich melden könnte damit der arme Torsten hier nicht den Alleinunterhalter machen muss.  :p

bearbeitet 17. März 2014 von neochrome

[neochrome 0]

Wenn ich auf den Referenz Computer (über MAC hinzugefügt) gehe, und dann auf "Advertisements" wird mir meine TS angezeigt.

 

Will ich aber jetzt "Clear Last PXE Advertisement" machen bekomme ich die TS darunter überhaupt nicht mehr angezeigt. 

Kann es vielleicht daran liegen ? Muss ich bei dem Erstellen der Sammlung noch auf irgendetwas achten ? Ich hatte für den Build and Capture einfach eine Sammlung ohne jede Optionen oder regeln erstellt.

 

Gruß

neochrome

bearbeitet 19. März 2014 von neochrome

[TorstenM 20]

"Clear Last PXE ..." dient nur dazu, um "mandatory adverstisements" (also mit Deadline) zurückzusetzen. Wenn es nur optionale gibt, dann wird auch nichts angezeigt.

 

"Ich hatte für den Build and Capture einfach eine Sammlung ohne jede Optionen oder regeln erstellt" --> dann kann der Client doch gar kein Mitglied sein - es sei denn, Du hast den per Direct Membership hinzugefügt bzw per "Import Computer Information" (was dann ja ok ist).

[neochrome 0]

"Clear Last PXE ..." dient nur dazu, um "mandatory adverstisements" (also mit Deadline) zurückzusetzen. Wenn es nur optionale gibt, dann wird auch nichts angezeigt.

 

"Ich hatte für den Build and Capture einfach eine Sammlung ohne jede Optionen oder regeln erstellt" --> dann kann der Client doch gar kein Mitglied sein - es sei denn, Du hast den per Direct Membership hinzugefügt bzw per "Import Computer Information" (was dann ja ok ist).

Ja, per Import Computer Information !

 

OK, das mit der Deadline wusste ich nicht. Dachte das würde auch bei den anderen gehen. Was ich nach wie vor nicht verstehe ist die Tatsache das der immer direkt in den smsboot\x64\abortpxe.com läuft ! Warum überhaupt x64 ? Ich habe doch ein x86 verteilt ? Warum nimmt der nicht wenigstens die x86 abortpxe (gibts ja in dem Ordner auch). Oder hängt das damit zusammen das ich den SCCM auf nem x64 System laufen habe. Kann das Problem mit VMware zusammenhängen ? Bootet der immer die x64 weil 64bit Server und wählt dann aber die x86 TS ?

 

 

No Boot Action for Device (12) found smspxe 19.03.2014 10:57:15 2576 (0x0A10) Was bedeutet diese Zeile im smspxe.log ? Kann  man die auch ignorieren ?

Found Image file: E:\RemoteInstall\SMSImages\SMSPKG\APU00019\sources\install.wim

       PackageID: SMSPKG\APU00019\sources

     ProductName: Microsoft® Windows® Operating System

    Architecture: 0

     Description: Windows 7 ENTERPRISE

         Version:  

         Creator: 

       SystemDir: WINDOWS

smspxe 19.03.2014 09:52:31 224 (0x00E0)

 

Anscheinend erkennt der ja hier ein .wim File

 

 

Closing image file E:\RemoteInstall\SMSImages\SMSPKG\APU00019\sources\install.wim smspxe 19.03.2014 09:52:31 224 (0x00E0) 

 

Hier scheint er es wieder abzubrechen (Oder bin ich da auf dem falschen Dampfer ?)

 

Dann erscheint noch folgendes:

Mutex was not owned. Now have ownership. smspxe 19.03.2014 09:52:31 224 (0x00E0) Kein Plan was das ist hab ich auf die Schnelle nicht gescheites zu finden können.

Opening image file E:\RemoteInstall\SMSImages\SMSPKG\APU00019\sources\install.wim smspxe 19.03.2014 09:52:32 224 (0x00E0) Hier scheint er das wim file zu anzunehmen.

Applying image 1 to volume C:\Windows\TEMP\PXEBootFiles smspxe 19.03.2014 09:52:32 224 (0x00E0) Das kopieren in den temp scheint jetzt auch zu klappen.

Closing image file E:\RemoteInstall\SMSImages\SMSPKG\APU00019\sources\install.wim smspxe 19.03.2014 09:52:33 224 (0x00E0) Hier schließt er es wieder.

PXE Provider finished loading. smspxe 19.03.2014 09:52:33 224 (0x00E0) Vorgang abgeschlossen.

 

Eigentlich müsste ja dann in dem Temp Ordner was liegen. Der Ordner ist aber so leer wie die spanische Staatskasse.  :mad: 

 

Danach kommen dann wieder die "Device not found in the Database" Meldungen (du hattest ja gesagt die kann man ignorieren, von daher uninteressant)

 

Wenn ich die TS lösche und neu verteile, dann ist der temp Ordner wieder geblockt und kann nicht gerlöscht werden. Lasse ich dann wieder mein Script zum neustarten des WDS und zur Besitzübernahme auf C:\temp durchlaufen sieht das logfile wieder wie oben beschrieben aus.

 

Ich such mir hier jetzt schon seit 2 Wochen den Wolf und finde einfach den Fehler nicht. Arrrrrgh !

 

Nochmals vielen Dank das du dir bisher soviel Zeit genommen hast.

 

Gruß

neochrome

 

 

PS:

 

Unter RemoteInstall\SMSBoot\x64 liegt nur die Datei abortpxe. Unter x86 liegen jedoch die anderen Dateien (bootmgr, pxeboot,pxeboot.n12 und wdsnbp) auch noch. Selbst wenn man WDS und PXE neuinstalliert liegt unter x64 lediglich die abortpxe. Kann das eventuell daran liegen ?

 

 

 

 

bearbeitet 19. März 2014 von neochrome

[TorstenM 20]

"No Boot Action for Device (12) found " --> bedeutet, dass es für die anfragende MAC oder SMBIOS-GUID (= die Resource mit der ID 12) keine Tasksequenz gibt. Kontrolliere auf jeden Fall auch, dass sowohl das x86, als auch ein X64 Bootimage auf dem PXE Service Point vorhanden sind.

Verdächtig ist auch, das: "Unter RemoteInstall\SMSBoot\x64 liegt nur die Datei abortpxe" <-- dort sollten auch die anderen Files liegen. Siehe entsprechend mein Hinweis vorher.

 

"Found Image file" und "Closing image file" --> passiert beim Start vom WDS oder beim Aktualisieren / Hinzufügen von Bootimages. Hat für den normalen Betrieb eigentlich keine Bedeutung.

 

"Danach kommen dann wieder die "Device not found in the Database" Meldungen (du hattest ja gesagt die kann man ignorieren, von daher uninteressant)" --> ja, wenn es sich um die "FF:FF:FF..."-Anfragen handelt.

[neochrome 0]

"Kontrolliere auf jeden Fall auch, dass sowohl das x86, als auch ein X64 Bootimage auf dem PXE Service Point vorhanden sind."

Wie meinst du das ? Beim erstellen der TS kann man ja jeweils nur eins von beiden auswählen !

 

Oder meinst die du beiden WinPe's ? Die sind beide auf die Verteilungspunkte verteilt, das passt !

 

 

zum device not found :  MAC=00:0C:29:45:EB:87 SMBIOS GUID=3C4E4D56-8E4D-D9E6-642C-73628945EB87 > Device found in the database. MacCount=1 GuidCount=0 smspxe 21.03.2014 10:57:22 4168 (0x1048)

 

Sollte also da sein, das not found wird nur bei FFFF angezeigt.

 

Wie gesagt, das mit dem SMSboot x64 Ordner ist auch nach kompletter Neuinstallation des WDS und PXE immer noch so (nur die abortpxe).

 

 

Gruß

neochrome

Klappt !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!


Ich habe die beiden PE Images mal entfernt und nochmal neu hinzugefügt dann den WDS per Script neugestartet und der Spass läuft durch !!!!

Super, vielen Dank bis hierher für die Tipps und ein ganz großes Dankeschön an Torsten !!  :thumb1:  :thumb1:  :thumb1:  :thumb1:  :)  :)  :)

bearbeitet 21. März 2014 von neochrome

[TorstenM 20]

"Kontrolliere auf jeden Fall auch, dass sowohl das x86, als auch ein X64 Bootimage auf dem PXE Service Point vorhanden sind."

 

Wie meinst du das ? Beim erstellen der TS kann man ja jeweils nur eins von beiden auswählen !

 

Oder meinst die du beiden WinPe's ? Die sind beide auf die Verteilungspunkte verteilt, das passt !

 

 

zum device not found :  MAC=00:0C:29:45:EB:87 SMBIOS GUID=3C4E4D56-8E4D-D9E6-642C-73628945EB87 > Device found in the database. MacCount=1 GuidCount=0 smspxe 21.03.2014 10:57:22 4168 (0x1048)

 

WinPE gibt's ja als x86 und x64 Version. Beide müssen zwingend auf dem PXE-SP verteilt werden - unabhängig davon, welches PE die TS verwendet. Im smspxe.log solltest Du beim Start des WDS-Dienstes auch sehen, ob/dass beide PEs vorhanden sind.

Die MAC 00:0C:29:45:EB:87 findet er in der Datenbank. Später im Log taucht dann ja folgendes auf (auf Seite 2 dieses Threads zu finden).

 

<![LOG[Executing GetBootAction(12, SRVAP02)]LOG]!><time="12:25:22.918+-60" date="03-07-2014" component="smspxe" context="" type="0" thread="4808" file="database.cpp:519">

 

<![LOG[No Boot Action for Device (12) found]LOG]!><time="12:25:22.919+-60" date="03-07-2014" component="smspxe" context="" type="0" thread="4808" file="database.cpp:586">

 

Also findet er kein Advertisement für das Objekt mit der ResourceID 12. Das kann zB auch passieren, wenn nicht beide Bootimages auf dem PXE-SP vorhanden sind.

Evtl liegt aber irgendwo auch noch ein "unknown" Objekt. Ich habe gerade keine CM07-Konsole greifbar, aber diese sollten unter "unprovisioned computers" (oder so ähnlich) auftauchen. Wenn ja, dann löschen.

bearbeitet 21. März 2014 von TorstenM

[neochrome 0]

WinPE gibt's ja als x86 und x64 Version. Beide müssen zwingend auf dem PXE-SP verteilt werden - unabhängig davon, welches PE die TS verwendet. Im smspxe.log solltest Du beim Start des WDS-Dienstes auch sehen, ob/dass beide PEs vorhanden sind.

Die MAC 00:0C:29:45:EB:87 findet er in der Datenbank. Später im Log taucht dann ja folgendes auf (auf Seite 2 dieses Threads zu finden).

 

<![LOG[Executing GetBootAction(12, SRVAP02)]LOG]!><time="12:25:22.918+-60" date="03-07-2014" component="smspxe" context="" type="0" thread="4808" file="database.cpp:519">

 

<![LOG[No Boot Action for Device (12) found]LOG]!><time="12:25:22.919+-60" date="03-07-2014" component="smspxe" context="" type="0" thread="4808" file="database.cpp:586">

 

Also findet er kein Advertisement für das Objekt mit der ResourceID 12. Das kann zB auch passieren, wenn nicht beide Bootimages auf dem PXE-SP vorhanden sind.

Evtl liegt aber irgendwo auch noch ein "unknown" Objekt. Ich habe gerade keine CM07-Konsole greifbar, aber diese sollten unter "unprovisioned computers" (oder so ähnlich) auftauchen. Wenn ja, dann löschen.

Wie gesagt, die PE's gelöscht und noch mal neu auf den PXE DP moppeddisiert und das ganze läuft ohne Probleme durch.

 

Vielen Dank für deine Hilfe bis hierher  :)

[neochrome 0]

Ich nochmal, bei der Verteilung von Win7 bootet der hoch, Ich kann das Passwort eingeben um die TS zu starten. Dann sagt der mir jedoch folgende Fehlermeldung:


"Diese Tasksequenz kann nicht ausgeführt werden weil ein Paket auf das diese Tasksequenz verweist nicht gefunden werden konnte."

Das einzige was ich ausgewählt habe ist das Win7 Image und das ConfogMgr Package. 

Hat einer eine Ahnung wo das Problem liegen könnte ? Sowohl das Bootimage als auch das ConfigMgr Aktualisierungspaket ist auf die Verteilungspunkte verteilt worden. Oder könnte es ein Berechtigungsproblem sein ? 

Danke und Gruß

neochrome

bearbeitet 24. März 2014 von neochrome

[neochrome 0]

OK Problem ist behoben, war das ConfigMgr Packet, was fehlerhaft war. Das läuft jetzt auf jeden Fall durch.

Jetzt nach der Partitionierung kommt beim kopieren von dem Image jedoch ein neuer Fehler: Fehlercode 0x80070490.

Kennt das jemand ?

 

Gruß

neochrome

 

bearbeitet 24. März 2014 von neochrome

[TorstenM 20]

Bei OSD-Problemen => IMMER in's smsts.log schauen (http://www.mssccmfaq.de/2010/08/16/smsts-log/). Und zum Start erst einmal eine default Tasksequenz verwenden und keine selbst erstellen.

[neochrome 0]

Bei OSD-Problemen => IMMER in's smsts.log schauen (http://www.mssccmfaq.de/2010/08/16/smsts-log/). Und zum Start erst einmal eine default Tasksequenz verwenden und keine selbst erstellen.

 

 

Leider ist das smsts.log in keinem der möglichen Ordner auffindbar  :mad: