Some Limited Windows Installer Event Information via Compliance Setting

I hesitated to blog this particular compliance setting for two reasons.

#1: the script inside could potentially (unlikely but it COULD) open an instance of a local exe (wevtutil.exe) and not close it properly.
#2: This is very 'big brother' like; it's got nothing to do with maintaining a system and keeping it healthy, and is completely about some governing body / management team wanting to point fingers.  If the user "sherry" isn't supposed to be installing things, then don't let "sherry" have local admin rights. Don't point fingers later.

With that said, use this baseline at your own risk, and I make no promises about it at all.  It's on shaky ground for how useful it is, and how reliable it is.  For example, I would NEVER tell Management "why yes, we can 100% get that data for you."  You would instead have to make it VERY clear that "this data is unreliable, and we may have to disable it at any time, but we can run it for a (week/month) and get you some data to prove that you really need to work toward removing local Admin rights to <some group of people>, but then we should disable it, we shouldn't keep it enabled forever."

Step 1: Attached --> Here <-- are two files, in your Console, Compliance Settings, import the "EventLogWindowsInstallerInfo.cab" by right-clicking on Configuration Baselines, Import and pointing to that Cab file.  Deploy that baseline (monitor only, no remediation needed) to a pilot collection of computers to verify, and once verified, deploy it to the correct target collection (whatever correct means to you).

Step 2: In your console, Administration, Client Settings, right-click properties on Default Client Agent, Hardware Inventory, Classes... Import... the file "To_import_into_Default_Client_Settings.mof"  The reason to import that file vs. browsing to WMI and selecting the class from a client which has this new custom class is because this mof to be imported has a custom name for the table and view; "hopefully" people, when looking at the console for collection queries, will NOT want to use this data for creating a collection--it makes no sense to do so.  This data should be used for reports only, and never to build a collection.

Various notes and caveats about the script inside the Compliance Setting.  It relies on data regarding Windows Installer installations reported to the Event Log.  With that in mind, if you have EventLog management policies or practices which clear the event log or your event logs quickly roll over, the data may simply not be there to be gathered.  Only Windows Installer events which resulted in a 0 or 3010 return code (a success, no errors or failures) will be gathered.  When I built this originally, the point was to "find rogue users installing things instead of using ConfigMgr", so only if a username is associated with that 0 or 3010 Windows Installer entry, will it be recorded.  The script inside relies on wevtutil.exe being available in %windir%\system32--if it's not, the script just exits and does nothing.  So as you can see there are several ways and places this routine is only marginally reliable.  Again--USE AT YOUR OWN RISK, and CAREFULLY explain to management (who are likely the ones asking you for this information) how unreliable it is or could be.  It is NOT foolproof by any stretch of the imagination.

To confirm, on your pilot box(s), confirm that the Compliance Setting Baseline has run, and that Hardware Inventory has run since receiving the updated hardware policy, and since running the Compliance Setting.

Potential sample report... You don't really care about installs from 'NT AUTHORITY\SYSTEM' (because that's either ConfigMgr or some other approved process), so you really just want those event where it's NOT that username.  If you have other "approved" user IDs you could also exclude those.

select s1.Netbios_Name0, rii.InstallDate0, rii.InstallUser0,
rii.Manufacturer0, rii.Name0, rii.Version0, rii.ScriptLastRan0
from v_GS_ReportOnlyInstallInfo0 rii
join v_R_System s1 on s1.ResourceID=rii.ResourceID
where s1.Netbios_Name0 like @ComputerName
and rii.InstallUser0 not in ('NT AUTHORITY\SYSTEM',s1.Netbios_Name0 + '\SomeLocalAdminIDWhichIsKnownToBeOK')
order by rii.InstallDate0 desc

Which if I run that against my lab CM12 server, some account called "TheAdmin" was installing stuff (see below).  It would be up to a human to determine if whatever "TheAdmin" was installing was acceptable or not to be doing that.  In this case, yes, it's acceptable--some account had to install the elements of R2 and Cumulative Update 1 for R2 onto the CM12 server.  As a human, I know that particular account isn't a domain admin, and has been granted rights to that server via the local Administrators group on that server--but nowhere else.  So it's acceptable use--but again... only a human can make those logical determinations.  Note that there's no indication of anything being installed prior to March.  The log on the server had rolled, and windows installer events prior to March 2014 simply weren't there to be gathered.