Create media for automated unattended install of Windows 10  

Hi All. New on forum. Working on a clean sysprep going windows 10 1809. With answer file copyprofile = true.
I too spent way too much time dealing with the 'default app was reset errors' upon new users being created.

microsoft's provides copyprofile instructions to delete the three keys:
HKEY_USERS.DEFAULT\Software\Microsoft\Windows\Shell\Associations\FileAssociationsUpdateVersion
HKEY_USERS.DEFAULT\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts
HKEY_USERS.DEFAULT\Software\Microsoft\Windows\Shell\Associations\UrlAssociations

HOWEVER, i realized that the FileExts key comes back after sysprep begins. I have been deleting this key immediately after sysprep is kicked off. haven't received these errors since. I hope others can confirm that this is a consistent solution/workaround.

@Taly,

Welcome to TenForums!

I have not tried your workaround, I've always simply ignored those "default app was reset" errors and have not seen any negative results. However, just in case you are interested, I've noticed that I no longer get those messages with Windows 10 version 2004.

I know that this is not the version that you are working with, but thought that I would let you know.

Hey guys.
Because I am new to this forum, first of all I would like to thank you all for all the great job you are doing here. The tutorials from Kari where a big help for me in making my first unattended installation. But unfortunately I have a problem that for days I can not solve and maybe you have some solution that can help me further.
I made an unattended installation, according to the instructions provided here, from an Win10 Enterprise Build 1903 (in german language). Everything went well after a couple of times and I've successfully created a bootable ISO image containing the customized install.wim, autounattend.xml (in the root folder of the windows image) and also unattended.xml (stored in C:\Windows\System32\Sysprep\). I configured my image to allow the build in Administrator account to be enabled with a hidden password. I have successfully installed this image on a real computer as well as on a VM. When I login to the Administrator account everything looks fine and I can access the System Settings and so on. And now comes my problem: when I create a new user (without administrative right) the System Settings and the Search Bar are somehow disabled or not working anymore. I have tried multiple times and every time is the same problem. In order to exemplify what I mean I have attached the System Settings view for a User and for the Local Administrator. I am looking forward for your advices on what might the problem be. Thanks a lot!

Wow! I've duplicated the problem that you are seeing but on Win 10 Pro 2004.

My sysprep install creates an admin account named "WinUser". I logon to that account and create a new standard user account. If I then logon to that new user account, I see the same problems that you are seeing.

That's a pretty major issue.

I have not caught this issue before because I normally only have been creating admin level accounts.

I have one question for you: With your configuration, are you using a first-time autologon and / or auto logoff? I'm just wondering because that is the only difference in my setup compared to what @Kari is doing in his tutorial.

I'm going to do some additional testing. Will post results when done.

Thanks a lot for your interest and the quick answer @hsehestedt. I am also really surprised that this happens and, as by you, I did not noticed the problem in the beginning when I used only the Administrator account. To answer your question: in my unattend.xml, I've set the Autologon Password for the pass="oobeSystem". So, after the customized ISO image is installed on a new machine it will boot to the Administrator account directly. Beside the Administrator account, in some of my attempts to figure out what is going on, I've set up also a normal user account to see if it helps. Unfortunately, in my case it did not and I registered the same behavior as described above. The auto logoff option I did not set it and to be honest I don't know where it is. Thanks a lot and if you require any xml files please let me know and I will gladly share them.

John, I do NOT enable the "Administrator" account. I'd have to look into this further but I had thought that one was specifically NOT supposed to do that. Instead, I create a seperate admin level account. After installation, if I want to enable the built-in Administrator account I can do so. I had thought that sysprep automatically disables the built-in admin account. Anyway, that's a test for another time.

In the meantime, I ran another test with interesting results.

I started the installation of Windows and entered audit mode exactly as Kari's tutorial prescribes. I made no changes or customizations to Windows at all other than installing the VMware tools. I performed the remaining usual steps (creating folders for imaging, creating the runonce.bat, putting the answer file in the correct folder). I finally imaged the system, created new boot media with that image, and installed Windows.

This time, creating a new standard user account and logging in with it worked just fine. That tells me that either one of two things is likely the source of the problem:

1) The customizations that I made to Windows
2) The autologon / autologoff functionality that I am using is not working as expected or interfering somehow.

Next test: I'm going to make the exact same customizations that I usually make, but leave off the autologon / autologoff.

Fortunately, it's easy for me to exactly reproduce my changes because all my changes are applied via a batch file that automates everything.

Once again, I'll post the results here soon.

Tried another couple of installs and cannot reproduce the problem. I did this on another system this time. The first system was a laptop but when I'm digging in for a long stretch of testing it's way more comfortable to be at my desktop system so I switched over to it, but of course, now I can't recreate the issue.

There are times where I really hate computers.

Anyway, will do more testing but it's going to be slow going. May be tomorrow before any further updates.

Okay, I have the pattern figured out, but the more I think about it, the more I think that this may be expected behavior.

I know that you are NOT supposed to configure the account named "Administrator" in your answer file. You should create a seperate admin level account.

With said, here is how this plays out:

Scenario 1

Create an admin account in unattended setup that is not named "Administrator".
After Windows is installed, logon with that account and create a new user account. This account can be either a standard user or an admin account. That new account will work fine.

Scenario 2

Create an admin account in unattended setup that is not named "Administrator".
After Windows is installed, logon with that account and enable the "Administrator" account.
Logout, then logon as "Administrator".
Create a new user account. This account can be either a standard user or an admin account.
That account will experience the problems with settings and the search box.

Some other observations:

Observation 1: In scenario 1, after you you create a new user account and logon with that username, you will see a quick succession of messages such as "Hi", followed by "We're getting everything ready for you", etc. In scenario 2, after the the message "We're getting everything ready for you" is displayed, the screen will go black and stay black for a good minute or two.

Observation 2: After creating a Reference system and running sysprep, you boot the system from alternate media such as a Windows boot disk or image in order to image it. If you skip that step and just allow the reference system to boot normally, it will behave the same as that image would behave so in testing with this issue you can save a lot of time by not bothering with the imaging.

So the workaround is simple - don't use the built-in account named "Administrator". I do know that the admin account created via your answer file should NOT be the account named "Administrator", but I was not aware that enabling the Administrator account later would be a problem.

Will research further.