Azure VM created from packer image slow to logon

After creating a packer image successfully I then make a new Azure VM from the image which deploys in the usual amount of time. It starts fine and I can connect to it however, it then take 10-15 minutes to actually get to the desktop. It pretty much takes just as long to logon asit does to create the whole thing.

Once I then restart the VM, I can logon normally in about 10 seconds or so.

I am using the Azure image Windows 10 Enterprise 20H2. Is there anything I can do to avoid this first start crawl?

which SKU are you using for the deployment compared to the packer build?
Perhaps also configurations or packages interfere with the initial login.

I am using 20h2-ent as the image SKU for packer to build with and I am using d4s_v4 vm size to build and create the VM. Just ran another test and recorded the following:

  • Once the new VM starts, I can remotely connect via mstsc and I get the blue screen with please wait and the rotating dots. This lasts for 10 minutes
  • Then the screen changes to the user account and says welcome. This lasts for 30 seconds
  • Then you get to the desktop. After a few seconds, a toast notification pops up saying:


  • I couldn’t find anything obvious jumping out in the event logs
  • If I then restart the machine, I can connect and receive the welcome screen straight away and get to the desktop in about 3 seconds.

In relation to the deployed apps, it doesn’t make any difference what apps are deployed. I have tried installing nothing, just one app like notepad++, or full install with office and apps. All produce the same result.

I assume deprovisioning steps are in place?

Sorry, I’m not sure what deprovisioning steps are. I have only just started using packer and have been building off blog posts regarding deploying machines for Citrix. I have a post processors section in the json -

“post-processors”: [
“type”: “manifest”,
“output”: “manifest.json”,
“strip_path”: true

I also found that on the first boot machine, the following services set to automatic failed to start but were then started the second time -

  • IP Helper
  • Windows Time
  • Software Protection

E.g. sysprep for windows installations:

Yep although mine doesn’t have the /mode:vm switch, but that would only affect the boot time up to logon not post logon I thought -

“type”: “powershell”,
“inline”: [
“& $env:SystemRoot\System32\Sysprep\Sysprep.exe /oobe /generalize /quiet /quit”,
“while($true) { $imageState = Get-ItemProperty HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Setup\State | Select ImageState; if($imageState.ImageState -ne ‘IMAGE_STATE_GENERALIZE_RESEAL_TO_OOBE’) { Write-Output $imageState.ImageState; Start-Sleep -s 30 } else { break } }”

I’m in the same situation and tried tried to nail the issue for quite a while now - without success. I tried to narrow down the issue by trying various provisioner combinations in hope of finding a common pattern:

-Install all available windows updates (via the windows update provisioner)
-Generalize image

-Install no windows updates
-Generalize image

-Install all available windows updates
-Don’t generalize image

-Install no windows updates
-Don’t generalize image

The last option did basically nothing. It spins up a virtual machine and immediately shuts it down and creates an image from it. In all cases I was using sku 20h2-pro-g2 and vm size Standard_DS4_v2 (both for building the image and deploying it).

I contacted the azure support with this, but since they don’t really offer support for custom images they only gave me a couple of hints to check the eventlog for running updates or framework installations, but that’s it.

Well like all annoying problems, this did actually end up going away for me or at least, is not visible any more now that I have moved to a complete WVD production line.

I create the packer image, push it into a Shared Image Gallery and then provision hosts into a WVD host pool. This all works nicely and the first logon by a user doesn’t have any issues.

Not much help I know, as it may simply be the deployment process taking the hit on the first slow logon, but at least it works.