Install OneDrive NGSC update on Windows 10 in OSD

This week Nickolaj Andersen released an excellent blog post on how to install OneDrive NGSC Next Generation Sync Client with ConfigMgr:

Also there was a great post on TechNet by Paulo Jorge Morais Dias:

I would like to share how to install OneDrive NGSC update on Windows 10 in OSD, because installing the update in an OSD task sequence improves the first run user experience on a new installed Windows 10 device. Let’s have a look what happens if a user is logging in the first time on a fresh installed Windows 10:

Windows 10 is shipped with a built-in OneDriveSetup.exe in C:\Windows\SysWow64, on Build 14342 its version number is 17.3.6381.405. Windows 10 1511 of course is shipped with a much older version.

2016-05-25 20_59_30-SysWOW64

When a user is logging in for the first time, this OneDriveSetup.exe is started by a Run key which is originated in the default users profile:

2016-05-25 21_05_32-Registry Editor


You can monitor the installation in the log files which are written to C:\Users\<username>\AppData\Local\Microsoft\OneDrive\setup\logs. As we can see here, the installer starts two processes with different parameters and log files, at first C:\Windows\SysWOW64\OneDriveSetup.exe /thfirstsetup and then C:\Windows\SysWOW64\OneDriveSetup.exe /thfirstsetup /peruser /childprocess.

Install_<date>.log file:


Install-PerUser_<date>.log file:

OneDrive_Install_PerUserIf we would use the above mentioned methods to update OneDrive, there would be a second installation of the OneDrive client after first logon, and this installation is not started until the ConfigMgr is initialized and has all policies. Some users may start their OneDrive in the meantime and would get an update notification by the OneDrive client itself which tries to download the newest installer from Microsoft.

In order to achieve a really completed Windows installation after an OSD task sequence finishes, I built a ConfigMgr application which replaces the original OneDriveSetup.exe in C:\Windows\SysWow64 with the current version. If I add this application to my task sequence all new users start with an already updated installer and don’t need a second, delayed installation. In order to use this application for running machines as well, we just need a method to gather the existing user profiles.

And now it’s time to admit that I have cheated 😉 I used the brilliant Powershell App Deployment Toolkit which offers a bunch of helpful methods, for example to get all user profiles on a machine. Please find it here:

If you don’t like the idea of introducing a new wrapper technology to your ConfigMgr, you can use the PowerShell script by Nickolaj Andersen to deal with existing user profiles and combine it with the following steps in your own installation script instead of using the psappdeploytoolkit.

  1. Because C:\Windows\SysWow64\OneDriveSetup.exe is owned by TrustedInstaller, change the ownership of the file
  2. Add temporary full NTFS permissions to OneDriveSetup.exe
  3. Override OneDriveSetup.exe with the current version
  4. Restore original ownership and NTFS permissions
  5. If a user is logged in, start OneDriveSetup.exe for current user
  6. If there are existing user profiles on the machine, create a runonce key in each users profile to start the update installation at the next logon

This is the code I used in the install section of the psappdeploytoolkit. Please note that it uses functions and variables from the toolkit, if you want to use it in your own native PowerShell script you need to replace them (Execute-Process vs. Start-Process, $envSystemRoot vs. $env:SystemRoot and so on).

## <Perform Installation tasks here>

# OneDriveSetup.exe is owned by TrustedInstaller, take ownership to replace file
Execute-Process -Path "$envSystem32Directory\takeown.exe" -Parameters "/f $envSystemRoot\SysWOW64\OneDriveSetup.exe"
# Grant full permissions for running user to replace file
Execute-Process -Path "$envSystem32Directory\icacls.exe" -Parameters "$envSystemRoot\SysWOW64\OneDriveSetup.exe /Grant `"$ProcessNTAccount`"`:(F)"
# Replace OneDriveSetup.exe with newer version
Copy-File -Path "$dirFiles\OneDriveSetup.exe" -Destination "$envSystemRoot\SysWOW64\OneDriveSetup.exe"
# Set ownership back to TrustedInstaller
Execute-Process -Path "$envSystem32Directory\icacls.exe" -Parameters "$envSystemRoot\SysWOW64\OneDriveSetup.exe /setowner `"NT SERVICE\TrustedInstaller`""
# Restore default permissions
If ($IsLocalSystemAccount) {
    # System account has read and execute permissions by default
    Execute-Process -Path "$envSystem32Directory\icacls.exe" -Parameters "$envSystemRoot\SysWOW64\OneDriveSetup.exe /Grant:r `"$LocalSystemNTAccount`"`:(RX)"
} else {
    Execute-Process -Path "$envSystem32Directory\icacls.exe" -Parameters "$envSystemRoot\SysWOW64\OneDriveSetup.exe /remove:g `"$ProcessNTAccount`""
# Run OneDriveSetup.exe for current user
Execute-Process -Path "$envSystemRoot\SysWOW64\OneDriveSetup.exe" -Parameters "/silent"

# Create runonce keys for all exisiting user profiles except default user (By default, there's a Run key in the default user profile) and except the running user
If ($(Get-UserProfiles -ExcludeDefaultUser)) {
    [scriptblock]$HKCURegistrySettings = {
            Set-RegistryKey -Key ‘HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce’ -Name ‘UpdateOneDrive’ -Value "$envSystemRoot\SysWOW64\OneDriveSetup.exe /silent" -Type String -SID $UserProfile.SID -ContinueOnError $true
    Invoke-HKCURegistrySettingsForAllUsers -RegistrySettings $HKCURegistrySettings -UserProfiles (Get-UserProfiles -ExcludeDefaultUser -ExcludeNTAccount $ProcessNTAccount)

You also need some settings to configure OneDrive for enterprise usage. You could use Group Policy, but again, if you want to achieve a really completed Windows installation after OSD, you’d prefer registry keys. With psappdeploytoolkit, it is also quite easy to add them to HKEY_CURRENT_USER.

  1. Disable sync of personal OneDrive accounts
  2. Enable enterprise update cadence*
  3. Remove OneDrive personal icon in Windows Explorer

This is how you can add those registry keys easily with the toolkit:

## Perform Post-Installation tasks here

[scriptblock]$HKCURegistrySettings = {

    # Disable sync of personal OneDrive accounts    
    Set-RegistryKey -Key ‘HKEY_CURRENT_USER\SOFTWARE\Microsoft\OneDrive’ -Name ‘DisablePersonalSync’ -Value 1 -Type dword -SID $UserProfile.SID -ContinueOnError $true
    # Enable enterprise update cadence
    Set-RegistryKey -Key ‘HKEY_CURRENT_USER\SOFTWARE\Microsoft\OneDrive’ -Name ‘EnableEnterpriseUpdate’ -Value 1 -Type dword -SID $UserProfile.SID -ContinueOnError $true
    # Remove OneDrive personal icon in Windows Explorer
    Remove-RegistryKey -Key 'HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Desktop\NameSpace\{018D5C66-4533-4307-9B53-224DE2ED1FE6}'

Invoke-HKCURegistrySettingsForAllUsers -RegistrySettings $HKCURecistrySettings

*Enterprise update cadence

This is the most annoying issue with OneDrive in managed enterprise environments. You cannot disable the automatic OneDrive update. With this registry setting, you’re just able to delay it by approximately 2 weeks and to avoid un-managed downloads by each and every client you need to be faster with your ConfigMgr deployments.

Choosing the right Windows 10 app store configuration

There are several options to configure the Windows 10 app store behaviour. In this post, I’d like to compare the different configurations with their implications. The following questions may come up in your Windows 10 project:

How to keep universal apps updated?
How to avoid un-managed download and installation of apps?
How to prevent the use of Microsoft accounts?

Computer configuration group policy for Windows 10 app store

In Computer Configuration – Administrative Templates – Windows Components – Store you can find the policy setting Turn off the Store application. If you set this one to enable, your users just see a notification that the app store is disabled on their system. The second important setting here is Turn off automatic Download and Install of updates.

Your Windows Store apps will never get any updates. Besides the general problems with outdated software, here are just two examples where this could lead to issues:

After installing language packs and Features on Demand and after correctly applying all localization settings, all universal apps on a fully localized Windows installation are still in English, because apps can not be updated when the store is disabled by computer policy.

The version of the OneNote universal app which is included in the Windows 1511 image only supports Microsoft accounts for login at the first app start (Azure AD accounts can only be added later). Presumably, since Windows 8 you don’t want your users to authenticate with Microsoft accounts 😉 Be aware, that even if you are installing the full OneNote 2016 application with Office 2016, you’ll need the OneNote universal app in order to use modern features of the Edge browser like making web notes, drawing on websites and stuff like that. Newer updated versions of the OneNote universal app support Azure AD accounts at first login.

User configuration group policy for Windows 10 appstore

In User Configuration – Administrative Templates – Windows Components – Store you can also find the policy setting Turn off the Store application. If you enable this setting, users still get a notification when opening the store application:

The store app is blocked

But compared to the computer configuration policy, you are now able to apply updates to universal apps on your Windows 10.

If you do not configure the computer policy Turn off automatic Download and Install of updates all of your Windows clients will download app updates from Microsoft directly. Especially in branch offices with bad WAN links this may impact your bandwidth dramatically. Just a few examples regarding app sizes: Calculator app – 6,1 MB, News app – 10MB, Mail and Calendar app – 148,9 MB. To avoid these downloads but keep your apps up-to-date, you can enable the computer policy and use Windows Store for Business to download an offline copy of the updated apps and deploy them via your ConfigMgr infrastructure or install them during your image creation process (your company needs an Azure tenant for the Windows Store for Business and app sideloading needs to be enabled in Windows).

MDM policy for app store

Unlike in Windows 10 Mobile, the Application Management/AllowStore setting in the Policy configuration service provider is not supported on desktops. You need no configure the AppLocker configuration service provider if you want to block the app store on desktops with MDM:

Group policy and MDM policy for private store

In Windows 10 Insider Preview Build 14295, Microsoft added a new group policy setting both for computer and user in Administrative Templates – Windows Components – Store: Only display the private store within the Windows store app. If you plan to use Windows store for Business you should choose this one, and users do not longer get the The app store is blocked notification:

2016-04-28 17_45_08-Store

The MDM setting ApplicationManagement/RequirePrivateStoreOnly is documented here:

Instead of using Group policy or MDM policy, you can disable the public store via registry, which works also on previous Windows 10 builds. In HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager\default\ApplicationManagement\RequirePrivateStoreOnly set value to 1:

2016-04-28 17_44_45-Registry Editor

Although the public store can not be accessed any longer, users are still able to enter a Microsoft account:

2016-04-28 17_45_24-

When they sign up with a Microsoft account, this error message comes up:

2016-04-28 17_50_02-

The most annoying issue here is that the added Microsoft account is visible in the store regardless of the error message. And when a users clicks on e.g. My Library, the store application crashes without any further error message:

2016-04-28 17_46_03-Store

Disable Microsoft accounts in Windows 10 app store with MDM policy and/or WMI

The group policy Accounts: Block Microsoft accounts in Computer configuration – Windows Settings – Security Settings – Local Policies – Security options which is already known from Windows 8 does not disable the usage of Microsoft accounts in the store application. You can configure this with the settings for Accounts/AllowMicrosoftAccountConnection and Accounts/AllowAddingNonMicrosoftAccountsManually in the Policy configuration service provider, which is documented here:

Fortunately, you don’t need a MDM solution but can enable these settings also via WMI. Here is the powershell code to create a new WMI instance for this:

$namespaceName = "root\cimv2\mdm\dmmap" 
$className = "MDM_Policy_Config01_Accounts02" 
New-CimInstance -Namespace $namespaceName -ClassName $className -Property @{ParentID="./Vendor/MSFT/Policy/Config"; InstanceID="Accounts"; AllowMicrosoftAccountConnection=0; AllowAddingNonMicrosoftAccountsManually=0} 

With this setting, users see still the option to add a Microsoft account to the store. But the error message is slightly different and most important: the Microsoft account does not appear in the store:

2016-04-28 17_58_17-

Combining the private store setting and blocking Microsoft accounts, users cannot browse the public app store and are not able to authenticate with any other account than their company Azure account.

Using this setting, Microsoft accounts are not only blocked in the store application. For example, the photos application also allows to enter a Microsoft account in order to sync all photos to a private OneDrive. You may decide on your own, if preventing this is a disadvantage or an advantage 😉

Users will see this message in the photos app:

2016-04-28 18_00_56-Photos_2

But keep in mind, that now it’s also impossible to add an (personal) email account to the built in Mail universal app.

Credit for the powershell script goes to Scott Breen, who published this on his blog in February 2016:


Group Policy, Registry, MDM and WMI offer completely different options to configure the Windows 10 app store. Each of them leads to a different result. Choose wisely 😉

Turn off app recommendations on Windows 10

This is again not quite new, but needs to be added here for the sake of completeness 🙂

2016-04-24 19_46_03-Mail

One of the first customizations of Windows 10 in the enterprise is probably to turn off app recommendations by Microsoft. This new feature displays suggested apps in the start menu like the good old Candy Crush Jelly Saga.

It can be turned off by group policy, MDM policy or registry. When you create a reference image, keep in mind that the reference client should not be connected to the internet. By the way, this is generally not recommended.

The group policy setting can be found here: Computer Configuration – Administrative Templates – Windows Components – Cloud Content: Set “Turn off Microsoft consumer experiences” to Enabled.

The MDM policy is documented here:

To configure it via registry, set the REG_DWORD value “DisableWindowsConsumerFeatures” to “1” here: HKLM\Software\Policies\Microsoft\Windows\CloudContent.

All credit goes to Michael Niehaus, who published this in his Technet Blog back in November 2015:

Infrastructure preparations for Windows 10

Let me start my series of Windows 10 posts with some basic information, even if most of it was already published earlier all around the internet. Anyway, it is a good summary and should be included in a blog about Windows 10 😉

In order to implement Windows 10 in your environment, these are the required prerequisites:

KMS server

If your KMS server is already running on Windows Server 2012 R2, install the KMS key for Windows 10. Further information can be found here:

If your KMS server is running on an older version of Windows, you can either install the required update:

Or seize the opportunity and upgrade your KMS server to Windows Server 2012 R2 (recommended)

Software Updates

Enable updates for Windows 10 in your WSUS server / ConfigMgr Software Update Point

Group Policies

Download the Group Policy templates for Windows 10 and add them to your Central Store (download link for Windows 10 1511):

Windows as a service

Windows as a service requires WSUS 4.0 (which means you need a Windows Server 2012 R2 server hosting the WSUS server / ConfigMgr Software Update Point). Note: ConfigMgr 1602 supports an inplace upgrade of Windows Server 2008 R2 to Windows Server 2012 R2.

Windows as a service also requires an update for WSUS:


Download and install the latest (!) Windows Assessment and Deployment Kit for Windows 10 1511:


If you are still running System Center Configuration Manager 2012 R2 SP1, first update your ConfigMgr hierarchy to ConfigMgr 1511 and finally to ConfigMgr 1602. Nevertheless, you can start implementing a Windows 10 Wipe and load deployment with ConfigMgr 2012 R2 SP1 and upgrade your hierarchy during your Windows 10 development phase.


If you are using MDT, update to MDT 2013 Update 2 (supports Windows 10 inplace upgrade task sequence):


If you are using MBAM to manage your Bitlocker-encrypted devices, plan the update to MBAM 2.5 SP1. Note: MBAM 2.5 already supports Windows 10, but MBAM 2.5 SP1 adds new features on Windows 10 devices like pre-boot recovery messages and the new MBAM clients supports Used Space Encryption: