Reporting Windows Defender health on Windows 10 via OMA-DM

About a year ago I did a blog post about managing Windows Defender on Windows 10 via OMA-DM, by using the available policies in the Policy CSP. This week I’m going to have another look at Windows Defender, on Windows 10, but this time from a reporting perspective. This time I want to report about the health of Windows Defender on the Windows 10 devices that are managed via OMA-DM. To get that type of information I can use the Defender configuration service provider (CSP). The Defender CSP contains the information about the health of Windows Defender.

During this blog post I’ll go through the Defender CSP, the required configuration to get the Windows Defender health information and the administrator experience.

Defender CSP

DefenderCSPBefore starting with the required configuration to get the information about the health of Windows Defender, it’s good to have a quick look at the Defender CSP. That CSP is used to configure various Windows Defender actions across the enterprise. More specifically, I will go through the Health node. That node contains the information about the Windows Defender health status that I’m looking for.

  • ComputerState: This node provides the current state of the device;
  • DefenderEnabled: This node shows if the Windows Defender service is running;
  • RtpEnabled: This node shows if the real-time protection is running;
  • NisEnabled: This node shows if the network protection is running;
  • QuickScanOverdue: This node shows if a Windows Defender quick scan is overdue;
  • FullScanOverdue: This node shows if a Windows Defender full scan is overdue;
  • SignatureOutOfDate: This node shows if the Windows Defender signature is outdated;
  • RebootRequired: This node shows if a reboot is required;
  • FullScanRequired: This node shows if a Windows Defender full scan is required;
  • EngineVersion: This node shows the version number of the Windows Defender engine;
  • SignatureVersion: This node shows the version of the Windows Defender signatures;
  • DefenderVersion: This node shows the version of Windows Defender;
  • QuickScanTime: This node shows the time of the last Windows Defender quick scan;
  • FullScanTime: This node shows the time of the last Windows Defender full scan;
  • QuickScanSigVersion: This node shows the signature version used during the last quick scan;
  • FullScanSigVersion: This node shows the signature version used during the last full scan.

Configuration

Now it’s time to start with the required configuration to enable the ability to report about the Windows Defender health of Windows 10 devices managed via OMA-DM. However, it’s good to note that this is currently only possible in Microsoft Intune hybrid, as we need to extend the inventory on Windows 10 devices.

The Health node of the Defender CSP contains exactly the information that I’m looking for and that I would like to add to the inventory of my Windows 10 devices. Luckily, in a Microsoft Intune hybrid environment I can extend the hardware inventory to include specific OMA-URI settings. OMA-URI settings that can be added to the hardware inventory are shown, in the picture above, in a rectangular shape (and are documented with a supported Get operation).

All of the available settings, in the Health node of the Defender CSP, support the Get operation. If I want to add a custom class to the hardware inventory, with all the the available settings of the Health node, I can use the following in a MOF file.

[ SMS_Report (TRUE),
   SMS_Group_Name (“PTCLOUD Windows10 DefenderHealth”),
   SMS_Class_ID (“MICROSOFT|Windows10_DefenderHealth|1.0”),
   Namespace (“Reserved”),
   SMS_DEVICE_URI (“”) ]


class Windows10_DefenderHealth : SMS_Class_Template
{
     [SMS_Report (TRUE), SMS_DEVICE_URI(“WM:./Vendor/MSFT/Defender/Health/ComputerState”)]
      String ComputerState;
     [SMS_Report (TRUE), SMS_DEVICE_URI(“WM:./Vendor/MSFT/Defender/Health/DefenderEnabled”)]
      Boolean DefenderEnabled;
     [SMS_Report (TRUE), SMS_DEVICE_URI(“WM:./Vendor/MSFT/Defender/Health/RtpEnabled”)]
      Boolean RtpEnabled;
     [SMS_Report (TRUE), SMS_DEVICE_URI(“WM:./Vendor/MSFT/Defender/Health/NisEnabled”)]
      Boolean NisEnabled;
     [SMS_Report (TRUE), SMS_DEVICE_URI(“WM:./Vendor/MSFT/Defender/Health/QuickScanOverdue”)]
      Boolean QuickScanOverdue;
     [SMS_Report (TRUE), SMS_DEVICE_URI(“WM:./Vendor/MSFT/Defender/Health/FullScanOverdue”)]
      Boolean FullScanOverdue;
     [SMS_Report (TRUE), SMS_DEVICE_URI(“WM:./Vendor/MSFT/Defender/Health/SignatureOutOfDate”)]
      Boolean SignatureOutOfDate;
     [SMS_Report (TRUE), SMS_DEVICE_URI(“WM:./Vendor/MSFT/Defender/Health/RebootRequired”)]
      Boolean RebootRequired;
     [SMS_Report (TRUE), SMS_DEVICE_URI(“WM:./Vendor/MSFT/Defender/Health/FullScanRequired”)]
      Boolean FullScanRequired;
     [SMS_Report (TRUE), SMS_DEVICE_URI(“WM:./Vendor/MSFT/Defender/Health/EngineVersion”)]
      String EngineVersion;
     [SMS_Report (TRUE), SMS_DEVICE_URI(“WM:./Vendor/MSFT/Defender/Health/SignatureVersion”)]
      String SignatureVersion;
     [SMS_Report (TRUE), SMS_DEVICE_URI(“WM:./Vendor/MSFT/Defender/Health/DefenderVersion”)]
      String DefenderVersion;
     [SMS_Report (TRUE), SMS_DEVICE_URI(“WM:./Vendor/MSFT/Defender/Health/QuickScanTime”)]
      String QuickScanTime;
     [SMS_Report (TRUE), SMS_DEVICE_URI(“WM:./Vendor/MSFT/Defender/Health/FullScanTime”)]
      String FullScanTime;
     [SMS_Report (TRUE), SMS_DEVICE_URI(“WM:./Vendor/MSFT/Defender/Health/QuickScanSigVersion”)]
      String QuickScanSigVersion;
     [SMS_Report (TRUE), SMS_DEVICE_URI(“WM:./Vendor/MSFT/Defender/Health/FullScanSigVersion”)]
      String FullScanSigVersion;
};

This MOF file can be used to extend the hardware inventory by simply performing the following steps in the Configuration Manager console.

1 In the Configuration Manager console, and navigate to Administration > Overview > Client Settings;
2 Open the Default Client Settings, navigate to Hardware Inventory and click Set Classes;
3

WindowsDefenderInvIn the Hardware Inventory Classes, click Import and Open the new MOF file.

This will add the new class for the inventory and will show it between the existing classes.

Also note that the dataldr.log will show the creation of the new class.

Result

Now let’s end this post with the most important thing, the visualization. The extension to the hardware inventory will make sure that the information about the Windows Defender health is reported by Windows 10 devices that are managed via OMA-DM. It will add the information, like every extension to the hardware inventory, to a custom table, with it’s own custom view, in the database. That will make it relatively easy to create a custom report, as shown below, to display the information in a readable form to the administrative users.

Administrator experience
WDExampleReport

Also, keep in mind that the information will also be available in the Resource Explorer, of the Configuration Manager console, for the Windows 10 devices that are managed via OMA-DM.

More information

Fore more information about the Defender CSP and the Policy CSP, please refer to:

Conditional access, Windows 10 and Microsoft Intune: What are the compliance options?

Recently Microsoft released a couple of blog posts about The Path to Modernizing Windows Management and about Clear & Simple Guidance: When ConfigMgr and Intune should be used with Windows 10, which should be really helpful with deciding how to managing the Windows 10 devices within an organization. I would really recommend everybody to read those posts. This blog post will not be directly related, but will continue on a more detailed level about the options for conditional access and Windows 10 devices.

In this blog post I will provide nice tables of the different compliance rules, for Windows 10 devices, that are currently available for Microsoft Intune standalone and Microsoft Intune hybrid. In those tables I’ll show the different management scenarios and the currently available applicable compliance rules.

Overview

Before I’ll start with the overview, it’s good to provide a short explanation about the distinction between the conditional access policy and the compliance policy.

The conditional access policy is a required configuration to enable conditional access on a particular service and to help secure access to that particular service. In the conditional access policy, the targeted platforms and the targeted users of devices are configured. Also, important for Windows 10 devices, in the conditional access policy it is possible to determine if Windows 10 devices must be compliant or domain joined.

The compliance policies, on the other hand, are optional additional rules that can evaluate settings like PIN and encryption. The devices of targeted users must be compliant to those additional rules. When there are no compliance policies deployed, the device will automatically be evaluated as compliant.

Microsoft Intune standalone

Now let’s start with the overview of available compliance rules in Microsoft Intune standalone. In Microsoft Intune standalone, a Windows 10 device can be managed by the Microsoft Intune client and it can be enrolled as a mobile device. Those two options will be mentioned in the following overview table. Spoiler, there are no compliance rules available for the Microsoft Intune client. That makes being domain joined the only additional configuration for those devices.

Intune client MDM
Allow simple passwords N/A Yes (Mobile only)
Maximum Windows Phone or Windows 10 Mobile version N/A Yes (Mobile only)
Maximum Windows version N/A Yes (Desktop only)
Minutes of inactivity before password is required N/A Yes
Minimum password length N/A Yes
Minimum Windows Phone or Windows 10 Mobile version N/A Yes (Mobile only)
Minimum Windows version N/A Yes (Desktop only)
Require a password to unlock an idle device N/A Yes (Mobile only)
Password expiration N/A Yes
Remember password history – Prevent reuse of previous passwords N/A Yes
Required password type – Minimum number of character sets N/A Yes
Require a password to unlock mobile devices N/A Yes (Mobile only)
Require devices to be reported as healthy N/A Yes
Require encryption on mobile device N/A Yes

Microsoft Intune hybrid

Let’s continue with the overview of available compliance rules in Microsoft Intune hybrid. In Microsoft Intune hybrid, a Windows 10 device can be managed by the Microsoft Intune client, the ConfigMgr client and it can be enrolled as a mobile device. Those three options will be mentioned in the following overview table. Spoiler, there are no compliance rules available for the Microsoft Intune client. That makes being domain joined  the only additional configuration for those devices.

Intune client ConfigMgr client MDM
All required updates installed with a deadline older than X days N/A Yes N/A
Allow simple passwords N/A N/A Yes (Mobile only)
File encryption on mobile device N/A N/A Yes
Maximum operating system version N/a N/A Yes
Minimum classification of required updates N/A N/A Yes
Minimum operating system version N/A N/A Yes
Minimum password length N/A N/A Yes
Minutes of inactivity before password is required N/A N/A Yes
Require a password to unlock an idle device N/A N/A Yes (Mobile only)
Reported as healthy by Health Attestation Service N/A N/A Yes
Require Antimalware N/A Yes N/A
Require BitLocker drive encryption N/A Yes N/A
Require password settings on mobile devices N/A N/A Yes
Require registration in Azure Active Directory N/A Yes N/A

More information

For information about about conditional for Windows 10 devices with Microsoft Intune standalone or Microsoft Intune hybrid, please refer to:

Conditional access and health attestation

This week another blog post about conditional access. And another blog post that is triggered by a feature that is introduced in ConfigMgr 1602. However, this time it’s about a feature that already did exist in Microsoft Intune standalone. I’m talking about the new conditional access rule that uses the Health Attestation Service. This new rule creates the ability to ensure that Windows 10 devices have trustworthy BIOS, TPM, and boot software configurations enabled.

In this blog post I’ll show the detailed configuration steps for Microsoft Intune hybrid and I’ll briefly note the most important configurations for Microsoft Intune standalone.

Introduction

Device health attestation is an additional level of restricting access to Exchange Online and SharePoint Online for Windows 10 devices. Currently only available for Windows 10 devices that are managed via OMA-DM. It adds the ability to create compliance policies that require Windows 10 devices to report as healthy. Device health attestation can be used to ensure that the following trustworthy configurations are enabled:

  • BitLocker: BitLocker provides encryption for all data stored on the Windows operating system volume.
  • Code integrity: Code Integrity provides improvements to the security of the operating system by validating the integrity of a driver, or system file, each time it is loaded into memory.
  • Early-launch antimalware (only applies to PCs): Early launch anti-malware (ELAM) provides protection for computers when they start up and before third-party drivers initialize.
  • Secure boot: Secure boot provides a security standard, which is developed by members of the PC industry, to help make sure that a PC boots with only software that is trusted by the PC manufacturer.

Note: A Windows 10 device must be compliant to all of the applicable configurations to be reported as healthy by the Health Attestation Service.

Pre-configuration

Before looking at the configuration of conditional access and device health attestation, I will begin with mentioning a new client setting and the health attestation dashboard. This is at least as important, as it will provide a good understanding about the impact of using conditional access based on the status reported by the Health Attestation Service.

Default client settings

To start with collecting information about the status, reported by the Health Attestation Service, of Windows 10 devices, it’s good to start with enabling the communication with the Health Attestation Service,. The following 2 steps will make sure that the information will be collected.

1 In the Configuration Manager administration console, navigate to Administration > Overview > Client Settings and open the Default Client Settings;
2

CA_ClientSettings_HAIn the Default Client Setting, navigate to Computer Agent and select Yes with Enable communication with Health Attestation Service and click OK to close the Default Client Settings..

Health attestation dashboard

After configuring the Default Client Settings, the information of the Health Attestation Service, on Windows 10 devices, will start showing in the health attestation dashboard and the List of devices by Health Attestation state report. This information can be used to get a good understanding about the impact of enabling conditional access based on the  status reported by the Health Attestation Service. The health attestation dashboard is available by navigating to Monitoring > Overview > Security > Health Attestation and will look like the following example.

CA_Intune_HealthAttestation

Note: In Microsoft Intune standalone similar reports are available, in the Reports section, named Health Attestation Reports.

Configuration

Let’s continue with looking at the real configuration for conditional access. I will start with briefly mentioning the conditional access policy and I’ll end this configuration section with going through all the required steps for creating the compliance policy.

Conditional access policy

Now that I know what the impact will be of using the health of a Windows 10 device, reported by the Health Attestation Service, I can start with enabling conditional access. Just like last week, I’ll only mention the conditional access policy briefly. It’s important that the setting Windows must meet the following requirements is selected and configured to Devices must be compliant. Also, for supporting Windows 10 mobile, it’s important to also select Windows 10 Mobile. These settings can be configured as shown below for Exchange Online and SharePoint Online.

Exchange Online Policy SharePoint Online Policy
CA_ExchOnl_Win10 CA_SPOnl_Win10

Compliance policy

Like last week, the more interesting configuration is the configuration of the new compliance policy. The following 9 steps will go through the creation of the compliance policy. After the creation of the compliancy policy, it can be deployed, like any other policy, to users.

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

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

  • CA_ConfigMgrIntune_CP_GeneralName: [Specify a unique name for the compliance policy]
  • Description: [Specify details that help identifying the compliance policy]
  • Select Compliance rules for devices managed without the Configuration Manager client with Specify the type of compliance policy that you want to create
    • Select Windows 8.1 and Windows 10

Note: Select Windows Phone and Windows 10 Mobile for supporting the configuration on Windows 10 Mobile devices.

4

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

  • CA_ConfigMgrIntune_CP_PlatformAll Windows 10 (64-bit)
  • All Windows 10 (32-bit)

Note: Select All Windows 10 Mobile and higher for supporting the configuration on Windows 10 Mobile devices.

5 On the Rules page, click New… to open the Add Rule dialog box;
6

ICA_ConfigMgrIntune_CP_AddRulen the Add Rule dialog box, select the Reported as healthy by the Health Attestation Service rule and click OK to return to the Rules page;

7

CA_ConfigMgrIntune_CP_RulesBack on the Rules page, verify the created configuration and click Next;

8 On the Summary page, click Next
9 On the Completion page, click Close.
CA_Intune_CompliancePolicyNote: In Microsoft Intune standalone a similar compliance policy setting is available, in the Device Health section, named Require devices to be reported as healthy.

End-user experience

Now it’s time to look at the end-user experience. This time I won’t show the end-user experience of a non-compliant device connecting to Exchange Online, or SharePoint Online, as it’s similar to the messages shown during last weeks post. This time I’ll only show the end-user experience in the Company Portal app on a Windows 10 Desktop device and a Windows 10 Mobile device. The messages will be similar as shown below. It will not just show a non-compliant device, it will actually show which configuration is reported as not healthy by the Health Attestation Service.

Non-compliant Compliant
CA_Intune_CompanyPortal CA_Intune_CompanyPortal2
wp_ss_20160319_0001 wp_ss_20160319_0002

More information

For more information about conditional access, Windows 10 device health attestation and the HealthAttestation CSP, please refer to:

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:

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:

Many reasons to look at ConfigMgr 1511

ConfigMgr1511At this moment Microsoft has just released System Center Configuration Manager (version 1511). This build was released to MSDN subscribers last week and is now general available and publically announced by Microsoft. During this blog post I will refer to this release as ConfigMgr 1511.

In this blog post I will post my five main reasons to start looking at ConfigMgr 1511 as soon as possible. This will be followed by a list with great improvements that could also be good reasons to start looking. Before I start with all those reasons it might be worth mentioning that it’s possible to do an in-place upgrade of ConfigMgr 2012 to ConfigMgr 1511. This process will feel similar to a service pack upgrade.

Main reasons

Lets start with my main reasons to start looking at ConfigMgr 1511 as soon as possible. Of course everybody can have their own main reasons, but I really do think that the following five reasons can be very beneficial to every company.

Reason 1: Full support of Windows 10

R1_Windows10My first reason is, probably for many companies the main driver for upgrading or migrating to ConfigMgr 1511, the Windows 10 servicing support. A great blog post about the Windows 10 support in the different version of ConfigMgr can be found here. A brief summary would be that ConfigMgr 2012 supports servecing Windows 10 LTSB 2015 and Windows 10 CB(B) through February 2016. Everything else would require ConfigMgr 1511 and later. Including support for newly introduced features in Windows 10.

Besides the servicing support, also the upgrade paths are a lot easier via ConfigMgr 1511. This version will also support deploying the upgrades via the software update management flow, it even introduced something new for that named Servicing Plans, while ConfigMgr 2012 can only do an in-place upgrade and of course a fresh installation.

Reason 2: Updates and servicing

R2_ServicingMy second reason is the updates and servicing model of ConfigMgr 1511. It even introduced a new role for that named Service connection point. This role creates a persistent connection with the Configuration Manager cloud services and proactively notifies about updates. When a new update is released, which can be done a lot faster now, it will be made available through this channel. This will be the road to keep as close as possible to the releases of Microsoft Intune and Windows 10.

Also, good to know is that this Service connection point role does more than just that. It also functions as what was previously known as the Microsoft Intune connector role. Besides that another important function is to upload usage data. For more information about this role, please refer to this article.

Reason 3: Latest mobile device management features

R3_LatestMDMMy third reason is the availability of the latest mobile device management features in ConfigMgr 1511. That includes many new settings that are available as a Configuration Item, but also some completely new features like Terms and Conditions, Device Enrollment Manager and Multi-Factor Authentication. These last options are already available in Microsoft Intune for a while and now finally came to ConfigMgr.

As I mentioned before, the Service connection point will allow the environment to stay in par with Microsoft Intune, where possible.

Reason 4: New software center

R4_SoftwareCenterMy fourth reason is the new Software Center in ConfigMgr 1511. This new Software Center is great for two big reasons, 1) it does not require Silverlight anymore and 2) it includes available user-targeted applications. Yes, really, it includes available user-targeted applications!

Good to know is that it does still require the Application Catalog web service point and the Application Catalog website point and, at this moment, it has to be enabled via the Client Settings.

Reason 5: On-premises mobile device management

R5_OnPremMDMMy fifth reason is the introduction of on-premises mobile device management in ConfigMgr 1511. This allows the enrollment of on-premises Windows 10 devices as a mobile device. At this moment only Windows 10 is supported and it’s not possible yet to publish this service externally. In my opinion this is bigger than we might think, as it could be the very first step to agentless management. It simply uses the buildin OMA-DM agent capabilities. The more management capabilities that agent can do the more ConfigMgr can do without it’s own agent.

An important configuration checkbox can be found in the Microsoft Intune Subscription configuration. That checkbox will make sure that no device information is send to the cloud. Keep in mind that the complete configuration also requires certificates, the Enrollment point and the Enrollment proxy point.

Good reasons

That was a great list with reasons to migrate or upgrade to ConfigMgr 1511 as soon as possible. Now lets continue with a list, in no particular order, of great improvements that also could be very good reasons to start thinking about ConfigMgr 1511.

  • Support for 175.000 clients per primary site – ConfigMgr 1511 introduces support in a primary site for up to 175.000 clients;
  • Multiple deployments for an Automatic Deployment Rule – ConfigMgr 1511 introduces the ability to add multiple deployments for each Automatic Deployment Rule
  • Phased client upgrade process – ConfigMgr 1511 introduces client piloting to easily deploy and test updates to the Windows client using a pre-production collection while leaving the current client version in use by the remainder of the hierarchy;
  • Software update management for Office 365 updates – ConfigMgr 1511 introduces the ability to manage Office 365 desktop client updates using the software update management workflow. 
  • WinPE Peer Cache – ConfigMgr 1511 introduces the ability to deploy a new operating system and computers that run the task sequence can use this ability to obtain content from a local peer instead of downloading content from a distribution point.
  • Bulk enrollment for Windows 10 devices – ConfigMgr 1511 introduces bulk enrollment to enable administrators to easily enroll devices for on-premises, or cloud, management without requiring end-users to work through the device enrollment process.
  • Integration with Windows Update for Business – ConfigMgr 1511 introduces the ability to differentiate a Windows 10 computer that is directly connected via Windows Update for Business (WUfB) versus the ones connected to WSUS for getting Windows 10 updates and upgrades.

It could very well be that I even forgot a few new additions to the product, little improvements, like the ability to add the Download Package Content step to a task sequence, or the ability to enable Run WSUS cleanup wizard. I tried to be as complete as possible. For the official list with new features, please refer to this article.

Removed and deprecated features

As with many new releases, it’s also often a moment to remove specific features and to stop supporting specific versions of operating systems and SQL. This article list the removed and deprecated features for ConfigMgr. Make sure to check this list before planning the upgrade or migration to ConfigMgr 1511. A key item in that article is the removal of the Out of Band Management feature.

Manage Windows Defender, of Windows 10, via OMA-DM

A couple of weeks ago I did a blog post about the different management options for Windows 8.1. In that specific post I already mentioned OMA-DM as a very valid method to manage Windows 8.1 and Windows 10 devices. To refresh the memories, OMA Device Management (OMA-DM) is an open management standard designed for mobile devices. The nice thing is that OMA-DM is also fully utilized in Windows 10, even the desktop version. That means that OMA-DM can be used to fully manage specific parts of a Windows 10 device.

In this post I’ll show how OMA-DM can be used to fully manage Windows Defender in Windows 10. For Windows 10 it’s possible to manage all the settings available for Windows Defender. This includes everything, from managing exclusions until blocking the access to the user interface. Managing Windows Defender can be very useful for Windows 10 devices connecting to the work resources. Also, this level of management can be useful for both personal and company owned devices.

Disclaimer: This blog post is based on a technical preview build of Windows 10 (build 10122). The configurations described in this post might change in future releases. I’ll update this post, if needed, with the next release.

Configuration

Now let’s have a look at the configuration. Actually it doesn’t differ a lot from the configurations required for managing settings on Windows Phone 8.1, but I’ll go through the required configurations anyway. I’ll go through the required configurations for both, Microsoft Intune standalone and Microsoft Intune hybrid.

Microsoft Intune standalone

The first configuration steps are for Microsoft Intune standalone. I’ll go through the high-level steps for creating the required policies and the required deployment. It shows the creation of a single OMA-URI setting, which can be used to (not) allow real-time monitoring. The creation of the other OMA-URI settings is similar and can be created by repeating step 2. A complete list of available settings can be found later in this post.

Step Configuration
1 Windows10DefenderBaseline_Conditions_The first step is to create a new Windows Custom Policy (Windows 10 and Windows 10 Mobile). Simply provide a valid name for the new configuration policy and it’s all ready for adding OMA-URI settings.
2 AllowRealtimeMonitoring_SettingThe second step is to add OMA-URI settings. This can be done by clicking the Add button and simply providing the required information. In this example I’ll create an OMA-URI setting for allowing real-time monitoring.
Setting name: Allow Realtime Monitoring
Setting description: Allows or disallows Defender’s Realtime Monitoring functionality.
Data type: Integer
OMA-URI (case sensitive): ./Vendor/MSFT/Policy/Config/Defender/AllowRealtimeMonitoring
Value: 1
3 Windows10DefenderBaseline_Deployment_The third step is to create a deployment for the configuration policy. The nice thing is that this is simply the last step after providing the right configurations. Simply click the Save Policy button, click Yes and select a group.

Microsoft Intune hybrid

The last configuration steps are for Microsoft Intune hybrid. I’ll go through the high-level steps for creating the required configuration items, the required configuration baseline and the required deployment. It shows the creation of a single configuration item, that’s used for a single OMA-URI setting, which can be used to (not) allow real-time monitoring. The creation of the other configuration items is similar and can be created be repeating step 1 and 2. A complete list of available settings can be found later in this post.

Step Configuration
1 AllowRealtimeMonitoring_GeneralThe first step is to create a Configuration Item that contains the OMA URI setting. Personally, I prefer to use a configuration item per setting. In this example I’ll create an OMA-URI setting for allowing real-time monitoring.
Name: Allow Realtime Monitoring
Description: Allows or disallows Defender’s Realtime Monitoring functionality.
Setting type: OMA URI
Data type: Integer
OMA-URI (case sensitive): ./Vendor/MSFT/Policy/Config/Defender/AllowRealtimeMonitoring
2 AllowRealtimeMonitoring_RuleThe second step is to add a Compliance Rule for the OMA-URI setting. In this example I’ll also create an compliance rule for allowing real-time monitoring.
Name: Rule for Allow Realtime Monitoring
Description: The following list shows the supported values:
•0 – Not allowed.
•1 (default) – Allowed.
This setting must comply with the following rule: Allow Realtime Monitoring Equals 1
Select Remediate noncompliant rules when supported.
3 Windows10DefenderBaseline_ConditionsThe third step is to create a Configuration Baseline for the created configuration items. Simply provide a valid name and use Add > Configuration Item to add the created configuration items.
4 Windows10DefenderBaseline_DeploymentThe fourth step is to create a deployment for the configuration baseline. Make sure that the configuration has Remediate noncompliant rules when supported and Allow remediation outside maintenance window selected. Also, don’t forget to add a compliance evaluation schedule, but only use every 1 hours for testing purposes.

Result

There is nothing better than looking at the results, especially with something relatively new. Below are two screenshots of the settings of Windows Defender. The first screenshot is before applying the OMA-URI settings and the second screenshot is after applying the configured OMA-URI settings. It shows that every configured setting can also not be changed anymore (besides the configuration of the exceptions). The best thing is that once the Windows 10 device is un-enrolled, the before-state will be applicable again.

Before After
10222_DefenderBefore 10222_DefenderResult

Windows Defender Settings

There are more than 30(!) settings available that can be configured via OMA-URI and are specifically targeted on Windows Defender. All of these settings are configurable via the path of ./Vendor/MSFT/Policy/Config/Defender/<PolicyName>. The following table shows the available policies including the supported and valid values. Many of these values are also available in the documentation, but I’ve noticed that many of the Allowed/ Not allowed values are switched.

PolicyName Values
AllowCloudProtection
To best protect your PC, Windows Defender will send information to Microsoft about any problems it finds.
Supported values (Integer):

  • 0 – Not allowed;
  • 1 (default) – Allowed.
AVGCPULoadFactor
Represents the average CPU load factor for the scan (in percent).
Valid values (Integer): 0–100.
DaysToRetainCleanedMalware
Time period (in days) that quarantine items will be stored on the system.
Valid values (Integer): 0–90.
AllowArchiveScanning
Allows or disallows scanning of archives.
Supported values (Integer):

  • 0 – Not allowed;
  • 1 (default) – Allowed.
AllowBehaviorMonitoring
Allows or disallows Defender’s Behavior Monitoring functionality.
Supported values (Integer):

  • 0 – Not allowed;
  • 1 (default) – Allowed.
AllowEmailScanning
Allows or disallows scanning of email.
Supported values (Integer):

  • 0 – Not allowed;
  • 1 (default) – Allowed.
AllowFullScanOnMappedNetworkDrives
Allows or disallows a full scan of mapped network drives.
Supported values (Integer):

  • 0 – Not allowed;
  • 1 (default) – Allowed.
AllowFullScanRemovableDriveScanning
Allows or disallows a full scan of removable drives.
Supported values (Integer):

  • 0 – Not allowed;
  • 1 (default) – Allowed.
AllowIntrusionPreventionSystem
Allows or disallows Defender’s Intrusion Prevention functionality.
Supported values (Integer):

  • 0 – Not allowed;
  • 1 (default) – Allowed.
AllowIOAVProtection
Allows or disallows Defender’s IOAVP Protection functionality.
Supported values (Integer):

  • 0 – Not allowed;
  • 1 (default) – Allowed.
AllowOnAccessProtection
Allows or disallows Defender’s On Access Protection functionality.
Supported values (Integer):

  • 0 – Not allowed;
  • 1 (default) – Allowed.
AllowRealtimeMonitoring
Allows or disallows Defender’s Realtime Monitoring functionality.
Supported values (Integer):

  • 0 – Not allowed;
  • 1 (default) – Allowed.
AllowScanningNetworkFiles
Allows or disallows a scanning of network files.
Supported values (Integer):

  • 0 – Not allowed;
  • 1 (default) – Allowed.
AllowScriptScanning
Allows or disallows Defender’s Script Scanning functionality.
Supported values (Integer):

  • 0 – Not allowed;
  • 1 (default) – Allowed.
AllowUserUIAccess
Allows or disallows user access to the Defender UI. If disallowed, all Defender notifications will also be suppressed.
Supported values (Integer):

  • 0 – Not allowed;
  • 1 (default) – Allowed.
ExcludedExtensions
Allows an administrator to specify a list of file type extensions to ignore during a scan.
Each file type in the list must be separated by | (String). For example, zip|exe.
ExcludedPaths
Allows an administrator to specify a list of directory paths to ignore during a scan.
Each path in the list must be separated by | (String). For example, C:\Data|C:\Temp.
ExcludedProcesses
Allows an administrator to specify a list of files opened by processes to ignore during a scan.
Each file type must be separated by a | (String). For example, C:\Program Files\7-Zip\7zG.exe|C:\Program Files (x86)\Foxit Software\Foxit Reader\FoxitReader.exe.
RealTimeScanDirection
Controls which sets of files should be monitored.
Supported values (Integer):

  • 0 (default) – Monitor all files (bi-directional).
  • 1 – Monitor incoming files.
  • 2 – Monitor outgoing files.
ScanParameter
Selects whether to perform a quick scan or full scan.
Supported values (Integer):

  • 1 (default) – Quick scan;
  • 2 – Full scan.
ScheduleQuickScanTime
Selects the time of day (in minutes) that the Defender quick scan should run.
Valid values (Integer): 0–1380
ScheduleScanDay
Selects the day that the Defender scan should run.
Supported values (Integer):

  • 0 (default) – Every day;
  • 1 – Monday;
  • 2 – Tuesday
  • 3 – Wednesday;
  • 4 – Thursday;
  • 5 – Friday;
  • 6 – Saturday;
  • 7 – Sunday;
  • 8 – No scheduled scan
ScheduleScanTime
Selects the time of day (in minutes) that the Defender scan should run.
Valid values: 0–1380 (Integer).
SignatureUpdateInterval
Specifies the interval (in hours) that will be used to check for signatures.
Valid values: 0–24 (Integer).
SubmitSamplesConsent
Checks for the user consent level in Defender to send data. If the required consent has already been granted, Defender submits them.
Supported values (Integer):

  • 0 – Always prompt;
  • 1 (default) – Send safe samples automatically;
  • 2 – Never send;
  • 3 – Send all samples automatically.

More information

For more information about all the possible configuration policies in Windows 10, see the Policy Configuration Service Provider documentation: https://msdn.microsoft.com/en-us/library/windows/hardware/dn904962%28v=vs.85%29.aspx

Windows 10 device enrollment

Updated May 21, 2015: Yesterday Microsoft released a new technical preview build of Windows 10 (build 10122). Within this build the look-and-feel of the enrollment process changed. I’ve updated the enrollment process to reflect these changes.

Windows10_TweetAfter the release of Windows 10 Technical Preview 2 (build 9926) I knew my next blog post would include Windows 10. So far I’m really liking the new start menu, the search, the notifications, the settings and I could go on like that for a while. Blogging about these subjects wouldn’t add something new as it’s already be done by many over the last week. Even the deployments of Windows 10 via MDT and/ or ConfigMgr are already done and covered in blogs. That’s why I looked further, to something that I already tweeted about, to enroll a Windows 10 device in Microsoft Intune (with or without ConfigMgr integration).

Disclaimer: This blog post is based on a technical preview build of Windows 10 (build 10122). The configurations described in this post might change in future releases. I’ll update this post with the next release.

How to enroll a Windows 10 device

A new operating system often means that everything is just in slightly different place. The thing that stayed the same is that the feature is still named Workplace. In Windows 8.1 this feature was located under Network and that’s something that really changed in (the early releases of) Windows 10. Now let’s go through the steps to enroll a Windows 10 device.

Step Action
1 10122_SettingsAccountsAfter logging on to a Windows 10 device, navigate to Settings > Accounts > Work access.
2 10122_ConnectWorkThe Connect to work or school feature provides information about the benefits and restrictions of enrolling your device.

Click Connect.

3 10122_ConnectWork_2The Connect to work or school dialog box will show, asking for your account to enroll the device.

Provide your account and click Continue.

4 YourWorkplace_SSOAs I’ve got AD FS configured with single sign-on I’m redirected to my on-premises AD FS to provide my credentials.

Provide your credentials and click Sign in.

5 10122_ConnectedThe Well done! dialog box will show, stating that your workplace is connected.

Click Done.

6 10122_EnrolledBack in the Connect to work or school feature, it now provides information about the user that enrolled the device.

Click on the user information.

7 10122_EnrolledOptionsThe Connect to work or school feature will now display some additional options to Sync the device, to get Info about the device and to Remove the device.

Clicking on Sync will trigger a synchronization with Microsoft Intune/ ConfigMgr and clicking Remove will trigger the removal of the device.

Click Info.

8 10122_EnrolledSettingsThe Work or school info feature, will provide the basic enrollment information about your device.
9

10122_ClientPropertiesIn this example I enrolled my device in to ConfigMgr, but I’ve could have done the same steps with Microsoft Intune standalone.

Now I can look in ConfigMgr to see the device details. I can see that it recognizes the operating system of Windows 10 and that it enrolled as a mobile device.