The cloud is not the problem-Part 4: Industry shakeout and playing with the big kids…

This entry is part 4 of 6 in the series Cloud
Send to Kindle

Hi all

Welcome to the fourth post about the adaptive change that cloud computing is going to have on practitioners, paradigms and organisations. The previous two posts took a look at some of the dodgier side of two of the industries biggest players, Microsoft and Amazon. While I have highlighted some dumb issues with both, I nevertheless have to acknowledge their resourcing, scalability, and ability to execute. On that point of ability to execute, in this post we are going to expand a little towards the cloud industry more broadly and the inevitable consolidation that is, and will continue to take place.

Now to set the scene, a lot of people know that in the early twentieth century, there were a lot of US car manufacturers. I wonder if you can take a guess at the number of defunct car manufacturers there have been before and after that time.


…One Hundred?

Not even close…

What if I told you that there were over 1700!

Here is another interesting stat. The table below shows the years where manufacturers went bankrupt or ceased operations. Below that I have put the average shelf life of each company for that decade.

Year 1870’s 1880’s 1890’s 1900’s 1910’s 1920’s 1930’s 1940’s 1950’s 1960’s 1970’s 1980’s 1990’s 2000’s 2010’s
# defunct 4 2 5 88 660 610 276 42 13 33 11 5 5 3 5
avg years in operation 5 1 1 3 3 4 5 7 14 10 19 37 16 49 42

Now, you would expect that the bulk of closures would be depression era, but note that the depression did not start until the late 1920’s and during the boom times that preceded it, 660 manufactures went to the wall – a worse result!

The pattern of consolidation


What I think the above table shows is the classic pattern of industry consolidation after an initial phase of innovation and expansion, where over time, the many are gobbled by the few. As the number of players consolidate, those who remain grow bigger, with more resources and economies of scale. This in turn creates barriers to entry for new participants. Accordingly, the rate of attrition slows down, but that is more due to the fact that there are fewer players in the industry. Those that are left continue to fight their battles, but now those battles take longer. Nevertheless, as time goes on, the number of players consolidate further.

If we applied a cloud/web hosting paradigm to the above table, I would equate the dotcom bust of 2000 with the depression era of the 1920’s and 1930’s. I actually think with cloud computing, we are in the 1960’s and on right now. The largest of the large players have how made big bets on the cloud and have entered the market in a big, big way. For more than a decade, other companies hosted Microsoft technology, with Microsoft showing little interest beyond selling licenses via them. Now Microsoft themselves are also the hosting provider. Does that mean most the hosting providers will have the fate of Netscape? Or will they manage to survive the dance with Goliath like Citrix or VMWare have?

For those who are not Microsoft or Amazon…


Imagine you have been hosting SharePoint solutions for a number of years. Depending on your size, you probably own racks or a cage in some-one else’s data centre, or you own a small data centre yourself. You have some high end VMWare gear to underpin your hosting offerings and you do both managed SharePoint (i.e. offer a basic site collection subscription with no custom stuff – ala Office 365) and you offer dedicated virtual machines for those who want more control (ala Amazon). You have dutifully paid your service provider licensing to Microsoft, have IT engineers on staff, some SharePoint specialists, a helpdesk and some dodgy sales guys – all standard stuff and life is good. You had a crack at implementing SharePoint multi tenancy, but found it all a bit too fiddly and complex.

Then Amazon comes along and shakes things up with their IaaS offerings. They are cost competitive, have more data centres in more regions, a higher capacity, more fault tolerance, a wider variety of services and can scale more than you can. Their ability to execute in terms of offering new services is impossible to keep up with. In short, they slowly but relentlessly take a chunk of the market and continue to grow. So, you naturally counter by pushing the legitimate line that you specialise in SharePoint, and as a result customers are in much more trusted hands than Amazon, when investing on such a complex tool as SharePoint.

But suddenly the game changes again. The very vendor who you provide cloud-based SharePoint services for, now bundles it with Exchange, Lync and offers Active Directory integration (yeah, yeah, I know there was BPOS but no-one actually heard of that). Suddenly the argument that you are a safer option than Amazon is shot down by the fact that Microsoft themselves now offer what you do. So whose hands are safer? The small hosting provider with limited resources or the multinational with billions of dollars in the bank who develops the product? Furthermore, given Microsoft’s advantage in being able to mobilise its knowledge resources with deep product knowledge, they have a richer managed service offering than you can offer (i.e. they offer multi tenancy :).

This puts you in a bit of a bind as you are getting assailed at both ends. Amazon trumps you in the capabilities at the IaaS end and is encroaching in your space and Microsoft is assailing the SaaS end. How does a small fish survive in a pond with the big ones? In my opinion, the mid-tier SharePoint cloud providers will have to reinvent themselves.

The adaptive change…

So for the mid-tier SharePoint cloud provider grappling with the fact that their play area is reduced because of the big kids encroaching, there is only one option. They have to be really, really good in areas the big kids are not good at. In SharePoint terms, this means they have to go to places many don’t really want to go: they need to bolster their support offerings and move up the SharePoint stack.

You see, traditionally a SharePoint hosting provider tends to take two approaches. They provide a managed service where the customer cannot mess with it too much (i.e. Site collection admin access only). For those who need more than that, they will offer a virtual machine and wipe their hands of any maintenance or governance, beyond ensuring that  the infrastructure is fast and backed up. Until now, cloud providers could get away with this and the reason they take this approach should be obvious to anyone who has implemented SharePoint. If you don’t maintain operational governance controls, things can rapidly get out of hand. Who wants to deal with all that “people crap”? Besides, that’s a different skill set to typical skills required to run and maintain cloud services at the infrastructure layer.

So some cloud providers will kick and scream about this, and delude themselves into thinking that hosting and cloud services are their core business. For those who think this, I have news for you. The big boys think these are their core business too and they are going to do it better than you. This is now commodity stuff and a by-product of commoditisation is that many SharePoint consultancies are now cloud providers anyway! They sign up to Microsoft or Amazon and are able to provide a highly scalable SharePoint cloud service with all the value added services further up the SharePoint stack. In short, they combine their SharePoint expertise with Microsoft/Amazon’s scale.

Now on the issue of support, Amazon has no specific SharePoint skills and they never will. They are first and foremost a compelling IaaS offering. Microsoft’s support? … go and re-read part 2 if you want to see that. It seems that no matter the big multinational, level 1 tech support is always level 1 tech support.

So what strategies can a mid-tier provider take to stay competitive in this rapidly commoditising space. I think one is to go premium and go niche.

  • Provide brilliant support. If I call you, day or night, I expect to speak to a SharePoint person straight away. I want to get to know them on a first name basis and I do not want to fight the defence mechanism of the support hierarchy.
  • Partner with SharePoint consultancies or acquire consulting resources. The latter allows you to do some vertical integration yourself and broaden your market and offerings. A potential KPI for any SharePoint cloud provider should be that no support person ever says “sorry that’s outside the scope of what we offer.”
  • Develop skills in the tools and systems that surround SharePoint or invest in SharePoint areas where skills are lacking. Examples include Project Server, PerformancePoint, integration with GIS, Records management and ERP systems. Not only will you develop competencies that few others have, but you can target particular vertical market segments who use these tools.
  • (Controversial?) Dump your infrastructure and use Amazon in conjunction with another IaaS provider. You just can’t compete with their scale and price point. If you use them you will likely save costs, when combined with a second provider you can play the resiliency card and best of all … you can offer VPC 🙂


In the last two posts we looked at some of the areas where both Microsoft and Amazon sometimes struggle to come to grips with the SharePoint cloud paradigm. In this post, we took a look at other cloud providers having to come to grips with the SharePoint cloud paradigm of having to compete with these two giants, who are clearly looking to eke out as much value as they can from the cloud pie. Whether you agree with my suggested strategy (Rackspace appears to), the pattern of the auto industry serves as an interesting parallel to the cloud computing marketplace. Is the relentless consolidation a good thing? Probably not in the long term (we will tackle that issue in the last post in this series). In the next post, we are going to shift our focus away from the cloud providers themselves, and turn our gaze to the internal IT departments – who until now, have had it pretty good. As you will see, a big chunk of the irrational side of cloud computing comes from this area.


Thanks for reading

Paul Culmsee

 Digg  Facebook  StumbleUpon  Technorati  Slashdot  Twitter  Sphinn  Mixx  Google  DZone 

No Tags

Send to Kindle

A brief sojourn into the world of Exchange 2010

Send to Kindle

Okay so this post is going to seem way out of place because it has utterly nothing to do with SharePoint and instead focuses on Microsoft Exchange Server. To explain why I have to give you a quick history lesson.

Before I was a SharePoint guy, I was a networking, infrastructure and security guy. In fact I met and worked with Jeremy Thake before either of us were full-time SharePoint guys. If you were to ask him I’m sure he would tell you I was a bit of an infrastructure and security nazi back then. What warms my heart though is that since then I have mellowed out and now Jeremy has taken on some of those nazi tendencies (I have heard him threaten to “hunt you down if you do that” at user group presentation – referring to some dodgy SharePoint developer practice that will hurt you later).

Anyways, I still get asked to do the odd bit of Cisco, Active Directory and Exchange work. Although my interest in these areas is practically nil, some part of me likes to have a crack at it every so often to make sure I can get on the bike again – so to speak. Each time I get on the bike, I then remember why I got off in the first place ;-( (It’s a bit like eating KFC – you swear you will never do it again but given enough time, the pain seems to fade)

This time around, I agreed to help a client extricate themselves from the evil nightmare that is Small Business Server 2008, to real, grown up Windows Server environment. They had outgrown SBS and had been taken over by a foreign company and there was a need for AD domain trusts, among many other things – something that SBS can’t do. As part of this I had to get Exchange, SharePoint, AD, WSUS, Certificate services and various other things like RRAS, DHCP and DNS off the Small Business Server and onto real servers.

So first up my big Exchange 2010 lesson learned and then some detail on how you too can make Small Business Server 2008 history in your organisation.

My first and last exchange post: Exchange 2010 RTM and SP1 do not play nice!

Due to the nature of this upgrade, I had to set up a temporary exchange server 2010 box to be a temporary mailbox store. Provided that any Exchange 2007 servers in the organisation are running Service Pack 1, mail can happily route between Exchange 2007 and 2010 servers. Once the migration of mailboxes was complete, we decommissioned the Small Business Server following the steps outlined in the next section. We then installed a fresh, new Win2008R2 + Exchange 2010 as the final server – only this time with Exchange 2010 service pack 1 (the client used newer media this time).

All went well, the new server installed fine. So now I had two Exchange 2010 servers in the organisation, one RTM and one SP1. I was able to manage both servers using Exchange system manager on both servers and there was nothing untoward in the logs on either server.

However, when I tried to move a mailbox from the RTM box to the SP1 box, I received the following error:

Service ‘net.tcp://<servername>/Microsoft.Exchange.MailboxReplicationService’ encountered an exception. Error: MapiExceptionNoAccess: Unable to open message store. (hr=0x80070005, ec=-2147024891)

Diagnostic context:
    Lid: 18969   EcDoRpcExt2 called [length=132]

[blah blah blah skip ugly stack trace stuff]

Exception details: MapiExceptionNoAccess (80070005): MapiExceptionNoAccess: Unable to open message store. (hr=0x80070005, ec=-2147024891)

[blah blah blah skip more ugly stack trace stuff]

As you can see, not a helpful message at all. So I tried to initiate the mailbox move from the SP1 server instead of the RTM server. This time, I received a different error:

There are no available servers that are running the Mailbox Replication Service.
+ CategoryInfo : NotSpecified: (0:Int32) [New-MoveRequest], MailboxReplicationTransientException + FullyQualifiedErrorId : 5C08CF31,Microsoft.Exchange.Management.RecipientTasks.NewMoveRequest

Now as Johnny says, this error suggests that no exchange server in the organisation is running the mailbox replication service. However in my case the RTM box was running this service and it was started. Clearly something was amiss.

Google didn’t show much about this problem, and I considered calling Microsoft support, but knew full well that they would probably make me install SP1 on both boxes before investigating. So I installed SP1, following Gnawgnu’s advice about surviving an Exchange 2010 Service Pack 1 install. All went smoothly and when I reattempted the mailbox move, everything worked fine.

Moral of the story, apparently a stack trace is an appropriate error message for an incompatibility between Exchange versions. C’mon exchange product team, you are no better than SharePoint in terms of horrible error messages. Surely a version check would be an easy use-case to test for?

How to extricate yourself from Small Business Server 2008

For what its worth, getting SBS2008 out of your domain is a bit like pulling teeth. It really doesn’t want to go. Nevertheless it can be done and I largely followed this unofficial guide and can confirm that it works for me (I have added a couple of steps below, and also remember, this is SBS2008 we are talking about so its bound to go wrong somewhere)

1. Upgrade the AD schema of the SBS2008 domain

  • Using your new Win2008 R2 media find the adprep utility and run: Adprep /forestprep and Adprep /domainPrep
  • On SBS 2008 ensure that the schema version is updated to 47 and *not* 44 by checking the HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\Schema Version registry key

2. Install Win2008R2 on your soon to be new domain controller and add it as a member server of your SBS2008 domain

3. Install the Active Directory Domain Services role and then launch the Active Directory Domain Services Installation Wizard (dcpromo.exe).

  • On the Choose a Deployment Configuration page, click Existing forest
  • On the Additional Domain Controller Options page, make sure the DNS and Global Catalog is checked
  • Check all of your group policies for reference to the original SBS server and repoint to the new AD server (recreating share folders where necessary)
  • Move FSMO roles to the new AD server:;EN-US;255504
  • Add the AD certificate services role and backup/restore the certificate store
  • Install DHCP and backup/restore config from SBS box and then remove DHCP role from SBS2008
  • Change DHCP scopes so DNS points to the new DC, as well as statically assigned devices

6. Install Win2008R2 on your soon to be Exchange Server and install Exchange 2010 (with the hub, client access server and mailbox roles)

  • Patch Exchange 2007 on your SBS2008 Server to SP1 if it is not already (otherwise you cannot move mailboxes to the Exchange 2010 server)
  • Note: You need to download a special Exchange SP1 installer for Small Business Server as the default installer will refuse to install on account that a SBS box does not meet minimum conditions for install
  • Move mailboxes and public folders from SBS2008 server to the new Exchange 2010 Server
  • Export IIS certificates from the SBS2008 server to the new server and then set up client access (OWA, ActiveSync and Outlook Anywhere) with the same certificate
  • Reconfigue your router/firewall to the ne server for OWA/Activesync/Outlook Anywhere

7. Uninstall Exchange 2007 from SBS 2008

8. Install Win2008R2 on your soon to be SharePoint Server and install Search Server Express 2010 or whatever SharePoint edition you have paid for

  • Create a new web application
  • Restore Companyweb site using database reattach method
  • Reconfigure companyweb search to use enterprise search template that comes with Search Server Express 2010
  • Install Microsoft fax (if you used faxing in SBS2008) and enable email based fax routing
  • Configure incoming email to SharePoint by configuring a subdomain in active directory and configuring a remote domain in Exchange 2010 Hub Transport
  • Mail enable the Faxes document library in companyweb
  • Set the destination for faxes to be the Faxes document library in companyweb

8. DCPromo down SBS 2008 and remove SBS 2008 from the network.

9. Crack open a beer and celebrate your victory


Thanks for reading

Paul Culmsee

 Digg  Facebook  StumbleUpon  Technorati  Slashdot  Twitter  Sphinn  Mixx  Google  DZone 

No Tags

Send to Kindle