Archive for the ‘Windows Server 2008 R2’ Category

AD LDS SSL woes   Leave a comment

This is a classic case of one of those problems you spend too much time on and the root cause is quite simple to resolve.

I created a new AD LDS installation last week and spent a bit of time plodding through the security side of things setting up a couple of AD LDS accounts and the appropriate delegation so that the appropriate service accounts could be used by the applications sitting either side of the directory service in only the intended manner.

Yesterday, I knocked up quickly the provisioning side of things in Forefront Identity Manager 2010 and pushed the accounts across just as a test and everything seemed fine. That changed when I added the code required for setting the initial password, at which point I started getting an error in FIM of the following nature:

  • In the FIM Synchronisation Service Manager output: cd-error
  • In the properties of the connection space object: “Illegal modify operation. Some aspect of the modification is not permitted.”

When I ran a quick test in LDP I connected just fine, but this was over 389 and without SSL. What I didn’t realise until I checked with the Microsoft FIM forums is that SSL connections are required if you’re going to be performing passwords sets (on the unicodePwd attribute).

So, no big deal. I added a certificate to the workgroup machine at the computer store level and thought I’d be good to go. Wrong!

Okay, so I’d seen this issure before where the service was configured to use the Network Service account, so I dug up this article (http://technet.microsoft.com/en-us/library/cc725767(WS.10).aspx) and quickly ran through the directory permission changes required, restarted the AD LDS instance and tried again. Still no joy.

At this point I was feeling a bit lost. As you do, I checked the event log, and fortunately, the Security event log held the key to the problem. Here’s the event details:

Event ID: 5061
Source: Microsoft Windows Security Auditing
Keywords: Event Failure

Cryptographic Parameters:
Provider Name: Microsoft Software Key Storage Provider
Algorithm Name: Not Available.
Key Name: {removed}
Key Type: Machine key.

Cryptographic Operation:
Operation: Open Key.
Return Code: 0x80090011

So, I still had a problem opening the key, which was a little confusing as I expected the above article to have resolved that issue.

Fortunately, I had ProcessMonitor lying around on my machine, so running it remotely from the server proved to be the trick that solved the problem. When I ran it while filtering for the Result of Access Denied while trying to connect to AD LDS with LDP, I trapped the issue, and determined that the directory published in the Technet article didn’t apply! (This is while using AD LDS on Server 2008 R2)

So, the key I was meant to edit was actually under C:\ProgramData\Microsoft\Crypto\Keys. After finding the correct key, I simply added the Network Service account with Read access and LDP immediately was able to bind with the AD LDS account over SSL! (And so was FIM, more to the point!)

I’m not sure if R2 changed the location as was referenced in the Server 2008 Technet article, but for such a simple fix, it was an obscure troubleshooting process to have worked through!

Cheers,
Lain

Volume activation and you!   Leave a comment

It seems to be that time of the season again where folks come out in force to tackle what seems to be one of the more enduring topics of discussion: volume activation for Windows Server 2008 and Vista / Windows 7.
 
There’s a lot of information and documentation around on this topic, perhaps so much so that it overwhelms people. With that in mind, I thought I’d drop a few lines in here to help simplify – not so much to demystify, the process people embark on. For those of you who love technical documents – in fact, I’ll recommend this reading to anyone working with KMS or MAK activation at all, take a look at this article, which is one of the more recent and helpful Microsoft documents. Though beware, it’s a comprehensive article that contains far more information than you need to actually get activation working, so if you’re not the type of person who can identify just the parts you need, you might find it overwhelming.
 
Anyway, on we go with the simplified version.
 
First, let me clarify the audience. This write-up is aimed at people wanting to get either a KMS host working in a corporate environment, or just folks looking to get a MAK activation working.
 
Assumptions for the corporate folks:
1. You want to set up a KMS 2.0 host that can activate Windows Server 2008 R2 and Windows 7.
2. You access the Internet through a proxy server.
3. You have either a Server 2008 R2 (preferred) or Server 2008 server that you intend to perform this role.
 
Licensing keys
This is always something people get stumped on. For the purposes of this discussion there’s two kinds of keys you need to know about:
  • KMS: These keys are a special key that typically are only available to volume licensing customers. To find your KMS key, you can either ask your account manager for it – if that’s who handles your licensing, or if you are a little more hands-on and have configured an account with which you can log into Microsoft’s Volume Licensing Service Center, then you can get it from there. The important thing to note is you only need one of them!
  • MAK: This key is what folks that own Technet or Technet Plus-style subscriptions typically have access to. Media Activation Keys (MAK) are used to activate a product once, and once only. Unlike KMS activations where the client checks in every 180 days (by default), MAK activations do not check in ever again once activation has successfully completed. The important thing to note here is that you do not use MAK keys with a KMS host-style topology! Just think of MAK and KMS as being mutually exclusive.
So, which key do you need? If you are looking to deploy a KMS licensing topology, where the KMS host activates all your clients, then you need just the one KMS key. If you are running a smaller environment and don’t require the services (or don’t meet the minimum licensing quantities to be able to use a KMS host) of a KMS host, then MAK keys are your best option. In order for a KMS host to start activating your clients, you need to have at least five Server 2008 registration or 25 Windows 7 / Vista registrations. The KMS host will make no attempt to register your licenses with Microsoft until either of these minimum requirements have been met.
 
So, onwards into the technical.
 
One of the most common mistakes I come across is that people do not have the correct proxy configuration in place. It’s important to remember that regardless of whether you use a KMS topology or MAK keys, your KMS service hosts or MAK clients need to be able to talk to specific Microsoft resources out in the wild Internet (note the deliberate exclusion of KMS clients, since they only need to talk to the KMS host). I’m not talking about whether you can get out to the Internet, but whether the computer can – there’s a difference.
 
Now, not all proxy servers are equal here. Here’s a quick guideline:
  • No authentication: Simplest configuration. Simply run the NETSH command that follows to configure the server for Internet access.
  • NTLM authentication: Still simple, though you will need to ensure that either the computer account has Internet access, or that the sites (also found after this section) are put into a group associated with anonymous authentication. Other than this one caveat, it’s the same as the no authentication scenario: just run the NETSH statement.
  • Basic authentication: The computer won’t be able to authenticate with basic credentials, so you will need to organise it so that the list of sites used in activation are added to an anonymous authentication group.

So at this point we have identified the key(s) we need and can get on with the job or setting up the KMS host.

  1. Log onto the server that you wish to be your KMS activation host,
  2. Bring up an elevated command prompt,
  3. Run (optional based on the above points): netsh winhttp set proxy proxy-server=”proxy.yourDomain.com:8080″
  4. Run: slmgr /ipk <5-part KMS key>
  5. That’s all!
For reference, here are the URLs that the KMS host (or MAK client, for those of you waiting on that section) needs to be able to get to:
 
You can verify the success of the KMS key with the following command: slmgr /dlv
 
This command will display whether or not this server is now enrolled in the KMS volume activation channel. The following is an example of the first couple of lines of output:
 
Software licensing service version: 6.0.6002.18112
Name: Windows Server(R), ServerStandard edition
Description: Windows Operating System – Windows Server(R), VOLUME_KMS_R2_B channel
 
The section highlighted in yellow is the crucial section, as this confirms the server is capable of responding to Server 2008 R2 and Windows 7 requests. Further down you will notice another section, for which the following is an example:
 
Key Management Service is enabled on this machine
    Current count: 50
    Listening on Port: 1688
    DNS publishing enabled
    KMS priority: Normal
 
This is a good section if you have to do any troubleshooting, as firstly it tells you that it is actually configured as a KMS host. Importantly, it also tells you what port it is listening on – which can be good to know when checking if the inbound firewall rule exception has been made. (Please don’t tell me you’re one of those strange people who disables the firewall?!)
 
There’s also some stats listed, but the only thing that’s important to know about these stats until either 25 clients or 5 servers have registered, the KMS host will not even try to contact the Internet to validate their activation requests.
 
Just for reference, if you have successfully set up the KMS host, and you aren’t having dramas with any of the following, then you should find you now have a working KMS activation server:
  • Proxy server authentication.
  • DNS SRV record registration (_VLMCS._tcp record).
  • Windows Firewall blocking inbound traffic for the the KMS listening port.
As an example of a successful client registration, if you run the slmgr /dlv command on a Windows 7 machine, you will see a bit of output that starts with the following:
 
Software licensing service version: 6.1.7600.16385
Name: Windows(R) 7, Enterprise edition
Description: Windows Operating System – Windows(R) 7, VOLUME_KMSCLIENT channel
 
Note the different channel name? This is indicative of what you should be seeing on all of your clients if they’re successfully registering (and once you have passed the initial activation requirements of 5 servers or 25 clients – prior to that the activation status will differ).
 
 
MAK activation:
Okay! This is the simple one!
 
For MAK activation, this couldn’t be any simpler. In terms of the steps required, you have some of the same concerns as the KMS folk in that you need to be sure that each and every computer can talk to the relevant Microsoft URLs required for successful activation (this is one of the benefits of a KMS infrastructure: only the KMS server needs to talk to the Internet!).
 
Assuming the clients can all talk to the Internet, then your process for activation is similar to that for setting up a KMS host:
  1. Log onto the client that requires activation.
  2. Open an elevated command prompt.
  3. Run: slmgr /ipk <5-part MAK key>
  4. Done!
Again, as with the KMS folks, you can also verify your KMS activation success (or failure) by running the slmgr /dlv command.
 
Cheers,
Lain

Posted March 15, 2010 by Lain Robertson in Windows Server 2008 R2

Tagged with , ,

2008 R2 Certificate Services   1 comment

I could almost cry over this one – it’s a classic case of trying to be too thorough being my undoing.
 
I’ve had issues with Server 2003 machines not enrolling correctly against a 2008 R2 enterprise CA, but not matter what error I typed in verbatim into the various seach engines, I couldn’t find much at all, let alone anything useful. Eventually, I plonked “Server 2003” SHA512 error site:microsoft.com into Google and low and behold, the best possible result comes up: a knowledgebase article! (And as a tidbit of interest, I put the same search into Bing, and it returned the result second in the list, compared to Google’s seventh! Way to go, Bing!)
 
Here’s some details:
 
Server 2008 R2 CA information
Signing is in SHA512 (though the article applies to SHA256 as well)
 
Server 2003 information
Partial error text:
  • From viewing the Trusted Root certificate:
    • General tab: The integrity of this certificate cannot be guaranteed. The certificate may be corrupted or may have been altered.
    • Certification Path tab: Certificate status: The certificate has a nonvalid digital signature.
  • From trying to request a new certificate:
    • The wizard cannot be started because of one or more of the following conditions:
      – There are no trusted certification authorities (CAs) available.
      – You do not have the permissions to request certificates from the available CAs.
      – The available CAs issue certificates for which you do not have permissions.

In reality, that last dialog should have had a fourth option, I think: You might need an update to your cryptographic provider! Yeah! Anyway, without further ado, you can find the Microsoft support article here! Hopefully this helps if you’re having trouble resolving the same problem I had! (The Server 2003 problem, that is – not the poor searching issue!)

Cheers,
Lain

PS, here’s two other links I stumbled across that are potentially really good to have on hand, even if they apply to different versions of ADCS:

Posted February 5, 2010 by Lain Robertson in Windows Server 2008 R2

Tagged with ,

Automatic Updates and Windows Server 2008 Server Core installations.   Leave a comment

Just a quick update to share a script used to install updates that have been downloaded already by the Windows Update client. Thinking about it, it’s a shame that the wuauclt.exe application doesn’t have an /install switch, since it already has the pre and post-requisites of /detectnow and /reportnow respectively. Oh well, the script was simple enough.
 
As an important aside, I wrote this for the WSUS 3 client, since that’s what we have here in our environment. This isn’t an issue for us given it’s destined for use on Server 2008 Core installations, but if you intend to use it elsewhere, just keep that in mind.
 
This is not designed to be a detection script, since you should already have configured your Windows Update settings via Group Policy. It’s purely meant to allow updates to be installed from the command line.
 
To execute the script, copy and save the content below into a JavaScript file (for example, installUpdates.js), then run it from the command line with the following syntax:
cscript //nologo installUpdates.js
 
You will not be able to run this through the wscript host (which is by design). In any case, here’s the code.
 
Cheers,
Lain
 
 
/*
  A simple script written for Server 2008 Server Core installations to install updates that
  have already been downloaded.
*/

var oWSUSSession, oWSUSSearcher, oWSUSUpdates, oWSUSInstaller;
var oUpdates, oUpdate, oInstallResult;

var oError, oDebug = true;  // Switch Debug to false to avoid some of the text output.

try {
  oWSUSSession = WScript.CreateObject("Microsoft.Update.Session");
  oWSUSUpdates = WScript.CreateObject("Microsoft.Update.UpdateColl");
  oWSUSSearcher  = oWSUSSession.CreateUpdateSearcher();
  oWSUSInstaller = oWSUSSession.CreateUpdateInstaller();

  // Perform a search against the WSUS server to see what updates are required.
  oUpdates = oWSUSSearcher.Search("IsInstalled=0 AND Type='Software'");
  if (Debug) WScript.StdOut.WriteLine("Detected updates = "+ oUpdates.Updates.Count);

  if (oDebug) WScript.StdOut.WriteLine("Enumerating search results:");

  for (var i = 0; i < oUpdates.Updates.Count; i++) {
    oUpdate = oUpdates.Updates.Item(i);

    if (Debug) WScript.StdOut.WriteLine("- Downloaded="+ oUpdate.IsDownloaded + "," + oUpdate.Title);

    // We're only interested in updates that are already downloaded.
    if (oUpdate.IsDownloaded) {
      oWSUSUpdates.Add(oUpdate);
    }
  }

  if (Debug) WScript.StdOut.WriteLine();

  // If we have some updates that are classed as downloaded, then it's now time to install them!
  if (oWSUSUpdates.Count > 0) {

    WScript.StdOut.WriteLine("Updates to install = "+ oWSUSUpdates.Count);
    oWSUSInstaller.Updates = oWSUSUpdates;

    // Run the installer
    oInstallResult = oWSUSInstaller.Install();
    WScript.StdOut.WriteLine("Reboot required = "+ oInstallResult.RebootRequired);
  }
} catch(oError) {
  WScript.StdOut.WriteLine(oError.description);
}

Posted January 29, 2010 by Lain Robertson in Server Core, Windows Server 2008 R2

Tagged with , ,