Home » Posts tagged 'IP address'

Tag Archives: IP address

Server Core Address Woes

From the files of “What the F@rk?!”

Here’s a little gotcha that I’ve been wrestling with all afternoon.  I hope this post can save some of you the frustration (exacerbated by jetlag) that I have been experiencing.

I am configuring a bunch of virtual machines as domain controllers for the company I am consulting for in Japan.  Things are going really smooth on the project, but we wanted to spin up half a dozen DCs for the new environment, so I figured I’d just spend a few minutes on it.  Then I had to configure the IP Addresses… something I have done thousands of times, both in Server Core and the GUI.  I have never encountered THIS before.

Server 1: Done.

Server 2: Done

Server 3: NO

Server 4: Done

…and so on.  I went back to Server 3 figuring there was a bit of a glitch, and sure enough, it had an APIPA (Automatically Provided IP Address) assigned.

I loaded up the sconfig menu, and set the IP Address by hand.  The weirdest thing happened… it replaced my IPv6 address with the Class A address I assigned, and left the APIPA address.

I went down to the command line… netsh interface ipv4 set address name=”Ethernet” static 10.x.y.z…  and it still gave me an APIPA address.

I was getting frustrated… something was simply not going right.  And then it occurred to me… someone else was playing on my network.  Sure enough, he had already assigned that address.  Instead of giving me a warning, it simply wouldn’t duplicate an address that already existed.

Now if I had already implemented my monitoring solution, this would never have happened!

Creating a New AD Forest in Windows Server Core (Revisited)

Several years ago Steve Syfuhs and I sat down and figured out how to create a new Active Directory forest in Windows Server Core.  It was an interesting experience, and even though I later gave rights to that article to the Canadian IT Pro Team (at the time it was Damir Bersinic) when you search Bing.com for the term ‘Create AD Forest Server Coremy article still comes up first.

R2 I have gotten a bit more adept with the command prompt of late (especially with my diving into Windows PowerShell recently, but even before), so when I had the need to create a new AD Forest for a courseware environment I am building, I decided to revisit this topic, and see what changes I could make.

In 2009 I had to create an answer file, or at least I believed I did.  It turns out that now I can get away with one command line string, which is as follows:

dcpromo /InstallDNS:yes /NewDomain:forest /NewDomainDNSName:alpineskihouse.com

/DomainNetBIOSName:SKI /ReplicaOrNewDomain:domain /RebootOnCompletion:yes

/SafeModeAdminPassword:P@ssword

For the record I had to break up the text into three lines, but obviously this should all be typed onto a single line.

Warnings:

The first time I ran this command it failed.  I suspect this is because I had a DHCP address assigned.  Before embarking on this trip, I suggest you assign a static IP address to your Server Core box.  While it is simpler to do it with the sconfig text-mode configuration menu tool, you can also use the following netsh command:

netsh interface ipv4 set address name=”Local Area Connection” source=static address=172.16.0.10 mask=255.255.0.0 gateway=172.16.0.1

At this point you should be ready to go… remember that with Windows Server 2012 (and R2) once you have the OS installed it is easy to manage it remotely using either PowerShell or the Server Manager console.  Just make sure you have the right credentials, and you are good to go!

SMB 150: A Real Race!

Wow… I had no idea that I had so much influence on so many of you.  I want to thank you all from the bottom of my heart.  It is because of all of you that I am in a real fight for top spot in voting for the SMB 150 Awards for 2013.

As the voting stands right now, Carlos Fernando Paleo da Rocha (an SBS MVP from Brazil) and I are vying for the top spot.  While I have not seen him in a few years, I know Carlos and think he is a great guy.  If I were to come in behind him I would see absolutely no shame in that.

Now with that being said, it would still be incredible to be right at the top of that list… Even that likely does not guarantee me anything, because the judges take the list once the voting is closed and according to the rules their votes account for 60% of the final award.

I am going to ask all of you one more time to vote; you can vote once per day from any given IP address… that means that if you have 5 IP addresses (phones, tablets, etc…) you can vote for me five times per day! Smile  I appreciate your help and thank you in advance.

Please ask all of your friends and contacts to do the same… let’s show the SMB world that someone who speaks Enterprise can still be a top influencer for SMBs!

Virtualizing your Domain Controllers

I am asked all the time what the best practices are for domain controllers in a virtualized environment.  There are several that I will call out, but let’s begin with the simplest rule.

You should never have ONE domain controller.

This rule is not only true in virtualized environments, it is always true.  If you are too small to have a domain that is fine, but if you have a domain you should have two DCs.  If you run Windows Small Business Server that rule is just as true – join a second server to the domain and promote it.  YES IT DOES WORK, please don’t argue it again! Smile

You can absolutely virtualize your domain controllers.

I hear this question from people all of the time… and the reality is that there is nothing wrong with virtualizing your DCs.  If the main concern is the Time Synchronization issue, then there is a simple answer for that.  Your Active Directory domain resources will not be able to authenticate if the time is off by more than 300 seconds (5 minutes).  However that skew is from the domain, and not your wrist watch.  If your radio says it is 3:15pm and your domain says that it is 10:38am, the only thing that matters is that your network resources think that it is between 10:34 and 10:42. 

In simple terms, if one time resource is off it is bad… if ALL of your time resources are off, it’s not.  This theory may fall down with external resources – I have noticed that Twitter (or at least many Twitter clients) are sticklers for time, and if you are off then you will not be able to authenticate.  Lync can also be an issue, and I am sure there are dozens of other externally provided services that will cause issues.  However internally as long as your client and your server have the same wrong time, you’ll be fine.

So with that being said, my tendency is to select one domain controller and configure it to synchronize with an external time server.  I will then create a GPO in my domains to use that server as the authoritative time source for the entire network.  That prevents all manner of things from going wrong if you find the time is off.

Your Domain Controllers should be just that… and not much else!

Your DC should not be a file server, database server, media server, deployment server, update server… there are only three services that my domain controllers generally perform: Active Directory Domain Services, Domain Naming Service (DNS) server, and Distributed Host Configuration Protocol (DHCP) servers.  In my networks these three services go together nearly all of the time.  I don’t know of any good reason to put anything else on a domain controller, and every time someone says ‘Well what about…THIS?’ I disagree.

Of course, sometimes you don’t have a choice… Windows Small Business Server is a good example of that, but as you have likely heard me say before, SBS out of the box forces you to break a lot of rules that are simply not meant to be broken.  If you ever hear me discuss it I have said there are ways to make it more palatable… but that does not change the facts.  This is one reason I always tell my classes that it is easier for an enterprise administrator to adapt to small business IT than it is the reverse… the good habits of the enterprise admin will never hurt the SBS (although they may be considered overkill); some of the habits of small business IT Pros can, conversely, do serious damage to the enterprise IT environment.

Don’t P2V your domain controllers.

This rule is not as clear-cut as the others, but calls on some of them.  I do not believe in performing physical to virtual (P2V) migrations of domain controllers.  If an organization does have a physical domain controller that they would like to retire, I feel the following is a much safer and cleaner practice:

  1. Before you begin (as much as 10-14 days in advance) I will reconfigure the DHCP scope on the server in question to shorten the address length from whatever is currently in place (by default 8 days) to 1 hour.  This will prevent or at least minimize problems later on.
  2. When you are ready, create a new virtual machine and install the operating system.  Make sure you patch it to the most recent service pack, and apply all applicable critical and security patches.
  3. Join the new server to the domain, and promote it to domain controller.  Assuming you are on Windows Server 2008 R2 Service Pack 1 (which you should be by now!) you need to install the Active Directory Domain Services role, but the dcpromo.exe command will do that for you.
  4. After the server reboots, it will begin to synchronize with the Active Directory.  Remember, since AD is a distributed database, when you add a new server to the mix it will simply (over a period of time directly related to the size of your organization, factoring for network bandwidth issues) receive a complete copy of the AD that will be identical (upon completion) to the original server.  DNS will do the same thing, as long as you a) install the DNS role when you promote the server, and b) your DNS Zones are configured as Active Directory Integrated.
  5. Install and configure the DHCP Server role in the new domain controller.  If you have room to grow with your IP addresses I would recommend creating a completely different scope, but if you are tight then creating an overlapping scope will only cause very temporary headaches, most of which will be mitigated by doing this switchover during off-peak hours.  Remember to copy any reservations from the original server, especially when you have devices (such as printers) that require specific addresses.  Also, do not forget to verify that all of your Scope Options are properly configured.
  6. Stop the DHCP Server service on the original server (net stop “DHCP Server”).  Again, If your scopes are overlapping be sure to do this during off-peak hours.
  7. If the physical box held any of the Flexible Single Master Operations (FSMO) roles then you should transfer them to the new server, or to another domain controller in the organization.  If you forget to do this they can later be seized, but this is the easiest and least intrusive way of doing it.
  8. You can leave your source DC on for a week or two, but after a day or so I would usually power it down; don’t reformat it or throw it out just yet, but at this point you are ready to go!

One of the rules of P2V Migrations is GIGO: Garbage In, Garbage Out.  In other words, any legacy issues you may have had previously – whether it’s clutter, breaks, bugs, or whatnot – goes with you.  With the distributed database replication model of Active Directory you get to start fresh, with all of your data. 

This method is also a great way of upgrading a DC from Windows Server 2003 to Server 2008 R2 – rather than do an in-place upgrade, you can simply do the side-by-side virtualization dance.  It won’t change your schema or upgrade your Domain (or Forest) Function Level, although if it is the first 2008 R2 domain controller in your domain you will have to run a couple of scripts to prepare the domain by running the following commands:

(On the server that holds the Schema Master FSMO role): adprep /forestprep

(On the server that holds the Infrastructure Operations Master FSMO role): adprep /domainprep /gpprep

That’s about it… as I mentioned, there may be exceptions if your DC is doing something that (according to my guidelines) it is not supposed to be doing, but then again this may be a great opportunity for you to step in line with best practices and separate other roles from the domain controller.

No go forth and virtualize your Active Directory Domain Controllers!

%d bloggers like this: