NTLite Post-Setup Trap (Machine vs User)

There is a conceptual trap in NTLite’s registry and post-setup section: anything user-specific are not handled properly until an account is established (say created by NTLite itself)! You might even run into this dead-end if you attempt to tell NTLite to install user-interactive programs before an account exist.

How can you install software that did not come with Windows without an account in place and Windows will know where to put the user-specific registry settings? Silent installers might get stuck as they don’t know how to handle it gracefully (such as aborting the particular installation and move on). So you might need to hard reset to interrupt the confused silent installers until there are none left.

Machine vs User

First of all, NTLite’s UI did not educate the user on the concept of ‘Machine’ vs ‘User’ and what are the implications and bad things that’d happen if conflated the two.

TLDR: ‘Machine’ vs ‘User’ in post-setup section is a matter of WHEN (before or after an *user* account is active), not a matter of WHICH (machine-wide or user-specific)! This is what the UI in NTlite doesn’t tell you and I had to figure it out on my own!

More specifically in the forum, ‘Machine’ refers to a special SYSTEM account (a kind of service account) which you cannot interact like a built-in Administrator (typical user account that’s a member of the interactive user group). When your user-interactive programs/installers try to write as (which settings also go into) a SYSTEM account, it’s hard to predict how the programs/installers will react when the program learned the hard way it shouldn’t/couldn’t/wouldn’t!

Of course if an operation is purely system-wide with no user-specific components, you can eagerly put them in the ‘Machine’ bin if you are 100% on top of it and know the operation has ZERO side effects/dependencies that are user-specific, but this is not necessary nor helpful to do so if it’s not a scenario that you absolutely have to. e.g. enabling an account before you have an active account is a good use of the ‘Machine’ section.

Machine refers to system-wide operations that are not tied to specific accounts, something like adding an account (or enabling built-in administrator account before the NTlite bug was fixed) or enabling Powershell scripts to run in the unattended process (yes, it’s disabled by default which is super-annoying).

You can think of it as if you are booting into Windows Recovery Environment (which is a kind of WinPE) and enter things in the command prompt (before you hook to a specific installation of Windows and log on as a specific user if applicable). Whatever that won’t work in WinPE/RE, you shouldn’t put it in the ‘Machine’ section of post-setup either.

Like you don’t want to install Microsoft Office through that minimal Windows scaffolding (WinPE), the ‘Machine’ section is not where you manage things that interacts with the user.

Keep the ‘Machine‘ section to the minimal and restrict to things that you fully know what are the implications of what you are doing. ‘Machine‘ is a place for you to enter things that you’ll run into a chicken-and-egg problem if you don’t do it before an user account is established/active. Don’t use this section if you don’t have to.

Say, it also doesn’t hurt to move HKLM (Machine-wide) registry operations to the User section (doing it from an user account) as long as that account has administrative privileges. More things can go wrong when you run operations before the system even has an active account.

User refers to what goes on after a *user* account is established. It’s like logging into your account (like Administrator) and start running programs there. If you’d install that program or run that command after you logged in as a user if you were to do this unautomated, this is the section where you should put in such commands.

User interface

The UI of post-setup is easy to miss/misunderstand. It’s very badly organized that it will lead people to do the wrong thing and land in cryptic errors or produce output images that doesn’t behave the way they anticipated. It’s another one of the design choices that’s convenient for the programmer, miserable for the user.

This clumsy UI design encourages the users to randomly dump the commands/programs with no regard to the distinction between ‘Machine’ and ‘User’ sections onto the Post-Setup page. For ages I thought programs go to the top and commands go to the bottom!

This is actually how the UI is structured: you are editing the page like a spreadsheet in Ribbon-enabled Microsoft Excel, not going through an installation wizard!

NTLite subdivide the post-setup screen into two halves (tables).

What’s so clumsy about this is that they don’t let you double click and add a new text command entry in the relevant sections (machine vs user) yet they let you drag and drop files into the sections! You also cannot drag-and-drop (move and insert) lines and you have to rely on “Move Up”/”Move Down” button. That’s the shortcut I’d take if I’m in a hurry to rush the program out to meet a hard deadline and there’s only 24 hours in a day, but yuck!

What even made less sense is that you can highlight a like and hit delete, yet you can’t right click on the line for a context menu to remove it. Instead you have to look for the ‘Remove’ button in the ribbon if you wish to delete a line with your mouse:

This goes the same with ‘Select All’, which the shortcut Ctrl+A works so I never paid much attention to the ribbon bar, which caused me to overlook the distinction between the two tabs for ages!

To add text commands, you have to use the ‘Add’ button from the ribbon, but you have to watch out which tab you are in (circled in the screenshot above with the matching color code)! The ‘Add’ in ‘Task – Machine’ tab looks exactly the same as ‘Task – User’ tab except the ‘Reset’ button says ‘(Machine)’ instead of ‘(User)’! WTF. This logically make sense if you are editing an Excel spreadsheet, except that we aren’t! It defies user expectation that it’s a step-by-step wizard, not a config file editor!

This means if you click on the ‘Add’ button from the wrong tab, the entry goes into the wrong section. Guess what? People tend to go with the first thing they see without reading every detail so every text command tend to go to the top half, which is the ‘Machine’ section! WTF.

It’s a terrible design that’d makes structural sense to the designer trying to save the work of ‘double-click and type’ UI by squeezing the clumsy menu-button ‘Add/Reset’ mechanism into the Microsoft Ribbon paradigm! You don’t want the ribbon tabs to look almost identical and use the tab for the ‘state’ information (in this case, the state info is “This command refers to the Machine section or it refers to the User section?”). It’s just setting the user up for failure.


I think it’d make more sense to simply split Post-Setup into two pages: Post-Setup (Machine) and Post-Setup (User), which the timeline accounts for the order of execution. This is the least-effort path from the developer’s perspective and it will promote the discussion about the difference between Machine and User sections which is essential to make sure the output works (or works as intended)!

The UI design in NTlite’s Post-Setup sucked so hard that we might as well be better off just editing a text cmd file where the user can drag and drop a file into the text editor for the full path. Then have a cmd file massager/transfomer/parser that strips the source paths and copies the files into a vault sources\$OEM$\$$\Setup.

If it’s a powershell script, just add a banner that tells user to call powershell.exe (first token) and have the path of the script as a parameter. I learned the hard way that NTlite isn’t doing anything to bypass Microsoft’s new hardening that doesn’t allow powershell scripts to run by default. So the UI adds no value to powershell script handling either, as I had to run this in Post-Setup before anything else to add powershell scripts to Post-Setup to actually get executed:

reg add "HKLM\SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell" /t REG_SZ  /v ExecutionPolicy /d "Unrestricted" /f

The present UI design for Post-Setup is simply counterproductive! All it does is to add constraints to pretend to have a structure where the structure adds no benefit to the use case. This would be one of the least effort path for the developer if somebody argue that it’s beneficial to put the ‘Machine’ section and ‘User’ section on the same page. At least people know why there should be two sections and they are not fungible!


Getting Quickbooks Pro 2019 to work on Windows 10 21H2

Turns out there’s two hurdles to launching Quickbooks as they used some old Windows dependencies

  1. Internet Explorer needed for DLL/ActiveX/DCOM
  2. XPS Writer needed for PDF libraries

In later versions of Windows 10, IE11 was turned off by default, and 21H2 made it difficult to re-enable it by hiding it from Windows’s (optional) features checkboxes, so it needs to be enabled through command line.

If you do not enable Microsoft’s XPS Writer feature, you’ll get this error message about PDF on start, though XPS is Microsoft challenger to PDF so they are not the same thing


Internet Explorer 11 on Windows 10 21H2

Microsoft has disabled Internet Explorer on later versions of Windows 10 as they really want people to use Microsoft Edge. However, disabling Internet Explorer 11 might break some software such as Quickbooks 2019, which relied on old fashioned DLLs.

Since 21H2, Microsoft went the extra mile preventing users from re-enabling Internet Explorer 11 by hiding it from GUI ways to turn Windows features on or off (whether you use the app mode interface or the classic optionalfeature.exe interface launchable from control panel’s “Programs and Features”). Instead this needs to be enabled from the command line


dism /online /Add-Capability /CapabilityName:Browser.InternetExplorer~~~~


dism /online /Enable-Feature /FeatureName:Internet-Explorer-Optional-amd64.


Windows shortcuts to less easily accessible config pages

Control panel has a lot of kinda-secret calls that open specific configuration windows that it’d be difficult to get to (need many clicks from other windows) and they might not necessarily have a path that you can access normally when Microsoft discourage their uses. Sometimes it’s just a phrase, sometimes it’s a .cpl in Windows’ system folder, yet sometimes you can call a .cpl that does not exist at all yet the control panel recognizes it.

Here are some examples

control userpasswords2 opens a dialog box to manger user accounts more directly without going through MMC’s user management (typically Local Users and Groups within compmgmt.msc Computer Management). It’s also netplwiz

It used to be valuable way of managing autologon until Microsoft Removed the checkbox “Users must enter a username and passwords to use this computer” because it doesn’t make sense with their freaking vision of Windows Hello where you logon with biometrics or other ways that you’d do with your cellphones. They are trying to make passwords a thing of the past.

Autologin in windows 10 without password!
Credit: Auto login in Windows 10 without password? (softwareok.com)

control sticpl.cpl opens up Scanner and Cameras

I picked this shortcut up from the README file of Network TWAIN Driver installer, which plug and play doesn’t make sense because the device is on the network so there’s no hardware to detect. Instead you add a scanner device manually and enter the connection information in its properties.

The interesting thing about this one is that sticpl.cpl do not exist! There’s no control panel file (.cpl) anywhere in the system drive!

There are more information from Microsoft about these commands.

Lifewire has a better formatted table with additional alternative commands

With Powershell, you can get the canonical names of major control panel items and use it with control /name switch

This blog page has a cheatsheet for Windows direct commands, presented in the way Linux people rolls

You can even unhide some .cpl files through registry!