SharePoint 2010 brought with it a new BI tool called PowerPivot (ok, I know this is really a SQL tool – don’t get all technical on me). Good friend and MVP, Rob Collie put together a quick survey to gauge it’s adoption by the greater SharePoint/BI community. If you have a moment – please take a moment to respond:
http://powerpivotsurvey.polldaddy.com/s/survey
I have the honor to be presenting at The Experts Conference being held April 17-20, 2011 in Las Vegas at the Red Rock.
![image[3]](http://www.social-point.com/wp-content/uploads/2011/03/image3.png "image[3]")
I have two sessions which I will be presenting:
SharePoint Multi-Tenancy in the Enterprise
SharePoint 2010 brought with it a host of additional capabilities for the traditional hosting company to scale while providing the data security required by their customers. These same features and capabilities can be used inside the enterprise to help enable tiers of service and security to different departments within the enterprise on their own deployment of SharePoint. In this presentation we dive into a business’s taxonomy and apply multi-tenant capabilities to increase features and security while limiting hardware spend. In addition we will discuss what needs to be done technically to enable these features in your farm.
Scaling SharePoint Farms
SharePoint was truly designed with large-scale deployments in mind. During this session we will take a real-world approach to building out a SharePoint farm that serves tens of thousands of users. It’s not always about adding hardware – it is about adding the right hardware at the right time. We will discuss the decision and present some tools that help with these decisions.
There are many other fantastic presenters that will be delivering some great sessions.
If you would like to attend AND save $300, please use the following links and info:
http://www.social-point.com/tec2011
- Use the code: ATGNMSPTGVT
- Put the name “Rackspace” in the referral line
See you there!
Here at Rackspace we call our employees “Rackers”. Not sure if you heard about the weather her in San Antonio – but we saw some snow and ice last night. Since we don’t normally get this type of weather – everyone freaks out!
Since many roads were closed around town our 3rd shift was having issues getting to work. Several of our fanatical Rackers offered to stay all night after having worked the “day shift” to make sure our customers received the service they have come to expect.
Well when things got quiet – they took the time at 0-dark-thirty to leave their mark in the parking lot.
In the words of a Racker: “That’s just how we roll!”
The purpose of this post is to lay the foundation of the scenario we will use to discuss data storage within SharePoint. This post is a continuation of my post on entitled “SharePoint Hosting: It’s a Taxonomy & Governance Decision”.
A quick recap of the previous post is that until recently – all storage had but one location: SQL Server.
But now we have various locations where data (and/or processing) could happen in “other” locations. Well what we will be talking about over the next few posts are:
- What are my processing location options?
- What are the determining factors in choosing processing location(s)?
- What are my data-storage location options?
- What are the determining factors in choosing locations for my data storage location(s)?
So here is the scenario:
A company with about 8500 employees is moving to SharePoint 2010 for their Intranet, General Council, and Team Collaboration. So before we get into the details how how we got here – I’d like to show you the “end state”:
As you can see – there was a lot to think about with our business users to come to this point. In the next post I’ll walk you through the decision process for making the decisions required to come up with a model like this one.
You’ve heard the old adage in real-estate for years –the 3 most important sales factors in selling real-estate are:
- Location
- Location
- Location
This actually holds true when thinking about the storage of your data in SharePoint. For years – actually the entire life of SharePoint – we haven’t really had the opportunity to engage in the conversation. There was only one location for content storage and that was in the content database stored within a SQL server. Now if you think about the typical content that went into SharePoint in those early years it was all the files from their file shares. So over the past 10 years we have been taking content from what was the cheapest storage location (files share) to the most expensive storage location (SQL Server). Smart move, Micro$oft.
Fortunately, we now have a choice – several choices, actually. Through RBS (Remote Blob Storage) and tools from companies like AvePoint, Metalogix (StoragePoint), and now Quest Software we can not only define multiple storage locations for SharePoint content – but set rules for when and where that content is stored.
Factors that Impact where your SharePoint content gets stored include:
- Business Record Retention Plan – I learned about Business Records when working for USAA in San Antonio. They are a pain in the neck. They are vital to your SharePoint solution being successful. More on them later.
- Cost of the storage
- Lifecycle of the data
- SharePoint budget – does the well have a bottom or are your resources infinite?
- Importance of the data – is the content a worksheet planning for the company picnic or an SEC filing document?
- How the data is used
So this post is a continuation of the post I started here. Over the next few days we will be looking at how we actually implement a plan for SharePoint data storage locations.
Before being joined on our SharePoint team at Rackspace by Matt Lathrop our “SharePoint Sales Evangelist”, I spent a good part of my day on the phone with pre-customers talking about SharePoint. One phrase exited my mouth so often that we turned it into a (coffee) drinking game. Every time I said “Taxonomy and Governance” everyone was required to take a sip. Trust me when I say that if the coffee was a stronger brewed drink typically consumed at a SharePint, we would left the office on legs that were less that steady!
Before we continue – let me give you my definition of Governance.
Governance is the who, what, where, why, and when of SharePoint.
Taxonomy is in large part the “what and where” in governance.
In our earlier SharePoint environments when SharePoint’s capabilities were much more limited, our decisions about Governance were much easier. You see SharePoint did less than it does today and consequently there was less data and less business processes in there. We also had a lot less options when it came options of where to placed our processing and data.
Quick aside: have you noticed that I am using the term “hosting” less and using the phrase “processing and data” more frequently? This isn’t an accident. Given the options available to us today we have the very real capability to break everything apart. Consider the following:
Data
There are newer and newer types of storage devices available to us in a variety of price points which provide varying degrees of availability, redundancy, and management. There is traditional “direct attached” storage drives that can be plugged directly into SQL to hold the data in your content databases. Netapp, EMC, and others provide block-level storage for your SQL data as well.
Using Remote Blob Storage (RBS) in SQL or by using products from AvePoint or Metalogix SharePoint BLOBS (Binary Large Objects) can now be stored outside of the traditional SQL database. With these options you could use:
- File Shares in your datacenter
- Cloud-based storage from companies like Rackspace, Microsoft, Amazon, and a few others.
Processing
IT data-center managers have all the usual suspects of servers that can be used to host SharePoint as well as the maturing market around blade-servers as well as virtualize servers running on shared processing resources.
In addition to the physical and virtual devices that exist to the data-center manager are a myriad of devices hosted (or managed) by 3rd party companies. These include:
- Virtualized server instances running on shared processing devices. This is what exists when we typically think of “Public Cloud Server Hosting”. Arguably the two front-runners in this space are Amazon and Rackspace. Benefits of this type of hosting are lead by the economics – it is very cost effective. A downside is that the company generally doesn’t have much control of where their processing takes place and they can be impacted by other companies who’s processing may spike.
- Virtualized server instances running on dedicated processing devices. In this case the individual company is the “sole tenant” on the underlying server. The company also has sole control of the exact topology who what server instances run on what devices. At Rackspace we call this a “Private Cloud”. So the benefit of this increased level of control is offset by the increase in expense for this type of cloud hosting.
- Dedicated Physical Servers. This is the traditional server hosting model that most are familiar with when thinking of “Server Hosting”. In this instance you have total control of the device and the software that runs on it.
- Hybrid Hosting. Quite simply – hybrid hosting is a collection of any of the processing hosting models.
So which form of data or processing hosting is correct? If you have any experience with SharePoint then you know that most SharePoint questions are answered with “It Depends”. What does the hosting decision depend on? Well in this case it depends on your SharePoint… wait for it…..
Governance!
Now everyone drink!
In the next post I’ll start to connect these concepts with some wire-frames to help you visualize what I’m talking about here.
Tags: Governance, Hybrid, Rackspace, Servers, SharePoint, SharePoint Governance, SharePoint Hosting
The behemoth that has become SharePoint is riddled with layers of complexity providing an endless array of options for specialization within the product. My own journey began in the same location as many of you – a SharePoint End-User. Like many of you (as you sit there reading a geeky SharePoint blog) I was not just an End User; I was an end user with the vision to see that this product had the capability to utterly route stoic business processes and replace them with true collaboration powered by SharePoint. What continues to amaze me is that this fabled future was even visible in SharePoint 2003! So now we find ourselves with SharePoint 2010 with Collaboration, BI, Social Networking, and more.
As an employee of Rackspace – I hear one comment over and over as I discuss SharePoint with pre-customers:
We are deciding if we are going to manage SharePoint ourselves – or have it hosted.
I would like to challenge that statement.
For those of you who keep and control your own SharePoint servers I’d like to ask how many of you have actually seen those servers? Our internal IT shops act as much like a hosting company as one employed in that specific business. Think about it – a separate department under its own unique management is in charge of: data-center facilities, power, network, server procurement, data-center personnel, operating system specialists, SQL DBA’s, and SharePoint IT-Pro’s. My point in this is not to ask you to challenge your thinking about whether to use your own IT shop for manage your servers – but make that point that should you decided to place any aspect of your SharePoint services outside of your own datacenter is a “hosting decision” not a “SharePoint decision”. To take this one step farther – we are moving far beyond this being a “one time decision” for SharePoint.
You see, SharePoint’s capabilities are so vast, data in your farms spans simple collaboration to that which could be covered under SEC regulations, and there are more options now for where this processing and data can exist. The new reality in choosing where processing occurs and where data is stored is that the One Size Fits All mantra simply doesn’t apply.
This post is the beginning in series where I hope to present a to you as many of the decision points that exists and the factors that impact them. It’s my hope that by the end of this series you will have a greater appreciation and understand of the options at hand and feel more empowered to make the decisions with which you will be faced.
For years so many people have struggled to understand SharePoint licensing. Well with the advent of SharePoint 2010 Microsoft has authored a WEB page that makes the different scenarios understandable (who know)!
http://sharepoint.microsoft.com/en-us/buy/Pages/Licensing-Details.aspx
If you have any questions about how to license SharePoint, take a look at the above link. One major change/clarification I found was when licensing the SharePoint server for “unlimited” connections:
No CALs are required for users licensed through SharePoint Server 2010 for Internet Sites.
That means no more dual licensing for users who are authoring content for their public facing WEB site.
Enjoy!
OK, I’ll admit it – this one was hard to figure out.
Background:
SharePoint 2010 Standard server. Search was returning content, crawlers were filling the index. No immediate customer impacting issue.
The Issue:
The event viewer had an error occurring every minute – Event ID 6482 which states:
Application Server Administration job failed for service instance Microsoft.Office.Server.Search.Administration.SearchServiceInstance (21e4447f-bac6-4a29-82db-165e074ac5db).
Reason: An update conflict has occurred, and you must re-try this action. The object SearchDataAccessServiceInstance was updated by domain\user, in the OWSTIMER (5040) process, on machine (server name). View the tracing log for more information about the conflict.
Technical Support Details:
Microsoft.SharePoint.Administration.SPUpdatedConcurrencyException: An update conflict has occurred, and you must re-try this action. The object SearchDataAccessServiceInstance was updated by domain\user, in the OWSTIMER (5040) process, on machine (server name). View the tracing log for more information about the conflict.
at Microsoft.Office.Server.Search.Administration.SearchServiceInstance.Synchronize()
at Microsoft.Office.Server.Administration.ApplicationServerJob.ProvisionLocalSharedServiceInstances(Boolean isAdministrationServiceJob)
It turns out there isn’t a lot of information about this specific issue available via your search engine of choice. I was able to find some similar information but that was related purely to the User Provisioning Service. So I went with the old tried and true:
- I reset the Index
- I deleted/recreated the Search Service App
Neither of these worked so I went back to the 2 blog articles I found that were similar the issue I was seeing. Turns out that this happens when “the contents of the file system cache on the front end servers is newer than the contents of the configuration database”. This could happen if you’ve recently been through a system upgrade or recovery.
Resolution:
The file system cache on all FE’s (in my case, this was just one server) on which the timer service is running needs to be cleared.
Below is the step by step provided by Microsoft in this KB Article for doing this:
- Stop the Windows SharePoint Services Timer service (Found in Windows Services)
- Navigate to the cache folder
In Windows Server 2008, the configuration cache is in the following location:
Drive:\ProgramData\Microsoft\SharePoint\Config
In Windows Server 2003, the configuration cache is in the following location:
Drive:\Documents and Settings\All Users\Application Data\Microsoft\SharePoint\Config
Locate the folder that has the file "Cache.ini"
(Note: The Application Data folder may be hidden. To view the hidden folder, change the folder options as required) - Back up the Cache.ini file.
- Delete all the XML configuration files in the GUID folder. Do this so that you can verify that the GUID folder is replaced by new XML configuration files when the cache is rebuilt.
- Note When you empty the configuration cache in the GUID folder, make sure that you do not delete the GUID folder and the Cache.ini file that is located in the GUID folder.
- Double-click the Cache.ini file.
- On the Edit menu, click Select All. On the Edit menu, click Delete. Type 1, and then click Save on the File menu. On the File menu, click Exit.
- Start the Windows SharePoint Services Timer service
- Note The file system cache is re-created after you perform this procedure. Make sure that you perform this procedure on all servers in the server farm.
- Make sure that the Cache.ini file in the GUID folder now contains its previous value. For example, make sure that the value of the Cache.ini file is not 1.
In my case – it worked like a champ. I will freely admit that I made 2 distinct copies of the cache … I was paranoid!
Sources for this article – you guys saved the day:
- My customer. Thanks for the
pain.. I mean opportunity to learn - Chaitanya Madala Blog
- Microsoft KB Article 939308
Tags: Event ID 6482, KB 939308, Search, SharePoint, SharePoint 2010, SharePoint Search
