Working in the Cloud is better than Going Up in Smoke

Working in the Cloud is better than Going Up in Smoke

Everyone Is Talking About the Cloud

There’s no doubt, that for many organizations there are compelling financial advantages for moving some, or all, of your systems to the cloud.  This is especially true in the case of SharePoint installations.  The cost of supplying and managing SharePoint to a large body of employees is lower on the cloud, and the capabilities are adequate, except…

When you need a Change that comes from the “Heart” of SharePoint

The problem with the cloud (unless it’s a cloud dedicated to just you) is that you’re sharing the environment with other organizations.  (The fact that the environment is being shared is what lowers your costs.)  But, because it’s being shared, you are typically not allowed to make any modifications to the core of the environment that is “common” to the other “tenets”.  If you “improve it” for you, you have altered it for them… and that’s why it’s not allowed.

The result is that most of the people who need to significantly modify or “enhance” their SharePoint environment don’t move to the cloud, they implement, modify and maintain their own environment.

Way To Go?

I applaud this approach, I really do.  At JFD, all of our SharePoint environments are either on-premise or dedicated cloud because we value what can be done when you are able to actually modify the environment itself.

The downside to our strategy is that we do have to bear the burden of constantly monitoring and updating our SharePoint environments.  The problem, and the underlying reason for this blog, is that implementing, configuring and maintaining a SharePoint environment is not a trivial undertaking.  It requires people who have the expertise to do it in the first place and a commitment to the continuing education necessitated by the constant modification (Hot Fixes, Cumulative Updates, etc.) and evolution of SharePoint.

“No Problem, We Got That Covered”

You may be aware of all this and you may have decided that an on-premise approach was the most appropriate for your organization anyway.  That’s great!  But if you’ve taken that approach I respectfully suggest that you routinely examine the health of your environment, its continuity and the information contained in your log file errors.

Are You Okay?

I need to be a little careful about how I phrase this, but the vast majority of the clients that we have dealt with in 2013 had SharePoint environments that were incorrectly configured, incorrectly updated and not monitored.  These are real companies.  They have significant IT departments.  In most cases individuals with real credentials were responsible for these issues.

“But It’s Running Fine”
In case you didn’t know, it takes a lot to kill SharePoint.  You can have an environment that is so screwed up that it’s throwing multiple errors per second and yet it will still run.  (But it can be doing some really weird things that you may not expect). Problems may surface in search results, time and date errors, and many other insidious places you wouldn’t immediately attribute to a bad installation or incorrectly sequenced updates.

The Living Room is Intact, but the Basement is Flooded

Working with clients this past year, almost 90% of the time, when just implementing a minor SharePoint improvement, workflow or some branding, the situation has required that we repair or replace the SharePoint development environment.  We have then gone to move the new work into the production environment we find that different but similar serious issues exist there also.  Build numbers don’t match between production and development, updates not applied or applied out of sequence.  The backups that they rely on have never been tested to see if a real restoration was even possible.

Check Your Own Oil

If you have a position in IT management, especially senior management, when it comes to SharePoint, it’s wise to become familiar with your own log file errors.  You may not understand them, but seeing that your system is generating something the size of a small phone book each day is enough to let anyone know that something’s wrong. (Although we have seen situations where the log file had been turned off because it was recording so many errors, that the logging process itself was slowing down the system!)

The moral of the story here is that SharePoint can, and will – in many cases – continue to run in a very damaged state.  Its performance will be impacted and in some cases its information will be unreliable, but it will still “run”.

As IT management, especially when it comes to SharePoint, it’s best to not assume, and instead check the log files yourself.  It’s the best way to avoid serious investments going up in smoke.  If it ever comes to that you’ll really wish you had been on the cloud.