Way to find out the creator of a share in Windows

We counsel Customers to "scorch the earth" and start fresh, oftentimes.

I have yet to see a good solution that works that doesn't involve have non-IT stakeholders involved. The best scenario I've seen yet is a Customer that has had management identify "stewards" of various data areas and delegated control of the AD groups that control access to those shared areas to those "stewards". That has worked really, really well, but has required some training on the part of the "stewards".

Here's what I know doesn't work:

• Naming individual users in permissions. Use groups. Always. Every time. Without fail. Even if it's a group of one user, use a group. Job roles change, turnover happens.
• Letting non-IT users alter permissions. You'll end up with "computer Vietnam" (the parties involved have "good" intentions, nobody can get out, and everybody loses).
• Having too grandiose-ideas about permissions. "We want users to be able to write files here but not modify files they've already written", etc. Keep things simple.

Things that I've seen work (some well, others not-so-well):

• Publish a "map" indicating where various data types are to be stored, typically by functional area. This is a good place to do interviews with various departments and learn how they use file shares.
• Consider "back billing" for space usage or, at the very least, regularly publishing a "leader board" of the departmental space users.
• Did I mention naming groups exclusively in permissions?
• Develop a plan for data areas that "grow without bounds" to take old data "offline" or to "nearline" storage. If you allow data to grow forever it will, taking your backups with it to infinity.
• Plan on some kind of trending for space usage and folder growth. You can use commercial tools (someone mentioned Tree Size Professional or SpaceObServer from JAM Software) or you can code something reasonable effective up yourself with a "du" program and some scripting "glue".
• Segment file shares based on "SLA". You might consider having both a "business-critical" share that crosses departmental lines, and a "nice to have running but not critical" share. The idea is to keep the "business-critical" share segregated for backup/restore/maintenance purposes. Having to take down business to restore 2TB of files from backup, when all that was really needed to go about business was about 2GB of files, is a little silly (and I've see it happen).

It's more dependent on bandwidth and latency (especially latency) than it is on the number of files and scaling in the algorithms being used to enumerate the directory. There is no "magic number", I guess, is what I'm saying.

The SMB protocol is hideous for requiring lots and lots of round trips. That number of files, with double the latency, would be many times more than twice as slow, for example.

You've done the benchmarking by accident for your LAN, your network infrastructure's latency, and your server computer's IO subsystem latency. You've obviously found a "magic number". I'd get that directory pared down until performance gets better. There's no other way!