[1909, ou] Office apps not responding

[Sheridan]

Got a really odd problem developing at a primary, all running windows 10 1903 that was upgraded in place from 1607 due to licensing being oem keys only on the PCs. This update was done some months ago.

 

Basically we did the in place upgrade, installed office 2016 and all seemed good. However we are now seeing major problems as anyone who is NOT an admin can’t actually use Word, excel etc as when they start it, it goes into ‘not responding’ pretty soon. Sometimes you can type a word or two but it always freezes.

 

When you login as an admin all works as expected, office apps open fine and show as activated, log back in as a teacher account and word etc will hang. I’ve also noticed the login times for these accounts seems a lot longer, even though they don’t have a lot of group policies applied and nothing has been changed. Another oddity is that some of the desktop icons take a long time to change from a white square shortcut to what they actually are, internet explorer link for example.

 

I’ve checked all the usual, making sure dns is all good and nothing is being mapped or directed to a dead path. What I don’t understand is why it’s happening to non admins only, suggesting it’s a policy problem but nothing has been changed in months.

 

Assuming a policy problem I moved a test non admin user to an OU with no policies and it was exactly the same! So now I’m baffled as the only other difference now between an admin and a non admin is their rights on the local PC and the smooth wall filtering they receive!

 

Anyone got any inspiration as I’m heading toward a full reimage of a lot of pcs, a pain as we have to use oem keys!

[Sheridan]

Well it looks like a rebuild, the Application event is chock full of events like this:

 

StartMenuExperienceHost (1992,R,98) TILEREPOSITORYS-1-5-21-1649468332-2773550204-2569608857-1406: An attempt to open the file "C:\Users\\AppData\Local\TileDataLayer\Database\EDB.chk" for read / write access failed with system error 5 (0x00000005): "Access is denied. ". The open file operation will fail with error -1032 (0xfffffbf8).

 

and lots of these:

 

taskhostw (9064,U,98) WebCacheLocal: Database recovery/restore failed with unexpected error -1907.

 

and thse:

 

taskhostw (9064,R,98) WebCacheLocal: An attempt to open the file "C:\Users\Administrator\AppData\Local\Microsoft\Windows\WebCache\WebCacheV01.dat" for read / write access failed with system error 5 (0x00000005): "Access is denied. ". The open file operation will fail with error -1032 (0xfffffbf8).

 

The above error is odd, as its referring to the local administrator account, even though its a non admin account logging in.

 

I used to hate windows 10, now I simply expect rubbish like this.

[chazzy2501]

Why don't you sysprep a machine and see if it helps it might be slightly less work!

[Sheridan]

Odd, when I delete the web cache folder in the above administrators profile path it all seems to work. To me that’s a pretty dodgy bit of coding as I fail to understand why the local admins profile is being access when another user logs in!

[Arthur]

Odd, when I delete the web cache folder in the above administrators profile path it all seems to work. To me that’s a pretty dodgy bit of coding as I fail to understand why the local admins profile is being access when another user logs in!

What sort of profile are you using on these PCs and how was it created?

 

This issue sounds like the sort of thing that happens when you copy a profile and don't remove all of the references to the source account in the new profile. e.g. when creating a mandatory profile.

[Sheridan]

What sort of profile are you using on these PCs and how was it created?

 

This issue sounds like the sort of thing that happens when you copy a profile and don't remove all of the references to the source account in the new profile. e.g. when creating a mandatory profile.

 

These are local profiles, no roaming or mandatory profiles. These particular PCs came with W10 pro on, and were simply in place ugraded due to OEM licensing. The local admin account was probably only used for the initial setup and domain join and that was about 2 years ago!

[Duke5A]

Well it looks like a rebuild, the Application event is chock full of events like this:

 

StartMenuExperienceHost (1992,R,98) TILEREPOSITORYS-1-5-21-1649468332-2773550204-2569608857-1406: An attempt to open the file "C:\Users\\AppData\Local\TileDataLayer\Database\EDB.chk" for read / write access failed with system error 5 (0x00000005): "Access is denied. ". The open file operation will fail with error -1032 (0xfffffbf8).

 

and lots of these:

 

taskhostw (9064,U,98) WebCacheLocal: Database recovery/restore failed with unexpected error -1907.

 

and thse:

 

taskhostw (9064,R,98) WebCacheLocal: An attempt to open the file "C:\Users\Administrator\AppData\Local\Microsoft\Windows\WebCache\WebCacheV01.dat" for read / write access failed with system error 5 (0x00000005): "Access is denied. ". The open file operation will fail with error -1032 (0xfffffbf8).

 

The above error is odd, as its referring to the local administrator account, even though its a non admin account logging in.

 

I used to hate windows 10, now I simply expect rubbish like this.

 

This is a pretty big clue. If I had to guess somewhere during the upgrade process the local admin account was used as a template and copied over the default user profile. You used to do this by setting the setting in the sysprep XML to true.

 

Whenever a new local profile is created on a client the default profile is used as a template. It's located here: c:\users\default\ntuser.dat

 

This can be fixed relatively easily. In regedit, you'll have to load registry hive from the default user profile, search for that path, delete the value of that key and unload the hive. This will fix the issue for users that don't already have a profile on that specific client. For existing users, you'll need to do the same thing for them, but won't need to mess around with loading/unloading hives. This will by located under HKEY_CURRENT_USER somewhere.

 

Clear as mud, right?

[Sheridan]

This is a pretty big clue. If I had to guess somewhere during the upgrade process the local admin account was used as a template and copied over the default user profile. You used to do this by setting the setting in the sysprep XML to true.

 

Whenever a new local profile is created on a client the default profile is used as a template. It's located here: c:\users\default\ntuser.dat

 

This can be fixed relatively easily. In regedit, you'll have to load registry hive from the default user profile, search for that path, delete the value of that key and unload the hive. This will fix the issue for users that don't already have a profile on that specific client. For existing users, you'll need to do the same thing for them, but won't need to mess around with loading/unloading hives. This will by located under HKEY_CURRENT_USER somewhere.

 

Clear as mud, right?

 

Yeah - these aren't the normal way we'd set PCs up to be honest , but the school doesn't have an EES agreement so the PCs were simply booted with their OEM Pro image on. The administrator account was then used to join to the domain and a few standard applications installed and that was basically it, and they worked fine for a couple of years like this (albeit with classic start menu installed)

 

This problem only occurred since we did an in place upgrade to 1903 - no profiles were copied or anything like that, just a simple upgrade really.