The Woz is Wrong: Content, Cocaine, and Clouds

Recently, Apple founder Steve Wozniak was quoted making dire predictions about the cloud:  “Horrible things” will happen in 5 years. He mainly referred to the loss of ownership rights.  But I have an different take:  You never really owned that 8 track anyway.

Stop a minute to think about this.  I was never privy to actual 8 tracks, but in 30-some years have lived through 3 major music formats, and a few minor ones:  tape, CD, mini-disc, and MP3.  I was never what you would call an aficionado, but most people I know re-purchased music during each of those formats.  Almost nobody I know listens to tapes or CDs any more, and almost nobody I know transferred from record to 8 track, or record to tape, or tape to CD.  (Plenty did transfer from CD to MP3)  Same for movies:  I remember standing in a record tape cd store in the mall thinking Laser Disc was going to be the format of the future.  But those Laser Disc and BetaMax owners never transferred to DVD, and I have a box of VHS now that will probably never be used again.  I know people re-purchasing their DVD collection as Blue-Ray now.  I am trying to transfer DVDs to disk, but even that is slow going, and quite possibly not worth the effort.  All that to say: the reality for most people is that the myth of this monumental media library that you own and pass on to posterity is a pipe dream.  Since recorded media began, you've never really owned content indefinitely, thanks to the progress of recording technology.

Now, it’s easy to think that humanity has finally arrived.  That the MP3 OGG and M4V AVI ISO stored on a CD DVD Hard Disk SSD represents the final epitome of recording formats.  From here on out, we own our music and our grandkids will thank us for preserving the 128-bit copy of Beasty Boys’ Rootdown.  Maybe so.  Or, maybe, we’re just like those star-struck hippie kids grooving to the 45RPM Beatles they just saved all week to buy.  Honestly, I really am torn:  I do like the idea of “owning” content, but when it takes hours to rip a DVD, and then terabytes of disc to keep it, I have to wonder if it’s really worth it.  Why _not_ just rent rights to content for $10-$20/month?

Add to that my growing curmudgeondry toward all things celebrity, and there’s a danger I go from non-aficionado to all out media non-consumer.  Why again would I pay 20 hard-earned bucks to own the latest Hollywood epic or must have single, and encourage some actor or musician telling me how to vote while I pay for his cocaine binge parties?  No thanks. What we need is less celebrity and more quality.  Start-up bands, open air concerts, and indie flicks. That is worth paying for.

But I digress. No doubt bad things will happen in the Cloud.  Amazon has gone down at least once.  Azure and iCloud probably will also at some point. But, then again, I know plenty of people that lost all of their photos and music thanks to “owning” it on their single hard disk with no backup.  I’d venture to say most data centers are more reliable than your home PC.  But for whatever bad happens in the cloud, Woz is still wrong:  “horrible” things have already happened.  My Hendrix CD sat on the car dash and got ruined in the heat.  My wife’s VHS collection of Little House on the Prairie will likely never be enjoyed by my daughter.  My Ace of Base tape cracked in my backpack. It turned out, these things weren’t that horrible after all.  Somehow, I managed to live through it, and to see a day where we feed our desire for music and video with a little Amazon, Netflix and Spotify.

Information Management Policy Recurrence (SharePoint Devilish Details)

Information Management Policy is one of those oft-overlooked features in SharePoint.  It can really help organizations keep content fresh, but like so much else in SharePoint, the devil is in the details.  Depending on the scenario you’re trying to implement, you may find some details causing confusion.

In one recent case, a customer asked for a solution that prompted users to review content that hadn’t been modified in 365 days.  Initially, this seemed straight forward. Set up policy to review every 365 days, like this:

But, reading the recurrence description made me think there may just be a devil lurking in this dialog.  So I wouldn’t have to wait a year, I set up a series of tests that expire in 1 day, with varying settings.  Based on those tests, here are some gotchas I learned.

The retention policy,  will _not_ recur just based on Modified date.   In the example above, the initial workflow will only occur once, as noted at the bottom of the dialog.  So if it kicks off after 365 days, and the user changes the modified date, it will not kick off again in another 365 days unless you specify a ‘recurrence’.  To me, this does seems counter-intuitive.  I expected changing the modified date to reset the clock for the recurrence policy.  But, I think the concept is that the item is flagged as having “expired”, and will never “expire” again, regardless of what actions the user takes.  The workflow option is more intended to move the document elsewhere, archive it, etc.  Still, by specifying recurrence of 365 days, you get the desired behavior: the workflow runs every 365 days.

The recurrence happens based on the _initial_ occurrence.  So, after the initial review kicks off, if you specify a recurrence period of 365 days, the workflow will run every 365 days from the time the document first expired, regardless of modified date.  Again, this is counter-intuitive to me.  I expected- and the customer wanted- the review to occur every time the document had not been modified in 365 days.  This is, in fact, the initial behavior: editing the document bumps up the initial occurrence.  But, once that first “expiration” happens, the recurrence will be every N days, regardless of changes to the document.

So, how do we handle this scenario?  It takes a little more logic in the workflow, but is not to difficult.  Simply set the initial occurrence to 365 days after modified date, but the recurrence to a more frequent period – say 2-4 weeks.  Then, add logic in the workflow to check the modified date:

This way, the workflow will be kicked off initially at 365 days.  After that, every 2-4 weeks.  But only if necessary will an actual review take place.

Bonus Powershell Timer Job Kick

Expiration Policy Processing occurs weekly by default.  If you ever need to test, or want to trigger processing at once, you can run the timer jobs in CA, or Powershell:

Get-SPTimerJob | ?{$_.Name.Contains(“ExpirationProcessing”)} |%{$_.RunNow()}

I didn’t find many specifics on how those settings played out, so I hope this is helpful for somebody (maybe me?) down the road.