The SharePoint 2010 Challenge – Planning Your Service Apps

I got a brilliant Question a while back at a SharePoint 2010 event.  During the Q&A someone asked… are Service Apps easier to manage than the old SSP?

Why is that such a brilliant question?  Because there are so many levels to the answer to that question.  The container of services such as the SSP has become so flexible, I’m finding just getting my head around proxy groups, service instances, and services with sync and dependencies that it’s easy to say No way!  Today I have to say man the service app alone has grown exponentially in SharePoint 2010.  You start digging and you get deeper and deeper and it keeps going!  I’m working on a deck for Teched on Global Deployments and I’m finding it’s very difficult to simply explain the dependencies and how the metadata service would work across the WAN.  The posters have been the most helpful as I’ve found there really isn’t much written on how to deploy services across the wan just yet.  I do promise to put together my thoughts on the topic following this presentation.  Global SharePoint 2010 has tons of potential.  Obviously we still don’t have replication, but did you know you can deploy multiple metadata services and designate one as primary?  I didn’t, but I’m finding as I keep digging these service apps and what they are continues to provide more solutions and more flexibility.

Here’s a few things to get your head around…

Are there services in SharePoint that are not Service Apps?

Yes, there are many… they are listed in “services on server” the section in Central Admin that ultimately determines what you’re running on your boxes.  The only one that’s required to run on the web front end is the SharePoint Foundation Web Application.  The inbound email is another common example of a service that usually is configured on a front end or two if you know what you’re doing.  That Foundation Web Application is actually a requirement to run on all WFEs, don’t forget it! If that service isn’t running you’re WFE box is effectively down.  The service should only be stopped on the App tier.

• SharePoint Foundation Incoming Email
• Foundation User Code Services
• WSS Workflow Timer Service (Legacy)
• Application Registry (BDC Legacy)
• Doc Conversion Launch
• Doc Conversion Load Balancer
• SharePoint Foundation Web Application (WFE)
• SharePoint Foundation Search (Help)

Is there one search database?  How many search databases can I expect?

There are many.  In fact the larger the environment the more property and crawl databases you’ll get.  You’ll also see the Search Query and Site Settings Service for managing the search settings that are configured per site collection.  The Search Server Search service has it’s own database as well.  The databases and configuration should be deployed

• Search Administration
• Property Store (larger deployments may have many)
• Crawl store (larger deployments may have many)
• SharePoint Foundation Search (Help)

Don’t be confused if all you see is this dialog in the posters. 

 

The Profiles don’t just rely on one database either… or just one service for that matter.  If you’re wondering why profiles don’t work, make sure you are following the path of making sure that social tagging and managed metadata service are also enabled.  These are dependencies that aren’t very apparent though the UI.  Some people will think Profile Sync is to another Profile Service.  It’s actually required for synchronizing between Active directory.  There’s a lot to get your head on around here.  I’ve been enjoying Octavie’s blog a new one for me, but very rich with information.

I’ve heard a lot of complaints about mysites or profiles failing to be configured properly.  I suggest reading these two articles.  First Octavie’s Setting up User Profiles Service Application, he learned by making mistakes.  I like those kind of articles.  The setting up the managed metadata service is good stuff too.  Remember you can and should I’d say, plan on having local managed metadata services even if only used for cache and designating the main one as primary.  Wish there were more good examples of global deployment step by step configurations out there.

The TechNet article “Configure Profile Synchronization” is a new article only as old as May 12.  Very fresh and relevant.  How about the hidden “Profile Synchronization does not work on a stand-alone installation for SharePoint Server 2010.” That’s wild isn’t it!

As well people who have ever installed or configured an application.  Ever heard “After starting the User Profile Synchronization service, wait for 5-10 minutes before proceeding to the next step.”  That’s actually very important.

These services are started automatically when the User Profile Synchronization service is started. It may take up to 10 minutes for these to start after starting the User Profile Synchronization Service. Do not start them manually.

Some Free “15” Planning Feedback SharePoint Team…

This request it to make the deployment and configuration easier.  Request is for a wizard.  Let’s come up with Service App Proxy Groups that essentially bring together groups of functionality.  I know we just got out from under the SSP grouping, and it being to restrictive, now we’re on the opposite end of the spectrum where you pick and choose everything, but it could be easier if you said.  I want Search! or I want ECM or I want Social Mysites and Profiles and you got all the services and dependencies all getting configured in a nice little wizard.  It’s tough to know what the options are and what’s required.  If you don’t know what the questions and options are, how can you effectively deploy in the best configuration?

In the meantime… Would also be nice to have some serious guidance around how to pull off Enterprise Managed Metadata.  There are lots of nice hints, but this is something that could really be put together that shows how the primary and synchronization and using it as a true global service such that the AJAX works, and the branching of the term store works by region, but also gives you the real nature of enterprise managed taxonomy.  There’s a set of docs we need for IT and a set of docs for the business.  Sounds like an SDPS for Enterprise Information Management.

In my next post on Service Apps I’ll discuss more about the global aspects…