ConfigMgr 1511

This is another short and quick blog post. This time about the device enrollment manager in combination with the automatic enrollment in Microsoft Intune, which is powered by Azure AD. The device enrollment manager is a configuration within Microsoft Intune standalone, or Microsoft Intune hybrid (starting with ConfigMgr 1511). However, with really active use of the device enrollment manager, it is possible to run into some default configuration challenges. This post will provide a quick tip about those challenges.

Configuration

The documentation about the device enrollment manager contains a note that device enrollment manager user accounts, with more than 20 devices enrolled, might have problems using the Company Portal app. In case that potential problem is not an issue, for the usage within the company, it’s good to know that those 20 devices are not a hard limit to the maximum number of enrolled devices.

However, in case more than 20 devices must be enrolled, in combination with automatic device enrollment of Azure AD, make sure to adjust the following configuration. Without this adjustment problems will occur with the Azure AD join, simply because the default maximum number of devices is set to 20 per user.

This is a short and quick blog post to point out where to start with troubleshooting Windows 10 device enrollment issues and Windows 10 device management issues. To start with troubleshooting, it’s important to know where to find the information about the device enrollment issues and the device management issues. This short and quick post will show the location of that information, starting with Windows 10 build 1511.

Event Viewer

To find the information about the device enrollment issues and device management issues, starting with Windows 10 build 1511, simply perform the following steps:

This week a blog post with only one purpose, and that purpose is, providing an overview. Providing an overview about when devices will be blocked after enabling conditional access. That information is available in the TechNet documentation (see the More information section of this post), but it might be a bit difficult to find. As the question pops up in the TechNet forums at a regular basis, I got the suggestion that it would be a good idea to provide a quick, but clear, overview.

This post will provide nice tables, for Microsoft Intune standalone and Microsoft Intune hybrid, with the time it will take before a device will be blocked from Exchange. That information will be provided for two different setups and three different scenarios. A quick spoiler, the tables for Microsoft Intune standalone and Microsoft Intune hybrid are identical.

Overview

Let’s have a look at the mentioned overview tables for Microsoft Intune standalone and Microsoft Intune hybrid. However, before looking at the overview tables, it’s important to understand the following details about the scenarios.

After user setting up email profile – This scenario is applicable when the end-user wants to configure email on a device that is not enrolled;

After user enrolling blocked device – This scenario is applicable when the end-user wants to get email on a device that’s just enrolled, or just remediated;

After user un-enrolling device – This scenario is applicable when the end-user has un-enrolled its device.

A while ago I did a blog post about managing Windows Defender of Windows 10 via OMA-DM. During that specific post I showed how to use OMA-DM, via Microsoft Intune standalone and hybrid, to configure Windows Defender. In this post I’ll do something similar for AppLocker. However, I have to admit that it was a bit more challenging for AppLocker. The main difference is that Windows 10 includes many different separate policy settings for Windows Defender, but provides a separate configuration service provider (CSP) for AppLocker.

During this post I’ll show how to create the required AppLocker XML, what the AppLocker XML looks like, what the AppLocker CSP looks like and how to combine the AppLocker XML and the AppLocker CSP. I’ll end this post with the end-user experience. During this post I’ll use the build-in Windows 10 app Candy Crush Soda Saga as an example.

Create the AppLocker XML

The required AppLocker XML can be created by using the Local Security Policy snap-in, the Local Group Policy Editor snap-in or the Group Policy Management snap-in. Any of these snap-ins will work in a similar way for creating the required AppLocker XML. It doesn’t matter which snap-in is used, as long as it’s being used on a Windows 10 device. That makes it easier with configuring and selecting the required apps. During the following twelve steps, I’ll use the Local Group Policy Editor snap-in for configuring the Candy Crush Soda Saga app.

Right-click the AppLocker node and select Export Policy to open the Export Policy dialog box;

12

In the Export Policy dialog box, provide a name and location and click Save;

Inside the AppLocker XML

Now let’s have a look at the AppLocker XML that I just created. That AppLocker XML should look like the one shown below. It should show a default allow rule and a specific deny rule on the Candy Crush Soda Saga app, both within the RuleCollection element of the Appx type. That element of the AppLocker XML is what’s required during the further configurations.

Inside the AppLocker CSP

Before using the AppLocker CSP it’s good to get a better understanding of the different nodes. The AppLocker CSP contains nodes for the different configuration components of AppLocker. Let’s go through these different nodes.

./Vendor/MSFT/AppLocker – Defines the root node for the AppLocker configuration service provider;

Policy – Defines the policy for launching executable applications, Windows Installer files, scripts, store apps, and DLL files. The contents of this node is precisely the RuleCollection element as discussed in the previous paragraph.

Create AppLocker OMA-URI

Now it’s time to use the created AppLocker XML for configuring Windows 10 devices. The key with this is that only the RuleCollection element is required that matches with the node in AppLocker CSP. With the RuleCollection element of the Appx type, I need the StoreApp node in the AppLocker CSP. This is applicable to Microsoft Intune hybrid and standalone.

Microsoft Inune hybrid

Let’s start with the configuration in Microsoft Intune hybrid. I’ll walk through the required steps to configure the required OMA-URI configuration item.

Note: [MyGroup0] is a custom GUID that can be literally anything. That GUID makes sure that the un-enrollment of a device will behave as expected. Also, the complete RuleCollection element, about the Appx type, should be provided in the value configuration.

5

On the Create Policy page, click Save Policy to open the Deploy Policy dialog box;

6

In the Deploy Policy dialog box, click Yes to open the Manage Deployment dialog box;

7

In the Manage Deployment dialog box, select a group click Add and click OK.

End-user experience

Let’s end this post with the most important thing, the end-user experience. Actually, the end-user experience will be exactly the same as with a local or domain group policy configuration. The end-user will receive the message as shown below and the end-user can find messages in the Event Viewer. Those messages in the Event Viewer will wrongly indicate that the app is blocked by group policy.

End-user message

Event Viewer message

More information

Fore more information about how AppLocker works, AppLocker policies and the AppLocker CSP, please refer to:

This week a short blog post about an issue that I ran into, and tweeted about, the other week. Due to the strange error message I thought it would definitely be blog worthy. The error description was 22004: Unsupported certificate configuration. However, the actual issue did not come close to what the description would imply. This post will provide a brief overview of the scenario, the issue and the solution.

Scenario

Let’s start with a brief overview of the scenario. The environment contains Active Directory Federation Services (AD FS) and Web Application Proxy (WAP) for providing single sign-on (SSO) to the cloud services of Office 365 and Microsoft Intune. Microsoft Intune is used in a hybrid configuration with ConfigMgr and is fully configured to deploy certificate profiles. The required Network Device Enrollment Service (NDES) is published through WAP.

Issue

Now let’s have a look at the issue that I started seeing with deploying Certificate Profiles via Microsoft Intune hybrid to mobile devices. It is good to mention that it was working before. I started seeing the following combination of error messages on specific Certificate Profile settings.

Name

Type

Error Category

Error ID

Description

Certificate already issued

Setting

Discovery

0x87D17D04

22004: Unsupported certificate configuration

Certificate configuration parameters

Setting

Enforcement

0x87D1FDE8

Remediation failed

The first error message seems very straight forward. At least, assuming that it is accurate. However, as the Certificate Profile deployment was working before, I couldn’t imagine that the issue was related to the configuration of the certificate, certificate profile or certificate template.

I had to look further. The first thing I did was checking the external availability of NDES. I did that by checking the external URL of NDES, via https://externalFQDN/certsrv/mscep/mscep.dll. That external URL gave me an HTTPError 503. The service is unavailable error message. The logical second thing I did was checking the internal availability of NDES. I did that by checking the internal URL of NDES, on the WAP server, via https://internalFQDN/certsrv/mscep/mscep.dll. That internal URL gave me an expected 403 – Forbidden: Access is denied error message.

Now the issue is narrowed down to the publishing mechanism used for NDES.

Solution

In this case it turned out to be the Web Application Proxy Service service that was in a Stopped state. Simply starting the service again solved the issue. After looking a bit further, I noticed that the service initially failed to start due to connection issues with the AD FS server. By default, the service tries to restart twice. After the third failure the service won’t retry again. However, in this case the connection came back to life after the third failure of the service.

In case the HTTPError 503. The service is unavailable error message also shows while checking the internal URL of NDES, the problem is likely related to NDES itself. In that case the issue is likely related to the application pool, named SCEP, used by NDES.

A good summary would be that the 22004: Unsupported certificate configuration error message is often related to any HTTPError 503. The service is unavailable error message in the NDES publishing chain.

This week I’m back in ConfigMgr and I’m back with custom Terms and Conditions. A few months ago I did my latest post about custom Terms and Conditions. That post was completely focused on Microsoft Intune standalone. Starting with ConfigMgr 1511 it’s now also possible to deploy custom Terms and Conditions through Microsoft Intune hybrid.

Custom Terms and Conditions can be deployed to end-users to explain how device enrollment, access to work resources, and using the Company Portal affects them and their devices. End-users must accept the custom Terms and Conditions before they can use the Company Portal to enroll and access their company data.

In this post I’ll show how to create, deploy, update and monitor custom Terms and Conditions in Microsoft Intune hybrid. I’ll also briefly show the end-users experience. Keep in mind that custom Terms and Conditions are deployed to users and that users only need to accept the Terms and Conditions once, unless specifically configured in an updated version of the custom Terms and Conditions.

Configuration

Now let’s start with the configuration of custom Terms and Conditions. I’ll first go through the configuration steps to create custom Terms and Conditions, followed by the configuration steps to deploy custom Terms and Conditions and I’ll finish with the configuration steps to update the custom Terms and Conditions.

Create Terms and Conditions

The first configuration activity is creating the custom Terms and Conditions. This configuration activity can be performed by simply going through the following six steps.

Select the new custom Terms and Conditions and in the Home tab click Deploy to open the Deploy Terms and Conditions dialog box;

3

In the Deploy Terms and Conditions dialog box, specify the following information and click OK;

Name: [Grayed out]

Collection: [Select to the collection containing the required users]

Update Terms and Conditions

The last configuration activity is updating the custom Terms and Conditions. This is an optional activity that is only required when an update to an existing custom Terms and Conditions is required. This configuration activity can be performed by simply going through the following three steps.

Select the new custom Terms and Conditions and in the Home tab click Properties to open the Terms and Conditions Properties dialog box;

3

In the General tab and Terms tab, make the required updates, choose between the following options on the Terms tab and click OK;

Increase the version number, and require all users to accept the updated terms the next time they open the Company Portal: [Select this option when significant changes are made to the custom Terms and Conditions];

Keep the current version number, and require only new users to accept the updated terms: [Select this option when typos, or formats are fixed in the custom Terms and Conditions].

End-user experience

Before I’ll go to the reporting capabilities, for the custom Terms and Conditions, I think it’s important to first show the end-user experience. Depending on the number of targeted custom Terms and Conditions, the end-users can experience the behavior as shown below.

Single custom Terms and Conditions

Multiple custom Terms and Conditions

Reporting

Let’s finish this post with the reporting abilities of custom Terms and Conditions. Out-of-the-box there is one report available, named Terms and Conditions acceptance, that shows which user accepted which version of which custom Terms and Conditions. That report is available in the category Compliance and Settings Management and only shows the information about end-users that accepted the custom Terms and Conditions.

Filters

Report

This report can use the following filters:

Terms and Conditions: [Select a specific Terms and Conditions to display];

This week a short post about the settings in the Upgrade Operating System task sequence step and how these settings translate to the parameters used during the Windows 10 upgrade. I will go through the standard parameters, for the Windows 10 upgrade, used by the Upgrade Operating System task sequence step and I will go through the effect, of the configuration options in the Upgrade OperatingSystem task sequence step, on the Windows 10 upgrade parameters.

Configuration options

Now let’s start by having a look at the standard parameters for the Windows Setup of the Windows 10 upgrade, used by the Upgrade Operating System task sequence step. To do this, let’s start with an Upgrade Operating System task sequence step with only Upgrade package selected. That setting will translate to a command line like this: “C:\_SMSTaskSequence\Packages\PCP0000F\SETUP.EXE” /ImageIndex 1 /auto Upgrade /quiet /noreboot /postoobe “C:\WINDOWS\SMSTSPostUpgrade\SetupComplete.cmd” /postrollback “C:\WINDOWS\SMSTSPostUpgrade\SetupRollback.cmd” /DynamicUpdate Disable

Based on that command line it’s possible to see the standard configurations of the Upgrade Operating System task sequence step. By default the Upgrade Operating System task sequence step performs an upgrade of Windows and saves apps and data (/auto Upgrade), suppresses any Setup end-user experience (/quiet), instructs Windows Setup not to restart the computer after the down-level phase of Windows Setup completes (/noreboot), runs a script after the Setup is complete (/postoobe), runs a script if the end-user rolls back Windows (/postrollback) and disables the dynamic update operations (/dynamicupdate Disable).

Now let’s have a look at the effect of the remaining configuration options option of the Upgrade Operating System task sequence step. The following table lists the configuration option, the parameter that it translates to, and a short description.

Option

Command

Description

Source path

/InstallFrom

Specifies a local, or network path, to the Windows 10 media, that is to be used.

Product key

/PKey <ProductKey>

Specifies the product key to apply to the upgrade process.

Provide the following driver content to Windows Setup during upgrade

/Driver

Specifies the drivers that need to be added to the destination computer during the upgrade process.

Time-out (minutes)

N/A

Specifies the number of minutes Setup has to run before ConfigMgr will fail the task sequence step.

Perform Windows Setup compatibility scan without starting upgrade

/Compat ScanOnly

Specifies to perform the Windows Setup compatibility scan without starting the upgrade process.

Let’s start this new year with a blog post about the Configuration Manager console language. I have to admit that it doesn’t really sound like an exiting subject, but it can be very useful with troubleshooting. Most issues can easily be found, on the Internet, when using the English language, while many other languages can be a lot more challenging. In this blog post I’ll go through an overview of the Configuration Manager console language behavior, the installation of the English-only Configuration Manager console and the possibility of disabling any additional Configuration Manager console languages.

Note: This activities and theories in this blog post are successfully tested on ConfigMgr 2012 and ConfigMgr 1511.

Configuration Manager console language behavior

Now let’s start with an overview of the behavior of the Configuration Manager console language. During the site server installation, the Configuration Manager console installation files, and configured language packs, are copied to the <ConfigMgrInstallationPath>\Tools\ConsoleSetup subfolder on the site server.

When the installation of the Configuration Manager console is started from that folder, on the site server, the Configuration Manager console, and configured language pack files, are copied to the device. That will make sure that when a language pack is available for the currently configured language on the device, the Configuration Manager console opens in that language. If the associated language pack is not available, the Configuration Manager console will open in English.

Each time the Configuration Manager console opens, it determines the currently configured language on the device, verifies whether an associated language pack is available for the Configuration Manager console, and then opens the console by using the appropriate language pack.

Install English-only Configuration Manager console

After going through the standard behavior of the Configuration Manager console language. it is time to look at some minor adjustments. In case multiple languages were configured during the site server installation, it might be useful to know that it’s still fairly easy to only install the Configuration Manager console with the English language, regardless of the configured language on the device. To do this, simply perform the following steps and install the Configuration Manager console, on any device, in English-only.

On the site server, navigate to <ConfigMgrInstallationPath>\ Tools\ConsoleSetup\LanguagePack;

Rename the.msp and .mst files of the languages that should not be installed. In this example, I configured the Dutch language during the site server installation, which means that I should rename the following files.

ALP1043.msp to ALP1043.msp.disabled;

ALP1043.mst to ALP1043.mst.disabled.

Note: Keep in mind that when a new language is configured on the site server, the .msp and .mst files are recopied to the LanguagePack folder.

Disable Configuration Manager console language

After going through the installation of the Configuration Manager console in English-only, it might be good to know that it’s also possible to temporarily switch a Configuration Manager console to English. That can be very useful when the Configuration Manager console is installed with the currently configured language on the device and it must be opened in English for easier troubleshooting. To do this, simply perform the following steps and open the Configuration Manager console in English.

On the device that is running the Configuration Manager console, navigate to <ConsoleInstallationPath>\Bin\;

Rename the language folder of the language that is currently configured on the device. In this example, I installed en configured the Dutch language on the device, which means that I should rename the nl folder to nl.disabled.

Note: Keep in mind that when a repair is performed of the Configuration Manager console, the language folder is recopied to the Bin folder.

This week a blog post about one of the smaller new features of ConfigMgr 1511 and later. I want to devote this post to the new ability to easily download the content of a package during a task sequence. This ability is mainly introduced to work with the Windows 10 upgrade scenarios and the WinPE peer cache functionality. However, it can also be used to replace all the Run Command Line task sequence steps that were used to copy the content of normal Packages during a task sequence. In this post I’ll go through the different configuration options of that new ability, the Download Package Content task sequence step. I will also show an example in a task sequence and I will end with a look at the results in the smsts.log.

Configuration options

The Download Package Content task sequence step can download the content of Boot Images, Operating System Images, Operating System Upgrade Packages, Driver Packages and Packages. It also has the very nice option of Save path as variable, which can be used to easily store the location of the downloaded package content. When a variable is configured it has to be referred to in subsequence steps with a numerical suffix. That means that when ContentPath is used, as variable, it has to be referred to like ContentPath01. The order in the list determines the numerical suffix that’s used as reference.

Task Sequence working directory

The download location Task sequence working directory can be used at any moment after the Format and Partition Disk task sequence step. After that step the content will be kept and moved during the running time of the task sequence. The variable configured with Save path as variable will be updated when the location of the downloaded content has changed.

Configuration Manager client cache

The download location Configuration Manager client cache can be used at any moment after the Setup Windows and ConfigMgr task sequence step. When the ConfigMgr client is up-and-running, the content can be downloaded to its cache. The content will be available even after the task sequence is finished. This allows the client to act as a peer cache source for other peer cache clients. The variable configured with Save path as variable will be updated when the location of the downloaded content has changed.

Custom path

The download location Custom path can be used at any moment in the task sequence. However, keep in mind that the content will not be moved during the running time of the task sequence. Only the changes to the driver letter, due to reboots, will be updated in the variable configured with the Save path as variable. The content itself will be left untouched. When this option is used after the Setup Windows and ConfigMgr task sequence step, the content will be available after the task sequence is finished.

Task Sequence example

Now that the configuration options are clear, let’s go through a configuration example. That example will mainly show how to use the configured variable.

1

The first action is to download the content and to configure the download-to location. This can be achieved by selecting a number of packages, of the previously mentioned types, and by specifying the download-to location. To make accessing the content easier, select Sava path as a variable and use ContentPath as variable.

2

The second action is to use the content after it is downloaded. This can be achieved by using a Run Command Line step and using the ContentPath02 variable. That will refer to the downloaded content of the Set Image VersionPackage. Now simply refer to anything available within that Package.

Important: After saving the task sequence by clicking OK or Apply the list with packages will be rearranged by the letters of the alphabet. This will impact the numerical suffix that is needed to point to the right location. My advise is to save the task sequence before referring to the content.

Result

After going through all the configuration options and the task sequence example, it’s time to look at some results. Let’s have a look at how the first Package is handled by the OSDDownloadContent component, in the smsts.log, for the three different download locations.

Task sequence working directory

The download location Task sequence working directory is the easiest to handle for the task sequence. The task sequence will download the content to the C:\_SMSTaskSequence\Packages directory and set the ContentPath01 variable to the location of the first Package. After that it will add the ContentPath01 variable to the list of paths that need to be remapped on reboot.

Configuration Manager client cache

The download location Configuration Manager client cache requires a few additional actions. The task sequence will download the content to the C:\_SMSTaskSequence\Packages directory. After that it will stage the downloaded content to the client cache directory and set the ContentPath01 variable to the location of the first Package in the client cache. After that it will add the ContentPath01 variable to the list of paths that need to be remapped on reboot.

Custom path

The download location Custom path requires similar additional actions. The task sequence will download the content to the C:\_SMSTaskSequence\Packages directory. After that it will stage the downloaded content to, in this case, the C:\Temp folder and set the ContentPath01 variable to the location of the first Package in that folder. After that it will add the ContentPath01 variable to the list of paths that need to be remapped on reboot.

This time a short blog post as an answer to one of my tweets of yesterday. I’m afraid this post will take away all the flair of that tweet. The picture in that tweet looked so cool, but is actually also so simple to configure. The new Software Center will actually just take the Company Logo as configured in the Microsoft Intune Subscription Properties.

Configuration

Now let’s quickly go through the configuration. Assuming a Microsoft Intune Subscription is added, simply perform the following steps:

Navigate to the tab Company Logo, select Include company logo, Browse to the JPEG or PNG that should be used and click OK.

End-user experience

Let’s end this post with showing the end-user experience again. The end-user will see the newly configured Company Logo in the top-left corner of the new Software Center. That makes sure that the end-user will experience a similar look-and-feel on all its devices. Here is an example of the new Software Center next to the Company Portal app on iOS.

Award

Subscribe to updates

About

I’m Peter van der Woude, born in 1983 and I’m living together with my wife and two sons in the Netherlands.

Currently I work for KPN Consulting. At this moment my main focus is Enterprise Client Management via Microsoft Intune and/ or System Center Configuration Manager (ConfigMgr 2007/ 2012/ CB) and I love it!