As I have written in my last post UEM is a game changer in the way how we can create great VDI solutions.
Having worked a lot with VMware’s User Environment Manager (UEM) within the last month I saw many errors made and occurring during the installation phase.
Even though the the installation is quiet straight forward, some minor mistakes can happen from time to time. I am going to summarize which symptoms might occur, how to check to gather further information and what most possiblely has caused the malfunction.
At the moment the post is focusing on the Active Directory Group Policy based installation & configuration within UEM. The newest version 9.1 allows us to it also in a non-ad way. If demand is there, I can add a section for that topic as well.
I am not going to cover the basic installation steps. Chris Halstead did a great job on that topic (and for all the things he worked on [flings, blogs, etc.]).
Please use that one for the basic installation tasks and come back to this post if you need to troubleshoot further ;-) With the following list you can fix 98% of the problems that might occur during the UEM installation ;-).
The log-file within UEM is pretty valuable. Make sure to configure it initially when setting up UEM. A log-level value of info is enough for daily usage.
To increase the log-level for a specific use-cases or a specific user just add a file (make sure you show the file endings) called flexdebug.txt to the folder where you log-files are created.
After a logoff and logon the log file includes debug data as well:
[Active Directory based installation / configuration]
UEM seems not to work. After the login of a UEM user, no Folders of the users are created on the profile-archive share.
Potential root causes:
During log-on the UEM FlexEngine service starts via group-policy extension and imports the relevant user profile or archive from the defined file-share. Normally during log-off UEM exports the settings back to the file-share (except when DirectFlex is used).
If no single user-folder is created after a logon the following configuration items might have been responsible for it.
- GPO with the UEM relevant settings not applied to the user.
- Incorrect permission on the user profile share.
- Incorrect Config & User profile share location defined within the Group Policies
- UEM Agent not running correctly
- Access to regedit.exe is prohibited
How to verify:
GPO with the UEM relevant settings not applied to the user:
Login with an affected user and run cmd. Within cmd type gpresult /R and verify that the GPO that includes the UEM configuration is being applied.
Fix: Make sure that the UEM configuration is applied to the specific user where UEM should get applied.
Incorrect permission on the user profile share:
Being restrictive with the permissions is really important and can lead to some problems as well. Please verify if you can access and create a folder on the profile share:
If the logged in user cannot manually create folder on the profile-share, UEM will not be able to create this folder as well.
Fix: Check and fix your NTFS and Fileshare permissions:
” Example Name: \\server\UEMProfileData
Share Permissions: UEM Administrators – Change
UEM Users – Change
NTFS Permissions: UEM Administrators – Full Control
apply to: “This Folder, Subfolder and Files”
UEM Users – Read / Execute, Create Folders / Append Data
apply to: “This Folder Only”
Creator Owner – Full Control
apply to: “Subfolders and Files Only”
” (taken by Chris Halsteads set-up documentation)
Incorrect Config & User profile share location defined within the Group Policies
If permissions are right and the UEM GPO gets applied, make sure that the correct data has been configured with the Group Policies.
Make sure the FlexEngine of UEM runs as a Group Policy Extension
For the config file share make sure the path ends with \General. Copy and paste your paths into the windows explorer to ensure that the specified location is valid and reachable via network based file access.
Do the same verification for the User Profile Share. (Leave the %username% section out)
Fix: Enter the correct path settings ;-) (copy and paste is your friend).
UEM Agent not running correctly:
If the UEM Agent is not running (even though all the above mentioned settings are correct) an issue might have happened during the installation. Verify it via services.msc and check for the VMware UEM Service status.
Started –> :)
Stopped –> :(
Fix: In case the service is stopped the best way to deal with it is to uninstall and reinstall the UEM Agent.
Access to regedit.exe is prohibited
How to verify:
Try to run regedit.exe as the user.
Check the log-files of UEM and search for the FATAL messages.
The log-file mentions: [FATAL] Policy prevents access to registry editing tools.
In case you have configured Application blocking for regedit.exe you will find the following message:
[FATAL] Error importing
UEM and the Flexengine use regedit.exe to inject information into the registry. If access to the registry is not possible from a specific user account the whole mechanism will fail. Make sure to allow execution of regedit (via Group Policy and UEM’s Application blocking feature).
and make sure regedit.exe is not configured as blocked application within UEM.
When creating the GPO for UEM the ADMX templates have been imported (e.g. by transferring them to the PolicyDefinitons folder) the UEM settings are not showing up when configuring the GPO and an error message appears.
Make sure to transfer also the language files (en-US) into your domain controller location.
UEM seems not to work. No profile data is stored when logging into a stateless/floating desktop. User folders are created on the profile shares, but with no specific input for the various Windows settings or applications.
Potential root causes:
During logoff the flexengine.exe file must be called with the -s parameter. If that is not the case all non-FlexEngine application data will not be exported at logoff. Since the user folder and the log files were created it is not related to a permission problem.
In a functional environment you can see within the log-file [must be configured via GPO; log-level info or higher] that an export takes place.
If that is not the case and you cannot find any export information, ….
…. check the logout script definitions in your GPO.
C:\Program Files\Immidio\Flex Profiles\FlexEngine.exe Script Parameters: -s
After installation and configuration of UEM a user cannot login to the desktop anymore. After login an automatic logoff appears.
Potential root causes:
A GPO setting has been defined that defines how the desktop reacts if the paths are unavailable at logon.
Make sure that you checked the settings mentioned earlier and check that the ‘always wait for the network at computer startup and logon’ setting is enabled.
I hope this short guide can help you to improve your UEM implementation and gives you some tips and tricks about what you should take care in the future.
17 thoughts on “Let’s troubleshoot User Environment Manager (#UEM) 9.X: How to avoid errors during the installation”
Pingback: VMware User Environment Manager – Carl Stalhood
Great article! Helped in an install I was having trouble with.
I do have a question. On an installation, if a VM is restarted, UEM does not load when logging in. If you logout and log back in again, it works fine. If you restart, it goes back to not working until a logout and login. If you simply lock the workstation, it works fine since it is already up.
Thanks again for the great article.
Glad you could use it. Your problem seems strange. Is something mentioned in the logfile of UEM? You are sure that ‘always wait for network’ is enabled?
Nothing in log file on misses. So to make it more interesting, I did more tests. It is every other time of anything? Restart or log out. When it does not fire, there is nothing at all in the logs. When it does fire, everything is without error on login and out. I do have the always wait for network in the GPO, although it almost sounds like that is the culprit!
What I had to do is make a simple GPO (since our UEM GPO is scoped to user membership). The GPO was simply the “wait for network” on for the logon settings. I caught this with the GPO modeling wizard.
Once applied, it is 100% every time!
Great article……Thanks again!
We are seeing the exact issue, but we are running in NoAD mode, so I don’t think this GPO will make any difference. But can you please clarify what changes you made? You have mentioned in your pervious comment that you already had this GPO, so curious to know what change resolved the issue, in addition to the GPO.
in my lab I have a strange situation: during logoff the “C:\Program Files\Immidio\Flex Profiles\FlexEngine.exe -s ” is not executed
Obiouvsly I put it in User Configuration > Windows Settings > Scripts > LOGOFF
If I execute it manually before logging off, UEM works like a sharm.
Do you have any idea on how to solve it?
And you are sure that the logoff script is exectued? Might be an AD issue. Try to do a dummy logoff script that just places a script on your C:\temp drive.
Otherwise I would really make sure that there is no type in the logoff script.
I have exaclty the same problem, as you described.
Manually does it work…
Can you please check the permissions of your shared drive profile folder
I have windows 10 each time starting with “Hi we’re setting things up for you..”. How configure flex to remove it?
What type of Windows-Profile are you using? I would assume local profile!
In this case everytime no Profile is available, Windows creates one in the first step. One Option would be to switch your Windows to use a mandatory Profile. Windows will preload the Mandatory-Profile and all user relevant infos will added to the flex-profile afterwards.
-> There have been some Windows 10 issues regarding the start menu and the mandatory-profile. That is something you can handle with a UEM application-profile.
Pingback: VMware用户环境管理器9.3 | 涂杰克的博客
Make sure that you aren’t putting C:\Program Files\Immidio\Flex Profiles\FlexEngine.exe -s
under Script Name. Under Script Name should be C:\Program Files\Immidio\Flex Profiles\FlexEngine.exe and under Script Parameters should be -s.
At one client of mine, it will absolutely not work unless I put the command in a batch file that is then selected as the logoff script. Everywhere else, it will absolutely not work if I put the command in a batch. Go figure.
Thanks for the input. I haven’t experienced this in the past, but that is a suitable (and Windows-typical) workaround ;-).
Which Windows are you using?
i am getting an error- there was an error creating a temporary file that is needed to complete the installation
We have VMware Horizon 7.13 infra and UEM profile is getting reset after re-login of some users. Eg PST from outlook gets removed and we need to re-map it, shared folder re-mapping, printer re-configuration etc
Do you have any solution on this?