2015-09-29
A Case Study in How NOT To Process Orders
Home » Windows »Event 560 in Perfmon
2015-09-29
A Case Study in How NOT To Process Orders
2014-02-08
Reading email SMTP headers to trace the origin of the message.
2014-02-07
Rants about the pains of performing what should be a simple package upgrade.
Your IP address is
3.238.253.163
Windows Server 2003 comes with a group called Performance Log Users, which is supposed to grant them access to the perfmon MMC snap-in (or rather - System Monitor, as it is now officially called).
I recently came across some servers where this wasn't happening. Accounts were definitely in the group, but were getting a message telling them "You must be an Administrator or Performance Log User to complete this task". Which was odd, because the account was a Performance Log User.
I checked the security logs, and got this back:
Event Type: Failure Audit Event Source: Security Event Category: Object Access Event ID: 560 Date: 6/23/2007 Time: 12:24:32 AM User: DOM_UK\usr.syslog Computer: ACME-WEB01 Description: Object Open: Object Server: SC Manager Object Type: SC_MANAGER OBJECT Object Name: ServicesActive Handle ID: - Operation ID: {0,759817950} Process ID: 720 Image File Name: C:\WINNT\system32\services.exe Primary User Name: ACME-WEB01$ Primary Domain: DOM_UK Primary Logon ID: (0x0,0x3E7) Client User Name: usr.syslog Client Domain: DOMAIN Client Logon ID: (0x0,0x2D498C3B) Accesses: DELETE READ_CONTROL WRITE_DAC WRITE_OWNER Connect to service controller Create a new service Enumerate services Lock service database for exclusive access Query service database lock state Set last-known-good state of service database Privileges: - Restricted Sid Count: 0 Access Mask: 0xF003F
A bit of trawling around the usual suspects didn't yield anything relevant, so it was time to take it to the next level.
This was surely a permissions issue - but permission to what? I fired up a trusty copy of RegMon from Technet/Sysinternals, set it to monitor everything being done by mmc.exe (the System Monitor process) or services.exe (the process listed in the security log) and tried again.
I saw that services.exe was spending quite a bit of time looking through the registry at HKLM\System\CurrentControlSet\Services\SysmonLog\Log Queries - but it wasn't getting any access denied errors. I decided to the check the key out anyhow, since it matched the process that was cited in the logs, and looked relevant to what I was doing.
As it turned out, the permissions set on that key hadn't taken the Performance Log Users group in to account. There was no entry for it in the ACL whatsoever. I added one, gave it permissions to create new keys (counter logs are defined in subkeys of 'Log Queries'), and tried again.
And hey presto, it worked!
If you're getting similar log entries while doing other things, it may not be that same key that's to blame - but fire up regmon and take a look - you'll be glad you did, especially if somebody's been 'hardening' your server.
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 2.0 UK: England & Wales License.
Design by GetTemplate