Something AD administrators used to dread was the inevitable request for access to Domain Controller event logs for monitoring purposes.
The lazy admin (Rob Field) approach was to give the service account Domain Admins. More dedicated staff would fiddle around with the SDDL security descriptors until they got it right.
Well that’s not needed anymore… Delegating read only permission to the event logs cannot be easier with 2008.
There is an Active Directory built-in group called ‘Event Log Readers’. All you need to do is drop the service account that needs this privilege into the Event Log Readers group and your monitoring software should be happy.
Note this gives access to all event logs. However if you do not want to give them access to all event logs you still have to resort to using SDDL. There is a good post here.
This also works with Member Servers. Just drop the service accounts into the Event Log Readers group on each member server.
Thanks to http://www.joulupukki.nl/wordpress/?p=523 for alerting me to this issue.
VMware made a pre release of the new vShield Endpoint Driver (184.108.40.206 build-813867) available last week to customers who are experiencing issues with their current vShield Driver. This will be released in Q4 but if you are using an anti malware product in your virtual environment that relies on vShield Endpoint Driver I would contact VMware to get the patch.
This hotfix needs to be applied on top of vShield Endpoint Driver build 652273 which is available with the VMware tools included with ESXi 5 Express Patch 3 (build 702118).
In the words of VMware this fixes two main issues: performance issues with network files and sharing violation issues.
1. Sharing violations – It was discovered that, while you had the thin agent installed and real-time AV scanning running, if you opened a file on a network share a few times in quick succession, the 3rd or 4th attempt could result in the file being locked. This was due to the lack of caching for network files, which is the recommend AV practice, but caused this locking
2. Performance issues – This was to due to the general overhead when our thin agent called some MS filter methods.
I also found that this version fixes a BSOD issue with vsepflt.sys. More about that in my next post.