5 Replies Latest reply on Apr 7, 2016 12:27 PM by eobiont

    ScriptScan DLL has thousands of names


      I am trying to limit the addins that are allowed to run in my managed IE 11 browsers.  I will be creating a whitelist in GPO to only allow approved add-ins to run.

      I have the ability to collect a report of all the installed add-ins in my environment using ConfigMgr (SCCM) and am using that to build the whitelist list.


      In my environment there are thousands of different iterations of Scriptscan dll They look like those in the table below.  What is the purpose behind giving every instance of scriptscan its own name?  I am not sure if this is going to cause trouble for me or not in approving the addin.  It looks like they all have the same ClassID  and the same product name and version.   None of my other inventoried plugins behave this way.  Weird?


        • 1. Re: ScriptScan DLL has thousands of names

          Would moving this thread to either (ePO) or (VSE) give it more exposure/assistance?

          If so please apprise...


          All the Best,



          • 2. Re: Re: ScriptScan DLL has thousands of names

            I don't know how it ended up here at the root.  Yes, I sure meant to put it in VSE,  Thanks.

            • 3. Re: ScriptScan DLL has thousands of names

              Moved to (VSE) for better assistance

              You are quite welcome

              All the Best,


              • 4. Re: ScriptScan DLL has thousands of names

                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 .

                • 5. Re: ScriptScan DLL has thousands of names

                  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.