Provisioning packages - What can or cannot be done?

Hi Windows 10 folks!

Today I wanted to talk about a topic that I like: Windows 10 provisioning.

There's a lot of discussion on Internet if the new Windows 10 deployment method (aka provisioning) was really a doable scenario. And to be honest, from my experience, I don't see a lot of customer adopting that method. To verify that, I've even done an internal survey within Microsoft Japan and gathered Windows 10 deployment method chosen by 60 out of the top 200 companies: 90% of them decided to go with the traditional "Wipe and Load".

Why? well, there's many reason for that. The first one I can think about is that customers are used to the traditional deployment method which works great on Windows 10 as well. They might have documented the whole deployment method and might want to limit cost of a complete new deployment design and documentation. In Japan, for instance, most of our customers consider migrating to Windows 10 at the specific time a bulk device replacement is planned. In this particular case, they will most of the time adopt the "Wipe and Load" method.

The second reason which comes to my mind is that the provisioning method has some limitation and challenges:  for instance, it doesn't offer an easy way to remove bloatware from an Windows 10 device bought in a store (you can script this but this won't work the same for all the devices available in the market). Another one would be that the edition upgrade only works from Pro (or Edu) to Enterprise, whereas most of consumer devices you can buy comes with Windows 10 Home edition (there's actually a way to do Home to Pro, then Pro to Ent using PPKG). And lastly, Windows ICD tool which might not be (for now) the most user friendly tool (it lacks some information about settings and some input format).

For me, provisioning should only be used for one scenario: BYOD. It is a solution which can solve some business critical situation where a sales person during a business trip would lose/break/get stolen his device and would need to replace it without the intervention of an IT pro. Provisioning will help him get back to work quickly by upgrading his device to Enterprise edition, installing Office 2016, setting up VPN profile and even domain join if needed.

For any other scenario, you should consider in-place upgrade (from Windows 7, 8, 8.1 devices) or wipe and load for any new devices.

Even though we face some limitations in the provisioning method, I wanted to gather here all the testing results I got from PPKG (what works and what doesn't) so that you have all the keys in hand while deciding the best deployment method which fit your needs.

  • Register device in the Corporate infra
    • Domain Join --> OK
      • [Runtime Settings]>[Accounts]>[Computer Account]
        • [Account] domain\account (i.e. contoso\admin)
        • [DomainName] domain FQDN (i.e.
        • [Password] domain join account password
    • Azure AD Join --> NO (it's related to the authentication method of enrollment offered by PPKG which is not compatible with Azure AD Join as well as Intune)
    • Intune enrollment --> NO (same as above)
    • SCCM On-prem MDM enrollment --> OK (not tested personally but found a great article explaining how to do it)
  • Profiles
    • WIFI --> OK
      • [Runtime Settings]>[ConnectivityProfiles]>[WLAN]>[WLANSetting]
        • Add the [SSID] of the WiFi
        • Under [WLANXmlSettings], fill [AutoConnect], [HiddenNetwork], [SecurityKey] and [Security Type]
    • Certificates --> OK
      • For Root CA Certificate, [Runtime Settings]>[Certificates>[RootCertificates]
        • Type a [CertificateName] and click [Add]
        • [CertificatePath] path to the CER root CA certificate file
    • Email profile --> since in a BYOD scenario you don't know the domain or azure AD account, I don't think it's something possible with provisioning
  • OS Customization
    • Start Menu --> OK (note: it doesn't apply to the current user but to any new users on the computer)
    • Wallpaper --> NO (copy the image file but doesn't apply it, don't know yet if it's an expected behavior. will update you later again on that)
    • Local Account creation --> OK
      • [Runtime Settings]>[Accounts]>[Users]
      • Type a [User Name] and click [Add]
      • [Password: password of the newly created account
      • [UserGroup] add the user to "Administrators" group for instance
    • UWF --> OK
      • [Runtime Settings]>[UnifiedWriteFilter]
      • [FilterEnabled] TRUE
      • [OverlaySize] in MB (i.e. 1024)
      • [OverlayType] select RAM or Disk
      • [Volumes]
        • Type the [DriveLetter] to filter (i.e. "C:") and click [Add]
        • [Protected] TRUE
    • Bitlocker --> NO (yes using manage-bde command within a script)
    • Edition upgrade --> OK (only from Pro/Edu to Enterprise)
      • [Runtime Settings]>[EditionUpgrade]
      • [UpgradeEditionWithProductKey] type the Enterprise product key
  • Universal Applications
    • Install --> OK (don't forget to enable sideloading, deploy the certificate, dependencies as well as the app file)
      • To enable sideloading, [Runtime Settings]>[Policies]>[ApplicationManagement]>[AllowAllTrustedApps]>[Yes]
      • To deploy certificate, [Runtime Settings]>[Certificates]>[TrustedPeopleCertificates]
        • Type [CertificateName] and click [Add]
        • [TrustedCertificate] specify the path to the app certificate file
      • To import app with dependencies, [Runtime Settings]>[UniversalAppInstall]
        • Type [PackageFamilyName] and click [Add] (can be any name)
        • [ApplicationFile] specify the ".appxbundle" file
        • [DependencyAppxFiles] add one by one all the dependencies files
    • Uninstall --> OK
      • [Runtime Settings]>[UniversalAppUninstall]
      • On a computer where the app to uninstall is installed, run the PowerShell command get-appxpackage to find the package family name.
      • Type the [PackageFamilyName] found using the above command.
  • Win32 applications installation
    • MSI --> OK
      • [Runtime Settings]>[ProvisioningCommands]>[DeviceContext]
      • [CommandFiles] add the MSI file
      • [CommandLine] type the command line to install the MSI package: "msiexec.exe /i xxx.msi /q"
    • Office --> OK (I will write another article to explain how to do that using WICD).

Hope this list will help you decide what's possible with provisioning. Obviously, I haven't covered all the possible settings available in Windows ICD so if you need any other settings, I can only recommend digging through the Windows ICD tool to search for it :)

Note: I will be presenting a session at DE:CODE 2016 about that topic, DE:CODE is the TechEd+Build conference in Japan, If you live in Japan (and speak Japanese), I strongly recommend attending my session INF-024 about OS deployment :)