How to drive a SharePoint Admin crazy

I missed an opportunity by not bringing the SharePoint team to a recent SQL PASS conference, where our DBAs scored several sessions about SharePoint (my favorite session title: "The New Hotness - SQL 2012 and SharePoint 2013"). 

The SharePoint team is feeling the heat; SharePoint is part of the Microsoft BI stack and provides the portal foundation for a number of Microsoft products (AX, CRM, Systems Center, Project Server, SSRS, PowerPivot...).

If you want to drive your SharePoint Admins (SPAs) crazy, just tell them they are part of all these efforts, and will need to integrate all the related Microsoft products into their SharePoint farm.  We are part of the ERP team (AX), the ITIL adoption effort (Systems Center), PMO efforts (Project Server), and enterprise adoption of BI.  How would a normal SharePoint loving admin react to this?

They might grumble:  Why do we have to work with all these other teams who don't appear to know much about SharePoint or think it is just a glorified file share (and at times even say they don't like SharePoint because they can't find anything they're looking for)?  Can we get out of this frying pan before it gets too hot?  How are we going to manage and maintain all this integration?
Then bargain:  Let's just tell each project/product effort to deploy their own separate portal, maybe using SharePoint foundation or just IIS to save on licensing. 
Then rationalize:  This would probably result in multiple deployments of SharePoint or IIS by people who don't know how to administer or maintain it... sounds messy.  This type of thing is usually followed in a few years by a large 'portal consolidation' project, to bring the mess of many different and confusing portals together (I usually get those kinds of messy clean up projects, so hope to avoid it).

Then accept: Drinking the Kool-Aid from a fire hose now, we've deployed the following products, for integration with SharePoint 2013:
- SQL 2012 Reporting Services running in SharePoint 2013 integrated mode
- PowerPivot for SharePoint 2013
- Project Server 2013
- Dynamics AX 2012 R2 Enterprise Portal
- Dynamics AX 2012 R2 Reports deployed to SSRS 2012 in SharePoint 2013 integrated mode
- Systems Center Service Manager 2012 self service portal (this one integrated with SharePoint 2010)

(CRM would have been an addition to this list, but we are moving to CRM Online without any on premises SharePoint integration... yet.)

This exercise has convinced me of something I've always suspected:
Microsoft is thousands of programmers, coding in loose formation.

The process for integrating each of these Microsoft products with SharePoint is completely different, and for the most part not oriented towards the SPA.  In some cases you have the impression that the product views SharePoint as the 'add on' instead of the other way around...
As usual, installation instructions typically assume you are running on a single machine, not a small farm or distributed environment.  In the real world, we don't install everything on one VM.  Sigh.

Not to scare anyone away - the installation experience was not terrible for every product (just some), and our only consistent complaint about them all is that the installation instructions could be much clearer, and written for companies who run products in distributed environments, with different DBA and SPA teams.  I'm fortunate to have both DBAs and SPAs in my team, so we bring different perspectives and ideas together.  I highly recommend integrating DBA and SPA teams - after all, they have all your data.

I've graded Microsoft products below based on their ease of integration with SharePoint.  These are purely my own opinions; I am not privy to any Microsoft secrets or future plans.  Overall, I would rather see integrated rather than isolated solutions, but the challenge is consistency and maintainability. 

SQL 2012 Reporting Services running in SharePoint 2013 integrated mode:  B

• Installation was reasonable, but could have better 'quick start' documentation with steps taken by the SPA and DBA in the case where you already have a small farm, and the order in which you need to perform the steps, on which servers.  In addition, all installations should contain a step for the SPA to confirm the deployment. In this case, we created a report library and launched Report Builder to create a 'Hello World' report.
• It did seem that you could easily wind up with phantom SSRS service applications on the farm that did not clean up well after an uninstall.  Power Shell is our friend for cleaning up service applications that either do not start cleanly or don't uninstall cleanly.  This will come in handy when we need to patch. 
• The best part of this exercise is deploying SSRS in SharePoint integrated mode together with a SPA alongside a DBA who is used to 'owning' the SSRS server in Native mode.  Does the new Reporting Server belong to the DBA or the SPA?  I think we've sorted this out but it is an example of how we need to re-think operations and have more blended teams for integrated solutions.

PowerPivot for SharePoint 2013:  B

• Similar to the above, but a slightly higher grade because you don't have to install additional 'add ins' on the web front ends.  Better documentation is needed for steps from a DBA and SPA point of view (the DBA creates the database, the SPA configures PowerPivot).  Again, every integration like this also needs a documented way for the SPA to confirm the deployment.

Microsoft Project 2013:  A

•  I admit that so far we have only deployed Project 2013 on a standalone SharePoint 2013 VM, but the deployment process was fairly simple.  Since Project Server 2013 was designed to sit 'on top' of SharePoint from the beginning, the installation process was more oriented to a SharePoint deployment (I reserve the right to change the grade when we deploy to our test farm).

Microsoft Systems Center Service Manager's 'self service portal':  C-

• Note: This integration was deployed on our SharePoint 2010 test farm, and we are in the process of deploying Service Manager 2012 R2 with a SharePoint 2013 sandbox VM (I might revise the grade when this is complete).
• Customizations for the service request forms shown in the portal depend on custom management packs or customizations made in Service Manager console; this is extremely limiting.  For example, capturing a rich set of details for a new account request can be done fairly quickly and easily in a SharePoint list; including extensive request details in the Self Service portal is nearly impossible and cumbersome to manage.
• The user interface strategy for Service Manager's Self Service Portal will need a complete re-invention in order to compete with cloud services such as Service Now.
• I would avoid investment in a lot of Service Request customization for the Self Service Portal for the reasons above.  If Microsoft changes the customization approach for Service Requests you never know what will be deprecated (as with AX, see below). 
• Service Manager should clearly be the single source of recording requests, request status, assignments, and request metrics, but I see it as a 'wrapper'.  For complex Service Requests I recommend using Service Manager to track the high level request, but keep the request detail data in something more flexible (e.g. SharePoint list or attachment) until we have a more mature Self Service portal.

AX 2012 R2 Enterprise Portal:  D

• The AX 2012 R2 product claims support for SharePoint integration, but by the time you complete an Enterprise Portal deployment on SharePoint, you'll learn a lot about AX administration.  To me, the AX product views SharePoint as the 'add in', not the other way around...
• As with the above, installation instructions are not oriented towards SPAs, and assume everything is on one VM.  When AX product code is deployed on your SharePoint servers it limits our ability to have separate webs for staging and production.
• Installation instructions were not oriented towards the the case where there is an existing SharePoint farm with multiple webs.  Our initial deployment resulted in a great deal of quality time with Premier Support.
• We've recently been told that Microsoft is moving away from investment in the Enterprise Portal and will re-invent the AX client as an HTML5 application. 
• Without knowing any details behind this direction, my take is that Microsoft understands the misstep in the architecture of the Enterprise Portal, and may be embracing an app model for the AX client.  Hopefully this will be aligned with the app model in SharePoint 2013 (or even better, a general convergence across the app models in Microsoft products).

AX 2012 R2 integration with SSRS 2012 when running in SharePoint integrated mode: F

• Along the way with AX 2012 R2, we've reached out to Microsoft for help with issues with AX 12 integration with SharePoint, but the Reporting Services integration was the bumpiest interaction.
• From the SPA and DBA side, we started by ensuring that the SharePoint web was healthy, and then that Reporting Services could render reports.  After that, it was nearly impossible to convince AX 2012 R2 to deploy reports to that working reporting environment.
• Finally, after much patience and persistence from Microsoft, our SPAs, DBAs and AX team, we realized that the AX integration can not work through load balanced SharePoint web front ends (we created a host record on the AX AOS server to get around this), and also had to move the SharePoint Central Administration service to the same farm server running the SSRS application service.  Not something our SPAs are very comfortable with, but it allows AX to publish reports.

Especially for our adventures with AX 2012, I wanted to give a shout out to Microsoft Premier Support - thanks for your time and patience, in a tough spot between the product and the customer.

In moving to a 'cloud first' release strategy I hope Microsoft doesn't lose sight of the deployment challenges for companies who choose to run hybrid or fully on-premises environments.  For any product that provides a portal, this could be as simple as including deployment steps for the case where you already run SharePoint, and cases where you don't.  And, avoiding the assumption that everything runs on a single VM.

I'm not claiming integration is right or wrong - there are always trade offs between integration and isolation of business solutions and data.  I tend to look at SQL, SharePoint, Systems Center, AX, CRM and custom applications as part of the same ecosystem, and not separate solutions, but know that sometimes it's hard to get the SPA to look at things from the DBA's view and vice versa.  The pendulum swings back and forth on unified environments and application silos every few years, and we appear to be heading into the 'Apps' wave, wherever that will lead.  I'm excited to see where we converge, and what doesn't quite fit the model, and will be doing my best not to drive the SPAs too crazy along the way.