In the past I have talked about the different configuration options when running Domain Controllers and Hyper-V. One of the more interesting configurations I discussed then was having a Hyper-V server joined to a domain where the domain controller was a virtual machine running on the same instance of Hyper-V.
This is actually a configuration I use all of the time when I am doing public demonstrations. The reason why I do this is because:
- I do not like to ship hardware – as I have had hardware get damaged in shipping too many times.
- I do not trust networking in a demo environment – so if I can keep it all on one computer, I will.
- I often have to demonstrate software / configurations that need a domain controller.
This all means that I need to have a domain controller in a virtual machine on my laptop.
Over the course of many demos – I have gleaned a few interesting tips and tricks for this sort of configuration.
One of the biggest differences (for me) about doing this on my laptop, is that I need to system to be able to boot quickly and reliably. Often when speaking publicly – I only get to take the stage about 10 minutes prior to speaking. I need to be able to boot my whole system and be confident that my demo is going to work in under 10 minutes.
Sometimes I also need to run my PowerPoint presentation on the same laptop – so make that 8 minutes to “up and running”.
Tip #1 – Disable the use of cached credentials
Normally, if you have a computer joined to a domain and you try to login when no connection to the domain controller is present- you will be able to log in successfully. The reason why this works is because Windows allows you to use a locally cached copy of your domain credentials.
Unfortunately – this can be a problem in a demo environment. Imagine this scenario:
You have your demo all setup and ready to go, you pack up your laptop and head out to where you are going to be presenting. Once there you boot your laptop, login, and start the presentation. 20 minutes in – it is time for your demo. You switch from PowerPoint and start to do the demo – only to find that none of your server virtual machines are authenticating with each other! After a few minutes of nervous muttering – you realize that the domain controller never started. By this time – your demo is pretty much ruined and you have to abandon the whole thing.
Yup, I have had this happen to me. That is why I like to disable the use of cached credentials. This way I am immediately alerted of problems with my domain environment – and know that if I was able to login – then everything is fine. Of course, if you are going to do this you need to be extra careful to have a local administrator account ready to go if there is a problem to fix.
You can disabled the use of cached credentials by going to the client computer (your physical computer / management operating system in this case), opening REGEDIT.EXE and locating this registry key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon. Then you want to find the entry called cachedlogonscount and change it to 0.
Tip #2 – Avoid huge delays by fixing the DNS up when the Domain Controller Starts
I have wrestled with this one for a while, as I know many of you have. When you restart your domain controller it seems to take *for ever* before it will let you authenticate from a remote computer. I timed my standard demo environment (without the change that I am about to discuss) and it would often take longer than 10 minutes from system boot to being able to login to the domain. Clearly this is a big issue for me when I am up on stage and trying to get my demo up and running quickly. But I have also been frustrated by this is my home server setup as well. After a bit of digging – I discovered that the cause of this delay is because the domain controller is not registered correctly with the domain name services server (DNS). As I have a small setup I usually create a single virtual machine that contains the domain controller, DNS server and DHCP server.
In this configuration – the DNS server comes up after the domain controller – and does not have the registration information from the domain controller. When a domain controller fails to register itself with a DNS server, two things happen:
- No one is able to find the domain controller
- The domain controller waits about 10 minutes before trying to re-register itself with the DNS server
So the trick is to try and get re-registration to happen quicker.
The way I do this is by creating a batch file (which I call “FixDNS.CMD”) the contents of this batch file is as follows:
The “ipconfig” commands ensure that all is correct with the DNS settings and the “nltest” command does the work to register the domain controller with the DNS server.
I then use task scheduler to run this batch file “At system startup”. I have it configured to run without needing a user to log in, and have it run as a domain administrator account:
The result of these changes is that my laptop is able to boot and login to the domain controller in under 4 minutes. Handy!
Well, that is it for today. Hopefully these tips and tricks will help you out some day.