Tim Eggleston

MOSS Powershell widgets (updated 2011-05-31)

1. Recycle bin flush
2. Clean old Choice column values
3. Document Library versions report
4. Delete all old versions
5. Deploy custom master page to all site collections

In my day job as a MOSS sysadmin, I'm often called upon to do or assist with various tasks which are either tedious or impossible through the web interface. Since it is possible to reference the MOSS libraries directly in Powershell, you can effectively write small console applications - utilising the full "under the hood" power and complexity - against SharePoint with nothing more than a text editor. This area serves as a repository for some of these scripts that I've written, both for my own future reference and anybody else's.

I have a fairly large library of these scripts but I have to put in some work to clean them up, genericise them and strip out the abusive comments, so this list is very much a work in progress.

Notes/Disclaimer

I am not a developer; I know just enough to be dangerous. Use these entirely at your own risk. Take backups prior to running, test in an isolated environment first, yada yada yada.

That said, all of these have been run in my production MOSS environment without any problems. If it didn't work in some obvious way, it wouldn't be here.

All scripts are written against MOSS 2007 Enterprise SP2; no guarantees of compatibility with anything else apply. This is especially true of SharePoint 2010, as the code has not been checked for forward compatibility against the 2010 object model. If you want to try, at the very least you'll need to update the reference to the Microsoft.SharePoint DLL. You should also make sure you're using Powershell 2, as some of the scripts use try/catch which didn't exist in PS1. If you're running on a version of Windows Server with UAC (i.e. 2008/2008 R2), you'll need to run these scripts from an elevated Powershell prompt (right click and do run as Administrator).

You can double-click on the code window to strip out the formatting, leaving a version suitable for copy-and-pasting.

1. Recycle bin flush

MOSS has a "two stage" recycle bin model; the first stage is merely a database flag, and deleting items to (or restoring from) this recycle bin is more or less instantaneous. To actually reclaim the space in the DB however, the items must be deleted entirely. This happens in one of two circumstances: either the retention period specified in Central Admin comes and goes, or the admin manually deletes the items from this recycle bin, which moves them to the second stage (another database flag, so a quick operation), and finally runs a permanent delete against the items, which will actually remove them from the DB.

I have found, in my environment where MOSS is a document management system, that large-scale deletions can cause the second stage recycle bin page to timeout before the delete process has completed for all the items. This is particularly true for big folders or lists of many GB; a few of these in one operation and unless you have a crazy I/O subsystem you can quickly exceed the 30s default page timeout.

This simple script alleviates the issue by doing the deletions via the object model, which will never time out. It's essentially a foreach loop, and it iterates through all the items in a query of the second stage recycle bin, deleting them as it goes. Note that by default it will only return 5000 items in each batch; if you need to, you can increase this number. Also note that you will need to manually delete the items from the first stage recycle bin beforehand, as this script won't do it for you as a safety measure (although it's certainly possible to do it in code).

Show/hide code

2. Clean old Choice column values

I wrote this script because we have some document libraries which use "choice" columns extensively. Choice columns are just string fields with a frontend that enforces selection of one of a number of allowed options (if it's a multivalue column, it just concatenates the strings with a semicolon separator). This works fine, until you need to delete one of the options: you can remove it from the picker frontend but not from all the items in the library which have already had that value populated.

This could have been made much more obvious in the UI by Microsoft, and is a pain when you are trying to use MOSS as a bona fide EDMS. I wrote this script to clean up after these kinds of mistakes corrections had been made.

Show/hide code

3. Document Library Versions Report

This script generates a simple report of sorts, which is suitable for identifying frequently-updated or very large files (or worse, files where both apply), where frequent versioning may be contributing to excessive storage utilisation. It is run at the document library level, and dumps out basic information about all the files contained within, irrespective of folder structure. The script is specifically written to be lightweight and performant (it must be capable of running against document libraries with hundreds of thousands of items in my environment), which is why the dataset returned is so basic. If you have the RAM, increase the $query.RowLimit value to allow the script to process more items in one go before going back to the database.

The output is built to be importable into Excel as a CSV (comma-separated values file) by > redirecting the output.

Show/hide code

4. Delete all old versions

One of the weaknesses of the MOSS (well, WSS) version control model for document libraries is that it defaults to "keep everything forever". This is definitely the safe choice, however it is definitely also a compromise, because it makes some assumptions about your use patterns that you may not fully understand in your haste/excitement to deploy SharePoint. For one thing, if you deploy both major and minor versions, will the users understand the difference - and, more importantly, will they actually use the Publish to Major Version functionality? Because if they don't, even if you've remembered to set limits on the number of versions to retain, the rules will never actually kick in, because they are all predicated on there being at least one major version.

Worse still, if you subsequently realise what's happened months or years down the line, it'll break your heart to find out that even after you put the rules in place, they only take effect the next time each item is modified. This exact situation happened to us, and in a library of 10,000 items, each one having 20-50 versions of up to a megabyte each, it was causing totally unnecessary storage headaches.

The below script is really simple, and just executes a method through the object model which deletes all but the current version of each item in a view of a document library.

Show/hide code

5. Deploy custom master page to all site collections

Got a custom master page? Great! Got it wrapped in a solution and triggered by a feature for deployment? Even better! This script will automate the process of pushing out your custom master page (and site logo) to every site collection and web starting at the root and working all the way down (or up, I suppose). I run it every night to ensure that all new sites created through the day pick up our custom branding without any effort necessary from the users. In my environment, that kind of delay (up to 12 hours for a site created early in the morning) is acceptable; if you run a high-traffic Intranet or publically available site, it may not be. But if that's the case, you probably won't be using this kind of ugly hack anyway!

If you have a custom master page, but no solution and no idea how to make one, fear not; you can do it pretty simply with nothing other than a text editor and makecab.exe. You do however have to understand how solutions and features work under the covers, which is something I can't go into here. This is a good starting point, and this applies it to the subject of master pages specifically.

Show/hide code