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

How to use the Microsoft Intune Company Portal app for Windows Phone 8.1 from the Download Center

A bit more than a month ago Microsoft released the Microsoft Intune Company Portal app specifically for Windows Phone 8.1 in the Download Center. This version of the Microsoft Intune Company Portal app is created specifically for Windows Phone 8.1 and later, as it’s created in the APPX format, which is not supported by Windows Phone 8. It can be used by administrators to deploy to end-users who do not have access to the Windows Phone Store. The main feature of this version of the Microsoft Intune Company Portal app is the ability to show the configured Terms and Conditions in Microsoft Intune standalone.

In this blog post I’ll describe how this version of the Microsoft Intune Company Portal app can be signed and how it can be used in either Microsoft Intune hybrid, or Microsoft Intune standalone.

Sign the Microsoft Intune Company Portal app

Let’s start with the part that got me puzzled for a while, signing the Microsoft Intune Company Portal app. I was smart enough to use the Signtool.exe, but that alone will not do the trick. This will provide an error message indicating that the publisher of the app does not match the used code-signing certificate. For signing the Microsoft Intune Company Portal app a little bit more is required, but luckily there is a PowerShell script, which is part of the Windows Phone 8.1 SDK, which is part of Visual Studio Community 2013 CU4, that takes care of everything. To sign the Microsoft Intune Company Portal app, perform the following steps.

Tip: Use the same certificate that’s used to sign other LOB applications, or that’s already been used to sign the Microsoft Intune Company Portal app for Windows Phone 8 (xap).

  1. SignCompanyPortalAppOpen a Command Pompt as administrator;
  2. Run the command PowerShell.exe –File “%ProgramFiles(x86)%\Microsoft SDKs\WindowsPhoneApp\v8.1\Tools\MDILXAPCompile\BuildMDILAPPX.ps1” -appxfilename C:\Data\CompanyPortal.appx -pfxfilename C:\Data\InovativEnterpriseCodeSigningCertificate.pfx –password <Password>;
  3. In the Delete Files dialog box, click Yes.

The PowerShell script BuildMDILAPPX.ps1 does all the required work to successfully sign the Microsoft Intune Company Portal app. The path specified in the command, of the script, is the default path after the installation of Visual Studio Community 2013 CU4. The parameters used as input to this script require the following information.

  • appxfilename – This parameter specifies the path and name of the APPX file;
  • pfxfilename – This parameter specifies the path and name of the certificate file;
  • password – This parameter specifies the password of the specified certificate.

Configure the Microsoft Intune Company Portal app

Now that the Microsoft Intune Company Portal app is signed, let’s have a look at how it can be used. I’ll go through both scenarios, Microsoft Intune hybrid and Microsoft Intune standalone, as they both have their own configuration requirements.

Microsoft Intune hybrid

WindowsPhoneConfigurationSince the release of the latest service pack for ConfigMgr 2012 R2, the configuration for enabling just Windows Phone 8.1 is a lot easier. Simply navigate to the Microsoft Intune Subscription Properties and select Windows Phone 8.1 and later in the configuration of the Windows Phone platform.

To make sure that the Microsoft Intune Company Portal app can be installed, the code-signing certificate, used for signing the app, must also be configured. This can be done by simply selecting pfx file and browsing to the code-signing certificate, that’s used to sign the Microsoft Intune Company Portal app, or by selecting Application enrollment token and browsing to the location of the AET file.

RequiredCompanyPortalAppFor Windows Phone 8.1 and later the Microsoft Intune Company Portal app must be deployed, with a Purpose of Required, to either an user or a device collection. I would suggest to target an user collection, as that collection membership is already available during the enrollment of the mobile device. This will make sure that the Microsoft Intune Company Portal app installation happens sooner, as it doesn’t have to wait on the collection membership of the mobile device. Even better would be to use the user collection configured in the Microsoft Intune Subscription Properties, as this user collection gets top priority.

Tip: Use the Microsoft Intune Company Portal app for Windows Phone 8 (xap), when the company also supports Windows Phone 8 devices, or when the company is still running ConfigMgr 2012 R2 (without service pack). This will save a lot of administrative overhead, for only minor application changes, especially from a Microsoft Intune hybrid perspective.

Microsoft Intune standalone

ConfigureCompanyPortalAppFunny enough, the configuration for the Microsoft Intune Company Portal app is more complicated in Microsoft Intune standalone. There is no configuration required to allow the enrollment of Windows Phone 8.1 devices, but the fun starts with uploading the code-signing certificate.

To make sure that the Microsoft Intune Company Portal app can be installed, the code-signing certificate, used for signing the app, must be uploaded to Microsoft Intune and that can only be achieved by uploading a signed Microsoft Intune Company Portal app for Windows Phone 8 (xap). After that’s successfully done, the code-signing certificate is available within Microsoft Intune for usage with other applications.

RequiredInstallCompanyPortalAppNow to prevent the installation of the Microsoft Intune Company Portal app for Windows Phone 8 (xap), configure the Approval configuration, of the deployment, to Uninstall. The next thing is to make sure that the Microsoft Intune Company Portal app for Windows Phone 8.1 (appx) is deployed with the Approval configuration of Required Install, to either an user or a device group. Again, I would suggest to target an user group, as that group membership is already available during the enrollment of the mobile device. This will make sure that the Microsoft Intune Company Portal app installation happens sooner, as it doesn’t have to wait on the group membership of the mobile device.

Tip: Use the Microsoft Intune Company Portal app for Windows Phone 8 (xap), unless the company uses custom Terms and Conditions. This will save a lot of administrative overhead, for only minor application changes.

Conclusion

Personally I prefer everything that’s newer, which in this case would be the Microsoft Intune Company Portal app for Windows Phone 8.1 (appx), but as mentioned a couple of times it’s not always the best option from an administrative perspective. To prevent any confusions make sure to know the different scenarios of the Microsoft Intune Company Portal app, before just simply deploying. For example, in Microsoft Intune standalone the use of custom Terms and Conditions can be a reason to (also) use the Microsoft Intune Company Portal app for Windows Phone 8.1 (appx).

More information

For more information about the different subjects of this blog post please refer to the following links:

Windows 8.1 and the different management options

WorkplaceEnrollment01In this blog post I would like to address a topic that’s often forgotten in the mobile devices management discussion. That topic is based on the question, “How are we going to manage the Windows 8.1 devices?”. Yes, I know, technically speaking a Windows 8.1 device is not a mobile device, but that doesn’t mean that we can’t treat it like one.

In this blog post I’ll go through the different management options for Windows 8.1 from a Microsoft Intune standalone and a Microsoft Intune hybrid perspective. Also, I will provide an overview of the related management prerequisites, from both perspectives, and I’ll show the end-user enrollment possibilities.

Management options

The introduction of Microsoft Intune introduced a lot of management options for all the iOS, Android and Windows (Phone) devices. More specifically, for Windows 8.1devices the management options are enormous. With the introduction of Microsoft Intune and Windows 8.1 we suddenly have multiple options for managing Windows 8.1 devices.

Microsoft Intune client

Let’s start with the Microsoft Intune client. The Microsoft Intune client can be used to fully manage the Windows 8.1 devices in Microsoft Intune standalone and the Microsoft Intune hybrid. Yes, really, even in Microsoft Intune hybrid. With Microsoft Intune hybrid, we only configure ConfigMgr as the mobile device management authority. That means that full clients can still be managed through Microsoft Intune. Yes, it does kill the idea of using one console to manage all devices, but I’ve been in scenarios where it was the best option for managing the close-to-always-out-of-the-office devices. It allowed them to stay in control without introduction something like Internet based client management (IBCM), or DirectAccess (DA).

In general, the Microsoft Intune client is the ideal solution for fully managing company owned devices in Microsoft Intune standalone. In really specific use cases, the Microsoft Intune client can a good alternative in Microsoft Intune hybrid.

ConfigMgr client

The ConfigMgr client can be used to manage the Windows 8.1 devices in Microsoft Intune hybrid. In Microsoft Intune hybrid the ConfigMgr client is the most enhanced client that is capable to manage devices in the most advanced way. The ConfigMgr client can not take advantage of the Microsoft Intune service, which means that for close-to-always-out-of-the-office devices we still have to look at something like Internet based client management (IBCM), or DirectAccess (DA).

In general, the ConfigMgr client is the ideal solution for fully managing company owned devices in Microsoft Intune hybrid.

OMA-DM agent

OMA Device Management (OMA-DM) is an open standard designed for mobile devices. The nice thing is that OMA-DM is now also available in Windows, since Windows 8.1, and will be even more utilized in Windows 10. That also means that the OMA-DM agent can be used to slightly manage a Windows 8.1 device in a similar way as a mobile device. It provides just enough capabilities to put some requirements on a personal device of the user that he, for example, wants to connect to the company Wi-Fi. After the installation of the Microsoft Intune Company Portal app it’s even possible to provide the user with some company specific apps.

In general, the OMA-DM agent is the ideal management solution for personal devices in Microsoft Intune standalone and Microsoft Intune hybrid.

Workplace Join

Besides OMA-DM, Workplace Join is the other often forgotten option for Windows 8.1. A Workplace Join is somewhere in between being part of the domain, or not.  Very simplistically said, after the Workplace Join action, the computer authentication can be used for single sign-on purposes and to provide conditional access to company resources and services. There is no overlap with the management capabilities provided via Microsoft Intune standalone or Microsoft Intune hybrid, it’s more an addition.

That’s also why I won’t go into more detail, in this blog post, about Workplace Join, as I want to focus on the management capabilities of the combination of Windows 8.1 and Microsoft Intune. I did thought it was worth mentioning that it’s a very nice addition to the management capabilities of Microsoft Intune.

Management prerequisites

Now that I’ve gone through the different management options, it’s time to look at the management prerequisites for Microsoft Intune standalone and Microsoft Intune hybrid.

Microsoft Intune client

Looking at the Microsoft Intune client there are no specific configurations required in Microsoft Intune standalone, or Microsoft Intune hybrid, to allow Windows 8.1 devices. From a client perspective, the device has to run Windows 8.1 Pro or Windows 8.1 Enterprise.  As I’m only writing about Windows 8.1, there are no specific software requirements. A couple of important things to keep in mind are the following.

Requirement More information
Administrative permissions The account that installs the Microsoft Intune client must have local administrator permissions on the device.
Remove incompatible client software Before the Microsoft Intune client can be installed any ConfigMgr-like management client should be removed.

For all the requirements related to the Microsoft Intune client installation, see: https://technet.microsoft.com/en-us/library/dn646950.aspx

ConfigMgr client

Now looking at the ConfigMgr client there are also no specific configurations required, in Microsoft Intune hybrid, to allow Windows 8.1 devices. However, it is required to run at least ConfigMgr 2012 SP1 CU3, to support Windows 8.1 devices. From a client perspective the device has to run Windows 8.1 Pro or Windows 8.1 Enterprise. Again, as I’m only writing about Windows 8.1 devices, there are no specific software requirements that are not already installed during the client installation. A couple of important things to keep in mind are the following.

Requirement More information
Administrative permissions The account that installs the ConfigMgr client must have local administrator permissions on the device.
Remove incompatible client software Before the ConfigMgr client can be installed any Microsoft Intune-like management client should be removed.
Microsoft Task Scheduler service The Microsoft Task Scheduler service must be enabled on the device for the client installation to complete.

For all the requirements related to the ConfigMgr client installation, see: https://technet.microsoft.com/en-us/library/gg682042.aspx

OMA-DM agent

For the OMA-DM agent there are specific configurations required, mainly for Microsoft Intune hybrid, to allow the enrollment of Windows 8.1 devices. Let’s have a quick look from both perspectives to see what the required configuration changes are.

Microsoft Intune standalone

Intune_WindowsEnrollEnabledIn Microsoft Intune standalone there is no specific configuration required to enable the enrollment of Windows 8.1 devices. However, if the installation of line-of-business apps is required, it is required to add sideloading keys. Also, if a non-public, not trusted, code-signing certificate is used to sign the line-of-business apps, it is also required to provide that certificate. To add sideloading keys and/or to provide the code-signing certificate, follow the next steps.

Step Configuration
1 Navigate to Mobile Device Management > Windows.
2

Intune_WindowsEnrollTo add sideloading keys, click Add Sideloading Key. In the Add Sideloading Key dialog box provide the Name, Key and Total activations and click OK.

To upload a code-signing certificate, click Modify Code-Signing Certificate. In the Upload a Code-Signing Certificate dialog box select the certificate and click Upload.

Microsoft Intune hybrid

In Microsoft Intune hybrid there is a small configuration required to allow the enrollment of Windows 8.1 devices. If the installation of line-of-business apps is also required, it is also required to add sideloading keys. Also, if a non-public, not trusted, code-signing certificate is used to sign the line-of-business apps, it is also required to provide that certificate. To allow the enrollment of Windows 8.1 devices and to add sideloading keys and/or to provide the code-signing certificate, follow the next steps.

Step Configuration
1 Navigate to Administration > Overview > Cloud Services > Windows Intune.
2 Double-click Windows Intune Subscription and select the Windows tab.
3 ConfigMgr_WindowsEnrollTo allow the enrollment of Windows 8.1 devices, select Enable Windows enrollment and click OK.

To upload a code-signing certificate, click Browse. In the Open dialog box select the certificate and click Open and click OK.

To add sideloading keys, do as mentioned in the dialog box, and navigate to Software Library > Overview > Application Management > Windows Sideloading Keys. Click Create Sideloading Key, in the Add Sideloading Key dialog box provide the Name, Key and Total activations and click OK.

Enrollment requirements

After allowing the enrollment of Windows 8.1 devices, a couple of important things to keep in mind, before enrolling the Windows 8.1 devices, are the following.

Requirement More information
Administrative permissions The account that enrolls the device must have local administrator permissions and can not be the buildin administrator.
Remove incompatible client software Before a device can be enrolled any ConfigMgr-like management client should be removed.

End-user enrollment

Now that I’ve gone through the different management options and the different management requirements, there is one last subject that I would like to address and that’s the end-user enrollment. No, I won’t go through all the different, known, options to install the Microsoft Intune client, or the ConfigMgr client. I’ll only go through the most unknown scenario and that’s the the end-user enrollment. The end-user enrollment experience is the same in Microsoft Intune standalone and Microsoft Intune hybrid.

Microsoft Intune client

Let’s start by looking at the end-user enrollment for the Microsoft Intune client. Yes, as long as the management requirements are met, the end-user can install the Microsoft Intune client by following the next steps.

Step Configuration
1 Login to portal.manage.microsoft.com.
2 Select This device is either not enrolled or the Company Portal can’t identify it.
3 In the Identify or enroll this device dialog box select ENROLL.
4 In the Enroll your computer dialog box select DOWNLOAD SOFTWARE.
5 In the Do you want to run or save Microsoft_Intune_Setup.exe from msub3.manage.microsoft.com dialog box select Run.
6 Intune_ClientInstallThis will start the Microsoft Intune Setup wizard.

  • On the Welcome to the Microsoft Intune Setup Wizard page, click Next.
  • On the Completed the Microsoft Intune Setup Wizard page, click Finish.

ConfigMgr client

There is no out-of-the-box end-user enrollment available for the ConfigMgr client.

OMA-DM agent

Now let’s have a look at the end-user enrollment from a OMA-DM perspective. When the management prerequisites are in place, the end-user can enroll their Windows 8.1 device by performing the steps mentioned below.

Enrollment

The first thing that the end-user must do is to enroll its Windows 8.1 device.

Step Configuration
1 Navigate to PC settings > Network > Workplace.
2 In the Workplace screen, provide a user ID and click Join.
3 In the Connecting to a service screen provide the password and click Sign in.
4 In the Allow apps and services from IT admin screen, select I agree and click Turn on.

Company portal

When the end-user also wants to be able to install the available company apps, the next thing that the end-user must do is to install the Microsoft Intune Company Portall app.

Step Configuration
1 Open the Store.
2 In the Home screen, use the Search for apps field to search for Microsoft Intune Company Portal.
3 In the Results for “Microsoft Intune Company Portal” screen, select Company Portal.
4 In the Company Portal screen, click Install.

More information

I have to admit that this was a long blog post. That’s why I can imagine that on specific subjects some more information might be required to get the complete picture. The following links provide additional information about the subjects touched in this post:

Remote device actions in ConfigMgr

Updated May 15, 2015: Yesterday the latest service pack, for ConfigMgr 2012 R2 and ConfigMgr 2012 SP1, was released. With the new functionalities in this service pack it’s now also possible to perform the same remote device actions in ConfigMgr 2012. The look-and-feel is an exact match with everything described in this post about the first technical preview of ConfigMgr vNext.

MobileDeviceActionsThis morning I’ve started exploring the technical preview of ConfigMgr vNext. I’ve been quite busy tweeting about the stuff I could easily find, but I would also like to devote a small blog post to some new features, from a ConfigMgr perspective, for mobile devices. The reason for that is because it’s cool and because the speed of it scared the crap out of me. For mobile devices new actions are added to remotely reset the passcode of the mobile device and to remotely lock the mobile device.

Disclaimer: This blog post is based on ConfigMgr vNext Technical Preview (5.00.8239.1000). The configurations described in this post might change in future releases.

Reset passcode

Let’s start with the first new action for mobile devices, which is to remotely reset the passcode of a mobile device.

Experience
ResetPasscode_ConfirmationIn the Configuration Manager Console navigate to the mobile device, in my case a Windows Phone, right click and select Remote Device Actions > Reset Passcode. In the Configuration Manager dialog box click Yes and the process will start.
wp_ss_20150505_0001This is the part that scared the crap out of me, as within a couple of seconds my Windows Phone got in the reset password state and I didn’t have a password, yet.

Good to know that in this state, nothing is possible with the mobile device without knowing the passcode, which is a 8 digit number.

ResetPasscodeEven better to know is that the required passcode will be available in the Configuration Manager Console, within a couple of seconds. Right-click the mobile device and select Remote Device Actions > View Passcode State. This will provide that status of the action AND the passcode.

Remote Lock

And now continue with the second new action for mobile devices, which is to remotely lock a mobile device.

Experience
LockDevice_ConfirmationIn the Configuration Manager Console navigate to the mobile device, in my case a Windows Phone, right click and select Remote Device Actions > Remote Lock. In the Configuration Manager dialog box click Yes and the process will start.
wp_ss_20150505_0002Within a couple of seconds my Windows Phone got locked. To state the obvious here, this will only happen when the device is configured with a password (PIN).

Good to know that in this state the mobile device can simply be unlocked by providing the configured password (PIN).

LockStateEven better to know is that the status of this action will be available in the Configuration Manager Console, within a couple of seconds. Right-click the mobile device and select Remote Device Actions > View Remote Lock State. This will provide that status of the action.

More information

For a lot more information about this first public release of ConfigMgr vNext technical preview have a look at the documentation here and the download the bits here.

Automagically set the mobile device owner to company

Before I’ll start with this blog post I would like to say thank you to Kim Oppalfens, for his great suggestion to look at WMI Eventing. I didn’t know that it was that versatile and powerful! Thanks Kim!

Scenario

DeviceOwnerThe scenario for this post is actually quite simple and is applicable to an environment with Microsoft Intune integrated with ConfigMgr. By default, the device owner of a mobile device is set to Personal and that’s not always the desired value. A lot of customers still provide their employees with (mobile) devices and want the tooling to reflect that information. This blog post will provide an automagic method to set the mobile device owner to Company, by default. The best thing is that it’s still possible to switch a mobile device to Personal if that’s required. Only newly added mobile devices will be automagically set to Company.

Solution

Now let’s start about the solution for this scenario. Initially I thought that I could easily tackle this scenario via a Status Filter Rule, only to find out that there is no status message generated for the creation of a new mobile device object. That was the moment that I needed advice and I got pointed in to the direction of WMI Eventing. In the rest of this blog post I’ll describe the key parts of the scripts that I used to automatigally set the mobile device owner to Company after it’s enrolled. The complete scripts are available for download in the TechNet Galleries.

>> Available via download here on the TechNet Galleries! <<

The action

Before I’ll start with explaining the key parts of the script for using WMI for monitoring and responding to events, I’ll start with a short piece about changing the device owner, similar to this post about changing the device ownership. As mentioned in that post, I can simply use call the WMI method ChangeOwnership, of the SMS_Collection class, by providing the device owner and the resource id. Together that would make the action to change the device owner look like this.

Invoke-WmiMethod -ComputerName $SiteServer ` -Namespace root\SMS\site_$($SiteCode) -Class SMS_Collection ` -Name ChangeOwnership -ArgumentList @($DeviceOwner,$ResourceId) ` -ErrorAction Stop

The event filter

WMI_EventFilterThe first thing that I need to create now is the event filter, as shown in the picture. An event filter is a WMI class that describes which events WMI delivers to a physical consumer. It also describes the conditions under which WMI delivers the events. Let’s start with the latter and start with describing the conditions. To do this I use the following hash table that contains the conditions for the event filter.

$PropertyHash = @{ QueryLanguage = "WQL"; Query = "SELECT * FROM __InstanceCreationEvent WITHIN 5 ` WHERE TargetInstance ISA 'SMS_R_System' AND ` TargetInstance.DeviceOwner = '2'"; Name = "DeviceOwnerFilter"; EventNameSpace="root\sms\site_$($SiteCode)" }

The most important part of the conditions is the query. In this query I select the creation, by using __InstanceCreationEvent, of mobile devices, by using  TargetInstance ISA ‘SMS_R_System’ AND TargetInstance.DeviceOwner = ‘2’, every 5 seconds, by using WITHIN 5. Effectively this query will run twice every 5 seconds and the differences are my results. I can imagine that running this every 5 seconds might be too aggressive, in that case simply adjust this value to any desired number.

Now, to create an event filter, I need to create a new instance of the __EventFilter class. To do this I can use the New-CimInstance cmdlet together with the just defined hash table, like this.

$InstanceFilter = New-CimInstance -Namespace root\subscription ` -ClassName __EventFilter -Property $PropertyHash -ErrorAction Stop

The event consumer

WMI_EventConsumerThe next thing that I need to create is the event consumer, as shown in the picture. An event consumer can be used to perform actions based on events. Each consumer takes a specific action after it receives an event notification. Let’s start with describing the actions for the consumer. To do this I use the following hash table that contains the actions for the event consumer.

$PropertyHash =@{ Name = "DeviceOwnerConsumer"; CommandLineTemplate = "PowerShell.exe ` -File $ScriptPath\Change-Ownership.ps1 -SiteServer $SiteServer` -SiteCode $SiteCode -DeviceOwner 1 ` -ResourceId %TargetInstance.ResourceId%" }

The most important part in the defined action is, of course, the location of the script file that performs the action. Almost as important is to get the resource id of the mobile device, as input for the action script.  Luckily, every instance creation event contains an embedded object called TargetInstance, which, in this case, is a representation of the created SMS_R_System object. That TargetInstance object is what I can use as input in my script, like this %TargetInstance.ResourceId%.

In this case I choose to use a command line event consumer. That means I need to create a new instance of the CommandLineEventConsumer class. To do this I use the New-CimInstance cmdlet, again, together with the just defined hash table, like this.

$InstanceConsumer = New-CimInstance -Namespace root\subscription ` -ClassName CommandLineEventConsumer -Property $PropertyHash ` -ErrorAction Stop

Binding the filter and the consumer

WMI_EventBindingThe last thing that I have to do, is to bind the event filter with the event consumer, as shown in the picture. This will make sure that when an event occurs that matches the specified filter, the action specified by the consumer will occur. To do this I first create the following hash table that contains a reference to the event filter and the event consumer.

$PropertyHash = @{ Filter = [ref]$InstanceFilter; Consumer = [ref]$InstanceConsumer }

Now I need to relate them by creating a new instance of __FilterToConsumerBinding. To do this I use the New-CimInstance cmdlet, one last time, together with the hash table, like this.

$InstanceBinding = New-CimInstance -Namespace root/subscription ` -ClassName __FilterToConsumerBinding -Property $PropertyHash ` -ErrorAction Stop

Result

The result of all of this is an event consumer that will change the device owner of every mobile device that’s found by the event filter. There are multiple way’s to verify that everything is created and working as expected. To check if everything is created in WMI, as scripted, either use PowerShell or simply use a WMI Explorer.

More importantly, to check if the consumer is working as expected, simply check the event viewer. My script to change the device owner writes a 3000 event in the Application log for every successful change and a 3001 event for every failure. Both of them use the SMS Server as source. A good place to check the functionality of the event filter is to look at the SMSProv.log. This log will show a hit, in this case, every 5 seconds as shown in the example below. Every hit will be performed by the SYSTEM account.

Every5Sec

More information

For a lot more information about the basics of WMI Eventing and about how this can be used in combination with scripting, have a look at the following great posts:

Store accounts and the Microsoft Intune Company Portal app

CompanyPortalAppLogo_thumb9In this blog post I will answer a question that I get, with a lot of customers, and that’s if it’s required for end-users to have an account for the app store, of their platform, to download the Microsoft Intune Company Portal app. The app store that I mean here is can be the Google Play app store, the Apple app store,  the Windows Phone app store or the Windows app store. All these stores match with their platform and require their own store account to download apps.

Before I can answer the initial question, I first have to answer another question. That question is if it’s required to use the Microsoft Intune Company Portal app, simply because a store account is not required if the Microsoft Intune Company Portal app is not required. In this post I’ll try to answer both of these questions by providing tables for a nice overview of the requirements per platform. In general this is applicable for both Microsoft Intune standalone and Microsoft Intune integrated with ConfigMgr 2012.

Microsoft Intune Company Portal app

Now let’s start with the first question, is the Microsoft Intune Company Portal app required? In almost all the scenario’s the answer to this question will be, yes. Also, keep in mind that the advised scenario for every platform is to install the Microsoft Intune Company Portal app  and to enroll the mobile device. To be complete the following table lists the functional requirements for the Microsoft Intune Company Portal app  for every platform.

 Platform Enrollment and policies Application deployment
Android Yes Yes
iOS Yes1 Yes
Windows Phone 8.0 No Yes
Windows Phone 8.1 No Yes
Windows No Yes

1 It is possible to enroll iOS devices without using the Microsoft Intune Company Portal app. That can be achieved by either using portal.manage.microsoft.com on an iOS device, or by using the corporate device enrollment feature with Microsoft Intune standalone.

Store account

That brings me to the second question, is the store account required to get the Microsoft Intune Company Portal app? Well, this also differs per platform. To make it easy I can say that it’s required for the non-Microsoft platforms. The following table provides a quick overview per platform, including the alternatives for the Microsoft platforms.

Platform Store account required Alternative
Android Yes N/A
iOS Yes N/A
Windows Phone 8.0 No Microsoft Intune Company Portal app for Windows Phone
Windows Phone 8.1 No Microsoft Intune Company Portal app for Windows Phone 8.1
Windows No Microsoft Intune Company Portal app for Windows 8.1

Conclusion

At this moment the best method for end-users to enroll their device is to use the Microsoft Intune Company Portal app, if possible. In case the Microsoft Intune Company Portal app is not required for the enrollment, like with Microsoft platforms, it’s still advised to install the Microsoft Intune Company Portal app to better manage devices and applications.

Back to the original question, this would mean that, at this moment, a store account is always required for non-Microsoft platforms. For Microsoft platforms it depends on how the Microsoft Intune Company Portal app is deployed. Like I mentioned in my previous post, I like to use the Microsoft Intune Company Portal app for the Microsoft App store, if possible, and in that case a store account is required.

Windows Phone 8.1 and the Microsoft Intune Company Portal app

CompanyPortalAppLogoThis blog post will be about the magical world of Windows Phone 8.1 and the Microsoft Intune Company Portal app. More specifically, about Windows Phone 8.1 and the two Microsoft Intune Company Portal apps. The Microsoft Intune Company Portal app of the Windows Phone Store and the Microsoft Intune Company Portal app deployed via either Microsoft Intune or ConfigMgr.

Yes, I know there was recently a KB article released about the same subject. In this post I’ll go through more scenarios and I’ll go in more detail about the possible solutions and the pro’s and cons of those solutions.

Scenarios

Now lets start with summarizing the different scenarios that are possible with the combination of Microsoft Intune, ConfigMgr, Windows Phone 8.1 and the Microsoft Intune Company Portal app. I found the following three scenarios and I’ll go through them in detail after listing them:

  • Scenario 1: Microsoft Intune standalone without code-signing certificate;
    • This scenario will be about the management of just Windows Phone 8.1 devices and no requirement of a code-signing certificate;
  • Scenario 2: Microsoft Intune standalone with code-signing certificate;
    • This scenario will be about the management of Windows Phone 8.1 devices and the requirement of either a code-signing certificate, or the management of Windows Phone 8 devices;
  • Scenario 3: Microsoft Intune integrated with ConfigMgr;
    • This scenario will be about the management of Windows Phone devices.

Scenario 1 – Microsoft Intune standalone without code-signing certificate

Intune_WindowsPhoneThe first scenario is also the easiest scenario. With Microsoft Intune standalone and no need for code-signing certificates, or the management of Windows Phone 8 devices, there will not be a problem with possibly installing the two versions of the Microsoft Intune Company Portal app.

In this scenario simply use the the Microsoft Intune Company Portal app of the Windows Phone Store.

Scenario 2 – Microsoft Intune standalone with code-signing certificate

Intune_WindowsPhone881The second scenario will be more complicated. With Microsoft Intune standalone and the requirement of either a code-signing certificate, or the management of Windows Phone 8 devices, there can be challenges with possibly installing the two versions of the Microsoft Intune Company Portal app.

When a code-signing certificate, or the management of Windows Phone 8 devices, is required, it’s also required to upload a signed Microsoft Intune Company Portal app to Microsoft Intune. That process will automatically create a deployment for the Microsoft Intune Company Portal app. After this, even the enrollment of Windows Phone 8.1 is not possible without a deployment of the Microsoft Intune Company Portal app. This gives us two options to choose from for the Microsoft Intune Company Portal app.

Company Store app

The first option is to make the Microsoft Intune Company Portal app, deployed via Microsoft Intune, the only available Microsoft Intune Company Portal app by blocking the version from the Windows Phone Store.

Intune_CompanyPortalBlockThis can be achieved by creating a Configuration Policy in Microsoft Intune. That Configuration Policy  has to be a Windows Phone Configuration Policy and has to be configured to Block devices from opening the listed apps. The list of blocked apps has to contain the Microsoft Intune Company Portal app URL of http://www.windowsphone.com/en-us/store/app/company-portal/0b4016fc-d7b2-48a2-97a9-7de3b5ea742 in the App URL.

That configuration will make sure that the Microsoft Intune Company Portal app, deployed via Microsoft Intune, truly is the only available Microsoft Intune Company Portal app. It’s now not possible anymore to have two functional Microsoft Intune Company Portal apps on a Windows Phone 8.1 device.

Windows Phone Store app

The other option would be to make the Microsoft Intune Company Portal app, of the Windows Phone Store, (close to) the only available Microsoft Intune Company Portal app by changing the deployment of the Microsoft Intune Company Portal app in Microsoft Intune. Intune_CompanyPortalUninstallThat’s possible because the deployment is accepted in both the install and the uninstall state.

This can be achieved by editing the standard created deployment of the Microsoft Intune Company Portal app. The standard Approval configuration is Available Install and that can be adjusted to Uninstall. Using Not applicable is not an option as it will cause failures similar to when no deployment exists.

wp_ss_20150412_0001That configuration will make the Microsoft Intune Company Portal app, of the Windows Phone Store, almost always the only available Microsoft Intune Company Portal app. There remains one situation in which it’s still possible to install the Microsoft Intune Company Portal app, deployed via Microsoft Intune. That situation comes when the workplace settings of the company are opened. This provides the option of download hub, which in fact will download and install the Microsoft Intune Company Portal app that’s deployed through Microsoft Intune. No matter how the deployment is configured, this option will always be available in this scenario.

Scenario 3 – Microsoft Intune integrated with ConfigMgr

ConfigMgr_WindowsPhone881The third scenario is as complicated as the second scenario. With Microsoft Intune integrated with ConfigMgr, there can also be challenges with possibly installing the two versions of the Microsoft Intune Company Portal app.

When Windows Phone enrollment is enabled, it’s also required to add an application of a signed Microsoft Intune Company Portal app. That application has to be deployed to be able to enroll a Windows Phone 8.1 device. This gives us two options to choose from for the Microsoft Intune Company Portal app.

Company Store app

The first option is to make the Microsoft Intune Company Portal app, deployed via ConfigMgr, the only available Microsoft Intune Company Portal app by blocking the version from the Windows Phone Store.

This can be achieved by creating a Configuration Baseline in ConfigMgr. That Configuration Baseline has to contain a Configuration Item with at least the following configuration:

  • imageSetting type: OMA URI
  • Data type: String
  • OMA-URI: ./Vendor/MSFT/PolicyManager/My/ApplicationManagement/ ApplicationRestrictions
  • Compliance: Equals <AppPolicy Version=”1″ xmlns=”http://schemas.microsoft.com/phone/2013/policy”><Deny> <App ProductId=”{0b4016fc-d7b2-48a2-97a9-7de3b5ea7424}”/> </Deny></AppPolicy>

That configuration will make the Microsoft Intune Company Portal app, deployed via Microsoft ConfigMgr, truly the only available Microsoft Intune Company Portal app. It’s now not possible anymore to have two functional Microsoft Intune Company Portal apps on a Windows Phone 8.1 device.

Windows Phone Store app

The other option would be to make the Microsoft Intune Company Portal app, of the Windows Phone Store, (close to) the only available Microsoft Intune Company Portal app by changing the requirements of the Microsoft Intune Company Portal app in ConfigMgr.

imageThis can be achieved by editing the requirements of the standard Deployment Type of the Microsoft Intune Company Portal app and adding a requirement for only Windows Phone 8.0 devices. This requirement will make sure that the Microsoft Intune Company Portal app will not show in any Company Portal, on a Windows Phone 8.1 device, as an optional installation.

That configuration will make the Microsoft Intune Company Portal app, of the Windows Phone Store, almost always the only available Microsoft Intune Company Portal app. There remains a couple of situations in which it’s still possible to install the Microsoft Intune Company Portal app, deployed via ConfigMgr.

  • wp_ss_20150413_0001The first situation comes during the enrollment of a Windows Phone 8.1 device. After the account is added there is the option of Install company app, which in fact will download and install the Microsoft Intune Company Portal app that’s deployed via ConfigMgr.
  • The second situation comes when the workplace settings of the company are opened. This provides the option of download hub, which in fact will download and install the Microsoft Intune Company Portal app that’s deployed via ConfigMgr.

No matter how the application is configured, these option will always be available in this scenario.

Conclusion

Even though I like the Microsoft Intune Company Portal app, of the Windows Phone Store, more, it does not seem to be possible, yet, to completely remove the Microsoft Intune Company Portal app that’s deployed through either Microsoft Intune or ConfigMgr. There always seems to be a way to “secretly” install a second Microsoft Intune Company Portal app that’s deployed via either Microsoft Intune or ConfigMgr. Simply keep this in mind with determining how to manage applications on Windows Phone 8.1 devices. That will save a lot of confusion with the end-user.

Retire or wipe mobile devices via PowerShell

This blog post will be about a new tool, written in PowerShell, to retire and/ or wipe a mobile device. Let’s start with the fact that I know that it’s possible to retire and/ or wipe a mobile device through the ConfigMgr console, but that didn’t stop me from creating this tool. The reason for that is related to how mobile devices are managed and who is usually responsible.

In most cases the service desk is responsible for helping end-users with their mobile devices. Now what if a company rather not provides the ConfigMgr console to the service desk, or a company wants to prevent the service desk from wiping a mobile device? That’s were this tool comes in place.

>> Available via download here on the TechNet Galleries! <<

Overview

RW_Overview

Now lets start with a quick overview of this tool. The interface is pretty straight forward. It provides a textbox to provide a username. This textbox has a tooltip to provide information about the required information. After providing a username the Get button can be used to get the registered mobile devices of the specified user. The mobile devices, of the specified user, will be shown in the datagridview. After selecting a mobile device, in the datagridview, the Retire and/or Wipe buttons will enable, if applicable. Wiping a mobile device is not applicable for Windows (RT) devices.

Messages

This tool provides a few messages based on the actions performed by the administrative user. The following message can show, based on the provided input.

RW_ValidUsernameThe message Please provide a valid username will show when the textbox was left empty and the Get button was used already.

Together with this message, also the error message Please verify the username will show next to the textbox.

RW_ExistingUsernameThe message Please provide an existing username will show when a wrong username was specified.

Together with this error message, also the error message Please verify the username will show next to the textbox.

RW_DeviceUsernameThe message Please provide an user with a primary mobile device will show when an username was specified that doesn’t have a (primary) mobile device configured.

Together with this message, also the error message Please verify the username will show next to the textbox.

RW_GenericIssueThe message Please verify the connection with the specified site server will show when anything else will go wrong. In most cases that will be an issue with the provided information for starting the tool.
RW_VerificationRetireThe message Are you sure that you want to retire the mobile device with the ResourceId <ResourceId> will show when a mobile device was selected and the Retire button was used.
RW_InitiatedRetireThe message The action to retire the mobile device is successful initiated will show when the action to retire the mobile device was successfully initiated.
RW_VerificationWipeThe message Are you sure that you want to wipe the mobile device with the ResourceId <ResourceId> will show when a mobile device was selected and the Wipe button was used.
RW_InitiatedWipeThe message The action to wipe the mobile device is successful initiated will show when the action to wipe the mobile device was successfully initiated.

Usage

Before this tool can be used, the user, or service account, used to start this tool, requires at least the permissions as described in this post. Besides those permissions, there are no special requirements for using this tool. I also didn’t use the ConfigMgr cmdlets, which completely removes the dependency to install the ConfigMgr console (or do something creative with the cmdlets).

To start this tool the following parameters are available.

  • SiteServer: This parameter is mandatory and should point to a server containing the SMS provider;
  • SiteCode: This parameter is mandatory and should be the (primary) site code of the mobile devices;
  • AllowWipe: This switch is optional and enables an additional button to wipe a mobile device.

All these parameters together will make a complete example look like this.

.\Retire-MobileDevice.ps1 -SiteServer CLDSRV02 -SiteCode PCP -AllowWipe

Troubleshooting Windows Phone 8.1 enrollment – Part 2

A few months ago I did a blog post about How to troubleshoot Windows Phone 8.1 enrollment via Microsoft Intune. By then that was the only method to get log files from a Windows Phone 8.1 device for troubleshooting, but that has changed. A few days ago Microsoft released a document describing a different and easier method to get log files from a Windows Phone 8.1 device. This method is all around the, recently released, Field Medic app. As I previously wrote about troubleshooting Windows Phone 8.1 enrollment, I thought it would be good to do a short follow up with this easier method.

Steps

Let’s go through the required steps on a Windows Phone 8.1 device, to get the required logging. It’s pretty straight forward, but definitely good to know.

FieldMedic FieldMedic_Advanced FieldMedic_Advanced_Providers
Download and install the Field Medic app from the Store. Start the Field Medic app and select Advanced. In the advanced screen select <16 categories selected>.
FieldMedic_Advanced_Enterprise FieldMedic_Advanced_Logging FieldMedic_Advanced_Report
In the categories screen select Enterprise and return to the begin screen of the app. Start logging by selecting Start Logging. Now perform a normal enrollment and select Stop Logging. Provide a Report title and Save the logging.

Now connect the Windows Phone 8.1 device to a computer. On the computer open the File Explorer and navigate to [PhoneName] > Phone > Documents > FieldMedic > reports. The folders are numbered like, WPB_000_yyyymmdd_xxxxx. The folder with the most recent date contains the latest log files.

The MDM distribution point

imageThis blog post will be about the MDM distribution point. The MDM distribution point is the distribution point that’s added after completing the Microsoft Intune integration. To be honest, I didn’t even know that the distribution point was named MDM distribution point. Also, I don’t know if it’s the official name, but I do know that it’s being referenced like that in every related log file.

In the rest of this blog post I’ll describe the high level flow of a package to the MDM distribution point.

SMS_DISTRIBUTION_MANAGER

The SMS_DISTRIBUTION_MANAGER is the default component for handling all the content notifications. Once a distribution point is added to a package, the SMS_DATABASE_NOTIFICATION_MONITOR drops a notification file in the distmgr.box and by that triggers the SMS_DISTRIBUTION_MANAGER to start processing the package. So far nothing different from a normal distribution point.

What makes it different is what follows now. The SMS_DISTRIBUTION_MANAGER detects that the package is targeted to the MDM distribution point. This triggers the SMS_DISTRIBUTION_MANAGER to copy the package to the DMP connector share instead of going the normal route to a (remote) distribution point. The DMP connector share is a shared folder named SMS_OCM_DATACACHE and is located on the site server in the installation directory of ConfigMgr. After that the SMS_DISTRIBUTION_MANAGER is done with its work for this package.

SMS_OUTGOING_CONTENT_MANAGER

The SMS_OUTGOING_CONTENT_MANAGER is the component for sending the packages targeted to the MDM distribution point. Just like with a normal cloud distribution point this action is not performed before encrypting the files. The SMS_OUTGOING_CONTENT_MANAGER picks up the content in the SMS_OCM_DATACACHE and uses it as the content source directory of the package. The next thing the SMS_OUTGOING_CONTENT_MANAGER does is encrypting the content files and for that it uses a temporary folder named SoftwarePublishing located, by default, in C:\Windows\TEMP\. When the content files are encrypted they’re uploaded to the MDM distribution point and, like all the connections with Microsoft Intune, for connecting to the MDM distribution point the certificate issued by SC_Online_Issuing is used. This certificate is generated during the completion of the Microsoft Intune integration.

When its all done the SMS_OUTGOING_CONTENT_MANAGER drops a state message in auth\statesys.box\incoming that will be picked-up by the normal process for state messages.

More information

Read the smsdbmon.log, the statesys.log, the distmgr.log and the outgoingcontentmanager.log for all the information about this whole process. For more information about all the log files see: https://technet.microsoft.com/en-us/library/hh427342.aspx