One of the companies I work for is very conscientious about the amount of resources used in their development and QA environments.  They also like to have their SDLC farms as close to production as possible without having to take up additional space that comes with a production farm, such as versions and audit data.  We can usually get a copy of the production database to mount to our SDLC farms, but we don’t need to take up all that space if we don’t have to.

Removing versions from the farm is explained here:

It is a pretty straight forward command to limit/remove the number of versions on lists that have the feature turned on to one copy of the previous version where applicable.

Now another set of production data we don’t need is the auditing data.  In order to remove this I use the following script, where the $user is set to your login ID as the Site Collection admin:

$user = "<doman\user>" foreach ($site in get-spsite -Limit ALL) { if (($site.Owner.UserLogin -eq $user) -OR ($site.SecondaryContact.UserLogin -eq $user)) { Write-host 'Deleting audit data for site: ' $sc.URL $i = -350 do { Write-Host $site.URL ' - Delete day ' $i ' : ' ([System.DateTime]::Now.ToLocalTime().AddDays($i)) $site.audit.deleteentries([System.DateTime]::Now.ToLocalTime().AddDays($i)) $site.audit.update() $i++ } while ($i -le 1) }

$site.Dispose() }

The reason I check to see if I’m a site collection admin is that the Farm also includes mySites, so when run on a site where the $user is not a Site Collection admin we’ll end up getting an ugly red warning about permission denied.  The reason I loop through each day is so that the delete is quick and if I have a farm with a lot of auditing turned on the transaction logs won’t choke and run out of room.