MIM LAB 1: Prepare a domain controller

This post is a part of a series. The chapter index is located here.

We will look at:

  • Installing ADDS
  • Creating a domain
  • Configuring DNS
  • Creating a basic OU structure
  • Creating users and groups required for the MIM installation

Installing ADDS

VM: DC01.mim.local

  • First you have to create the VM. A small one should suffice as domain controller, say one core and 6GiB.
  • Give your DC fixed IP addresses (v4 and v6).
  • Disable IPv6 if you are not using it, as this will cause problems down the road. Also, make sure your network infrastructure and virtual environment supports IPv6 if you want to use it.
  • Set the servers’ own IP as DNS1 and local host loopback as DNS2 (127.0.0.1 / ::1).
  • Open Server Manager and add the ADDS features and roles:

 

clip_image001

  • When the installation is complete, you have to configure ADDS. Some clips from the DCPromo wizard follows:

clip_image002

 

clip_image003

 

clip_image004

 

  • DNS is grumpy and afraid that it will be all by its lonesome. We will correct this later, so you can ignore this message for now.

 

clip_image005

 

clip_image006

 

Create reverse lookup zones

You should have reverse lookup zones for the subnets where your DCs are located. Preferably for all subnets. The zones should be:

  • Primary
  • Stored in AD
  • Replicated through the domain to all DNS servers running on domain controllers.
  • Allow secure dynamic updates only

Remember to create reverse lookups zones for IPv6 as well if you are using it.

 

Set up DNS secondary and forwarding

As I have another forest with another domain in my lab that I want to cooperate with this one, I have to make sure that the DNS servers in the different domains are able to talk to each other. There are many ways to solve this, and I chose to configure DNS secondary’s and forwarding. You should always have forwarding configured to reduce the load on root hints servers. Use your local router or your ISPs DNS servers as a forwarding address.

 

Forwarding

Let your new forest forward dns requests to the existing forest, or to an external DNS. This configuration should be performed on dc01.mim.local:

 

clip_image007

 

A test will verify that you are able to look up internet addresses and local addresses. You should run the following tests on your DC:

  • Nslookup mim.local
  • Nslookup microsoft.com (or some other public dns query)
  • Nslookup second.forest.local (if you are using multiple forests).

Make sure that reverse lookup works. The name of the DNS server / Domain Controller should be listed as an FQDN, not as “Unknown”. Something like this:

 

clip_image008

 

Not like this:

 

clip_image009

 

Secondary zone

When your forwarding is working, create a secondary zone for mim.local in the existing forest. First you have to add the dns server or servers in the existing forest as a Zone transfer secondary on DC01.mim.local:

 

clip_image010

 

You could also add notification to increase update speeds:

 

clip_image011

 

On the DC in the existing forest (DC03) you create a secondary zone for mim.local.

 

clip_image012

clip_image013

 

The master dns server is the IP address for dc01.mim.local.

 

clip_image014

 

You can add the IPv6 addresses as well if you want to complicate things a bit.

Now, repeat the test from Forwarding on a client connected to the existing forest to make sure that everything works as expected. If it does not work, the DNS server event log is a good place to look for an explanation.

 

Creating an OU Structure

A complex OU structure is not really necessary in the lab, but for familiarity you should use an OU structure similar to your production setup. In this sample, we have one Services-OU containing computers, groups and service-accounts needed by installed services such as MIM, Exchange, Skype and so on. Next to it, we find an OU for objects controlled by MIM. This is where we place our end users, mail enabled groups and such. Further granularity in departments and locations are of course possible and may even be necessary.

 

clip_image015

 

Disable Server manager autostart

Server Manager is notorious for hogging a lot of memory, so we do not want it starting up at every login on our servers. As this is a lab, I just created a Domain Wide group policy, but you could of course be more granular.

The setting is located in Computer\Policies\Administrative Templates\System\Server Manager.

clip_image016

clip_image017

Create service accounts

Finally it is time to start on the MIM-specific parts. I have made some changes from the proposed setup in the MS guide:

  • Reduced it to one line per user for readability and re-usability.
  • Added an account for the SQL Server agent. The guide suggests using Network Service, but as a DBA I simply can not let such atrocities pass. I also changed the name of the engine-account to ensure an error if I should forget to update references to it.
  • Moved the accounts into my OU structure (the -path option)

Of course one would never ever use identical passwords for all these accounts in production. That kind of defeats the purpose of having multiple accounts.

Sample powershell script:

import-module activedirectory
$sp = ConvertTo-SecureString "Pass@word1" –asplaintext –force
New-ADUser –SamAccountName MIMMA –name MIMMA -path "OU=ServiceAccounts,OU=MIM,OU=Services,DC=mim,DC=local" -AccountPassword $sp -PasswordNeverExpires 1 -Enabled 1 -UserPrincipalName "MIMMA@mim.local"
New-ADUser –SamAccountName MIMSync –name MIMSync -path "OU=ServiceAccounts,OU=MIM,OU=Services,DC=mim,DC=local" -AccountPassword $sp -PasswordNeverExpires 1 -Enabled 1 -UserPrincipalName "MIMSYNC@mim.local"
New-ADUser –SamAccountName MIMService –name MIMService -path "OU=ServiceAccounts,OU=MIM,OU=Services,DC=mim,DC=local" -AccountPassword $sp -PasswordNeverExpires 1 -Enabled 1 -UserPrincipalName "MIMService@mim.local"
New-ADUser –SamAccountName MIMSSPR –name MIMSSPR -path "OU=ServiceAccounts,OU=MIM,OU=Services,DC=mim,DC=local" -AccountPassword $sp -PasswordNeverExpires 1 -Enabled 1 -UserPrincipalName "MIMSSPR@mim.local"
New-ADUser –SamAccountName SharePoint –name SharePoint -path "OU=ServiceAccounts,OU=MIM,OU=Services,DC=mim,DC=local" -AccountPassword $sp -PasswordNeverExpires 1 -Enabled 1 -UserPrincipalName "Sharepoint@mim.local"
New-ADUser –SamAccountName SqlEngine –name SqlEngine -path "OU=ServiceAccounts,OU=MIM,OU=Services,DC=mim,DC=local" -AccountPassword $sp -PasswordNeverExpires 1 -Enabled 1 -UserPrincipalName "SqlEngine@mim.local"
New-ADUser –SamAccountName SQLAgent –name SQLAgent -path "OU=ServiceAccounts,OU=MIM,OU=Services,DC=mim,DC=local" -AccountPassword $sp -PasswordNeverExpires 1 -Enabled 1 -UserPrincipalName "SQLAgent@mim.local"
New-ADUser –SamAccountName BackupAdmin –name BackupAdmin -path "OU=ServiceAccounts,OU=MIM,OU=Services,DC=mim,DC=local" -AccountPassword $sp -PasswordNeverExpires 1 -Enabled 1 -UserPrincipalName "BackupAdmin@mim.local"

Create groups

Again, I have added a -path parameter to place the groups into the correct OU automatically.

New-ADGroup –name MIMSyncAdmins –GroupCategory Security –GroupScope Global –SamAccountName MIMSyncAdmins  -path "OU=Groups,OU=MIM,OU=Services,DC=mim,DC=local"
New-ADGroup –name MIMSyncOperators –GroupCategory Security –GroupScope Global –SamAccountName MIMSyncOperators -path "OU=Groups,OU=MIM,OU=Services,DC=mim,DC=local"
New-ADGroup –name MIMSyncJoiners –GroupCategory Security –GroupScope Global –SamAccountName MIMSyncJoiners -path "OU=Groups,OU=MIM,OU=Services,DC=mim,DC=local"
New-ADGroup –name MIMSyncBrowse –GroupCategory Security –GroupScope Global –SamAccountName MIMSyncBrowse -path "OU=Groups,OU=MIM,OU=Services,DC=mim,DC=local"
New-ADGroup –name MIMSyncPasswordReset –GroupCategory Security –GroupScope Global –SamAccountName MIMSyncPasswordReset -path "OU=Groups,OU=MIM,OU=Services,DC=mim,DC=local"
Add-ADGroupMember -identity MIMSyncAdmins -Members Administrator
Add-ADGroupmember -identity MIMSyncAdmins -Members MIMService

Create SPNs

To enable Kerberos authentication, SPNs are needed. This is a complex subject worthy of a separate post, maybe another time. You have to edit the script to reflect your environment, sample below. This script has to be executed at a domain controller as a domain admin.

setspn -S http/IM01.mim.local MIM\SharePoint
setspn -S http/IM01 MIM\SharePoint
setspn -S FIMService/IM01.mim.local MIM\MIMService
setspn -S FIMSynchronizationService/IM01.mim.local MIM\MIMSync

 

 

This is the end of the first chapter. In the next chapter, we will look at preparing the MIM01-server, and install SQL Server and Sharepoint.

Author: DizzyBadger

SQL Server DBA, Cluster expert, Principal Analyst

One thought on “MIM LAB 1: Prepare a domain controller”

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.