Video Screencast Help

Performance issue moving/deleting files/folders on Notification Server

Created: 05 Jun 2013 | 3 comments

Hello together,

I'm having an issue with the Windows server running Patch Management Solution.
With 2 Languages enabled and the most Microsoft Patches enabled since 2007 I have got round about 8600 updates inside the Patch Management Solution active. This results in also having 8600 SMB Shares in the operating system.

If I'm trying to move or delete a folder or a file it takes round about 20 seconds until the action is completed. During this time one CPU core is on full load by the server service. (I'm expecting that the system is checking if this file or folder is opened over a network share).

I'd like to ask if anyone of you see the same behaviour or allready done a investigation ?

Greetings Chris

Operating Systems:

Comments 3 CommentsJump to latest comment

Roman Vassiljev's picture

Hello Chris,

Could you please clarify what do you mean under "move or delete a folder or a file "?
Are they moving or deleting using Console settings and tasks?
Please be aware that in case if file is moved or deleted manually from Windows File System or virtual directory is modified manually in IIS manager, most probably it will cause incorrect behaviour in the future because of inconsistency between database and physical files.


ChristophMueller's picture

Yes... I mean moving or deleting a file in the Windows File System. Even if I try to delete a folder in the My Documents Library which is definitly not shared I'm having this behaviour.

I'm expecting this issue because the high amount of SMB shares (round about 7000) on the system because the high CPU load is produces for the server service. I only published the HTTP codebase. SMB is not used. Is there maybe a way to disable the SMB share creation for a package?

Does someone else having such an amount of SMB shares on his system?

Arthur Prosso's picture

Hello Christopher!

I assume you are doing folder deletion/renaming/moving using the tradition Windows Explorer UI.

Yes, we observe the same  situation on environments with several thousands of UNC shares.

Our preliminary investigation has shown (we have not yet received an official confirmation from Microsoft) there seems to be an issue with the Explorer.exe executing folder rename/delete/move operations on the systems with large amount of UNC shares.

Other file managers like cmd.exe or Far Manager do not cuase any delays on the same systems for the same operations.

So as a temporary workaround I would suggest to use other file managers if the issue is really bothering.

Thank you!