Ops Mgr 2007 “Failed Accessing Windows Event Log”
If you’ve been getting these errors from your Operations Manager 2007 DHCP Management Pack, the solution is at hand! Here’s the typical error you’d get:
Failed Accessing Windows Event Log
The Windows Event Log Provider was unable to open the System event log on computer ‘{69E3F0CF-36C3-9FDC-1892-42FB003E34DB}’ for reading. The provider will retry opening the log every 30 seconds. Most recent error details: The RPC server is unavailable. One or more workflows were affected by this. Workflow name: Microsoft.Windows.DHCPServer.Library.Server.UnitMonitor.DependentServiceHealth Instance name: myserver.mycompany.local Instance ID: {69E3F0CF-36C3-9FDC-1892-42FB003E34DB} Management group: MyCompany-SysCtrOpsMgr
It seems that the DHCP MP v6.0.6383.0 introduced this annoying bug that seemingly had no solution. Well, I guess it really didn’t have a solution…until the next version was released. That version, v6.0.6452.0, was released in November and seems to fix the problem. Before you import this updated version though, be sure to remove any exisitng DHCP management packs. Per the included documentation:
Before you import the Windows Server DHCP Management Pack, take the following actions:
- Perform a full backup of the Operations Manager 2007 database.
- Uninstall any existing DHCP management packs. You may wish to record custom overrides and rules for possible inclusion in the new DHCP management pack.
Of course, the fix for this bug isn’t documented in the release notes, but none the less it does appear to be fixed.
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,169 hits)
-
Translator
