NSE's are been saved under c:\windows\system32\inetsvr folder

book

Article ID: 170474

calendar_today

Updated On:

Products

Management Platform (Formerly known as Notification Server)

Issue/Introduction

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.

Cause

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.
 

Environment

ITMS 7.6 HF7

Resolution

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 :

  1. Only apply permissions for the folders on our system services, like the main one and event receiver.
  2. IIS applications will ONLY apply permissions if there was no folder before, so it's not going to do it at all (except one time, when we install by SIM)
  3. The folder infrastructure checks are not under lock anymore, so all the HTTP requests will initialize concurrently since it's going to be fast (folders are there for sure), they need no locks.