CCMEXEC.COM – System Center blog

CCMEXEC.COM – by Jörgen Nilsson

Another post of mine on how to make Windows 10 1607 handle the way I like in an Enterprise is now live on the 4Sysops website.

Many enterprises would like to control and remove such notifications because they can confuse users and trigger unnecessary help desk calls. At the time of this writing, no Edge setting or Group Policy exists that allows admins to remove the Edge welcome page. Thus, I decided to dig in to how we can stop the page from showing.
Edge Welcome Page

It ended up being an Active Setup as the registry keys are not present when the user logons the first time, a user would hit the welcome page if they launch Microsoft Edge without login in/out once. I tried creating the whole structure but that didn’t feel right and could probably be something that bites back as that is for all modern apps and Microsoft Edge seemed to hang for me afterwards.

I hope it is useful!

Read the full post here:

I had to write a post on the new options we have in Windows 10 1607 and managing the items in the Taskbar, it is now live at where I am one of the authors. It covers how to deploy a custom taskbar during OS deployment, Group Policy, Powershell script and some lessons I learned so far when using it.

“The feature we used to deploy a customized Start menu in Windows 10 has been extended with the ability to manage pinned items on the Taskbar. There are some unsupported solutions for importing a Taskbar layout during OS deployment, including the one I wrote :-) However, now we can do it in a supported manner, and we can even add items using Group Policy after we create the user profile.

Windows 10 Taskbar

Note that this feature requires Windows 10 Enterprise/Education and it only works in Windows 10 1607.  (Editor’s note: There is some evidence that this feature works in Windows 10 Pro. Please share your experiences in a comment.) We cannot use this feature to remove items the user pinned to the Taskbar; we can only remove items from the Taskbar that we added with the new feature.

The Taskbar layout is configured in an .xml file either together with the Start menu layout or in a separate file. The .xml file can then be deployed using different tools according to which suits your organization best.”

Check out the whole post here:

I have written posts both about how to uninstall builtin apps in Windows 10 using Powershell and how to block them with Applocker before so this is just a note that you will need to use Applocker once more.
Now that Windows 10 1607 is here we have a new app called “Connect” which we cannot uninstall much like the Contact Support app.


The connect app turns your PC into a Miracast Receiver , which can be useful but not really in an enterprise.

If we try to uninstall it, we get the following message, that it is part of the Operating System and cannot be removed.

Remove Connect

We can block it using Group Policy as I have described before with the Contact Support app and Microsoft Feedback app.

If you are doing that already we only need to edit the Group Policy and add the following app as well. In the Group Policy add a new Package app rule for the Connect app

So we end up with the following rules together with the Contact Support app and Feedback app as I have in my Group Policy since Windows 10 1507 and 1511.

When deploying Windows 10 1607 the anniversary update for the first time I realized I need to be able to filter applications and also Task Sequence steps based on builds in the future. Why? Well I am lazy so I just copied my existing Windows 10 deployment Task Sequence and it failed when deploying applications as it included both the App-v client and the UE-V Client installations and those are now builtin Windows 10 and the installation will fail.

So here are two ways of creating a Global Condition that can be used as requirements for the different deployment types in the application model.

Global Condition using Buildnumber as a variable

This will give us the possibility to enter different Buildnumbers in the Deployment Type Requirements as shown below. So we can type 14393, 10586 or whatever we need it to evaluate on the clients for the deployment type to install.


Global4To create it do the following:

1.In the Configuration Manager Console we select Create Global Condition under Software Library/Application Management/Global Conditions

2. We use the values below


3. Done!

Global Condition using a specific Buildnumber

We can also create a Global Condition for a specific build number, so that we don’t have to type the build number in the deployment type Requirement like shown below when selecting it, we use the “Existential” option instead of string.


This is created in the following way:

1.In the Configuration Manager Console we select Create Global Condition under Software Library/Application Management/Global Conditions

2. The only difference is that now we enter the WQL Where query as well as shown below.


3. Done!

When we deploy the UE-V application to a Windows 10 1607 machine we get the following in the deployment status to verify that it works.
Global Condition

I hope it is useful!

Windows defender has become even better in the Windows 10 1607 release which is great! But it has also added a first-run dialog for each user that launches the Windows Defender UI.
Defender 1607

This is kind of annoying as it doesn’t check i the settings are already configured and a normal user doesn’t have permissions to turn it on as it requires local admin permissions. So after a little Regshot usage, the registry value that is set after you press close is the following: HKCU\Software\Microsoft\Windows Defender\UIFirstRun with a value of 0.
Defender1So by using a script or a Group policy preference as shown below we can disable that end-user dialog. I haven’t found it in the group policy settings for Windows 10 1607 which I think it actually should have been. Enterprises will want to turn this of. Defender2I hope that can be useful!

I just had to write this post as one of my User-voice items for Configuration Manager and favorite new feature is included in this release, the Company Logo is now displayed in end-user dialogs and Software Center.

What is new in Configuration Manager 1607 Technical Preview, you can read the full list here: but basically it is four things:

  • Customizable branding for end-user dialogs, this is so great! we get the same Company logo displayed in for instance restart dialogs as in Software center, defined in the Intune Subscriptions as we have done for mobile devices before.16073
    Configured under Intune Subscription, Company Logo 16074
  • Manage duplicate hardware identifiers, Makes it possible to add Mac or SMBIOS number under Hierarchy settings to exclude them from PXE Boot and Client Registration. It sure beats the hacks we had to do before!! Awesome! I really would still like a switch to ignore MAC address totally but this is really good!
  • Microsoft Operations Management Suite (OMS) connector, Syncs data to OMS, I haven’t had the time to test it out yet.
  • Windows 10 Edition Upgrade, makes it possible yo upgrade Windows 10 from Pro to Enterprise without media! Great!
    UPDATE: The client setting below is not the place where we configure it.

    Update: the client setting screen shown below doesn’t seem to do anything, it should be the already existing dialog that is under Compliance Settings and Windows 10 Edition Upgrade that should be used. However it is not working for me, troubleshooting it now, will update the post again.
    I will continue my testing of Configuration Manager 1607 all night, let’s see if there are more new features!

This solution has been created and tested by a colleague of mine Johan Schrewelius, he has done most of the work so I cannot give him enough credit for this. We have been using it for a while now and it works great, it is 100% unsupported ;-) as we change values on a read-only variables in the TS.

If you are using Configuration Manager 1610 or later there is now a supported built-in way to do this.

1         Background

The release of Windows 10 in combination with steadily increasing security demands means an operating system upgrade, or fresh install, today also includes security measures that not long ago where sort of luxury or only experimental.

Two major such are UEFI and Secureboot; a significant challenge as not even Configuration Manager 1602 supports a seamless transformation from Legacy Bios to UEFI.

This post describes our method of achieving the desired; one (1) Task Sequence that starts in Legacy mode and results in an UEFI configured computer with Secureboot enabled. A script and files for configuring HP computers have been included as example. No PXE boot is required as we boot from the local disk when we reboot. This is a short flow of what happens:

1. Configure Bios to UEFI and Secureboot using the tool for the vendor/model

2.Then we partition the local disk to GPT and format it

3.Copy an exported Boot image from a package to the local disk

4.Change the value for a read-only variable _SMSTSServiceStart using the 1E tool

5.Restart the computer and boot to the local installed Operating System

6.Change the second read-only variable _SMSTSBootUEFI to true and then the TS and all builtin steps for formatting will see that it is a machine running UEFI.

In the Task Sequence it looks like this:



To implement our solution, you need to download Legacy2Uefi as well as TSEnv2.exe from 1E ( 1E has been generous enough to share this powerful tool with us, and we cannot thank them enough.

2         Obstacles

There are two major obstacles that prevents us from achieving our goal using a standard TS.

Firstly, we will not be able to apply a boot-image nor an operating system to a GPT disk on what is detected as a MBR System.

Secondly, if we (which we nevertheless will do later) apply bootable media to disk by running a script we will not be able to restart the computer in a controlled fashion as built-in controls (smsboot.exe) will prevent this based on inconsistencies in TS configuration, i.e.  the TS-variable “_SMSTSServiceStartType” not being set to auto, which is required to allow rebooting to an installed operating system. Unfortunately, this variable is read-only and we cannot modify it using supported means. But what if we use unsupported means……

3         Read-only TS-variables < TSEnv2.exe

It is usually not recommended to use unsupported means; this however could be the time when circumstances call for it? TSEnv2.exe is able to modify read-only TS-variables and since that is what stands between us and a successful Legacy to UEFI transformation, that’s exactly what we are going to do.

TSEnv2.exe comes in both 32- and 64-bit versions, it is also depending on native Configuration Manager libraries, at least tscore.dll. This makes it reasonable to include it in our boot images using OSDInjection.

4         OSDInjection

To include TSEnv2.exe in already existing, as well as in new, boot images do the following on the primary site server or CAS that “owns” the images. And yes you can use the MDT feature as well to include the files when you create a new MDT Boot Image instead.

  1. Localize your ..\OSD\bin directory.
  2. Copy the corresponding version of TSEnv2.exe to the x64 as well as the i386 subfolder.
  3. Once the files have been copied we need to tell ConfigMgr to actually include them the next time an image is created or updated. This is done by editing “osdinjection.xml” which is found in ..\bin\x64:

Remark – there’s only one osdinjection.xml, not one per architecture.

Remember to Backup osdinjection.xml before editing.

osdinjection.xml holds the “recipe” for boot images and needs to be supplemented with information about the new files.

Open osdinjection.xml in notepad or similar.

As we know there’s already a native file with similar name (tsenv.exe) we will search for that and copy the section, thus avoiding misspelling.

First hit when searching should give you this:


Copy (duplicate) the section and replace the file name:


The result should look like this:

Repeat for x64 (second hit when searching for tsenv.exe):

Save and close osdinjection.xml. Next time a boot image is updated on distribution points TSEnv2.exe will be included.

5         Bootable media Package

As stated earlier we will apply bootable media to disk by script, therefor we will need to create a package containing the necessary files. Use the same procedure as when creating bootable media for use on a USB boot stick, then mount the iso-file and copy the entire content to a new folder on your package share.

Remark – you cannot reuse an old iso; it has to be “fresh” with TSEnv2.exe included.

Make sure to also include “copy.cmd” from

Create a package in ConfigMgr from the folder, do not create any program.

6         Task Sequence

At this point boot images should be updated and include TSEnv2.exe. We should also have a new package including the small copy.cmd command file. The rest of the work is done in the TS-editor, let’s start….

6.1       Create a new group

Create a new group, call it “Transform to UEFI”.

In our case we have a few extra conditions but as a minimum you should check that the machine isn’t already configured for UEFI (_SMSTSBootUEFI equals False).

The steps within in the group will be explained over the next couple of pages.

6.2       TS Steps

6.2.1      UEFI Config

This step will have to be adapted to local circumstances. It’s simply an example that shows how to reconfigure a HP Laptop to UEFI mode. contains a folder with only two files:

ConfigUEFI.ps1 is designed to utilize HP’s Bios Configuration utility, which is not included. You also need to create your BIOS password file with the HP tool.

uefi.txt contains a minimum of settings to configure UEFI with SecureBoot.

To make this fully operational more files are needed, these files must be added locally. If you’re an administrator with experience in HP computer this is hopefully enough information to get it working, this is a picture of a functional set of files:


As we prefer keeping bios config files on a network share the step looks like this at most of our customers:

Command: powershell.exe -NoProfile -ExecutionPolicy ByPass -File “%BiosShare%\%Model%\BCU\ConfigUEFI.ps1″

If your running Dell, Lenovo or any other brand – modify as needed. If you don’t have Powershell included in your boot images the script is useless and has to be replaced.

6.2.2      Partition Disk 0 – UEFI Simple

Use a standard “Format and Partition Disk” step to create a GPT disk with a minimal UEFI-compatible partition. The automatically assigned drive letter will be stored in “OSDisk”.

6.2.3      Copy Boot Media to Disk

This is a straight forward “Run Command Line” step that uses the media package and “copy.cmd” to copy the media (iso) content onto the new partition.

”OSDisk” contains the drive letter and tells copy.cmd where to put the content.

Command: copy.cmd %OSDisk%

6.2.4      SET _SMSTSServiceStartType=auto

Another “Run Command Line” step; that invokes TSEnv2.exe and sets ”_SMSTSServiceStartType” to ”auto”.

Command: TSEnv2.exe set _SMSTSServiceStartType=auto

6.2.5      Restart Computer

Next we restart the computer using a standard “Restart Computer” step. Because of the previous modification of the read-only TS-variable we will now be allowed to reboot to the currently installed default operating system, e.g. our media (iso).


6.2.6      SET _SMSTSBootUEFI=true

Finally, we need to modify a second read-only TS-variable. When the TS started the computer was running “Legacy BIOS” and “_SMSTSBootUEFI” was set to “false”.

We need to correct that, as we are now running in UEFI mode.

Command: TSEnv2.exe set _SMSTSBootUEFI=true

7         Done

The rest of the Task Sequence will after the reboot execute as UEFI, no PXE boot needed totally unattended, except for Lenovo Thinkcentre machines but that is a different topic.

When deploying Windows 10 1511 the builtin Onedrive client is now “old” and then it doesn’t support the same group policies as the new Onedrive Next Gen client does. Before we start some background information on the Onedrive client in Windows 10 1511.

  • The onedrive client is installed in this location in the users profile at first logon “C:\Users\%Username%\AppData\Local\Microsoft\OneDrive\Versionnumber”
  • It is installed from “C:\Windows\Syswow64\onedrivesetup.exe”OnedriveUpdate1
  • The command that is run is when the user first logs in is placed in the runonce registry key in the default user hive:
  • When a user first logs on to Windows 10 the Onedrive client is installed in the user profile and then it starts by updating itself to the latest version automatically.

However when a user is fast he/she can start the Onedrive client before the policies are applied that is why I started updating the Onedrivesetup.exe file during OS deployment then I know it is the latest version and it uses the “new” group policies and it is a bit faster for the end user as well.

It is really simple just replace the OnedriveSetup.exe file during OS deployment.

  1. Download the latest version of the Onedrive client
  2. Create a folder in your packagesource folder and place the Onedrivesetup.exe file in that folder.
  3. Create a simple .cmd file in the same folder with the below content will do the trick.
    %SYSTEMROOT%\system32\takeown /f %SYSTEMROOT%\SysWOW64\OneDriveSetup.exe >> %SYSTEMROOT%\logs\Onedrive.log
    %SYSTEMROOT%\system32\icacls %SYSTEMROOT%\SysWOW64\OneDriveSetup.exe /Grant System:(F) >> %SYSTEMROOT%\logs\Onedrive.log
    Copy %~dp0onedrivesetup.exe %SYSTEMROOT%\SysWOW64\OneDriveSetup.exe >> %SYSTEMROOT%\logs\Onedrive.log /Y
  4. Create a Package/program in Configuration Manager
  5. Add it to your Task Sequence

After deployment the Onedrive client will never popup at first logon with the message  that “An Update is being installed” and it will honor the “new” Group Policy settings as well. If they are configured correctly the user will be prompted to logon instead as shown below, and if you disabled “Personal” Onedrive it will not be permitted to use either.