One of our Console Operators contacting me this morning.
The TEM Agent is reporting that the system needs MS13-004 (Fixlet ID# 1300409). But Add/Remove Program reports that the patch has already been installed. When they open Microsoft’s Windows Update site, no patches are needed on the server. When I logged into the server and looked under Add/Remove programs (Show Updates), I can see that an update with the correct KB number has been installed on the server already.
Has anyone else seen any issues with this fixlet? In looking at the Relevance for it, it seems to be relying on registry information for Local System (S-1-5-18) for applicability. On this server there were 3 additional SID’s listed under the Installer\UserData key. Two of them returned errors when the relevance clause was modified to look in them, and one of them returnd False.
It should go without saying that QnA returned True when pointed to the Installer\UserData\S-1-5-18 key as in the Fixlet.
Any one have any suggestions? It looks like the Patch has been applied, but TEM is not detecting it correctly because the patch was not run by System, rather it was run by a Domain user account, hence the different SID.
I had the Console Operator try pushing the fixlet to one of the computers, and it ran successfully and shows that it is now fixed, but I still think the relevance clause needs to be looked at, unless the patch truly needs to be INSTALLED by System to take effect.
Thank you for letting us know your concerns on this.
To your question “unless the patch truly needs to be INSTALLED by System to take effect.”, frankly speaking, this is really hard to tell, unless there is some public information specified in KB web page. I guess normally we take granted that as long as the patch is installed successfully by admin level account, it should be fine.
I would like to explain more.
When we are authoring our content, our goal is to help our customers automate the patching process. So the fixlet behavior should be align to the installer itself. That’s to say if the installer could be installed, then fixlet expected to run successfully on target machine.
Another point is that, if we modified the fixlet to make it not relevant on target machine, but the installer can be installed anyway. Customers may have doubts that why the installer can be installed but fixlet is not showing relevant. Will this leave the machine in the vulnerable state? After taking serious consideration and also based on the data from L3 support tickets, we will let the patch install in order to keep the same behavior as the patch installer itself. Hope the information helps and thanks for your kindly understanding!
Back to this issue, sometimes the IT environment can be quite complex. So I suggest you may contact our support guy and we can continue our investigations with further information from your IT system.
My comment was really that the relevance clause was ‘inaccurate’ in that it was showing that computers needed the patch, when in fact it had already been installed on the computer. The portion of the Relevance that looks at the UserData was only looking in the “Local System” SID portion for evidence of the installation. In this case, the patch had been installed by a Domain User (local administrator rights) and as such, the evidence of patch installation was stored under their SID, and not correctly detected by the Relevance clause.
Granted, if TEM/BigFix installs the patch, since the Agent runs as Local System, the installation evidence will show in the location that the patch is looking, but that’s not the point. The point of the relevance clause should be,
We also seem to be having the same issue. All of our patches are applied via WSUS server automatically at schedule times. By process we have removed and manually installed the offending patch on a test server and that allowed the system to drop of the report.
The fixlet debugger seems to be reporting an issue with one of the relevance settings, any ideas where, how or when this will be resolved