Monthly Archives: February 2014

The Content Database Support and Remote BLOB Storage Myth

Posted on by
Reply

There’s a popular myth that keeps popping up that I wanted to post about.

Why is it so popular?
Well, because it seems intuitive if you aren’t working with SharePoint on a regular basis. If you are then I’m sure you don’t think this… and if you did, well shortly you’ll know the truth.

So here’s the myth
“We don’t need to split our content across separate content databases because if we need more than 200GB support for each database we will [1] move subsites around to different site collections in different databases or [2] use remote blob storage and put it all on file shares… then we’ll have a very small content database size.”

Why is this a myth?
Let’s address the second part of the statement first – “[2] use remote blob storage and put it all on file shares… then we’ll have a very small content database size”. This is a myth because the content database will still not be supported by Microsoft. The reason for this is that both the actual database size itself PLUS the content offloaded and stored on file shares count in the 200GB (or 4TB if you meet additional requirements). This means that even if you had a 1GB database and 225GB offloaded onto fileshares for this content database, then you’re actually at 226GB and therefore not supported if you do not meet these requirements. If you do meet the requirements and have a 1GB database with 4.5TB offloaded onto fileshares for a specific content database, now you’re at 5.5TB of content and again, not supported.
From http://technet.microsoft.com/en-us/library/cc262787.aspx: “If you are using Remote BLOB Storage (RBS), the total volume of remote BLOB storage and metadata in the content database must not exceed this limit.”

Now let’s address the first part of the statement “we will [1] move subsites around to different site collections in different databases”. This also is a myth because although this is doable, it doesn’t make it a good idea.. Do you remember that old Chris Rock line.. “You can drive your car with your feet if you want to, but that don’t make it a good, [expletive] idea?” Yes? Well that’s the same here. So why isn’t it a good idea? In this case it’s because subsites are contained within a site collection. There is a close relationship between a site collection and its subsites. Objects such as site columns and content types are associated with and shared by subsites. If you want to move an individual subsite, then you have to consider how you are going to move these shared objects as well – and this is where it gets tricky. This is because there are a number of objects are difficult to move – for example workflow history and approval field values. Even if you investigate using third party tools to perform the move your subsites, you will likely encounter issues.

Ok I get it, but what do you recommend… what is the fix?
Essentially what needs to happen is that the architecture of the SharePoint environment should be considered carefully up front as much as possible, in conjunction with:

In case you are thinking, well, surely Microsoft should just raise their support limits even higher, or that subsites should be able to be moved around in a more full fidelity manner. I understand this point and was guilty thinking this myself when I first started working with SharePoint. As time grew on though, I also asked myself.. Is there any other product that offers all of the functionality that SharePoint does and has comparable supportability limits? Well frankly I couldn’t think of any. Besides, given that there is full transparency with the supportability limits and a wealth of information on TechNet to make it clear (at least to IT pros) what to do and what not to, I’m happy with this, at least for now.

Is It Possible to Integrate Chris21 with SharePoint?

Posted on by
Reply

Chris21 is a surprisingly popular system for a large number of clients I work with, so I wanted to comment on a solution that may help unlock value for your company if you are using it.

What I’ve found working with a number of companies is that their Active Directory is often out of date (surprise surprise), yet Chris21 is, and must be up to date because they are using it as their Payroll system.

Wouldn’t it be great if you could automatically update Active Directory based on information in Chris21? For example, finally the Manager or Contact Details of each employee might be accurate for once!

The flow on effect of this is that you can then have accurate SharePoint profiles. This can be a good approach when you’re initially setting up your SharePoint environment because you don’t need everyone to manually update them. Perhaps not an issue in a very small company, but for larger ones this is important. Then, if you want to empower your staff, and need to keep any fields up to date in Chris21 easily, well, then you have the ability to let users update their user profile fields and sync the data back into Chris21! This is pretty cool if you ask me.

Now, let’s take this solution a step further – what if you could stop sending those email or paper based Leave Request forms around and leverage a web based / electronic form? What if you already have a web based Leave Request form but it can’t really do much because the data just sits inside SharePoint and that’s it? How about instead of the form just sitting there, you leverage it instead, so that once a manager has approved a Leave Request, it is sent to Chris21 where the leave balance is automatically adjusted… wouldn’t that save a lot of time?

Well, the good news is that all of this is actually is possible. A while back I was fortunate enough to work with one of the few people I’ve met that had a good handle on both SharePoint & Chris21, and we implemented a solution to do this very successfully. As much as I would like to comment on the specifics, I’m unable to because the detailed solution is confidential IP owned by the company I work for – however I thought this post may still have value to at least mention what is possible in terms of the integration because looking around on the web now, there is very sparse content on this.

Essentially, the high level approach is that you can achieve the integration through the use of Chris21 web services – which does require additional licensing from Frontier.  The Chris21 web services only got us so far though so ultimately we ended up with additional custom code, which ended up working solidly, though was quite a headache to write and may very well have taken double or triple the time/budget if it weren’t for the expertise of a colleague who had previously worked on a similar project before.

Looking back on dollars invested vs. returned – does it seem worth it? For the companies that I’ve worked with, yes – namely because they were going to be ‘stuck’ with Chris21 for the next few years, they had staff members manually entering and processing leave requests in Chris21 and AD was way, way out of date.  Could it be worth it for you? Well, if you have staff manually entering data into Chris21 or use it as your primary source of truth for employee details then it very may well be.

InfoPath Retired & Sneak Peak of New MS Forms Tech To Be Given in March

Posted on by
Reply

Well, it’s official.  Microsoft have just announced the retirement of InfoPath and that they have been working on a new forms technology, of which a sneak peak will be given to the public at the SharePoint Conference in March.

For those in the know, or developing with InfoPath on a regular basis this was not really a surprise.  Ever since the 2007 release of InfoPath, fewer and fewer investments had been made in the product, bucking the trend of other Microsoft technologies, causing people to speculate that Microsoft may move in a different direction for the enterprise forms technology.

This different direction is to add new forms capabilities into SharePoint, Word and Access.

So where to next then?

The official position of Microsoft is to keep creating InfoPath forms because the product is still supported, and a migration plan will be announced.

In my opinion this makes sense for companies using InfoPath for simple forms and ones that are not heavily used in workflows.

For companies that have more advanced form requirements, such as those used heavily in workflows, you may want to consider a technology such as K2 Forms or Nintex Forms.