MDT Capture start zijn PE niet.

[IceTeaGX]

Ik heb met veel moeite een deployment opgezet om windows 7 op een Dell latitude E5470 te zetten. (NVME SSD, en UEFI) Nu wil ik hiervan een image capturen om in de toekomst te kunnen deployen, maar hier gaat het fout.

Ik gebruik hierbij MDT 2013 u1 en Windows 10 ADK op een Windows 2008R2 server.

Als ik de litetouch.vbs start vanuit windows, doet die de nodige voorbereidingen, plaatst de PE omgeving, maar bij het rebooten kan hij niet opstarten. Er wordt geen boot device gevonden. Ik kan dus ook de originele windows niet meer starten. Legacy aanzetten in BIOS helpt ook niet.
De capture task sequence is standaard, net als de .ini files.

Ik vermoed dat de oorzaak vooral in het UEFI gegeven zit, want moest er enkel een probleem zijn met drivers, zou de PE omgeving initieel nog moeten kunnen opstarten (hij zou enkel geen schijf vinden).

Weet iemand waar ik fout ga, of vraag ik nu teveel met de combinatie Win7/NVME/UEFI te capturen?

[Killah_Priest]

welke versie van MDT en ADK gebruik je?

Edit : Doh, overheen gelezen (snap niet hoe ik het heb kunnen missen).

Hoe capture je je image? (ik neem aan booten naar OS, deploymentshare mounten als admin, litetouch.vbs starten en capture kiezen oid)?

En als je bv PXE boot op zo'n machine en je kiest voor de command prompt, wordt de harde schijf dan wel gezien? En hoe ziet bv de BCD info eruit?

En zoals degene onder mij zegt : inderdaad, beter om een generieke (hardware onafhankelijke) image te maken in een VM en de drivers correct te injecten (zij het met een driver install tool van de fabrikant, custom geschreven scripts of de opties in MDT)

[ Voor 106% gewijzigd door Killah_Priest op 18-07-2016 18:56 ]

[citruspers]

Ik deploy al onze 5470's met mdt dus kan je uit ervaring vertellen dat het wel zou moeten werken. Heb je de nieuwste generieke Dell pxe drivers aan de image toegevoegd?

Anders kan hij mogelijk de msata ssd niet vinden.

Trouwens, het is veel beter om je generieke image vanuit een VM te capturen en tijdens de deployment de drivers te injecteren voor je specifieke laptopmodel. Kost wat meer tijd in het begin maar gaat je met elke volgende laptop tijd besparen.

[ Voor 35% gewijzigd door citruspers op 18-07-2016 18:02 ]

[IceTeaGX]

Het deployen van 0 lukt. Dus de pxe boot vanop de wds ook.
Enkel het capturen niet.

En de capture wordt inderdaad gestart vanuit het os, vanop de deployment share.
Ik heb de capture ook al eens opgestart vanuit de pxe boot, maar daar bleef hij hangen ergens in de task sequence. (ik ga dit morgen nog eens proberen)

Het beste is inderdaad via een hyper-v gaan en zo een base image opzetten. Dit geval is een uit zijn voegen gebarstte test
Vond het alleen raar dat het niet wou werken.

[citruspers]

Bijzonder. Tijd om de logs te checken denk ik

[TheVMaster]

citruspers schreef op maandag 18 juli 2016 @ 18:00:
Ik deploy al onze 5470's met mdt dus kan je uit ervaring vertellen dat het wel zou moeten werken. Heb je de nieuwste generieke Dell pxe drivers aan de image toegevoegd?

Anders kan hij mogelijk de msata ssd niet vinden.

Trouwens, het is veel beter om je generieke image vanuit een VM te capturen en tijdens de deployment de drivers te injecteren voor je specifieke laptopmodel. Kost wat meer tijd in het begin maar gaat je met elke volgende laptop tijd besparen.

Ik zou trouwens alleen in zeer specifieke gevallen (grote hoeveelheid applicaties die tijdens de Task Sequence geinstalleerd moeten worden of een deployment waarbij de doorlooptijd cruciaal is) een capture willen maken, moet eerlijk zeggen dat ik het eigenlijk nooit implementeer. Ga meestal voor een 'vanilla' Windows image en tijdens deployment schiet je dan de drivers en applicaties in (in een basis image wil je eigenlijk ook alleen maar Visual C++, Silverlight en misschien Office hebben volgens mij).

En het is inderdaad best-practice om een capture op een virtual machine te doen (i.v.m. vervuiling van drivers en de snelheid aangezien je vaak op snelle centrale storage werkt).

[ Voor 7% gewijzigd door TheVMaster op 19-07-2016 10:22 ]

[IceTeaGX]

De logs staan op de schijf die niet meer wil opstarten. Ik ga er niet achter jagen uit een recovery omgeving ofzo. Denk ook niet dat daar veel op te zien zal zijn. Hij doet zijn task sequence, maar de manier dat hij zijn capture PE omgeving opzet is niet bootbaar.

Momenteel is het dus een volledige deployment. Maar vooral de updates duren daarbij zeer lang,zelfs met de hotfix die het eindeloze searching for updates aanzienlijk verkort. De updates rechtstreeks in de deployment duwen gaf hier problemen (misschien ook iets verkeerd mee gedaan) dus doen we het maar via wsus. De geïnstalleerde software is daarbij vrij algemeen, en op iedereen van toepassing (office, java, browsers, VPN client, PDF reader, ...)

Momenteel werkt men met een sysprepped acronis image, maar die is device specific (give or take enkele kleine revisies). Het zal de vraag zijn of ze het hierbij willen houden, of toch een algemene deployable image willen.

[citruspers]

TheVMaster schreef op dinsdag 19 juli 2016 @ 10:22:
[...]


Ik zou trouwens alleen in zeer specifieke gevallen (grote hoeveelheid applicaties die tijdens de Task Sequence geinstalleerd moeten worden of een deployment waarbij de doorlooptijd cruciaal is) een capture willen maken, moet eerlijk zeggen dat ik het eigenlijk nooit implementeer. Ga meestal voor een 'vanilla' Windows image en tijdens deployment schiet je dan de drivers en applicaties in (in een basis image wil je eigenlijk ook alleen maar Visual C++, Silverlight en misschien Office hebben volgens mij).

En het is inderdaad best-practice om een capture op een virtual machine te doen (i.v.m. vervuiling van drivers en de snelheid aangezien je vaak op snelle centrale storage werkt).

Ik houd mijn reference image zo schoon mogelijk, maar zorg er wel voor dat deze voorzien is van de meest recente updates. Dat spaart tijd en heeft toch elke laptop nodig. En zeker met een VM met snapshots kost het nauwelijks tijd om de image te updaten. Updates, snapshot, sysprep+capture en revert naar de snapshot.

Applicaties, drivers en dergelijke installeer ik wel tijdens de deployment omdat ik die flexibiliteit wil behouden. Inclusief Office trouwens, die heeft ook een prima silent installer (in tegenstelling tot, bijvoorbeeld, symantec)

[ Voor 5% gewijzigd door citruspers op 19-07-2016 11:22 ]

[TheVMaster]

IceTeaGX schreef op dinsdag 19 juli 2016 @ 10:58:
De logs staan op de schijf die niet meer wil opstarten. Ik ga er niet achter jagen uit een recovery omgeving ofzo. Denk ook niet dat daar veel op te zien zal zijn. Hij doet zijn task sequence, maar de manier dat hij zijn capture PE omgeving opzet is niet bootbaar.

Momenteel is het dus een volledige deployment. Maar vooral de updates duren daarbij zeer lang,zelfs met de hotfix die het eindeloze searching for updates aanzienlijk verkort. De updates rechtstreeks in de deployment duwen gaf hier problemen (misschien ook iets verkeerd mee gedaan) dus doen we het maar via wsus. De geïnstalleerde software is daarbij vrij algemeen, en op iedereen van toepassing (office, java, browsers, VPN client, PDF reader, ...)

Momenteel werkt men met een sysprepped acronis image, maar die is device specific (give or take enkele kleine revisies). Het zal de vraag zijn of ze het hierbij willen houden, of toch een algemene deployable image willen.

Anno 2016 kan een sysprepped Acronis image echt niet meer hoor. Microsoft biedt zulke handige (gratis!) tools aan waarmee je veel flexibeler bent : WDS (standaard onderdeel van Windows Server) in combinatie met MDT is een super oplossing. Daarnaast wil je JAVA eigenlijk niet in je basis image hebben, die moet je geloof ik 3x per week updaten (als je nu een image maakt en die over paar weken gaat deployen...dan heb je al weer 10 fixes gemist), maar goed..dat is jouw keuze...ik zou het anders doen Geen idee of je uberhaupt een andere applicatie-deployment-methode in gebruik hebt hoor...misschien is MDT wel je enige optie...

citruspers schreef op dinsdag 19 juli 2016 @ 11:21:
[...]


Ik houd mijn reference image zo schoon mogelijk, maar zorg er wel voor dat deze voorzien is van de meest recente updates. Dat spaart tijd en heeft toch elke laptop nodig. En zeker met een VM met snapshots kost het nauwelijks tijd om de image te updaten. Updates, snapshot, sysprep+capture en revert naar de snapshot.

Applicaties, drivers en dergelijke installeer ik wel tijdens de deployment omdat ik die flexibiliteit wil behouden. Inclusief Office trouwens, die heeft ook een prima silent installer (in tegenstelling tot, bijvoorbeeld, symantec)

Ehh....je kunt je WIM file ook heel makkelijk 'offline' up2date houden, heb ik een reference image voor nodig hoor. Ik installeer inderdaad ook alles tijdens de deployment, dat zorgt er natuurlijk ook voor dat je zo je Windows 7 Image kunt vervangen door een Windows 10 variant. Je hoeft dan niet weer helemaal een capture te doen etc. Scheelt ook qua beheer erg veel tijd.

[ Voor 44% gewijzigd door TheVMaster op 19-07-2016 11:46 ]

[IceTeaGX]

TheVMaster schreef op dinsdag 19 juli 2016 @ 11:41:
Anno 2016 kan een sysprepped Acronis image echt niet meer hoor. ...

Yes, preaching to the choir, maar ik denk dat we allemaal wel weten hoe stug het soms kan zijn. Als "groentje" kan ik hier misschien wel enkele nieuwe ideetjes aanbrengen, dat wil niet zeggen dat men er ook mee gaat werken.
Had de nvme/UEFI toestand niet zo moeilijk gedaan had ik niet eens een WDS/MDT test opgestart.

Net nog eens getest, voor de fun.
Er komt vrij snel (3 sec) een rode balk boven op het starting windows scherm en de PC reboot.
Dan vraag hij een startup repair uit te voeren.
Die komt met een "0xc000000f A required device isn't connected or can't be accessed" error, waarna de PC uitschakeld.

Ik ga de poging tot capturen opgeven.
Men krijgt de keus tussen acronis, full deployment, of via hyper-v capturen.

Toch bedankt voor het meedenken.

[TheVMaster]

IceTeaGX schreef op dinsdag 19 juli 2016 @ 12:25:
[...]

Yes, preaching to the choir, maar ik denk dat we allemaal wel weten hoe stug het soms kan zijn. Als "groentje" kan ik hier misschien wel enkele nieuwe ideetjes aanbrengen, dat wil niet zeggen dat men er ook mee gaat werken.
Had de nvme/UEFI toestand niet zo moeilijk gedaan had ik niet eens een WDS/MDT test opgestart.

Net nog eens getest, voor de fun.
Er komt vrij snel (3 sec) een rode balk boven op het starting windows scherm en de PC reboot.
Dan vraag hij een startup repair uit te voeren.
Die komt met een "0xc000000f A required device isn't connected or can't be accessed" error, waarna de PC uitschakeld.

Ik ga de poging tot capturen opgeven.
Men krijgt de keus tussen acronis, full deployment, of via hyper-v capturen.

Toch bedankt voor het meedenken.

Maar eh....waarom capturen? Is er een harde eis m.b.t. de doorlooptijd ofzo?

[IceTeaGX]

Hoofdzakelijk om de deployment tijd terug te dringen.
Het mag niet veel langer duren dan een acronis image te plaatsen.
Klanten betalen misschien wel per uur, maar niet om op een deployment te babysitten.

Een full deployment duurt wel ettelijke uren.
Tegenover een 15 minuutjes voor een acronis image terug te zetten, met misschien nog 15 minuutjes om deze af te werken.

[qwasd]

Probeers eens een capture uit te voeren met wds i.p.v. met mdt. Boot image toevoegen en dan een capture inage.

[TheVMaster]

IceTeaGX schreef op dinsdag 19 juli 2016 @ 14:00:
Hoofdzakelijk om de deployment tijd terug te dringen.
Het mag niet veel langer duren dan een acronis image te plaatsen.
Klanten betalen misschien wel per uur, maar niet om op een deployment te babysitten.

Een full deployment duurt wel ettelijke uren.
Tegenover een 15 minuutjes voor een acronis image terug te zetten, met misschien nog 15 minuutjes om deze af te werken.

Oke.....je hebt heel veel software in je TS staan (waarmee je je Golden Image maakt?). Van wie mag het niet veel langer duren dan een Acronis (bah) image plaatsen? Hoezo betaald de klant per uur, ik neem aan dat je een deployment aanzet en dan wat anders gaat doen?

Of kom je soms bij de klant om puur en alleen een deployment te doen? Dat kan een klant toch ook gewoon zelf...hij drukt op F12 en gaan met die banaan. Helemaal als je de database functionaliteit in MDT gebruikt, dan kan het redelijk zero-touch gaan.

qwasd schreef op zaterdag 13 augustus 2016 @ 00:36:
Probeers eens een capture uit te voeren met wds i.p.v. met mdt. Boot image toevoegen en dan een capture inage.

Waarom zou je 'terug' gaan naar WDS als je MDT gebruikt?

[ Voor 63% gewijzigd door TheVMaster op 13-08-2016 01:06 ]

[qwasd]

Ik bedoel om die foutmelding. Misschien dat hij iets fouts doet bij het maken van die capture via mdt. Als het via wds werkt dan ligt het misschien aan de ts die hij heeft aangemaakt.

Maar ik ben het compleet met je reactie eens m.b.t. het gebruik van MDT en dat een gebruiker dit zelf ook kan als je bijvoorbeeld per locatie, merk/model alles vol hebt geautomatiseerd in de mdt database.
Zelf doe ik alles met mdt en paketten zoals acronis kunnen hier niet aan tippen vind ik.

[TheVMaster]

qwasd schreef op zaterdag 13 augustus 2016 @ 10:06:
Ik bedoel om die foutmelding. Misschien dat hij iets fouts doet bij het maken van die capture via mdt. Als het via wds werkt dan ligt het misschien aan de ts die hij heeft aangemaakt.

Maar ik ben het compleet met je reactie eens m.b.t. het gebruik van MDT en dat een gebruiker dit zelf ook kan als je bijvoorbeeld per locatie, merk/model alles vol hebt geautomatiseerd in de mdt database.
Zelf doe ik alles met mdt en paketten zoals acronis kunnen hier niet aan tippen vind ik.

Oohw...zo bedoel je, ja om te troubleshooten zou het inderdaad wel een optie kunnen zijn.

[IceTeaGX]

Het komt er op neer dat je een capture best uitvoert vanop een HyperV guest.
Momenteel hadden we het probleem dat de PE omgeving die opgezet wordt om de capture uit te voeren niet kan opstarten, omdat die totaal geen benul heeft van de NVMe drive.
De capture starten vanop de netwerkboot gaf ook consistent problemen (dat is dan nog een ander probleem)

Nu is een acronis capture ook geen optie omdat de generalize evengoed de drivers voor te booten weggegooid, en acronis (toch de 11.x) ook niet goed overweg kan met heel het NVMe gebeuren.

De rest van de company policy stond hier niet ter discussie, dus daar ga ik ook niet op ingaan. Het werkt in ful deployment mode, al duurt het 8 uur, en als men daar een oplossing voor wilt, kan dit ook via een Hyper-V capture.

Ik vond het alleen raar dat ik een netwerk boot image kan tunen met de juiste drivers, maar dat het capture systeem niet zo slim is om diezelfde drivers ook te gebruiken in de capture PE (of waar ik de mist in ging)

[TheVMaster]

IceTeaGX schreef op zondag 14 augustus 2016 @ 13:06:
Het komt er op neer dat je een capture best uitvoert vanop een HyperV guest.

Dat gaat inderdaad het snelst en je hebt geen 'modelspecifieke drivers' die je image kunnen vervuilen ('k doe ook al een jaar of 9 MDT/SCCM etc, dus ik weet hoe het werkt ).

Momenteel hadden we het probleem dat de PE omgeving die opgezet wordt om de capture uit te voeren niet kan opstarten, omdat die totaal geen benul heeft van de NVMe drive.
De capture starten vanop de netwerkboot gaf ook consistent problemen (dat is dan nog een ander probleem)

Dan zul je in je PE image dus die NVMe driver moeten stoppen, zonder die driver gaat hij die drive nooit herkennen vanuit je PE.

Nu is een acronis capture ook geen optie omdat de generalize evengoed de drivers voor te booten weggegooid, en acronis (toch de 11.x) ook niet goed overweg kan met heel het NVMe gebeuren.

De rest van de company policy stond hier niet ter discussie, dus daar ga ik ook niet op ingaan. Het werkt in ful deployment mode, al duurt het 8 uur, en als men daar een oplossing voor wilt, kan dit ook via een Hyper-V capture.

Volgens mij vraagt niemand dat aan je...

Ik vond het alleen raar dat ik een netwerk boot image kan tunen met de juiste drivers, maar dat het capture systeem niet zo slim is om diezelfde drivers ook te gebruiken in de capture PE (of waar ik de mist in ging)

Als je voor de Capture PE een ander PE image gebruikt, tja...dan zitten daar die drivers niet in.