joeware - never stop exploring... :)

I was recently reading something where someone described a multi-tree forest as a forest with a disjoint namespace. This is not correct and since there seems to be quite a bit of confusion on what exactly a disjoint namespace and its supportability is I thought I would put some words out there about it since my first forest I supported in production had both types of possible disjoints and we went around and around with Microsoft initially on what was and wasn’t supported.

 

What a disjoint namespace isn’t 

So anyway… to start off with if you have a forest with a root domain of domain.com and another domain of bob.com, that is a forest with two domain trees. The naming hierarchy isn’t preserved in a child-parent manner and when you add a domain to a forest that does that, you have added a new tree. There is absolutely nothing out of the ordinary when doing this, it can simply be a source of confusion for folks because they tend to expect a a certain hierarchy. It only gets dangerous if a script or a program doesn’t take the separate trees into account. How is that you ask? In two main ways really.

1. Scripts/programs that do silly things like work out the structure of the environment by string manipulation of DNs. So for instance, if you are in the domain child.bob.com the script truncates the string down to bob.com to determine the root domain. This is obviously way incorrect if the forest root is actually domain.com. However if you have a domain of child.domain.com, the script could actually appear to work properly (really it depends on what it does with that info on whether it works or not…). The lesson here is DO NOT make assumptions on the hierarchy based on the name of any given domain that you are aware of. Look up the info in the ROOTDSE (there is a reason that info is supplied anonymously people!!!!)
2. Scripts that actually look up the root properly in the ROOTDSE and then make an assumption that a GC search starting at the root domain of domain.com will look at every object in the forest. To be honest, you can’t fault people too much for this because there are a lot of people that say this is how it works. It is such a popular incorrect opinion that I considered making ADFIND override the base supplied on all global catelog queries to be the null base but finally decided against it because some people actually do do it correctly and would be confused when that happened and they intended something else… So let me tell you authoritatively… using the root domain as the base of a GC doesn’t guarantee you will see every object in the forest unless the forest has but a single domain tree. You can easily prove this up in a VM lab, let me give a quick example you can run off and setup. If you set your search base for the GC search to the root domain of domain.com, then bob.com and child.bob.com are not in that hierarchy to be searched and therefore absolutely will not be searched. So why does that matter? Let’s say you are running Exchange and you need to find out if the proxyaddress SMTP:Complaints@mycompany.com is in use so you don’t create another mailbox with the same email address and you base the GC search at the forest root which is the base of the domain.com tree (child.domain.com and domain.com) the name could easily exist in the bob.com tree (child.bob.com and bob.com) and cause a world of troubles if you reuse it. If you have a multiple tree environment or think it is possible you have a multiple tree environment or you have no clue whatsoever if there could be a multiple tree environment, use the null base for your global catalog searches that are supposed to search the entire directory.

 

Disjoint namespace Type 1

As I mentioned there are two types of disjoint namespaces. The first is a disjoint between  the NetBIOS name of the domain and the DNS name of the domain. So for instance, say you have the NetBIOS domain name of CORPNA for the North American Domain of the company called CORP. You also have CORPEMEA, CORPSA, and CORPAPAC for EMEA, South America, and Asia Pacific Rim. When you set up your AD domain name you are usually going to want to do something like corp.com  or maybe ad.corp.com and you really aren’t thinking you want corpna.corp.com or corpna.ad.corp.com, it is just a waste of characters and contributes to global warming. Your desire is more likely to nip that down to na.corp.com or na.ad.corp.com which means you also get emea.corp.com (emea.ad.corp.com), sa.corp.com (sa.ad… err you get the point), and apac.corp.com. You will note that all of those look much nicer, aren’t redundant, and are faster to type as well as reducing the production of green house gases by .0031% because we produce less CO2 while saying them.

The first namespace disjoint is called the Domain name disjoint. There is a disjoint between the two legal domain names of the domains in the forest. Even if you only did it with one you still have a disjoint, just like you can’t be a little bit pregnant, you can’t be just a little bit disjoint. If you have a single domain that is disjoint, you have a disjoint forest.

Oh my god, my forest is disjoint!!!! What is going to happen? Will the world collapse? Will chickens start having sex with kittens? Will Will and Boogie be voted off Big Brother All Stars? (Say that one three times fast) Will Netware actually make a comeback???? No, everything is fine. This is very standard and quite common in larger organizations. It is a bit confusing to anyone who doesn’t know it is possible and fine or does stupid things like assuming if they tack on a .COM to the NetBIOS name of the domain they get the DNS name but other than that, it is perfectly cool.  

 

Disjoint namespace Type 2

The second of the two types of namespace disjoints is not as common for most deployments but I have seen it in several larger distributed organizations, especially those with well established DNS environments that didn’t have anything to do with Windows. You know the companies, the ones that use many different platforms even though Windows may be the primary one. You find mainframes, miniframes, linux, BSD, VMS, 8 flavors and 40 versions of of UNIX, etc.

The second disjoint is a disjoint between the DNS Hostname of the machines in the domains and the DNS Domain Name of the AD Domain. So to follow the previous example, you have the CORPNA domain of na.corp.com but the machines in the domain don’t have na.corp.com in their fully qualified domain name (FQDN). So normally one would expect to see the domain controller DC1 of the na.corp.com domain to have an FQDN of dc1.na.corp.com. But in this type of disjoint, the DC1 machine may actually have a name of dc1.fresno.cali.us.na.corp.com and DC2 may have a name of dc2.tampa.fl.us.na.com and DC3 may be a DC for the EMEA forest and have a name of dc3.telford.bfe.england.corp.com. Now I know when some people see this they may just drop off the deep end and have their mind explode (sorry for that) but this is perfectly legal[1] and supported and works fine. With domain controllers you don’t have to do anything special, with member machines according to an MSKB you have to grant them SELF rights for updating their own SPN and dNSHostName; this is really simply and should just be done at the root of the domain right off and then you can forget about it. I never really tried to verify what the complete “real” fallout would be if you don’t but that is what the KB says and honestly granting SELF rights to the computer for those attributes isn’t all that scary though I have seen some what if comments around it. I saw an extremely large org run this way and it worked just fine and honestly, I preferred that versus having a hundred thousand machines registered in a single domain DNS zone.

This disjoint can also cause issues in stupid applications that do stupid things. For instance an application that figures it can look at the machine’s FQDN (dNSHostName) to work out what AD Domain the machine is in… If they did things properly, this would absolutely not be an issue though.

 

SUMMARY

Now you know what the actual disjoint namespaces are. If you happen to have one or the other or even a multiple tree forest make sure your lab environment reflects that exactly or else your tests to prove out applications is absolutely worthless. I have seen way too many times some sort of disjoint or non-standard deployment in production and a test lab that is soup to nuts perfectly standard and then people all confused that something worked great in the test lab but blew up in production…

 

 

[1] There was some question about it for some time if it was. Initially back in 2000 we were told it was supported and then a few weeks later we were told it was unsupported and then a few weeks after that we were told it was supported. Finally we asked for someone high level to make the call one way or the other and the call was made and it is supported. However, being supported doesn’t mean the various product teams at MSFT won’t occasionally screw it up. Some of the recent releases of MOM and SMS can bear that out.