October, 2009

Hello everyone, Brian Singleton here. There has been a lot of confusion over the Remote Desktop Services (aka Terminal Server) client access license upgrade process in Windows and this posting is an explanation on how the behavior is actually supposed to function.

In Windows Server 2003 as well as Windows Server 2008 and Windows Server 2008 R2 we have a group policy setting called, “Prevent License Upgrade” and below is a description of the setting:

The license server will always try to provide the appropriate RDS CAL for a connection.  For example a license Server provides a Windows 2000 Remote desktop services (RDS) CAL token for clients connecting to a terminal server running Windows 2000, operating system, a Windows Server 2003 family RDS CAL token for a connection to a terminal server running Windows Server 2003, and a Windows Server 2008 family RDS CAL token for a connection to a terminal server running Windows Server 2008.

By default, if the most appropriate RDS CAL is not available for a connection, a Windows Server 2003 license server will issue a Windows Server 2003 RDS CAL, if available, to the following:

• A client connecting to a Windows 2000 terminal server

In the case of a Windows Server 2008 license server, it will issue a Windows Server 2008 RDS CAL, if available, to the following:

• A client connecting to a Windows Server 2003 terminal server
• A client connecting to a Windows 2000 terminal server

So if it works like it is stated in the group policy setting by default, “why does it not work for me”?

This feature is only utilized in mixed terminal server\terminal server license server environments.

The RDS CAL upgrade behavior functions as follows:

Scenario 1: Windows 2000 and Windows Server 2003:

In my environment I have a Windows Server 2000 licensing server as well as a Windows Server 2003 licensing server (TLS).  The Windows 2000 TLS does not have any available Windows 2000 TS CAL tokens, but my Windows Server 2003 TLS has only Windows Server 2003 Per Device TS CAL tokens installed.  I also have a Windows 2000 terminal server which retrieves its TS CAL token from the Windows Server 2000 TLS via license server override. In this scenario my client is a WinCE thin client, since we require a purchased TS CAL to be installed.  The first time I connect to the Windows 2000 terminal server, I obtain a Windows 2000 Temporary TS CAL token from my Windows 2000 TLS.  The second time I connect to the Windows 2000 terminal server the following occurs:

Since my Windows 2000 TLS does not have any purchased, permanent TS CAL tokens available, the Windows 2000 TLS will forward the request to another TLS via TS licensing discovery, in the case of my environment, to the Windows Server 2003 TLS.  Since my Windows Server 2003 TLS does not have any Windows 2000 TS CAL tokens installed it will issue a Windows Server 2003 TS CAL token to the client connecting to the Windows 2000 terminal server.

Scenario 2: Windows Server 2003 and Windows Server 2008/Windows Server 2008 R2:

In my environment I have a Windows Server 2003 licensing server as well as a Windows Server 2008 licensing server.  The Windows Server 2003 TLS does not have any Windows Server 2003 TS CAL tokens available, but my Windows Server 2008 TLS has only Windows Server 2008 Per Device RDS CAL tokens installed.  I also have a Windows Server 2003 terminal server which retrieves its TS CAL tokens from the Windows Server 2003 TLS via license server override.

In this scenario my client is a Windows XP Professional client.  The first time I connect to the Windows Server 2003 terminal server, I obtain a Windows Server 2003 Temporary TS CAL token from my Windows Server 2003 TLS.  The second time I connect to the Windows Server 2003 terminal server the following occurs:

Since my Windows Server 2003 TLS does not have any permanent TS CAL tokens available, the Windows Server 2003 TLS will forward the request to another TLS via TS licensing discovery, in the case of my environment, to the Windows Server 2008 TLS.  Since my Windows Server 2008 TLS does not have any Windows Server 2003 TS CAL tokens installed it will issue a Windows Server 2008 RDS CAL token to the client connecting to the Windows Server 2003 terminal server.

I hope this explanation on the TS CAL upgrade process has cleared the confusions you may have on this feature.

Brian “Bingleton” Singleton

KB

Blog

KB

Blogs

Hello, this is Sabin and Shravan from the Microsoft Directory Services Support team. We are back to cover the third and final part of this series to troubleshoot slowness/delay experienced by clients in accessing a DFS Namespace. As a recap, in Part 1 of this blog, we reviewed the referral process for Domain Based Namespaces wherein we illustrated a working scenario of DFS access. In Part 2 we troubleshot slow access of DFS Shares where user is seeing a delay DFS Servers are in the same site as the client.

In the third part of this series for troubleshooting slow access of DFS Shares, we will review a scenario where a user is seeing a delay while trying to access a DFS share and picks a DFS server outside its own site instead of the local DFS server. This is also referred as “Out of Site Referral”.

STEPS TAKEN:

We reproduced the problem (slow DFS access) and ran the following tools:

Step1: A referral cache view (dfsutil /pktinfo) for a slow DFS access issue:

dfsutil /pktinfo
2 entries...
Entry: \Ms2\rootdfsn\Data
ShortEntry: \Ms2\rootdfsn\Data
Expires in 1780 seconds
UseCount: 1 Type:0x1 ( DFS )
   0:[\Ms1\Data] State:0x100 ( TARGETSET )
   1:[\Ms2\DataReplica] State:0x110 ( ACTIVE TARGETSET )

Entry: \contoso.com\rootdfsn
ShortEntry: \contoso.com\rootdfsn
Expires in 257 seconds
UseCount: 1 Type:0x81 ( REFERRAL_SVC DFS )
   0:[\Ms1\rootdfsn] State:0x100 ( TARGETSET )
   1:[\Ms2\rootdfsn] State:0x110 ( ACTIVE TARGETSET )

DfsUtil command completed successfully.

Analysis:

1. In this case, as you can see the root referral (0x81) shows two TARGETSETs with one server as each indicating a cost boundary –

0:[\Ms1\rootdfsn] State:0x100 ( TARGETSET )
1:[\Ms2\rootdfsn] State:0x110 ( ACTIVE TARGETSET )

2. As we can see, MS2 is set to ACTIVE. Ideally, the client should have chosen the first root target (MS1) in the domain-based root referral, connect to the root server and navigate the subfolders under the root folder. On encountering a link folder, the root server should send a status message to the client, indicating that this is a link folder that requires redirection.

3. If the link referral is not in the cache, the Vista client should have connected to the IPC$ named pipe of the root server in the user’s context (or in the context of the LocalSystem account for pre-vista clients) and request a link referral from the root server which in turn returns a list of link targets.

4. However, as we can see, MS2 (second server in the list) is set as the ACTIVE server since the client was unable to connect and/or request a link referral from the first targetset i.e. MS1.

5. Note: It’s important to note here that the client spent some time trying to traverse the root referral list until it was able to get a link referral and finally get to the link target. This can cause and/or add to the delay in accessing a DFS share.

6. Finally, as we can see in the referral cache the client gets a link referral from MS2 and eventually accesses the target on MS2.

Question:

Why was the client not able to access MS1 DFS root?

Step 2: The following is an excerpt from dfsdiag /testdfsconfig /dfsroot:\\contoso.com\rootdfsn

Starting TestDfsConfig ....
Retrieving All the Root Targets ....

Validating DFS Service ....
Validating DFS Service on MS1.
DFSDIAG_ERROR - SYS - The RPC server is unavailable.
Validating DFS Service on MS2. DFSDIAG_INFO - APPL - DFS Service on MS2 is OK.
Validating Registry Entries ....

DFSDIAG_ERROR - SYS - The network path was not found.
DFSDIAG_WARNING - APPL - MS1's Registry not accessible;Ignoring this for comparison.
DFSDIAG_INFO - APPL - Not a single comparison occured due to errors.
Finished TestDfsConfig.

Analysis:

As evident from above, the DFS service on MS1 doesn’t seem to be running and/or we are not able to bind to this box due to RPC errors.

Step 3: Run dfsdiag /testdfsintegrity /dfsroot:\\contoso.com\rootdfsn /full

Starting TestDfsIntegrity ....
DFSDIAG_ERROR - SYS - The RPC server is unavailable.
DFSDIAG_ERROR - SYS - The specified domain either does not exist or could not be contacted. DFSDIAG_WARNING - APPL - Unable to access dfs metadata of \\MS1\rootdfsn.
Finished TestDfsIntegrity.

Analysis:

More evidence on accessing/binding issues with MS1 root server

Note: Alternatively, we could run dfsdiag /testreferral /dfspath:\\contoso.com\rootdfsn\data /full which collectively runs all the above tests.

Step 4: Try to access the DFS share on MS1 using NetBIOS and FQDN

\\ms1\data - Error: Unspecified Error
\\ms1.contoso.com\data - Error: The network path was not found
“Ping ms1.contoso.com” returns “Destination Host Unreachable”.

Step 5: Run a Netmon trace (network capture) while trying to access the DFS share from client

The following is an excerpt from a Netmon output for the same setup. Not all frames are shows as some have been removed for brevity.

35    VistaDFSClient    DC1    DFS    DFS:Get DFS Referral Request, FileName: \contoso.com\rootdfsn, MaxReferralLevel: 4
36    DC1    VistaDFSClient    DFS    DFS:Get DFS Referral Response, NumberOfReferrals: 2 VersionNumber: 4

Dfs: Get DFS Referral Response, NumberOfReferrals: 2 VersionNumber: 4
NumberOfReferrals: 2 (0x2)
DfsPath: \contoso.com\rootdfsn
DfsAlternatePath: \contoso.com\rootdfsn
TargetPath: Index:1 \Ms1\rootdfsn
TargetPath: Index:2 \Ms2\rootdfsn

40    VistaDFSClient    MS1    ARP    ARP:Request, VistaDFSClient(10.10.10.6) asks for MS1(10.10.10.3)
46    VistaDFSClient    MS1    ARP    ARP:Request, VistaDFSClient(10.10.10.6) asks for MS1(10.10.10.3)
47    VistaDFSClient    MS1    ARP    ARP:Request, VistaDFSClient(10.10.10.6) asks for MS1(10.10.10.3)
48    VistaDFSClient    MS1    ARP    ARP:Request, VistaDFSClient(10.10.10.6) asks for MS1(10.10.10.3)
83     VistaDFSClient    MS1    ARP    ARP:Request, VistaDFSClient(10.10.10.6) asks for MS1(10.10.10.3)
84     VistaDFSClient    MS1    ARP    ARP:Request, VistaDFSClient(10.10.10.6) asks for MS1(10.10.10.3)
114     VistaDFSClient    MS2    SMB    SMB:C; Tree Connect Andx, Path = \\MS2\ROOTDFSN, Service = ?????
115    MS2    VistaDFSClient    SMB    SMB:R; Tree Connect Andx, Service = A:
116     VistaDFSClient    MS2    SMB    SMB:C; Transact2, Query Path Info, Query File Basic Info, Pattern = \contoso.com\rootdfsn
117    MS2    VistaDFSClient    SMB    SMB:R; Transact2, Query Path Info, Query File Basic Info
120    MS2    VistaDFSClient    SMB    SMB:C; Tree Connect Andx, Path = \\MS2\IPC$, Service = ?????
121    MS2    VistaDFSClient    SMB    SMB:R; Tree Connect Andx, Service = IPC
241     VistaDFSClient    MS2    SMB    SMB:C; Transact2, Query Path Info, Query File Basic Info, Pattern = \contoso.com\rootdfsn\Data
242    MS2    VistaDFSClient    SMB    SMB:R; Transact2, Query Path Info - NT Status: System - Error, Code = (599) STATUS_PATH_NOT_COVERED
243    MS2    VistaDFSClient    DFS    DFS:Get DFS Referral Request, FileName: \Ms2\rootdfsn\Data, MaxReferralLevel: 4
244     MS2    VistaDFSClient    DFS    DFS:Get DFS Referral Response, NumberOfReferrals: 2 VersionNumber: 4

Dfs: Get DFS Referral Response, NumberOfReferrals: 2 VersionNumber: 4
NumberOfReferrals: 2 (0x2)
DfsPath: \Ms2\rootdfsn\Data
DfsAlternatePath: \Ms2\rootdfsn\Data
TargetPath: Index:1 \Ms1\Data
TargetPath: Index:2 \Ms2\DataReplica

245    VistaDFSClient    MS2    SMB    SMB:C; Tree Connect Andx, Path = \\MS2\DATAREPLICA, Service = ?????
246    MS2    VistaDFSClient    SMB    SMB:R; Tree Connect Andx, Service = A

ANALYSIS:

1. Packets 35-36 – Shows the DFS referral request from Vista client to domain controller DC1. Then DC1 comes back with a referral response and provides a list in the following order:

TargetPath: Index:1 \Ms1\rootdfsn
TargetPath: Index:2 \Ms2\rootdfsn

NOTE: The referral order is important. As we can see, MS1 is the first server in the list followed by MS2.

2. Packets 40- 84 - Shows the Vista attempting an ARP request to access MS1 (first server in the list) and eventually failing over to MS2. Notice the delay identified by the second column in the parsed capture information.

3. Packets 114 -242 – Shows the client trying to connect to the IPC$ of root (MS2) and navigating shares before getting a STATUS_PATH_NOT_COVERED response (expected) from server indicating the share is a “link folder” as against normal share and requires a link referral.

4. Packets 243-244 – Shows a link referral request from client and MS2 responds with the following referral order:

TargetPath: Index:1 \Ms1\Data
TargetPath: Index:2 \Ms2\DataReplica

NOTE: As you can see, MS1 is the first in the list. However the client chooses MS2 due to previous failures accessing DFS on MS1.

5. Packets 245 – Shows the client accessing the \\MS2\datareplica (target replica for data on MS1) and the user navigates/accesses the files (file.txt) as needed.

Netmon 3.3 Tip: You can parse the network captures using a combination of the following filters:

SMB
DFS
IPV4.address == a.b.c.d && IPV4.address == w.x.y.z

{Where a.b.c.d and w.x.y.z are DFS client/Server IP addresses}

RESOLUTION:

Based on the above steps, we can clearly see that the client is unable to access MS1 via DFS and NetBIOS/FQDN. The traces also indicate the failure accessing MS1 and eventual failover to MS2 server causing the delay of about 40 seconds as evident in the information above. When we checked the services on MS1, the DFS and Server services were running. However as identified above with the ping test, there was an issue with routing to MS1 and once the network issue was resolved, the access to DFS on MS1 was working as expected.

This brings us to the end of our 3 part series. We hope that this blog help solidify your knowledge with DFS behavior and troubleshooting issues with slow access to DFS Shares when you run into them in your environment. Good Luck! Ciao!

-Sabin Nair and Shravan Kumar

KBs

Blogs

Greetings! This is Jonathan again. I was reviewing Chris’ excellent blog post series on designing and implementing a PKI when I realized that it would be helpful to better document the CAPolicy.inf file. The information in this post relies heavily on the information published in the Windows Server 2003 Help File, but this information is updated to include information pertinent to Windows Server 2008 R2.

Another helpful document that discusses many of these settings is available on Technet.

Background

First, what is a CAPolicy.inf file? The CAPolicy.inf contains various settings that are used when installing the Active Directory Certification Service (ADCS) or when renewing the CA certificate. The CAPolicy.inf file is not required to install ADCS with the default settings, but in many cases the default settings are insufficient. The CAPolicy.inf can be used to configure CAs in these more complicated deployments.

Once you have created your CAPolicy.inf file, you must copy it into the %systemroot% folder (e.g., C:\Windows) of your server before you install ADCS or renew the CA certificate.

I’m not going to discuss what settings you need for your particular configuration, nor will I offer guidance on how you should set up your PKI to meet whatever your needs may be. Please follow Chris’ series for that sort of information. I’m simply going to document the available settings in the CAPolicy.inf which, if you follow Chris’ guidance, you’ll find will come in handy.

Let’s get started, shall we?

As I mentioned earlier, the CAPolicy.inf file uses the .INF file structure to specify sections, settings, and values for those settings. It will be impossible here to define a default template suitable for all purposes, so I’m just going to describe all the options and allow you to decide which settings meet your needs. Not all the settings below are required in the file, but those that are required will be called out.

The following key words are used to describe the .INF file structure.

• A section is an area in the .INF file that covers a logical group of keys. A section always appears in brackets in the .INF file.
• A key is the parameter that is to the left of the equal sign.
• A value is the parameter that is to the right of the equal sign.

Version

The first two lines of the CAPolicy.inf file are:

• [Version] is the section.
• Signature is the key.
• “$Windows NT$” is the value.

Version is the only required section, and must be at the beginning of your CAPolicy.inf file.

PolicyStatementExtension

Next is the PolicyStatementExtension section. This section lists the name of the policies for this CA. Multiple policies are separated by commas. The names LegalPolicy and ManagementPolicy are used here as examples, but the names can be whatever the CA administrator chooses when creating the CAPolicy.inf file.

NOTE: Administrator defined section names must observe the following syntax rules:

• A section name cannot have leading or trailing spaces, a linefeed character, a return character, or any invisible control character, and it should not contain tabs.
• A section name cannot contain either of the bracket ([]) characters, a single percent (%) character, a semicolon (;), or any internal double quotation (“) characters.
• A section name cannot have a backslash (\) as its last character.

The names have meaning in the context of a specific deployment, or in relation to custom applications that actually check for the presence of these policies.

For each policy defined in the PolicyStatementExtension section there must be a section that defines the settings for that particular policy. For the example above, the CAPolicy.inf must contain a [LegalPolicy] section and a [ManagementPolicy] section.

For each policy, you need to provide a user-defined object identifier (OID) and either the text you want displayed as the policy statement or a URL pointer to the policy statement. The URL can be in the form of an HTTP, FTP, or LDAP URL. Continuing on with the example started above, if you are going to have text in the policy statement, then the next three lines of the CAPolicy.inf will be:

If you are going to use a URL to host the CA policy statement, then next three lines would instead be:

Please note that the OID above is arbitrary and is used as an example. In a true deployment, you would obtain an OID from your own OID gatekeeper.

In addition:

• Multiple URL keys are supported
• Multiple Notice keys are supported
• Notice and URL keys in the same policy section are supported.
• URLs with spaces or text with spaces must be surrounded by quotes. This is true for the URL key, regardless of the section in which it appears.
• The Notice text has a maximum length of 511 characters on Windows Server 2003 [R2], and a maximum length of 4095 characters on Window Server 2008 [R2].

An example of multiple notices and URLs in a policy section would be:

CRLDistributionPoint

You can specify CRL Distribution Points (CDPs) for a root CA certificate in the CAPolicy.inf. This section does not configure the CDP for the CA itself. After the CA has been installed you can configure the CDP URLs that the CA will include in each certificate that it issues. The URLs specified in this section of the CAPolicy.inf file are included in the root CA certificate itself.

Some additional information about this section:

• Multiple URLs are supported.
• HTTP, FTP, and LDAP URLs are supported. HTTPS URLs are not supported.
• This section is only used if you are setting up a root CA or renewing the root CA certificate. Subordinate CA CDP extensions are determined by the CA which issues the subordinate CA’s certificate.
• URLs with spaces must be surrounded by quotes.
• If no URLs are specified – that is, if the [CRLDistributionPoint] section exists in the file but is empty – the CRL Distribution Point extension will be omitted from the root CA certificate. This is usually preferable when setting up a root CA. Windows does not perform revocation checking on a root CA certificate so the CDP extension is superfluous in a root CA certificate.

Authority Information Access

You can specify the authority information access points in the CAPolicy.inf for the root CA certificate.

Some additional notes on the authority information access section:

• Multiple URLs are supported.
• HTTP, FTP, LDAP and FILE URLs are supported. HTTPS URLs are not supported.
• This section is only used if you are setting up a root CA, or renewing the root CA certificate. Subordinate CA AIA extensions are determined by the CA which issued the subordinate CA’s certificate.
• URLs with spaces must be surrounded by quotes.
• If no URLs are specified – that is, if the [AuthorityInformationAccess] section exists in the file but is empty – the CRL Distribution Point extension will be omitted from the root CA certificate. Again, this would be the preferred setting in the case of a root CA certificate as there is no authority higher than a root CA that would need to be referenced by a link to its certificate.

Enhanced Key Usage

Another section of the CAPolicy.inf file is [EnhancedKeyUsageExtension], which is used to specify the Enhanced Key Usage extension OIDs placed in the CA certificate.

• Multiple OIDs are supported.
• This section can be used during CA setup or CA certificate renewal.
• This section can be used for both the root CA and for subordinate CAs.
• This extension can be marked as Critical.

An example of this section is:

If this section is omitted from the CAPolicy.inf file, the Enhanced Key Usage extension will be omitted from the root CA certificate. If this extension does not exist in a root CA certificate then that root CA certificate can be trusted for all purposes.

By populating this section with specific OIDs, you are limiting the purposes for which the root CA certificate can be trusted. For example, consider the following section:

During the setup of the CA, the root CA certificate will be created with the two OIDs above in the Enhanced Key Usage extension. This root certificate, because of the OIDs specified, can only be trusted for Secure Email (signing and encrypting) and Smart Card Logon. Any certificate issued for some other purpose, such as Client or Server Authentication, would be considered invalid. This restriction would apply not only to this root CA, but also to any CA subordinate to this root.

Basic Constraints

You can use the CAPolicy.inf file to define the PathLength constraint in the Basic Constraints extension of the root CA certificate. Setting the PathLength basic constraint allows you to limit the path length of the CA hierarchy by specifying how many tiers of subordinate CAs can exist beneath the root. A PathLength of 1 means there can be at most one tier of CAs beneath the root. These subordinate CAs will have a PathLength basic constraint of 0, which means that they cannot issue any subordinate CA certificates.

This extension can be marked as Critical.

It is not recommended to use this section in the CAPolicy.inf file for a subordinate CA. To add a PathLength constraint to a subordinate CA certificate if the parent CA has no PathLength constraint in its own certificate, you can set the CAPathLength registry value on the parent CA. For example, to issue a subordinate CA certificate with a PathLength constraint of 1, use the following command to configure the parent CA.

Certutil –setreg Policy\CAPathLength 2

Setting this value causes the CA to behave as though its own certificate had a PathLength constraint of whatever number you specify. Any subordinate CA certificate issued by the parent CA will have a PathLength constraint set appropriately in its Basic Constraints extension.

You must restart Active Directory Certificate Services for this change to take effect.

Cross Certificate Distribution Points

The cross certificate distribution points (CCDP) extension identifies where cross certificates related to the CA certificate can be obtained and how often that location is updated. The CCDP extension is useful if the CA has been cross-certified with another PKI hierarchy. Windows XP and later operating systems would use this extension for the discovery of cross-certificates that might be used during the path discovery and chain building process.

The SyncDeltaTime key indicates how often, in seconds, the locations referred to by the URL key(s) are updated. While this entire section is optional, if it exists, and if the SyncDeltaTime key is present, then at least one URL key must also be present.

This extension can be marked as Critical.

Request Attributes

The [RequestAttributes] section, when implemented on a subordinate CA, allows you to specify a custom subordinate certification authority template. There is already the default Subordinate Certificate Authority template that is published in Active Directory the first time an Enterprise CA is installed in the forest. This default template, however, is a v1 template (Windows 2000-style) and cannot be edited. The CertificateTemplate key allows you specify a different template for your subordinate CA certificate request, one that you created by duplicating the default template.

Server Settings

Another optional section of the CAPolicy.inf is [certsrv_server], which is used to specify renewal key length, the renewal validity period, and the certificate revocation list (CRL) validity period for a CA that is being renewed or installed. None of the keys in this section are required. Many of these settings have default values that are sufficient for most needs and can simply be omitted from the CAPolicy.inf file. Alternatively, many of these settings can be changed after the CA has been installed.

An example would be:

RenewalKeyLength sets the key size for renewal only. This is only used when a new key pair is generated during CA certificate renewal. The key size for the initial CA certificate is set when the CA is installed.

When renewing a CA certificate with a new key pair, the key length can be either increased or decreased. We in Support see this most often when a customer has set a root CA key size of 4096 bytes or higher, and then discover that they have Java apps or network devices that can only support key sizes of 2048 bytes. In that situation, we can use this setting in the CAPolicy.inf file to reduce the key size of the CA. Of course, that means that we have to reissue all the certificates issued by that CA. The higher up in the hierarchy the CA resides, the more inconvenient this procedure is.

RenewalValidityPeriod and RenewalValidityPeriodUnits establish the lifetime of the new root CA certificate when renewing the old root CA certificate. It only applies to a root CA. The certificate lifetime of a subordinate CA is determined by its superior. RenewalValidityPeriod can have the following values: Hours, Days, Weeks, Months, and Years.

CRLPeriod and CRLPeriodUnits establish the validity period for the base CRL, while CRLDeltaPeriod and CRLDeltaPeriodUnits establish the validity period of the delta CRL. CRLPeriod and CRLDeltaPeriod can have the following values: Hours, Days, Weeks, Months, and Years. Each of these settings can be configured after the CA has been installed:

Certutil -setreg CA\CRLPeriod Weeks
Certutil -setreg CA\CRLPeriodUnits 1
Certutil -setreg CA\CRLDeltaPeriod Days
Certutil -setreg CA\CRLDeltaPeriodUnits 1

Restart Active Directory Certificate Services for any changes to take effect.

ClockSkewMinutes allows you to accommodate possible clock synchronization issues. The CA will set the effective time of the published base CRL and delta CRL to the current time less the ClockSkewMinutes. For example, if the clock skew is set to 5 minutes, and the current time is 4:00pm, then the effective time of a newly published CRL would be 3:55pm.

This value can also be set after the CA has been installed.

Certutil -setreg CA\ClockSkewMinutes 10

Restart Active Directory Certificate Services for any changes to take effect.

The default value for ClockSkewMinutes is 10 minutes; if this interval is sufficient then this key can be omitted from the CAPolicy.inf file.

LoadDefaultTemplates only applies during the install of an Enterprise CA. This setting, either True or False (or 1 or 0), dictates whether or not the CA is configured with any of the default templates.

In a default installation of the CA, a subset of the default certificate templates is added to the Certificate Templates folder in the Certification Authority snap-in. This means that as soon as the ADCS service starts after the role has been installed a user or computer with sufficient permissions can immediately enroll for a certificate. This behavior is not always desirable.

To illustrate the point, the Domain Controller and Domain Controller Authentication templates are among the default templates added to the CA as it is installed. The default permissions on these two templates allow all domain controllers in the forest to enroll for certificates based those two templates. Finally, the default behavior of a domain controller is to immediately enroll for a Domain Controller or Domain Controller Authentication template as soon as an Enterprise CA is detected in the forest (Windows 2000 DCs will attempt to enroll for a Domain Controller certificate; Windows Server 2003 and higher will attempt to enroll for a Domain Controller Authentication certificate).

You may not want to issue any certificates immediately after a CA has been installed, so you can use the LoadDefaultTemplates setting to prevent the default templates from being added to the Enterprise CA. If there are no templates configured on the CA then it can issue no certificates.

On Windows Server 2003 and Windows Server 2003 R2, the LoadDefaultTemplates setting only applies to a root Enterprise CA. It is ignored on a subordinate Enterprise CA.

On Windows Server 2008 and Windows Server 2008 R2, the LoadDefaultTemplates setting applies to both root and subordinate Enterprise CAs.

AlternateSignatureAlgorithm configures the CA to support the PKCS#1 V2.1 signature format for both the CA certificate and certificate requests. When set to 1 on a root CA the CA certificate will include the PKCS#1 V2.1 signature format. When set on a subordinate CA, the subordinate CA will create a certificate request that includes the PKCS#1 V2.1 signature format.

ForceUTF8 changes the default encoding of relative distinguished names (RDNs) in Subject and Issuer distinguished names to UTF-8. Only those RDNs that support UTF-8, such as those that are defined as Directory String types by an RFC, are affected. For example, the RDN for Domain Component (DC) supports encoding as either IA5 or UTF-8, while the Country RDN (C) only supports encoding as a Printable String. The ForceUTF8 directive will therefore affect a DC RDN but will not affect a C RDN.

Finally, EnableKeyCounting configures the CA to increment a counter every time the CA’s signing key is used. Do not enable this setting unless you have a Hardware Security Module (HSM) and associated cryptographic service provider (CSP) that supports key counting. Neither the Microsoft Strong CSP nor the Microsoft Software Key Storage Provider (KSP) support key counting.

For more caveats to be aware of when using key counting, please review the following KB article:

951721 The certification authority startup event in the Security log always reports a usage count of zero for the signing key on a computer that is running Windows Server 2008 or Windows Server 2003

Conclusion

There we go. We’ve finally finished the list of all the settings you can configure via the CAPolicy.inf file.

I had at first considered putting all the sections I talked about above into one file so you could see how a “finished” CAPolicy.inf file would look. Then I realized that would be a monumentally bad idea seeing as, with the exception of the [Version] section, everything covered above is totally optional – perhaps with some settings even being contradictory. I’d hate to be responsible for a bad sample CAPolicy.inf file bouncing around the Internet.

The settings that you will want to configure in your CAPolicy.inf file will completely depend on your needs, and will vary between root CAs and subordinate CAs. I certainly hope that you find this information useful.

- Jonathan ‘Small bills only’ Stephens

Hello all, Jason here again. With this blog post, I just wanted to bring an ADMT issue to the masses’ attention, as I’ve experienced it multiple times within just the last couple of months.

There’s an issue when attempting to migrate computer account objects into a Windows 2008 domain that had been prepared for a Read-Only Domain Controller with the ‘ADPrep /RODCPrep’ command.  To confirm if the command had been implemented, look for the following attribute within the ADSIEdit snap-in on the targeted 2008 domain:

CN=ActiveDirectoryRodcUpdate,CN=ForestUpdates,CN=Configuration,DC=<DomainName>,DC=com

Note: If ran, the value for the ‘Revision’ attribute will be set to ‘2’.

This is what is specifically witnessed within the ADMT log file:

ERR3:7075 Failed to change domain affiliation, hr=800704f1

The system detected a possible attempt to compromise security. Please ensure that you can contact the server that authenticated you.

When this error is generated, it is due to the following hotfix NOT being installed onto the client machine that you are migrating into the Windows 2008 domain:

944043 Description of the Windows Server 2008 read-only domain controller compatibility pack for Windows Server 2003 clients and for Windows XP clients and for Windows Vista
http://support.microsoft.com/default.aspx?scid=kb;EN-US;944043

Upon installing the hotfix and rebooting the client machine(s), re-running ADMT for the computer object migration will now succeed.

- Jason “J4” Fournerat

You can stop yelling at me, it's released:

Download:

DFS Replication Management Pack for System Center Operations Manager 2007

Overview:

The DFS Replication Management Pack for System Center Operations Manager 2007 monitors the health of the DFS Replication service on Windows Server 2003 R2 and Windows Server 2008 computers. This management pack monitors events generated by the DFS Replication service. These events provide an insight into the health of the service and folders replicated on monitored computers. This management pack includes a dashboard view which can be used to monitor replication backlogs.

The management pack also features consolidation rules that monitor computers for frequent occurrences of certain operational conditions such as staging cleanups, sharing violations, replication conflicts etc.

Feature Summary:

The following features are new in this release of the DFS Replication Management Pack:

• Alerts indicating outages of the DFS Replication service on monitored computers.
• Alerts indicating configuration issues that require administrative intervention.
• Dashboard view that enables tracking of replication backlogs on monitored computers.
• Tracking of intermittent operational conditions. These conditions are tracked by the management pack and show up either as warnings/errors. Transient warnings/errors flagged for conditions that are resolved over time are automatically corrected by the management pack, once those conditions are resolved.
• Intuitive state view indicating red, yellow and green states of the service, replication groups, and replicated folders configured on monitored computers.
• Monitoring of important service parameters such as staging area usage and replication conflicts generated.

System Requirements:

Supported Operating Systems: Windows Server 2003 R2 (32-Bit x86); Windows Server 2003 R2 x64 editions; Windows Server 2008
Other Software: System Center Operation Manager 2007

Big thanks to MaheshU for letting everyone know the instant it was out.

- Ned 'you hurt me with your words' Pyle