CCMEXEC.COM – System Center blog

CCMEXEC.COM – by Jörgen Nilsson

Provisioning packages in Windows 10 is a really cool new feature which has great potential both for configuring Windows 10 and to assist in the deployment. Configuration Manager vNext has a great new feature as well which is Bulk enrollment of Windows 10 devices, Technical Preview 3 support Windows 10 Desktop edition, but let us all hope it will support Windows 10 Mobile as well when it is released. It is great news that we will get Bulk enrollment of Windows 10 devices!

It can be used to import a Trusted Root certificate, Wi-Fi Profile and enroll the device either in the cloud or On-Prem MDM which is new as well in Configuration Manager vNext. Panu and Kent has written a great blog post on how to get started with On-Prem MDM in Configuration Manager vNext Technical Preview, I had the same issue as they are explaining as well that my CRL lists where not accessible to non-domain clients and then you cannot enroll a Windows 10 using the MDM agent in Windows 10.

What I will focus on here is the new Bulk Enrollment feature. It is configured in the Configuration Manager vNext Admin Console, before we start note the following:

  • Configuration Manager vNext Technical preview must be installed and configured to support On-Prem MDM
  • You MUST start the Console with right-click and “Run as Administrator” otherwise creation of the Provisioning Package will fail.
  • A Trusted Root Certificate must be imported before starting the wizard under Compliance Settings, Company Resource Acess, Certificate Profiles.

Under All Corporate-owned Devices we have a new option under Windows, Enrollment profile.


We select Create Enrollment Profile in the menu. In the next dialog we can choose either On-Premise or Cloud.


We select which proxy enrollment point the Windows 10 client we run the provisioning package on should use.


We select the Root Certificate that should be imported as part of the enrollment process so that the Windows 10 client trust the certificate that is used for the roles in the Configuration Manager site that uses HTTPS.





Now we have a enrollment profile that we want to export to a provisioning package, that is achieved by selecting the enrollment profile and select export.


Then we have two files in that folder which makes up the provisioning package.


We then copy the files to a USB drive or locally on the Windows 10 computer and launch the provisioning package and we are presented with a dialog with what the package will do to the client.


After launching it we wait a minute before we open Work Access under Settings, Account in the Windows 10 client. There we now can see that the enrollment process is successful. Note that as it is enrolled as a Corporate owned device it has no username associated with it.


The provisioning package created can be opened using the Windows Imaging and Configuration Designer, you will get a warning that not all settings can be read.
bulkwicd After opening it we can see which feature in WICD that is used to do the Bulk enrollment which is shown below.

bulkwicd1I am really looking forward to when we can start using this live to enroll Windows 10 devices in Intune and Configuration Manager vNext ON-Prem MDM will be really cool. Then we can have a single provisioning package that can configure the device and enroll it in Intune. :D

In my last post I wrote about how to make Internet Explorer the default web browser in Windows 10, now I will cover how to deploy a customized Start Menu during deployment and add a menu item for Internet Explorer the last took a while to figure out how to add the shortcut to Internet Explorer. There are many more ways to customize the Start Menu, deploy it as a mandatory Start Menu using Group Policies in that case the user cannot modify it.

Let’s start with the basic information, the default Start Menu template is located here:

C:\Users\%username%\AppData\Local\Microsoft\Windows\Shell\DefaultLayouts.xml this file should not be modified. To modify the start menu we use file called LayoutModifications.xml that should reside in the same directory. This file can be used in many ways for OEM’s to add icons to the Start Menu or for us IT-Pro to override the default Start Menu. More information on how to use these files can be found here on MSDN:

Exporting a customized Start Menu layout

To export the Start Menu we start by using a computer and a user and adjust the Start Menu on that computer so it looks the way we want it.


Then we use Powershell to export a customized start menu using the following command, Export-Startlayout –path C:\Windows\Temp\Startmenu.xml


Then we have a .xml file with our current Start Menu Layout that looks like below that will override the default start menu defined in the DefaultLayouts.xml in Windows 10.


Import a Start Menu layout using Powershell

Now that we have an exported Start Menu we can import it using Powershell. All users that log on to the machine the first time will get this Start Menu layout that you import.

Import-StartLayout –LayoutPath C:\Windows\Temp\Startmenu.xml -MountPath $env:SystemDrive\


After the command is successfully completed the Layoutmodification.xml file is created here: C:\Users\Default\AppData\Local\Microsoft\Windows\Shell\Layoutmodification.xml


When we log on to the computer as a “new” user that haven’t logged on the computer before we get the newly imported Start Menu as shown below.


But wait, where did the Internet Explorer icon that we added before go?

Solving the Internet Explorer icon issue

When we export the file above it exports the Internet Explorers ApplicationID in the .xml file. This will fail when you import it as the Internet Explorer icon doesn’t exist in the users Start Menu folder or as an application during when the Start Menu is imported. It doesn’t exist in the Default start menu folder either and it is not present as an ApplicationID when the Start Menu is imported and therefor it will not show up in the users Start Menu.

To solve this we need to do two things, add a .lnk file that points to Internet Explorer somewhere that all end-users can reach it. I will create it in C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Accessories


Then we need to change the information in the exported .xml file as well. The following line in the .xml file needs to be replaced with a pointer to the .lnk file instead of the ApplicationID.


So we replace it with the following line instead, using the DesktopApplicationLinkPath instead and pointing to the Internet Explorer.lnk file we created before.

DesktopApplicationLinkPath=”%ALLUSERSPROFILE%\Microsoft\Windows\Start Menu\Programs\Accessories\Internet Explorer.lnk”

If we then log on as a new user once again we get the Internet Explorer icon on the Start Menu as well as intended.


Applying the Start Menu during OS deployment

To deploy this I have written a simple Powershell script that imports the StartMenu.xml file and copies the Internet Explorer link we created before.

The Powershell Script content:

Import-StartLayout -LayoutPath $PSScriptRoot\StartMenu.xml -MountPath $env:SystemDrive\

Copy-Item -Path $PSScriptRoot'\Internet Explorer.lnk' -Destination $env:SystemDrive'\ProgramData\Microsoft\Windows\Start Menu\Programs\Accessories'

I then place the Powershell script in a folder together with the exported Start Manu and the Internet Explorer.lnk file.
Then we create a package of that folder in Configuration Manager with no program as we use the Powershell step in the Task Seqeunce to execute it and distribute it to the Distribution Points. And add a step in the task sequence to run the Powershell script as shown below.

Then you are ready to test the deployment of a customized start menu including an Internet Explorer icon.

I have had this request a couple of times now, on how to make Internet Explorer the default browser in Windows 10. I think Microsoft Edge is and will be a great browser and the most secure browser out there but in some scenarios Internet Explorer is still required to be the default browser.

Here is how to export the associations from one Windows 10 computer and then import them during OS deployment on the target computer which is the way to do it. It exports all file associations so it can be used for 3rd party applications as well.

To export the file associations from a computer running Windows 10 do the following.

  1. Log on to the computer as a user that is local administrator and open Settings and then System
  2. Under Default Apps mark the Web Browser and click Microsoft Edge, then you get an option on which browser to use instead, select Internet Explorer
  3. Then open and Command Prompt with Run as administrator.
  4. In the command prompt type, the following command to export the file associations.
    C:\WINDOWS\system32>Dism.exe /online /Export-DefaultAppAssociations:C:\Windows\Temp\DefaultApps.xml
  5. In the C:\Windows\Temp we now have a file with the default associations.

To import the file associations during OS deployment when deploying Windows 10 the following steps are needed. The easiest way is to use a .cmd file and the “%~dp0” variable that gives us the path to the folder the .cmd file is executed from.

  1. Create a folder in your source folder structure that can be used as a package source for the Default Apps Association package.
  2. Copy the DefaultApps.xml file we just created to that folder
  3. Create a new file in the folder called DefaultApps.cmd with the following content
    Dism.exe /online /Import-DefaultAppAssociations:%~dp0Defaultapps.xml
  4. Then we have the following files in that folder
  5. Create a Package in Configuration Manager and use the folder created as the source folder. Do not create a program. By using Run Command line, it is easier to add more .xml files so that we can import different files based on different roles or purpose for the target computer.
  6. In your OS deployment Task Sequence create a new “Run Command Line” step somewhere after the “Setup Windows and Configuration Manager” step.
  7. Then you are ready to test deploy a Computer and test the updated Default Associations

This procedure is the same as it was for Windows 8 / Windows 8.1 and can be applied to Adobe Reader as well for instance or other 3rd party applications as well.

Yesterday an update was released to the Technical Preview 3 version of Configuration Manager vNext. A really cool update which is distributed using the new Updates and Servicing feature. First the end-users will love the new Software Center, one unified place instead of two and no more Silverlight!


The next cool thing in the update is how it is delivered. It is delivered using the new Update and Servicing feature in the Preview. It will look like this. In the console under the Update and Servicing branch we now see that an update is available.
We have two choices, Install Update pack or Run Prerequisite check.


I choose the Install Update Pack option and here are the screenshots of how it will look like.



Next is an interesting choice if we want to upgrade all clients directly without testing or use the test new version with a pre-production collection.



Done! But what happens next? Well the upgrade actually starts and the progress can either be tracked in the console. If we look at the update it is now changed state to Installing and we can in the bottom of the screen we can select Show Status.

cmvnexttp3u11Really cool, but for us who like to use CMtrace or Notepad if you want instead ;-)

The pre-req part uses the same log files as the setup of Configuration Manager so you can follow it in ConfigMgrSetup.log and ConfigMgrPrereq.log.

For the update installation itself can be tracked and troubleshooted in the following log file, CMUpdate.log


What about the console on the Configuration Manager Server? It is updated automatically the next time you open the console :-)

The new way to handle this kinds of updates are really cool and it works really well. Well I have only installed it three times but it has worked so far :D

Just a quick post to announce that our recordings from System Center User Group online meetings in June on “Enterprise Mobility Suite” and in September on “ConfigMgr vNext TP3 + Windows 10″ are now available on our YouTube channel, they are both in Swedish…

SCUG.SE – Sept 2015 – ConfigMgr vNext TP3 + Windows 10

SCUG.SE – June – Enterprise Mobilty Suite


One new feature in Configuration Manager vNext is a new Task Sequence step called: “Download Package Content”. It does what the name implies and could be one of my new small favorite features in Configuration Manager vNext. It will be useful to download content in a controlled way that later on can be used by scripts, applications installations.

There are a few options for the step on where you want the content located, the following are the options:

  • Task Sequence Working Directory
  • Configuration Manager Client Cache
  • Custom Path

To be able to choose the location is a really cool feature as we don’t want to fill up the Client Cache for instance.

It is also possible to set a task sequence variable containing the location of the downloaded package as show below.


So where does the files end up on the client in the example above? In the C:\Windows\temp directory?
Yes, in the C:\Windows\Temp folder and a folder with the PackageID as shown below.


The variable we created is available in the Task Sequence just as expected as shown in the variable dump below.

DownloadContent2This will be a very useful new Task Sequence step in the upcoming version of Configuration Manager which will at least get rid of some of the Xcopy and Robocopy steps out there. It would have been even better if it was possible to tick a box that it should copy the package content to in this case C:\Windows\temp and not a sub-folder with the packageID as name.

I wrote a handy little VBscript a couple of years ago that can be triggered by a Status Filter Rule to automatically distribute packages as soon as they are created to a Distribution Point. When upgrading to MDT 20213 Update 1 I missed this so I re-wrote it in Powershell. The script is triggered by a Status Filter Rule and then distributes the content to the DP group that is configured in the Powershell script. I am lazy I know ;-)

Below is the script, change the $DPgroup variable to the name of your DP group.
It can also be configured with the $CopyToShare variable to configure the package to be available on the package share if that is used. I used it in some environments to speed up OS deployment and use the “Access content directly” option for the Task Sequence when bandwidth is no issue. Save the script in a folder on the Primary Site server.




$DPgroup = "All DP"

$CopyToShare = $False

import-module $env:SMS_ADMIN_UI_PATH.Replace("bin\i386","bin\ConfigurationManager.psd1") -force

[String]$SiteCode = $(Get-WMIObject -ComputerName “$ENV:COMPUTERNAME” -Namespace “root\SMS” -Class “SMS_ProviderLocation”).SiteCode

new-psdrive -Name $SiteCode -PSProvider “AdminUI.PS.Provider\CMSite” -Root “$ENV:COMPUTERNAME” -Description “SCCM Primary Site”

Set-Location “$SiteCode`:”

# Configure the package to be availble on DP Share

if($CopyToShare) {

Set-CMPackage -Id $PackageID -CopyToPackageShareOnDistributionPoints $True -ErrorAction SilentlyContinue


# Add to distributionpoint group

Start-CMContentDistribution –PackageID $PackageID –DistributionPointGroupName $DPgroup


import-module $env:SMS_ADMIN_UI_PATH.Replace("bin\i386","bin\ConfigurationManager.psd1") -force
[String]$SiteCode = $(Get-WMIObject -ComputerName “$ENV:COMPUTERNAME” -Namespace “root\SMS” -Class “SMS_ProviderLocation”).SiteCode
[String]$DPgroup = "All DP"
new-psdrive -Name $SiteCode -PSProvider “AdminUI.PS.Provider\CMSite” -Root “$ENV:COMPUTERNAME” -Description “SCCM Primary Site”
Set-Location “$SiteCode`:”
# add to distributionpoint group
Start-CMContentDistribution –PackageID $PackageID –DistributionPointGroupName $DPgroup

The Status filter rule we need to create will look like this, trigger on Message ID: 30000


For the Actions to run, the following command line needs to be used like shown below.

C:\Windows\System32\WindowsPowerShell\v1.0\Powershell.exe -NoProfile -ExecutionPolicy ByPass -File E:\Scripts\Addtodp.ps1 “%msgis02″

The variable %msgis02% will be used to pass the package ID to the script from the Status Message.

StatusFilterRule2Then you are all done, no more forgetting to add a package to a DP anymore.

I wrote a blog post earlier about how to uninstall built-in apps from Windows 10 CBB using Powershell, however some apps cannot be uninstalled like Microsoft Edge, Contact Support and Windows Feedback.

They can be blocked using Applocker instead that is the best workaround I have found. Blocking them using an Applocker policy is working really well, if the user never logged on to the computer before the Applocker policy is applied the application, in this case Contact support is not installed for the user at all and therefor not present either on start or by using search which is really great!

If the user have logged on to the computer before the Applocker policy is applied the applications is present but the user can no longer start it, and will get the below message displayed.
BlockContactSupport10So this method could be used instead of uninstalling the apps as the end result for the end-user is basically the same if they haven’t logged on to the computer before the policy is applied.

The challenge with that right now is there is no RSAT for Windows 10 available yet so creating the policy is a a bit of a challenge. So I ended up creating the Applocker policy locally on a Windows 10 computer and then export it and then import it on a Windows 2012 R2 server with the Group Policy Management MMC installed.

Here are the steps for creating a Group Policy to block Contact Support, the same steps would be used to block Microsoft Edge and Windows Feedback if that is a requirement for you as well.

1. Create a new Group Policy for this test.

2. Under Computer Configuration\Policies\Windows Settings\Security Settings\System Services change the startup to Automatic for the Application Identity Service. This service must be started for the Applocker policies to be enforced on the client computers.

3. On a Windows 10 computer running the Enterprise version start Group Policy Editor by typing Edit Group Policy in the search Taskbar.

4. Under Computer Configuration\Windows Settings\Security Settings\Application Control Policies\Applocker right-click and select Properties and enable Packaged app Rules and select Enforce rules.

5. Then we need to create two Packaged app Rules one default rule to allow all apps to run and one rule to block the Contact Support app in this scenario.

6. Right-Click Packaged app Rules and select Create default Rules, this will create a rule that allows all signed apps to be executed. Note that this setting only applies to Apps and not Win32 applications.
BlockContactSupport3 7. Then we create a new Package app Rule by right-clicking Packaged app Rules and select Create New Rule

BlockContactSupport28. On the next screen we select to Deny this app to run for Everyone.

9.  Then select Use and installed packaged app as a reference and click select.
BlockContactSupport5 10. In the next dialog select the apps you want to block, in my case the Contact Support app, then select OK, and Create

11. Now we have a policy created locally on the Windows 10 computer with the correct policy shown below.


12 In the Applocker node in Group policy editor Right-Click and select Export policy. Save the file on a share so you can access it from the computer where you are running the Group Policy Management MMC.
BlockContactSupport7 13. On the computer running the Group Policy Management MMC edit the Group Policy we created in AD in step 1 and under Applocker in the group policy editor select Import Policy and import the policy exported from the Windows 10 computer.
BlockContactSupport814. You will be prompted that it will overwrite all existing policies.
BlockContactSupport9Now we have a policy that can be deployed to Windows 10 that will block the Contact Support app!

Time to start testing.