Set the DSConfigDN for Standalone Root CAs
Are you setting up a new PKI implementation in your organization? Are you using a Standalone Root CA with an Enterprise Subordinate CA? If so, don’t forget to properly set the DSConfigDN attribute for your Standalone Root CA (since it can’t read or write in AD!). If you do forget to do this and then you install your Enterprise Subordinate CA…well, you’ll be unhappy and end up having to uninstall and then reinstall that Enterprise Subordinate CA after making this change or reissue it’s certificate after making this change. (honestly, the uninstall and reinstall is a cleaner approach if you need to fix this problem).
To properly set the DSConfigDN attribute on the Standalone CA:
- From an administrative command prompt, enter the following command to set the Configuration container DN for the Root CA.
certutil -setreg ca\DSConfigDN “CN=Configuration,DC=mycompany,DC=local” - You should get the following output back:
- SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\ROOTCANAME\DSConfigDN:
- NewValue: DSConfigDN REG_SZ = CN=Configuration,DC=mycomapny,DC=local
- CertUtil -setreg command completed successfully.
- The CertSvc service may need to be restarted for changes to take effect.
- Stop and then start the Active Directory Certificate Services service as required. This can be done from the command prompt, the Services console or the CA console.
The change looks like that seen in the figure below when viewed in the Registry Editor.
ForeFront for Exchange scanners not showing as updated
I recently had one of my Hub Transport servers running ForeFront for Exchange Server 2007 SP1 start behaving strangely. It was reporting that the scanner updates for “Norman Virus Control” and “AhnLab AntiVirus Scan Engine” as being over a week old, even though the most current definitions were on the disk in the correct location and the ini file (update.ini) indicated the correct version both in the ini file and within the ForeFront console. This, of course, caused OpsMgr to send quite a few emails about the out of date definitions.
Trying to force a manual update did no good, neither did restarting the relevant services. The solution, delete the update.ini file and then force a manual update process. You can find the current (extracted) scanner defintion files in the following location:
C:\Program Files (x86)\Microsoft Forefront Security\Exchange Server\Data\Engines\x86\scanner\Bin
Adding 32-bit print drivers to 64-bit print server
This is one of those issues that I just can’t figure out why Microsoft did not include both 32-bit and 64-bit print drivers on the media for Windows Server 2008. Or maybe as a download pack or something. The trend is definitely to use 64-bit servers (no other choice if you’re using Windows Server 2008 R2 or newer), but many client workstations are going to be 32-bit for years to come. Anyhow…if you have a 64-bit print server and need those 32-bit print drivers, see below. (Or vice versa, 32-bit print server serving up print queues to 64-bit workstations).
Step 1: Share a print queue out on the 64-bit print server
- Login with local administrative permissions to the Windows Server 2008 64-bit print server.
- Add a new printer, name it, share it, add to the directory, etc. (You should be using the Print Management Console to manage your printers!)
At this point you have a new shared print queue with 64-bit drivers.
Step 2: Add the 32-bit drivers
- Login with local administrative permissions to a Windows Server 2008 32-bit server. (For best results always use the EXACT SAME OS VERSION AND SP LEVEL here, though you can possibly do this from a fully up to date Windows 7 or Windows Vista workstation)
- Browse to the 64-bit print server by UNC path, i.e. \\PrintServer.
- Click on the Printers folder (or just include that in your UNC path above).
- Right-click a shared printer and select Properties from the context menu.
- Click on the Sharing tab.
- Click the Additional Drivers button.
- Check the x86 Type 3 - User Mode box.
- Click OK, install the drivers.
- Close all open windows.
Done.
Adapted from TechNet social discussion.
Black login screen on Windows Server 2003
This was passed to me by Robert C.
Issue: An application server ran out of disk space on the “C” volume. We could connect to file shares but RDP sessions and the console session showed a black screen so no one could not log in.
Fix: Since the server ran out of disk space the colors for the default user are all reset to black. To correct the issue I took a similar OS and exported the following reg key “HKEY_USERS\.DEFAULT\Control Panel\Colors”. Since I could not login, I connected via network registry, saw all of the color values were set to “0” and imported the export from a valid source taken previously. Rebooted and issue was resolved. Below is an example of that that hive should look like.
[HKEY_USERS\.DEFAULT\Control Panel\Colors]
“ActiveBorder”=”212 208 200″
“ActiveTitle”=”10 36 106″
“AppWorkSpace”=”128 128 128″
“Background”=”58 110 165″
“ButtonAlternateFace”=”180 180 180″
“ButtonDkShadow”=”64 64 64″
“ButtonFace”=”212 208 200″
“ButtonHilight”=”255 255 255″
“ButtonLight”=”212 208 200″
“ButtonShadow”=”128 128 128″
“ButtonText”=”0 0 0″
“GradientActiveTitle”=”166 202 240″
“GradientInactiveTitle”=”192 192 192″
“GrayText”=”128 128 128″
“Hilight”=”10 36 106″
“HilightText”=”255 255 255″
“HotTrackingColor”=”0 0 255″
“InactiveBorder”=”212 208 200″
“InactiveTitle”=”128 128 128″
“InactiveTitleText”=”212 208 200″
“InfoText”=”0 0 0″
“InfoWindow”=”255 255 225″
“Menu”=”212 208 200″
“MenuText”=”0 0 0″
“Scrollbar”=”212 208 200″
“TitleText”=”255 255 255″
“Window”=”255 255 255″
“WindowFrame”=”0 0 0″
“WindowText”=”0 0 0″
“MenuHilight”=”210 210 255″
“MenuBar”=”212 208 200″
Anyone else run into this one?
DPM agents not functioning on Server 2008 DCs
I recently rebuilt two domain controllers in a remote site to be Windows Server 2008 SP2 64-bit. They were previously running Windows Server 2003 SP2 R2 64-bit and were in DPM 2007 SP1 with no issues. The build for the 2008 installation from bare metal: the old DCs were demoted, kicked out of the domain and then rebuilt as new with 2008.
When trying to install a DPM agent to the new DC installations now, error 337 was received in the DPM console: the agent did install, but the service does not start and the agent is in an error condition in the DPM console. Looking at a relevant DCOM article in TechNet to verify security for error 337 provided no help. Attempting to manually install and register the DPM agents resulted in the same error. Either way, not good…no protection groups can be configured and no backups can occur.
I could find no documentation specific to what might need to be done to get this working.
Here’s the solution as provided by PSS (with minor edits by me):
*** Problem Description ***
In a 2003 domain that is upgraded to a 2008 domain (native mode) DPM agents on the 2008 domain controllers will never communicate to the DPM server. The agent in DPM will show a red x on it. You can remove the agent and then reinstall the agent with the same results.*** Resolution ***
DPM requires access to AD keys that only have the Builtin “Users” with permissions on them. During the upgrade of the domain, it removes the NT Authority “Authenticated Users” group from the Builtin “Users” group and thus breaks the DPM server from getting access to these keys. To fix this problem, add the NT Authority “Authenticated Users” group to the Builtin “Users” group in Active Directory Users and Computers and wait for replication to occur (in the event of DPM in a remote site), refresh the DPM agent information in the DPM console and you should be green and good.
Strange.
RFC 3647 Certification Practice Statement (CPS) template
Are you implementing a Public Key Infrastructure solution? If so, do you want to fully comply with RFC 3647 and ensure maximum credibility for your PKI solution?
If you answered yes to both of these questions then you’re going to be spending a lot (A LOT) of time working on the writing and approval of a Certification Practice Statement (CPS) and possibly also a Certificate Policy. Per RFC 3647, there is a specific template should should be followed in most, if not all, cases.
Download a template here and don’t forget to also get your organization a Private Enterprise Number (PEN) from IANA…you’ll want that PEN to create your OID tree and assign a globally unique OID to your CPS.
Disclaimer: The template is provided with no warranty or guarantee to suitabiltiy in your orgniazation. The template was created using Microsoft Word 2007 and may open or appear differently in other versions.
Get the template:
CPS_Template.zip (23.8 KiB, 611 hits)
ADAM/AD LDS import fails with error 0×20e7
We’ve got an ADAM instance setup that provide proxy authentication for an application. In one partition of the ADAM instance are the userProxy objects and in another partition objects exist specific to the application that contain security and role information, thus determining what permissions each user has in that application. I use a scheduled VBScript to synchronize the contents of the “ADUSERS” partition with those of the application container. The application support personnel use the built-in vendor provided security management tools to manage the data in the “application” partition, including adding new user entries. My VBScript just created the required userProxy objects when needed in the “ADUSERS” partition…without a corresponding entry in both partitions, i.e. without the userProxy object, there can be no proxy authentication for the user to that application. Simple, standard ADAM usage.
Anyhow, I had been alerted by the applications teams that a certain user that was provisioned within the application security tools hadn’t had a userProxy object created accordingly. Upon further investigation, I found that the scheduled synchronization process, which relies on an ADAM LDIFDE import to create the new userProxy objects had been failing for several days. Running the scripted LDIFDE import command manually, so I could see the exact error, yielded the following output:
C:\WINDOWS\ADAM>ldifde -b <account, domain and password> -s <server> -t <port> -i -k -f <import.ldif file>
Connecting to “<server>”
Logging in as “<user>” in domain “<domain>” using SSPI
Importing directory from file “<import.ldif file>”
Loading entries..
Add error on line 7: Unwilling To Perform
The server side error is: 0×20e7 The modification was not permitted for security reasons.
The extended server error is:
000020E7: SvcErr: DSID-03152AA9, problem 5003 (WILL_NOT_PERFORM), data 84710 entries modified successfully.
An error has occurred in the program
When looking at the import file, there were no issues noted…nothing out of the normal.
dn: CN=adusers,CN=application,CN=adam,DC=company,DC=local
changetype: add
objectclass: container
objectclass: top
cn: adusersdn: cn=someuser,CN=adusers,CN=application,CN=adam,DC=company,DC=local
changetype: add
objectSID: S-1-5-21-xxxxxxxxxx-xxxxxxxxxx-xxxxxxxxxx-xxxxx
objectclass: userProxy
cn: someuser
The key part of that error is actually the data field, 8471. A check of that error code on the System Error Codes (Windows) site of MSDN reveals the following information:
ERROR_DS_NAME_ERROR_NOT_UNIQUE
8471 (0×2117)Name translation: Input name mapped to more than one output name.
So, a duplicate SID exists (the SID is the unique identifier and I’d already verified that this specific CN did not exist in the “ADUSERS” partition of the ADAM instance. Now knowing that this userProxy cannot be created due to a duplicate SID problem, things are getting clearer…but how to determine what existing userProxy object has that SID? And how did another userProxy object get the same SID?
First things first, to determine what existing userProxy object has that SID already, an export of the ADAM “ADUSERS” partition is required. Use a command similar to the following to get it:
C:\WINDOWS\ADAM>ldifde -s <server> -t <port> -d CN=adusers,CN=application,
CN=adam,DC=company,DC=local -f e:\output.ldif
Now that you have the ldif file, the next step is to find the Base64 value of the SID for the user account in question. The easiest way is to look up the objectSID value in ADSIEDIT, targeted at Active Directory (not the ADAM instance) and get the Hexadecimal value of the objectSID attribute for the user account in question. Then convert that Hex value into Base64 using your favorite converter. A really nice one can be found here at TRANSLATOR, BINARY. Simply copy the Hex value into the Hex input box and click Decode. Your Base64 value appears below. Copy this Base64 value and use it to search the exported ldif file. You’ll find the userProxy object with the duplicated SID in no time.
In my case, the problem tracked back to a name change on the user object, changing the first name. The userProxy object had previously been created for the user account before the name change (and with the same SID obviously), but the application administrators had not deleted the old (incorrect) userProxy object manually as they needed to. Thus when the LDIFDE import process tried to create a new userProxy object for the newly renamed user account, the import process failed. Once the incorrect userProxy object was deleted, the import process was able to complete again successfully.
AD Powershell cmdlets!
With the release of Windows Server 2008 R2, there will finally be native support for Active Directory management in Powershell. For those of us (myself included) who don’t/won’t use the third-party add-ins for AD, this is great news!
Check out the AD Powershell team’s blog: Active Directory Powershell Blog (easy enough name to remember) for more information and a downloadable cmdlet reference chart.
Thanks AD Powershell Team!
Exchange Server 2007 SP1 Update Rollup 7!
Wow, that was quick! (I just got SP1 UR6 installed on all my servers a week ago).
Update Rollup 7 for Exchange Server 2007 SP1 has been released. The full list of fixes and updates is documented in MS KB 960384, but I think a lot of people will be happy to see this one specific item corrected:
- 961281- An error is returned when you enable SCR from any source in a child domain after you install Exchange Server 2007 Service Pack 1 Rollup 5
You can get the update here and get to updating! 
Data Protection Manager 2007 error ID 998
I’m currently doing some testing with Exchange Server 2007 and Data Protection Manager 2007 on Hyper-V. As I needed several VMs for the testing, I just installed one and then used NewSID to change the VM SID and name before joining each one to my test domain. Later, upon attempting to configure a new protection group on DPM for one of the Exchange servers I got this error:
The operation failed because of a protection agent failure.
Retry the operation.
ID: 998
Details: Unknown error (0×80042318) (0×80042318)
After checking the usual suspects, including the required VSS patch on the Exchange server to be protected and examining the Event Logs on the Exchange Server I found lots of VSS errors with Event ID 12302 on the Exchange server.
Tt turns out the problem is actually with using NewSID…it doesn’t play well with VSS. The solution’s pretty simple once you find it–here’s one place it resides. The steps are as follows:
- Stop the Microsoft Shadow Copy Provider & Volume Shadow Copy Service.
- Export the contents of the HKLM\Software\Microsoft\EventSystem key to a .reg file (as a backup).
- Delete the HKLM\Software\Microsoft\EventSystem\{26c409cc-ae86-11d1-b616-00805fc79216}\Subscriptions key. (Just delete the Subscriptions subkey; leave the EventClasses key.)
- Restart the server.
- Run the “VSSADMIN LIST WRITERS” command, which should procude output similar to that shown below.
This causes the VSS entries in the HKLM\Software\Microsoft\EventSystem\{26c409cc-ae86-11d1-b616-00805fc79216}\Subscriptions key to be rebuilt when the writers initialize.
If that does not resolve the problem, check the Sysinternals forum link mentioned above for more steps.
-
Translator
