Guys, I having this issue with only Windows 10 VDI. When the user first login to the Windows 10 VDI, drive mapping set on UEM don't show up. If the user lock the machine and log back in, the UEM get refresh, all drive mapping work fine. Any ideas? I have a open case with tech Support but no feedback yet!
FYI, we are using UEM mappings and not having any issue with Windows 10.
Mike_A
I am having it! A lot of issues with Windows 10.
With Windows 10, there is a few issues that we have run into also and have found workarounds or expectable issues that we can let go to production, until Microsoft fixes them.
Finding that most of the issues are Microsoft doing and they need to fix it for enterprise admins to make global settings apply to users profile as a whole.
FYI, mappings was not one of the issues.
The only thing I can think of, confirm you have set this GPO setting.
Mike_A
Mike, Thanks!
I have that enable in the GPO and confirm that is getting applied.
Is strange, Applications, Windows Settings, Printers, everything work fine except for the drive mapping during the first login.
Here is how I have configured my mappings.
Make sure it has Run Asynchronously is enabled.
I have no conditions for this mapping and it works from the get go.
Same setting on my side. But not working on Windows 10 Only at first login!
Created a new Gold Image using Windows 10 Ent v1511
Same Issues:
1. Long Login process - Preparing Windows - 2 to 3 minutes
2. Map Drive Dont show until second login after user timeout
3. Windows 10 Re-scaling issue
AppVol 2.11
VMware SVGA 3D Driver version: 8.15.1.46
VMTools 10.0.6 Build 3560309
UEM 9,0
Do you have GPO's and/or scripts applied to the users and/or machine OU's?
I've seen current GPO's and login scripts cause the slow logins for Windows 10, because some of the policies are not for Windows 10 OS.
I always suggest my clients create a new OU structure for VDI/Win10 and then review their GPO policies to determine what policies the need to transition over and one's they need to create new for Windows 10 OS.
FYI, UEM makes this much easier to manage and test your GPO policies against logons.
Can you enable debug logging and post the FlexEngine-ASYNC.log file?
Enabling debug logging for a single user in VMware User Environment Manager (2113514)
We are also facing the same issue, drive mapping set on UEM don't show up on Win10 VDI. We are still on UEM 8.7. Any fix or solution to resolve this issue. UEM - 8.7 VMTools 10.0.0 Build 3000743.
Please share a UEM logfile in debug mode with me. Should be the -async logfile if you have asynchronous mapping enabled.
2016-08-22 10:53:07.009 [INFO ] Performing async UEM actions [IFP#1c384b30-745c745>>] 2016-08-22 10:53:07.009 [DEBUG] Processing pending async UEM settings 2016-08-22 10:53:07.087 [DEBUG] Set friendly name for drive 'Z:' to 'Binaries' ('PGH-binaries.xml') 2016-08-22 10:53:07.087 [INFO ] Successfully mapped drive 'Z:' to '\\xxxx\pgh\binaries' ('PGH-binaries.xml') 2016-08-22 10:53:07.087 [DEBUG] Processed 1 UEM drive mapping (1 successful) 2016-08-22 10:53:07.087 [INFO ] Completed async UEM actions (68 ms) [<<IFP#1c384b30-745c745]
The logfile says the drive mapping is created successfully.
Can you try the following: in the users session, open a command prompt, but do it elevated (with admin rights). See if the drive mapping is available there. (look for the driveletter, or type 'net use')
Did anyone find a solution? I'm having the same issue on Win 8.1. I'm able to net use as the user and map and it shows OK in the log. It must be something with Win 8.1 or Win 10
Is the user your are testing with Local Admin on the machine?
Is User Account Control (UAC) enabled?
There is a known limitation with drive mappings if both of these statements are true.
The drive mappings are only visible in that case if you open an elevated command prompt and type 'net use'
This is an old thread, but just in case: UEM 9.3 has been released, with a fix for the issue where a drive mapping is not visible in File Explorer for local administrators or power users.
To work around this problem, configure the EnableLinkedConnections registry value. Add a new registry key “EnableLinkedConnections” (DWORD) =1
HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\ EnableLinkedConnections =1
That workaround is no longer necessary – UEM 9.3 fixes the underlying issue.