The administrator of Configuration Manager, who has to put a particle of his "power over the product" in other hands, often encounters the consequences of ill-considered actions. And it was someone who deleted a collection, or someone else who created an object contrary to the naming convention....
It's not even a matter of "prosecuting the perpetrator," but of reaching the right people with the necessary guidance on how they should act. Of course, there are also companies and institutions where accountability is so important that administrator actions must be recorded.
By itself, Configuration Manager records information about administrators' actions in the status message system, distinguishing them with the "Audit" type. Thus, it is enough to create a filter that catches such messages, directing them to a properly prepared log. Application log, although the easiest to use is not a good place, as many applications write various information to it. So the plan of action is as follows:
- Create an audit log for Configuration Manager.
- Create a data source.
- Create a script that writes information to the indicated log based on variables.
- Create a Configuration Manager filter (or change the existing filter 12 by adding a program run) referring to the Audit type causing the execution of a script with the indicated parameters. Note that the log created with such a command will start its "life" from the next reboot of the system, do not try to write to it before.powershell.exe -ExecutionPolicy Bypass -Command "&{Write-EventLog -LogName ConfigMgrSecurity -Source 'Configuration Manager security auditing' -eventID %2 -EntryType %3 -message '%4′ }"Configuration Manager's status filter should have an example form (assuming that a script named FILTR.BAT is placed in the C:SCRIPTS directory.
- C:SCRIPTSFILTR.BAT "Configuration Manager security auditing" %msgid SuccessAudit "%msgdesc"
- A script (here, for example, FILTR.BAT located in the C:\nSCRIPTS directory) can contain a single line, calling a PowerShell command:
- New-EventLog -LogName ConfigMgrSecurity -Source "Configuration Manager security auditing"
- Assuming that the log will be named "ConfigMgrSecurity" and the data source will be "Configuration Manager security auditing", start with the PowerShell command:powershell.exe -ExecutionPolicy Bypass -Command "&{Write-EventLog -LogName ConfigMgrSecurity -Source 'Configuration Manager security auditing' -eventID %2 -EntryType %3 -message '%4′ }"
Configuration Manager's status filter should have an example form (assuming that a script named FILTR.BAT is placed in the C:SCRIPTS directory
C:SCRIPTSFILTR.BAT "Configuration Manager security auditing" %msgid SuccessAudit "%msgdesc"
Results:
The creation of a collection results in a status message, recorded in the log with a given name in the form:
Concluding remarks.
- Although the log name can be longer than 8 characters, but the identification meaning of the log is only the first 8 characters of the name!
- There is a whole set of parameters that can be passed in filters (not just %msgid and %msgdesc). It is worth taking a look at the summary in Technet (https://technet.microsoft.com/en-us/library/bb693758.aspx)
- Why is there a PowerShell command in the script and not a call to the built-in EventCreate program? EventCreate forces you to use an EventID of up to 1000, while most Configuration Manager events have four-digit event codes... Fortunately, Write-Eventlog does not have this limitation.