problem is many UEFI capable machines today are shipping from lenovo, dell, etc pre-configured in Legacy mode in order to run windows 7, as specified by the customer, and... they then decide to migrate to windows 10 and want to use UEFI,
On Fri, Jan 1, 2016 at 9:27 PM, Jason Sandys <[email protected]> wrote: > “Staff should really not have to muck around in the BIOS before kicking > off the OS deployment.” > > > > The problem though is this is a hardware issue with hardware requirements > that cannot be overcome with software at this time. Switching from BIOS to > UEFI is a major hardware change that nothing on the existing system > survives. OS deployment is a software mechanism, Windows has no direct > control over the hardware. Using vendor tools you can effect certain > changes, but there are implications of those changes that simply cannot be > overcome and in this case the change is much, much more than a simple > switch and more than changing the partition type. It’s effectively changing > how the system boots, how it sees its hardware, and how it even powers on. > You can’t expect software alone to overcome that. The hardware vendors may > be able to help out, but given that this is not a new problem – it’s been > around for at least 5 years now – I don’t have a lot of confidence that > anything will change because of the drastic nature of the change itself. > > > > If you want UEFI systems, then have then vendor ship them to you in UEFI > mode. > > > > J > > > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *Miller, Todd > *Sent:* Thursday, December 31, 2015 5:32 PM > *To:* [email protected] > *Subject:* RE: [MDT-OSD] Switch to GPT/UEFI during bare metal install > > > > I suppose I could move the whole switch to UEFI mode into the > pre-execution hook phase too. Boot from the stick and if UEFI is not > enabled and the model of computer is a UEFI supported model, then set UEFI > and reboot back to the stick and let the pre-hook run again, this time it > would pass the “is UEFI mode enabled” check. > > > > I don’t know that the run task sequence A from Task Sequence B is going to > help with this scenario. The problem is in the staging of the WinPE image > onto a disk when the disk format doesn’t match the perceived Firmware > type. Even if you’re doing nested task sequences, you still will need to > stage WinPE on a disk that the TSCore.dll doesn’t like. > > > > It should be a fairly common scenario to pull a machine from the box and > deploy an OS to it with all the Firmware set as desired. Staff should > really not have to muck around in the BIOS before kicking off the OS > deployment. There should be a way to automate it. Just the TS engine > doesn’t account for staging WinPE to a differently partitioned disk than it > expects. We repartition and reboot during a task sequence now, it is > just that the TS is seeing the Legacy boot and refusing to stage onto a GPT > partitioned disk. > > > > *From:* [email protected] [ > mailto:[email protected] <[email protected]>] *On > Behalf Of *Niall Brady > *Sent:* Thursday, December 31, 2015 4:24 PM > *To:* [email protected] > *Subject:* Re: [MDT-OSD] Switch to GPT/UEFI during bare metal install > > > > i'd just wait until microsoft releases the 'run another task sequence from > the first' next year and use that to do it, > > or, develop something very custom and very unsupported, such as pxe boot, > copy the contents of the _SMSTaskSequence to somewhere like a network > share, then use a diskpart script to make the switch, and before rebooting > xcopy the _SMSTaskSequence back to whatever the OSDISK is... > > before rebooting. > > might work, might not, definetly not supported > > > > On Thu, Dec 31, 2015 at 11:14 PM, Miller, Todd <[email protected]> > wrote: > > > > I am trying to take a machine that is Legacy BIOS and switch it to UEFI > during a bare metal install. So take a machine out of the box and end up > with a UEFI enabled, GPT partitioned, bitlockered, Windows 7sp1 x64 > deployment (fully automated) > > > > > > So the system boots in Legacy bios to a USB Stick with the WinPE 5.1 64bit > boot image. Then I am using Dell tools to switch the Firmware to UEFI > mode. Then I repartition the disk in the GPT format. Then I want to > reboot the task sequence to boot into UEFI mode from the newly GPT > partitioned disk. My problem is that “Restart Computer” task step refuses > to stage the WinPE image on that GPT partitioned disk. > > > > The error says that disk C: is on a GPT disk, but the system is MBR. It > is unable to see that I have just switched the Firmware to UEFI and so it > is refusing to stage WinPE on that GPT partition. I would have sworn I > had this working, but now it is broken. Can TSCore.dll be made to > reevaluate the Firmware state so it can see that the Firmware has been > switched to UEFI? > > > > Any ideas on how to trick “Restart Computer” step into staging the WinPE > image to the boot drive – even though it thinks the partitioning scheme is > wrong? It isn’t realty wrong… if it would just stage it and reboot, it > would boot OK. > > > > > > > > SCCM 2012R2Cu4, OSD+MDT2013, deploying Windows 7sp1 x64, boot image is > WinPE 5.1 based. > > > > > > My other solution would be to force the desktop support staff to go in an > manually set the BIOS to UEFI mode and then restart the process, but that > is unreliable since it is not automated. > > > ------------------------------ > > Notice: This UI Health Care e-mail (including attachments) is covered by > the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is > confidential and may be legally privileged. If you are not the intended > recipient, you are hereby notified that any retention, dissemination, > distribution, or copying of this communication is strictly prohibited. > Please reply to the sender that you have received the message in error, > then delete it. Thank you. > ------------------------------ > > > > > ------------------------------ > > Notice: This UI Health Care e-mail (including attachments) is covered by > the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is > confidential and may be legally privileged. If you are not the intended > recipient, you are hereby notified that any retention, dissemination, > distribution, or copying of this communication is strictly prohibited. > Please reply to the sender that you have received the message in error, > then delete it. Thank you. > ------------------------------ >
