- Can’t uninstall app: Delete or change Windows apps that have been flagged as non-removable - Thu, Mar 16 2023
- FSLogix VHDX compaction: Resize virtual disks - Thu, Dec 1 2022
- Sysinternals Process Monitor: Real-time file system, registry, and process monitoring - Fri, Oct 28 2022
Windows 7 completed a first logon in less than 35 seconds, and the profile weighed in at less than 5 MB. Windows 8.1 exponentially increased both the first logon time and the size of the profile. Windows 10 continues this grand “tradition,” with a first logon time of well over two minutes and a profile weighing in at approximately 130 MB.
Why does profile creation take so much longer in Windows 10? Most of it can be attributed to Modern Apps, which are possibly the biggest paradigm change from operating system versions newer than Windows 7. Each of Microsoft’s new Modern Apps is assigned on a device-by-device basis, and when a user logs in for the first time, the Modern Apps assigned to it are created and loaded. Each Modern App also has a database sitting behind it, as you can see from the screenshot below showing the database file for Edge.
The creation of the Start Tiles, which is also controlled by a database, further increases logon time over and above that of Windows 7. The Windows 7 Start Menu was simply a window into a file system, but Windows 10 insists on not only compiling a database from installed applications and shortcuts, but also creating links to live Internet pages and inserting advertisements for various Windows Store apps.
All of this “magic” takes time. Normally, the time is spent looking at the mildly patronizing Windows 10 “first logon animation” (see below), but many choose to disable this and instead find themselves staring at a screen saying “preparing Windows.”
Once a user is logged in for the first time, if they’re using a local profile, subsequent logons to this machine will be an order of magnitude faster. This stands to reason—they now have a local profile cached on the device. However, if you’re in an environment where you have “open access” machines, which remove cached local profiles after a certain period of time, then users may be exposed to the “first logon” experience a lot more often than they’d like.
Additionally, if you use any sort of solution in which the copy of the profile is removed, this issue will keep on rearing its head. In this case, you may just want to improve the first logon time anyway, even if you’re not removing cached profile copies, so that your users don’t develop a negative perception of the new operating system you’re deploying.
So how can you decrease logon time?
Try not to log on straight after a cold boot
Windows 10 doesn’t specifically finish “booting up” when the logon screen is presented. In the background, there’s still a lot of stuff going on to do with the boot process. This is intentional—a smoke-and-mirrors approach to make Windows 10 look like it boots up much faster. However, the trade-off comes when you log straight on after a cold boot; the operating system is still running boot processes in the background. Logging on straight after a cold boot increases logon time by approximately 30 seconds in my lab.
Using a technology to start up machines prior to user arrival may help with this, but in many environments, this isn’t something that can be accurately predicted. It may also go against policies regarding power consumption.
Go Long-Term Servicing Branch (LTSB)
This is the option Microsoft would rather you didn’t take, but if you’re really concerned about the effects of Modern Apps, the LTSB option removes almost all of them (including bringing back the old Windows 7-style Calculator application).
However, there are things you need to be aware of, as the LTSB version (only available on Enterprise) is essentially a whole different operating system. The delivery of patches and feature updates will be significantly affected, so it is something about which you need to think carefully before taking the plunge.
Remove unneeded Modern Apps
PowerShell cmdlets exist to allow you to remove Modern Apps either individually or all at once. They are specified on a device-by-device basis, so you will need to run the cmdlets on each machine from an administrative PowerShell session.
If you wanted to remove all Modern Apps from a machine (except for those that are listed as part of the operating system), use this command:
Get-AppxProvisionedPackage -online | Remove-AppxProvisionedPackage -online
Bear in mind that this will also remove the Calculator app, so you may want to take a more piecemeal approach. To remove Modern Apps on an individual basis, use the Remove-AppxPackage cmdlet. Here are examples of removing some of the more esoteric apps:
Remove-AppXProvisionedPackage -Online -PackageName Microsoft.3DBuilder_10.10.38.0_neutral_~_8wekyb3d8bbwe Remove-AppXProvisionedPackage -Online -PackageName Microsoft.BingNews_4.8.268.0_neutral_~_8wekyb3d8bbwe Remove-AppXProvisionedPackage -Online -PackageName Microsoft.BingFinance_4.8.268.0_neutral_~_8wekyb3d8bbwe Remove-AppXProvisionedPackage -Online -PackageName Microsoft.BingSports_4.8.268.0_neutral_~_8wekyb3d8bbwe Remove-AppXProvisionedPackage -Online -PackageName Microsoft.BingWeather_4.8.277.0_neutral_~_8wekyb3d8bbwe Remove-AppXProvisionedPackage -Online -PackageName Microsoft.MicrosoftOfficeHub_2015.6811.23771.0_neutral_~_8wekyb3d8bbwe Remove-AppXProvisionedPackage -Online -PackageName Microsoft.MicrosoftSolitaireCollection_3.8.3092.0_neutral_~_8wekyb3d8bbwe Remove-AppXProvisionedPackage -Online -PackageName Microsoft.Office.OneNote_2015.6769.17901.0_neutral_~_8wekyb3d8bbwe Remove-AppXProvisionedPackage -Online -PackageName Microsoft.Office.Sway_2015.6769.45081.0_neutral_~_8wekyb3d8bbwe Remove-AppXProvisionedPackage -Online -PackageName Microsoft.People_2016.219.2348.0_neutral_~_8wekyb3d8bbwe Remove-AppXProvisionedPackage -Online -PackageName Microsoft.SkypeApp_184.108.40.206_neutral_~_kzf8qxf38zg5c Remove-AppXProvisionedPackage -Online -PackageName Microsoft.Windows.Photos_2016.325.13200.0_neutral_~_8wekyb3d8bbwe Remove-AppXProvisionedPackage -Online -PackageName Microsoft.XboxApp_2016.322.258.0_neutral_~_8wekyb3d8bbwe Remove-AppXProvisionedPackage -Online -PackageName Microsoft.ZuneMusic_2019.6.15131.0_neutral_~_8wekyb3d8bbwe Remove-AppXProvisionedPackage -Online -PackageName Microsoft.ZuneVideo_2019.6.18671.0_neutral_~_8wekyb3d8bbwe Remove-AppXProvisionedPackage -Online -PackageName Microsoft.WindowsAlarms_2015.1258.20.0_neutral_~_8wekyb3d8bbwe Remove-AppXProvisionedPackage -Online -PackageName microsoft.windowscommunicationsapps_2015.6568.46361.0_neutral_~_8wekyb3d8bbwe Remove-AppXProvisionedPackage -Online -PackageName Microsoft.CommsPhone_2.3.25005.0_neutral_~_8wekyb3d8bbwe Remove-AppXProvisionedPackage -Online -PackageName Microsoft.Messaging_2.1.20000.0_neutral_~_8wekyb3d8bbwe Remove-AppXProvisionedPackage -Online -PackageName Microsoft.WindowsPhone_2016.202.10.0_neutral_~_8wekyb3d8bbwe Remove-AppXProvisionedPackage -Online -PackageName Microsoft.Getstarted_220.127.116.11_neutral_~_8wekyb3d8bbwe
Import a standard Start Tiles layout
The creation of the Start Tiles database (vedatamodel.edb) also takes a while. What you can do is use the Export-StartLayout cmdlet to create a standard layout that you import into the default user profile. Set the Start Tiles the way you want them, and then use this command (substituting the path as appropriate):
Export-StartLayout -Path x:\xxx\LayoutModification.xml
Then simply copy the LayoutModification.xml file into C:\Users\Default\AppData\Local\Microsoft\Windows\Shell. When the user logs in, this file will be used to create the Start Tiles instead, reducing logon time.
Use a default user profile
By far, the most difference that you can make to the logon time of Windows 10 (in a domain-joined environment) is by creating a Default User profile in the netlogon share. When a user logs on for the first time in a domain situation, the netlogon share is checked for the existence of a folder called “Default User.vx” (where x is the version number corresponding to the operating system in use). For Windows 10 build 10586 and under, the folder should be called “Default User.v5.” Builds of 14279 and upwards expect a profile folder called “Default User.v6.”
You create the default user folder by logging on as a template user, logging out again, and then copying the contents of the %USERPROFILE% folder to a network share. Sanitize the Registry and the file system so that permissions are correct (make sure all users have at least Read permission to the files in the profile and inside the ntuser.dat file). Remove all references to the template user from the Registry ntuser.dat file, as well. You can also remove the APPDATA\LOCAL and APPDATA\LOCALLOW folders from the profile folders.
The process used is very similar to that involved in creating a mandatory profile, except that the ntuser.dat file is not renamed to ntuser.man. Creation of mandatory profiles is documented in many places online.
Using a default user profile in this way can reduce the first logon time on a Windows 10 device by a margin of approximately 66%. This makes a huge difference to the user experience, especially in environments where local profile copies are not maintained. A video demonstrating the difference between the logon times when using a default profile is available here.
Subscribe to 4sysops newsletter!
Used together or individually, the above tips should help administrators reduce the drag for their users when they are accessing Windows 10 for the first time.
Want to write for 4sysops? We are looking for new authors.
You said: “C:\Users\Default\AppData\Local\Windows\Shell” and should be: “C:\Users\Default\AppData\Local\Microsoft\Windows\Shell“.
Thanks for pointing that out, it has been rectified.
Not sure I agree with the default user recommendation. No control over which machines get the profile – I.e. Win 10 and Windows Server 2016 RDS environments. Do the default profile in a custom reference image instead.
I forgot about the imminent(ish) release of Server 2016, as I am running 2012 R2 in my lab, but it’s a good point.
Yes, the limitations of this recommendation are that it would apply by default to all users, unless you did something cunning with the permissions (and obviously that would require testing). At the moment, though, Windows 10 Anniversary build will be a .v6 profile and Server 2016 still uses a .v5, so initially you might be able to maintain two different streams, but obviously you’d be at the mercy of Microsoft incrementing the profile version for Server 2016 at any given time.
Putting them in a reference image would be the most foolproof way, yes. I may do some research into ways of applying the default domain profile from the netlogon share for specific groups of users only, but at the moment nothing concrete jumps easily to mind.
Nice article James! Good to see that some of this older knowledge is still useful!
Your video comparing login times was quite amusing, thanks for making the effort.
I’ve always relied on modification of the local Default user profile as the core of the streamlining process. After Windows 7 I started using a free utility called Defprof from Forensit. A local template user is created and logged on, settings are added (not too many!), then logged off. Using an admin account the defprof utility overwrites the Default user profile with that of the template. I was able to get Windows 7 Enterprise new logons (in computer labs) down to one minute.
We’ve also tried roaming profiles and mandatory profiles, but never a network-based default profile as you suggest above. Will have to give that a try!
I’m about to start working on Windows 10, and LTSB is where I’ll begin. One pass at the EDU version was disappointing. After stripping out all the modern apps and sysprepping (generalize setting) Windows went ahead and added them all back.
I wouldn’t recommend using LTSB for an education environment. LTSB is designed for things like ATMs and digital signage. Using LTSB will mean missing out on useful features such as cortana/O365 integration. There may also be modern apps you do wish to use and you will not be able to. You also cannot ever upgrade LTSB, you have to wipe and reload.
I would have to disagree. LTSB is designed for enterprises where their vendors can’t match up to an “up to eight month” servicing window. I am doing a project in education currently and we have to apply LTSB to some machines because the vendors refuse to guarantee that they can fix issues with Windows 10 systems within that eight-month servicing branch for CBB. Some of them have actually insisted that we use LTSB in order to continue using their software. We have mixed-and-matched but have about 12% of systems running LTSB because of issues with vendors. Microsoft would like you to believe that it is just for ATMs, air-traffic control systems and medical stuff, but I know many businesses who are evaluating LTSB because to them, revenue streams are mission-critical and they are generated by ordinary staff desktops.
As to Modern Apps – again, many people I talk to are unconcerned by them and find them an annoyance to their administrative and management processes. I’ve noticed many sites popping up with scripts to remove them. As for Cortana – only 7 billion searches have been done through it on 300 million Windows 10 devices, so with an average of 24 per device, it is clear many people turn it off. We also have Office 365 instances on LTSB and they work fine.
Of course the whole point of CBB is to get everyone on a fast-update schedule that makes them more ready to accept the Windows 10 Azure platform that is now in the works. Microsoft’s partnership with Citrix is bringing this closer.
But anyways, I do believe that when you have assessed your application estates, some will end up on LTSB. I recommend CBB where possible, but unfortunately some vendors are very bad at fixing issues within their software within reasonable time frames. Of course, vendors need to step up, but risking unsupported configs while vendors sort their acts out is not something many people are willing to do.
However, I also recommend disabling all the (frankly useless) Modern Apps and using Current Branch for Business where possible. This allows the best of both worlds, and would perhaps be a better performance improvement than adopting LTSB. I agree in that LTSB shouldn’t be adopted solely for performance reasons (disabling Modern Apps is a better way), but I don’t believe that it shouldn’t be considered at all, because in some verticals vendor response can be absolutely abysmal.
Thanks James, a good explanation. I am considering using LTSB in an education environment for hot desk areas just to get over the logon time hurdle. With some of the kit being used even with the default profile in place the logon time is unacceptable (>30s)…
Thanks for this found it really helpful article and just tried it on three different schools and it worked a treat
Hi James. I know this is a year later, so Im hoping you still around. There is a lot of discussion around what worked and didnt, for other users. Can you be a little more specific about what you did that worked for you. Am in a similar situation with supporting schools and have only recenttly tied 10 in labs. Logon times are a deal beaker for us.
Since we are a large university where each college uses different profile settings, we don’t use the Default Network User (on DC Netlogon share).
We’ve been trying to use Mandatory profile, but don’t seem to get a speed increase on first login.
What is the difference between this and just renaming a profile “Default” (and performing the clean-up you mentioned)?
“LTSB is not intended for deployment on most or all the PCs in an organization; it should be used only for special-purpose devices. As a general guideline, a PC with Microsoft Office installed is a general-purpose device, typically used by an information worker, and therefore it is better suited for the CB or CBB servicing branch.” — from Microsoft.
Yes, and I think Microsoft are being naive about this. Here is an in-depth discussion of the issues around CBB versus LTSB, if you’re willing to listen https://www.youtube.com/watch?v=wZmtNrvU3Hs&t=147s
I was informed schools have to use the EDU license and not the Enterprise License (LTSB). We have a school agreement. Is this the case ? or can we use either.
Logon times are a nightmare first time using Windows 10 EDU, however mates using ENT LTSB complain that drives keeps disappearing and printers too. Which we don’t have that issue.
Is there not a policy setting to turn off all the apps not needed in a school environment?
We did remove at sysprep, but they just come back.
Schools can use whatever they want, assuming they have the right license in place. Enterprise doesn’t mean LTSB either, it can be CB or CBB also.
If you remove all of the Modern Apps within the image using PowerShell they shouldn’t return if you’ve turned off Store updates via GPO.
I am in an environment where we do not have an AD or a netlogon share. We are actually an education institution where we are running Samba 3 as a domain login.
Question I have is how to apply a ‘mandatory’ or ‘default’ profile on Windows 10 so that they load up with that profile when they authenticate against our LDAP server. The attempt is to avoid creating new profiles on the machine and reduce login so we aren’t creating a new profile for each user.
Is it possible to define something like this on the Windows 10 box or we are pretty much unable to mitigate the profile creation portion?
I’m also in an EDU environment and dealing with slow logins as user profiles are created. Any thoughts on if UE-V could speed up login times? I’m about to start building out a UE-V environment and test but would like to hear from others.
Hi James, useful article – have you ever copied the default profile locally, I’m thinking of doing this but don’t want to host in the netlogon as our links are a bit rubbish. So, I’m thinking of creating the DUP and then either overwriting the original “Default User” or pointing domain accounts to use my newly created local one (if it’s possible. Any thoughts?
is not better making default profile on local computer and forcing users to use it by
-creating a reference image and syspreping it with copyprofile in unattend.xml
-and then in active directory users profile tab left in empty.
so when the user logs on he/she will use the local default profile. no network traffic (in my lab the profiles are arround 300MB due to softwares)
ofcourse we need to tweak start menu and apps tweaks.
Thank you very much for some interesting pointers. I would add just this one thing:
There may be an alternative to copying the profile to the NETLOGON share, especially in a VDI environment. This could be useful as there would be no impact to 2016 servers.
I created my Gold build and then, using Sysprep, I copied the profile I had just created to the Default User profile. I did not then copy this to NETLOGON.
Logging on to the pool created from this image shows a marked decrease in login time, nearly all of which was coming from the “Preparing Windows” stage.
But thanks once again.
All i can say is, get your image correct if you’re depoying using wds or similar.
I used removeapps.ps1 (search on google) also one of the best logon time speed up methods I’ve used is to remove the stubpath from registry entries for ActiveSetup, and set the ‘IsInstalled’ to 0. One of the biggest slow initial logon times is caused by the activesetup creating a mail database, and setting up other apps from active setup.
In addition to the above activesetup, is also tsetting up the new modernapps, if you remove all of the ones you don’t need or want e.g xbox.app this will reduce the new user logon times as well, but if you do this, remember to turn off store updates using GPO.
I am using LTSB and it’s a lot closer to the way Windows 10 should be. Also, I’ve replaced the Start Menu with Classic Shell for an actually usable Start Menu. And a lot of policy changes and some edits to the BCD to make it more robust.
This makes Windows 10 a lot better, but it’s still a lot more delicate than Windows 7.
Microsoft really needs to take a step back to reevaluate now that they’ve dropped their (destined to fail) phones.
My security Team forced us to use Creators Edition in a VDI environment all I can say it has been one of the worst mistakes ever. Forget the performance issues and let's just focus on the new features patches and resulting ever-changing nightmare. The instability of all these variables has been almost impossible to manage.
Then let's add in the fact that almost every product in the VDI stack must be supported by release date and then needs about two or three more patches to be stable. Couple that with your Broker / Hypervisor /Nvidia Cards, AV and additional Security software all needs to be supported all the time.
One of the biggest mistakes we ever made and now I have so much built into it I cannot back out.