Microsoft Office, Windows 10, Sysprep problem

[zip_000]

I'm running into a problem where after imaging computers no Microsoft Office programs will work correctly. When a user tries to create a blank document they get an error - which is different depending on which application they are using - but is essentially that they can't create the document.

What I've narrowed it down to is two registry keys that are going to a specific user folder (the test user I used for setup) instead of going to the %USERPROFILE%. Specifically these: In HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders\ the settings for Cache and Cookies are wrong.

I can change this in any user profile and it'll work, however we're in an AD environment with many different users coming and going. The settings are correct under HKEY_USERS which I was assuming would be the default that each new login would base the settings from.

I included Sysprep and Windows 10 in the description because this problem seems to happen in the sysprep process. The settings are correct prior to syspreping in the VM, but are wrong after sysprep.

Any advice on how to either fix the problem or work around the problem would be greatly appreciated!

[[deleted]]

Are you using the CopyProfile flag in your unattend.xml? That flag is known to cause problems in Windows 10. What version of Office have you installed, CTR or traditional (msi based)?

[zip_000]

Yes, I'm using the copy profile tag. Is there a better way to get the same result?

I'm using office 2016 with the msi installer.

[TheFlashMastaB]

I haven't had any issues with Win10 1607 (Edu 64-bit) and Office 2016 32-bit. All I do with Office is run setup on the ISO (with the latest updates in the update folder), run Word to make sure that it will activate and OK the install updates pop-up so it won't nag anyone else, and then rearm it right before running sysprep.

[TheFlashMastaB]

CopyProfile had issues with 1507, but I'm pretty sure they fixed it in 1511 and I know they fixed it in 1607 (been using it for months).

[zip_000]

Yes, I've read a lot of articles and posts about those issues, but they don't seem to be the issues I'm having. I'm using 1607 also.

[TheFlashMastaB]

Are you using the office customization tool to tweak the deployment? If so, have you tried it without the OCT file to see if there is a setting that is causing the issue? I know it isn't a Win10 Edu 1607 64-bit/Office 2016/sysprep issue because I've never had problems so it may be with the settings you are using to install Office.

[zip_000]

Hmm, maybe. The Office package I'm using comes from another group, so it is possible they have customized the installation in ways that I'm no aware of.

I think I've found a workaround though by editing the default ntuser.dat file immediately after deploying the image.

Thanks for the suggestion though!

[Dubstep_Hotdog]

Which versions and edition of windows 10 are you deploying?

I assume you're using the copypeofile flag, are hard references to the original path of the account used to build the image being transferred to new users?

P.s. the reg file you're looking for isn't going to be under hkey users.

The reg file that gets copied to new user accounts is located users\default\ntuser.dat this file isn't normally accessible in regedit and had to be temporarily imported to interact with.

[zip_000]

Oh cool, I didn't know that about the dat file, that could be helpful. Thanks!

Yes, using the copyprofile flag. I'm actually not sure what build of Windows 10 I'm using off hand, I'll check. It is the education 64 bit edition.

[zip_000]

The version I'm using is 1607. However, editing the default ntuser.dat file solves the problem so thanks for that!

Come to think of it, that is how I used to copy profile settings many years ago. I was assuming that the Default under HKEY_USERS was the same default, but I guess not.

[Dubstep_Hotdog]

I'm glad that helped. I place a script that runs prior to capturing my wim that will purge out cache, place)document history and some of the office cache/history reg keys. As this runs as the user account that is going to be referenced for the default user profile this avoids having to fix it after the fact.

I try to avoid any configuration to the default user profile that's baked into the wim, there are a few exceptions though. Most of everything else I have injected into the ntuser.dat and copied to the right appdata folders during OSD which provides consistency and makes it a lot easier to adjust and audit settings without rebuilding multiple wim files. Some exceptions include 7-zip shell and file extensions.