Quick tip: Working with the device enrollment manager and automatic enrollment

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.

  • MaxDevicesIn the Microsoft Azure
    portal, navigate to ACTIVE DIRECTORY >
    [Directory];
  • Select the CONFIGURE tab and scroll down to the devices section;
  • Adjust the number with MAXIMUM NUMBER OF DEVICES PER
    USER
    .

More information

For more information about the device enrollment manager, in Microsoft Intune standalone and hybrid, and automatic enrollment, please refer to:

Quick tip: Troubleshooting device management failures on Windows 10

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:

  • DM_EventViewerOpen the Event Viewer and navigate to Applications and Services Logs > Microsoft > Windows > DeviceManagement-Enterprise-Diagnostics-Provider;
  • Select the Admin node to show the available events;
  • (Optional) Select View > Show Analytic and Debug Logs to enable the ability to generate debug logging;
  • (Optional) Right-click the Debug node and select Enable Log to enable detailed logging.

Note: When automatic device enrollment is configured with an Azure AD join, the User Device Registration node will provide helpful information for everything before the device enrollment.

More information

For more information about troubleshooting mobile device management failures on Windows 10 devices, please refer to Diagnose MDM failures in Windows 10.

When are devices blocked after enabling conditional access?

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.

Microsoft Intune standalone

Below is the overview table for Microsoft Intune standalone.

After user setting up email profile After user enrolling blocked device After user un-enrolling device
Exchange Online Device is blocked immediately Device is unblocked within 2 minutes Device is blocked after around 6 hours
Exchange on-premises Device is blocked after around 1-3 hours Device is unblocked within 2 minutes Device is blocked after around 1-3 hours

Note: The legacy Exchange Online Dedicated is identical to Exchange on-premises.

Microsoft Intune hybrid

Below is the overview table for Microsoft Intune hybrid.

After user setting up email profile After user enrolling blocked device After user un-enrolling device
Exchange Online Device is blocked immediately Device is unblocked within 2 minutes Device is blocked after around 6 hours
Exchange on-premises Device is blocked after around 1-3 hours Device is unblocked within 2 minutes Device is blocked after around 1-3 hours

Note: The legacy Exchange Online Dedicated is identical to Exchange on-premises.

More information

For more information about managing email access via Microsoft Intune standalone or Microsoft Intune hybrid, please refer to:

Managing AppLocker on Windows 10 via OMA-DM

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.

1 In the Local Group Policy Editor snap-in, navigate to Local Computer Policy > Computer Configuration > Windows Settings > Security Settings > Application Control Policies > AppLocker;
2 In the Configure Rule Enforcement section, click Configure rule enforcement to open the AppLocker Properties;
3 AppLockerPropertiesIn the AppLocker Properties, enable Configured with Package app Rules, select Enforce rules and click OK to return to the AppLocker node;
4 Right-click the Packaged app Rules node and select Create Default Rules;
5 Right-click the Packaged app Rules node and select Create New Rule to open the Create Package app Rules wizard;
6 On the Before You Begin page, click Next;
7 On the Permissions page, select Deny and click Next;
8 AppLockerAppOn the Publisher page, select Use an installed packaged app as a reference and click Select to open the Select application dialog box;
9 In the Select applications dialog box, select Candy Crush Soda Sage, click OK to return to the Publisher page and click Next;
10 On the Exceptions page, click Next;
11 On the Name and Description page, click Create;
10 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.

<AppLockerPolicy Version="1"> <RuleCollection Type="Exe" EnforcementMode="NotConfigured" /> <RuleCollection Type="Msi" EnforcementMode="NotConfigured" /> <RuleCollection Type="Script" EnforcementMode="NotConfigured" /> <RuleCollection Type="Dll" EnforcementMode="NotConfigured" /> <RuleCollection Type="Appx" EnforcementMode="Enabled"> <FilePublisherRule Id="a9e18c21-ff8f-43cf-b9fc-db40eed693ba" Name="(Default Rule) All signed packaged apps" Description="Allows members of the Everyone group to run packaged apps that are signed." UserOrGroupSid="S-1-1-0" Action="Allow"> <Conditions> <FilePublisherCondition PublisherName="*" ProductName="*" BinaryName="*"> <BinaryVersionRange LowSection="0.0.0.0" HighSection="*" /> </FilePublisherCondition> </Conditions> </FilePublisherRule> <FilePublisherRule Id="8ea1fe67-536d-4324-99e2-88f9c9c70321" Name="king.com.CandyCrushSodaSaga, version 1.58.0.0 and above, from king.com" Description="" UserOrGroupSid="S-1-1-0" Action="Deny"> <Conditions> <FilePublisherCondition PublisherName="CN=F80C3B33-B9E8-4F23-AB15- B97C700EFF2F" ProductName="king.com.CandyCrushSodaSaga" BinaryName="*"> <BinaryVersionRange LowSection="1.58.0.0" HighSection="*" /> </FilePublisherCondition> </Conditions> </FilePublisherRule> </RuleCollection> </AppLockerPolicy>

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.

  • AppLockerAppLaunch./Vendor/MSFT/AppLocker – Defines the root node for the AppLocker configuration service provider;
  • ApplicationLaunchRestrictions – Defines restrictions for applications;
  • Grouping – Defines dynamic nodes. These nodes contains a GUID naming that can be literally anything. That GUID makes sure that the un-enrollment of a device will behave as expected;
  • EXE | MSI | Script | StoreApps | DLL | CodeIntegrety – Defines restrictions for launching executable applications, Windows Installer files, scripts, store apps and DLL files;
  • 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.

1 In the Configuration Manager administration console, navigate to Assets and Compliance > Overview > Compliance Settings > Configuration Items;
2 On the Home tab, click Create Configuration Item to open the Create Configuration Item Wizard;
3

On the General page, specify the following information and click Next;

  • Name: [Specify a unique name for the configuration item]
  • Description: [Specify details that help identifying the configuration item]
  • Select Windows 8.1 and Windows 10 with Settings for devices managed without the Configuration Manager client.
4

On the Supported Platforms page, select the following platforms and click Next;

  • All Windows 10 (64-bit)
  • All Windows 10 (32-bit)
  • (Optional) All Windows 10 Mobile and higher
5 On the Device Settings page, select Configure additional settings that are not in the default settings groups and click Next;
6 On the Additional Settings page, click Add to open the Browse Settings dialog box.
7 In the Browse Settings dialog box, click Create Setting to open the Create Setting dialog box;
8

AppLockerSettingIn the Create Setting dialog box, specify the following information and click OK to return to the Browse Settings dialog box;

  • Name: [Specify a unique name for the setting]
  • Description: [Specify details that help identifying the setting]
  • Setting type: OMA-URI
  • Data type: String
  • OMA-URI (Case Sensitive): ./Vendor/MSFT/AppLocker/ApplicationLaunchRestrictions/[MyGroup0]/StoreApps/Policy

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.

9 In the Browse Settings dialog box, select the newly created setting and click Select to open the Create Rule dialog box;
10

AppLockerRuleIn the Create Rule dialog box, specify the following information and click OK to return to the Browse Settings dialog box;

  • Name: [Specify a unique name for the rule]
  • Description: [Specify details that help identifying the
    rule]
  • Rule type: Value
  • The setting must comply with the following rule: Equals
  • the following values: <RuleCollection Type=”Appx” EnforcementMode=”Enabled”>[…]</RuleCollection>
  • Select Remediate noncompliant rules when supported

Note: The complete RuleCollection element, about the Appx type, should be provided in this compliance rule configuration.

11 In the Browse Settings dialog box, click Close to return to the Additional Settings page;
12 On the Additional Settings page, click Next;
13 On the Platform Applicability page, click Next;
14 On the Summary page, click Next;
14 On the Completion page, click Close;

Note: This created a configuration item that can be deployed like any other configuration item, as a part of a configuration baseline.

Microsoft Intune standalone

Let’s continue with the same configuration within Microsoft Intune standalone. I’ll walk through the required steps to configure the required OMA-URI configuration policy.

1 In the Microsoft Intune administration console, navigate to Policy > Configuration Policies and click Add to open the Create a New Policy dialog box;
2 In the Create a New Policy dialog box, select Windows > Custom Configuration (Windows 10 Desktop and Mobile and later) and click Create Policy to open the Create Policy page;
3

On the Create Policy page, specify the following information in the General section and click Add in the OMA-URI Settings section to open the Add or edit OMA-URI Setting dialog box;

  • Name: [Specify a unique name for the policy]
  • Description: [Specify details that help identifying the policy]
4

AppLockerSetting_InIn the Add or edit OMA-URI Setting dialog box, specify the following information and click OK to return to the Create Policy page;

  • Setting name: [Specify a unique name for the setting]
  • Setting description: [Specify details that help identifying the setting]
  • Data type: String
  • OMA-URI (case sensitive): ./Vendor/MSFT/AppLocker/ApplicationLaunchRestrictions/[MyGroup0]/StoreApps/Policy
  • Value: <RuleCollection Type=”Appx” EnforcementMode=”Enabled”>[…]</RuleCollection>

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
AppLocker_OMA_URI AppLockerEventId

More information

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

Certificate profile deployment failed with the error ‘22004: Unsupported certificate configuration’

Tweet_NDESThis 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

Env_OverviewLet’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 HTTP Error 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 HTTP Error 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 HTTP Error 503. The service is unavailable error message in the NDES publishing chain.

Custom Terms and Conditions

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.

1 In the Configuration Manager administration console, navigate to Assets and Compliance > Overview > Compliance Settings > Terms and Conditions;
2 On the Home tab, click Create Custom Terms and Conditions to open the Create Custom Terms and Conditions Wizard;
3

On the General page, specify the following information and click Next;

  • CustomTandC._GenName: [Specify a unique name for the custom Terms and Conditions]
  • Description: [Specify details that help identifying the custom Terms and Conditions]
4

On the Terms page, specify the following information and click Next;

  • CustomTandCTitle: [Specify the title that will be displayed to the end-users in the Company Portal]
  • Text for terms: [Specify the custom Terms and Conditions that will be displayed to the end-users in the Company Portal]
  • Text to explain what it means if the user accepts: [Specify a short explanation that will be displayed to the end-users in the Company Portal]
5 On the Summary page, click Next;
6 On the Completion page, click Close.

Deploy Terms and Conditions

The second configuration activity is deploying the custom Terms and Conditions to an user collection. This configuration activity can be performed by simply going through the following three steps.

1 In the Configuration Manager administration console, navigate to Assets and Compliance > Overview > Compliance Settings > Terms and Conditions;
2 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;

  • CustomTandC_DeplName: [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.

1 In the Configuration Manager administration console, navigate to Assets and Compliance > Overview > Compliance Settings > Terms and Conditions;
2 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;

  • CustomTandC_EditIncrease 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
IMG_0013 IMG_0014

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];
  • User filter: [No function];
  • User Name: [Select a specific user to display].
CustomTandC_Report

More information

For more information about creating, deploying, updating and monitoring custom Terms and Conditions, please refer to:

How the settings in ConfigMgr translate to the command line of the Windows 10 upgrade

DefaultSettingsThis 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 Operating System 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.
Ignore any dismissible compatibility messages /Compat IgnoreWarning Specifies that Setup completes the installation, ignoring any dismissible compatibility messages.
Dynamically update Windows Setup with Windows Update /DynamicUpdate Enable Specifies whether setup will perform dynamic update operations, such as search, download, and install updates.
Override policy and use default Microsoft Update N/A Specifies to temporarily override the local policy in realtime to run dynamic update operations and have the computer get updates from Windows Update.

Note: When dynamic update is enabled, ignore warnings is not allowed. That results in the task sequence ignoring the /compat switch.

More information

For more information about the Windows 10 upgrade and the different task sequence steps, please refer to:

Managing the Configuration Manager console language

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.

  • DisableLanguageCentralOn 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.

  • DisableLanguageLocalOn 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.

More information

For more information about managing the Configuration Manager console language, please refer to the following article: https://technet.microsoft.com/en-US/library/mt605315.aspx#BKMK_ManageConsoleLanguages

Download package content during a task sequence

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 DownloadPackageContentThe 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 DownloadPackageUsageThe 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 Version Package. 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.

petervanderwoude.nl

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.

SMSTS_CCMCache

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.

SMSTS_CTemp

More information

For more information about this new task sequence step, please refer to the following article: https://technet.microsoft.com/en-us/library/mt629396.aspx#BKMK_DownloadPackageContent

Company logo in the new Software Center

SoftwareCenter_TwThis 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:

  • MISPIn the Configuration Manager administration console navigate to Administration > Overview > Cloud Services > Microsoft Intune Subscriptions;
  • Select Microsoft Intune Subscription and click Properties;
  • 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.

New Software Center Company Portal app
SoftwareCenter_LF IMG_0004