Sawta's questions

I am using BigFix in an Enterprise Environment and noticed a recent round of Microsoft patches for 2016 have failed on a small group of assets. I was able to work around this by creating Custom Copy Fixlets, using modified relevancy, however the relevancy that I had to use was not always consistent, even though most of the files were all located in C:\Windows\Sytem32.

For example: MS16-031 - The criteria that my scanning platform is looking for, is based off of the version number for Ntdll.dll. I create a Custom Fixlet with Relevance:

((version of x64 file "C:\Windows\System32\Ntdll.dll") as string) < VersionNumberGoesHere

This worked great, as I had created an BigFix Analysis previously looking for Ntdll.dll using relevancy:

if (exists x64 file "C:\Windows\System32\Ntdll.dll") then ((version of x64 file "C:\Windows\System32\Ntdll.dll") as string) else "Does Not Exist"

I was able to confirm that relevancy for the Custom Fixlet was just about spot on with the Analysis. For some reason, it's not a mirror image of the two, but it's extremely close and the Custom Fixlet list's all the machines that are flagged in the scan results, so I'm happy with it.

The problem arises here: For some files in C:\Windows\System32, I have to use an entirely different syntax to get the correct version number information I'm looking for based off of scan results. That is, I can use the method listed above, but the version information it will give is not even close to what the scanner is looking for. If I were to use the above listed method, assuming the scanner is looking for something like "Version Number 6.1.7600.16385", the results I would see would instead read "1.1.11302.0". It would still be some sort of apparent version numbering, but not at all similar to the type that my scanning platform is referencing.

For example: MS16-027 - To find the file version information for mfds.dll for the analysis I had to use:

value "FileVersion" of version block 1 of file "mfds.dll" of system folder

For the Custom Fixlet, I had to use:

value "FileVersion" of version block 1 of file "mfds.dll" of system folder != VersionNumberGoesHere (OSServicePatch_gdr.LongStringOfNumbers)

I have done a bit of reading on Action Script syntax for BigFix and it seemed like x64 file (command) vs. file (command) can lead to different results based on the pathing for 32-bit systems vs 64-bit systems, however, I thought that would only apply for files located within C:\Program Files and C:\Program Files (x86)? Is that not the case? If so, where is the 64 bit version of System32 located and why are the results between the two so drastically different?

I'm planning on implementing a enterprise-wide solution in accordance with a workaround provided by Microsoft (CVE-2015-2423) and I would like to backup existing registry keys for each users machine before deleting the referenced items for future compatibility, and incase something goes horribly wrong.

I have the task ready to launch via Internal Distribution Software, but I'm at a loss for where these .reg backups should be stored on each machine. My initial assumption was in: C:\Users\Default\Documents but it doesn't seem quite appropriate as that's meant to be used more as a template for future user accounts, not as a storage space for .reg backup files. I don't want users to be able to access, or even see the .reg files so I won't be putting them into C:\Users\Public\Documents.

Preferably, there should be a directory that exists on all Windows images that I can store this in without having to worry about users finding it and poking around in there. I've considered making a new folder under say, C:\, but I'm hesitant of going to that level...it seems a bit much, and I'm assuming that something like this already exists for Windows and I'm just unaware of where it is.

I've consulted this article but the suggestion was pretty unhelpful:

To back up the registry by manually copying files, copy all files in Systemroot\System32\Config to removable media, a network share, or a compatible partition.

That would work if I were putting it onto a different device but I'm not...it's going to be stored locally on each Hard Drive. I want as few moving parts to this as possible in case I have to undo the work around down the road, if needed. Is anyone where of guidance for securing .reg backups, or is just kind of "follow your heart" and hide/secure it as best you can?

Update: There are several reasons why I'm trying to store these locally per-machine, rather than having say, a single copy of the .reg file stored on our Network Share which would be distributed on request. The main one is this: Unique registry values. That is, some of these machines have Visio, some do not. Some have Visio and Project. Some have neither. Depending on what Office products they have installed changes the number of keys they have. If I revert this action after words, and mistakenly add keys that a machine did not have previously, it might adversely affect a large amount of users Office products.

Additionally, I would also like to keep this somewhat generalized, so if I do need to do something similar in the future, I can refer to this same area to store additional registry keys for backup use.

On top of that, if I do need to use this for some registry fixes in the future, some programs generate randomly assigned key names or values. If I import a .reg key that does not match what the machine expects it to be, this could also cause serious issues.

I have recently been given Administrative rights to help maintain ePO on my companies network. From the group of machines that I am in charge of keeping up-to-date, a small amount of these machines do not have the proper McAfee Product information displayed in ePO.

I have remoted into these machines manually and checked the version numbers for these Products (VSE, Policy Auditor, HIPS, DLP, etc.) and they all list the most up-to-date information for those products, (example, HIPS 8.0.0.2239). I then open up the McAfee Agent Status Monitor Console and select "Collect and Send Props", "Send Events", "Check New Policies" and "Enforce Policies" to ensure that the agent is able to communicate with the ePO server without throwing out any error messages. Everything seems to register fine. When I log back into ePO and check the computer name in System Tree, the computer still shows an outdated version of that product number (HIPS 8.0.0.2151, for example).

I have tried to tag these systems with Uninstall/Reinstalls to fix the issue, and it worked on two machines, but there is still at least 20 machines that are not registering properly! I've tried this several different times over the course of a week now, giving plenty of time (at least 24 hours) between the uninstall and reinstall but the issue still remains in ePO.

I've done some searching online and see that other people have been suffereing from this same problem (link), but the only "solution" that has been repeated over and over was to uninstall/reinstall, which like I said before, is not working for some of my machines.

Any advice would be much appreciated.

I'm trying to change some security settings in Group Policy for Windows 7 x64 to comply with DISA STIG viewer; its flagging a lot of presets for the 2007 Microsoft Office Suite. When I attempt to navigate to the correct subfolder (Microsoft Office 2007 system (Machine)) in gpedit.msc, the location is mysteriously missing.

Example: Disable user name and password

I launch gpedit.msc, Navigate to Local Computer Policy -> Computer Configuration -> Administrative templates -> the folder "Microsoft Office 2007 system (Machine)" is not listed. I've checked the filter options and set them to "any" as well as disabling the filter. I tried to perform a Windows search for "powerpnt" and "pptview", which STIG said were related to the setting I was supposed to change and both searches returned 0 results.

Note: I'm still able to launch Powerpoint and the other applications just fine, so it doesn't appear to be a bad install.

I've already read threads: one, two and three and none of them seem related to the problem that I'm having.