Trying to capture an image from a desktop computer using OSD, and it doesn’t reboot into the WinPE, instead it PXE boots and attaches to the OSD server. That doesn’t seem right to me. We’ve already turned on the Disable enhanced error detection option. What am I missing?
Any input from you two would be most appreciated, @JasonWalker and @bradsexton81
Hello,
Did you check the boot order?
Regards
We’ll check on that. I presume that PXE shouldn’t be the first option.
Troubleshooting some of the OSD tasks is pretty complex because of the way it does a lot of the work “outside of the BigFix Client”. I assume you’re using the “OS Deployment - Capture” Dashboard to run the Capture action?
That would create a group action with components similar to this…
Are you able to tell how far the Capture process gets? In particular the last component, ‘Initiate Capture Action’ is where the BES Client gives up control of the rest of the process. After the earlier components have downloaded MDT resources, downloaded the boot.wim image that is used in the capture process, and sets up the configuration/answer file at C:\Deploy\Control\CustomSettings.ini, that last action runs the MDT LiteTouch.vbs script and the BigFix portion is finished.
LiteTouch.vbs, from the Microsoft Deployment Toolkit, is what should execute Sysprep, execute bcdedit to update the boot options (adding the boot.wim to the BCD), and rebooting the system into the boot.wim WinPE image to capture the image and upload it to a network share.
Note that after a successful Image Capture, the system is usually left unbootable, its BCD unusable, so it’s normal after a capture to end up booting PXE when the hard drive boot option is unusable (after a Capture, the same image should be imported into BigFix and re-deployed back to the captured machine.)
If LiteTouch is failing in some place, it should have left logs on the client, usually in C:\MININT, that can be helpful in figuring out where it went wrong. Of course it can be difficult to get to those logs if the system is unbootable, you may have to boot from another WinPE media to access the files. This is where I usually find it extremely helpful to do all of my captures in a virtual machine, where I can get a remote console while the OS is not bootable.
(Some of the most common causes of a capture failure are that the storage or network drivers required on the machine are not available in the WinPE image, so when the system reboots into WinPE it cannot access the disk or cannot access the network to upload the image. Another place where capturing a VM is really helpful is you don’t have to constantly chase drivers. If you find you need to add drivers, use the OS Deployment - Driver Library dashboard to bind drivers; target the WinPE image, not the final OS image, to fix driver problems at that level.)
Everything worked correctly up to the point of rebooting the machine. Then we into a secure boot issue, - not a valid signature. Turning off the secure boot resulted in it going to PXE boot and connecting to the OSD server.
Is Secure Boot supported?
Edit: We’re just trying to do a capture at this point.
Ah, that’s ringing a bell.
There was a fairly recent Windows Update that revoked a UEFI secure boot certificate, and requires all boot media (including the WinPE that we use in OSD) to be regenerated with a newer build of Windows. If you’ve applied that update to the endpoint and you’re still using an older WinPE, you may have to recreate your WinPE resources with a higher build of Windows media.
Let me find the details on that.
I believe that what I’m thinking of is https://support.microsoft.com/en-gb/topic/kb5012170-security-update-for-secure-boot-dbx-72ff5eed-25b4-47c7-be28-c42bd211bb15
A lot more details on the boot media at https://support.microsoft.com/en-us/topic/kb5025885-how-to-manage-the-windows-boot-manager-revocations-for-secure-boot-changes-associated-with-cve-2023-24932-41a975df-beb2-40c1-99a3-b3ff139f832d#updatebootable5025885
@sergio_tarchi do we have any specific OSD guidance on the UEFI DBX security updates from May/July? My expectation would be something like “update to latest MDT Bundle Creator & then generate & upload a new Bundle, overwriting the WinPE resources”?
The MDT bundle was generated in the last 2 weeks, so I’m not sure that this applies.
For what it’s worth, we are working with a physical machine.
In our current test run, the machine has not rebooted itself, even though the BigFix multi-action group completed successfully more than 30 minutes ago.
Hm. You just generated the bundle, but can you confirm you used a current version of the bundle creator when you generated it? And when you uploaded the bundle, did you take the option to ‘Overwrite WinPE resources’?
In the ‘Bundle and Media Manager’ dashboard, what version of PE10 is it showing in the ‘Resource Info’?
On the ‘MDT Bundle Creators and Windows Media’ tab of the same dashboard, which version of Deployment Kit is shown on your creator, and is there a warning about it being out of date (like mine is) ?
Yes, we chose to Overwrite WinPE resources.
Resource info is 22H2
And the Deployment Kit is current:
Thanks for your time, Jason.
Boyd
I may have been mistaken on how I read your earlier post… I was taking the ‘secure boot issue’ to be a problem booting into the locally-cached WinPE image, but on second reading that might have just been a blocker when it was already trying to boot PXE.
(We don’t want it to boot PXE right now, but as an aside - yes we can do PXE Secure Boot; but you have to configure the Bare Metal Server to do “WinPE Direct Boot on UEFI Targets”, which is configured on the Edit button of the server in the Bare Metal Server Manager dashboard)
On the most recent run, you say the BigFix multi-action group completed successfully…the last step of that should have launched LiteTouch.vbs
// Running LiteTouch.vbs
parameter "liteTouchScriptPath" = "{(value of variable "SystemDrive" of environment) & "\Deploy\Scripts\LiteTouch.vbs"}"
runhidden cmd.exe /C wscript "{parameter "liteTouchScriptPath"}"
LiteTouch.vbs should have started logging, even before rebooting. I expect the logs should be at C:\MININT\SMSOSD, check there and see if any errors were logged. It’ll probably be really useful to get a copy of CMTrace, which parses & searches their XML log file format, from https://learn.microsoft.com/en-us/mem/configmgr/core/support/cmtrace
Another thing you could try, is to manually launch from an elevated command prompt
cscript C:\Deploy\Scripts\LiteTouch.vbs
that should do command-line display of what LiteTouch.vbs is trying to do, and may make any errors a bit more obvious.
(references at https://learn.microsoft.com/en-us/troubleshoot/mem/configmgr/mdt/troubleshooting-reference )
Thanks for the advice. We’ll give it another try and see where we end up.
We did not expect the machine to PXE boot on the earlier tries.
The LiteTouch.vbs was launched during this attempt, but it seemed to be taking a long time, and perhaps became a bit impatient. We rebooted manually, and this time it did boot into WinPE. However, as you might expect, it wasn’t really ready for the reboot.
We’ll monitor the folder C:\MINIT\SMSOSD as you suggested.
Hello.
To run the Windows capture, if your UEFI booted computer has the secure boot enabled, you have to select the “Disable enhanced error detection” option.
More information on capture task at this link -> https://help.hcltechsw.com/bigfix/10.0/lifecycle/Lifecycle/OSD_Users_Guide/c_capture_images.html
In particular -> To capture an image on a UEFI client with the Secure Boot firmware option enabled, you must select the Disable enhanced error detection option
Thanks.
Sergio
BigFix OSD L3 team