QuickPost – Improve Windows 10 logon times with FastFirstSignIn

There’s a new trick in the quest for Windows 10 logon nirvana – introducing FastFirstSignIn.

Specifically this for those of you using Windows 10 (whether this be ordinary Windows 10, or brokered through Citrix Virtual Apps/RDSH/WVD/Horizon/Parallels/etc.), there’s a nifty new trick in town you can use to make a helluva difference.

My original logon times article is here, although it will be undergoing a detailed series of updates soon. A critical part of this for Windows 10 users is the removal of UWP apps from the image, wherever possible. This makes a major difference to the first logon time (because it is first logon time we are concerned about in non-persistent environments such as we often find in Citrix Virtual Apps and Desktops). Unfortunately, the removal process is a bit of a pain and involves a touch of PowerShell hit-and-miss. Sometimes you inadvertently remove apps you want to keep, sometimes you end up trying to remove apps you can’t remove, sometimes they reprovision themselves – you know the drill. Soon you get into the realms of UWP whack-a-mole, and ongoing maintenance is something busy administrators don’t need adding to their already-overflowing workloads.

However, if you’re on Windows 10 1809 or higher, you can bypass the provisioning of UWP apps entirely by using this little routine on your machines during the build. Massive credit due to Nicke Kallen for discovering this awesome black magic and sharing it.

Implementation

Firstly, fire up a WIndows 10 image higher than 1809. I’m using 1909.

Install the Windows Assessment and Deployment Kit on your machine with the default settings.

Run the Windows Imaging and Configuration Designer tool

Click on Advanced Provisioning

Give the project a name and click Next

Choose “All Windows desktop editions” from the next menu, click Next

Click Finish and it will load the settings.

Expand Runtime settings | Policies | Authentication | EnableFastFirstSignIn and change the property to Enabled

Expand Runtime settings | SharedPC | AccountModel and change the property to Domain-joined only

Expand Runtime settings | SharedPC | EnableSharedPCMode and change the property to TRUE

Click on Export | Provisioning package

Give the package a name and change the Owner to IT Admin, then click Next

Click Next, select where to save the package (make a note of the path), click Next again, and then click Build

Click Finish

Close the Windows Config Designer

Make sure the package file generated is in an area accessible from your golden image

Access your golden image and open an administrative PowerShell session

Run the following command

Install-ProvisioningPackage -PackagePath “pathtopackage\packagename.ppkg” -QuietInstall

The package will install

Now, next time you log on to the system this provisioning package has been run on, you should see an appreciable difference in logon time – the video underneath shows the difference. Essentially, the UWP app provisioning is not run, shaving a big chunk (almost 50 seconds in the video!) off from the logon time.

Probably worth mentioning that SharedPC mode does a few odd things to the interface – essentially it works by enabling a bunch of local GPO settings, rather bizarrely. It does things like remove the Lock option from Explorer, but more pertinently, it disables the use of OneDrive storage via the GPO settings. However, what you can do is simply configure domain- or OU-level GPO settings to override these, so that you get the required settings with the benefit of the fast sign-in. A full list of the settings in use is available in this document.

 2,005 total views,  28 views today

5 comments

  1. This is fantastic, I’m an IT manager in a college so this is big for us!

    Can this be run retrospectively on in place installation and as part of a MDT task?

    Thank you

    Matthew Wood

    1. As far as I know, yes. However pay careful attention to the article linked at the end and be sure to test overriding any of the policies set locally. Given that you’re in education though, this is ideal for a lot of your device base, possibly.

  2. So given your recent article on NOT using Mandatory profiles anymore, where does this fall within the whole setup/deployment process for an Education environment? Do I still need to create a reference image? Do I still use the Decrapifier to get rid of unwanted provisioned apps? Do I use this article to improve logon times? Do I use the Schools PC app to provision PC’s within school? I’m very confused which path I should be taking!

    1. The profile is just one piece in the entire setup. I’d still use a reference image and keep that as lean as possible in terms of apps. I’d also definitely look to use as many logon optimizations as are necessary, but make sure that you validate each one correctly. Set a logon time that you are happy to accept and aim to stay at that level – no sense spending weeks on saving just half a second, for example. Of course, make sure you are baselining and testing properly so you understand the KPI implications of each change you make.

      Ideally, you should look to make your provisioning process as automated as possible. Maybe look into code-based deployment and evergreen scripts. We’ve had great success with these. I also recommend using things like the BIS-F tool, VMware OSOT or Citrix Optimizer to help with other performance adjustments (even in non-RDSH environments).

      Don’t tell anyone 🙂 but I am actually starting work on a series of logon times articles looking at each step in the process and the impacts of each optimization at each stage. This should allow you to target the optimizations you choose a lot more sensibly

Leave a Reply

Your email address will not be published. Required fields are marked *