Not so much a question but an FYI, In relation to 4-24039351261. We have been looking into various errors shown in the ENS Platform Error log and this one came down to injection, as if often does. Many pieces of software inject. Finding out why and stopping them from doing it is not easy. Simply blocking them is also not easy. From what I read in Trellix information, there is a bit of a disclaimer that says 'The product might not work if you allow the injection' but we have also found that blocking injections can lead to a corrupt install or future failure. Understanding exactly what might not be working in the product is not easy.
We have also discovered that the Platform policies do not update before the install of the actual ENS product unless you install the Platform on it's own first and do ASCI. Being that the ENS product install contains the platform, it is logical that you would allow the ENS product install to also install the platform first. However, because the platform policies do not update before the product install, you don't get any of your settings, like trusted certificates. So then you get things like injection errors...
So, I have been asked to raise a PER for that, even though if seems like a design fault to me.
Even if these errors could be ignored on install, how would you know they were related to installation? It takes some time to work that out. Time which most of us probably don't have. So you have to assume that certain injections can be ignored - a dangerous game. The key event ID is 34865. This can come for other reasons, but it is also an indicator of which machines have been responsible for populating those 'Trusted Certificates' you see in the Platform Policy. Beware though - the hash value shown in that event is the hash of the DLL and NOT the hash of the certificate itself. This does not help either and apparently I have to raise another PER to show the Hash of the certificate.
You Deserve an Award
