A CNAME record is not allowed to coexist with any other data. However, DNS    servers like BIND will see the CNAME and refuse to add any other resources for that name.  Since no other records are allowed to coexist with a CNAME, the NS entries are ignored.  Therefore all the hosts in the podunk.xx domain are ignored as well!

Don't go overboard with CNAMEs.  Use them when renaming hosts, but plan to get rid of them (and inform your users).  However CNAMEs are useful (and encouraged) for generalized names for servers -- `ftp' for your ftp server, `www' for your Web server, `gopher' for your Gopher server, `news' for your Usenet news server, etc.
[RFC 1034] in section 3.6.2 says this should not be done, and [RFC 974] explicitly states that MX records shall not point to an alias defined by a CNAME.  This results in unnecessary indirection in accessing the data, and DNS resolvers and servers need to work more to get the answer.

Also, having chained records such as CNAMEs pointing to CNAMEs may make administration issues easier, but is known to tickle bugs in some resolvers that fail to check loops correctly.  As a result some hosts may not be able to resolve such names.
Having NS records pointing to a CNAME is bad and may conflict badly with current BIND servers.  In fact, current BIND implementations will ignore such records, possibly leading to a lame delegation.  There is a certain amount of security checking done in BIND to prevent spoofing DNS NS records.  Also, older BIND servers reportedly will get caught in an infinite query loop trying to figure out the address for the aliased nameserver, causing a continuous stream of DNS requests to be sent.

If the response contains an answer which is a CNAME RR, it indicates that REMOTE is actually an alias for some other domain name. The query should be repeated with the canonical domain name.

Of course, by the robustness principle, domain software should not fail when presented with CNAME chains or loops; CNAME chains should be followed and CNAME loops signalled as an error.

<request> 
    <data> 
        <preferredDomainController>Domain Controller</preferredDomainController>
        <path>LDAP Path</path>
    </data>
    <procedure> 
        <execute namespace="Exchange 2007 Provider" procedure="RepairExchangeObject" impersonate="1" > 
            <before source="data" destination="executeData" mode="merge" />
            <after source="executeData" destination="data" mode="merge" />
        </execute>
    </procedure>
</request>

Sample:

<request> 
    <data> 
        <preferredDomainController>srv01</preferredDomainController>
        <path>LDAP://[email protected],OU=MyCustomer,OU=MyReseller,OU=Hosting,DC=litware,DC=local</path>
    </data>
    <procedure> 
        <execute namespace="Exchange 2007 Provider" procedure="RepairExchangeObject" impersonate="1" > 
            <before source="data" destination="executeData" mode="merge" />
            <after source="executeData" destination="data" mode="merge" />
        </execute>
    </procedure>
</request>

The second tip is distribution lists, which are also kind of an important thing to get set up. To do this you need to craft an CreateDistributionList XML request, this is just an XML file which looks like:

<request> 
    <data> 
        <container>LDAP Path</container>
        <preferredDomainController>Domain Controller</preferredDomainController>
        <managedBy>List Owner</managedBy>
        <name>List Name</name>
    </data>
    <procedure> 
        <execute namespace="Hosted Email 2007" procedure="CreateDistributionList" impersonate="1" > 
            <before source="data" destination="executeData" mode="merge" />
            <after source="executeData" destination="data" mode="merge" />
        </execute>
    </procedure>
</request>

Sample

<request> 
    <data> 
        <container>LDAP://OU=MyCustomer,OU=MyReseller,OU=Hosting,DC=litware,DC=local</container>
        <preferredDomainController>srv01</preferredDomainController>
        <managedBy>[email protected]</managedBy>
        <name>Triage</name>
    </data>
    <procedure> 
        <execute namespace="Hosted Email 2007" procedure="CreateDistributionList" impersonate="1" > 
            <before source="data" destination="executeData" mode="merge" />
            <after source="executeData" destination="data" mode="merge" />
        </execute>
    </procedure>
</request>

You can then run that on your HMC server using the provtest command. So how do you manage who actually is in the list? Well this actually very easy, thanks to Outlook. First just open an email and type the list name in to line, then right click and select properties:

You can then use the Modify Members… button to add/remove members of this list.

Note: This can ONLY be done my the list owner which you specified when you created the list in the managedBy node.

For a consistent environment you need naming standards, but the idea of a standard is a universal adherence and in IT there is no such thing. The first thing I started to look at is a naming standard for the servers themselves. Thankfully Microsoft has published a recommendation on this (available here) which is what we decided to follow since it is a simple one and is easy enough to use and remember.

Microsoft's published recommended naming convention which is aa-bbb-ccccc-dd. The definition of the format is aa is the country code, bbb is the city designation, ccccc is the server role and dd is the number of the server. If the server is part of a cluster, array or similar then last two characters of the server role indicate which cluster it is part of.

Samples:

The first domain controller in Redmond, USA would be: us-rmd-ad-01

• us = USA
• rmd = Redmond
• Ad = Active Directory
• 01 = First Server

The first BizTalk server in the second BizTalk cluster in Cape Town, South Africa would be: za-cpt-bts02-01

• Za = South Africa
• Cpt = Cape Town
• Bts02 = BizTalk Cluster 2
• 01 = First Server

The first MSCRM server in Auckland, New Zealand would be: nz-ack-crm-01

• nz = New Zealand
• ack = Auckland
• infr = Infrastructure
• 01 = First Server

However this is the only published naming standard I could find, so the naming for databases, ISA rules etc… have all been developed internally so I can’t disclose those.

This also brings to an end this series on HMC hosting, but fear not I have a quick 3 part mini-series on the top 3 tips I have for managing a HMC environment to keep busy with.

The solution is to remove that network card and add a Legacy Network Adapter under the Add Hardware section.

This network card works regardless of integration components, but is not as fast. So once you are up and running don’t forget to change it back.

I stumbled across this with the HMC 4.5 documentation which is presented in, you guessed it, CHM help files. Just like when I found the MSDN Library Broken this is caused by a security feature trying to protect you. To resolve this you need to close the file, right click and select properties. On there in the bottom right hand corner is a nice little Unblock button which once clicked you can then use the file normally.

The last of the hurdles to overcome for the deployment was the running of the DNS server. This is because we run on a private IP range internally and use ISA to match external IP's and ports to the services we want to publish (i.e. NAT). This basically allows us to lower the attack surface because we only let out what is needed and an also mix and match servers to the same IP (lowering our IP address usage).

This also means that we have not only DNS servers to allow the servers and staff internally to find the other servers and services but we also have to have external servers too to allow users on the big bad Internet to find them. There is so much duplication of work for this configuration deployment scenario as you are having to create records on a best case of two servers and worst case is four servers and configure them differently. This also means the area for mistake is increased considerably. The upside is that internal staff do not need to go out the LAN and back in via the net or even go through the external firewalls and that we an have different domain names internally and externally, which is great for testing and development and only publishing when needed.

What I do not understand is why the DNS server team at Microsoft can't take a leaf from MSCRM 4.0's IFD deployment and allow you to specify what the internal IP range is and allow you to set A/CNAME’s for both internal IP ranges and external IP ranges. So when an internal IP requests a resolution it gives the internal A/CNAME records and for non-Internal they get the external A/CNAME record. This is such a logical thing to do, that Bind has this feature for ages, so come on Microsoft steal another idea from Linux ;)

One of the design choices for the DNS structure is a concept of mine called IP address abstraction. The idea of DNS is to get us away from IP’s but the problem is that in normal DNS configurations you end up with loads of A records and the moment you need to change IP addresses you end up with spending days changing IP addresses through all the records. What IP address abstraction is that you take a core domain name, and create a single A record for each IP you have.

Examples:

• internal1.test.com A 192.168.0.1
• internal2.test.com A 192.168.0.2

What you do then is everywhere else you use CNAMEs to those names, regardless of what the domain name.

Example:

• www.sadev.co.za CNAME internal1.test.com
• sadev.co.za MX 10 internal2.test.com
• www.test.com CNAME internal1.test.com

The advantage is that if the IP’s change ever, you change them in one place and it reflects everywhere, yet the experience to the end user is the exact same as DNS has always been.

So before I get into core, let me first state that Win2k8 is the best server OS Microsoft has ever released. It is amazing how well polished everything is, and the tools that are there are great. Does it compare to Linux servers, well in some places it kicks ass and others it doesn’t, but since Linux servers are the de facto for command line based systems if we compare the command line features then they have done a HORRIBLE job.

All that is actually happening is you are getting the normal command prompt in a Windows and they dropped Explorer.exe from being the shell. In fact explorer.exe does not even get installed, but a lot of our old favourites are there, such as Ctrl+Alt+Del still brings up the usual menu and task manager still works.

Actually Microsoft dropped so much the gain in RAM is impressive (our avg RAM usage normally is 750Mb but on core it is a mere 300Mb) and the attack surface and patch requirements shrinkage is great.

Getting back to command.com as the shell, is likely the biggest single mistake of core.It’s not like Microsoft doesn’t have a great command line system, called Powershell which they could have used. In fact there is so little added to the command line that after this experience I went to a Win2k3 machine and was able to do most of this anyway, and it’s not hard to kill explorer.exe as the shell in Win2k3. One advantage doing this core mockup on 2k3 has, is that at least Internet Explorer is there for you to get online to get help, Win2k8 core has no decent help (just the same old crappy command.com stuff).

Linux has man pages, Powershell has get-help, the console has... Thank the heavens that I was able to use my laptop to get on to the Internet. For example I had problems with the first two core boxes trying to run Hyper-V on them, it just gave all kinds of RPC issues. Turned out that although I had not set the DNS correctly using netsh, I had set it for Primary Only and not Both. What the difference is beyond me because using the Windows GUI to set network settings for the last 20 years obviously sets this correctly so why make it so much tougher.

Another interesting feature of core, which I never had to it my head with but learnt about when I attended Win2k8 IIS training that Microsoft ran and the trainer said that in Core you couldn't run ASP.NET for web sites, because Core doesn't have the .Net framework. This is because the .Net framework installer needs a GUI. I suspect this is the same reason why Powershell can't be used, being .Net based and all. But the part I don’t understand is that THERE IS A FRIGGING GUI! It's all around the command prompt Window!

My recommendation is avoid Core as the extra work doesn’t make up for the cost of a little bit of extra ram, rather spend less time on setting up the server, more time billing customers and buy the ram. Hopefully in Windows Server vNext gets it right.