Problems With Default Ntuser.dat

[Björn Kaiser]

Hi, i hope some of you have an idea which can help me with my problem.

I'm using unattended.sf.net to install Windows XP unattended. Within the process past the Windows installation, I'm running a AutoIt-Script to modify the Registry of the already created users and the default ntuser.dat. My problem is, that my changes to the ntuser.dat don't seem to be all copied to the new users i create, after running the registry modifying script, with net user /add.

I use reg.exe to load and unload the ntuser.dat. Should that be the problem or could it be access restrictions? (although the created and modified keys in the ntuser.dat have at least "everyone" set for read access)

I know this is not totally AutoIt related, but maybe someone can kick me in the right direction.

I have really no clue what's happening here.

[PsaltyDS]

Hi, i hope some of you have an idea which can help me with my problem.

I'm using unattended.sf.net to install Windows XP unattended. Within the process past the Windows installation, I'm running a AutoIt-Script to modify the Registry of the already created users and the default ntuser.dat. My problem is, that my changes to the ntuser.dat don't seem to be all copied to the new users i create, after running the registry modifying script, with net user /add.

I use reg.exe to load and unload the ntuser.dat. Should that be the problem or could it be access restrictions? (although the created and modified keys in the ntuser.dat have at least "everyone" set for read access)

I know this is not totally AutoIt related, but maybe someone can kick me in the right direction.

I have really no clue what's happening here.

Well, first off of course, you need at least modify - not read - access to change the keys. You could also have your changes undone by overriding local or domain policies, but I don't think that would change the user.dat, just the effective setting while they were logged on.

Your post sounds as if some changes took and others didn't. Is that the case, and have you checked perms on ones that worked and ones that didn't? Are you only looking at effective settings while the user is logged on, or seeing actual reg keys that didn't change, or keys that changed and then got reverted?

[Björn Kaiser]

Well, first off of course, you need at least modify - not read - access to change the keys. You could also have your changes undone by overriding local or domain policies, but I don't think that would change the user.dat, just the effective setting while they were logged on.

Your post sounds as if some changes took and others didn't. Is that the case, and have you checked perms on ones that worked and ones that didn't? Are you only looking at effective settings while the user is logged on, or seeing actual reg keys that didn't change, or keys that changed and then got reverted?

The thing about read-access is what i got from the MS KB, regarding the process which happens when a new user is created. The article i read said, that the new user has to have at least read-access (obviously) to copy the settings to the new profile. The automated installation after the initial setup of Windows run inside the Admin account (so I think, I should not have problems with the permissions).

For the permissions: I loaded the default ntuser.dat into regedit and looked at the permissions for the key which failed to be applied. It was readable to everyone and my change was applied.

And that is what im irritated about. As far as I understand it, if I edit the default ntuser.dat, all changes made in there should be applied to all users HKCU which are created after that.

[MHz]

I use Cmdlines.txt to apply a reg file full of changes, which apply to each new user HKCU creation. Some user settings such as theme settings may not be accepted, but all of the important changes that I want do. Installations and settings from Cmdlines.txt execution, will be shared amongst all the HKCU user accounts.