ConfigMgrFu

Ack, Where Are My Certificate Templates?

Although they’ve been around for a while, certificates are a relatively new thing for administrators to have to deal with.  Configuration Manager in Native Mode heavily relies upon them.   

Although technically not required for Configuration Manager, the only documented way (http://technet.microsoft.com/en-us/library/bb694035(TechNet.10).aspx) to create and support ConfigMgr in Native Mode is with a Microsoft Enterprise Certificate Authority (CA) running on Windows Enterprise.  Notice the use of the word “Enterprise” twice.  The first occurrence indicates a CA integrated with Active Directory.  An Enterprise CA enables auto-enrollment via group-policies, AD based CRL publishing, and certificate template use.  The second occurrence of “Enterprise” indicates that the CA must be installed on Windows Server Enterprise (2003 or 2008).  This enables you to use customize certificate templates.  Although you can create certificate templates on standard versions of Windows, you cannot actually use them.

Certificate templates will make your life much easier – they let you customize certificates that are issued by your certificate authority.  Creating the certificate templates for ConfigMgr is straight-forward when you follow the guide above – note that this guide is for a Windows 2003 based CA, Microsoft has a draft document for using a Windows 2008 CA but it is not generally available yet (http://blogs.technet.com/wemd_ua_-_sms_writing_team/archive/2008/06/30/having-problems-deploying-the-certificates-for-native-mode-with-a-windows-server-2008-ca.aspx).  I’m using this draft guide right now and its works well.

One slight hiccup that you might encounter is that when you create a new certificate template, it is not immediately available when you click on New->Certificate Template to Issue.  Many troubleshooting guides recommend that you ensure that you are running on Windows Enterprise.  They neglect to mention that the template must first replicate to every DC in your forest before it is available.  For smaller forests, no big deal.  For larger ones, this will cause you a delay that may have you pulling your hair out if you don’t know what’s going on.

It’s 10 o’clock, do you know where your DNS zones are?

Windows 2003 introduced the ability to move Active-Directory integrated DNS zones from the default AD partition to dedicated partitions.  You do this through the DNS MMC snap-in by right-clicking on a DNS zone and choosing Properties.  On the General tab of the properties dialog box, click Change next to the Replication line.  This brings up the Change Zone Replication Scope dialog box which allows you to choose one of the following:

• To all DNS server in the Active Directory forest
• To all DNS server in the Active Directory domain
• To all domain controllers in the the Active Directory domain
• To all domain controllers specified in the scope of the following directory partition

So what is the difference between these and why would would want to move your zones?

Each choice specifies which AD partition is used to store the zone’s data.  AD partitions are separate areas of storage within AD itself; each individually named partition can have its own security and replication configuration.  The third choice in the list, To all domain controllers specified in the scope of the following directory partition, is equivalent to how zones were stored in a Windows 2000 AD; the partition used is the default AD partition where all User and Computer objects are also stored.

The first two choices create or use a new application partition in AD and stores the DNS zone there.  The main purpose for this is to prevent the replication of the DNS zone and its records to domain controllers that do not need it, specifically to DC's without DNS installed.  The second option also limits the replication scope by not replicating the zone to DC's outside of the local domain in the forest.  If you have a single domain forest, there is no effective difference between these two.  In smaller network implementations, the reason for doing this is not evident, but when you are dealing with thousands or ten of thousands of dynamically updated records, replication latency and replication bandwidth usage become issues.

The third option allows you to define a custom application partition for advanced control over the replication scope or schedule.

Each zone is configured separately and all zone types have these options available as long as they are AD integrated.

To verify the actual AD storage of a zone, use ADSIEdit (built into Windows 2008 or loaded from the Windows Server 2003 support tools).  Zones are always stored in a parent container called MicrosoftDNS.  The table below contains the DN of this container for the three primary zone locations.  Every zone will have a sub-container that contains all the records for the zone.  The standard caveat for editing AD data using ADSIEdit applies: if you don’t know what you are doing, look, but don’t touch.

2008 DC in a 2003 Domain/Forest

I recently installed a new 2008 domain controller in 2003 forest for a customer.  The documentation on TechNet is straight-forward and I didn’t encounter any issues with upgrading the schema or the domain or DCPROMOing the server.  I returned to the customer last week and discovered that Group Policy was not refreshing for the computer account and attempts to update global catalog related DNS entries were also failing. 

GroupPolicy, 1055:

The processing of Group Policy failed. Windows could not resolve the computer name. This could be caused by one of more of the following:
a) Name Resolution failure on the current domain controller.
b) Active Directory Replication Latency (an account created on another domain controller has not replicated to the current domain controller).

Web searches revealed nothing.  At first I though it was my IPv6 configuration on the system. Nothing there. I tried adding the computer account to various groups, still nothing. After a day and a half, I finally felt that the promotion went bad somewhere and demoted the system, let it sit over the weekend and promoted it again. Same problems with different error messages.

GroupPolicy, 1097:

The processing of Group Policy failed. Windows could not determine the computer account to enforce Group Policy settings. This may be transient. Group Policy settings, including computer configuration, will not be enforced for this computer.

Web searches for this didn’t reveal a lot either. A reboot later and the error message changed with the same end result: Group Policy for the system was not refreshing.

GroupPolicy, 1006

The processing of Group Policy failed. Windows could not authenticate to the Active Directory service on a domain controller. (LDAP Bind function call failed). Look in the details tab for error code and description.

This time, however, a web search turned up a KB and a hotfix: Events 1925, 1006, 1645, 1055, 40961 on new Windows Server 2008 domain controllers or error message: "No authority could be contacted for authentication" in Windows Vista when you try a Remote Desktop Connection. A quick call to Microsoft scored me the hotfix which has cleared up the problem: Yipee! Because this is at a customer site, I cannot verify the exact cause of the issue or whether it lines up with the cause described in the KB. I’m just glad that it worked.

OWA Plain text

So I've noticed this "problem" on our internal Exchange system and at every customer site that I deal with that has Exchange 2007: when you send e-mail to an external recipient via OWA, it is sent as plain text.  This is sometimes very annoying but I could never find a solution or even anyone asking the question.  After some (more) hunting the other day I actually came up with a possible solution: http://forums.microsoft.com/TechNet/ShowPost.aspx?PostID=2012151&SiteID=17.  I had our internal IT folks implement the fix and it's now working.  It's a quick command to run in Powershell and completely reversible:

set-remotedomain -Identity Default -ContentType MimeHtmlText

You can verify the setting on an Exchange 2007 server by running the following:

Get-RemoteDomain -Identity Default

The documentation for set-remotedomain indicates that the default setting for the ContentType option is MimeHtmlText; however, this is not (based on my experience with multiple production Exchange installations) the default Exchange setting.