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

An overview of my posts about ConfigMgr 2012 SP1

Let’s start my first post, of this new year, with an overview of my latest post about ConfigMgr 2012 Service Pack (SP) 1. Normally I’m not really the kind of person that looks back, but in this case it’s with a reason, as most of my posts where with pre-release versions of SP1. I also tried to sort all my posts per subject, even though sometimes there is some overlap. The following posts are all tested, this week, with the RTM version of SP1 and I can confirm that they are still working:

System Center Orchestrator

Windows Azure

Windows Intune

OS Deployment

Application Deployment

Client Settings

Allowing access to Cloud Distribution Points for specific systems with ConfigMgr 2012

To end this year in the cloud, I would like to devote this weeks post to allowing systems access to cloud distribution points. A bit more then two months ago I already did a post about creating a cloud distribution point, but until now I’ve never posted anything about the client configuration. By default, a system is not allowed access to cloud distribution points.

Prerequisites

Before it’s even useful to allow a system access to a cloud distribution point, the system needs to be able to resolve the name of the cloud distribution point. There are two ways to achieve this:

  • The proper way – Create a public CNAME –record to map the service name, provided with the certificate for the cloud service, to the Windows Azure service FQDN.
  • The dirty way – Create a private HOST –record to directly map the the service name, provided with the certificate for the cloud service, to the IP address of the Windows Azure service FQDN (only for testing!).

Configuration

CusPolAllCloDisPoiNow lets start with the configuration, which is actually very easy. Like almost all the previous times, this year, it’s all about knowing that the possibility exists. The configuration is another new Client Setting in ConfigMgr 2012 SP1, named Allow access to cloud distribution point. This setting can be used to control access to cloud distribution points. To configure this, for specific systems, follow the next steps:

  • In the Configuration Manager Console navigate to Administration > Overview > Client Settings.
  • On the Home tab, in the Create group, select Create Custom Client Device Settings and the Create Custom Client Device Settings –popup will show.
  • On the General page, fill in with Name <aName> and select Cloud Services.
  • On the Cloud Services page, select next to Allow access to cloud distribution point Yes and click Ok.
  • Select the new policy <aName> and on the Home tab, in the Client Settings group, select Deploy.
  • Select <aDeviceCollection> and click Ok.

Result

PolSpyCloDisPoiAs always, now it’s time to take a look at the result. In this case I want to show two things, first the result, and second the impact, of the deployment of the new Client Settings. Normally, the best places to look at the results are the log files. In this case, there is no log file that shows whether cloud distribution points are allowed, or not. So the best place to look at that is the old-school Policy Spy. It will show AllowCloudDP = True as a custom setting under, in this case, Machine \ CustomSettings.

To look at the impact, the best places are still the log files. There are lot’s of log files that will show the usage of the cloud distribution points. A cool log file to look at the different blobs that are used during the download is the DataTransferService.log. The log file that I will show under here is the ContentTransferManager.log. In here it will also show the cloud distribution point, including the message that the Content location type is Azure.ConTraManAzuDisPoi

Creating a Cloud Distribution Point with Windows Azure and ConfigMgr 2012

This week I decided to start with Windows Azure. One of the biggest reasons for that, was that I knew that with ConfigMgr 2012 SP1, which is currently still in BETA, it is possible to create a Cloud Distribution Point based on Windows Azure. So that’s what I decided to start with this week.

Prerequisites

First I started with figuring out how exactly Windows Azure works. It’s actually quit easy to set-up, but after another good look at ConfigMgr 2012 I figured that it’s not even necessary to do anything within Azure. The following things are a prerequisite for creating a Cloud Distribution Point:

  • Create a Windows Azure subscription.
  • Create a certificate for the management of Windows Azure.
  • Add the management certificate to Windows Azure.
  • Create a certificate for the new cloud serivce.

Configuration

The configuration was actually quit easy and, as always, a nice wizard. To create a Cloud Distribution Point navigate to Administration > Overview > Hierarchy Configuration > Cloud, click Create Cloud Distribution Point and follow the next steps:

On the General page, fill in a Subscription ID, add a Management Certificate and click Next. CCDPW_Gen
On the Settings page, a Service Name will be generated, Browse to a certificate for the cloud service and click Next. CCDPW_Set
On the Alerts page, configure alerts and click Next. CCDPW_Ale
On the Summary page, click Next. CCDPW_Sum
On the Completion page, click close. CCDPW_Com

Result

As always I like to show the results of the actions. This time I will do it with a few small screenshots instead of log files. The log files where the most actions are logged are the CloudMgr.log and the DistMgr.log. First take a look at the results in the ConfigMgr Console, there is now a Cloud Service and a new Distribution Point:CloSerCloDP

Now let’s have a look at Windows Azure, to see what’s created there. There should be a Storage Account and a Cloud Service:AzuSer

AzuConAlso a more closer look look the Storage Account will show that the Cloud Distribution Point is created. The contentservice-master-container, the deploymentcontainer, the publickeystore and the wad-control-container are default containers, but to show that the server-side is working I already uploaded content and that’s the content-ptn0001b container.

For more information see: http://technet.microsoft.com/en-us/library/hh272770.aspx#BKMK_InstallCloudSiteSystems

The NEW Distribution Point in ConfigMgr 2012 B2

I already tweeted last week that I really, really like the new Distribution Points in ConfigMgr 2012. Around that time they started writing some really good posts at the ConfigMgr OSD Blog about the new Distribution/PXE Point and Content Management. Even though these posts give really good information I still feel like I have to write down what I really, really like about it. So in this post I will sum up some of the cool new features/ properties of the new Distribution Point in ConfigMgr 2012. 

  • Distribution Point Role: The Distribution Point Role is now merged into one single type that can be used on workstations and server. Also there is now the ability to choose (and prioritize) two drives for the use of the Distribution Point. To me this is a logic choice as there are now no vague difference anymore in what is supported with which type of Distribution Point.
  • DPPropertiesPXEPXE Service Point Role: The PXE Service Point is now a property of a Distribution Point. To me this is a logic choice, as there was always a Distribution Point needed when there was a PXE Service Point. Besides that it also saves a lot of confusion, because of the extra Server Share Distribution Point that got created (SMSPXEIMAGES$). Adding a Boot Image to the RemoteInstall folder of WDS is now just a property setting of a Boot Image (Deploy this boot image from the PXE Service Point).
  • Distribution Point Groups: The Distribution Point Groups functionality got a really nice update too. It can still be used to distribute content to multiple Distribution Points at the same time, but now it also directly distributes content (assigned to the group) to new members of the group. To me this is a really nice (and very logic) additions to this functionality, because now all the members of a group always have the same content assigned to it.
  • Content: The Distribution Point now has the option to show all the content that is assigned to. It also gives the option to validate the content and to manage (redistribute or remove) the content. Also the possibility to validate the content is added. This means as much as, the hash of the content will get checked on a schedule. When the has doesn’t mach this will be reported, but not “fixed”. To me this is a great addition to finally be able to quickly see the assigned content to a Distribution Point. Also no hash mismatches anymore! Well… if the content gets checked on a regularly base and (manual) actions will be taken.
  • Content Library: The Distribution Point now stores the data in the Content Library (SCCMContentLib). This library is divided in three parts, Data Library (DataLib), File Library (FileLib) and Package Library (PkgLib). The Data Library stores Metadata about files, the File Library stores actual files and the Package Library stores references to files. To me this looks like a good solution to prevent the many different times (and locations) that where used to store data on a Distribution Point.
  • Boundary Groups: The Distribution Point now gets protected by adding a Boundary Group directly to it. And a Boundary Group can contain multiple Boundaries. To me this is a not necessary addition, because now there will always be the need to create a Boundary Group to be able to create a Protected Distribution Point.

More information about Content Management in ConfigMgr 2012: http://technet.microsoft.com/en-us/library/gg682003.aspx