I've been struggling for quite a while now on how to get things setup for the hospital and doctors so that they can experience some decent login times. As it stands now for the hospital login times are about 1 minute and that is with nothing loaded. I have Optimized the desktop, cleaned up any startup apps, among other things and still getting these long times. To top that off it takes another 40 seconds to login to our web based EMR program and get desktop icons for it. This is very painful for the nurses and docs and was curious if there were any other suggestions. I am using INSTANT CLONES with view 7.4 and it needs to build the local profile every login. I am trying to use UEM for the profile portion but that is only for the ROAMING profile. I am trying to find the best solution to get this done and it this isn't it then I am open for comments. Here is my setup. Any help or comments are always welcome. Thanks

Horizon 7.4 Instant Clones

Windows 1607 (LTSB version)

UEM 9.3

Nimble storage

Some HP embedded Thin Clients and some thick clients running the latest clients.

Briefly, you could allow the VM to roam with the end-users so that they only have a long log in for the first time during their shift. If you choose to do that you could auto logoff the VM after they are disconnected for several minutes or hours, whatever fits your scenario.

What we do is auto login from our Wyse thin clients into the VM with a generic AD account, then once logged into windows the desktop locks with Imprivata. When an end-user taps their prox card on the prox reader connected to the thin client it unlocks the VM and Imprivata does its thing to give the user their access and expected experience. That's a big infrastructure discussion, not to mention lots of planning.

Have you tried the below link for building your image. The only difference is for the mandatory profile part I did it with local polices vs group polices and I'm getting 40 seconds with app volumes and UEM both used. Taking away app volumes its closer to 20 seconds, not quite 8 seconds like they say, I have a hard time seeing our profiles taking 12 seconds to apply.

Also have you watched the cpu usuage while people are logging in, I saw this recently on our terminal servers. See if the desktops are going to 100% cpu, and if so you may need to find a way to either lower the cpu usage on logon, or increase the VMs resources.

Here is what we do now at teh hospital. We do use Imprivata throughout. They badge in with Prox card, Imprivata launches an app called iAccess (made by our EMR company) then the view client is launched, and then the desktop. So the time that i am referring to is just when the desktop is launched until the time i get windows icons on the desktop. That is the painful part. No matter what we try the login times always exceed a minute. There is really nothing on the windows setup that loads at all. My login monitor times say about 30 seconds but that is not what i see when we login. Is usually about double what the login monitor says. I understand that GPO's will play a role in that but we need to get that as close to 30 seconds as possible. Not sure how to accomplish that. Thanks for the reply

Are the clients essentially waiting for a login to the physical client, and then additionally waiting for a login to the Windows VM?

Our people required an 8 second login. So to realistically accomplish that we do what I referred to, using a Wyse thin client auto launching View and logging in with a generic account. Essentially when an end user walks up to a workstation they tap the badge and Windows unlocks for them to the VM desktop. :-) Like I said initially could be a big architecture discussion. Maybe you should consider allowing the VMs to roam with the end-user so they aren't waiting for the VM to login each time (Just the first time after they start their shift). I know sometimes it's not feasible for EMRs to "roam" to a new location without being closed and reopened from scratch, so that might not work either.

When using UEM, check the logs to see what is taking the most time extracting and applying to the profile. My recommendation is to set all of your applications to DirectFlex so that the settings are applied at application launch rather then logging into the system. Another suggestion is to make sure that any logon tasks are all set to async. If its not, it while hold onto the logon shell. You didn't mention app volumes in your list of things but if you are using that it will also a huge impact on login times.

I have not tried this optimization article but am going to give it a whirl. The issue i have so far is with the ISO file. On my Volume License Portal i have a lot of options for iISO's but mine don't quite launch the way it does in the KB. Mine doesn't let me chose the OS since it's already there. Here is the name of the iso..SW_DVD5_WIN_ENT_LTSB_2016_64BIT_English_MLF_X21-07421.ISO. This is 2016 Windows 10 LTSB Enterprise. All my VDI masters are currently using this ISO so i'm curious if this is going to make a difference going thru these steps if the ISO isn;t the same. There seems to be a few differences. Any help with the correct iso would be great. Thanks for the reply.

If you use a mandatory profile and run into issues with the start menu, try not using it. I just found that 1703 can't use a mandatory profile because of how the permissions work, but it looks like it works correctly in 1709.

I only have access to Version 1607 LTSB which is on the compatibility list. Ran thru the entire setup and did my fist test image and it still takes 45 seconds to get to a desktop. Strange thing in the Login Monitor log, says it took 15 seconds for the GPO's and there is only one policy and that is UEM. Nothing is really enables in UEM at this point so not sure why it takes 15 seconds. Total time say 60 seconds. Is the master better off being joined to the domain or not?? At this point it is NOT. Still going to look through logs to see what i can but it doesn't look promising. Any comments are welcome. Thanks.

I don't join the parent to the domain, for us it makes it easier. Try disabling the logon monitor service and disabling the startup tool. Its weird that monitoring tool adds to the logon time from what I've seen. Add or edit this key below, it will make the desktop appear quicker, and you can see how long that vlm_helper command runs. I took a look at the fling where that started, I think it later versions they are going to disable this by default and you can enable it if you need it.

Instead of saying welcome to windows and preparing desktop, it says what services are starting and exactly what is going on. I'm probably going to add this to mine again, I did this in the past and saw in windows 2012 r2 it was hanging on the UEM service for some reason. You can see if when UEM starts if it just sits there for some reason, and that may help really pinpoint

Followed your last couple posts. Seems like there are a couple places it hangs. One is GPO's and the other is UEM. The VMlogin monitor hangs at the very end as well. Probably adds about 5 seconds to it. The Login Monitor service is disabled yet this still runs. Any thoughts?

Another thought of something to try is UEM configured in NOAD mode. I have absolutely no experience with using UEM in this method, since we started with UEM a few years ago and haven't tried switching to NOAD mode, yet. My co worker met someone at VMworld 2018 that was raving about the login time savings for his environment by switching to UEM in NOAD mode, getting away from that one remaining GPO.