Making Sense of the SharePoint World

May-272010

Successful SharePoint 2010 People Search

MC900139387[1]

Finding your Way through the Configuration Maze

SharePoint has two basic configuration modes:

- SharePoint sets up "Everything" for you
- You set up "Everything" manually

There is precious little in between these two extremes. The good news is, if you let SharePoint configure everything, chances are everything will work. The bad news is, these settings rarely reflect best practices, and if (when?) you want to tweak some of those settings later you often find that one change has to lead to another, and another, and another in order to get back to working order. By the time you're done you may as well have done it manually in the first place.

Configuring SharePoint 2010 to do people search is one such area. The first half of the manual configuration (or reconfiguration) process is setting up the User Profile import. That is fairly well documented in several places. Probably the best is by fellow MVP Spencer Harbar in his article "A Rational Guide to Implementing SharePoint Server 2010 User Profile Synchronization".

The Bread of the Sandwich

Given how comprehensive Spencer's article is, you wouldn't think that there is anything more to say, and in truth, it is the meat of the issue and often the hardest part to get working. But as I said, that is only half of the story - getting user profile data into SharePoint. What my article is about is letting your users find the information. Since some of this comes before, and some comes after, the AD configuration in Spencer's article, you could think of this as the bread of the sandwich.

Once Central Administration is up and running, the first thing it offers is the opportunity to let another Wizard configure all of your service applications for you, and set up a default SharePoint web application. If you followed Spencer's advice, you said "No" to its kind offer. His article assumes you did, and gives instructions for setting things up completely manually. For this article, I'll assume you said "Yes" and want to fix things up. For completeness, I cover some of the same ground, and you can safely follow either set of instructions for creating the User Profile Sync service app.

Again, if you say "Yes", you'll get something that works. But if you look carefully, you'll discover two big things that violate good configuration practice for production environments:

The Search service application is configured to use the Server Farm/Database Access account as the default content access account.
My Sites and the Profile host site collection are configured to live within that first web application, which is named with the host name of your central administration server.

The first one is easy to address - on the surface. Create a suitable domain account, then in Central Administration, go to your Search service application and assign it to be the default content access account.

SharePoint will give it a default read policy on every web application associated with that service application. That's great as far as it goes, but hold that thought for a moment. I'll be coming back to it shortly.

As for the second issue, having the personal sites embedded in a content web application, you'll need to delete and re-create the User Profile Service application to resolve that. Or create the service application for the first time if you didn't invoke the wizard. Whether correcting from the wizard or creating the applications for the first time, other than the deletion, the steps (and some of the potential issues) are the same.

First, create a "normal" web application for your profiles and personal sites. Create a site collection at the root of the web application using either the "Blank" or "MySite Host" template.

Second, go to your Service Applications page and from the New button select User Profile Synchronization service application. Like most service applications, this one requires you to allocate an application pool and number of databases. The page suggests leaving them as the default names, which you can, though if you do make sure the databases from the original service application (if any) are deleted first. Otherwise, give them appropriate names for your environment.

Toward the end of the configuration page, specify the server in your farm that you want to host the profile sync service, and enter the web application you defined in the previous step.

MyWebApp

After you accept your settings, wait for the service application to finish creating. (You will return to the UI before that process completes.) Now would be a good time to go read Spencer's article to see what you should have done to get to this point, and have your AD administrator set the permissions required for your profile import account.

By that time, you should be able to complete the User Profile service application configuration as instructed.

The Last Piece of Bread

In a perfect world, you would be done. Of course, we don't live in a perfect world. Chances are, you'll get a wonderful set of profiles imported, and you can navigate to them and see everything. If your users create MySites, you'll probably even be able to find their content. But do a people search, and you get a whole bunch of "nothing". That's because you're not actually crawling the profile store - at least not successfully.

Time to go back to Central Administration, and first look at your Search service application's management page. Click the Content Sources link on the left hand side, and open/edit your Local SharePoint Sites content source. In the Start Addresses section, you will see a box with entries similar to those below:

Notice the sps3: line. This is the protocol SharePoint uses to read profiles. (Note: It isn't a "protocol", per se. It just instructs SharePoint to call a specific web service hosted at that address.) If you ran the wizard to configure your service applications, it will be pointing at the original web application created by it. You'll need to change it to reflect your new profile web application, then save the changes to your content source definition. Also, if you deleted the original wizard-created web application (or aborted its creation), you'll need to delete the regular http: line referencing it.

You might think (again) that that's all there is, but again you'd probably be wrong. Once you make the change above, you'll probably start seeing access denied errors on that "server". Remember when we assigned a new default content access account way back in step one? Well, even though it has permission to read the contents of the web site, the service under the sps3 protocol leads right back to the User Profile Synchronization service application, and you didn't tell that application to let the new content access account in.

To do that, navigate to the Manage Service Applications page, and highlight your User Profile Service Application. Click the Administrators icon in the ribbon.

ProfileAdmins

You'll need to add your default content access account to the list of "administrators". It won't really be an administrator - notice that there are an array of permissions available. Once you add the account, highlight it and ensure that the "Retrieve People Data for Search Crawlers" permission is checked, as shown below:

PermissionDialog

Click OK, and reset IIS on the profile import server. Maybe even reboot it.

Best Practices?

At last, you're done. You should now have functioning user profiles and people search, configured in accordance with "best" practices. (Yeah, "best" is relative...) Still, there are reasons for this kind of configuration. It gives you an easily manageable farm, with excellent control over My Sites - ensuring that personal content is in separate databases from your corporate portal data. The account used to crawl won't be the "all powerful" Farm account, and you can tell the difference through access and audit logs between administrative access to resources and the search crawler's.

Now, wasn't that a tasty sandwich?

Published: May-27-10 | 5 Comments | 0 Links to this post
Tagged as: Administration, Architecture, Governance, Search, SharePoint 2010, Best Practices

Mar-72010

It's a Date!

SharePoint and Office 2010 to Launch on May 12th

On Friday, Arpan Shah announced the official debut date for Microsoft Office 2010 and, of course SharePoint 2010, on the Microsoft SharePoint Blog. In the same post, he mentioned that the RTM (Release to Manufacturing) will come a few weeks earlier, some time in April.

There are a lot of changes coming in the new versions, so there is also lots of planning to do. I know many of you are planning to move forward aggressively, while many of you will also be on older versions of SharePoint long into the future. Whichever path you choose, it might be helpful to keep the following in mind:

Your current stuff will still work, even once the new software comes out. You don't "need" to upgrade immediately.
SharePoint Server 2010 requires Windows Server 2008. It also requires that your entire stack, including both Windows Server and SQL Server, be 64-bit.
Although you will always get the best results when keeping both the Office client and SharePoint versions in sync, you will still get reasonable functionality with staged upgrades. (Look for information about just how the different version combinations interact soon.)
One exception to the previous statement is SharePoint Designer. SharePoint Designer 2007 will not work for SharePoint 2010 sites. Conversely, SharePoint Designer 2010 will not work with anything except SharePoint 2010 sites.
On the Office client side, even if you are using 64-bit Windows, you can still use the 32-bit Office. This is critical, because you cannot mix and match 32 and 64 bit versions of Office on the same system. Naturally, you can't use 64-bit Office on 32-bit Windows in any case.
No matter what version of SharePoint you are on, a failure to plan is a plan to fail. Think about how you want to use SharePoint in your company before you deploy it.

This is going to be an exciting Spring in the SharePoint world, and I can't wait to help you make sense of it!

Published: Mar-07-10 | 0 Comments | 0 Links to this post
Tagged as: Office 2010, SharePoint 2010, SharePoint Designer, SharePoint, Upgrade, Architecture, Governance

Jan-212010

On Ends and Means

The Answer may be SharePoint, but Don't Forget the Questions!

One of the biggest reasons some SharePoint deployments fail is because they are "SharePoint Deployments".

People hear the buzz, and want to jump on the SharePoint bandwagon. They buy servers, attend training, install the software. Big bux are spent customizing and branding a SharePoint home page. Maybe there's a big roll-out promotion. Everybody says "Look! We've rolled out SharePoint!". And then...

Crickets.

All Dressed Up, and Nowhere to Go

But, you ask, what about all of those stories you hear about "uncontrolled growth"? People clamoring to get their own SharePoint sites? That's all true as well, but you need to consider why that is happening. In those cases, the people have a goal, and find that SharePoint is a great tool for making that goal a reality. The goal isn't to have a SharePoint site, per se. Rather the goal might be "easier document and calendar sharing", and SharePoint is used to attain it.

Simple Pleasures

Often those implementing SharePoint forget the KISS principle (Keep it Super Simple). SharePoint has a lot of great features and functions right out of the box. It is very tempting to try implementing all of them at once on the same site, sometimes even the same page. It is almost like when "desktop publishing" was made possible by Postscript laser printers. People discovered how easy it was to have a dozen fonts on a single page, and so that's what they did.

Similarly, in the early days of the web, as new features were added to web browsers, they started showing up everywhere on sites. (Does anyone remember the <Blink> tag?) And don't even get me stated on some of the early Flash-based sites. It got to the point where IBM was even poking fun at the designs in their commercials. "It's a Flaming Logo!" Why? Because we can!

The fact is, like the flaming logo, the fanciest features SharePoint has are worthless unless they are used in the service of some actual user need. For example: Assuming it is reasonably well implemented and up to date, the most used feature on any intranet is almost guaranteed to be the company phonebook or employee directory. Probably by an order of magnitude above any other function. It isn't fancy, but it is something people actually need on a regular basis.

As it turns out, SharePoint, with its personal profiles and My Sites, makes a great employee directory. :)

Form Follows Function

Of course, if all you needed was an employee directory, SharePoint would be overkill in the extreme. But put that directory in the context of a company intranet, with news and knowledge bases, collaboration and search. And here's a radical idea - Ask your users what they need first, and implement that! Maybe throw in a few things that are just for fun, like classified ads, or pictures from the company picnic. Suddenly you have a "destination" that will draw in your users and enhance the sense of community in your organization.

These are all things that could be (and often have been) done individually without SharePoint. But SharePoint gives you the tools you need to build and maintain these "applications" easily, quickly, and consistently - usually without custom code.

Now you can add your branding, and promote "Our-Net 2.0". Sure, it is a site based on SharePoint, but now you have put the horse before the cart, and given your users the tools they really need. It doesn't matter to them what the name of the technology behind the scenes is. All they care about is that you have created something that can help them do their jobs better.

Let SharePoint play Clark Kent, so you can look like the super hero.

Published: Jan-21-10 | 0 Comments | 0 Links to this post
Tagged as: Architecture, Design, General, Governance, SharePoint

Nov-122009

SharePoint Virtualization

All of Your Eggs in One Basket?

Every time a new version of a virtualization tool comes out, people get all excited about the possibility of reducing the costs of running their data centers. Most of them are thinking in terms of hardware consolidation, but virtualized environments also allow for new ways of handling resilience and recovery as well.

This is all well and good, but then you run into what I call "the new hammer syndrome". The idea is, after you buy a new hammer, everything starts to look like a nail. You keep thinking of ways to apply this new tool. Some of them are great. Others, not so much.

Note: This post is neither "pro" nor "anti" virtualization in SharePoint. It is very much about the considerations involved in making that decision for your environment.

Virtualization and SharePoint

SharePoint, in particular, frequently seems like a ripe target for virtualization. It has a multitude of roles, which can be (and often are) distributed among many servers. Data center managers see all of this hardware and envision collapsing it onto a single box. And, SharePoint is officially supported in virtualized environments. It seems like a match made in heaven, doesn't it?

But, not so fast! Take a step back and think about what I just said. You are taking all of these SharePoint roles, and spreading them out among multiple servers. Now you want to take all of these servers and virtualize them back onto a single piece of hardware? Where is the sense in that?

Why did you build out that many servers in the first place?

Pausing while people try to gather back the pieces of their exploded heads from that bit of circular logic...

Profound, isn't it? Almost like a Zen koan.

On Over-Engineering a Solution

SharePoint will very happily run all of its roles on a single server (physical or virtual), if you want it to. So, why would you want to split the roles at all? There are really only two reasons (good ones, anyway) - performance, and resilience. (No, I don't consider being able to point at a monitoring station covering a half-dozen or more servers and saying "Look at all of the systems I manage in my SharePoint farm" a good reason.)

From a performance standpoint, some SharePoint roles are real resource hogs. The two big ones would be SQL Server and Search Indexing/Crawling. SQL Server, though not technically part of SharePoint, is hit pretty much constantly by nearly every SharePoint component, and so is almost always set aside on separate hardware. The search crawl process, though intense, is "peaky." In other words, it goes through cycles of short bursts of intense activity, followed by periods of near idleness. In comparison, the web front-end functionality is a cake-walk. A single WFE server can handle potentially many thousands of users without breaking a sweat.

In fact, a big, modern server can probably handle hundreds, if not thousands, of users even with everything except SQL Server running on it. (Naturally, this depends upon just what those users are doing.) So performance is rarely the real reason for splitting off most of SharePoint's functions, except in very large environments.

That leaves resilience. Resilience is the ability of a system to keep on going, even if a piece of it fails. By splitting the SharePoint roles onto several servers, and having multiple instances of the roles that face your users, you can create a system which can tolerate a failure of any one component with minimal short-term impact. It is possible to take this too far, however. It isn't a case of "if two are good, three must be better, and five are better still."

What good is having three or more web front end servers, when they all sit practically idle at singe-digit percent utilization - even during peak periods? Not very good at all. At a minimum, it is not a very efficient use of resources. This is the kind of thing that makes virtualization look really attractive.

Balance

So, is virtualization really the answer? Maybe. Or maybe not. Let's get back to that biggest of little questions - "Why?"

Why did you build out your farm onto multiple servers?

Did you build out this big farm because your usage is so heavy, you were stressing out anything less? Then you are almost certainly not a good candidate for virtualization. In this case, you've got your hardware optimized to its load. Virtualization is just going to add another layer, and if you're already fully loading your systems, you won't get any benefit from host sharing with other virtual servers. The only reason you might justify going virtual is to be able to quickly replicate a failed system from an image, or shift a running image onto another host. But can you handle the extra overhead?

Did you build out your farm for resilience? The minimum "fully" resilient SharePoint farm is a configuration I call "2.1+". That's two servers running as WFE and Query servers (along with Excel Services in Enterprise Edition), one application server running the Index role (of which there can be only one per SSP) and optionally running other duplicated roles as well, "plus" a properly specified SQL cluster. This configuration can handle thousands of users, even with modest (by today's standards) hardware. In fact, from a performance standpoint it is probably still overkill for most organizations. Here, you might find some room to virtualize. But be careful - you split these roles out in the first place to avoid having a single point of failure. Virtualizing them and simply placing all of the VM's on a single host eliminates that benefit.

And What About SQL Server?

I decided to write about virtualization because I've been approached several times in the last week or so with folks asking about virtualizing the SQL Server side of SharePoint. Up until now, even when virtualization has been appropriate for some SharePoint components, I've always advised against making SQL virtual. But VMWare has just introduced a new version for which their marketing message is claiming that SQL virtualization is now a good thing.

Frankly, I'm not convinced. My main concern is that SharePoint is a very heavy user of SQL Server. Again it boils down to your utilization. Are your SQL Servers already CPU or disk I/O bound? If so, virtualization isn't going to help matters. If not, then you might be OK. Even if you decide to virtualize computation, I would still avoid virtualizing the data storage without first doing extensive load testing.

Going Forward

Ultimately, all computer configuration involves trade-offs. Cost, performance, and resilience are three corners of one of those "pick any two" engineering triangle conundrums. Virtualization doesn't eliminate the trade-off, but it can shift the balance toward the lower-cost corner. Whether or not it is appropriate in your case will depend upon your server load and tolerance for risk. In the case of SharePoint, you can achieve many of the same results as virtualization by simply re-consolidating the roles that were originally split off.

Mark Twain once said: "Keep all of your eggs in one basket - then watch that basket!" If you do decide to virtualize, make sure you take appropriate precautions. The Microsoft Consulting Services UK SharePoint Team has written an excellent series of articles on SharePoint virtualization. I suggest checking that out for more technical details.

Published: Nov-12-09 | 10 Comments | 0 Links to this post
Tagged as: Administration, SharePoint, WSS, Governance, Architecture

Woody Windischman - The Sanity Point

Search

Categories

Links

Blog Roll

Archives