I recently implemented a new external DNS solution for a financial customer of mine. They had some issues lately and wanted to replace their old external DNS servers that were running on Windows Server 2000. Server 2008 Core was the perfect solution for this task because of its small attack surface and minimal overhead. The trick with Core of course is getting all of the configuration done without a GUI. I had a couple of challenges that we overcame and so I've outlined most of the steps here. Note that all these command along with more information is documented in various places on the web, I just wanted to put it all together for this particular implementation. Also, every command below can actually be run on non-Core installations of Windows (except for scregedit.wsf).
- Load Windows. First step was of course to load Windows Server 2008 Standard in core mode.
- Change Name. Changed the name of each system.
netdom renamecomputer %computername% /NewName:NS1
- Add Key. Added the customer's Multiple Activation Key (MAK).
C:\Windows\system32>cscript slmgr.vbs -ipk <product key>
- Activate Windows. Here was the first challenge. We were building the systems inside the customer's network; however, they use a firewall based authentication process to allow or disallow all Internet bound traffic. Authentication is usually handled by Internet Explorer (and other browsers) by prompting the user with a dialog box. This isn't directly possible with Windows Core. I could've load Firefox or some other Internet access software that would prompt for credentials, but given the use of these boxes, that's wasn't a good plan. Telnet isn't loaded and I didn't want to have to load it either. FTP was the ticket. We simply telneted to ftp.microsoft.com and the FTP client prompted us for the credentials.
C:\Windows\system32>cscript slmgr.vbs -ato
- Disable IPv6. Not strictly necessary, but given that these were going to be IPv4 DNS only (for the time being) and in the spirit of removing or disabling things not necessary to reduce the attack surface, this makes sense.
Using regedit (yes regedit exists in Core), added the following registry value (DWORD type) set to 0xFF: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters\DisabledComponents
- Disable NIC. As with most servers these days, the system had two on-board NICs, so we disabled the one not in use.
netsh interface set interface name="Local Area Connection 2" admin=DISABLED
- Enable RDP. For remote access and configuration.
c:\windows\system32\scregedit.wsf /CS 0
- Disable hibernation. When looking around at available drive space, I noticed some missing. Upon investigation, I found hiberfil.sys. Not sure why hibernation would be enabled by default in core, but given that these are always on systems, this file and functionality was not needed.
powercfg.exe /hibernate off
- Disable NetBIOS over TCP/IP. Definitely no reason to leave this on.
wmic nicconfig get caption,index,TcpipNetbiosOptions wmic nicconfig where index=1 call SetTcpipNetbios 2
- Create volume. I decided to put all DNS files on a separate volume from the OS files.
diskpart
show disk
select disk 1
create partition primary
show volume
select volume 2
format quick
assign letter=E
- Set timezone. Set the current timezone.
timedate.cpl
- NTP. Set the authoritative NTP time source.
w32tm /config /update manualpeerlist:x.x.x.x /syncfromflags:MANUAL
- Open firewall. Opened the Windows firewall for a few groups of rules to allow remote administration.
netsh advfirewall firewall set rule group=”Windows Firewall Remote Management” new enable=yes
netsh advfirewall firewall set rule group=”Windows Remote Desktop” new enable=yes
netsh advfirewall firewall set rule group=”Windows Administration” new enable=yes
netsh advfirewall firewall add rule name=”ICMP Allow incoming V4 echo request” protocol=icmpv4:8,any dir=in action=allow
- Install DNS
OCSetup DNS-Server-Core-Role
- Configure DNS. Configured the default directory for DNS to store zone files and the the default DNS log file.
dnscmd.exe /config /logfilepath E:\DNS\Logs\Dns.log
Used regedit to update HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DNS\Parameters\DatabaseDirectory to E:\DNS\Zones
- Windows Updates. Here's a another little challenge. Fortunately, Windows Updates can be initiated using WMI and a handy little script from Microsoft: WUA_SearchDownloadInstall.vbs (found at http://msdn.microsoft.com/en-us/library/aa387102(VS.85).aspx)
- Static IP Address. We then moved the servers into the DMZ for final preparation. This meant assigning the final DMZ static IP addresses.
netsh interface ipv4 set address "Local Area Connection" static x.x.x.x 255.255.255.0 x.x.x.x
netsh interface ipv4 set dnsserver "Local Area Connection" static 127.0.0.1
- Create Primary Zones. Because this was a clean swap from the current DNS servers to the new, we simply had to copy all of the zones files, about 25 of them, from the old primary to the new. Then, using a simple batch file with a for loop, executed the following command for each zone file. The same batch file was used to enable zone transfers on each zone. Because of NETing, the NS records listed in the zone do not match the actual IP addresses of the secondary servers, so zone transfers had to be locked to IP addresses instead of the NS records.
dnscmd.exe /zoneadd <zonename> /primary /file <zonename>.dns /load
dnscmd.exe /zoneresetsecondaries <zonename> /securelist x.x.x.x z.z.z.z
- Create Secondary Zone. For the secondary zones, a similar batch script was used with the following command.
dnscmd.exe /zoneadd <zonename> /secondary y.y.y.y
I just got done with a small Exchange Server 2003 to Exchange Server 2007 migration and ran into a couple of problems. What makes these problems notable is that when I searched on them for answers, a lot of people seemed to have encountered similar (or exactly the same) symptoms, but none of the solutions listed actually worked -- this included at least one KB article.
- The first problem became evident right after we moved the first mailbox from the old server to the new. None of the messages sent to the new mailbox actually made it. They all got stuck in the Unreachable Destination queue on the Exchange 2003 system. This included messages from an external source and from mailboxes hosted on the 03 server. Messages from the migrated mailbox were delivered fine however.
Most references and discussion on the web revolved around the site connectors that get created automatically when installing an Exchange 07 server into and 03 Organization. These had been created correctly, but we recreated them just for grins, no va.
It turned out that we hadn't suppressed the Link State updates on the 03 server. This was conscious choice made because only a single 03 server existed and according to certain web sources, it was not necessary. Turns, out, at least in this case, it was needed. Once we suppressed the updates, the queue emptied and all the mailed flowed successfully.
- When we went to uninstall Exchange 2003, we kept getting "0x80072030 (8240): There is no such object on the server". Microsoft KB 283089 explicitly talks about this error but was not the issue; all mailboxes had been moved and the private information store on the 03 server had actually been deleted.
Some research led me to look at the Recipient Update Service (RUS). Apparently the uninstall actually checks to the see if the Recipient Update Service container exists and when I deleted the RUS, I deleted the entire container at CN=Configuration,CN=<domain>,CN=Services,CN=Microsoft Exchange,CN=<Exchange organization name>,CN=Address Lists Container,CN=Recipient Update Services instead of just the Recipient Update Service (Enterprise Configuration) object in the container. I simply recreated the container in ADSI edit and the uninstall worked without an issues. Exchange 2007 doesn't use the/a RUS, so this is a required step to uninstall Exchange 2003. The Technet library article http://technet.microsoft.com/en-us/library/bb288905(EXCHG.80).aspx talks about the entire procedure with the correct steps.
Ultimately, the migration went pretty smooth and the customer was extremely happy with their brand, spanking new Exchange 2007 server!