The official blog of the Microsoft System Center Configuration Manager Product Group
[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:
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:
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.
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.
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.