What is wrong with this Post-Setup command? Files will not copy to OS installation

PlateauRealm

PlateauRealm

New Member
Messages
9
Reaction score
0
I am wondering why this will not copy the unpacked soures subfolder files to the new OS installation %appdat% subfolder.

I do not understand this directory import function format of NTLite.

I am trying to Post-Setup add the ScreenCapture license .dat files to the OS installation %appdata% subfolders that normally exist to grant license to ScreenCapture.

The ISO is unpacked to D:\OS_Configuration\W11_CURRENT\ folder that was imported into NTLite.

The $OEM$ folder was created in the unpacked ISO folder prior to importing the D:\OS_Configuration\W11_CURRENT\ folder to NTLite.

What am I missing here?

The Post-Setup before and after commands appear in the .xml file but will not import the *.dat files to the new installation %appdata% subfolders.

View attachment 13434
 

Disclaim: This is ChatGPT4o answer not mine..!!!​

  1. To ensure that the .dat files for the ScreenCapture license are copied to the %APPDATA% folder during the Windows installation, the following points and adjustments are crucial:

    Key Observations:​

    1. NTLite Directory Structure
      • NTLite uses the $OEM$ folder for file deployment during Windows setup.
      • Subfolders within $OEM$ must match the Windows directory structure:
        • $OEM$\$$\ → Maps to C:\Windows\
        • $OEM$\$1\ → Maps to C:\
        • $OEM$\$Docs\ → Maps to C:\Users\Public\Documents\
    2. Post-Setup Copy Command
      • The command /c copy /Y indicates a manual copy during Post-Setup.
      • %APPDATA% resolves to C:\Users\<User>\AppData\Roaming during a running user session.
    3. Timing Issue
      • If the %APPDATA% path does not exist during Post-Setup, the copy command fails. This is possible if the command runs before the user profile is initialized.
    4. Correct Syntax
      • %SYSTEMROOT% and %APPDATA% are environment variables, but ensure they resolve correctly within NTLite's execution context.

    Adjustments to Fix the Issue:​

    1. Move the .dat Files to $OEM$\$1
      Add your license file to:

      ruby
      Copy code
      $<span>OEM</span><span>$\</span><span>$1</span>\<span>SetupKeys</span>\<span>ScreenShotCapture</span>.dat<br>
      • This ensures the files are placed in C:\SetupKeys\ during the Windows installation.
    2. Modify Post-Setup Command
      Use the following robust Post-Setup copy command to ensure it executes after logon when %APPDATA% is valid:

      cmd
      Copy code
      cmd /c xcopy "C:\SetupKeys\ScreenShotCapture.dat" "%APPDATA%\DonationCoder\Keys\" /Y /I<br>
      • Breakdown:
        • xcopy handles creating target directories (/I) if they don't exist.
        • %APPDATA% resolves correctly because the user profile is loaded after logon.
    3. Ensure Correct Timing in NTLite
      • Place this command in the Post-Setup After Logon section.

    Step-by-Step Solution:​

    1. Place the .dat file in the $OEM$$1 folder:

      ruby
      Copy code
      <span>D:</span>\OS_Configuration\<span>W11_CURRENT</span>\$<span>OEM</span><span>$\</span><span>$1</span>\<span>SetupKeys</span>\<span>ScreenShotCapture</span>.dat<br>
    2. Add this to the Post-Setup After Logon task in NTLite:

      cmd
      Copy code
      cmd /c xcopy "C:\SetupKeys\ScreenShotCapture.dat" "%APPDATA%\DonationCoder\Keys\" /Y /I<br>
    3. Rebuild the ISO with NTLite and test.

    Why This Works:​

    1. $OEM$\$1 ensures the files are copied to the root of the system drive (C:\).
    2. The command executes after logon, when the %APPDATA% folder is guaranteed to exist.
    3. xcopy ensures the folder structure is created if missing.


Click to expand...
 
I changed and simplified the Post-Setup (for quick testing purposes) with just a command to copy KeePass plugins from the C:\SetupKeysPlugins\KeePass\Plugins folder to the empty KeePass Plugin folder that the KeePass installation creates.

No files were copied with the CMD command although KeePass was successfully installed with the previous Post-Setup line before the CMD line.

All plugins have .plgx extensions and can ordinarily be manually dragged and dropped into the Plugins folder. These plugins are detected by KeePass when started.

I also tested the CMD line after manually creating a C:\SetupKeysPlugins\KeePass\Plugins folder in a current Windows installation and the CMD command did copy the .plgx files into the KeePass plugins folder. So, I am not sure why the Post-Setup CMD command is not copying the plugins.

Also, there exists no C:\SetupKeysPlugins folder in the target installation. I thought that the outlined procedure above was suppose to create that folder during target installation.
 
Last edited:
The solution offered by Cobra_Smile works when the $OEM$ folder is located in the \sources folder.

I found my solution by trial and error.

This is done prior to loading the copied ISO into NTLite:
I mount the Win ISO and then copy its contents to an empty folder.​
I then copy the pre-built $OEM$ structured folder that I separately created to the copied ISO \sources subfolder. If the \sources subfolder already has an $OEM$ folder, I add the $1 subdirectory of my $OEM$ structured folder to the existing $OEM$ folder.​

I then load the directory of the copied ISO into NTLite to perform ops.

NTLite will add the $$ (with \Setup\Files, \Setup\FilesU and \Setup\Scripts subfolders) folder to a pre-existing $OEM$ folder found in the \sources subfolder, retaining the pre-existing $1 subfolder.
 
Last edited:
Out of curiosity, have you tried adding the files into the mounted directory within NTLite so you can bypass the need for a Post-Setup command? Have you tried using the absolute filepath within the Post-Setup? I found that using stuff like %Appdata% does not work reliably compared to typing the full path out.
 
The majority of the Post-Setup commands are required as follow-ups in the sequence of prior silent app installation in the Post-Setups after log-on section. I cannot reliably add the license and plugin files until the directories are first created by the associated silent app installation, else the license and plugin files may be overwritten or deleted by their associated,subsequent silent app installation. So, although folders and files can be added to the mounted directory within NTLite, these Post-Setup commands are still necessary for a reliable result.

Both absolute file paths and file path environment variable placeholders work consistently for me in Post-Setup commands.

The problem I encountered was due to my mistakenly adding the $OEM$\$1 structured license and plugin folders and subfolders to the root of the loaded copy of the mounted ISO, instead of placing the $OEM$\$1 in the loaded copy's \sources subfolder. Apparently, NTLite looks only at the \sources\$OEM$ folder during processing. NTLite will add the $$ subfolder to the \sources\$OEM$ folder during processing. Any pre-existing \sources\$OEM$\$1 subfolder found by NTLite in the \sources\$OEM$ folder prior to processing will be retained following the processing.

Any other $OEM$\$1 (C:\) and $OEM$\$$ (C:\Windows\) folder locations not found in the \sources subfolder seem to be ignored during processing and their respective contents will not be created at C:\ and C:\Windows\ during deployment installation, thus, any Post-Setup commands referencing files in these locations during deployment will fail.

Alternatively, the attached NTLite Image and USB Utility (text version) I wrote can perform several pre and post operations on edit and reference images prior to deployment.
 
Last edited:
Here's the context of what's happening behind the scenes:

Windows Setup has always supported the notion of $OEM$ folders. If there's a "\sources\$OEM$" folder on the install media, then Setup will begin copying files in the WinPE pass to the target disk and follow the standard rules:

$OEM$\$1 maps to C:\
$OEM$\$2 maps to D:\
$OEM$\$$ maps to C:\Windows

Folders are recursively copied to their mapped destinations, and this stage is completed before the first reboot out of WinPE and into your just installed Windows. The one weird catch is Windows sets the read-only flag on each of the copied files.

This was the old school method, and you had to manually do it yourself. Earlier versions of NTLite would automatically create $OEM$\$$\Setup folder to stage your Post-Setup commands and files. But only with the intention of temporarily staging them on the target system as C:\Windows\Setup, and performing a cleanup to purge all staged files when Post-Setup was done.

When you submit an executable file with a recognized extension (.*bat, *.cmd, *.ps1), it gets copied to the staging folder. And will be removed after Post-Setup is done.

What was missing, and most beginners found confusing, was a simpler way of submitting a non-executable file for copying to the target disk. You could (and still can) use the $OEM$ folder method. But that's too hard for some users.

NTLite now allows you to select "Copy" of a non-executable file and allows you to provide a relatively target path ("\some\path") which appends to the C:\ drive path. But this is in the context of the SYSTEM user, and not you (the primary user).


When commands are executed in Post-Setup (After logon), it's done during your first desktop logon session. Tasks are executed on your user context, but with Admin rights. You own an %APPDATA% folder, but it's not populated by NTLite. Windows doesn't really create all those user folders (provisoning) until your first logon session.

If you need to access to external files (because you have no %APPDATA% folder before logon), then you need to:
1. Stage files in Post-Setup (Before logon) to some neutral folder location.
2. Run your Post-Setup (After logon) task to either copy it from the neutral folder back into your profile, or read directly from the external file source.

You have a chicken & egg problem: NTLite can't help you by providing a way to pre-stage %APPDATA% or any user profile folders because your Windows account isn't completely provisioned before first-time logon. And you can't pre-create a whole user account unless you decide to sysprep an already configured post-setup image.

Hope that makes sense.
 
I do find it more useful to utilize the old OEM folder method. I can add both executable and non-executable files to the $OEM\$1 folder, then use After logon user operations to not only install apps silently but also delete the $OEM$ folder after all Post-Setup After logon silent installations complete.

The attached USB device Windows boot installation creation utility I created assists me in the USB building operation.
Updated 2026-02-12_2235
 

Attachments

Last edited:
You must log in or register to reply here.
Back
Top