When doing test migrations or otherwise coordinating multiple environments, it’s sometimes useful to create a list of files modified since a cutoff date.

PowerShell makes it easy:

Add-PSSnapin Microsoft.SharePoint.PowerShell

$dateCutoff = "2015-01-01"
$spQuery = New-Object Microsoft.SharePoint.SPQuery 
$spQuery.Query = "<Where> 
 <FieldRef Name='Modified' /> 
 <Value IncludeTimeValue='TRUE' Type='DateTime'>" + $dateCutoff + "</Value>
$spQuery.ViewFields = "<FieldRef Name='EncodedAbsUrl' /><FieldRef Name='Modified' />" 
$spQuery.ViewFieldsOnly = $true

Get-SPWebApplication | Get-SPSite | Get-SPWeb | ForEach-Object { ForEach ($list in $_.Lists) { $listItems = $list.GetItems($spQuery); $listItems | ForEach-Object { $_['EncodedAbsUrl'] + " (" + $_['Modified'] + ")" } } }

Have you ever come across a SharePoint installation that’s been customized in an unsupported way? You look at the 12 (or 14) hive and see that files have been modified by hand? Not good.

As you may know, changing core SharePoint files is unsupported and can lead to problems when patching.

The best way to clean up modified SharePoint installations is to pull out the customizations and move them into new files as part of a solution package (WSP file). That makes it easy to re-deploy customizations and ensures your environment will stay clean.

Re-packaging most files is easy, but CSS can be very tricky to pull out the customizations. What if somebody went in and modified a few random styles (e.g. changing a color attribute or border width). Tracking those down by hand is tedious and error-prone.

Enter CSSCompare

For situations like these, I wrote a tool called CSSCompare which is hosted on CodePlex. CSSCompare will look at two CSS files and output the effective differences between them.

With SharePoint, you can take your customized version of Core.css (or other customized CSS file) and find the differential from an uncustomized version of Core.css by running:

CSSCompare.css -v1 CustomizedCore.css -v2 OriginalCore.css > MyCustomStyles.css

You can then add “MyCustomStyles.css” to your solution and replace your customized file with its original version.

Other Uses

CSSCompare works with any CSS files, so it can be used in non-SharePoint scenarios as well. I’ve started using it in version control situations to quickly determine changes between styles.

SharePoint deployments succeed or fail based on adoption and adherence to business goals, not technical functionality. It doesn’t matter how pretty your SharePoint site is or how many features you pack in. Perception is reality, and if people don’t perceive value, it’s failed.

Along those lines, communications planning is paramount for winning hearts and minds. Whether deploying a small upgrade or embarking on a transformational change from another system, engaging end-users early and throughout is the most important ingredient of success.

With that in mind, I’d like to offer a checklist of topics to consider during any SharePoint project. There are more comprehensive guides available (I particularly recommend “Essential SharePoint 2010″), but this primer should get you on the right track. I’ve mapped the steps to Prosci‘s “ADKAR® Model”, a goal-oriented framework for Organizational Change Management. If your business has an OCM framework, the same steps should apply regardless; if not, I recommend ADKAR as a starting point.

  1. Gaining Awareness
    1. Designate an “Awareness Team” of all impacted business users
    2. Catalog potential objections to change
    3. Discuss project objectives with Awareness Team
    4. Review key SharePoint workloads with Awareness Team
    5. Recruit a “Design Team” for interested parties to share input
  2. Driving Desire
    1. Communicate outcome benefits to all stakeholders via multiple channels
    2. Provide targeted demos to Awareness Team
    3. Solicit feedback via focus groups with Design Team
  3. Spreading Knowledge
    1. Train SharePoint IT operations teams
    2. Educate end-users via one or more channels:
      1. Videos
      2. Classroom training
      3. Training manuals
      4. Wikis / knowledge bases
      5. Power user groups / communities
  4. Fostering Ability
    1. Deploy SharePoint solution
    2. Proactively check in with affected users
  5. Ensuring Reinforcement
    1. Enact governance plan
    2. Incorporate SharePoint training into onboarding training plans
    3. Require training before receiving sites / administrative rights
    4. Regularly survey for feedback
    5. Foster Power user groups / communities
    6. Start small; focus on quick wins

How many versions of a typical document do you need to keep? 5? 10? 100?

SharePoint content databases often get cluttered with redundant versions of the same documents. In some cases, I’ve seen presentation libraries with less than 10 GB of active content, but hundreds of GBs of content due to gradual changes.

If you’re ready to clear out old versions, SharePoint’s Management Shell makes it easy. The script below will iterate through all lists and update them to keep only the last 2 copies. It will also loop through and delete unneeded versions.

Get–SPWebApplication | Get–SPSite –Limit All | Get–SPWeb –Limit All | ForEach–Object { ForEach ($list in $_.Lists) { If ($list.EnableVersioning –eq $true){ $list.MajorVersionLimit=2; $list.Update(); ForEach ($item in $list.Items){ $item.URL; $item.SystemUpdate() } } } }

You can see that it…

  1. Loops through all web applications
  2. Loops through their site collections
  3. Loops through their webs
  4. Loops through their lists
  5. If versioning’s enabled, it sets the major version limit to 2
  6. In order to remove old versions, it needs to loop through each item and perform a system update

The script can be easily amended to deal with only specific site collections / libraries. To keep a different number of versions, modify the MajorVersionLimit variable above.