First a little bit of background. My current project has me working at a federally regulated power company. (We’ll call them PowerBiz for anonymity sake) They are also publicly traded and accept credit cards so to say they have to be secure is an understatement. They use a product called Bit9 as part of their protection strategy.
Bit 9 is a great product that is used for application white listing. However it is a resource hog and a bit difficult to work around unless constant care and feeding is performed. Part of that care and feeding is to keep it on the latest patch level as well as keep it “right sized” for your environment.
Now I have been fighting with getting a Win10 1803 image built for PowerBiz. As part of that build process PowerBiz wants to make sure that Bit9 is implemented the instant the image is laid down. to accomplish this, PowerBiz has set up their capture process to include the Bit9 parity agent installation and synchronization. This way there is never an instance of a computer being on the network without Bit9 installed. This is great saves me the trouble of having to build in wait steps to my imaging process. Not a problem Right? Wrong! as it turns out, PowerBiz is on an older version of Bit9. 7.2.3 to be exact. This version does not support 1803 much less even 1703. In order to bring it to a supported state, the Bit9 infrastructure would have to be raised to 7.2.4. Due to hardware constraints and the possible lack of knowledge regarding making hardware adjustments in a virtual environment, the bit9 infrastructure is not right sized for the current load and therefore would be directly impacted by patching. This means in summary that PowerBiz is not going to be updating their environment until they can go through the process of building out a NEW environment
Having said all that, the troubleshooting to discover the above was a bit painful. Nothing was being written in the SMSTS logs other than the task sequence failing with an obscure error code. However this error code led me to the true source of logging used in the “configure Windows” step, the Setup.etl logs. These logs though difficult to translate were a goldmine of information. I had to first translate these from the .etl to something a little more readable. this is where the command tracerpt setup.etl -of csv came in handy. This command converted the etl into 2 files, dumpfile.csv and summary.txt. The first file is where I found the gold. I did a quick search for the word “error” and came up with the following entries:
|“(c0000022): Failed to open child key: [Bit9]”|
|“(c0000022): Failed to process reg key or one of its descendants: [\REGISTRY\MACHINE\SOFTWARE\WOW6432Node]”|
|“(c0000022): Failed to process reg key or one of its descendants: [\REGISTRY\MACHINE\SOFTWARE]”|
These entries or variants of the were repeated numerous times in the setup.etl logs.
This find led me to a discussion with the Bit9 SME who followed up with Carbon Black to find out the above mentioned support status.
Long story short. Keep your critical applications updated so that they are always under support as well as allow support of OTHER critical applications.