Activation Headaches: Here is your aspirin!

March 14, 2013 2 Comments

This post was originally written for the Canadian IT Pro Connection.

There are three concepts in Microsoft licensing that people often mistake for a single entity, when in fact the three are connected but very separate.  They are:

  • Licensing
  • Activation
  • Product Keys

Because the three are so tied together it is easy to get yourself in trouble if you do not take the time to understand how the three of them interrelate.  However with a little understanding you should be good to go.

Licensing

You have paid for an instance of an operating system or an application; you are licensed to use it.  Does that mean you are licensed to use it anywhere? Of course not.  Depending on the type of license you may be good, or you may be limited.  For example, there may be educational licensing that cannot be used outside of a school, or charity licensing that can only be used by a non-profit (and non-religious) organization.  Then there are OEM licenses which are tied to a piece of hardware, which means that it cannot be transferred to another physical machine (or, depending on the license, to a Virtual Machine).  These types of limitations are important to understand not only when planning your licensing, but also when migrating from older to newer hardware, and from physical to virtual, and even from vSphere to Hyper-V (virtual to virtual).

Activation

You install an operating system or an application.  Now you are allowed to use it… however before you do it has to ‘call home’ to make sure that your license is legitimate.  Unfortunately over the past few decades software piracy and misuse caused companies like Microsoft to come up with ways to try to prevent theft or misuse.  In the days before ubiquitous interconnected computing (the Internet) you might have had to call Microsoft with a code and type in their response code.  Fortunately today our computers are all connected, and all that software activation requires is your permission (some companies do not ask even that).  However what if your computer is not connected to the Internet at the moment?  Simple… most companies will let you install and use their software for a trial period (often 30 or 60 days) before having to activate it.

 

Product Keys

In order to make sure your operating system or application software is legitimate the company that sells it to you will provide you a product key, often represented on a Certificate of Authenticity (COA).  This key ensures that you purchased it legitimately, and is encoded with protections to make sure a) you enter a legitimate key, and b) that the key has not simply been stolen or used more often than permitted.

—

So we’re good to go… we understand the three different concepts.  How they interconnect is as such:

  • Not all Licensed software comes with a Product Key, but most of them do, and most of them require Activation to work.
  • Having a Product Key does not mean that you are licensed, but will usually allow you to Activate your software (or OS).
  • Having a Licensed Product Key does not necessarily mean you will be able to Activate your software, because if the Product Key has been compromised the software vendor may ‘kill’ the Product Key.
  • A ‘killed’ Product Key does not mean you lose your License; you will however have to contact your software vendor to get a new key in order to Activate.
  • An Activation is not proof of License.  You can reinstall the same machine ten times and only use a single license.  Also if you are able to Activate a Product Key more often than the number of Licenses you bought it does not make it legitimate.

Ok… so now that you understand all of this (there will be a test Winking smile) it is time to manage your Licenses and Product Keys and Activations.

…What? Are you serious?

Okay okay… we know it sounds like a much simpler task in an organization with ten machines than in one with 10,000 machines, but Microsoft has a solution that is going to make your life easier.  For the Enterprise (or at least for organizations with over 25 licenses) Microsoft provides a couple of free tools for managing your Volume License (VL) Activations.  The Key Management Server (KMS) is a great way to manage your activations for Windows (Server & Client), Office, and several other Microsoft products, including OEM, Volume License, and even ‘FPP.’

Charity Shelbourne, a Senior Premier Field Engineer with Microsoft, wrote a great piece on Active Directory-Based Activation vs. Key Management Services.  It discusses and links to articles on setting up and managing a KMS Server, as well as takes you through installing and configuring the Volume Activation Services role in Windows Server 2012, and managing all of the components of same.  You can check out that article on the Ask Premier Field Engineer (PFE) Blog here.  I was going to do a similar write-up, but when she has done such a great job I decided it was better to just point to hers.  Now go forth and get your Licensed Product Keys Activated!

Filed under Activation, Active Directory, KMS, licensing Tagged with , , , , ,

Following My Own Advice: New DCs at SWMI

October 10, 2012 Leave a comment

Earlier this year I published an article in which I told you that it was okay to virtualize your domain controllers; however in the piece I opposed the idea of doing a P2V (physical to virtual) migration of them, or to upgrade them from one version of the OS to another.

This weekend I followed my own advice.  It was time to integrate my new servers into my production infrastructure on Windows Server 2012.  Once I had the two hosts running the new OS with Hyper-V 3, I decided to create a couple of new domain controllers.  My policy is to have one domain controller on each virtualization host.  Although I exported and then imported a few of my VMs from the older hosts onto my newer ones (the old hosts will be re-provisioned for another project) I opted to create two new VMs running Windows Server 2012 to be my new DCs.

In a secure, well-managed IT infrastructure the domain controllers should not be doing much.  My DCs run Active Directory Domain Services (AD DS), Dynamic Host Configuration Protocol (DHCP), and Domain Naming Service (DNS).  That’s it, nothing else.  Because I keep them clean, it is easy for me to spin up a new server, join it to the domain, install these three roles (and the requisite role services and features), then promote it to be a domain controller. 

Because Active Directory is a distributed, self-replicating database, your new DC will get a clean copy of the full AD automatically.  After a few minutes (remember, this is still a small single-site environment) the domain and DNS have replicated onto the new server, and it is fully functional.

Don’t get me wrong.  There are plenty of servers that need to be upgraded from one OS to another, or migrated (P2V).  If you keep your DCs clean then they shouldn’t be in that category.  As long as you keep them clean and simple you will never need to perform a migration or upgrade of a domain controller. 

If you are doing a migration from Server 2008 to Server 2012 and are planning to decommission your older DCs, then the only think you will need to migrate are the Operations Master roles (formerly known as FSMO roles).  Additionally because my environment is simpler than many I will upgrade the Schema to Windows Server 2012… although this may or may not be important (or possible) for you.

Migration is not the only reason for keeping your domain controllers clean, but it is certainly an added benefit… one that will save you time and troubles down the road.

Filed under Active Directory, Domain Controllers, Windows Server 2012

Virtualizing your Domain Controllers

April 26, 2012 11 Comments

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!

Filed under Active Directory, Domain Controllers, FSMO Roles, Virtualization Tagged with , , , , , , ,

%d bloggers like this: