binaryfactory.ca

As many companies have skipped Vista and may be starting to migrate to Windows 7, the need for servers running KMS (Key Management Services) is going to be felt for many of them.

 

KMS allows you to do the authorization/activation of Windows in-house, and allows you to get stats about what is going on. However, running this on a full blown Windows installation could be too expensive, overkill.

 

This article explains the steps to get KMS working in your domain, using a Windows 2008 R2 server in Server Core mode, virtualized. Yes, it is possible to run a KMS in a VM, unlike a few years ago when the EULA explicitly stated you were not allowed to.

Another good reason to go with Windows 2008 R2 is that it supports being a KMS for Windows 7 as well as 2008 servers. If you had a Windows 7 KMS, not only could you not run it in core mode but it would only be able to authorize workstations. And Windows 2008 first release is simply not supported.

 

Create a Virtual Machine

This VM can be in a Hyper-V environment or a VMware environment.

As we will be running Core, the requirements are lower. I suggest starting with:

• 1 vCPU
• 512MB of RAM
• 10GB of Hard drive (single drive)
• Low resource shares relative to your other VMs

Install Windows Server

Select your Windows 2008 R2 ISO from your data stores. Obviously, this article is not about that, I assume people interested in KMS know how to install Windows.

Select the core mode.

 

Windows is up – now what?

Log into the server’s console through VMware or hyper-v (well this guide mostly works for physical servers too – I just find it’s a waste of metal !). You will be greeted by the minimal UI of Core.

Configure the networking

Run the sconfig command. Chose option 8.

Select your NIC (normally number 0 if you only have one).

Configure it with a static IP , and make sure you configure the DNS settings properly for your domain.

KMS relies on DNS a lot so having a static IP will save you trouble in the future. Alternately depending on your setup, how you manage VLANs and IPs etc, have a reservation for it. ipconfig /all will show you the MAC address of the card, as on the standard Windows install.

Once you’re done configuring the network, go back to the main menu of sconfig.

Configure your Windows Update Settings

Set it to obtain updates from Microsoft for now. Later on you will surely manage this by GPO so it does not really matter. Back to the main menu, chose option 6 to download the updates that are required right now. (As core has no Internet explorer or Windows update UI that’s the way of getting them manually).

Configure date and time (option 9)

Configure the hostname (option 2)

I recommend rebooting after you changed it and before you join the domain – if the computer account is pre-staged in AD it will use the old name instead of the pre-staged one if you don’t.

Join the domain (option 1)

You can also use the typical netdom commands if you want to join it and force a specific OU.

Reboot

Add a local administrator

Once the server reboots, on the domain, log in with your local admin account. Run sconfig, and use option 3 (or use net localgroup – faster!) and add a domain account to your local admins, so you can login with an AD account and manage the server. While you are there, you may want to change the local admin password (the ctrl-alt-del screen does have that option).

Remote management

Once the server is fully patched up, and your local admin account is secured and you can now login using a domain account, consider enabling remote management. Option 4 in sconfig allows you to enable remote powershell, remote MMC, WinRM, etc. An interesting thing you can do once this is open is open the event log remotely easily, which may be useful. Be aware that KMS is very low maintenance and that keeping everything locked down may prove more secure, but be sure your operational teams will have a way to get into the server, either through the virtualized console, powershell, or RDP (enabled in the sconfig main menu – with two options, one to allow only secure RDP clients like Vista and Win 7 or one to allow any clients, useful if you still use XP workstation).

Enable KMS

Enabling KMS is very simple. The only thing you will need is your “KMS Key”, which can be found on the Microsoft licensing website.

Run this command:

slmgr.vbs /ipk KmsKey

You should then see a small window pop up and confirm the product has been activated.

Now, we should activate our server, while we’re at it.

slmgr.vbs /ato

There we go. KMS is enabled, the server is activated. What else needs to be done?

 

Well first of all, clients rely on DNS to locate the KMS. So if you do not have dynamic updates enabled, start by disabling the automated registration by running:

slmgr.vbs /cdns

The command to enable automatic updates (default but try it if you run into issues or change your mind) is :

slmgr.vbs /sdns

After running these, make sure to restart sppsvc by using net stop and net start or by using the services MMC, if you enabled remote MMC.

If using manual DNS, create an entry with the following settings:

Service	_VLMCS
Protocol	_TCP
Port number	1688
Host offering the service	Fully qualified domain name (FQDN) of the KMS host

 

Verify the DNS entry

Manual or automated, let’s check if it worked.

nslookup -type=srv _vlmcs._tcp.<your DNS domain>

If this command returns the SRV record pointing to your KMS server on port 1688, it means clients will now find the KMS.

Open the firewall

As you noticed while creating or verifying the SRV record, the KMS, by default, is listening on port 1688. This can be changed with the slmgr.vbs command. However, no matter what port you do, you will need to open it up in the firewall. You can use netsh…

netsh firewall set portopening tcp 1688 KMS enable

However, the beauty of Server core is that you should never have to connect to it. For this, I highly recommend that you apply your standard Windows 2008 security baseline GPOs, and create a KMS Specific one. In this GPO, you should ensure that the KMS service is set to automated, and that this TCP port is opened.

You can then apply further hardening to the machine, and configure Windows updates by GPO as well. As server core is not a service that is very visible to the users, this server could easily be patched and rebooted at almost any time, but you can patch it like any server that you use. Less patches will be required, as Server core does not include a lot of software that comes with the full install.

Troubleshooting

Read the slmgr.vbs documentation for more information. slmgr.vbs /dli will show you some information, and there will be an Event Log created just for KMS where you can get useful information about activations. If you have any issues, remember to check the DNS record from the workstation you’re trying to activate, as well as test connectivity to port 1688.

The error you receive on a workstation may seem cryptic but most of them have a good explanation, so Google them ! Remember you need at least 25 workstation licenses or 5 server licenses to use KMS, and have fun !

Depending on how you use Active Directory in your organization, you may be setting a lot of security policies on workstations, and some of these settings can be problematic during the automated build of computers.

A few workarounds exist to avoid applying those to the workstations being imaged:

* Create a temporary OU for the computer account, and move it to the proper location once the build is done
* Change the order of the steps in your build to avoid issues caused by security settings
* Configure a GPO to override the settings that need to be set only during deployment, and filter that only to machines being used.

For multiple different reasons, I had to use the last option. It is a rather clean option, as it doesn’t involve moving computer accounts after the build or any chances on the domain during the imaging process, other than joining the machine, which is great.

One word of notice: Make sure whatever you are overriding is not a must for security and is simply an “annoyance”, because eventually (within a few minutes probably), a user WILL figure out how you’re doing the filtering and WILL apply it to his own machine, in order to bypass some security settings.

Only a few steps are involved :

1) Create a GPO that will set the values to what they need to be during the build (don’t link it yet)

2) Create a WMI filter called “BoxBeingBuilt” or something similar. Have it do a query on something you know is true only during imaging. If you can’t find anything reliable, do something like this:

Select * from Win32_Environment Where Name = “BuildinDaBox”

3) Ensure your built process sets a system variable with that name at the beginning, and removes it at the end.

Tada!

Having issues pushing SCOM through the Windows firewall?

You opened the Remote Administration exception, you can ping it, you can browse shares, file and print sharing is enabled, yet it still fails?

There is one thing I have not seen documented in the SCOM installation/deployment guides: The agent actually adds an exception for itself when it runs, so if you block local exceptions (What’s the point of having a GPO for the firewall config on your serves if you don’t?) , it will fail.

Add this to your Firewall policy, as a program exception:
%SystemRoot%\422C3AB1-32E0-4411-BF66-A84FEEFCC8E2\MOMAgentInstaller.exe

Be sure to open it for the proper IPs only for added security. Then try to push it again..

Good luck!

You may have issues with the discovery in SCOM not doing anything other than pretending to be working…for days.

It can happen on new setups, or on existing ones if things in particular break. It is a very common problem, and being the lucky guy I am, I obviously had this issue except none of the fixes discussed on forums worked.

Here’s a link to the thread I opened on technet… which includes a detailed description of the problem:

http://social.technet.microsoft.com/Forums/en-US/operationsmanagergeneral/thread/0d76679f-a6ae-4b41-bae8-5477d905a160

Here’s a rundown of what to check. However, this document doesn’t explain how to do every Windows or AD operation, but if you need more info on a specific step, believe me, there’s a lot of information out there on how to proceed with them..

Bottom line:

1 – Is your SCOM running with Local System or domain service accounts?

read more »

Having issues similar to:

Trying to enable EFS on a specific OU, while it’s disable at the top of the structure or domain?
Recovery certificates from two different GPOs mixing up instead of being replaced?

Overall EFS GPOs looking like they aren’t merging properly?

Well, it’s not because EFS GPOs are supposed to behave like black magic. Turns out there’s a bug, Microsoft’s aware of it, but doesn’t think it would be a good idea to FIX IT on Windows XP and 2003.

Thankfully, all it means is you need to edit your GPOs from a Vista, 2008 or Windows 7 machine.

KB : EFS may not be enabled expectedly after you disable a policy and this policy turn off the EFS feature

Opening my EFS GPOs in Windows 7, switching the Allow/Don’t allow and applying the ‘change’ fixed my GPOs. A few minutes later, and stuff was behaving like it should’ve been… Can I have those wasted hours of my life back, Mr. Ballmer?

Sometimes, it might be impossible to clean up all old domain accounts at the same time. Maybe you’re using Windows 2000 mixed mode and don’t have the LastLogonTimestamp field handy, maybe your users use some applications that don’t update it properly…there can be many reasons.

However, if it is a huge environment where there are a lot of administrators, and you know that the deprovisioning process is not always followed, you should at least disable the old accounts that are members of Domain Admin.

I use oldcmp by Joeware, maker of the greatest AD tools on Earth.

Oldcmp was originally designed to disable old computer accounts, but it’s also made to work with user accounts. It can use pwdLastSet and LastLogonTimestamp as attributes.

Check out the oldcmp usage first.

Then, it is a matter of running oldcmp with the proper switches, and filters. Always run it in reporting mode first.

oldcmp -users -report -af “memberof=CN=Domain Admins,CN=Users,DC=domain,DC=com” -llts -age 120 -format csv

oldcmp -users -report -af “memberof=CN=Administrators,CN=Builtin,DC=domain,DC=com” -llts -age 120 -format csv

This will output a CSV file with a list of Domain Admins that have not logged in for 120days+ according to the LastLogonTimestamp attribute. Of course, this attribute is not precise as it is replicated roughly every 2 weeks. However, this will give you a pretty good list of “old” admins.

Then, if you only want to remove them from the Domain Admins group, either do it manually or use admod to do it. If your domain is not totally insane, there should be few accounts to remove.

If you want to completely disable the accounts, you can use the same oldcmp string as above, with the safety and reporting removed. I’ll let you read the usage so you don’t blame me if you disable all your domain admins! If you are using pwdLastSet, watch out not to disable accounts that are set so that the password doesn’t expire..

You should do that on Enterprise Admins and other high privilege groups as well obviously, and also, on the whole domain.

Today I read a post on Windows Networking by Brien M. Posey about “The Confusion of AD Design”.

He argues that some people use way too many OUs and that “less is more”.

As I said before, there are situations that do warrant using multiple OUs. This is particularly true in situations in which there are multiple administrators, and each administrator needs to be delegated control over a different portion of the network.

Well, I’m not aware of many domains that do not have “multiple administrators that need to be delegated control over a different portion of the network”. Those that don’t have that usually don’t have any OUs created other than the default ones, with every user under Users, and every computer under Computers. Of course there might be some exception, for example a domain used only to host your Exchange servers, however, most companies that pay high priced consultants to come in and set up their Active Directories have structures a little more complex than a 25 employee small business.

Having a lot of OUs can be very useful in almost any big domain structure. Let’s say you have 50 different types of servers. Each of these server sets has their own Hardening rules. You apply a “master” hardening GPO at the top of your OU structure, that locks everything down, and then you unlock things for each application, at the OU level. This way, your OUs apply in the proper order by default, and delegation is pretty easy as each application has their own container.

At least, at the end of the article, he acknowledges this:

Right about now, you might be wondering what I really have against creating multiple OUs. There are a couple of reasons why I do not like using multiple OUs unless I have to. Maybe it’s just laziness on my part, but the first reason why I like to try to stick to using a single OU in an Active Directory design is because having multiple OUs tends to complicate LDAP queries.

Well, just do a subtree search then! Laziness, on my end, makes me want to have a structured design where Group Filtering is the exception rather than the rule.

When working a lot with Group Policy, one thing that I would love being able to do is merging user right assignments. If you’re aware of how to do it, be sure to post a comment (Workaround, 3rd party tool, etc).

Let’s say you have 500 servers. All servers run some agent service that must always be set to automatic, and for which you have customized ACLs. (You grant helpdesk the right to restart the service for example).

Well, this is pretty easy to handle as every service can be handled in different GPOs, so you just create a GPO with your settings, and you link it appropriately.

Now, what if you want to grant the service account that this service uses on every computer the right to “Log On as a Service” ? You could put that in the same GPO, but it would override any other policy that has “Log On as a service” defined and is applied before this one. Wouldn’t it be nice to be able to specify in a GPO that the service account must have “Log on as a service” while keeping the currently specified rights?

A great new feature in 2008 is the ability to replicate SYSVOL using DFS Replication. DFS replication is much more powerful and (IMO) easier to troubleshoot than FRS. It was a great improvement in 2003 r2, and it is great that we can now use it on SYSVOL!

 

Ned Pyle at Technet has a great article about verifying on his blog

A limitation of Active Directory that I have always found to be extremely aggravating is the Password and Account lockout policy.

You could only set one for the domain..any other policy defined at the OU level would be applied to local accounts only.

How many times did I wish I could set a different password policy for service accounts ! I had to decide between relying on people to use good service account passwords or forcing end-users to use insane passwords. So we had to trust the people creating the service accounts..

Different departments requiring different policies for auditing purposes were also a reason to setup a separate domain. That means at least two new servers, more management time..ew!

 

In 2008, if you are running AD in Windows 2008 Native mode, you can now create PSOs (Password Settings Objects)  and therefore apply different password policies to different security groups!

 

This is absolutely awesome and is a very good argument to migrate to 2008.

See this Technet article about Password Settings Objects/Fine-grained password policies , and use this great tool (PSOMgr from Joeware) to play with the settings, instead of using Adsiedit.

I wonder when Microsoft will have a nice interface to create these..

 

Oh yeah, and my other favorite reason is Read-Only DCs..let’s say they both rank as #1 reasons