Using an NTLite-modifed WIM with SCCM

[AlBundy]

Hi all - I'm pretty new to NTLite, not too sure I'm using it as best as I could be, so thought I'd reach out... I work in a fairly large-scale Educational org, and we use SCCM for deploying desktops. Traditionally we've deployed modified versions of Windows that were created by installing a vanilla Windows ISO onto a VM, then making manual modifications, then capturing the resulting image with SCCM as a wim file. This process fell apart when Windows 11 came along with hardware requirements that prevented us installing the ISO on our VMs. It was also just time to move to something a bit more automated.

So far NTLite is working out pretty well, but it is not quite a like-for-like approach. When NTLite is finished processing, I basically just take the resulting install.wim file from the NTLite cache, and import it into SCCM. But there's one particular area where I'm struggling: our old wims used to incorporate a couple of apps: specifically MS Visual C++ Redists for 2015-2022, x86 and x64.

When I saw the "Post-Setup" feature on NTLite, I thought that would be perfect, I could just add the redists there. I assumed these were somehow integrated into the install.wim. However I've had no luck in this regard, and I think I see why now: The Post-Setup process seems to depend upon other files that accompany the install.wim file, right? Like it relies on the presence of directories like "sources\$OEM$\$$\Setup". And because I'm just importing the install.wim into SCCM, these files are not included?

Has anyone else encountered a challenge like this before?

I've got a workaround, we can just install these apps in the SCCM task sequence, and that's ok - it's just a bit of a change of direction for our Org that will is a bit change-averse at times

 

[garlin]

NTLite follows the normal install process (which always existed before SCCM).

1. Boot WinPE off the network or USB. Setup extracts files from install.wim, and copies $OEM$ folder files to the disk.
2. First reboot. Windows self-initializes, looks around for newly discovered devices, does more self-installation.
3. Second reboot. Runs OOBE, and runs Post-Setup before doing first logon.

For a normal install, Windows checks in C:\Windows\Setup folder for SetupComplete.cmd. If this file exists, it's executed by SYSTEM. There are two methods for inserting your own SetupComplete:

1. Mount the image, copy your script to \Windows\Setup. This is too much work if you need to keep updating SetupComplete, since it requires mounting and unmounting/commit the image.

2. Using the $OEM$ folder mechanism to overlay your script to \Windows\Setup. Because $OEM$ is a non-privileged folder in the ISO distribution, updating files is a simple file copy. When Post-Setup is run, $OEM$ files will have been staged in advance.

SCCM strings its own task sequences together, and adds them to the unattended file. There's nothing that precludes SetupComplete from running under SCCM, except for the fact that SCCM doesn't work at the ISO level. So it doesn't bother copying $OEM$. It's presumed you're in professional environment, and everything you need is mounted from network shares.

My advice is the same one as with WSIM: Use NTLite to customize the image with updates, removals and reg key integrations. Allow SCCM to do the post-install tasks.

NTLite serves a specific target niche, and it's not trying to compete with WSIM/MDT/SCCM. Use it for its image editing strengths.

 

[AlBundy]

Ok - Thanks for that, it clarifies the situation, and also confirms what I suspected: our past process of treating Visual C++ as if it was part of the OS needs to go, and we need to just install that through SCCM task sequence steps.

 

[JanetValentin]

Transitioning from manual modifications to a more automated approach can definitely have its challenges, especially with new operating system versions like Windows 11 shaking things up. It sounds like you're adapting well, though! Regarding your struggle with incorporating MS Visual C++ Redists into your modified images, I can see why the Post-Setup feature in NTLite seemed promising. It's unfortunate that it didn't quite work out as expected due to dependencies on additional files. Anyone else navigating the world of SCCM task sequences, I stumbled upon this helpful resource https://learnmesccm.com. It's got some useful insights for optimizing your OS deployments.

 

[garlin]

Regarding your struggle with incorporating MS Visual C++ Redists into your modified images, I can see why the Post-Setup feature in NTLite seemed promising. It's unfortunate that it didn't quite work out as expected due to dependencies on additional files.

The real problem is SCCM works by importing only the install WIM from an ISO project. None of the other files are preserved in the import.

For a normal ISO install, Setup recognizes the $OEM$ folder structure on the media, and begins copying \Windows\Setup which contains both the SetupComplete.cmd script and Post-Setup executables and scripts. The post-OOBE phase then executes SetupComplete.

Since SCCM doesn't replicate these files, then it must be done as a post-install SCCM task. And that's the normal way you're expected to follow in a SCCM environment, having a separate task for those items.

The normal advantage SCCM provides is every task's files are stored on a managed server. And if you get newer versions of .NET or VC++ runtimes, then you can drop replacements on the server's folders without having to rebuild a new ISO image.

NTLite will handle isolated WIM's, which is any install.wim which has been separated from a source ISO distribution; and no longer has the other media files. You can perform all the normal image tasks with isolated WIM's with the exception of Unattended mode and Post-Setup tasks for the obvious reasons.