Distribution Point

This 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.

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

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

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

As 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.

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:

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.

On the Settings page, a Service Name will be generated, Browse to a certificate for the cloud service and click Next.

On the Alerts page, configure alerts and click Next.

On the Summary page, click Next.

On the Completion page, click close.

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:

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:

Also 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.

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.

PXE 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.

This time I want to devote a post to Distribution Point Groups in ConfigMgr 2007. The most important thing to understand is that Distribution Point Groups are NOT meant to balance the load. Distribution Point Groups are meant to facilitate the processes of copying packages to Distribution Points (DP). Packages can then be sent to a Group of DP’s rather than to a single DP.

One important thing to remember is that if you add a DP to an existing Group of DP’s, the new DP does not automatically receive packages that are previously copied to that Group.

Create a Distribution Point Group by following the next steps:

Open the Configuration Manager console and browse to System Center Configuration Manager > Site Database > Site Management > <YourSiteName> > Site Settings > Site Systems.

Select the/ a Distribution Point and click in the Actions pane Properties to open the ConfigMgr Distribution Point Properties.

Select the General tab and press with Group Membershipthe New Icon.

On the Distribution Point Group General Tab fill in a Distribution Point Group Name, select Include this site system in the Distribution Point Group and click Ok.

This post will be a short follow-up on a previous post about How a client chooses a Distribution Point. In that post I tried to explain how a client picks a (Remote) Distribution Point (DP). In this post I will try to take away some more confusion about Remote DP’s.

Let’s start with when a DP is considered a Remote DP. ConfigMgr looks at this from the clients perspective. If a client is within a Fast Network Boundary, then the DP(‘s) that is in the same Boundary will be marked as a Local DP. All the other DP’s are marked as Remote DP’s. The important part here is that a client has to be within the correct Boundary and that you are the only one who can make that happen. To make sure which DP is used to download, you have to make the DP Protected with that Boundary.

So if a client is on a remote location, doesn’t mean that it connects to the DP on the remote location. As long as you don’t configure a Boundary for the client, the client will see the DP on its own location as a Remote DP.

Award

Subscribe to updates

About

I’m Peter van der Woude, born in 1983 and I’m living together with my wife and two sons in the Netherlands.

Currently I work for KPN Consulting. At this moment my main focus is Enterprise Client Management via Microsoft Intune and/ or System Center Configuration Manager (ConfigMgr 2007/ 2012/ CB) and I love it!