Automated Server Setup in Windows Server 2012 and Windows 8, Part 2

Let’s continue our discussion from last month (“Automated Server Setup in Windows Server 2012 and Windows 8, Part 1”) about tools that simplify server automation. Recall that, for this discussion, I’m building a second physical domain controller (DC) for my domain. This month, I want to focus on three useful commands that maximize server power, enable Remote Desktop, and help you avoid a stale Sysvol.

Set Power Profile to “High Performance” with Powercfg

By default, any server hardware running Windows Server will have the default Balanced power profile, which seeks to save power. That sounds like a nice thing, but sometimes isn’t. I found that my Server 2012 R2 web server sometimes needed a little jumpstart when I accessed it, and a bit of investigation showed that power management was the culprit. Well, to heck with that! I wanted 100 percent from my new DC (to be clear, in general I don’t need 100 percent from this or most DCs), so I tossed the Balanced profile and replaced it with High Performance. I haven’t discovered a PowerShell cmdlet that lets me switch power profiles, but our old friend Powercfg can do the trick:

powercfg /setactive 8c5e7fda-e8bf-4a96-9a85-a6e23a8c635c

That long hex GUID string identifies the High Performance profile, but if you don’t believe me (or you’re running some future version of the OS that re-GUIDs the profiles), you can always use Powercfg /list to list the profiles and GUIDs.

Enable Remote Desktop with Reg and Netsh

I enable Remote Desktop as a matter of course on my servers. But how to automate enabling it? Basically, you need only flip a registry bit! In the HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlTerminal Server subkey, find a REG_DWORD entry named fDenyTSConnections. If it doesn’t exist, create it and set it to 0. Upon the next reboot, your system will allow incoming RDP connections—unless, of course, your firewall is blocking port 3389. If that’s the case, turn to yet another pre-PowerShell command-line tool, Netsh:

netsh advfirewall firewall set rule group="remote desktop" new enable=Yes

(Actually, you could do this with PowerShell, but I’ll cover PowerShell firewall control next month. I think you’ll be surprised at how useful and well-designed—if somewhat initially complex—it is.)

I could also use PowerShell to set fDenyTSConnections, but honestly registry manipulation is one of PowerShell’s weak points. If, however, you’d like to remain PowerShell-pure in your setup, you can find powerful community-written registry-oriented cmdlets, as well as a couplet of WMI commands that offer an alternative way to turn on remote desktop.)

Instead, I find the old Reg (reg.exe) command a useful standby in this role:

reg add "HKLMSYSTEMCurrentControlSetControlTerminal Server" /v fDenyTSConnections /t REG_DWORD /d 0 /f

I never said it would be pretty! But it is prettier than the PowerShell cmdlets would be.

Convince AD to Allow “Stale Sysvol” to Replicate

At this point, there’s more configuring to do, but I could add the Active Directory (AD) role and promote the system to DC at any time. I can accomplish this with two PowerShell commands:

install-windowsfeature AD-Domain-Services -includem –includea

That command installs AD with all of its role services (-includea) and also installs the PowerShell and GUI AD tools (includem). Next, I can run the wizard to promote the server to a DC, or fill in the blanks and try this cmdlet to do the promotion (this should be typed as all one line):

install-ADDSDomainController -NoGlobalCatalog:$false -CreateDnsDelegation:$false -Credential (Get-Credential) -CriticalReplicationOnly:$false -DomainName "" -InstallDns:$true -LogPath "C:NTDS" -NoRebootOnCompletion:$false -ReplicationSourceDC "" -SiteName "" -Force:$true -AllowDomainControllerReinstall -SafeModeAdministratorPassword (convertto-securestring "" -asplaintext -force)

Now, at this point, I figured my new DC would be totally up to date and ready for me to get rid of the existing ancient DC—just transfer the Flexible Single Master Operations (FSMO) roles and remove the AD role from the old system, right? Wrong.

You see, the new DC could log systems on, but it couldn’t deliver Group Policies. Puzzled, I started to troubleshoot the problem and soon discovered that the Sysvol share was completely empty. Furthermore, there weren’t any useful items in the event log. But, then, isn’t that always the case with Sysvol issues?

Eventually, I found that Server 2008 R2 and later DCs have a rule that essentially says, “If you haven’t replicated your Sysvol to another DC for 60 days, your Sysvol must be ‘stale.’” A stale Sysvol probably has bad data in it, and so replicating it to another DC would be a bad idea. Ergo, my old DC was refusing to replicate its Sysvol to the new DC. (If you’re wondering why I had only one DC, it’s a low-priority domain that I don’t use much, and the DC does an image backup every night.) The answer lies in a WMI Command Line (WMIC) command to reset the 60 to something larger, as in

wmic.exe /namespace:\rootmicrosoftdfs path DfsrMachineConfig set MaxOfflineTimeInDays=6000

In this example, the 6000 value would make my new sole DC’s Sysvol not go stale for about 16 years, by which time it would no doubt be the last on-premises DC left in the free world.

Powercfg, Reg, and WMIC are great tools to know, but we’re not done yet. See you next month, when we’ll tackle firewalls!