The awesome world of child task sequences

Like last week I’m staying in the world of new features of Configuration Manager, version 1710. This time it’s all about the awesome world of child task sequences. Awesome. To be a bit more specific, the awesome world of child task sequences, which refers to the newly introduced task sequence step Run Task Sequence. This opens up a whole lot of options, from using specific standards throughout all deployments until enabling different administrators from maintaining their own child task sequence. In this post I’ll go through a short introduction about the Run Task Sequence step, followed by the configuration options for the Run Task Sequence step. I’ll end this post with the end result of running a child task sequence, by showing how it’s logged.

Introduction

Starting with Configuration Manager, version 1710, it’s possible to add a new task sequence step that runs another task sequence. That is the Run Task Sequence step. This creates a parent-child relationship between the task sequences. Child task sequences are enablers for creating modular and re-usable task sequences. Before starting with using child task sequences, make sure to be familiar with the following:

  • The parent and child task sequences are combined into a single policy;
  • The task sequence environment is global;
  • The status messages are sent for a single task sequence operation;
  • The child task sequence writes entries to the same smsts.log file (like a group);

Note: Make sure to go through the information mentioned in the More information section, as the second link provides useful information about the abilities.

Configuration

Now let’s have a look at the available configuration options for using the Run Task Sequence step. The four steps below walk through those configuration options. After that, the parent task sequence can be deployed like any other task sequence. However, when deploying a parent task sequence, be aware that the criteria for showing the “high-impact” warning is not detected in Software Center when the child task sequence contains the “high-impact” steps. In that case, use the User Notification properties of the parent task sequence to force the “high-impact” warning.

1 Open the Configuration Manager administration console and navigate to Software Library > Overview > Operating Systems > Task Sequences;
2 Now either create a new task sequence by using Home > Create > Create Task Sequence, or select an existing task sequence and select Home > Task Sequence > Edit to open the Task Sequence Editor;
3 In the Task Sequence Editor, select Add > General > Run Task Sequence;
4

TS_RunTaskSequenceIn the Run Task Sequence step, it’s as simple as browsing to the task sequence and selecting it.

Note: It’s not possible to select a task sequence that contains a boot image reference. The boot image reference has to be on the parent task sequence.

Note: Keep in mind that any chain containing a disabled task sequence will fail and that the Continue on error won’t work for that step containing the disabled task sequence.

Result

Let’s end this post by having a look at the end result. I’ll do that by looking at the smsts.log file and by looking at the deployment status in the Configuration Manager administrator console. When looking at the deployment status, see screenshot below, the first section shows the start of the parent task sequence and the second section shows the start of the child task sequence, like a group within a normal task sequence.

TS_StatusMessage

When looking at the smsts.log, something similar is shown, see screenshot below. The start of the child task sequence is shown like the start of a group within the parent task sequence.

TS_SMSTSLOG

More information

For more information about the Run Task Sequence step, please refer to the following articles:

Setting up kiosk mode on Windows 10 via OMA-DM

A while ago I did a blog post about managing AppLocker on Windows 10 via OMA-DM. During that post I showed how to use OMA-DM, via Microsoft Intune hybrid and standalone, to configure AppLocker. In this post I’ll do something similar for setting up kiosk mode on Windows 10. Windows 10 Enterprise and Windows 10 Education provide a configuration service provider (CSP) for setting up kiosk mode. That’s the AssignedAccess CSP.

During this blog post I’ll go through the AssignedAccess CSP, and its required input, I’ll go through the configuration steps in Microsoft Intune hybrid and standalone and I’ll show the end-user experience with the Twitter app as an example.

AssignedAccess CSP

Before using the AssignedAccess CSP it’s good to get a better understanding  of the CSP. The CSP is used to set up the Windows 10 device to run in kiosk mode. Once the CSP has been executed, then the next user login, that is associated with the kiosk mode, puts the Windows 10 device in the kiosk mode running the specified application. Let’s go through the nodes of the AssignedAccess CSP.

  • AA_CSP./Vendor/MSFT/AssignedAccess– Defines the root node for the AssignedAccess configuration service provider;
  • ApplicationLaunchRestrictions – Defines a JSON string that contains the user account name and the Application User Model ID (AUMID) of the Kiosk mode app
    • The JSON string should look like the following example: {“Account”:”CORP\\pvanderwoude”,”AUMID”:”9E2F88E3.Twitter_wgeqdkkx372wm!x554f661dyd360y462cy8743yf8a99b7d41dbx”}
    • The account name can be a domain account as well as a local account. When a local account is used, the domain name should be the name of the device;
    • The Application User Model ID (AUMID) can be easily received through PowerShell. The following example can help with collecting the information:
      foreach ($App in (Get-AppxPackage)) { foreach ($Id in (Get-AppxPackageManifest $App).package.applications.application.id) { Write-Output ($App.packagefamilyname + "!" + $Id) } }

Configuration

Now it’s time to use the AssignedAccess CSP to set up Windows 10 devices in kiosk mode. In this configuration I’m going to use the Twitter app as an example for my domain user account and I’m going to show the required configuration for Microsoft Intune standalone and hybrid.

Microsoft Intune hybrid

Let’s start with the configuration in Microsoft Intune hybrid. I’ll walk through the required steps to configure the required 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)
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

KioskModeAppIn 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/AssignedAccess/KioskModeApp
    9 In the Browse Settings dialog box, select the newly created setting and click Select to open the Create Rule dialog box;
    10

    KioskModeApp_RuleIn 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: {“Account”:”CORP\\pvanderwoude”,”AUMID”:”9E2F88E3.Twitter_wgeqdkkx372wm!x554f661dyd360y462cy8743yf8a99b7d41dbx”}
    • Select Remediate noncompliant rules when supported
    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 hybrid

    Let’s continue with the same configuration within Microsoft Intune standalone. I’ll walk through the required steps to configure the required 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

    KioskModeApp_SAIn 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/AssignedAccess/KioskModeApp
    • Value: {“Account”:”CORP\\pvanderwoude”,”AUMID”:”9E2F88E3.Twitter_wgeqdkkx372wm!x554f661dyd360y462cy8743yf8a99b7d41dbx”}
    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. After the device receives the new configuration and the configured end-user logs on, the end-user will receive a full screen Twitter app as shown below. The end-user won’t be able to close the Twitter app and can only get out of the kiosk mode by pressing Ctrl+Alt+Del. That will bring the end-user back to the logon screen.

    End-user experience
    TwitterApp

    More information

    Fore more information about kiosk mode on Windows 10, the AssignedAccess CSP and the AUMID, 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.

    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

    Reset passcode via the Company Portal website

    This week a blog post about the new ability in the Company Portal website to reset the passcode of a mobile device. Before only the administrator could reset the end-users’ passcode, but this has changed. Starting with the November update, of Microsoft Intune, a new option Reset Passcode is added to the Company Portal website. This option is available when the end-user is looking at the information of a specific mobile device.

    In this blog post I will go through the complete end-user experience. Starting with the end-user experience in the Company Portal website, followed by the end-user experience on the mobile device. I will end this post with a summarization per platform that will show the behavior of the (new) passcode.

    Also, a bit of topic, but this blog post was a good reason to verify my Remote Mobile Device Manager with the latest version of ConfigMgr and I can say that my Remote Mobile Device Manager fully works with ConfigMgr 1511!

    End-user experience in the portal

    Now, lets start with the end-user experience in the Company Portal website. The end-user can logon to any device and use a web browser to navigate to the Company Portal website. After that the end-user can select the device of which the password must be reset and simply following the step.

    Step Action
    1 Step1_ResetPasscodeIn the Company Portal website the end-user must select the mobile device and select Reset Passcode.
    2 Step2_SignOutAfter selecting Reset Passcode, the end-user will be prompted to sign out and sign in again. Select Sign out.
    3 Step3_ResetPasscodeAfter signing out and signing in again, within 5 minutes, the end-user will be prompted to reset the passcode. Select Reset Passcode.
    4 Step4_PendingAfter selecting Reset Passcode, the end-user will be notified that a Passcode reset is pending.
    5a Step5_Success_iOS_HSOn an iOS device, managed by Microsoft Intune standalone or Microsoft Intune hybrid, the end-user will be prompted within a few minutes with Passcode successfully reset.
    5b Step5_Success_WP_SOn a Windows Phone 8.1 device, managed by Microsoft Intune standalone, the end-user will be prompted within a few minutes with Passcode successfully reset and New Passcode: <Passcode>.
    5c

    Step5_Success_WP_HOn a Windows Phone 8.1 device, managed by Microsoft Intune hybrid, the end-user will be prompted within a few minutes with Passcode successfully reset.

    5d Step5_Success_Android_HSOn an Android device, managed by Microsoft Intune standalone or Microsoft Intune hybrid, the end-user will be prompted within a few minutes with Passcode successfully reset and New Passcode: <Passcode>.

    End-user experience on the mobile device

    After looking at the end-user experience in the Company Portal website its interesting to look at the end-user experience on the mobile device. Like with almost everything, the end-user experience is completely different on every platform. Below is the behavior shown, per platform, after the end-user has performed the reset passcode procedure.

    iOS Windows Phone 8.1 Android
    20151210_201907000_iOS wp_ss_20151210_0001 IMG-20151212-WA0001
    On an iOS device, the end-user will receive a message to change the passcode within 60 minutes. On a Windows Phone 8.1 device, the end-user will receive a message that the password was reset. On an Android device, the end-user will receive a notification that a new temporary passcode was set.

    End-user experience summarization

    The last thing that I want to provide is an overview, per platform and per scenario, about the passcode behavior. In the table below I will show what happens to the passcode and where the new passcode can be found. The scenario refers to Microsft Intune standalone and Microsoft Intune hybrid.

    Platform Scenario Behavior
    iOS Standalone and hybrid Removes the passcode from the device and gives the end-user 60 minutes to see a new passcode.
    Windows Phone 8.1 Standalone Creates a new numeric passcode that is shown to the end-user in the Company Portal website.
    Windows Phone 8.1 Hybrid Creates a new numeric passcode that is currently only available through the ConfigMgr console.*
    Android Standalone and hybrid Creates a new alphanumeric passcode, which is shown to the end-user in the Company Portal website.

    *At this moment the end-user experience on a Windows Phone 8.1 device, in a Microsoft Intune hybrid environment, is not working how it should be. The end-user has to contact the administrator to get the new passcode. Also, the administrator will only see the new passcode when a passcode reset has been performed before. If this is not the case, the administrator will have to perform another passcode reset to get the required new passcode for the end-user.

    More information

    For more information about the latest additions to Microsoft Intune, about the Company Portal website, or about my Remote Mobile Device Manager, please refer to:

    Enable modern authentication for Exchange Online

    ExchangeOnline_OauthThis blog post is about enabling modern authentication on Exchange Online. Modern authentication is a requirement for conditional access for PCs. For SharePoint Online that’s enabled by default and for Exchange Online that’s disabled by default. However, that configuration is now available via PowerShell. This post is meant to show how easy this can be achieved now. Before this had to be done by enrolling in to the preview program. Now it’s publically available.

    Why I’m posting about Exchange Online? Well, actually that’s quite simple, I can’t get around it. If I want to configure conditional access in Microsoft Intune standalone or hybrid, I often need to use Exchange Online. In this post I’ll go through five simple steps to connect, verify and configure modern authentication on Exchange Online.

    Connect to Exchange Online

    The first thing that is required is to connect to Exchange Online. The good thing about connecting to Exchange Online via PowerShell is that it doesn’t require the installation of any additional modules. Simply walkthrough the following three steps to get connected with Exchange Online.

    Step 1: Provide credentials

    The first step is to provide the admin credentials for the Office 365 tenant. This can be achieved fairly easy by using the Get-Credential cmdlet. That will show a Windows PowerShell credential request dialog box that can be used for providing these credentials.

    $O365Credential = Get-Credential

    Step 2: Create a new session

    The second step is to create a new remote session to Exchange Online. This can be achieved by using the New-PSSession cmdlet. The session can be created by using the provided credentials and by providing the URI mentioned below.

    $EOSession = New-PSSession -ConfigurationName Microsoft.Exchange ` -ConnectionUri https://outlook.office365.com/powershell-liveid/ ` -Credential $O365Credential -Authentication Basic -AllowRedirection

    Step 3: Import the new session

    The third step is to import the remote session. This can be achieved by using the Import-PSSesion cmdlet. That will import the remote commands to the current session by using providing the new session information. To connect the remote session again, simply use the Remove-PSSession cmdlet.

    Import-PSSession $EOSession

    Enable modern authentication

    The next thing is what this post is actually about, enabling modern authentication on Exchange Online. In two relatively simple steps it’s possible to verify the configuration and to enable modern authentication.

    Step 4: Verify the configuration

    The fourth step is to verify the current configuration of modern authentication. This can be achieved by using the Get-OrganizationConfig cmdlet. That will get the configuration data for the Exchange organization. In this case simply use a specific select to only get the OAuth* configuration.

    Get-OrganizationConfig | Select Name, OAuth*

    Step 5: Enable modern authentication

    The fifth step is to truly enable modern authentication. This can be achieved by using the Set-OrganizationConfig cmdlet. That can configure the various settings for the Exchange organization. One of the parameters OAuth2ClientProfileEnabled can be used to enable or disable modern authentication on Exchange Online.

    Set-OrganizationConfig -OAuth2ClientProfileEnabled:$true

    More information

    For more information about modern authentication, Exchange Online and PowerShell please refer to the following links:

    The new ability on iOS devices to send diagnostic information

    This week a short blog post about the new ability in the updated Microsoft Intune Company Portal app, for iOS, to send diagnostic information. Before it was always fun to explain somebody the method to get the Company Portal Diagnostic Information, as it would require the end-user to open the Microsoft Intune Company Portal app and simply start shaking the device. Actually, this is still a possibility to get the Company Portal Diagnostic Information.

    New in the latest update of the Microsoft Intune Company Portal app, for iOS, is the ability to send the Company Portal Diagnostic Information via the menu of the Microsoft Intune Company Portal app. This is a new Microsoft Intune Company Portal app ability and is not related to the iOS version.

    End-user experience

    Now let’s have a look at what the new end-user experience looks like. The end-user has to open the Microsoft Intune Company Portal app and simply walkthrough the following two steps.

    Step 1 Step 2
    IMG_0017 IMG_0018
    The first step is to click on the username and to select About. The second step is to click on Send Diagnostic Report.

    Note: After selecting Send Diagnostic Report an email will open, like with shaking the device, that includes the Company Portal-Log.log.

    More information

    For more information about the new features released in November, please refer to the following article: http://blogs.technet.com/b/microsoftintune/archive/2015/10/28/coming-soon-new-intune-features-including-windows-10-edp-policies.aspx