So now we have the internet connectivity working.
I’ve installed win2016 server (with desktop) and assigned it a static ip address (10.208.1.16).
Trying to manage it through vmware remote console sucks, so the first step is to enable remote desktop.
So I open up the Server Manager -> Local Server, and click the “Disabled” link next to “Remote Desktop” and allow remote connections.
Now I can remote desktop in and continue.
Domain controller stuff
The last time I installed a domain controller, the procedure was to go to start -> run, type in dcpromo, and voila.
This time I took a look at a step-by-step guide from Microsoft.
Note that it guides you to put “127.0.0.1” as the primary DNS server.
And since we have the server manager already open.
Dashboard -> Add roles and features -> next -> next -> oh… the name of the server is still like someone slammed their head on the keyboard.
Ok back to local server and change the name of the computer, to “dc01”, which required a reboot.
So back to the Server Mananger
Dashboard -> Add roles and features -> next -> next -> next -> select “Active Directory Domain Services” -> press “Add Features” to the popup dialogue -> Next -> next -> next -> “Restart […] if required” checked -> Install
And let it run.
Now it says “succeded” and you can press the “close” button.
But if you read closely, there’s a text stating that additional steps are required, with a link that says “Promote this seriver to a domain controller”, which we click.
We’re going to “Add a new forest”, type in our domain name and “next”
And then…. I wait and wait because everything is grayed out, for like 2 minutes, before I can type in a DSRM password and press “next”
And next -> next -> next -> next -> there are some error messages which look kind of informational only -> install
Aaaand we’re off to a reboot.
And some mintues later, I can do a DNS query to the server:
The initial setup is done and we can start working “with” the domain.
While we’re at it, the FMC needs a NTP server, the ISE will too, as will other devices.
There’s a “built in” NTP service in Active Directory, or well, a time service.
System admins have generally argued that the AD NTP service is “good enough”. This is often not the case.
The “How the Windows Time Service Works” article states:
“[…] the Windows Time service is not an exact implementation of the Network Time Protocol (NTP), […] Prior to Windows Server 2016, the W32Time service was not designed to meet time-sensitive application needs. However, updates to Windows Server 2016 now allow you to implement a solution for 1ms accuracy in your domain.”
Basically what it says is: The main purpose of the time service in active directory is to authenticate kerberos tickets, so the clients can not skew more than 5 minutes, which does not qualify as “time sensitive”.
For this reason, the time service in active directory can be somewhat unreliable and appliances may have issues trying to sync with the NTP service in AD, especially if the server is running in a virtualized environment (vmware?).
Now the article also states that you can now configure win2016 for better accuracy, and if you are a microsoft/windows expert, you can go down that path.
If you’re not a microsoft expert, I recommend you use other NTP sources for FMC, ISE etc.
The main reason I knew about this article to begin with is that I’ve had to help out with too many issues with time sensitive applications where the core issue was it was trying to use the Active Directory time service as NTP, and the issue was easily fixed by using any other NTP service.