Blog - Title

May, 2010

  • Enabling CEP and CES for enrolling non-domain joined computers for certificates

    Hey all, Rob here again. I thought I would expand upon my last blog describing Certificate Enrollment Web Services by covering some of the different configurations that are possible.

    As a refresher, Certificate Enrollment Policy and Certificate Enrollment Services abstracts certificate Policy and certificate Enrollment from a specific Active Directory forest allowing clients in a different forest -- or no forest -- to request and obtain certificates.

    So here is a simple network diagram of what I am setting up in this blog post.


    A non-domain joined computer on the Internet needs to be able to enroll for certificates from a Microsoft Enterprise Certification Authority. We are configuring the CEP/CES web services to interact with the Internet-based computer and this computer has no network connectivity to domain controllers or certification authorities behind the firewall. You could also further isolate the domain controllers and certification authorities by placing the CEP/CES server(s) in a perimeter network with another firewall between CEP/CES and the internal network.

    Installing CEP and CES Role Services

    First you need to install the CEP and CES roles on the member server Win2K8R2-MEM1.

    1. Launch Server Manager.
    2. Click on Roles in the tree view.
    3. In the right hand pane click on “Add Roles”.
    4. Click the Next button.
    5. Check the box “Active Directory Certificate Services”.
    6. Click Next button twice.
    7. Uncheck “Certification Authority”.
    8. Check “Certificate Enrollment Web Service”.
    9. When you check the role, another dialog box will come up as shown below. Click the “Add Required Role Services” button.

      Figure 1 - Additional required role services 
    10. Check “Certificate Enrollment Policy Web Service”.

      Figure 2 - Adding CEP and CES Role Services 
    11. Click the Next button.
    12. Click the Browse button and select the CA to which this CES server will send certificate requests.

      Figure 3 - Select the certification authority 
    13. Click the Next button.
    14. Select “Username and password” as the Authentication Type. We are choosing this method because these are non-domain joined computers and do not have a domain-based account to pass to the web service.

      Figure 4 - Select Authentication Type 
    15. Click the Next button.
    16. Select “Use the built-in application pool identity”.

      NOTE: I know that the setting default is Specify service account (recommended). If you want to specify an account see the advanced configuration section at the end of the blog.

      Figure 5 - CES Application pool identity 
    17. Click the Next button twice.
    18. You will be given a screen listing IIS components. Do not make any changes; just click the Next button.
    19. Click the Install button.

    Configuring SSL certificate for the websites

    For those of you well versed in getting certificates issued through IIS and how to setup the websites to require SSL you can skip this section.

    1. Open Internet Information Services (IIS) Manager.
    2. Select the server node in the tree view.
    3. In the right hand pane double click on Server Certificates.

      Figure 6 - Server certificates 
    4. Click on Create Domain Certificate.

      Figure 7 - Create domain certificate 
    5. The Create Certificate dialog box will be presented. Fill out the fields; the “Common name” field MUST be the DNS name that the clients will use to connect to the CEP / CES services on the Internet. In figure 8 you will be using “” as the Internet DNS name. If you need to request a certificate that has multiple DNS names associated with it then you can create the certificate using the Custom Certificate requests within the Certificates snap-in.

      Figure 8 - Create Certificate wizard 
    6. Once you have filled in the fields, click the Next button.
    7. Select the online certification authority.NOTE: If an enterprise certification authority is not listed, then look to make sure that the Root CA certificate is in the Trusted Root Certification Authority machine store. Also, the Create Certificate Wizard will attempt to enroll for a certificate based on the default Web Server template. If that template is not available then enrollment will fail.
    8. Type in a friendly name for the certificate.
    9. Click the Finish button.
    10. Back in the IIS Manager Tree view, expand to select Default Web Site node.
    11. In the right hand pane select SSL Settings.
    12. Click on Bindings for the action.

      Figure 9 - SSL Bindings
    13. Select the HTTPS binding, and click the Edit button.
    14. Select the certificate created in step 9 for the SSL certificate field.
    15. Click the OK button.
    16. Click the Close button.
    17. Select each web service virtual directory one at a time and do the following.
      1. Double click on SSL Settings.
      2. Verify Require SSL is checked.
      3. Lastly, you will want to give a friendly name to the CEP service. This friendly name shows up on all client computers when they manually request certificates.
      4. Expand Default Web Site.
      5. Select the virtual directory ADPolicyProvider_CEP_UsernamePassword.
      6. Double click on Application Settings.
      7. Double click on the group name FriendlyName.
      8. In the value field, enter a name that uniquely identifies your organization. See figure 10 for an example.

        Figure 10 - Adding FriendlyName value

    Modification of msPKI-Enrollment-Servers attribute

    Now that you have the services installed and the IIS configuration completed, you need to focus on the URI sent to the client computer to which it will send the enrollment request.

    1. Run ADSIEdit.msc.
    2. Expand ADSIEdit to: cn=Enrollment Services,cn=Public Key Services,cn=Services,cn=Configuration, DC=yourforestrootdomain,dc=com.
    3. In the right hand pane select the CA for which you are configuring CEP/CES.
    4. Right click and select Properties.
    5. Double click on the attribute msPKI-Enrollment-Servers. See Figure 11.

      Figure 11 - CA Enrollment Services object properties
    6. You need to modify the URL address here to match the Internet based URL that the client computers will be using. You can use the Remove button, and modify the URI and then click the Add button to get the changed URI added back to the attribute.
    7. So in my setup here is what I changed:

      Original URI: 140

      Changed URI: 140
    8. Click the OK button.
    9. Exit ADSIEdit.msc.

    Configuring the client computers

    Alright, you are almost done with the setup now. The last thing you have to do is configure the clients to use the CEP/CES services.

    Before clients will enroll for certificates against a certification authority hierarchy, they must have the public Root CA certificate in the computer’s trusted root store. This part of the configuration is probably the most difficult since these are not domain computers and you will have to rely on the user to follow the steps. There are two ways to do this – through the snap-in, or with a command-line that you could give to the user as a batch script.

    Adding the Root certificate to the Trusted Root Store
    1. Logon as a local computer administrator account.
    2. You can add the Root CA certificate to the computers Trusted Root Certification Authorities store via the MMC:
      1. Open the Run command and type MMC.
        1. Select File then Add/Remove Snap-in
        2. Select Certificates, and click the Add > button.
        3. Select Computer Account, and click the Next button.
        4. Click the Finish button.
        5. Click OK
      2. Expand Certificates (Local Computer).
      3. Expand Trusted Root Certification Authorities.
      4. Right click on Certificates, and select All Tasks, and then select Import
        1. Certificate Import Wizard comes up.
        2. Click the Next button.
        3. Click the Browse… button and navigate to the CER file.
        4. Click the Next button.
        5. Leave the defaults, and click the Next button.
        6. Click the Finish button.
    3. Or you can run an elevated command prompt (Run as Administrator) and type the below command:

      CertUtil –AddStore Root <Root CA Public Certificate file name>

      For example:
      CertUtil –AddStore ROOT c:\fab-root-ca1.cer
    Configuring the CEP web address in the client

    Before I go into the steps it is important to understand that this configuration is based on the security context. You have a CEP configuration for the user, and you have another configuration for the computer. Depending on what certificates you plan on issuing (user or computer certificates) you may only require one of these to be configured.

    Configuring user certificate enrollment

    1. Run CertMgr.msc.
    2. Expand Certificates, then Current User.
    3. Expand Personal.
    4. Right click on Personal, and select All Tasks, then Advanced Operations, then Manage Enrollment Policies
    5. On the Manage Enrollment Policies dialog click the Add… button. See Figure 12

      Figure 12 - Enrollment Policies dialog box
    6. Type in the URI for the CEP service in the field. This will be in the format of:

      https://<Internet FQDN>/ADPolicyProvider_CEP_UsernamePassword/service.svc/CEP

      In my example this would be:

      NOTE: the only thing that will be unique to your environment is the Internet FQDN of the URI.
    7. In the Authentication type drop down select: Username/password
    8. Click the Validate button.
    9. Once the Validate button is pressed, you will be prompted to type in a domain user name and password. Supply these credentials.
    10. If everything goes correctly you should see that the validation test passed in the lower section of the dialog box see Figure 13.

      Figure 13 - Validation of Enrollment Policy Server configuration

      NOTE: You can see in Figure 13 that the only difference is the DNS portion of this URI. If you scroll down further in the validation output, you will see the friendly name you added under the website configuration being displayed also.
    11. Click the Add button.
    12. Uncheck Enable for automatic enrollment and renewal.

      NOTE: Failure to do so could cause users to be prompted for user name and password each time they logon to the computer. This occurs because Windows Autoenrollment runs immediately after the user has logged on. If the enrollment policy is configured for automatic enrollment and renewal, Windows Autoenrollment will attempt to contact the configured CEP server when it starts in order to determine if new certificates have been assigned. Since this will result in the users being prompted for credentials every time they log on your users may be annoyed.
    13. Click the OK button.NOTE: Follow the same procedures to configure the Enrollment Policy server for the computer personal store if you need to enroll for computer certificates.

    Testing the configuration

    With the users certificate store MMC still open do the following:

    1. Right click on Personal, select All Tasks, and select Request New Certificate…
    2. Certificate Enrollment wizard is displayed.
      1. Click Next.
      2. You will see that our new CEP configuration is being displayed.

        Figure 14 - Certificate Enrollment CEP server 
      3. Click the Next button.
      4. You will be prompted for a domain user name and password. Type in a valid domain user name and password combination. Keep in mind that the account used here will determine what certificate templates that are displayed to you next. You can check the box “Remember my credentials”, however if the account password changes you will have to change the credentials through the credentials vault.
      5. Select a certificate template to issue. I always like to use Basic EFS during testing.
      6. Click the Enroll button.
      7. You will be prompted for User name and Password. Type in a valid domain user name and password combination.
      8. You have now successfully enrolled for a certificate against the certification authority.

        NOTE: The same procedures can be used to test computer certificates. The templates that are available must be configured for “Supplied in the request” on the Subject Name tab for the template. Also, the user account used to authenticate to the CEP and CES service must be configured on the templates Security tab with Enroll permissions.

    How to deploy the Certificate Enrollment Policy URL to clients:

    Now you may be asking “how can I get this configuration deployed to users?” And you may be thinking “these steps are way too complicated for them to follow.” Well, you can export the configuration from the registry and have the users import the settings.

    Computer CEP configuration is located here:

    Use CEP configuration is located here:

    Advanced Configurations

    Alright, so you got your non-domain joined client computers requesting and getting certificates over the Internet. Great job! There are two different topics to be discussed for advanced configurations:

    1. You have multiple CES servers or multiple authentication methods (Kerberos, Username Password, or Certificate) in your environment.

    2. You want to use the CEP and CES services on the same computer, and use a domain or managed service account for the web application pool.

    Multiple CES servers or multiple authentication methods:

    If you have multiple CES servers that host different authentication methods or one CES server that hosts multiple authentication type web services, you need to be concerned with the priority of the authentication methods you specify. If you recall from the section “Modification of msPKI-Enrollment-Servers attribute”, those changes assume that this is the only CES server and authentication method you are implementing in your environment. If you need to support multiple authentication methods then the CES URI needs to be added in a different way to assign different priorities to each authentication method.

    The first thing to understand is that the lower the priority number the more preferred the CES URI is. So a priority of 100 is more preferred then that of 200. If you want to find out the different CES authentication types assigned to a certain CA and the priority you can type the following CertUtil command: certUtil –config “<CA Computer Name>\<CA Name>” -enrollmentServerURL

    for example:

    CertUtil –config “\Fabrikam Root CA1” –enrollmentServerURL


    Figure 15 - EnrollmentServerURL output

    As you can see from the output in Figure 15 there are two authentication methods assigned to the Fabrikam Root CA1. You have Kerberos at a Priority of 100, and UsernamePassword at a priority of 200. You can also see that the URL addresses are different. External clients would not resolve the DNS name, and internal clients would prefer Kerberos authentication over the UserNamePassword method because the priority for Kerberos is lower. Failure to set the priorities correctly could cause domain joined client computers to prefer UsernamePassword authentication method over Kerberos, and you will get a lot of calls to the help desk asking why the computer is constantly asking for credentials.

    Domain account running the application pool

    Alright, if you are reading this section, you must be really serious about security, and using domain based service accounts to run application pools. As stated earlier, during the installation phase if the CEP and CES web services are running on the same server then the application pool accounts for both of these services must be using the same account.

    1. Open Internet Information Services (IIS) Manager snapin.
    2. Highlight the Application Pools tree node.
    3. On the right hand pane, you will see some application pool accounts. You are interested in WSEnrollmentPolicyServer and WSEnrollmentServer.
    4. Do the following for each application pool.
      1. Right click on the application pool, and select Advanced Settings.
      2. Select Identity under Process Model node, and click on the button. See figure 16.

        Figure 16 - Application Pool Identity
      3. Radio button select Custom account:
      4. Click on the Set… button.
      5. Type in the Application Pool account in the form of domain\user name.
      6. Type in the password twice.
      7. Click the OK button three times.
    5. Open up computer management (Compmgmt.msc).
    6. Add the group to the local computer IIS_IUSRS group.
    7. Open an elevated command prompt, and type IISRESET

    So in a nutshell, that’s pretty much how you can configure CEP/CES to allow users on non-domain joined clients to enroll for certificates against an internal Enterprise CA. Stay tuned in the future when we’ll cover some other scenarios featuring CEP/CES in Windows Server 2008 R2.

    I hope that you have enjoyed learning how to use CEP and CES to extend certificate issuance to your users and customers.

    Rob “Unjoined” Greene

  • Designing and Implementing a PKI: Part III Certificate Templates

    The series:

    Designing and Implementing a PKI: Part I Design and Planning

    Designing and Implementing a PKI: Part II Implementation Phases and Certificate Authority Installation

    Designing and Implementing a PKI: Part III Certificate Templates

    Designing and Implementing a PKI: Part IV Configuring SSL for Web Enrollment and Enabling Key Archival

    Designing and Implementing a PKI: Part V Disaster Recovery

    Chris here again. In this segment I will be covering setting up certificate templates on the newly created CA hierarchy. Enterprise Certification Authorities (CAs), as well as clients, utilize what are called certificate templates. Certificate templates contain properties that would be common to all certificates issued by the CA based on that template. Windows includes several predefined templates, but Administrators also have the ability to create their own templates specific for their enterprise. When requesting a certificate, a client can just specify the template name in the request and the CA will build the certificate based upon the requestor’s information in Active Directory and the properties defined in the template.

    Certificate templates are also used to define the enrollment policy on the CA. First, an Enterprise CA can only issue certificates based upon the templates it is configure to use. For example, if the CorpUserEmail template is not available on the CA then the CA cannot issue certificates based on that template. Second, permissions set on the certificate template’s Active Directory object determine whether or not a user or computer is permitted to request a certificate based on that template. If a user does not have Enroll permissions on a particular template, the CA will deny any request submitted by the user for a certificate based on that template.

    As the Windows Server operating system has evolved over the last ten years, so has the concept of the certificate template. Currently, there are three versions of templates:

    Version 1 templates were introduced in Windows 2000, and can be used by Windows 2000, Windows Server 2003 (R2), and Windows Server 2008 (R2) Enterprise CAs. Version 1 templates Active Directory objects are created the first time an Enterprise CA is created in the forest. These templates were designed to reflect the most common scenarios for digital certificates in the Enterprise. Unfortunately, if you don’t like the settings we selected you’re pretty much out of luck. Creating new v1 templates, or editing the existing templates, is not supported. The only customization supported is to the permissions on the template.

    Version 2 templates were introduced in Windows Server 2003 and are a vast improvement over v1 templates. First and foremost, v2 templates can be modified by an Enterprise Admin. In addition, the Admin can duplicate an existing v1 or v2 template to create a new v2 template, and then customize the result. Finally, v2 templates expose a larger number of properties that can be configured, and also expose some controls to take advantage of some other new features introduced in Windows Server 2003. One of these features, for example, is key archival. Version 2 templates can be used by Windows Server 2003 and Windows Server 2008 Enterprise or Datacenter Editions. On Windows Server 2008 R2, v2 templates can be used by a CA installed on Standard, Enterprise, Datacenter, Foundation and Server Core Editions.

    Version 3 templates were introduced in Windows Server 2008. Version 3 templates have all the features of a version 2 template with two major additions. First, v3 templates support the use of Crypto Next Generation (CNG) providers, which means that the certificates support Suite B algorithms based on Elliptical Curve Cryptography (ECC). Second, v3 templates have a setting that instructs Windows to grant the Network Service account access to the private key created on the requesting computer. This is great for those certificates that will be used by applications or services that run as Network Service rather than Local System. Version 3 templates are supported by CAs installed on Windows Server 2008 Enterprise and Datacenter Editions. They are also supported by CAs installed on Windows Server 2008 R2 Standard, Enterprise, Datacenter, Foundation and Server Core Editions.

    For a complete table of Windows Server SKU and the features supported by it, check out this blog post by the Windows PKI development team.

    Deploying Certificate Templates

    For the purpose of example, I am going to use a fictional company called Fabrikam. The diligent IT staff at Fabrikam have done their research, performed some testing, consulted the auguries, and they’ve determined what types of certificates they need to issue to meet the specified business needs. The next step is to look at what templates are available that they can use out of the box and which ones they need to modify to suit their purposes.

    Here’s a quick overview of what Fabrikam determined:

    CA Issuance: Domain Controller Authentication, Web Server, and User certificates
    Key Archival: The private keys for User certificates should be archived
    Doman Controller Authentication template: No additional requirements
    Web Server template:

    • A version 2 template must be created from the default Web Server template.
    • The security group Fabrikam Web Servers should have Enroll permissions.
    • The Subject name must contain the DNS name of the web server, and should be provided automatically.

    User Certificate Template:

    • A version 2 template must be created from the default User template
    • Key Archival must be implemented for the template

    Certificate Templates Setup

    Fabrikam has decided that they need to deploy the following certificate templates: Domain Controller Authentication, Web Server, and User. In addition, the fact that Key Archival is to be enabled for the User template means that the CA should also be configured to issue certificates based on the Key Recovery Agent template (Actually, this is not a requirement if there is another Windows Enterprise CA in environment that is configured to issue Key Recovery Agent certificates, and is trusted to do so.)

    Let’s assume that the PKI hierarchy has been set up and is functional. The next step is to configure the certificate templates. Let’s check the configuration of the templates before deploying them.

    To manage the certificate templates, you use the Certificate Templates MMC snap-in. In the Certificate Services MMC snap-in, right-click on the Certificate Templates folder and select Manage from the context menu.


    In the view pane of the Certificate Templates snap-in you’ll see all the certificate templates available in Active Directory. If you locate the Domain Controller Authentication template and double-click on it, you’ll see the properties available for that template. Our fictional IT staff has already reviewed the settings and determined that no changes need to be made, so we’ll just click Cancel, here.


    Next, locate the Web Server template. The default Web Server template already meets the current requirements that arose from an analysis of business needs. However, to allow for future changes Fabrikam has decided that they need to duplicate this default template and create a v2 template.


    To duplicate the existing Web Server template and create Version 2 template:

    1. I right click on the Web Server template and select Duplicate Template from the context menu.
    Fabrikam still has a lot of Windows Server 2003 servers and Windows XP workstations (But they are steadily upgrading. No, really! They are!! Trust me! Sigh.) This means that we can’t use the latest and greatest v3 templates available on our Windows Server 2008 CA. We’ll have to specify that we’re creating a template for Windows 2003 Server, Enterprise Edition which will create a v2 certificate template.

    2. We’ll give a new name to the template: Fabrikam WebServer.

    3. Clients within Fabrikam will connect to the web servers via the server’s DNS name. This means that the requesting server’s fully qualified DNS name must be in the Subject of the certificate it receives. To meet this requirement, click on the Subject Name tab and select Build from this Active Directory information. For the Subject Name Format, select DNS Name. Finally, deselect all of the check boxes under Include this information in the alternate Subject name.

    Now that the new template is configured per the specified requirements, we need to set the security. The computer account for a particular web server will be the principal enrolling for the Fabrikam WebServer template, so we have to make sure that all the web server computer accounts have Enroll permission on the new template. Fabrikam, luckily, has a Security Group containing all of their web servers called, oddly enough, Fabrikam Web Servers. We can simply grant the necessary permissions to that group.


    1. In the template properties, elect the Security tab, and click Add…
    2. Enter the group name (Fabrikam Web Servers) and click the Check Names button.
    3. After the name of the security group is resolved, click OK.
    4. Grant the group Enroll permission.

      The permissions in the security tab should like this when these changes are complete.


      Once all the necessary changes have been made, click Ok to commit the new template and save it to Active Directory. The Fabrikam WebServer template is now ready to be added to the CA.

    User Certificate Template

    We’ll use essentially the same process to duplicate the default User template and modify the resulting v2 template to suit Fabrikam’s requirements.

    Just as with the default WebServer, we’ll duplicate the existing User template to create the custom v2 template. We need to do this because the default User template is a v1 template, so its properties cannot be modified. One of our requirements is to enable Key Archival which requires configuring a setting in the template, so in order to do this a v2 template is required.

    To create and configure our new User template:

    1. Select the User template, right click on it, and select Duplicate Template from the context menu.

    2. Select Windows 2003 Server, Enterprise Edition to create a v2 template.

    3. Change the Template Display name to Fabrikam User.

    4. Navigate to the Request Handling Tab, and select Archive subject’s encryption private key to enable key archival for this template.

    5. Next, set permissions on the new template. Domain Users will already have Enroll permission, but since this certificate will be deployed via user Autoenrollment, Domain Users will also require Autoenroll permission. The permissions, when set properly, should look like this:


      Once all the necessary changes have been made, click Ok to commit the new template and save it to Active Directory. The Fabrikam User template is now ready to be added to the CA.

    Key Recovery Agent Certificate Template

    Although this template was not mentioned as one of Fabrikam’s requirements, it is a requirement to issue at least one Key Recovery Agent certificate to support Key Archival. This step is only necessary if there is not another Windows Enterprise CA configured to issue certificates based on the Key Recovery Agent template.

    For this example, however, let’s assume that there is not and go ahead and configure the Key Recovery Agent template. The only setting that requires modification is the permissions. We’ll assign enroll permissions to the Fabrikam KRA security group so that members of that group can enroll for a Key Recovery Agent certificate.

    1. Open up the Key Recovery Agent certificate template by double-clicking on it and selecting the Security tab. I click Add…
    2. Enter the name Fabrikam KRA and click the Check Names button.
    3. After the name of the security group is resolved, click OK.
    4. Check the Enroll permission.

    Configuring the CA to issue certificates

    To configure the CA to issue the desired certificate templates, I right-click on the Certificate Templates folder, select New, then select Certificate Templates to Issue from the context menu.


    Then I select the certificate templates I wish to issue, by holding down the control key and selecting multiple templates, and then clicking OK.


    This CA can now issue certificates based on the selected certificated templates.



    That’s really all there is to it. While in this segment we only modified a few properties of our templates, in the vast majority of cases there should be no need for making extreme changes. The default templates should be sufficient for most implementations, and the changes we made were more to ease certificate deployment than actually create truly custom templates. Perhaps in a later blog post we’ll cover some of the more esoteric settings. However, this shouldn’t stop you from exploring on your own using the online help.

    In Part IV of this series we’ll cover implementing Web Enrollment and Key Archival.

  • AD FS 2.0 and AD FS 1.x Interoperability

    Hi, it’s Adam Conkle again. I am excited about our recent release of AD FS 2.0 on May 5. I wanted to post a blog about AD FS 2.0 and AD FS 1.x interoperability as soon as possible since I think it will be a common scenario for our customers.

    AD FS 2.0 and AD FS 1.x interoperability was a priority for this release, and full functionality of AD FS 1.x security token servers (STS) and the Claims-aware Web Agent is supported in AD FS 2.0.

    Note: AD FS 2.0 does not support the AD FS 1.x Windows Token Web Agent

    In order to federate between the two versions of AD FS there are some requirements that we need to manually address.

    AD FS 1.x includes three claim types:

    1. Identity – claims to uniquely identify the user
    2. Group – claims to show security group membership
    3. Custom – any other attribute you need to extract and send (i.e. – Given name, surname, office, phone, etc.)

    Below, I will describe methods to send claims from AD FS 2.0 which satisfy the AD FS 1.x claim requirements.

    We will be extracting several claims from an Attribute Store, and, before we begin, we need to understand where the extractions should take place. You can extract from the Attribute Store either on the Claims Provider (CP) Trust or on the Relying Party (RP) Trust. Both will work; the difference is this:

    Claims Pipeline

    When you extract using the CP Trust rules, the claims are injected into the policy processing pipeline early in the process. Then, on the RP Trust, we execute the Issuance Authorization Rules and can make RP authorization decisions based on claims that we already have in the pipeline.

    When you extract using the RP Trust rules, the claims are injected into the pipeline later in the process, and any Issuance Authorization Rules you have configured for the RP Trust will not apply to claims which are issued here since the authorization rules have already executed.

    Name Identifier (Name ID) claim in the SAML subject

    In AD FS 1.x, we require at least one Identity Claim (UPN, Email, or Common Name). The Identity Claim is sent as the subject of the SAML 1.1 assertion as a claim called Name Identifier (Name ID). Name Identifier also has a format property which equals the URI of the primary Identity Claim sent. For example, if userPrincipalName (UPN) is sent as the primary Identity Claim, then the Name Identifier claim is specified with the format of UPN with the claim value equal to the UPN of the authenticating user.

    Here is a snippet of AD FS 1.x SAML assertion showing the Name Identifier claim:

    AD FS 1.x SAML Assertion

    When we utilize AD FS 2.0 there is no concept of Identity Claims, and we also do not automatically send a Name ID claim. This needs to be manually configured so that AD FS 2.0 will send the Name ID claim to the AD FS 1.x server in a format that the AD FS 1.x server is expecting. Simply issuing a UPN claim from AD FS 2.0 to AD FS 1.x does not achieve the requirement, and a Claim Rule is needed.

    Let’s go to the AD FS 2.0 STS, and let’s also assume that AD FS 2.0 is the identity provider (IdP) for this federation scenario. We will configure an Acceptance Transform Rule for the Active Directory CP Trust which extracts userPrincipalName from Active Directory as the UPN claim type (URI). Creating this rule on the CP Trust will place the UPN claim into the pipeline prior to any RP Trust rules firing.

    When you create this rule, use the Send LDAP Attributes as Claims template in the rule editor.

    Figure 1 – Selecting a claim rule template to extract from AD
    Figure 1 – Selecting a claim rule template to extract from AD

    Figure 2 and Figure 3 show a rule named Extract UPN from AD which has been added to the claim rules for the Active Directory CP Trust.

    Figure 2 – Configuring the Claim Rule to extract UPN from AD
    Figure 2 – Configuring the Claim Rule to extract UPN from AD

    Figure 3 – New rule has been created to extract UPN from AD
    Figure 3 – New rule has been created to extract UPN from AD

    Now that we have a UPN claim in the pipeline, the next step is to transform this claim into the format that AD FS 1.x requires: Name ID. We perform the transformation with an Issuance Transform Rule on the AD FS 1.x RP Trust.

    To create a transformation rule, use the Transform an Incoming Claim template in the rule editor

    Figure 4 – Selecting a claim rule template to transform a claim
    Figure 4 – Selecting a claim rule template to transform a claim

    Configure the rule to transform from the Incoming claim type: UPN to the Outgoing claim type: Name ID. Once you select Name ID as the outgoing claim type, the Outgoing name ID format drop-down box becomes available so that we can select the UPN format for Name ID. We want to pass the value of the user’s UPN to the new claim, so select Pass through all claim values.

    Figure 5 – Configuring the transformation rule for Name ID
    Figure 5 – Configuring the transformation rule for Name ID

    When a user authenticates to the AD FS 2.0 STS, the UPN will be extracted from AD during execution of the AD CP Trust rules and injected into the pipeline. Next, the processing rules are executed for the AD FS 1.x RP Trust, and UPN will be transformed to Name ID with the UPN format. The value of the user’s UPN is maintained for the outgoing claim to the RP (AD FS 1.x).

    AD FS 1.x Identity Claims

    Now that we have the Name ID claim handled, we still need to send the appropriate Identity Claim(s) to AD FS 1.x. For that purpose, AD FS 2.0 includes Claim Descriptions for AD FS 1.x UPN and AD FS 1.x E-Mail Address.

    Figure 6 – AD FS 1.x Claim Descriptions shown in the Claim Descriptions node of AD FS 2.0
    Figure 6 – AD FS 1.x Claim Descriptions shown in the Claim Descriptions node of AD FS 2.0

    We simply need to extract them from our Attribute Store (AD, in my case), and send them to the AD FS 1.x RP.

    Figure 7 shows how to configure the claim rule to extract UPN and E-Mail as AD FS 1.x UPN and AD FS 1.x E-Mail Address. I have chosen to create this rule on the CP Trust.

    Figure 7 – Configuring a rule to extract AD FS 1.x claims from AD
    Figure 7 – Configuring a rule to extract AD FS 1.x claims from AD

    In Figure 8, I have selected the Pass Through or Filter an Incoming Claim template so I can pass the AD FS 1.x claim types to the AD FS 1.x RP. This rule is created on the RP Trust so that the claims accepted from the AD CP Trust can be passed to the RP.

    Figure 8 – Selecting the claim rule template to pass a claim through to the RP
    Figure 8 – Selecting the claim rule template to pass a claim through to the RP

    Finally, in Figure 9, I have configured the rule to Pass through all claim values for the Incoming claim type: AD FS 1.x UPN. You will need to create another set of extraction and pass through rules to handle the AD FS 1.x E-Mail Address or Common Name claim types if you wish to send them.

    Figure 9 - Configuring a claim rule to pass through the value of the AD FS 1.x UPN claim type
    Figure 9 - Configuring a claim rule to pass through the value of the AD FS 1.x UPN claim type

    AD FS 1.x Group Claims

    Next, you may need to send Group claims to AD FS 1.x. AD FS 2.0 comes with a built-in Claim Description named Group which has the URI that AD FS 1.x expects for Group Claims. This can be seen on the Claim Descriptions node in the AD FS 2.0 MMC console.

    Figure 10 – Group Claim Description on the Claim Descriptions node of AD FS 2.0
    Figure 10 – Group Claim Description on the Claim Descriptions node of AD FS 2.0

    AD FS 2.0 also has a Claim Rule template named Send Group Membership as a Claim which allows you to select a security group, and send a claim based on membership of that group. I have chosen to create this rule on the RP Trust.

    Figure 11 – Selecting the claim rule template to send a claim based on group membership
    Figure 11 – Selecting the claim rule template to send a claim based on group membership

    Now, all we need is the AD FS 1.x Incoming Group Claim Mapping name the AD FS 1.x administrator is expecting on the resource federation server. For our example, let’s call it SharePointUsersMapping. Our rule looks like this:

    Figure 12 – Configuring a claim rule to send a Group claim based on group membership
    Figure 12 – Configuring a claim rule to send a Group claim based on group membership

    Since I created my rule on the RP Trust this time, there is no need to create a pass-through rule in order for the claim to be sent to the RP.

    AD FS 1.x Custom Claims

    We’re on the home stretch now! Finally, we may need to send additional claims to AD FS 1.x which are neither Identity Claims nor Group Claims; they are AD FS 1.x Custom Claims. As an example, I have extended my AD schema to include a user attribute named costCenter. I want to send the users’ cost center as a claim when they authenticate to a resource hosted by my AD FS 1.x partner.

    I need to create a new Claim Description to handle this on the AD FS 2.0 STS, but I need to do a bit of background work before I create the new Claim Description. If I take a look at a SAML assertion from AD FS 1.x which contains a Custom Claim, it looks like this:


    The way the SAML assertion is constructed here is as follows:

    1. The full URI of the claim type is passed in

    2. Everything after the last “/” in the URI is stripped off of the URI and is used as the AttributeName property

    3. Everything before the last “/” in the URI is used as the AttributeNamespace property

    Consider the following full URI:

    Now, run that through the steps above:

    1. is passed in

    2. FirstNameMapping is stripped off of the URI and is used as the AttributeName property

    3. is used as the AttributeNamespace property

    I’m ready to create my Claim Description for costCenter, which is accomplished on the Claim Descriptions node of the AD FS 2.0 MMC console:

    Figure 13 – Configuring a new Claim Description for Cost Center
    Figure 13 – Configuring a new Claim Description for Cost Center

    The AD FS 1.x administrator will need to create an Incoming Custom Claim Mapping named costCenter so that the incoming claim is mapped.

    The last thing we need to do on the AD FS 2.0 federation server is create a rule using the Send LDAP Attributes as Claims template to extract the costCenter attribute from AD and send it to AD FS 1.x as our new claim type. I have chosen to do this on the RP Trust which, again, negates the need for an additional pass-through rule to the RP.

    Figure 14 – Configuring a rule template to extract costCenter from AD and send as Cost Center
    Figure 14 – Configuring a rule template to extract costCenter from AD and send as Cost Center

    We’re done! This blog post covers AD FS 2.0 as the Claims Provider (Identity Provider) and AD FS 1.x as the Relying Party (Resource Provider) because it is AD FS 1.x which has the special claims requirements. You can certainly configure AD FS 1.x as the Claims Provider and AD FS 2.0 as the Relying Party, but that deployment should be a bit more straight-forward since AD FS 2.0 simply needs to be configured to accept the incoming claims from AD FS 1.x. Thanks for reading, and please let me know if there are any questions or points needing clarification.


    Adam “So He Claims” Conkle

  • FRS to DFSR Migration Tool Released

    Heya, Ned here again. I am out of my barrel and on the road again this week, coming to you live from Las Colinas Texas. As you may have noticed, I recently wrote a TechNet Whitepaper on how to migrate your old custom FRS data to DFSR. Hopefully that's been useful.

    In the meantime though, Mike Stephens and I also created a free migration tool. Because I am lazy very busy I am simply going to repost from our download page at Code Gallery. I hope you find this useful.


    FRS2DFSR is a utility that assists Windows admins in moving from the legacy File Replication Service (FRS) to the newer Distributed File System Replication (DFSR) service. Because FRS is no longer supported except for SYSVOL starting in Windows Server 2008 R2 and because Windows 2000 support ends on July 13 2010, this utility can help unblock admins from migrating to newer operating systems. The tool is written in C# .NET and can be run on x64 and x86 Windows Server 2003/2008/2008 R2 and Windows Vista/7 with DFSR RSAT installed. It requires domain admin rights and is command-line only. FRS2DFSR.EXE exports an existing File Replication Service replica set, deletes the replica set in Active Directory and creates DFS Replication group with the same servers, folders, connections, and settings. See the release notes for utility limitations. This tool is not used for SYSVOL migrations, see below for steps on using DFSRMIG.EXE in that scenario.

    Important support information:

    This tool is provided as-is, without warranty and is not supported by Microsoft Commericial Technical Support (aka CTS, PSS, CSS, EPS). No official support cases may be opened against this tool. It is intended only as a fully functional sample. Use the Discussions and Issue tracker tabs to report issues.

    For a supported set of steps for migrating from FRS to DFSR for custom sets, see:

    DFS Operations Guide: Migrating from FRS to DFS Replication

    To migrate SYSVOL, use the DFSRMIG.EXE tool included in Windows and reference:

    SYSVOL Replication Migration Guide: FRS to DFS Replication

    - Ned "and Mike Stephens" Pyle

  • Friday Mail Sack – Tweener Clipart Comics Edition

    Hey folks, Ned here again. For those keeping score, you’ve probably noticed the full-on original article content has been a bit thin in the past few weeks. We have some stuff in the draft pipeline so hang in there. In the meantime, here’s a weeks worth of.. stuff.

    I like to move it, move it.


    I am confused on what DFS features are different between Standard Edition and Enterprise Edition versions of Windows Server. This includes DFSN and DFSR.


    There are only two* differences:

    DFS Replication – Enterprise edition gives you the ability to use cross-file RDC. Cross-file RDC is a way to replicate files by using a heuristic to determine similar data in existing files on a downstream server and use that construct a file locally without the need to request the whole new file over the network from an upstream partner.

    DFS Namespace – A Standard Edition server can host only one root standalone namespace. It can, however, host multiple domain-based namespaces if running Win2003 SP2 or later. Nice bullet points here.

    * There was a third difference prior to Windows Server 2003 SP2 and in Windows 2000 SP4 – those Standard Edition servers can only run one DFS root namespace, no matter if domain-based or standalone. Since 2000 is nearly dead and you are not supported running Win2003 non-SP2, don’t worry about it further.


    Can I use the miguser.xml and migapp.xml from USMT 3.01 to migrate data using USMT 4.0?


    Yes, but with plenty of caveats. You would not have any errors or anything; the schema and migxml library are compatible. But you are going to miss out on plenty of new features:

    • New applications that were added will not migrate
    • New types of helper functions will not work
    • Updated migration features will not work
    • f you use an old config.xml it will be missing settings.

    Plus if you are using miguser.xml, you are not using the new migdocs.xml, which is vastly improved in most scenarios for what it gathers and for performance. It’s a much better idea to use the new XML files and simply recreate any customizations that you had done if 3.01 – if you still need to use them, that is. A lot of 3.01 customizations may be duplication of effort in 4.0.

    You can steer a car with your feet, but that doesn’t make it a good idea.


    Are there any free tools out there for reporting on AD? Stuff like number of objects, installed OS’s, functional levels, disabled user accounts, locked out users, domains, trusts, groups, etc. The gestalt of AD, basically.


    You can pay for these sorts of tools, of course (rhymes with zest!). If you dig around the intarwebs you will also find some free options. You could of course script any of this you want with AD PowerShell – that’s why we wrote it. One fellow on my team recommends this nice free UNSUPPORTED project that lives on CodePlex called “Active Directory reporting”. It’s a way to use SQL Reporting Server to analyze AD. Feel free to pipe up in the comments with others you like.


    Does USMT migrate file information like security & attributes? The “metadata” aspects of NTFS.


    USMT preserves the security (DACL/SACL) as well as the file attributes like hidden, read-only, the create date, etc. So if you have done this:

    clip_image001 clip_image001[4]

    It will end up migrating the same:

    clip_image001[6] clip_image001[8]

    Note that if you are using the /NOCOMPRESS option to a non-hard-link store, these permissions and attributes will not be set on that copy of the file. That extra data is stored in the migration catalog. So don’t use the data in an uncompressed store to see if this is working, it is not accurate. When restored, everything will get fixed up by USMT based on the catalog.

    Don’t confuse all this with EFS though – that requires use of the /EFS switch to handle.


    When I deploy new AD forests, should I continue to use an empty root domain?


    We stopped arbitrarily recommending empty forest roots a while back – but instead of saying that we just stopped talking about them. Documentation through omission! But if you read between the lines you’ll see that we don’t think they are a great idea anymore. Brian Puhl, the world’s oldest AD admin wishes they had never deployed an empty root in 1999. Mark Parris and Instan both provide a good comprehensive list of reasons not to use an empty root.

    For me, the biggest reason is that it’s a lot more complex without providing a lot more value. Fine Grain Password Policy takes care of differing security needs since Win2008. The domain does not provide enough admin separation to be considered a full security barricade, but merely a boundary of functionality – meaning you are now maintaining multiple copies of group policy, multiple SYSVOLs, etc. All with more fragility. Better to have a single domain and arrange your business via OU’s, if possible.

    PS: I mean that Brian runs the world’s oldest AD, not that he is old. Well, not that old.


    Is there a command-line way to create DFS links (i.e. “folders”)? I need to make a few hundred.


    In 2008/2008R2 & Vista/7 RSAT:

    dfsutil.exe link add

    In 2003/XP Support Tools:

    dfscmd.exe /map


    Finally – the clock is ticking down on Windows 2000 end of life – now just 7 weeks to go. If you have not begun planning your upgrade, migration, or removal of Windows 2000 in your environment, you are officially behind the eight ball. Soon you will be running an OS that does not get security updates. Then it will be immediately owned by some new malware that your AV vendor fails to catch.

    Then your boss will be all like


    and you will be all like


    and your users will be all like


    and your week will be all like


    and your company’s bottom line will be all like


    and you don’t want that. So get to our Windows 2000 portal and make your move to a supported operating system before it’s too late: Windows 2000 End-of-Support Solution Center. Also, Windows Server 2003 enters extended support the same day, so don’t bother asking for bug fixes after that. Get on Win2008/R2 and we’ll be all ears…

    Until next time,

    - Ned  “like”  Pyle

  • Migrated Users Get Prompted To Change Password at First Logon Even After Migrating Their Password with the PES

    Hello all, Jason (J4) here again. I recently experienced an issue with ADMT and the Password Export Service (PES) tool that I wanted to quickly bring to everyone’s attention. The new revision of the ‘ADMT v3.2 Migration Guide’ will include an update to the documentation, but wanting to post here as it’s also something relevant to both ADMT versions 3.0 and 3.1 - which won’t get updated.

    When one uses ADMT and the PES service to migrate passwords of user accounts, the migrated user accounts get the option “User must change password at next logon” enabled by default. Hence, when the user logs onto the new target domain they are required to change their migrated password at first logon.

    After some investigating and discussion with ADMT Program Managers and Developers, this is by-design type of behavior to prevent what is considered a security risk. ADMT and the PES service has no way of determining if the users migrated password is compatible with the target domains password policy; specifically the more sensitive password complexity settings.

    Here are a couple of options in maintaining the end users passwords that they were using in the source domain and commonly the end-goal/desire when using the PES service to migrate users passwords from the very beginning:

    1.) The obvious – manually toggle the “User must change password…” check box within the ‘Active Directory Users and Computers’ snap-in for the user account’s properties and prior to the end user logging into the target domain for the very first time. As represented here with the screen shot, this can also be done by multi-selecting the migrated accounts to check the far-left checkbox and remove the check for “User must change password at next logon”:


    2.) Use the free, excellent, and unsupported ADModify.NET tool:

    3.) Create a VBScript that toggles the pwdLastSet attribute of the migrated user accounts from the default of ‘0’ to ‘-1’. There are a number of samples here:

    4.) Scripting option with DSQUERY and DSMOD USER commands:

    DSQuery user “ou=foo,dc=contoso,dc=com” –scope subtree -limit 0 | DSMod User –mustchpwd no

    5.) And finally, AD PowerShell in Windows 2008 R2/Windows7 RSAT tools:

    Get–aduser –filter {pwdlastset –eq 0} –searchbase “dc=contoso,dc=com” –searchscope subtree | set-aduser –changepasswordatlogon $false


    -Jason (J4) Fournerat

  • Friday Mail Sack – It’s About To Get Real Edition

    Hello Terra, it’s Ned here again. Before I get rolling, a big announcement:

    On May 16th all the MSDN and TechNet blogs are being migrated to a new platform. This will get us back in line with modern blogging software, and include new features, better search, more user customization, and generally remove a lot of suck. Because AskDS is a very popular blog – thanks to youwe rated extra sandbox testing and migration support and we believe things are going to go smoothly. The migration will be running for a week (although many sites will be done before then) and during this time commenting will be turned off; just email us through our contact form if you need to chat. You can read more about the new features and track progress on the migration here.

    On to this week’s most interesting questions.


    What happened to the GPMC scripts in Windows 7 and Win2008 R2?


    Those went buh-bye when Vista came out. They can be downloaded from here if you like and I’ll wager they’ll work fine on 7, but the future of scripting GP is in PowerShell. Recommended reading:


    KB832017 (Services Overview and Network Port Requirements...) lists port 5722/TCP as being used for DFSR -- but only on Server 2008 or Server 2008 R2 DCs.  What exactly happens over 5722/TCP?  KB832017 is practically the only time I've ever seen that port mentioned.


    There’s no special reasoning here, it’s a bug. :-) In a simple check to determine if a computer was a member client or member server, we forgot that it might also be a domain controller. So the code ends up specifying a port that was supposed to be reserved for some client code. Amazingly, no Premier contract customer has ever opened a DCR with us asking to have it fixed. I keep waiting…

    Nothing else weird happens here, and it will look just like normal DFSR RPC communication in all other respects – because it is normal. :)


    You can still change the port with DFSRDIAG STATICRPC <options> if you need to traverse a firewall or something. You are not stuck with this.


    I am missing tabs in Active Directory Users and Computers (DSA.MSC) when using the Windows 7 RSAT tools. I found some of your old Vista content about this, but you later said most of this has been fixed. Whiskey Tango Hotel?


    As is often the case with RSAT (a tool designed by committee due to all the various development groups, servicing rules, and other necessities of this suite), there are a series of steps here to make this work. I’ll go through this systematically:

    After installing RSAT on a domain-joined Windows 7 client, you add the Role Administration Tools for "AD DS Snap-ins and Command-line Tools":


    You then start DSA.MSC and examine the properties of a user. You notice that some or all of the following tabs are missing:

    Published Certificates
    Password Replication
    Attribute Editor
    Remote Control
    Remote Desktop Services Profile
    Personal Virtual Desktop
    UNIX Attributes

    1. Enable "Advanced Features" via the View menu. This will show at least the following new tabs:

    Published Certificates
    Password Replication
    Attribute Editor


    2. If still not seeing tabs:

    Remote Control
    Personal Virtual Desktop
    Remote Desktop Services Profile

    Add the following RSAT feature: "Remote Desktop Services Tools". Then restart DSA.MSC and if Advanced View is on, these tabs will appear.


    3. If still not seeing tab:

    UNIX Attributes

    Add the following RSAT feature: "Server for NIS Tools". Then restart DSA.MSC and if Advanced View is on, this tab will appear.


    4. The "Dial-In" tab will always be missing, as its libraries are not included in RSAT due to a design decision by the networking Product Group. If you need this one added, open a Premier contract support case and file a DCR. We’ve had a number of customers complain about this, but none of them bothered to actually file a design change request so my sympathy wanes. Until they do, there is no possibility of this being changed.


    What tools will synchronize passwords from AD to ADAM or ADLDS?


    MIIS/IIFP (now Forefront Identity Management 2010) can do that. We don't have any in-box tools or options for this. [Thanks to our resident ADAM expert Jody Lockridge for this answer. He’s forgotten more about ADAM than I’ll ever know - Ned]


    I am trying to script changing user home folders to match the users’ logon ID’s. I’ve tried this:

    dsquery.exe user OU=AD_ABC,DC=domain,DC=local | dsmod.exe user -hmdir \\servername\%username%

    But this only places the currently logged on username in all users profile. How can I make this work?


    DSMOD.EXE includes a special token you can use called $username$. It automatically uses the SAM account name passed in from DSQUERY commands and works with the –hmdir, –email, –webpg, and –profile arguments.

    So if I do this to locate all my users and update their home directory:


    I get this:



    When will the Windows Server 2008 Resource Kit utilities and tools be released?


    Never. If it didn’t happen 3 years ago, it’s not going to happen now. The books do include helpful scripts and such, but the days of providing unsupported out of band reskit binaries are behind us - and it’s for the best. If you want to buy the 2008 books, here’s the place:

    2008 Resource Kit -
    2008 GP Resource Kit -


    Something something something Auditing something something something.


    While I find Windows security auditing quite interesting and periodically write about it, if you want retroactive answers to every common audit question you need to visit Eric Fitzgerald’s  blog "Windows Security Logging and Other Esoterica”. Eric was once the PM of Windows Security auditing and helped design the new audit system in Vista/2008, then he moved on to helping design the Audit Collection Service, and gosh knows what he does now – he’d probably have to kill me after he told me. A million years ago, Eric was also a Support Engineer in my organization, so he knows your pain better than most Windows developers. Many questions I get asked about auditing have already been answered on his blog so give it a look before searching the rest of the Internet. Eric is also a funny, decent guy and a good writer – pick any blog post and you will learn something. I wish he wrote more often.


    Finally, we had a nice visit this week from Tim Springston – yes, that  Tim Springston. Tim’s been working on a new system designed to make it easier for you to open support cases and have them route correctly so he bored us to tears demo’ed all that to us. Make sure you stop by his blog and check it out.

    Until next time.

    Ned “fingers crossed on the blog migration” Pyle

  • New Directory Services KB Articles 4/25-5/1



    You cannot generate FSRM reports in Windows Server 2008 if the policy for the United States FIPS compliant algorithms is enabled


    A Windows Server 2003-based terminal server stops responding after many users log on to it and log off from it


    A client cannot automatically join a domain that contains RODCs when a Windows Server 2008-based WDS server is used


    An update is available for Best Practices Analyzer for the File Services role in x64 editions of Windows Server 2008 R2


    Update for the AD DS Best Practices Analyzer rules in Windows Server 2008 R2


    Description of an update for Remote Desktop Services BPA


    The April 2010 stability and reliability update for Windows 7 and Windows Server 2008 R2 is available


    You cannot access the shared files or folders that are hosted on a Windows Server 2008-based or Vista-based computer if the path contains a junction point


    Network connectivity for a Windows Server 2003-based Hyper-V virtual machine is lost temporarily in Windows Server 2008 R2


    Recommended hotfixes and updates for Windows Server 2008 R2-based server clusters


    An incorrect IP address is returned when you ping a server by using its NetBIOS name in Windows Server 2008 or Windows Server 2008 R2


    Files do not go into the Recycle Bin when you delete more than 1000 files at the same time in Windows 7 or in Windows Server 2008 R2


    You cannot run a task that is associated with a business rule of Authorization Manager in Windows Server 2008


    Reliability Monitor displays no information in Windows Server 2008 and in Windows Server 2008 R2


    "SSL Certificate add failed, Error: 1312" error message when you try to add a CTL in Windows Server 2008 R2 or in Windows 7


    The Licensing Diagnosis tool returns a value of “0” for the number of RDS CALs that are available in Windows Server 2008 R2


    The Windows Remote Management service stops responding in Windows 7 or in Windows Server 2008 R2


    The "Invoke-WmiMethod" cmdlet dispatches incorrect results on a computer that is running Windows 7 or Windows Server 2008 R2


    RemoteApp applications are displayed as black windows when you restart the applications in a Remote desktop connection in Windows Server 2008 R2


    "A referral was returned from the server" error message when you use the IADsUser::ChangePassword method in Windows Server 2003 SP2


    Some IPsec packets are dropped unexpectedly on a computer that is running Windows Server 2008 or Windows Vista


    Win2008 R2 BPA Updates Released for April 2010 wave

    Friday Mail Sack – Cup Runneth Over Edition

    Inspecting AD replication facilities with LDAP searches

    Quick-Find, what domain-joined VMs you have?

    Volume Activation Management Tool 2.0 released

    Giving Non Administrators permission to read Event Logs Windows 2003 and Windows 2008

    How to mitigate the SharePoint XSS security issue with Group Policy – KB983438

    Key considerations for Hyper-V virtual machine deployments

    New Networking-related KB articles for the week of April 18 – April 24

    Network Monitor 3.4 Beta Released on Connect!

    Group Policy Hotfix Round Up – 22/4/2010 to 28/4/2010

    KB274274 Focus: The Cross-Forest program deployment problem using Group Policy

    Keep an eye on the Windows Server Information Experience Networking Team’s blog!

    Microsoft's new directory-federation services finally ready to roll

    How Microsoft Secures the Cloud Infrastructure

    Active Directory Domain Services Command Fu, Part 6

    Scripts to make your life easier

    64-bit Version of Acctinfo2.dll

    Active Directory Domain Services Command Fu, Part 5

    The Case of the Printing Failure

    Say goodbye to Windows logon scripts with Group Policy preferences

    Group Policy Setting of the Week 23 – Outlook 2003 RPC Encryption