Some customers started seeing NSE files under C:\windows\system32\inetsvr folder.
In some instances, they found under this folder over 2 million NSE files. Most of those were from the last three months.
The issue here is that because of the number of files in the inetsvr folder, the SMP Console has become unresponsive or even inaccessible. In order for them to
do anything (like using the Console), they started deleting these NSE's from c:\windows\system32\inetserv.
The issue is about applying our permissions for the NSE folders, not checks for NSE files themselves.
Each time, when IIS applications start and go to use NSE (agent web app, that delivers it) it makes sure that we have our folder structure ready on disk to keep NSE there.
During this check, we force it to create and reapply all required permissions (for IIS and NS App Identity user) for these folders.
This should be blazing fast, and always was - but for some reason, it's not on some systems anymore. And when it fails, there was a bug, which set the folder to be "" (empty string), not trying anymore, and this will put incoming data effectively under the IIS folder (inetsvr).
These folder manipulations are done under 'lock' in the code, so parallel threads in the application have to wait for the first one to complete.
And it (the first one) took too long to set permissions, which we don't really need at all.
This issue has been reported to Symantec Development team. A fix has been added for the Cumulative ITMS 7.6 Post-HF7 (see INFO3459 for SMA_SMF_SMP_7.6_POST_HF7_P2P zip file version 12 or later)
What we've done is :