Would moving this thread to either (ePO) or (VSE) give it more exposure/assistance?
If so please apprise...
All the Best,
I don't know how it ended up here at the root. Yes, I sure meant to put it in VSE, Thanks.
Moved to (VSE) for better assistance
You are quite welcome
All the Best,
You'll notice the file contains a timestamp, which provides it a unique name - at least in the context of that system where the feature is installed.
In the past the DLL had a single name, reused in subsequent updates or upgrades; and that imposed limitations for us. Most notable, that we could not upgrade the feature oft-times without requiring a reboot (or closing the process we were loaded in).
It's a requirement that our software avoid reboots wherever possible.
One way to achieve that was to ensure the file for ScriptScan was unique, new each time the component is installed or upgraded.
The user story you present here is a good one, something new for the team to consider and perhaps revisit the design. But it needs to be heard by Product Management and is ultimately up to them to steer/shape the product's future. I'll pass this thread along to them .
Thank you Warren.
While this is not too great for reporting on IE Add-ons that are installed, I have found that the GPO for listing allowed Add-Ons is governed by ClassID of the add-on (only). It looks like all of the thousands of Scriptscan DLLs all have the same ClassID - so I should be OK for the end goal of managing the state of this add-on, and will just need to do some SQL SSRS magic to replace the file name with something generic so the Select Distinct can combine all those rows into one line.
Why Intel has chosen to do things this way makes perfect sense - thanks for the explanation.
With IE 11, users have a lot of freedom to disable Add-ons by default, so it realty is important to have a list of add-ons like scriptscan that we want to prevent end users from disabling and set them to force-enabled.