I think UEFI and secure boot are security functions that should be taken advantage of whenever you have a machine that is capable. Pass the hash and hacked drivers are no joke. Neither are attacks with hacked firmware. As security attacks become ever more sophisticated it will be more and more a requirement to have a fully secure boot chain. Secure boot protects against rootkits and hacked firmware - both are real threats that will gain in popularity in the coming years. I think it is a big mistake to continue to deploy new machines that are capable of UEFI in MBR/Legacy mode.
Turning on UEFI when doing a new deployment is not that much trouble. I just would like to figure out how to automate it. When upgrading from Windows 7 to Windows 10, perhaps the scales are tipped towards leaving MBR and Legacy BIOS if that is what you have in a refresh scenario. I don't anticipate upgrading to Windows 10 for another two years, so it would be nice to start getting out my Windows 7 machines out now with UEFI/GPT formatted drives so they can take advantage of Windows 10 security features once we are ready to upgrade to Windows 10. For the moment though, I am only interested in getting this to work in a bare metal task sequence. I just can't get the task sequence to stage WinPE to a GPT disk when it is booted into Legacy. I'll need to figure out a way to switch to UEFI before the task sequence starts up. Right now, I am looking into moving the switch to UEFI out to the pre-execution hook stage. When you boot from the key it will check to see if the computer model is on the "switch to UEFI" list. If the computer is a model that we have validated for UEFI then the script will enable UEFI and reboot. When the computer gets to the Pre-Execution hook a second time, it will "pass" the UEFI check and continue with the OS Deployment process. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Keith Garner (Hotmail) Sent: Saturday, January 02, 2016 12:26 PM To: [email protected] Subject: RE: [MDT-OSD] Switch to GPT/UEFI during bare metal install Then challenge is all the companies out there who purchased Secure-Boot capable machines with Windows 8 or 8.1 pre-installed, but who installed Windows 7 SP1 as a standard corporate image instead. Now these same companies want to move these win7 machines to Windows 10 with Device Guard and Secure Boot which would require going back to uEFI. For most machines, my recommendation is to just upgrade from Windows 7 to Windows 10 in-place and keep it BIOS/MBR (no secure boot/ no device guard). Otherwise, if you need the full uEFI Device Guard/Secure Boot experience, wipe the machine and load. -k -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Marcum, John Sent: Saturday, January 2, 2016 6:30 AM To: [email protected] Subject: Re: [MDT-OSD] Switch to GPT/UEFI during bare metal install Why should we move machines that are configured for legacy BIOS to UEFI? On Jan 1, 2016, at 4:26 PM, Jason Sandys <[email protected]<mailto:[email protected]>> wrote: Yep, not saying it's not an issue, just that there's no magic on the software side that's going to make it go away. I know that doesn't help anyone other than help prevent them from wasting lots of time on it. J From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Niall Brady Sent: Friday, January 1, 2016 2:48 PM To: [email protected]<mailto:[email protected]> Subject: Re: [MDT-OSD] Switch to GPT/UEFI during bare metal install 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]<mailto:[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]> [mailto:[email protected]<mailto:[email protected] >] On Behalf Of Miller, Todd Sent: Thursday, December 31, 2015 5:32 PM To: [email protected]<mailto:[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]> [mailto:[email protected]] On Behalf Of Niall Brady Sent: Thursday, December 31, 2015 4:24 PM To: [email protected]<mailto:[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]<mailto:[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. ________________________________ ________________________________ Confidentiality Notice: This e-mail is from a law firm and may be protected by the attorney-client or work product privileges. If you have received this message in error, please notify the sender by replying to this e-mail and then delete it from your computer. ________________________________ 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. ________________________________
