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.

Silicon Anniversary

It's January - Bob and I will celebrate our fifteenth wedding anniversary this year!

The Iron Anniversary in 2010 brought us the HyperV host that runs SharePoint 2010 (plus other VMs, including a MineCraft VM server that our sons enjoy).  Looks like this year is the Silicon Anniversary - time for more memory so that we can fire up additional VMs.  I'm installing the Systems Center 2012 suite to kick the tires before it is released in April, and have started with Systems Center Service Manager.

What's that got to do with SharePoint?  In the past few years all the Microsoft server products have been converging on the use of the SQL database engine, SQL Reporting and Analysis Services, Web Services, and SharePoint.  If you are used to being 'just the SharePoint Administrator' get ready for a wild ride because all the Microsoft products will have pieces that need to be installed in your SharePoint farm.  You're now not just the 'enterprise collaboration' guy, you are also the ERP portal guy, and the Infrastructure Operations portal guy.

All this convergence makes a huge amount of sense.  Deploying every Microsoft product in its own silo with databases and web portals deployed on application servers is a waste of licensing and limits your ability to scale out the system.  In my HyperV world (at this time) I only have 4 CPUs per VM, so I always make sure I'm deploying products in a scale out configuration, even if it means just starting with two load balanced application servers or a two node SQL cluster.  That way I can always add capacity later without completely reconfiguring the system.

In reality, even if this is where Microsoft is heading and it all makes sense, it's painful getting there.  Take a product like AX 2012 for instance, which includes the following components:
- Application Server (AOS)
- Transactional Database and Analytics (SQL Database Engine and Analysis Services)
- Reporting (SQL Reporting Services)
- Web Services for data access and systems integration
- Enterprise Portal (SharePoint)

Say we've seen the future and have drunk the scale-out kool-aid, and want to deploy AX in a fully scaled out configuration.  It's pretty straightforward to deploy the AOS cluster, but the explanation of the actual clustering technology and techniques is confusing since there is AX specific load balancing, as well as ways you can use Microsoft NLB in addition to the AX specific clustering.  The documentation on why you might want to do this, or not, is not clear.

You would also want to deploy the AX reports in a separate, scaled out, SSRS environment - this is also painful.  We have a separate two node NLB cluster for Web Services, so this was relatively easy.  The AX Help Server is just a standard web application (but why not use our existing SharePoint farm for this?).   Saving the best for last, we have the AX Enterprise Portal.  The deployment of the AX Enterprise Portal on our scaled out SharePoint farm was a huge pain due to the lack of information that a SharePoint administrator needs.  We had to open a Premier incident and get previously un-published documentation. 

If Microsoft really wants us to buy the Hyper-V scale out deployment model, the ideal set of information on every product would include the full scale out topology option and documentation of how and when to use Microsoft NLB (or other load balancers like F5) as needed to configure the scale out scenario.  It would take into consideration the integration with existing scaled out deployments of SQL and SharePoint.  Most installation documentation I see assumes you are starting with a brand new environment, not existing SharePoint farms or SQL clusters.  Heck, I can get any product installation to work when I install everything on one VM in an isolated environment, but that does me no good in the real world.

So, I'm curious to see how the Systems Center products play in the real world...  I'm not planning to install a completely separate SharePoint farm, SQL cluster or SSRS environment just for Systems Center when I can continue to scale out the environment I've got...  I think this is where Microsoft wants it all to go, but based on my experience with AX 2012 they are not making it easy.

If Microsoft is converging on SQL and SharePoint for applications like AX and Systems Center, I'd like to see more load balancing information and deployment documentation written for the SQL and SharePoint administrators who live in the real, scaled out, world.  Maybe for my next anniversary (the Cloud Anniversary?)...

Fear of Folksonomy

I'm a big believer in the saying that some things are better left unsaid, but in the age of Twitter, Facebook and teenagers running up thousand dollar phone bills by texting, I seems that everyone wants a chance to say what's on their mind (even bloggers...).

I had the opportunity to deliver presentations and demos in a SharePoint 2010 SDPS (SharePoint Deployment Planning Service offering) for a customer who was very interested in the new social networking and communities features as a way to get physicians to collaborate on specialties and practices.  I deployed the 2010 RTM bits on my Hyper-V environment and built an 'Org Chart' out of reporting relationships in Active Directory, and imported some managed meta data from a company in Germany that provides meta data... check out their offerings here.  Very cool!

We demonstrated document and page tagging, document rating, and 'tag cloud' features (among other things), and then one of the participants started to look a little worried.

It never fails - a 'cool feature' to one customer is an absolute nightmare to another...

The discussion started with a question on how to control the ability to tag pages and documents, so that search wouldn't be influenced by people randomly tagging pages, and led to a discussion of the managed meta data service and ways to 'lock down' taxonomy facets and allow business subject matter experts to manage taxonomy.  There was a great concern that some employee might decide to tag a document with something like 'this sucks' (pardon the language), and this led to a discussion on whether the use of Microsoft Forefront could help police language used in social tagging.

I absolutely understood and sympathized with their concerns - nobody wants to demonstrate a great new collaboration tool to an executive, bring up the tags and notes associated with a press release announcing the executive's recent promotion and read a tag that says 'idiot'... that would be the definition of a bad demo.

So, how do we introduce the full set of social networking capabilities and benefits into an organization that wants some structure and ground rules?  As I always say, the technology is the easy part.  One approach would be to prohibit people (all, or selectively) from tagging pages and documents. The social tagging features of SharePoint 2010 are enabled by default, but you can disable them by removing the Use Social Features permission through the User Profile service.  See here and here for more information.

Another, more complicated approach is to undertake the change management needed to educate and train users, and think through just how this type of information might be monitored and harvested for the benefit of the organization.  If tagging is introduced as a way to help the organization understand and gather employee feedback, and it's made clear that the feedback is *not* anonymous and no inappropriate comments will be tolerated, there will always be the random 'this sucks', but those tags can be traced directly to the author for a 'heart to heart' follow up discussion with HR...

And just imagine, what if these features were available at Enron and Goldman Sachs, and small handfuls of employees started tagging financial information or trading reports with things like 'unethical?' ?

Maybe we're not ready to hear everything that everyone has to say, but maybe we could be...  I'm interested in seeing where social networking can take hold in Corporate America and seeing where it leads.  Remember, the technology is the easy part.

Iron Anniversary

So, my husband and I are both married to big geeks.  Now *that's* over with, I have to say I'm really excited about running SharePoint 2007 and now SharePoint 2010 (beta) at home.

By home, I mean that since hubby and I are both in 'the business' (product development, tech consulting) he wound up putting a tower rack in our basement some years ago.  We run more servers at home than I've seen deployed at many small companies (or possibly, some small countries).

Since we are both notoriously hard to buy gifts for, when our anniversary rolled around last year I told him what I really wanted.  A server in the rack that was hefty enough to run several virtual servers under Hyper-V.  Being a guy, I'm sure he thought this was almost (but not quite) as good as me saying I'd really like a busty woman to come to our house and give us both backrubs, so I did get a really awesome Hyper-V server for our anniversary.

I was amazed at how much iron you can get for your money these days.  Since we lived in Boston some years ago we've purchased servers from PC's For Everyone, and our new dual-quad-proc (eight core) 1U server with 16GB RAM was just a little over two grand.  That really floored me, coming from environments that typically budgeted tens of thousands of dollars for that class of compute power.

Of course, I failed to anticipate how busy I was going to be last year.  I finished my last few classes in night school, consulting by day and studying on nights and weekends.  Hubby set up the Hyper-V server and moved our domain controller to a virtual server, but the Iron Giant was not put to much use last year.  Sigh.

But, I finished my MBA at the end of the year, and re-focused my brain cells on our server infrastructure.  Before long I had our home portal up on SharePoint 2007, just in time to post the kids' summer activities schedules to the family calendar.  Then, last week I took the plunge and set up the SharePoint 2010 beta in a separate virtual server, with the databases for both the 2007 and 2010 farms on an instance of SQL2008 (SP1, CU2) running in yet another virtual server.  My virtual SharePoint kingdom is running like a top.

Having my first 'hands on' look at SharePoint 2010, the first things that jumped out while poking around the home page of my portal were:

• Pulldowns on the left, pulldowns on the right.  Site actions was moved to the left on the default home page.
• The inescapable ribbon.  Although you have to click on the 'Page' tab to see it, things like editing the page or setting permissions and properties are now exposed as big icons on an Office-style ribbon.
• Top-tabs and Uber-breadcrumbs (not the Microsoft sanctioned terms for these things, by the way). I created a document library for OneNote Pages (new!), and from the top 'Browse' tab you can see the normal bread crumb path, but the end of the breadcrumb path now shows your current view.  There's a dropdown off the end of the breadcrumb path that provides actions to create/modify views.  This is easier to find than the old view dropdown on the upper right corner of the screen.
• Other 'Top-tabs' for Custom Commands and Library Tools follow the default 'Browse' tab, and, there's a little folder with an 'Up' arrow that gives you a folder type of breadcrumb navigation if you need it.  I'm thinking this might help people who are still using directories on a shared fileserver understand SharePoint navigation if they haven't yet made the leap.
• More 'page oriented', like a multi-page website that has neat document and list management capabilities.  I have to say SharePoint 2007 has awesome document and list capabilities, but you sometimes wonder if the 'web page / web site' side of it was an afterthought.
• Selections of themes includes heading and body font selections - one small step in the direction of more 'point and click' customization on the look and feel front.

And so much more - but, I'm rambling.  Overall, I'm pretty excited about what I see - and am looking forward to digging in with SharePoint Designer and Visual Studio 2010 to have even more fun.

I wonder what I should ask for as an anniversary gift next year....

System.Console.WriteLine("Hello, Blog!");

It's a great feeling to jot the first lines into a pristine new blog.  Nothing but potential....

Now that's over with, I can get on with the whys and wherefores.  I created this nook in the blogosphere to capture thoughts and stories about adventures with Microsoft SharePoint and related technologies.  I've been connected to SharePoint as a business customer and technology consultant since its early incarnations, but I don't consider myself a technical guru - perhaps more a a technical tourist...  Technology has a way of constantly leveling the playing field, and with the release of SharePoint 2010 we're all back near square one.  I'm looking forward to climbing the learning curve again.

The area in which I do claim some chops is finding interesting and simple ways to apply tools and platforms like SharePoint in the workplace.  Or, at least it's what I enjoy best about working with technology - working with people who have to get a job done, and finding ways that I can make things easier or more interesting using technology.

I was inspired to get on this blog-wagon by an old friend, and a new friend.  My new friend is Dan Lewis, already a bright star in the SharePoint universe, who blogs as the SharePoint Comic.  And, because of a recent adventure in SharePoint, I reconnected with an old friend, Marc Anderson at Sympraxis Consulting, who blogs about bending SharePoint to his will in all sorts of ways, including jQuery and xsl.  Marc helped me out of a jam with his jQuery library (but more about that in another post).

So, with thanks to my inspirations, I hereby christen this blog -
Stay tuned for more SharePoint adventures (I know I will)!