Clarifying: DNS Publishing in Configuration Manager

Clarifying: DNS Publishing in Configuration Manager

  • Comments 3
  • Likes

[Today's post is supplied by Carol Bailey]

DNS publishing was introduced in Configuration Manager 2007, and perhaps because of the vagueness in the term ("to publish" simply means to make available), we see a number of customer questions and confusions about this option - what it is and when it should be used.  This post addresses the commonly asked questions and confusions that we've seen around this option.

First, let's confirm what DNS publishing does not do, so that we can eliminate the common confusions.  DNS publishing in Configuration Manager Does NOT:

  • Have anything to do with site assignment.
  • Publish host (A or AAA) records for management points so that clients can resolve the FQDN of the management point to the correct IP address.
  • Allow clients to find an Internet-based management point.
  • Allow clients to find an NLB management point.
  • Allow clients to find proxy management points.
  • Allow clients to find the server locator point.
  • Work with auto-site assignment.

That's a long list of what DNS publishing in Configuration Manager doesn't do.  So what does it do and what is it for?  DNS publishing in Configuration Manager provides an optional, alternative service location method by which clients can find their default management point when this isn't possible with Active Directory Domain Services - perhaps because they are workgroup computers, or clients from another forest, or because the site is not publishing to Active Directory Domain Services. 

There are two other methods that clients can use to find their default management point, so why add this new method?  The other methods are to use WINS and the server locator point.  One of the reasons for adding DNS publishing was for clients in native mode that couldn't use Active Directory Domain Services for service location.  These clients cannot use WINS to locate their default management point (although they can use WINS to locate a manually added record for the server locator point, and for name resolution).  Additionally, for native mode clients to use a server locator point, they must be configured with an option that weakens security so that they can use HTTP in addition to HTTPS.  The other reasons included increased reliability and scalability.  In large-scale networks, replication of WINS records or a non-joined up WINS solution can result in problems when you are relying on this method for service location.  In comparison, DNS is better suited to highly distributed and more complex networks, which includes a disjointed namespace.

How DNS publishing works in Configuration Manager is by the client looking for a service location resource record (SRV RR) in DNS, which contains its assigned site code, in a particular domain.  The SRV record can be automatically created by Configuration Manager (enable the option "Publish the default management point in DNS (intranet only) in the site properties, Advanced tab) or it can be manually created by the DNS administrator. 

Configuration Manager 2007 supports RFC 2782 for service location records, which have the following format: _Service._Proto.Name TTL Class SRV Priority Weight Port Target.  Within this record, the _Service field uses  _mssms_mp_<sitecode>, where <sitecode> is the management point's site code (which is why you cannot use auto-site assignment, because you might have more than one site in a single domain). The Target field specifies the FQDN of the management point, which is why you must have an additional host record to resolve that name to an IP address.

How does the client know which DNS zone to use to look for this record?  Because the client is configured with the domain suffix of its default management point - either by using the CCMSetup option DNSSUFFIX, or the UI option of "Specify or modify a DNS suffix for site assignment below" on the Advanced tab of the client properties.  Yes, I know that this wording says it's used for site assignment, but it's inaccurate.  However, the F1 help for this tab and option is accurate.  Unfortunately, we didn't find this discrepancy until it was too late to change it.  Site assignment uses Active Directory Domain Services or the server locator point, not management points.  However, clients cannot be managed until they find their default management point in their successfully assigned site, so the net result is very similar.

Hopefully, by explaining how DNS publishing of the default management point works, you can now see why it doesn't do some of things on the Does Not list.  Let's run through them one by one with an explanation.  DNS publishing in Configuration Manager does not:

  • Have anything to do with site assignment.  Explanation:  We've already established that site assignment uses Active Directory Domain Services or a service locator point - and has nothing to do with the default management point, despite the wording in the client UI.
  • Publish host (A or AAA) records for management points so that clients can resolve the FQDN of the management point to the correct IP address.  Explanation:  DNS publishing of the management point uses an SRV record - for it to work, you must already have a host record for the management point's FQDN.
  • Allow clients to find an Internet-based management point.  Explanation:  Clients must be manually assigned to an Internet-based management point in their assigned site.  Unlike management points on the intranet, Internet-based clients cannot use service location for this configuration. 
  • Allow clients to find an NLB management point.  Explanation:  In theory, there's no reason why you can't manually create an SRV record for an NLB management point, but it was never tested and so is not supported.  When Active Directory Domain Services cannot be used for service location, clients can find NLB management points in WINS (with a manual entry, and only if clients are in mixed mode) and using the server locator point.
  • Allow clients to find proxy management points.  Explanation:  When Active Directory Domain Services cannot be used for service location, the default management point instructs clients to use a proxy management point when applicable.
  • Allow clients to find the server locator point.  Explanation:  There is no SRV record for the server locator point.  Instead, this site system can be assigned to clients manually, using CCMSetup and SMSSLP, or clients can locate it with a manually created entry in WINS (includes native mode clients).
  • Work with auto-site assignment.  Explanation:  In order to find the right SRV record in DNS, clients must be configured with their site code. 

For more information about DNS publishing in Configuration Manager, and how service location works, see the following in the Configuration Manager documentation library:

For customers already using DNS publishing of the default management point and wondering why the port field is not 80 or 443 as expected, see this blog post:  Why is My Management Point Published in DNS with Port Number 79 - or No Port Number?

-- Carol Bailey

This posting is provided "AS IS" with no warranties, and confers no rights.

 

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • I recently came across your blog and have been reading along. I thought I would leave my first comment. I don't know what to say except that I have enjoyed reading. Nice blog. I will keep visiting this blog very often.

    Ruth

    http://ramupgrade.info

  • In case you missed them, the following posts were published on the System Center Configuration Manager

  • Knowing that SCCM uses AD naming for its internal communications and NOT DNS FQDN, how do you suggest that people with disjoined namespace configure these fields? If you use the AD naming myserver.domain1.company.net then your clients cannot find the MPs. If you use the DNS FQDN, siteserver.company.com then the servers can communicate but the you cant use BITS as the servers will try to use the AD naming to resolve within IIS..

    There should be an easier way to manage naming and resolution of the servers and the clients.