With the release of StoragePoint 3.1 (...coming in October, public Beta available September 7th) we will deliver our Fileshare Librarian module.  It leverages the Shallow Copy Migration capability at the core of StoragePoint to import fileshare content into SharePoint without actually moving it.  Aside from being pretty cool stuff, it works incredibly well.  Incredibly well = millions of documents and terabytes of content cataloged in a day.  This is obviously a vastly superior approach compared with traditional Fileshare Migration solutions that carry the BLOB around as part of the migration workload and ultimately dump them in a content database.  And our Librarian (...go ahead, think of the old lady walking around the library cataloging the books and putting data on where to find them in a card catalog...it's a good analogy) doesn't just import the files, it creates a user-definable structure inside of SharePoint to hold it all.  You're not pointing a document library at a fileshare and everything lands in one doclib...you can make the destination a Web Application and it will start by creating site collections based on the top level folders in the fileshare, then sites, then libraries, then folders.  Start at a site and it will start with lists, then folders.  You get the idea.  You can also specify site and list templates (where applicable), including custom ones.  So if you want the libraries created a certain way just customize a library, save it as a template, and then select it when you setup the Librarian.  We also enable both "one and done" and "co-exist" usage scenarios. 

"One and done" is pretty straightforward.  You have a share, you want to get that content into SharePoint, turn off end user access to the fileshare, and have everyone access the content from SharePoint.  While the second scenario is not one we would endorse for use with a traditional "end-user-collaborative" (...dynamic, active, non-static, etc.) fileshare, the product supports it nonetheless.  You can run the Librarian on a schedule and it will recognize new files and catalog them accordingly.  I think this capability is more useful for a "drop folder" solution pattern.  We regularly run into customers that are dropping PDF files from a mainframe print stream (...think monthly statements for a financial services firm) to a fileshare and them importing them into a CM/DM solution.  The Librarian would accommodate this usage scenario quite nicely.

Still not convinced?  I took a fileshare with 100k items (over 2400 folders), 250GB in size, and cataloged it in 1 hour!  The resulting structure in SharePoint was 4 site collections (Finance, HR, IT, and Sales), a whole bunch of sites, an even larger number of libraries, and the rest being folders.  Seriously, it took 1 hour on a small farm with commodity hardware and storage!  The resulting content database (...it was empty to start) was under 5GB.  And this is where the size doesn't matter part comes in.  I took the same setup, quadrupled the size of the fileshare to 1TB (...without increasing the number of files) and it still took 1 hour...and the resulting content database was still under 5GB.  It could be a share full of GB+ ISOs or multi-100MB videos or spy satellite photos or UFO evidence (...each license of StoragePoint comes with a foil hat) ...it won't matter because the size of the content being shallow copied has no impact on the amount of time it takes to complete that process or the size of the resulting content database.  As a note, we're performing some larger scale tests this week on a beefier setup and will publish those results when they are available. 

One last feature that I personally like...Simulate!  You can simulate the process to weed out any problems before you run it for real.  This gives you an opportunity to condense folder and filenames that go beyond SharePoint's URL size limit and/or remove invalid characters and sequences in container and filenames.  You can also have the Librarian clean folder and file names automatically...it's an option.

While the Beta we are making available on September 7th is "public", we are limiting the number of folks that get access to it, so get your name on the list by sending an email to info@storagepoint.com.  It will be largely 1st come, 1st serve with existing customers and partners getting preference.  We'll also be firing up some webinars in the coming weeks to start demonstrating this capability, so stay tuned for that.

As far as licensing goes it will be licensed per WFE and for a very limited time will be included with the core StoragePoint license for no additional charge.  So if you're working on a StoragePoint purchase, wrap it up and get this for free, or if you need this capability but haven't engaged us yet an email to info@storagepoint.com can start the process.  You can also go to storagepoint.com and try our "sometimes live" chat or request additional information.

The StoragePoint team is pleased to announce the release of the StoragePoint PowerShell Extension Library for SharePoint 2007 and 2010.  This free add-on for StoragePoint 3.0 gives SharePoint admins the ability to manage endpoints, profiles, and jobs/agents within existing or newly created PowerShell scripts. 

The library comes with a command reference (both PDF and within PowerShell via Get-Help) that contains several sample scripts along with a sample script file for creating storage profiles for each site collection, content database, or web application in your farm.  It highlights the use of several of the StoragePoint cmdlets and is also very useful when setting up StoragePoint on a new farm. 

Profile and Endpoint Management

• Add-Endpoint
• Add-Profile
• Add-EndpointToProfile
• Get-EndpointExists
• Get-Endpoint
• Get-AllEndpoints
• Get-Profile
• Get-AllProfiles
• Get-AllEndpointsByProfile

Agent/Job Scheduling

• Set-OrphanBLOBCleanupJob
• Set-BLOBExteranlizationJob
• Set-BLOBRecallJob
• Set-BLOBMigrateJob
• Set-ArchivingAgingJob
• Set-ArchivingMetadataJob
• Set-ArchivingVersioningJob

BLOB Information and Migration

• Get-BLOB
• Get-AllBLOBs
• Move-BLOB

Examples of what you can do with the PowerShell Extensions...

Add a new storage endpoint
Add-Endpoint -epn MainEndpoint2 -adn FileSystem -conn "PATH=\\Server\blobShare\EP2;AUDITDELETE=False;BUFFERSIZE=8192;SHREDONDELETE=False;"

Take storage endpoint offline
$endpoint = Get-Endpoint -ep MainEndpoint1
$endpoint.Status = 0 
$endpoint.Save()

Displaying all endpoints meeting a certain criteria
$endpoints = Get-AllEndpoints | Where-Object {$_.Name -Like "*Test*"}
ForEach ($endpoint in $endpoints) {$endpoint.Name + " : " + $endpoint.Connection}

Creating multiple profiles using the same endpoint
# Add the common endpoint
Add-Endpoint –epn "Common Endpoint 1" –adn "FileSystem" –conn "path=\\NAS\COMMON"
# Get web app - there are many other ways to do this.
$site = New-Object Microsoft.SharePoint.SPSite("http://spsite")
$webapp = $site.WebApplication
# Iterate through all site collections in web app
foreach($sc in $webapp.Sites)
{
  $startfolder = $sc.RootWeb.Title
  $profilename = $startfolder + " Profile"
  Write-Output "Creating profile for: $startfolder"
  # Create profile
  Add-Profile –pn $profilename –ptype SiteCollection –sid $sc.ID.ToString() –eid "Common Endpoint 1" -EndpointStartFolder $startfolder
  # Cleanup
  $sc.Dispose()
}
# Cleanup
$site.Dispose()

Displaying all BLOB files associated with a SharePoint document
$blobs = Get-BLOB –doc "http://spsite/documents/123.tif"
ForEach ($b in $blobs) {$b.Endpoint.Name + " : " + $b.FilePath}

New Farm Setup Script
FarmProfileSetup.ps1 (2.68 kb)

In addition the the PowerShell Extension Library, we've also released our StoragePoint API for Version 3.  In addition to providing a .NET API for configuring StoragePoint and managing remoted BLOBs it also serves as a reference for the objects returned by some of the PowerShell cmdlets.  The PowerShell Extension Library or API Reference can be downloaded from our Support site under Downloads > StoragePoint > 3.0, with the PowerShell library in the PowerShell folder and the API reference in the Documentation folder.  If you are not a customer and wish to test out the PowerShell extensions or APIs as part of your evaluation of StoragePoint then please send a request to support@storagepoint.com for download instructions.  Once you have the bits you just add our library to your PowerShell session using the Add-PSSnapIn cmdlet.  To ensure that the library is loaded on subsequent loads of the PowerShell console simply add the Add-PSSnapIn command to your profile.  See http://msdn.microsoft.com/en-us/library/bb613488(VS.85).aspx for a reference on managing PowerShell profiles.  Once the library has been added you can use the cmdlets to configure StoragePoint or management BLOBs.

We will continue to expand the PowerShell Extension Library and our APIs in future releases with the goal of creating an entirely "headless" installation and configuration experience.  Among other things, this will enable partners to OEM or bundle StoragePoint with their own offering and instrument the installation and configuration of the solution without exposing our tooling.  If you find as you use the PowerShell extensions or APIs that something is missing for your use case then please don't hesitate to leave a comment or shoot us an email at support@storagepoint.com.

The Metalogix StoragePoint team is pleased to announce the 3rd major release of our SharePoint Storage Management solution.  This version marks a substantial upgrade in SharePoint storage management functionality over our own V2 releases and the BLOB Offloading, archiving, and appliance solutions on the market today.  The tiered storage and hierarchical storage management (HSM) capabilities alone give SharePoint customers a very compelling reason (i.e. “Storage Economics”) to move all their content in SharePoint.  Combine that with Metalogix’s expanding suite of migration tools and a SharePoint customer can confidently move their content from expensive, but most often underutilized legacy content management platforms and unmanaged content sources like fileshares to SharePoint. 

Chris Geier, StoragePoint Product Manager, and I talking about how StoragePoint is "blazing a new trail" in SharePoint Storage Management.

StoragePoint is much more than the entry level BLOB offloading solutions out there.  It doesn't break SharePoint or bust your IT budget like the big box archiving solutions out there with their legacy and unsupported stubbing methods.  And it doesn't present the ongoing support and maintenance challenges associated with hardware, especially hardware from a startup that hasn't established whether or not it's a viable business.  Don't take my word for it...consult our own SharePoint Storage Management Mystical Square.  The "Square" is obviously our own creation and we think it's a pretty fair assessment of the space, but you can obviously decide for yourself.

Storagepoint.com has also been updated with new content, so please check it out for more information.  We'll be pushing out additional content and making some other announcements in the coming days and weeks, so stay tuned.

You can register to attend a live overview presentation and demo of StoragePoint 3.0 every Thursday at 11:00am Eastern.  Ping us at info@storagepoint.com if you want to request a demo/presentation for another day or time.

You can also view recorded 3.0 demos on our YouTube Channel:

• SharePoint Version 3 Installation and Configuration
• StoragePoint Version 3 Basic Introduction
• StoragePoint 3.0 Archiving Functionality

Mark Brazeau (...the guy that started BlueThread with me almost 4 years ago) and the one who runs the StoragePoint business unit here at Metalogix got a new toy (...never seen anybody so excited about a camera before) early last week and wanted to try it out.  He's been wanting to get me and Chris on camera talking about our offering and how we see things for a while now and while I've been open to the idea the opportunity didn't present itself until last week when Chris was in town from Chicago...cue Mark and his new camera.  The result was some very lightly staged, but completely unscripted talk between Chris and I about what we do and how we do it. 

We do get into our thinking and approach more than most ISVs would, so some that view these will ultimately proclaim, "What are they thinking?". One of our sales guys saw a couple of these clips yesterday and wondered "is it wise to publish our playbook", to which I replied "you can have the other team's playbook, but if you don't have the talent to execute it then it's just a book full of meaningless X's and O's".  Another asked why we were giving up the secret sauce, to which I replied "everyone knows it's Thousand Island Dressing".  I firmly believe that the StoragePoint wanna-be's out there don't have teams good enough to execute our playbook and/or can't mix-up a good batch of the secret sauce even if they had the recipe...I can make a mean New York style pizza and can give you the recipe for that, but if you don't use San Marzano tomatoes in the sauce and you don't take enough time to knead the dough or let it proof then it's not going to be good.  It would be like replacing .NET with Java or Focus with "We've got an App for that"...it's not going to be good eats. Besides, these other guys have all used creative means to get access to our bits and copy-cat our features. Some have even gone as far as copying content from our website, verbatim, to their own.  We can spend a bunch of time trying to stop them from copying and stealing from us or we can spend that time earning the innovation award we got at SPC09...making sure they are always at least one reverse-engineered release behind us.  When y'all see StoragePoint 3.0 next Monday it will be clear where we're investing our time.

So onto the videos...

We loaded the videos into a playlist on YouTube.  You can view the playlist here: http://bit.ly/at5W5I

You can play the entire playlist starting with the 1st video here: http://bit.ly/9uNM9k

StoragePoint 3.0 Information

• Contact us at info@storagepoint.com if you have any questions or would like to request access to the Release Candidate.  We will not issue pre-release trials without full corporate contact information (Name, Title, Company, Address, Phone Number, and Email Address).
• Attend one of our weekly StoragePoint 3.0 Overview sessions.
• Follow us on Twitter for updates on new content (videos, whitepapers, blogs, etc.).
• Find us on Facebook @ www.facebook.com/StoragePoint
• Check storagepoint.com on June 14th for our new site.

This is personally one of my favorites for two reasons, 1) the absolute opposite is true and 2) StoragePoint has been architected from the beginning to handle this.  I love having the replication (or how do I create a replica?) conversation with customers and partners because they are always shocked how easy it is to do this with StoragePoint in place.  I regularly have a hypothetical conversation with a SharePoint admin or IT management type around the following scenario: We regularly take content from our production environment and refresh one or more of our pre-production environments for development, testing, or staging purposes. How do I move the content databases without them pointing back to my production BLOB stores?  The answer to this question is simple with StoragePoint.  It helps to understand that the BLOB References we hand back to SharePoint and that are stored in the content DB contain to pieces of information, one is an Endpoint ID (reference to the physical location of the BLOB store) and the BLOB ID (reference to the relative location of the BLOB within the BLOB store).  This de-coupling or abstraction of the physical location from the BLOB reference allows us to point the BLOB refs to a different BLOB store by simply changing the physical location of the BLOB store within the Endpoint definition.  So an admin can attach the content db from the prod environment into their non-prod environment (...or do a backup and restore), simply copy the prod BLOB store to another location, and change the Endpoint entry in StoragePoint to reflect the new non-prod BLOB store location.  Done!  No need to re-synthesize (...re-build) BLOB References.  No need to internalize and then re-externalize content.  This same "shallow copy" methodology can be used for other replication scenarios, whether they be batch processed or real-time.  You're just moving the list item information along with the BLOB Reference from a SharePoint perspective and using Windows DFS or some other replication capability to move the BLOBs.  The DR site has the same Endpoint definitions, the path (FileSystem adapter) or accesspoint/bucket/container/tenant (cloud Adapter) of each Endpoint definition is just different.

If you're looking at other solutions and replication is important to you, make sure they don't store the physical location of the BLOB in the BLOB reference because it will unnecessarily complicate or restrict certification and disaster recovery tasks if they do.  This seemed like the obvious architectural approach to us, but based on feedback from some of our customers and partners that evaluated other solutions along with StoragePoint it apparently is not that obvious a choice.  I tend to chalk it up to us being focused on delivering a best of breed solution that handles a wide array of real-world usage scenarios elegantly and simply rather than just flinging something out there in an effort to be all things SharePoint.

There will be more on this in a DR whitepaper we are releasing along with the RTM of StoragePoint 3.0 on June 14th.

StoragePoint 3.0 Information

• Contact us at info@storagepoint.com if you have any questions or would like to request access to the Release Candidate.  We will not issue pre-release trials without full corporate contact information (Name, Title, Company, Address, Phone Number, and Email Address).
• Attend one of our weekly StoragePoint 3.0 Overview sessions.
• Follow us on Twitter for updates on new content (videos, whitepapers, blogs, etc.).
• Find us on Facebook @ www.facebook.com/StoragePoint
• Check storagepoint.com on June 14th for our new site.

I've heard other vendors in the SharePoint storage space (i.e. BLOB Offloading, Archiving, and Appliances) claim that you can't run EBS and RBS at the same...I heard some folks from the self-proclaimed leader of all things SharePoint declare this a few days ago.  Those claims show a fundamental lack of understanding of how those technologies work and how they are implemented within the SharePoint OM.  Additionally, if you couldn't have them implemented simultaneously, how would you migrate from EBS to RBS once EBS is no longer supported (NOTE:  EBS is deprecated in SharePoint 2010)?  You going to take your farm down while you perform some complicated and long-running upgrade/migration process or worse internalize all the content that was externalized with EBS, unplug the EBS provider, start associating instances of an RBS provider with all your content DBs, and then externalize the content again?  Neither one of those options sound real appetizing or even viable, but that's what you're left with if you in fact can't run the two technologies side-by-side.

The fact of the matter is you can run them side-by-side.  The folks out there saying you can't do this simply do not know what they're talking about and to be perfectly frank there's a lot of that going around these days...and not just on this specific topic (...lot's of noise about how stuff works and how you should be scared of these technologies, but not a lot of facts to back it up...I feel a rant coming on, so I'll stop there).  The misstatements from folks that should know is at the same time amusing and frightening.  We get a quick laugh about it within our product team, but then you talk to a customer that is fearful about implementing the technology because they've been told there is no simple upgrade path or the vendor doesn't have a good answer and it's not funny any longer.

So here is our position on this topic: I can declare with absolute certainty that the two technologies can run side-by-side...we demonstrate this pretty much every day to somebody.  And as far as migrating from EBS to RBS, we've implemented a shallow copy migration capability into our 3.0 product.  So let's take the following scenario.  I'm customer X and I've implemented StoragePoint 2.2 in my MOSS 2007 farm and externalized all my content.  I'm now contemplating an upgrade to MSS 2010 and want to use RBS instead of EBS once I'm there because I'm concerned about the future supportability of EBS.  Here's how you would accomplish that with StoragePoint:

1. Upgrade from MOSS 2007 to MSS 2010
2. Upgrade from StoragePoint 2.2 to StoragePoint 3.0
3. At this point everything works and content is retrievable using EBS, which as previously noted is deprecated, but still supported, in 2010...DEPRECATED does not equal UNSUPPORTED.
4. Create Content DB scoped Storage Profile(s) in StoragePoint that "cover" the existing EBS profiles.  So if you have a bunch of site collection scoped EBS profiles, creating a Content DB scoped RBS profile will "cover" all the site collections within it.  If you have web application scoped EBS profiles, you would need to create a Content DB scoped RBS storage profile for each Content DB in the web application if you wanted to "cover" all the EBS-externalized content within that web application.
5. Run the Externalize job on the new Content DB scoped profiles.  A shallow copy migration between EBS and RBS will occur, transferring control of the externalized BLOBs to RBS.  Users can access the content while this is happening, no downtime has to be planned or incurred.
6. That's it!  No painful or long-running process.  No down-time.  No re-allocation of storage to account of content being internalized.

If you're looking at BLOB Remoting solutions and are concerned about 2007 to 2010 upgrades or future supportability ask the question..."how do you upgrade from 2007 to 2010?" and/or "how do I migrate from EBS to RBS?".  I would also encourage you to consider yourself a temporary resident of the fine state of Missouri and say "OK, SHOW ME!".  And with that in mind, I don't expect you to just take my written word for it, so we'll have a short video demo of this up on our YouTube Channel in the coming weeks...as we get closer to RTM of StoragePoint 3.0 on June 14th. 

StoragePoint 3.0 Information

• Contact us at info@storagepoint.com if you have any questions or would like to request access to the Release Candidate.  We will not issue pre-release trials without full corporate contact information (Name, Title, Company, Address, Phone Number, and Email Address).
• Attend one of our weekly StoragePoint 3.0 Overview sessions.
• Follow us on Twitter for updates on new content (videos, whitepapers, blogs, etc.).
• Find us on Facebook @ www.facebook.com/StoragePoint
• Check storagepoint.com on June 14th for our new site.

With the RTM of SharePoint 2010 I feel comfortable proclaiming that the days of traditional ECM vendors (i.e. FileNet, OpenText, and Documentum) are numbered.  The picture of a bunch of dinosaurs looking up to the sky as a big fiery ball bears down on them comes to mind and at the same time seems appropriate. These dinosaurs have prolonged their existence by adopting a wide array of co-existence strategies in a thinly veiled attempt to pigeonhole MOSS as a complimentary offering.  It is (…and has been since 2007) a viable alternative or replacement, something that has been proven over and over again by partners like the company I co-founded, BlueThread.  We took a great platform, filled some gaps, worked with some partners, and made it easier for organizations to adopt it as a true ECM platform.

SharePoint has most of the content management capabilities an organization needs.  Out of the box it delivers exceptional forms management capabilities and reasonable records management capabilities that are vastly improved with SharePoint 2010.  Add portal, collaboration, and business intelligences capabilities that you won’t find in any other CM/DM platform and an enormous partner community that fills any real or perceived gaps and it’s game over. 

And SharePoint’s approachability from an IT organization perspective along with the high rate of adoption within an end user community makes it the only viable Enterprise Content Management platform available today in my mind.  The expense and complexity associated with standing up and maintaining these legacy CM platforms prohibits them from being deployed enterprise-wide.  Not to mention the at times awful end user experience they surface…goes back to the primary co-existence strategy theme…use SharePoint as the portal to our repository.  These platforms are at best point (i.e. claims management at a healthcare insurer) or departmental (i.e. accounts payable) solutions.

So if I’m even only partially right, why haven’t more companies adopted SharePoint to manage all or least most of their enterprise’s content?  Why do we still see huge volumes of unmanaged contents sitting on file shares?  Why are organizations still putting their content in underutilized, yet highly expensive legacy content and document management solutions?  Why do they still fill file cabinets, filing rooms, and warehouses with a small forest’s worth of paper?  I did the traditional ECM thing for a 10+ years and have been doing the Microsoft SharePoint thing for going on 7+ now, so I think I know at least some of the reasons why.  So here I go, we’ll see how I do…

1. Microsoft has to rely on partners to deliver True or Total ECM.  As a longtime partner, I hear this one a lot.  Can someone please define what it means to be a True or Total ECM platform?  That would be like me saying, I’m a True American or a Total Italian.  To the guy working on the assembly line in Detroit I am probably a True American because I’ve never owned anything other than a GM, Ford, or Chrysler automobile.  But the guy working the line down at the Toyota plant in Georgetown, KY will very reasonably argue that the cars he produces are every bit American and would not give me “True American” credit for my choices.  Total Italian?  I like pasta, pizza, and Italian pastries from Sorrento’s Bakery in East Hanover NJ where I grew up…and my 3 boys are Nick, Vinnie, and Joey, but I’ll take a Cabernet over a Chianti most of the time and if Jersey Shore is about being Italian than I’m officially changing my nationality.  So what’s the lesson here…this assertion is all about perspective.  To some folks, SharePoint OOB will do what they need it to.  But if they want to scan documents they’re going to need something like KnowledgeLake, just like you’d need a Kofax or Captiva if you were going to implement FileNet.  If you want to do BPM (…not workflow…there is difference…one makes people more efficient…the other tries to remove people from the process) you’re going to need something like K2, just like you’d need Pega or Lombardi if you wanted to do more than what was offered OOB with the others.  And if you want to have short, near, and long-term storage options for your SharePoint content you’re going to need something like StoragePoint, just like you’d need Tivoli or some other hugely expensive solution if you wanted to do what StoragePoint does with FileNet or any of the others.  So with this in mind, maybe a) we can agree that SharePoint is not one size fits all and a company’s perspective and requirements will ultimately dictate how True or Total SharePoint is as an ECM platform and b) agree that complementary partner solutions are good and needed and not scary.  They should not be seen as evidence that SharePoint is somehow incomplete.  They exist to make SharePoint applicable across a wider range of solution patterns and usage scenarios, whether we’re talking about ECM or not.  They allow organizations to get more out of their SharePoint investments, which I think is good for everyone…the customers, Microsoft, and the partner ecosystem as a whole.


2. SharePoint is incomplete.  Somewhat related to #1, but not entirely.  This is more about the whole 80/20 rule as it relates to traditional ECM platforms…80% of the cost is represented by 20% of the functionality.  Microsoft is happy, and from my perspective rightfully so, delivering 80% of the functionality for 20% of the cost of traditional platforms.  It’s that difference that makes it the only True ECM platform on the market because it’s truly accessible enterprise-wide.  That other 20% of functionality is used by such a small percentage of the users within an enterprise that it normally can’t be cost justified.  By way of example, I worked with a large Blue Cross Blue Shield that was contemplating a move from Stellent to SharePoint and the Stellent guy (…I’ll talk about his kind in #7) couldn’t accept SharePoint as a replacement because it didn’t have this obscure set of features available out of the box or from a 3rd party.  This was a 20,000+ person organization.  Anybody want to guess how many people used these features?  Less than a dozen!  So the rationale for not replacing an expensive and highly underutilized legacy content manage platform with SharePoint was the needs of .06% of the organization’s employees.  If the job function of these people was mission critical and there was not an alternative approach to addressing their requirements then I guess you may have a justification, but there was nothing mission critical about what they were doing and there were several viable  alternative approaches using SharePoint’s out of the box capabilities and readily available 3rd party solutions.  The lesson here…most of what most of an organizations end users will need is there out of the box or readily available from partners…don’t allow the lack of highly specialized and often expensive functionality to hold you back.  In all likelihood that specialized functionality is making it harder and more expensive than it needed to be in the first place.


3. Anything that cheap can’t be any good.  I heard this for the 1st time about 5 years ago when I was presenting to the Chicago chapter of AIIM on SharePoint Content Management back in my KnowledgeLake days.  They loved the message, lots of nodding heads, and then the sales guy threw up a slide on what it all cost and the room broke out into laughter.  These folks were used to paying upwards of a few thousand dollars per user for a FileNet, just for document imaging…throw in workflow or records management and you were talking several thousand dollars per user.  So a message promoting the idea that you can do pretty much everything you’re doing in a FileNet in SharePoint + some add-ons for the cost of FileNet maintenance was so beyond belief that it amused the 100+ attendee audience we were presenting to.  To say the least it was an eye-opening experience.  As SharePoint has evolved and become more prominent in enterprises the cost of the traditional ECM platforms has dropped, but you still find this attitude from time to time, especially in large organizations.


4. Best Practices, Governance, and Information Architecture.  Folks are quick to dismiss SharePoint as an ECM platform because there are not well-established best practices, governance, and IA around ECM.  That is a debatable point in my mind…there’s actually a lot of information out there on these topics…granted, not all good, but there is plenty of knowledgeable folks having thoughtful discussion on these and other topics.  I will say that it’s equally debatable whether or not there are good best practices, governance, and IA available for all the other ECM platforms out there.  I guess the point here is if someone asserts that they are hesitant to implement SharePoint for ECM for a lack of the above, ask them to see the above for any of the others.  It’s just kind of a weak objection and I encourage you to call it out as such.


5. Conventional wisdom is that SharePoint doesn’t scale.  This is almost always asserted by analysts in the ECM space in one form or another. A lot of times it’s not such a definitive declaration, it’s more of an “at least we don’t think it scale” or “there is not enough evidence to support scalability claims” or something like that.  I think there is plenty of evidence to suggest that it scales quite nicely, both on its own and with the help of add-ons.  KnowledgeLake published a whitepaper a couple years ago that showed 10’s of millions of documents managed in a farm with all the content sitting in SQL.  It worked without issue.  Could they have scaled that out even further and more economically if they remoted the BLOBs with something like StoragePoint…most definitely yes, but that’s more of a storage cost and to some extent a SQL cost consideration rather than a question of the architecture’s scalability.  That being said, there are definitely performance and scalability improvements to be had when you remote the BLOBs from SQL, especially with bulk (…think mail room scanning or customer statements imported from a mainframe AFP stream) operations.  So analysts, naysayers, and the dude from OpenText that calls it ScarePoint every time he does a presentation (…you know who you are), stop hiding behind a perceived lack of evidence that SharePoint scales or the fear that it actually might. 


6. Risk avoidance.  This is the person that hates keeping all their content in that legacy repository, but is risk adverse.  No one has been able to convince them that they can easily and without issue move all that content from legacy platform X to SharePoint.  No one has been able to convince them that it’s an affordable and low to no risk exercise.  No one has been able to convince them that it can be done in a reasonable amount of time with little or no impact to business continuity.  I frankly think this starts with a general level of immaturity within the Microsoft partner ecosystem on what ECM is.  I hear a lot of partners talk about ECM and proclaim themselves ECM experts, but I don’t regularly see evidence to back up the talk.  That has translated into failed implementations and burnt fingers and contributes to the myth that SharePoint can’t be my ECM platform.  It really speaks to the accessibility and approachability of the platform along with the massive size of the partner ecosystem.  It creates a dynamic where an organization has to weed through all the partners out there to find the ones that really do understand ECM, can translate that to SharePoint, and in the end help the customer achieve their goals.  You think I’m unfairly asserting something here.  Go to your local Borders or Barnes & Noble or go search Amazon.com for both SharePoint and FileNet.  Not only are you not going to find much on FileNet (…or Documentum or OpenText or Stellent), but you won’t find anything that ends in “for Dummies”.  Not suggesting that the “ECM experts” in the SharePoint ecosystem are dummies, just that I think the ecosystem has generally over-simplified what ECM is and has little expertise with legacy ECM platforms and getting content out of them and into SharePoint.


7. Job Security.  No, this is not the same person talked about in #6.  This person likes all the content in that legacy repository.  It was hard to stand-up, it’s hard and expensive to maintain, and he/she has created the perception that if anyone other than them even looks at it the whole thing will come crashing down.  This is the clown that keeps the person in #6 from doing anything, acting in their own best interests and not the best interests of their organization.  They like things just the way they are and there is at least one of these folks in every organization.  If SharePoint has any chance at becoming an enterprise-wide standard for content management within an organization, these folks have to be disarmed or marginalized.  You’re also never going to be their friend, so don’t waste any time trying to be.

There are most certainly other reasons, but I think this is a good start.  Feel free to leave a comment with others or challenge my lucky 7.

If you’re currently burdened by expensive and hard to maintain legacy content management platforms or have content in more places than you count and want to get all or most of it into SharePoint but don’t know where to start then reach out to us.  Metalogix has both solutions for getting content from any number of content sources into SharePoint and efficiently and cost effectively managing it once it’s there.  We also have partner companies and friends that can help you where we can’t and would be happy to point you in the right direction.

StoragePoint 3.0 Information (RTM June 14th)

• Contact us at info@storagepoint.com if you have any questions or would like to request access to the Release Candidate.  We will not issue pre-release trials without full corporate contact information (Name, Title, Company, Address, Phone Number, and Email Address).
• Attend one of our weekly StoragePoint 3.0 Overview sessions.
• Follow us on Twitter for updates on new content (videos, whitepapers, blogs, etc.).
• Find us on Facebook @ www.facebook.com/StoragePoint
• Check storagepoint.com on June 14th for our new site

We have just published a whitepaper about using Distributed File System (DFS) when you are externalizing your SharePoint content (BLOBs) using EBS or RBS.  This is the first of a many pieces of content we intend to publish.  We hope that you will find some of the content useful. 

We are proud participants of a great community that is SharePoint and we are privileged to be in a position to spend our days, and sometimes nights, not only digging into the technology but also talking to our partners and customers who are relying on the technology every day. This experience gives us good insight into the product. 

We feel compelled to share this insight with you in our attempt to give back to the community that has given us so much. In the coming year you will see Whitepapers, blogs, presentations, webinars, and podcasts get published on a variety of SharePoint topics. If you have any feedback, questions, comments or just want to chat, let us know.

StoragePoint 3.0 Information

• Contact us at info@storagepoint.com if you have any questions or would like to request access to the Release Candidate.  We will not issue pre-release trials without full corporate contact information (Name, Title, Company, Address, Phone Number, and Email Address).
• Attend one of our weekly StoragePoint 3.0 Overview sessions.
• Follow us on Twitter for updates on new content (videos, whitepapers, blogs, etc.).
• Find us on Facebook @ www.facebook.com/StoragePoint
• Check storagepoint.com on June 14th for our new site.

Thank you

Here is a link to the new DFS whitepaper.

http://www.storagepoint.com/papers/Using%20Windows%20DFS%20with%20SharePoint%20Remoted%20BLOBs.pdf

Next on the agenda is SharePoint backup, restore and disaster recovery.

For further reading on DFS see:

http://en.wikipedia.org/wiki/Distributed_File_System_(Microsoft)

 http://technet.microsoft.com/en-us/library/cc753479(WS.10).aspx

We've heard stuff like the following over the past few months (...with increasing frequency as we approach the RTM of SharePoint 2010):

"SharePoint will do BLOB remoting OOB with 2010 so there is no need for a StoragePoint-like solution."

"SharePoint 2010 on top of SQL 2008 will do what StoragePoint does."

"BLOB Remoting is or will become commoditized, so there's no need to pay for it."

Some of these are just plain inaccurate.  There is no OOB BLOB Remoting capability in SharePoint 2010...I've looked for it, can't find it.  There are two provider interfaces, EBS and RBS, that you can plug a solution into, but that's it.  The closest you can come to an OOB solution is the RBS FILESTREAM provider.  It's a stretch to call this OOB.  And not because it's a separate install.  And not because it's a pain to implement.  It's a stretch to call it OOB because it doesn't do an awful lot...it's at best an entry level solution.

It doesn't provide you with the capability to save much money on storage (...BLOB store needs to be local to SQL), make your BLOB store smaller (...no compression), make your BLOB store more secure (...no encryption), or make your SharePoint implementation faster.

So if you're not going to derive much benefit from implementing it then why would Microsoft create it?  The answer is quite simple.  It's there for all the folks running WSS 3.0 with the WIDE (Windows Internal Database Engine) option.  It's there so these folks can upgrade to SFS (SharePoint Foundation Server) and use SQL Express 2008 and stay within it's per-instance limits.  For reference, SQL 2008 R2 Express has a per-instance limit of 10GB...pretty good, but there are plenty of folks out there with WSS 3/WIDE that have a lot more than that.  And I'm not trying to suspend reality in order to sell you some unnecessary 3rd party solution.  I'd go away quietly (...not normally a trait attributable to me), embarrassed that we built something that didn't need to be built, if that was the case.  We happen to see a lot of value in our solution...value that customers have, are, and will continue to pay for.

And you know what, you don't take my word for it because there are plenty of articles and blog posts out there on this topic:

From Jie Li, Technical Product Manager on the SharePoint Team in Redmond: http://blogs.msdn.com/opal/archive/2010/03/24/faq-sharepoint-2010-remote-blob-storage-rbs.aspx or http://blogs.msdn.com/opal/archive/2009/12/07/sharepoint-2010-beta-with-filestream-rbs-provider.aspx

From TechNet: http://technet.microsoft.com/en-us/library/ee663474(office.14).aspx or http://technet.microsoft.com/en-us/library/ee748607(office.14).aspx

I hate the fact that we have to create StoragePoint vs. RBS FILESTREAM Provider position papers or I have to waste time on blog posts like this.  Why are solutions so quickly dismissed if there is a real or perceived OOB capability in an upcoming SharePoint release?  Why is it assumed that this new capability will magically meet the needs of every SharePoint customer out there?  Is SharePoint and the highly energized community that orbits it "one size fits all"?  The answer is most definitively NO!  And that's a good thing.  I'm reasonably confident that most of us wouldn't be doing what we're doing today if it was.

I'd like to suggest a compromise on this point.  We'll stay away from the WSS 3.0/WIDE upgrade business if it's not assumed that the RBS FILESTREAM Provider provides the same value across a wide array of industries and customer sizes as StoragePoint does.  Seems like a fair (...and obvious) compromise. 

As always, please feel free to leave a comment or email me directly at rdoria@metalogix.net if you think I'm wrong or misleading folks.  Maybe we could debate the topic at a SharePoint Saturday or other event in the future.

The StoragePoint product team is pleased to announce that its highly-anticipated 3.0 release will RTM on June 15th.  The release builds on our award-winning 2.0 product with a long list of enterprise class features.  The release will include an intelligent archiving module, extensive Powershell support, more monitoring and reporting, and intelligent endpoint management to name a few.  Existing StoragePoint maintenance customers will be able to seemlessly upgrade for free to the 3.0 release.

This release will support both SharePoint 2007 (WSS and MOSS) and 2010 (SFS and MSS).

Stay tuned for more information on features and a schedule of pre-release webinars.

Ping us at info@storagepoint.com if you are interested in learning more or want to get early access to V3.  We are only making V3 available to a select group of customers and partners, so please be specific about your use case and provide full contact information in your request.  One of our technical pre-sales engineers will follow-up.