A common practice is to place an $OEM$ structure beneath the Control folder for it to be build-specific. I.e., if you have a build named Srv2003, then D:\Distribution\Control\Srv2003\$OEM$ is the starting point for inserting $$, $1 or textmode goodies. I recently discovered, and Michael Niehaus verified, that there’s a bit of a bug in the BDD code for copying this content to a Media deployment point. The command in use is copying files at the Control level, and specifically only gets .TXT, .INF and .XML files (which are the only ones expected to be found in the build Control folders). However this also includes a switch to recurse down the folder hierarchy, so any $OEM$ folders are also copied to the media deployment point. But only the .TXT, .INF and .XML files! I as pulling out my already non-existent hair trying to figure out why my textmode folder was only containing the INF and not the SYS and CAT files.
One workaround for this is to manually copy the necessary files to the Media deployment point (e.g., D:\MEDIA\Content\Deploy\Control\…\$OEM$\…)and then manually recreate the ISO. The command to manually recreate the LiteTouchPE ISO is
“C:\Program Files\Windows AIK\Tools\PETools\oscdimg.exe” -h -u2 -m -bD:\MEDIA\Content\Boot\etfsboot.com D:\MEDIA\Content D:\MEDIA\LiteTouch_x86.iso
The -h parameter grabs hidden files, -u2 uses UDF format, -m overrides the 650MB default maximum size, and -b is the path to the bootable file.
The other option is to utilize another little quirk I discovered. When updating a media deployment point (I’m not sure if this applies to others as well) it does not remove/replace any existing Content files. So if you update the deployment point for the first time, and then copy the necessary files under Control\…\$OEM$, and then update again, those added files will get wrapped up into the ISO.
A catch with this though (and perhaps this is common knowledge, but it threw me for a loop this week): if you need to completely update the source for an Application or Driver (for example), you need to first delete it from the Media deployment point. In my example I had the wrong Server 2003 R2 Components in a build (as an Application). I deleted the existing application, recreated (with the same name), and updated the deployment point. What happened is that the R2 Components folder almost doubled in size, but retained the previous (and incorrect) setup2.exe. I blew away the entire deployment point, updated and all was well.