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.
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?
OALGen in CCR clusters
Just a heads up if you’re running Exchange Server 2007 CCR clusters. Moving the cluster resources (using Exchange Management Console or Exchange Management Shell) does not update the OALGen registry settings accordingly. So, if you normally run your CCR clusters active the “A” node, when you move them to the “B” node, OALGen will start throwing errors once per day with an Event ID of 9395 as seen below.
Event Type: Warning
Event Source: MSExchangeSA
Event Category: OAL Generator
Event ID: 9395
Date: 7/28/2008
Time: 2:12:30 AM
User: N/A
Computer: xxx
Description:
OALGen is running on a cluster continuous replication (CCR) node which does not have registry value ‘SYSTEM\CurrentControlSet\Services\MSExchangeSA\Parameters\CCRCluserName\EnableOabGenOnThisNode’ or it is not set to this node name. Offline address book generation will not be performed.
I don’t know why the cluster move process doesn’t update the registry accordingly, at least it doesn’t in Exchange Server 2007 SP1 UR1. (I wasn’t able to apply UR2 in June due to other maintenance taking a higher priority and now UR3 is out so I’ll just apply that in August during the maintenance window.)
It’s an easy enough fix though as the error itself indicates. Just navigate the appropriate location in the registry of both nodes in the CCR cluster and make the change. I’ll be creating two registry .REG files and just importing them from now on to make the change even faster (and without error).
If you want to perform detailed logging on the next OAB rebuild, which you will want to trigger manually after updating the registry, simply change the logging level for the “OAL Generator” component to Expert by using the following command at the Exchange Management Shell: Set-EventLogLevel -Identity “MSExchangeSA\OAL Generator” –Level Expert. You can then manually trigger the OAB update by using this command (assuming that you haven’t renamed the Default OAB): Update-OfflineAddressBook –Identity “Default Offline Address List”. You should see a lot of activity in the Application log on that CCR node with an Event ID 9107 being the last entry for OAL Generator.
Event Type: Information
Event Source: MSExchangeSA
Event Category: OAL Generator
Event ID: 9107
Date: 7/28/2008
Time: 7:34:24 AM
User: N/A
Computer: xxx
Description:
Offline address list generation finished.
- Default Offline Address List
Don’t forget to set your OAL Generator logging level back down…it’s typically at Low by default, although can check it by using the Get-EventLogLevel “MSExchangeSA\OAL Generator” command. Use the Set-EventLogLevel -Identity “MSExchangeSA\OAL Generator” –Level Low command to set logging back down.
Ops Mgr agents not discovering Active Mailbox nodes
A while back, when I had first started rolling out Operations Manager 2007, I had a strange issue occur where the agents would not discover that the Active nodes in CCR mailbox clusters actually were actually holding the “mailbox” role. The agents made this discovery correctly on the Passive nodes of the CCR clusters, but not on the Active nodes. In fact, the agent wasn’t discovering any Exchange Server 2007 roles on the Active nodes of the CCR clusters.
The problem ended up being that something (although we never found out what) had a lock on the required portion of the Registry that the Ops Mgr agent was trying to scan. Working with PSS, Ops Mgr tracing per KB 942864 was dialed up and analyzed for the Active nodes of the CCR clusters. A snippet from one of the server’s “TracingGuidsNative.etl” log indicates that the Ops Mgr agent was failing to open the registry key below HKLM\Microsoft\Exchange\v8.0\.
[4]33AC.220C::04/11/2008-00:28:25.131 [ModulesRegistry]Failed to open registry key SOFTWARE\Microsoft\Exchange\v8.0\MailboxRole. Error 0×80070006(ERROR_INVALID_HANDLE)
[4]33AC.220C::04/11/2008-00:28:25.131 [ModulesRegistry]Failed to open registry key SOFTWARE\Microsoft\Exchange\v8.0\HubTransportRole. Error 0×80070006(ERROR_INVALID_HANDLE)
[5]33AC.1CD8::04/11/2008-00:28:25.131 [ModulesRegistry]Failed to open registry key SOFTWARE\Microsoft\Exchange\v8.0\MailboxRole. Error 0×80070006(ERROR_INVALID_HANDLE)
[0]33AC.0870::04/11/2008-00:43:23.733 [ModulesRegistry]Failed to open registry key Software\Microsoft\Exchange\v8.0\HubTransportRole. Error 0×80070006(ERROR_INVALID_HANDLE)
[3]33AC.220C::04/11/2008-00:43:23.733 [ModulesRegistry]Failed to open registry key Software\Microsoft\Exchange\v8.0\MailboxRole. Error 0×80070006(ERROR_INVALID_HANDLE)
[5]33AC.3114::04/11/2008-00:43:23.733 [ModulesRegistry]Failed to open registry key SOFTWARE\Microsoft\Forefront Server Security\Exchange Server. Error 0×80070006(ERROR_INVALID_HANDLE)
[7]33AC.2824::04/11/2008-00:43:23.733 [ModulesRegistry]Failed to open registry key SOFTWARE\Wow6432Node\Microsoft\Forefront Server Security\Exchange Server. Error 0×80070006(ERROR_INVALID_HANDLE)
[7]33AC.2824::04/11/2008-00:43:23.733 [ModulesRegistry]Failed to open registry key SOFTWARE\Microsoft\Exchange\v8.0\HubTransportRole. Error 0×80070006(ERROR_INVALID_HANDLE)
[0]33AC.0C18::04/11/2008-00:58:24.102 [ModulesRegistry]Failed to open registry key SOFTWARE\Wow6432Node\Microsoft\Forefront Server Security\Exchange Server. Error 0×80070006(ERROR_INVALID_HANDLE)
[0]33AC.0D78::04/11/2008-00:58:24.102 [ModulesRegistry]Failed to open registry key SOFTWARE\Wow6432Node\Microsoft\Forefront Server Security\Exchange Server. Error 0×80070006(ERROR_INVALID_HANDLE)
[5]33AC.0D78::04/11/2008-00:58:24.102 [ModulesRegistry]Failed to open registry key SOFTWARE\Wow6432Node\Microsoft\Forefront Server Security\Exchange Server. Error 0×80070006(ERROR_INVALID_HANDLE)
Unfortunately, no exact process was found that was locking the Registry. By chance, a reboot neccessitated by the installation of Exchange Server 2007 SP1 Update Rollup 1 freed the lock. After that reboot, the discovery successfully completed.
Granting permissions on Event Logs
I was asked a few days ago by our application developers to grant them read-only access to the Application logs on a couple of Web servers. Some of their Web applications write custom entries to the Application log, and they wanted to be able to connect to the Web servers via Computer Management and see those log entries.
Easy enough request…but I’ll never understand why Microsoft doesn’t allow you to configure Event Log security from the Properties dialog box like you can for literally everything else (file, folders, registry hives and keys, directory services objects, the list goes on…). No, we get stuck using SDDL (Security Descriptor Definition Language)…not exactly the funnest thing in the world.
Fortunately, you can grant permissions on the Event Logs easily enough to either well-known SIDs or even to individual groups or users. First things first…you’ll manage the security settings for the Event Logs via the CustomSD string value in the Registry. Look at the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Eventlog key. Under this key, you’ll see entries for the Application Log, Security Log, etc.
Looking at the CustomSD String key, you see the lovely SDDL entries. Joy!
So, basically, there are three parts:
- Allowing (A) or Denying (D)?
- What level of access?
- Who to?
Allowing or Denying access is pretty straight-forward.
The levels of access are as follows (and are cumulative to reach combinations):
- 1 = Read
- 2 = Write
- 4 = Clear
The last part is the SID that the permissions are being set for. This can either be a well-known SID (in that case a SID string can be used such as IU in the third to last enty in the key above or an actual SID like that seen in the last entry in the key above…or even a REAL user’s or group’s SID. Cool!
So, since I wanted to grant read access to the Application Log only for the developers, I added the following entry to the end of the CustomSD String key for the Application log. Of course, your SID values will be different!
(A;;0×1;;;S-1-5-21-1605523419-404293322-1556899496-26114)
Be sure to get all of the parts of the entry correct. That would be the opening parenthesis, the A or D, the two semi-colons, the Hexadecimal value representation of the cumulative permissions desired, three more semi-colons, the SID and lastly a closing parenthesis.
Need a quick way to get the SID for a security principal in your domain? Try the attached script file. Save it as a .VBS file and place the sAMAccountName of the security principal you’re interested in where the **SAM** placeholder is.
You can get some more information about making these changes in KB323076, and on MSDN.
getSIDv2.zip (419 bytes, 1,170 hits)
-
Translator
