SharePoint and World Economics

The economy is definitely on the mind of people in the U.S.  Maybe yours too?  I’ve spent time abroad lately and around the world gas prices and currency is a common topic.  What about SharePoint?  How does it relate to economics…

In a recession SharePoint will continue to do well.  Why?  SharePoint principals are:

  1. Consolidation of Legacy applications – so many custom .NET and Java apps could be quicker and more simply deployed on out of the box SharePoint Apps 
  2. Consolidation of local and distributed collaborative shares – When every team has their own shares and/or servers there is a lot of unnecessary redundancy, power consumption, rack space, etc…
  3. Economies of scale with Operations Teams – consolidate division or departmental solutions
  4. Access to Line of Business Data – licenses to those expensive LOB apps are pricey, so why not expose the data in SharePoint search with custom actions?
  5. What doesn’t SharePoint do – You can do so many things with SharePoint I call it plastic.  Obviously having it all in one platform you get more out of it, especially when you have it deployed as a service.

You won’t save money by moving file for file to SharePoint from file shares.  I’ll save you that math.  It is more than 2-3X the cost just for storage.  You could see another 2X or more with ops.

Career/Job Growth Continues

While the U.S. economy goes down and pressure on IT increases, more and more SharePoint deployments are happening and are not slowing.  The demand for SharePoint expertise both in the corporate and consulting world and top dollar/Yen/Euro is required. 

I got a message from my bank saying they were "safe and sound."  Well, rest assured "SharePoint is safe and sound."  You don’t have to take my word for it.  A recent CMS Wire article talks about the "One Collaboration Platform to Rule Them All."  In this dark article which talks about SharePoint as a virus and puts a negative spin to the wave of deployments pushes governance (something I push as well) it explains quadrupling of SharePoint applications.  It talks about poorly planned and poorly executed deployments, which unfortunately will likely get worse before it gets better.  SharePoint deployments are not a commodity that you can get turn key from SharePoint consulting shops… unfortunately.  MCS would like to make you think so with SDPS (SharePoint Deployment Planning Services).  Heard about it?  Partners get certified where you can use your EA bucks for free SharePoint deployments.  Be cautious.

FYI: There’s a SharePoint Skills shortage!  Redmond Developer magazine agrees in their SharePoint Dev skills Shortage article.  SharePoint Dev skills… not a commodity.  A big complaint of companies is what they’ll pay for SharePoint dev skills.  Guess what?  You pay for the experienced guy and get it done faster and done well, or you pay the cheap guy to do it wrong until you learn it takes experienced and today unfortunately or fortunately (for the dev) high pay.

Alert there is not enough SharePoint skills on both Dev and IT sides.  (Hush – Don’t tell anyone. 🙂  Even consultants who have been doing just SharePoint for a year are still struggling to understand the "best practices" and plan for scalability.

While SharePoint deployments have exponential growth, most IT departments will attempt to roll over existing resources and with economic challenges they are going to try to do it without training.  That part definitely concerns me.  People (Devs and IT and Business Analysts/PMs) need training to ramp up.

Announcing the SharePoint Planning and Governance 3 day course for Project Managers and Business level Implementation teams.  I will be co-teaching this with Nicola Young and John Ross on 9/23 in Cincinnati, OH for a steal.  That’s our first class.  So go ahead and sign up now.  Note this is not a techncal class, it’s about governance and planning and successful deployments.  You’ll leave the class with a project plan, a governance plan.

Where is the change log?

Shane today in class was looking for where the SharePoint change log is.  I did a quick search and found a decent answer on MSDN with detail on Change Log Freshness
"The Change Log is a physical table in each content database, and each transaction writes to the log." The Change Log recevied by hitting the lists web service http://<Site>/_vti_bin/Lists.asmx  GetListItemChanges with GetListItemChangesSinceToken method of the Lists Web service to get changes starting from a specified point in time."
Found a great WSS 3.0 web service one page quick reference on Look Alive blog which I’m sure came from across the various MSDN pages.
Note: The change log is security trimmed.  "The change log returns a list of SPChange objects for changes that happened, for example, to the following object types:
  • Items, files, and folders
  • List metadata
  • Site metadata
  • Security"

I want verbose SharePoint errors when things break!

If you hate those generic general or unspecified error or unknown error occurred or even errors that failed and told you to contact the admin without telling you why you should contact your administrator?  I really hate it when I am the administrator and it tells me nothing! Well you can turn on verbose errors that actually tell you something.
The web.config calls the application default as custom errors.  It may seem counter intuitive to say "turn custom errors off," but essentially you’re saying those friendly errors aren’t telling me what I need.  Here’s three simple steps…
1) During your maintenance window, find in your web.config file in the <SharePoint><SafeMode> section the following line <customErrors mode="On"/> and simply change the "On" to "Off" (case sensitive).
2) Then look for Callstack="False" and change it to "True" (again case sensitive) this will actually give you the verbose (rich) details beyond the simple error codes.
3) Reset the affected app pool or app pools (or run iisreset on the command line if you’re lazy or have no idea what I’m talking about…)
I know I’m not the first to say this, but I want to make sure this is more broadly understood.  This is a great troubleshooting tip.  Note it will require an app pool cycle to get this to take effect since the change is in the web.config file.
Also to note, if this is on the intranet and not exposed to external users you may find keeping the errors verbose reduces troubleshooting time.  I can’t argue with that.  I caution for Internet sites for revealing too much detail.
Looking for more detail on this?  Andrew Connell one of my favorite MVPs, has a developers quick post of making sense of SharePoint errors on this.  This is obviously not new, but often not well understood that you can even do this.  (Also, kudos to Shane Young for calling this out in SharePoint Survival Admin Class).

How can I easily force the SharePoint Web Part Maintenance Page?

Append ?contents=1 to your querystring.  Example: Try it.  It’s cool.  Thanks Shane Young for pointing this out in our Survival class.  🙂
We were talking in class about deleting closed web parts… it’s a pain to try to get to the UI where you can delete "closed web parts."  I find that most page perf issues I see are related to bad web parts that are actually closed. 
I’m not a fan of any closed web parts.  I think it’s a poor feature.  Just my 2 cents.  The idea of closing web parts for private views… just didn’t work like it was designed and has more downsides than up.

Words of Caution on SQL Mirroring with SharePoint

I’ve had a lot of conversations with my friend Mike Watson spent a ton of time working on Disaster Recovery strategies in his time working on DR for the Hosted SharePoint and Microsoft IT deployment, as well I’ve gathered a lot of feedback in various conversations with customers, MCS, and other SIs.  One thing I’ve gathered from various conversations and in my own experience is there should be some words of caution for those venturing into the SQL mirroring space.  These words deal with mirroring for SharePoint in SQL 2005, I think SQL 2008 still has promise or potential.  Feel free to comment as I expect this is controversial.
Also check out the latest whitepaper on SQL mirroring, you’ll see the holes are a bit smaller as we all gather more info on this complex operation.
1. It isn’t ready – In my experience SQL mirroring is half there for SharePoint in SQL 2005.  The idea is awesome, but since the granularity is in the database I have heard way too many times of failures with unknown reasons.
2. Too complex – with operations folks it is a pretty big jump for real admins to jump from doing clustering (doable) to mirroring (complex).  It increases the level of difficulty for supporting the environment by a factor.  I find anyone who is new to SharePoint should wait a year to mess with something like SQL mirroring.  Unless it’s a SQL team, the SharePoint ops folks will find the complexity just way too high.
3. Doesn’t live up to it’s potential – Without Mirroring really giving you automatic failover what does it give you?  Manual failover is complex and even the most experienced SharePoint people will be challenged to properly failover the farm across the databases…. let alone dealing with the config, SSP databases and Index.
4. Consumes too much memory – this may not be a big deal for most of you, but I’ve found the amount of memory that SQL mirroring sucks up is really something to be aware of if not concerned about.  The SQL team themselves had a low threshold for mirroring due to memory from what I could glean.  In Mike’s own testing he found there really was an upper limit to mirroring since SQL would consume more and more memory with each database that’s added.  Please don’t assume that I had mike review this post, since he hasn’t and he may not agree with everything I’m saying here.  I’ll let him respond on his blog or refute this.
5. Mirroring over the WAN is obviously a problem too since figuring out the challenges of latency really end up pushing log shipping which is an old TCP/IP netbios basically file sharing type of operation.  Sadly inefficient, chatty and continues to still be superior to mirrioring in my opinion.  Again I say SQL 2008 and Mirroring step up the challenge. 
My 2 cents is to wait for SQL 2008 and pretend like Mirroring doesn’t exist unless you have a top notch SQL team and a top notch SharePoint team.  If you do, then you’ll likely be looking at fancy tools that will help you manage the failover and manage the namespace challenges that come with mirroring.  I know there are alias workarounds that some have come up with that really reduce the complexity, but the index and SSP challenges don’t completely go away.  Don’t sell yourself short with Clustering vs. Mirroring or with Log Shipping vs. Mirroring.  In both cases the alternative to mirroring is more simple and does the job in most cases.  It is the exceptions which is why we are all looking at mirroring, so let’s not totally write it off, but keep it in your back pocket.