Same Netbios names in different child domains
Hi all, First of all, please don't kill me; I DID search for the answer. Setup: AD forest: contoso.com One child domain per site; say site1.contoso.com and site2.contoso.com. ConfigMgr setup in Site1 (in domain site1.contoso.com), currently configured to serve both Site1 and Site2. (Trying to keep it simple as I'm a first-timer.) I have explicitely setup a child domain per site to be able to have duplicate hostnames; i.e. dc.site1.contoso.com and dc.site2.contoso.com. Now it seems configuration manager doesn't support this kind of setup, am I right? In the case of the example, in Collections, only one of the two servers with hostname DC show up. While I'm at it, simple other question: does ConfigMgr need dns suffixes configured properly, to reach the computers in the other domain? Or does it connect by FQDN..? I personally hate Netbios and I was ruling it out of my environment completely.. I understand that in the local domain (say to connect to the db, configured as \\SQL1), it can connect properly find it because .site1.contoso.com is suffixed, is that correct? Thanks for your help, Fréderic
October 25th, 2010 2:42pm

Now it seems configuration manager doesn't support this kind of setup, am I right? In the case of the example, in Collections, only one of the two servers with hostname DC show up. [...] While I'm at it, simple other question: does ConfigMgr need dns suffixes configured properly, to reach the computers in the other domain? Or does it connect by FQDN..? Yes, you're right. Name resolution has to work fine. I don't understand the difference between "dns suffix" and "FDQN" in your statement. Isn't a FDQN name composed of name + dns suffix?
Free Windows Admin Tool Kit Click here and download it now
October 25th, 2010 2:56pm

There was a very recent hotfix addressing AD System Discovery's ability to resolve IP Addresses for systems not in the DNS namespace of the site server itself on Server 2008 R2: http://support.microsoft.com/default.aspx?scid=kb;en-us;2345551&sd=rss&spid=12769.Jason | http://myitforum.com/cs2/blogs/jsandys | http://blogs.catapultsystems.com/jsandys/default.aspx | Twitter @JasonSandys
October 25th, 2010 4:13pm

Unfortunately, Configuration Manager doesn't support this setup where many of the calls still use a flat namespace. So, for example, if you install a site system server for a hostname of "server" in site1.contoso.com from site2.contoso.com and you have a computer named server.site2.contoso.com, your DNS server for site2.contoso.com is going to resolve "server" to the computer in site2.contoso.com (which isn't what you want). Only if you didn't have a hostname of server in site2.contoso.com would a dns search suffix (or forwarding) work. Similarly for server-initated calls to clients, such as client push installation - these also use a flat namespace. The calls that do support an FQDN (when you've specified an FQDN in the site system properties) include client-initiated calls to the management point, distribution point, software update point, and fallback status point (the site systems that support Internet-based client management).
Free Windows Admin Tool Kit Click here and download it now
October 25th, 2010 4:24pm

There was a very recent hotfix addressing AD System Discovery's ability to resolve IP Addresses for systems not in the DNS namespace of the site server itself on Server 2008 R2: http://support.microsoft.com/default.aspx?scid=kb;en-us;2345551&sd=rss&spid=12769 . Jason | http://myitforum.com/cs2/blogs/jsandys | http://blogs.catapultsystems.com/jsandys/default.aspx | Twitter @JasonSandys Great news, hope that will resolve my problems! Going to test it this instant, and I'll let you know if it resolved my issues and mark your reply as answer! Won't it be having the same issues as Carol Bailey pointed out for server-initiated connections?
October 26th, 2010 5:54am

Too bad, the hotfix doesn't same to make any difference. I found out, however, that these systems (like server.site1.contoso.com and server.site2.contoso.com) get merged records in the collections; so the out-of-domain clients are successfully discovered but are seen as 1 system. When I open the properties, the says i.e. IP Address[0] = ip.of.server.site1 IP Address[1] = ip.of.server.site2 Same story for its FQDNs (Resource Name[]). Too bad.. Don't quite understand how this can scale with very large environments, with trusted forests etc... Especially when companies get merged.. Guess I'll have to rename a bunch of servers :( Any hopes for this for v.Next? Don't see how this would be hard to implement; just use \\HOSTNAME.FQDN instead of \\HOSTNAME? :S Thanks, Frederic
Free Windows Admin Tool Kit Click here and download it now
October 26th, 2010 6:14am

The hotfix only addresses AD System Discovery and it's ability to resolve IPs for clients not in the same (DNS) domain as the site server -- it doesn't do anything about the duplicate hostname issue.Jason | http://myitforum.com/cs2/blogs/jsandys | http://blogs.catapultsystems.com/jsandys/default.aspx | Twitter @JasonSandys
October 26th, 2010 11:23am

Guess I'll have to rename a bunch of servers :( Any hopes for this for v.Next? Don't see how this would be hard to implement; just use \\HOSTNAME.FQDN instead of \\HOSTNAME? :S Submit this feedback request on the Microsoft Connect site for Configuration Manager v.Next and explain that you use the same hostname in different domains. The product group takes customer justification very seriously when considering changes.
Free Windows Admin Tool Kit Click here and download it now
October 27th, 2010 12:07pm

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics