VMware Horizon Community
alsmk2
Hot Shot
Hot Shot

UEM Import Errors

I'm having a re-occurring issue that I'm struggling to get to the bottom of. When users log on to UEM, the log files fill with various "Access Denied" errors. For example:

[ERROR] ImportFiles::ImportFile: Access denied on 'AppData/Microsoft/Word/ExampleFile.asd'

If I check the location from the desktop, UEM has imported the files it is claiming it couldn't. This seems to happen on random files.

The users in question have full access to their UEM profile, and everything in their user profile on the local desktop. UAC has been disabled via registry to rule that out. Event Viewer on the rdsh servers shows no issues during logon /logoff.

UEM: 8.7

Desktop: RDSH 2012 R2

Has anyone come across this before?

Reply
0 Kudos
10 Replies
Pim_van_de_Vis

those .ASD files are Office Autorecovery files. Does it only show the errors on those files?

Maybe it's because those files are locked, or being deleted the same time UEM tries to import/export them.

Reply
0 Kudos
alsmk2
Hot Shot
Hot Shot

It does seem to be similar files coming up, but not just temp word ones. At the moment it appears to be Word and Excel temp files, pinned taskbar items, and a folder containing ICOs (the last one has been configured as a UEM task under the Files / Folders section, so in my mind, should definitely not cause errors).

The errors only happen at import, so I can't see how it could be down to a file lock when it has to export it from a UEM zip file; however, I can't find a way to confirm this one way or another. The only Access Denied error comes from UEM. There doesn't seem to be any other trace of an issue with the referenced files (event viewer on the RDSH or UEM FS shows no locks, the files aren't already listed as open on the UEM File Server, and for all intents and purposes, the files appear to import correctly).

I'd normally assume this is a bit of a red herring due to the import appearing to be successful despite the errors, but at this site we're seeing some strange issues with UEM, so I'd like to rule it out.

Reply
0 Kudos
Pim_van_de_Vis

What kind of profiles are you using on the RDSH hosts? Mandatory?

Reply
0 Kudos
piratefan
Enthusiast
Enthusiast

Did you ever find a solution to this issue?  I'm having the same issue. 

thanks.

Reply
0 Kudos
Pim_van_de_Vis

Can you share a complete UEM logfile, that might give me some more clues what's happening. Could also be in a private message.

Reply
0 Kudos
alsmk2
Hot Shot
Hot Shot

I'm afraid not - support never got anywhere with it either.

As it seemed to be purely cosmetic, and the files referenced were accessible and importing/exporting correctly, we just left it I'm afraid Smiley Sad

Reply
0 Kudos
Pim_van_de_Vis

Could this be related to anti-virus? Have you implemented the exclusions for UEM?

They are described here:

Imports and exports in VMware User Environment Manager are slow (2113665) | VMware KB

Reply
0 Kudos
alsmk2
Hot Shot
Hot Shot

I don't think so - I also tested this against a server with no AV.

One thing I didn't mention was that in our situation we were using a mandatory profile stored on a network location with the profile path set in GP. Some of the files referenced in the errors had at some point managed to work their way into the base profile as the permissions on it were too lax. Tightening up the permissions, setting the GP to prevent changes from propagating to the profile, and removing the referenced files from the profile resolved quite a few of the errors. However, the office auto save files still cause errors on a regular basis, and are definitely not propagating down to the default mandatory profile.

Assuming you're using a mandatory profile, maybe have a check of your profile and make sure it is set up correctly?

Another suggestion from VMware support was to modify the profile state to spoof an admin account. This didn't have any effect for us, but it may be something you can also try:

http://www.htguk.com/profile-state-emulation/

Reply
0 Kudos
Pim_van_de_Vis

Yep, that was one of my thoughts as well. Using a mandatory profile can cause this.

And an 'access denied' message if pretty straight forward: check your permissions, because something is preventing a write.

To rule out the Mandatory profile, test with a regular local profile and see if the issues are gone.

If you do want to use a mandatory profile, make sure to set it up correctly. The supported way is pretty technical and should be done correct.

See these blog posts for guidance:

https://blogs.vmware.com/euc/2017/01/vmware-user-environment-manager-mandatory-profiles-part-1.html

https://blogs.vmware.com/euc/2017/01/vmware-user-environment-manager-mandatory-profiles-part-2.html

Reply
0 Kudos
ajvioland
Contributor
Contributor

Also.......would these only come up upon login?

Reply
0 Kudos