Unattended install: Account is duplicated under C:\Users

C

chrcol

Member
Was diagnosing why an app didnt install during installation. I did find the reason, however. I have this problem.

So under C:\Users

Chris
Chris.DESKTOP-68TP2BF

The second account has machine id attached to end of it.

%userprofile% takes me to "Chris.DESKTOP-68TP2BF" however if I install a new app that installs to user profile, the app appears in "Chris".

Chris has the earlier creation date.

I only see one actual account created correctly called Chris.

HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders registry is using Chris.DESKTOP-68TP2BF
 
This is expected. Don't create any user folders before Windows runs new user provisioning (right after OOBE exits).
Which means no overlapping folder names created by $OEM$\$1\Users, or by Post-Setup commands.

To avoid name collision during provisioning, Windows renames any C:\Users\Account folder it finds to Account.[Desktop name]. This is a safety mechanism to guarantee each new user has a known profile.

The correct way is to update the Default User's profile, and hope W10/11 copies its values to your new user profile. Default User's folder always exists, so there's no risk in modifying it. Some HKCU mods will be actively blocked by provisioning (or overridden).
 
Is importing a registry with HKCU potentially causing this then?

I just switch that to default user and it should avoid the early folder creation?

I also have currently 3 post setup user commands.

Thanks, I will probably figure it out with what you told me, pretty sure it was working on one of my older presets so makes sense.
 
Last edited:
So previously HKCU was expanding to both User - System and User - Default.

Now HKEY_USERS\.DEFAULT just expands to User - System, was expecting User- Default.

I read in another post you said post-setup runs after OOBE, so if its these registry files, not sure what it is, but if the problem persists I will also try removing all user post-setup's. Dont think I am using $OEM$\$1\Users unless thats from %WINDIR%\Setup\FilesU
 
Last edited:
Ok so the good news is, duplicate folder is gone.

I initially thought failed, but after reboot the settings work, and in registry is ok, so NTLite reporting it going to system instead of default was only issue.

I also am diagnosing missing command prompt on context menu (set using the built in ntlite settings tweak), it was there when I tested earlier in the week probably about 4 revisions ago on my presets )all the preseets are saved as well as separate isos, so will see if I can nail down which preset broke it), I think when these last niggly issues are done with I will be happy with this image.

I will leave the changes attached.
 

Attachments

  • 7tt-default.reg
    6.1 KB
  • 7tt.reg
    6.1 KB
Last edited:
You're trying to solve this problem wrong.
7+ Taskbar Tweaker belongs to that annoying category of portable apps, when there isn't a real reason to stay portable.
Code: 
[HKEY_CURRENT_USER\Software\7 Taskbar Tweaker]
"install_dir"="C:\\Users\\Chris\\AppData\\Roaming\\7+ Taskbar Tweaker"

Fortunately, there's support for installing it to a "normal" location.
Code: 
7tt_setup.exe /S /D=C:\Program Files\7+ Taskbar Tweaker
Code: 
[HKEY_CURRENT_USER\Software\7 Taskbar Tweaker]
"install_dir"="C:\\Program Files\\7+ Taskbar Tweaker"

After switching to a shared folder -- you can provide a generic HKCU reg file to Post-Setup (User).
 
Ok there is a better way to install it, exporting the install dir as a setting wasnt intentional, I was just meaning to install the other settings.

However that registry is actually working fine now, I just had to reboot for the settings to kick in (signing in and out wasnt enough). 7tt is installed itself on the user execution queue (machine failed i assumed due to it using the user profile folder).

I have now decided to move registry imports back to a post install batch file, it just seems more reliable, as there is also some registry keys that seems to get overwritten for the user later in the install process (even in post-setup user), I only started experimenting with registry imports on ntlite to try and fix the tamper proof problem which didnt work anyway. Originally it was just silent installers and a few commands for things like the remote desktop firewall rule, disable default standby mode, that sort of thing. 7tt was the only installer I had to move to user execute, although I assume changing the install path would allow it to work under machine queue.

So now 7tt will be installed with no registry keys on the post-setup command, and then after I am at the desktop i run my batch script (the install_dir part is now excluded).

As an example one visual effects key doesnt stick when added with ntlite via reg file, likewise with making app interface default to dark mode. I am guessing windows runs some setup stuff for the user after that stuff is processed by ntlite.
 
Dark mode or theme settings are clobbered by user provisioning. Import in Post-Setup (User).
 
garlin said:
Dark mode or theme settings are clobbered by user provisioning. Import in Post-Setup (User).
Click to expand...
That didnt work, still seems to be run too early.

But its fine, I have a batch file I run anyway so having the command in there to import it isnt the end of the world.
 
Theme and personalization settings can be handled much easier if you change the reg key that installs the Aero theme. It's actually the installation of the Aero theme itself that causes a lot of the personalization settings in Windows to get changed, because the theme doesn't get installed until you can reach the desktop for the first time, and it installs on every account created thereafter too, so we have to prevent that behavior.

I tried all the methods for tweaking themes, including making my own theme file, and the reg key was by far the cleanest and best route. Rarely have I come across a situation where a tweak cannot be integrated into the image, sometimes you have to figure out the root cause and fix that:
; Start > Settings > Personalization > Themes > Custom
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Themes]
"InstallTheme"=""
"InstallThemeLight"=""

; Start > Settings > Personalization > Themes > Custom
[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Themes]
"InstallTheme"=""
"InstallThemeLight"=""

The same is true of the Visual Effects, don't use the traditional routes if you want to integrate it for all users. Check out the following thread for insight into a totally different approach that addresses visual effects at a higher level in the registry (link).
 
Last edited:
Well command prompt seems fine, I just realised ntlite only implemented via shift and right click, not the admin prompt with basic right click menu.

I have seen that visualfx file somewhere before, but was turned away from it when users reported it merely ticked or unticked boxes without changing actual settings, however I just tested it manually and it does actually seem to toggle the defaults so is worth using thanks, as I tested it ok.

In terms of the other stuff, I havent seen if ntlite logs what is happening during the install process, and things like aero theme being applied at end of first login could only be figured out if you already know what windows does on logon, which I dont as i havent seen it documented.

So my question is, what is the repercussions of importing that theme registry key, the default is set to aero.theme or light.theme for light theme. The default must be there for a reason, I try to learn about things before using them, thanks.
 
Last edited:
You must log in or register to reply here.
Back
Top