Dumping ground for useful (and otherwise) IIS related scripts. YMMV.

What's Here?

TristanK's IIS Crudware. Don't assume there are no bugs; assume I tested these to the point of "it works on my system" and if you're lucky, maybe a couple of others.

Takes IIS Log files associated with a website, and archives them. Optionally deletes Older-Than-X files too.

Tries to work out what log files live where automatically, from IIS config.

I suggest running without -RemoveOldLogFiles and -RemoveOldArchivedFiles - at least until you're comfortable with how it works and handles retention. And have backups of your archives if necessary.

Designed to be run from a scheduled task each day.

Scans IIS websites, apps and vdirs for crufty files, and evil cruft like config backups containing passwords.

Produces .\Cruft.csv - full of interesting and cryptic information, like word counts of "password" vs "pass".

Categorizes cruft with severity based on confidence of the word appearing being evil. May enhance later.

Also identifies general sampleware based on names.

Cruft on a production web server is evil. It should not exist.

Cruft could be sampleware, unused libraries, old versions of things, previous apps stored in "v2" folders, readme files, sample.txt files, demo files which come with the developer package the dev just unzipped into the web folder and never cleaned up.

Do you have cruft? If you do have cruft, you should work out where it is, and how to get rid of it, before something becomes crufty and important and kills you.

• A web.config renamed to web.config.txt because there was already a .bak!
• Or a saved web.config file that was edited in notepad... and maybe also the .bak... and they became .txt too
• Or .xml files used for configuration information, but aren't .config files... they're .xml files... so...

.TXT and .XML file types are 99.9% considered servable static files by IIS. So if one of the above files

• or any sampleware for that matter - contains sensitive information - like a username and password - and someone manages to guess/infer the URL and request it, you're potentially done.

Backups shouldn't be stored in a servable content area. Keep 'em outside the site's wwwroot.

Related: https://blogs.technet.microsoft.com/tristank/2016/11/24/website-security-suggestions/