Tagged: DNS

Active Directory – Lab 1 ADDS with internal subdomain

The majority of Active Directory domains I have seen use a standalone internal domain such as .local, .internal or .company name.

When you suggest that the Active Directory domain should be a subdomain of the company’s public domain, you get the worried look that you’re exposing Active Directory to the internet… o_O.

If you take time to read Microsoft TechNet you’ll discover an article which details an internal subdomain of your public domain as the recommended way to deploy a DNS namespace, see here.

So If you’re building a new Active Directory domain then please feel free to follow the instructions details below.

Windows Server 2008 R2


  • Windows Server 2008 R2 media – download an evaluation from here
  • A static IPv4 address
  • Your internet providers DNS server IP addresses
  • A public DNS name registered with an applicable authority


Install Windows Server 2008 R2, assign a static IP address, give the computer a suitable name and then run dcpromo.

Computer Name: ADDS01

IP Address Gateway Primary DNS


Forest root domain FQDN: office.[public domain name]


Reboot when prompted

DNS Configuration

Create a reverse DNS zone for your local subnet.


Create DNS forwarders which point to your ISPs DNS servers and deselect use root hints if forwarders are unavailable; this basically passes on the recursive DNS queries to your ISP rather than your DNS server. If root hints is left ticked then should your ISPs DNS servers be unavailable then your internal DNS will perform recursive DNS queries. Just FYI recursive DNS can be vulnerable to DOS attacks, cache poisoning and other issues commonly found when a DNS server is incorrectly configured.


Remove the root hints.


Testing DNS resolution using Network Monitor

Run Network monitor and scope the display filter to the DNS protocol, click start.

Because forwarding is enabled there are only two ethernet frames.


Initial query to my ISPs DNS servers.


Response from my ISPs DNS servers.


Office 365 – Lab 1 ADDS and DirSync

Lab 1


  • Office 365 trial
    • Directory Synchronisation enabled within Office portal
    • Public domain name
    • Applicable DNS records configured
  • Windows Server with ADDS installed
  • Windows 7 client
  • Windows Server client
  • Enterprise Administrator credentials
  • Global Administrator credentials


The purpose of this lab is to simulate the implementation of DirSync with Office 365 using an Active Directory domain which has been deployed with a non-public routable DNS domain name e.g. domain.local or domain.internal.

Once DirSync is synchronised with Office 365 then I’ll look at implementing Office 2013 on the Windows 7 client logging in as a domain user and observing the effects of DirSync and the password synchronisation feature.

Lab Setup

Domain Controller

Install Windows Server 2008 R2, assign a static IP address, give the computer a suitable name and then run dcpromo.

Computer Name: ADDS01

IP Address Gateway Primary DNS


Forest root domain FQDN: office.local


The forest functional level needs to be at least Windows Server 2003.

reboot on completion.

DNS configuration

Create a reverse DNS zone for your local subnet.

Create DNS forwarders which point to your ISPs DNS servers and deselect use root hints if forwarders are unavailable.

Remove the root hints.

Active Directory configuration

Using the Domains and Trusts snapin configure a publicly routable DNS name; this UPN must match your domain defined within the Office 365 portal.


Then configure all users who will be using Office 365 to use the public DNS name for their UPN; you can multi select.


DirSync Server

Install Windows Server 2008 R2, assign a static IP address, assign a suitable name and join to the domain.

Computer Name: MSOLDS01

IP Address Gateway Primary DNS


Join the computer to the office.local domain.

Install DirSync ensuring the prerequisite software is installed e.g. Microsoft .Net Framework 4.0.

DirSync configuration

Follow the wizard entering the global administrator username and password for your Office 365 environment.


Enter the username and password of an account with Enterprise Administrator membership.


Enable password synchronisation – http://technet.microsoft.com/en-us/library/dn246918.aspx. This enables the user to only remember one password; when the user changes their password within the on-premises ADDS the password will be synchronised within minutes.


Once you click finish you’ll be prompted to synchronise your ADDS with the cloud.


With password sync enabled the directory sync will result in the application event log recording verify Password Change Requests and Password Change Results for user accounts



You also notice event ID 650 and 651 recorded to signify that synchronisation has started and finished.

Once the directory synchronisation is complete you can verify within the Office 365 portal the last sync time and synchronised users.



Windows 7 Client

Install Windows 7, assign a suitable and name and join it to the domain. I’ve assumed DHCP is deployed so no need to configure an IP address.

Computer Name: Client01


Join the computer to the domain.

Client configuration

Logon to the client computer using your domain credentials e.g. jbloggs@UPN, login to the Office 365 portal and install Office 2013.


Open Outlook 2013 and follow the wizard, if your Active Directory properties do not have an email address defined as below then then Outlook auto-configure will not populate the Display Name, Email address etc.



Click next, If you have configured your DNS records as suggested by Microsoft e.g.


then Outlook will auto-configure itself too, you’ll be prompted for your Office 365 credentials as we are not using federated logins but because the password has been synchronised the password is the same as your Windows login credentials.


If you haven’t configured the autodiscover record correctly this step will fail; check out https://www.testexchangeconnectivity.com/ and select Outlook Autodiscover.


Outlook 2013 is now connected to Exchange Online


MCTS 70-646 Plan high availability

Plan high availability

Service redundancy

More on Microsoft failover clustering here

Microsoft failover clustering no longer supports direct parallel SCSI and requires shared storage that is SCSI Primary Commands (SPC-3) compatible i.e. uses SCSI-3 persistent reservations.

Service availability

More on Microsoft Load balancing and DNS round robin here

Mixed-mode clusters are possible but it is recommended that all cluster  nodes are running the same operating system.

If IGMP multicast mode is used then IGMP snooping must be enabled on the switch.

Each cluster host sends a heartbeat every second, if five consecutive heartbeats are missed then the cluster converges removing the failed host.

The MCITP self-paced training kit for Windows Server 2008 administrator seems to suggest that Microsoft testing has found that NLB clusters with more than 8 nodes are not efficient. If you need more than 8 nodes consider multiple NLB clusters which use DNS round robin.

DNS round robin is enabled by default, remember than netmask ordering is enabled by default too; netmask ordering will return the ip address of a particular record which is within the same subnet. DNS netmask ordering uses class C to determine whether the network is local.