FIrst, you have to install the server and set an IP address – my previous posts on IP changes on DCs all used netsh commands as well, so if you followed thouse, you should be somewhat prepared for Server Core. I already had a WIndows Server 2003 DC in the environment, so that will be my primary DNS server for the install, untill DCPromo edits the settings.
netsh interface ipv4 set address local static 10.1.1.6 255.255.255.0 10.1.1.1 10
netsh interface ipv4 set dns local static 10.1.1.5
netsh interface ipv4 set wins local static 10.1.1.5

Now networking is set up, we can rename the computer: netdom renamecomputer %computername% /NewName:dc02 and join the domain with netdom join dc02 /domain:foo.local /UserD:FOO\Administrator /reboot:5 /PasswordD:*. The “5″ after the reboot flag says to reboot 5 seconds after completion, and the “*” at the end says to prompt you for your password. I join the system to the domain manually first, because then I can WSUS patch it (if WSUS is in the network), or open up the firewall for any other patching software I have.

Once the server is back from reboot, activate, update the firewall to allow remote MMC connections (if you’re not doing that through GPO already), and install new roles.
slmgr.vbs -ato
netsh advfirewall firewall set rule group="Remote Administration" new enable=yes

The following roles are optional, depending on the service of the server. Mine has DNS and the File Server roles, but not DHCP. None of these are required to install AD Domain Services!
start /w ocsetup DNS-Server-Core-Role
start /w ocsetup DHCPServerCore
start /w ocsetup FRS-Infrastructure
start /w ocsetup DFSN-Server
start /w ocsetup DFSR-Infrastructure-ServerEdition

If this is the first Windows Server 2008 DC in your environment, you’ll need to take the Windows Server 2008 DVD to the DC with the Infrastructure Master role (required for /gpprep only) and run the following (E: assumed as DVD-ROM drive):
e:\sources\adprep\adprep.exe /forestprep
e:\sources\adprep\adprep.exe /domainprep
e:\sources\adprep\adprep.exe /domainprep /gpprep (Also run adprep /rodcPrep if you plan on building RODCs.)

Now you’re ready to do the DCPromo itself. Create an unattend.txt file. To add a DC to an existing domain, you can use:
[DCInstall]
AutoConfigDNS=Yes
ConfirmGc=Yes
DatabasePath=E:\Windows\NTDS
LogPath=c:\windows\NTDS
RebootOnSuccess=Yes
ReplicaDomainDNSName=foo.local
ReplicaOrNewDomain=Replica
ReplicationSourceDC=dc01.foo.local
SafeModeAdminPassword=passwordhere
SysVolPath=e:\windows\SysVol
UserDomain=foo.local
/Password:passwordhere

DCPromo will wipe out the passwords when it starts, or you can fill in “*” instead of the password, to be prompted. When it’s done, the server will reboot and be a new Global Catalog / DC in your domain. DCPromo will install neccessary binaries and configure the firewall for DC Services for you. It’s quite slick.

And as promised, here are the DCPromo Unattend Options for reference for creating your own unattend.txt.

Of note is a response for T. Colin Dodd regaring his short and sweet post regarding Red Hat Flaws according to Secunia. In short, Mr. Dodd (please correct me if the address is wrong), yes, Red Hat should be proud of what they’ve accomplished, but…

Well, that’s 2 pages of text that’s not yet finished.

System Error 317 has occurred. The system cannot find message text for message number 0x*** in the message file for ***.

Further information about adding the “Allowed to Authenticate” right to the trusted users is available at Microsoft TechNet. If you have the opportunity to raise your forest and domain functional levels to take advantage of this, I highly recommend it. But I recommend also (even more strongly) documenting precisely what you set.

1. Same as before: why are you changing IPs? In larger environments, I do this because of a physical move of just one site. If the networking team doesn’t have the new subnet up and routing, don’t start!
2. Make sure the new site (if required) is set up in AD. If I’m moving DCs from one physical location to another, I will build a new site, rather than re-using the old one, because the new site often has better connectivity, so the site link costs are changing.
3. Add the new IP to the DC you’re moving (DC01 for this). Same as before: don’t remove the old one, just add the new.
4. On DC01, do the following to verify registration worked:
   ipconfig /registerdns
   Wait a few minutes.
   nslookup
server DC01
set type=A
DC01.foobar.local
foobar.local
server DC02
DC01.foobar.local
foobar.local
   The answers from DC01 and DC02 should be the same, with possibly different orders. The important thing is that the new IP address and the old IP address show up for both queries on both servers.
5. Shut down DC01, pack it up and move it. (Or just plug it into the new network.)
6. Boot up, verify that DC01 has network connectivity, and that other systems can see that it has the new IP.
7. If you haven’t, make the new IP primary (change order in Network settings), make sure the DNS and WINS servers are correct and reachable (Remember that Windows 2003 DNS should point to itself).
8. Once verifying that AD is replicating across sites properly (up to 15 minutes in my experience), remove the old IP, ipconfig /registerdns, and reboot.
9. When it comes back up re-verify that AD is still replicating, and you should be set.

I would point out that when doing a change this big to your environment, reviewing your AD replication, DNS forwarding, and WINS topology is a good idea.

First off, I’d like to mention that the software installs first on a Windows “console” system. That install has the option of extending the schema, but it is not required (the extensions allows administrators to use the Centrify Profile tab for users and computers without installing the Centrify Console locally).  All required pieces work with the standard out-of-the-box Windows 2003 AD schema.  Although the view extensions are well worth it, if you can get them approved by your AD administrative team.

I installed this on a Debian Etch system and a Red Hat Enterprise Linux 4 box.  They ship RPM and DEB installers, so installation is a snap, and shows up in your package manager.  Restarting the systems was not required, but a few systems may not pick up the new PAM settings without at least a reload (OpenSSH did fine).

One of the best parts of this software, however, is in their updated version of OpenSSH to support Windows Kerberos tickets for authentication of users.  Single-signon to any Linux box from Linux or Windows (customized Putty for the same reason) without having to copy RSA keys across your network every time you build a box.  Now my Oracle admins can log into the 10g databases seamlessly (yes, they support Oracle authenticating through AD as well).

Of course, no solution that integrates into AD would be complete without support for Group Policy.  As a huge user of Group Policy (I have 8 GPOs on my home domain), this is key for me.  The thing that makes it so spectacular, is that they just install new ADM files to your console system.  That’s it – no new trees needed, just new ADM files with settings specific to Linux like “SuDoers entries” and “SSH settings”.  Just like GPO on Windows, they’re applied every 90+-30 minutes, and when you remove the system from the policy, the settings get pulled.  For the Sudoers settings, they are appended to the end of the existing file.  Also, many of your security settings for Windows boxes are read directly by the Centrify systems as well, including password expiration notices, lockout policy handling, etc.

There are so many other little features that show how well thought-out the system is.  The client can be configured to cache logons similar to Windows, so you can control your Linux laptops, and still enable the users to log in when they’re on the road. There are several scripts and other tools to help “suck” the users out of /etc/passwd and NIS into AD, to help keep your UIDs in check if you’re installing the client into existing servers.

And that’s just the operating system.  JBoss, WebSphere, Apache and other applications and middleware can be AD-enabled, and anything that uses PAM is automatically AD-enabled, giving you the ability to set up true single sign-on everywhere in your network, if you so choose.

Needless to say, we purchased it, and I’ll be integrating this into all my deployments from this point forward.

Thanks to cyrilliano at Neowin Forums I was reminded of all the fun that is netdom.

I just had to run netdom resetpwd /server:dc2 /userd:FOOBAR\administrator /passwordd:admin_password and wait 15 minutes. His post suggests disabling the KDC service, but I found it unneccessary. However, the 10 minute wait was not quite enough in my situation. Yet another reminder that patience is the first requirement for DC troubleshooting.

1. Why are you changing the subnet? Most often, I’ve had to do this for customers because a business partner’s subnet has conflicts that are coming up during VPN tunnel creation. I’ve had other reasons, and you might too – but that’s the most common I’ve seen – 2 sites that are both 192.168.1.0/24 trying to build a VPN tunnel to each other.
2. Now that you have a good reason to go through the pain, determine your layout – I’m going to write this for a single DC environment and point out a few changes for a double-DC environment. If you have more, you should be able to extrapolate the requirements from there, but you can also leave some comments and I can write another post if required. I’ll also be writing cmd scripts for most changes, rather than attaching huge (pixel-size) images.
3. Determine the new subnet.
4. Add the reverse lookup zone to DNS for your new network. In this case, in the DNS wizard, you’d make the reverse zone “172.31.2″ (filling in all boxes). This makes the zone name “2.31.172.in-addr.arpa” or “172.31.2.x” in the DNS console.
5. Open Active Directory Sites and Services. Right-Click “Subnets” and add in the new subnet (172.31.2.0 with a Subnet Mask of 255.255.255.0). You’ll see the subnet listed as CIDR notation in the box (172.31.2.0/24) for verification. Pick the site that the new subnet belongs in (probably Default-First-Site-Name), and click “OK”. This guarnantees that AD will recognize the new site properly.
6. Determine the new IP for the DC, and *add* it to the DC’s adapter. Do NOT remove the existing IP, yet. Don’t add the new gateway, yet. Just add the new IP, and save the settings.
   netsh interface ip add address "local area connection" 172.31.2.2 255.255.255.0
   (This command assumes that your DC has a static IP address. I haven’t seen a site use DHCP for their DCs yet, but it’s a possibility. This command on a DHCP address will set only a SINGLE address with no gateway, and could leave you with 0 remote access to the server.)
7. Verify that the new IP is showing up on the server.
   ipconfig
8. Get the server to register its new info in DNS
   ipconfig /registerdns
9. Wait and watch the Application and System event logs for DNS related errors. Also check that the DNS server is publishing the new IP address, not just as the server name, but also as the domain name, and the DCs (This can take up to, but shouldn’t take longer than, 15 minutes):
   nslookup foobar.local
   Also, open the DNS console and look inside “_msdcs.foobar.local” to see that the GUID of the server is listed with both IPs.
10. Once the server is advertising the new IP, you can swap the system to use the new IP range completely. It’s not time to remove the old IP yet though. This is the time to change the gateway, DNS servers, and WINS server. Since the server is listening on, and advertising on, the old and new IPs, DNS shouldn’t have any issues.
    netsh interface ip set address "local area connection" static 172.31.2.2 255.255.255.0 172.31.2.1 10
netsh interface ip add address "local area connection" 192.168.1.2 255.255.255.0
netsh interface ip set dns "local area connection" static 172.31.2.2
netsh interface ip set wins "local area connection" static 172.31.2.2
    This can, like all other steps, also be done in the GUI quite easily, by just shifting the orders of some things (IPs), and replacing others (DNS/WINS/Gateway).
11. Now re-register the server with itself, looking for error messages in the Application and System logs.
    ipconfig /registerdns
12. Remember that changes to DNS can take up to 15 minutes to appear, as you watch the logs for errors, and check dns.
    nslookup foobar.local
    What you’re looking for in the nslookup is to see the address of every domain controller in your domain. If this is a single server (like a Small Business Server 2003 network), you should, at this point, see 2 or 3 addresses (depending on how you set up your public network, for SBS2003).
13. If everything looks good here, this is a good time to test some logons to make sure things are working properly. This is the point in the project where I normally create the new DHCP scope, deactivate (not delete) the old scope, and change the LAN settings on the router. This is also a good time to reboot some of the client PCs to make sure that they can boot up properly, get IP addresses in the new subnet, login without errors (remember to check that Application log!), and get online without issues.
    Because we haven’t removed the old IP from the server yet, the biggest issue you *should* run into is a client who gets an IP from the old subnet, or is statically set. They’ll log in ok, but won’t be able to get to the internet (unless you’ve got SBS2003, and the server is also your router). At this point in time, it’ll be easy to figure out if the new IP is working – clients that can log in and get access to resources are logging in to the IP address for the DC that’s local to them – if they’re in the new subnet, then your new IP is working. You can now reboot your DC as a final test (or act of faith, as your experience may prompt).
14. When the DC comes back up, log in, and remove the old IP address – this is easiest in the GUI, but if you’re doing it with netsh, I prefer to just reset the DC settings completely.
    netsh interface ip set address "local area connection" static 172.31.2.2 255.255.255.0 172.31.2.2 10
ipconfig /registerdns
nslookup foobar.local
    Now it’s cleanup time.
15. Open Active Directory Sites and Services. Delete the old subnet.
16. Open up your DNS server and make sure your forwarders are correct – lots of small offices skip this step – your forwarders should be the IP addresses of the DNS servers that your ISP gave you. Don’t put these into your DHCP scope DNS servers list, or even in the list of DNS servers on your server – they go in the “forwarders” section here.
17. That’s it. Your clients are set up and ready to go, your server is healthy, and now you get to tackle the problem that made you have to change the IP in the first place!

For those who are having issues, because they’re finding this after attempting the change, or for my friend who prompted me to write this, here are some suggestions:

1. Add the old IP back to the server, run <code>ipconfig /registerdns</code> and wait for the old IP to take. Now verify that the server’s logging in properly, and not giving error messages.
2. Do you have all the zones in DNS, so that registration can take? Many small sites forget to put in the reverse zones into the DNS server.
3. Go back and check Active Directory Sites and Services to verify that both the old and new subnets are listed. While you’re in transition, all subnets should be listed in all locations.
4. If your server is screwed up badly enough that you can’t even log in, boot into Active Directory Services Restore Mode, make sure that your networking changes are set properly, and that your DNS server has it’s forwarders set up right. This is a good way to check the base level of your server’s health, then bring it back online to try to log into AD.
5. There’s no reason to need to rebuild the server, but if it’s a small enough location (AD doesn’t change very often, or if it does, the changes are minor), and you have good backups, take a look at how long this is taking you, and how much longer you’ll spend attempting to fix the problem. Going back to the backup from the previous night and restoring ONLY the system state in Directory Services Restore Mode might be the fastest and best solution. Then you can follow the steps in here in order, and grow fewer ulcers.

Next week sometime I’ll do a similar version for multi-DC, multi-Site AD networks – it’s a lot shorter and easier.