Tag: SharePoint

hybrid-sharepoint

Why Hybrid SharePoint Isn’t Halfway to the Cloud

Despite a strong push or desire by organizations to move to the cloud, 2015 will undoubtedly be the year that many organizations move to a hybrid SharePoint environment. And that’s where the confusion begins. The term “hybrid SharePoint” can mean different things depending on how you choose to adopt the cloud.

Everyone from Microsoft to third-party cloud hosting providers offer differing definitions of hybrid SharePoint. For me, it means running SharePoint on-premises and in the cloud leveraging Office 365/SharePoint Online, third-party hosting providers, or simply running SharePoint with your favorite IaaS provider.

Ultimately hybrid SharePoint is a safer approach as organizations already have long tail plans to move to the cloud when the time is right. And hybrid solutions allow organizations to provision new workloads or start moving existing workloads to the cloud. For many organizations the long-term goal is to move as many workloads to the cloud as possible. Hybrid SharePoint offers these organizations additional flexibility and granularity that allows teams to move, manage and secure one or several workloads.

In addition, a new practice is emerging which sees SharePoint admins using the cloud to create new workloads in test environments that will eventually replace their current workloads. While this involves more effort, it’s a clean and practical approach that provides SharePoint professionals with an option eliminates the legacy dependencies that occur when moving existing workloads to the cloud.

As you can see, hybrid SharePoint has many meanings. For one admin, it might mean embracing Office 365 as a way to collaborate with external users or trading partners. For another, it could mean offloading critical workloads to better support a mobile workforce. Yet, the one overriding observation that we can take from all of this is that for many the hybrid cloud is considered a halfway step to the cloud.

blob-externlization

If BLOB Externalization Is Right for Office 365 Then Why Not for My Growing SharePoint Environment?

It’s no secret that third party BLOB externalization solutions have provided tremendous value to organizations with growing SharePoint environments. The capability first appeared in SharePoint 2007 as BLOB Storage (EBS) and later in SharePoint 2010 as Remote BLOB Storage (RBS).

The value of RBS/EBS has always been clear. Removing BLOBs from the SharePoint database increases file access performance, allows for scalability in a cost effective manner, reduces storage costs and improves backup performance. Despite the clear value of BLOB externalization guidance on whether to use RBS/EBS varies wildly depending who was dispensing the advice, many SharePoint MVPs, consultants and even some Microsoft employees aggressively recommended against using BLOB externalization. Yes, there have been supporters of BLOB externalization including Microsoft’s own Bill Baer. However, guidance on whether to use RBS/EBS has been, at best, chock-full of contradictions.

Microsoft recently disclosed the inner workings of Fort Knox, a project that aims to bring increased security to Office 365 through the use of heavy encryption. Fort Knox is being described as RBS-like as it externalizes and stores file shreds across multiple Azure blob storage containers while encrypting each shred with AES 256 bit encryption. Yes, this isn’t RBS in its purest form but rather a custom, one-off BLOB externalization capability developed by the Microsoft product team for Office 365. Regardless, the Fort Knox project is BLOB externalization. Ironically this capability has been available from third party RBS providers since the introduction of SharePoint 2010 and even earlier leveraging EBS with SharePoint 2007.

The process of removing a BLOB from a SharePoint content database creates an opportunity to perform certain functions such as encrypting BLOBs, thus allowing a higher level of protection in transit and at rest. Encryption of files is only possible when externalizing BLOBs for SharePoint Content Databases. Yes, Transparent Data Encryption (TDE) is a possibility but requires that the entire database be encrypted. TDE is not without its caveats including the potential for performance degradation.

It may be time to revisit whether BLOB externalization is right for your growing, more secure SharePoint environment. Heavy encryption of externalized content is just another feather in the cap of BLOB externalization. Unofficially the BLOB externalization capability used by Office 365 is employed to provide more than just encryption of files at rest. Consider the massive size of Office 365 farms and you have to assume that scalability, backup, and high availability are all challenges for such a massive deployment of SharePoint. So you have to ask yourself, if BLOB externalization is the right answer for Office 365 shouldn’t it also be right for my growing SharePoint environment?

StoragePoint 3.0 Webinar Series Announced

Yesterday we announced a new webinar series where we will review and demonstrate the features of StoragePoint 3.0.  StoragePoint 3.0 is a highly anticipated release that provides significant advancement over our  already robuts BLOB remoting capabilities for SharePoint 2007 and SharePoint 2010.  New features like Intelligent Archiving, Multiple Storage End Points, and advanced reporting capabilities significantly reduces the total cost of ownership of SharePoint deployments while providing improved performance, reduced backup/restore time frames, and flexible storage options .  StoragePoint 3.0 is a must have for organizations deploying any level of document management or enterprise content management solutions on SharePoint 20007 or SharePoint 2010.  To register for an upcoming webinar please visit our Event Brite page at http://storagepoint.eventbrite.com.  For more information on StoragePoint visit www.storagepoint.com, blog.storagepoint.com, or www.youtube.com/user/storagepoint.

EMC Certifies StoragePoint Centera Adapter

Organizations are often tasked with storing content in a compliant way.  Whether you are dealing with SEC, HIPAA, SOX, or DOD compliance scenarios, SharePoint’s native storage architecture fails to meet the level compliance that organizations require.  Enter StoragePoint.  By leveraging supported APIs and interfaces, StoragePoint alters the native SharePoint storage architecture allowing you to separate the BLOB (Binary Large Object) from the content metadata.  The metadata is stored within SharePoint Content Databases while the BLOB can be remoted to a variety of storage locations.  For complaince scenarios organizations often turn to EMC Centera to provide WORM (Write Once Read Many) storage.  StoragePoint provides a certified storage adapter for storing SharePoint content on EMC Centera.  EMC recently certified our StoragePoint adapter.  Check out the press release.  http://finance.yahoo.com/news/Metalogix-Releases-bw-3469966683.html?x=0&.v=1

Merge Content Databases After StoragePoint Externalization

It’s not uncommon to have multiple SharePoint content databases for a single SharePoint application.  The separation of site collections into different content databases is typically done in an attempt to work around content database size recommendations provided by Microsoft (see Microsoft’s Plan for Software Boundaries document for more information).  In many cases organizations have one content database per site collection.  After deploying StoragePoint into your existing SharePoint farm the next logical step is to run the externalize job(s) which will relocate your existing content outside of the content database.  Once completed you will be left with very small content databases that can now be merged (note that you will have to run the DBCC_ShrinkDB script several times to reclaim your unused database space or rebuild table indexes before running dbcc_shrinkDB.  For more information consult the StoragePoint Administrator’s Guide).  Merging SharePoint content databases can be done using the stsadm command. Execute the steps below to merge your content databases.

[more]

Prerequisites

  1. **** Important!  Microsoft recommends applying the April Cumulative Update before you merge content databases.  There are known issues with this merge database command prior to this update.
  2. Even though your content databases will be very small after relocating BLOBs with StoragePoint’s externalize job, you must make sure you have enough free space to merge content databases.  The general rule is that you must have at least three times the size of source site collections database size.  *** Note:  Do not use the value returned for the StorageUsedMB property when running the stsadm -o enumsites -url webappurl to determine your database size.  With StoragePoint deployed this property will reflect the total space used by content in SharePoint but not the actual size of the content database. 
  3. In order to execute the following STSADM command you must be a member of the Farm Administrators group and be an Administrator on the local computer.  Additionally you need to have Full Control permission for any site collection being moved.  For SQL Server, you must be a member of the db_owner database role.

Steps to Merge Content Databases

  1. From a SharePoint server in your farm, open a command prompt and navigate to %COMMONPROGRAMFILES%\Microsoft shared\Web server extensions\12\Bin
  2. Type the following STSTADM Command
    STSADM –o mergecontentdbs –url <url of web application> –sourcedatabasename <source db name> –destinationdatabasename <dest. db name> –operation2 Note that the URL is the URL of the web application that contains the site collection.  This is not the URL of the site collection itself.
    Operation2 = full database merge

  3. Restart IIS by running iisreset/noforce from a command prompt.