Making Sense of the SharePoint World

Sep-292009

A Little Shout-Out to Bil Simser

Bil SimserComplete Agreement

As you may have noticed, I try to keep this blog "original." In other words, I don't cover the same material as another blogger has recently done, unless I have something major to add, or there is some kind of debate going on.

Today (September 29, 2009) SharePoint MVP Bil Simser has managed to "scoop" me, by writing an article on almost exactly the same subject I was planning to comment on in an upcoming post. In it, he talks about people who claim SharePoint is bad, and questions how whatever the "SharePoint Killer" of the day might actually compare beyond one particular forte.

While I would have been a little softer in my language, I can't fault the sentiments he has expressed. So, rather than seem like I'm repeating it, I'll simply give you the link to his post:

SharePoint FUD... Spreading Far, Wide and Fast

Note - I have actually written on this topic before, though specifically on the subject of Wikis. For my take on that subject, check out this article, from April of this year:

Wiki-in-the-Box - Is SharePoint Wiki Really that Bad?

Be sure to check out Bil, and all the other great SharePoint bloggers on my Blog Roll...


Published: Sep-29-09 | 1 Comment | 0 Links to this post
Tagged as: Blog, General, SharePoint

Sep-202009

Indexing SharePoint List Columns

MCj03800210000[1]

Helping SharePoint Help You

A SharePoint system manages a huge amount of data. Amazingly, in a SharePoint content database, all of the data, for every list and library item, in every site and subsite, is stored in a single table. Looking at hundreds of sites, each with dozens of lists and libraries, each potentially containing hundreds or thousands of items, and you end up with one massive table!

Not So Limiting After All

Everybody has heard about the so-called "2000 item limit" in SharePoint. Remember that this isn't really a limit. SharePoint is quite capable of handling lists with tens, or even hundreds, of thousands of items. The issue is the "rendering" of those items, which starts becoming perceptibly slower if you have more than 2000 items in a single view.

While the indexing discussed in this article can have a minor effect on this rendering, it really is more general, and can improve list performance across the board.

Ask any DBA how to achieve maximum performance on a huge table, while other options may also come up, at a minimum you'll always hear the word "indexing". And make no mistake - SharePoint (whether Windows SharePoint Services 3.0, or Office SharePoint Server 2007) does do a lot of indexing. But that is only dealing with the user data table as a whole.

Once SharePoint has figured out which site and list the data belongs to, normally it is pretty much done with indexing. When you perform a query - whether in code, or for a web part view - each item in the list is examined individually for a match. As the amount of information in your sites grows, this can take quite a bit of time and cause significant slowdowns (This is independent of the "2000 item limit" - see sidebar).

Fortunately, you don't have to put up with this default behavior. SharePoint gives you the additional ability to index the information within individual lists or libraries.

Look at the settings page for just about any list or library, and you will find a link for "Indexed columns":

image

When you click the link, you will be given the opportunity to select which columns in your list you wish to index. This is where an understanding of your information, and how you use it comes into play. While you could just click everything, that isn't usually a good idea. For each column you index, SharePoint needs to store extra information about every item in your list.

You should only select columns for indexing that you will be using to query/filter, sort, and group your list. For this list, I'll usually need to do this with the item's title (or name), who created or modified an item, and when it starts. So those are the columns I'll select to index:

image

Note: When setting up indexed columns, you will almost always want to include the title or name field.

Once you click OK, SharePoint will build the appropriate extra indexes. While there won't be any change to the way your list looks, you should see the performance results almost immediately. (Of course, the more items in your list, the greater the impact will be...)

One place you usually see immediate results is when you click on the context menu of a column title to change the sorting or filtering. The list of unique values builds much faster on an indexed column.

image

That's all there is to it! Setting up indexed columns in your SharePoint list really is that simple. Give it a shot, and you might be surprised at how much faster your SharePoint applications can be.


Published: Sep-20-09 | 7 Comments | 0 Links to this post
Tagged as: Administration, Lists and Libraries, Search Server, SharePoint, WSS

Sep-162009

SharePoint Values Your Uniqueness

MCj04356080000[1]"Who Did You Say You Were?"

Today I'm going to talk about user accounts. In particular, Windows Active Directory accounts. You might be thinking, "This doesn't sound like a SharePoint topic!" But rest assured, it is.

I've talked about Windows accounts and SharePoint before. For example, I've told you about the many accounts you need to consider when setting up a SharePoint farm, and how to discover the Setup User account after the fact. I've also mentioned how you can let SharePoint know when User ID's change.

Normally, each person has one Windows account (user ID and password). They use this account to log into their PC in the morning, thus proving to the network who they are. This is called "authentication". Many systems that recognize Windows authentication (including SharePoint) will simply accept these credentials from the user's PC, without any further user intervention.  The systems use these credentials to determine what data and functions the user has been "authorized" to access by the administrator of the system.

Note: Behind the scenes, it is quite a bit more complicated than that. While a complete discussion of handshaking and protocols is beyond the scope of this article, understand that the negotiations taking place do result in one of the issues I will describe below.

On Being a Highlander - "There Can Should be Only One"

By and large, this system works pretty well. However, it is based on a pretty big assumption - that each user has only one account for their "day to day" system usage, and each account has only one user. Unfortunately, from time to time this assumption doesn't hold true. This can cause some subtle, and not-so-subtle (but hard to trace) problems in SharePoint if you aren't careful.

I'm going to discuss three main scenarios:

  1. One user has multiple accounts
  2. One account is shared across multiple users
  3. Accounts in different domains that have the same UserID portion, but different passwords.

For each group, I'll talk about why it might occur, how it presents a challenge, a few variations on the theme, and what you can do to minimize the difficulties presented by it.

One User, Multiple Accounts

Why it might happen:

There are many specific reasons a user might have multiple accounts, but they generally fall into three categories - Administration, Test, and Transition.

Transitions can be wide-spread - such as when companies realign or change naming standards, or individual - such as when marital status changes. Regardless of the reason for a transition though, generally there will be an "old" account, and a "new" account.

For purposes of this section, I'm considering administrative and test accounts to be equivalent. They don't need to be "administrators" per se, and the account may exist mainly for applications other than SharePoint. Essentially these are any accounts that a user signs into for a particular task that has different privileges from their normal User ID (e.g. DBA), and their use is often dictated by policy or best-practice. Regardless of the reason, the challenges and resolutions are basically the same.

Why this is a challenge:

Aside from the obvious - making sure each account actually has access to the correct resources - SharePoint keys a lot of stuff based on the current user. From Created and Modified by tags, to personalized pages, and audience targeting, SharePoint knows and shows who you are. But the real hazard of multiple accounts is their effect on profiles and my-sites.

User profiles are crated from Active Directory imports, as well as user-entered information. Certain features of My Sites, such as organizational relationships are built using the imported information. Typically a user's "primary" account will populate such fields a their title, office location, manager, and other useful business information. Administration and Test accounts, on the other hand, generally just use the name to describe the purpose of the account, and little else.

These impact not only the current user, but others as well. For example, suppose you fully populate AD info for each of the accounts. When someone clicks on the manager's profile, suddenly they will show all of the secondary accounts, as well as the "real" user, in their reporting relationships. Or, what if the user has reports of their own? Since each can only have one manager, you need to be very careful to assign it to the correct account, otherwise, someone may end up not appearing in org charts, or they may appear in the wrong place.

image

When someone starts using these secondary accounts for day-to-day activities in SharePoint, this is the account noted as the creator or modifier of data items, and tracked in logs. If you use Communicator, SharePoint's presence indicators can also be affected. They will show the presence and contact info for the account that actually made the change, rather than the potential real presence for the user.

Finally, aside from the profile, each of these accounts will register as separate for the creation of My Sites. Since Office can hook into a user's My Site as a default storage location, this can also cause confusion, as personal documents appear and disappear based upon which ID user is using to perform their activities.

Minimizing the pain:

Wherever possible, strive to make transitions instantaneous - at least as far as SharePoint is concerned. Don't let users access SharePoint with more than one of these accounts at a time. When the time comes, make use of the stsadm "migrateuser" operation as soon as possible, so that users don't get confused or accidentally start generating content under the new account before their old information is reassigned.

For admin/test situations, make sure there is a clear distinction in the users' minds about the purposes of each account. In addition, make sure the metadata in Active Directory correctly reflects which account will be used for day-to-day operations.

One Account, Multiple Users

Why it might happen:

The reasons for multiple users sharing an account typically revolve around cost savings in one form or another - either licensing or administrative.

A typical example might be in a "shop" situation, where one PC is on the floor, and once it is logged in, everyone just accesses the information they need.

Why this is a challenge:

Some of the challenges here are similar to those you might face in an Internet-facing, anonymous access, scenario. Essentially, when someone does something, you don't know who it was.

But there is an added complication. When you are authenticated, this triggers some things in SharePoint. For example, since you have an account, SharePoint will treat you as a named user for "Created by" information. But you can't use effectively use the "only their own" global list permission, or filter things by [Me], as everyone who shares the account will have that permission or see that information. Or on surveys that prevent multiple entries, only one person will be allowed to fill it in from that account. Discussion comments all appear to come from the same person.

Minimizing the pain:

By sharing a single account, you essentially remove the effectiveness "social" elements of SharePoint. Consider reducing confusion by turning off access to MySites and Personalization for the shared account. If you want to use interactive discussions, add a field for users to manually enter their names when posting, and make it a required field.

Frequently such shared resources are "read only". Consider simply allowing anonymous read-only access in those instances.

Another option is to enable a forms-based authentication zone for that group. This allows you to keep your AD clear of staff who otherwise don't use PC's, but still maintain individual control over SharePoint access, and monitor who is posting to writable areas.

Name's the Same, Different Domain

Why it might happen:

Unlike accounts within the same domain, which by definition must have unique IDs, it is possible for accounts in different domains to have the same "userID" part. For example, EMEA\SallieJo, AM\SallieJo, and APAC\SallieJo.

These may represent different users, or one user who travels. Sometimes organizations merge, and each already has their own Active Directory domain. Or for various reasons, your organization requires multiple domains on an ongoing basis. In some cases, this can be similar to "One User, Multiple Accounts". In fact, sometimes the situation is the same - accounts are held by the same user, and/or they are transitional. If this is the case, then the cautions mentioned in that section apply as well; but this situation presents its own unique challenges.

Why this is a challenge:

Here is where that "Behind the scenes" techie stuff I mentioned at the beginning comes into play. Essentially, when a user's web browser (Internet Explorer) and IIS (Internet Information Services) start negotiating authentication, only the UserID portion of their credentials, along with encrypted password information is sent from the client to the server. (SharePoint relies on IIS and the ASP.NET engine for authentication.)

Here's the problem - IIS usually assumes the user will be in the same domain as it is, and will try to match the ID with an account in that domain. Only if it doesn't find a match will it make a deeper query of Active Directory. If it finds an ID match, it will try to validate the encrypted password against the current domain. If the passwords match, no problem - or maybe big problem. SharePoint thinks IIS has authenticated the local user. If both accounts are really for the same person, you're OK. If it is a different user from the other domain, who just happened to have the same ID and password, they could actually be seeing the local user's information!

If the passwords don't match, unlike the situation when the UserID is different, IIS won't continue its search. It will just return a fatal error - typically a "500". (If the user is persistent, this also has the potential of locking out accounts in IIS' local domain.)

Note: This isn't an issue unique to SharePoint - you can encounter this problem with almost any system that requires NTLM pass-through authentication.

Minimizing the pain:

The best defense here is to make sure your user ID's are unique across all trusted domains accessing resources. Before initiating trusts, run reports and reconcile them, and set forest policies to prevent duplicates.

When duplicates exist for one or two users, a workaround for users in the remote domain is to assign your site to a specific zone (e.g. trusted sites) and configure Internet Explorer to always prompt for authentication in that zone.

image

If this is a problem for a large number of users, configuration changes at the server may be in order.

When the majority of your users are in a domain other than the one hosting SharePoint, you can configure IIS to use digest authentication and a different default realm. You can also extend SharePoint into multiple zones, and configure a different realm for each site in IIS. Then ensure that each domain's DNS points to the correct SharePoint zone.

image

Of course, if you change configurations - whether they be IE or AD, IIS or SharePoint - make sure you document them!


Published: Sep-16-09 | 2 Comments | 0 Links to this post
Tagged as: Administration, Governance, SharePoint, WSS, Search Server

Sep-122009

Off Topic - In a Fix with Ford

MCj03971260000[1]

We interrupt this blog to bring you a small consumer rant. If you have no interest in cars or complaints, please disregard this post.

On Being a Ford Guy

Let me start this out by saying that I'm what they, in a past age, would have called "A Ford Man". I've owned a lot of cars over the course of my life, and most of them have been by Ford Motor Company (memorable exceptions include my first car - a 67 Dodge Dart - and the dilapidated VW Beetle I had in college, but didn't everyone have one of those at some point?). This includes every one of the four cars I have purchased new.

This doesn't mean that I wouldn't consider other brands - I do a pretty thorough search and comparison before major purchases. It is just that when new car time rolls around, more often than not I find that one of their products best meets my needs. And if it is otherwise a tie, the Ford (or Mercury, or Lincoln) product will probably win by default.

Falling for the Fusion

A few years ago, Ford decided to split one of their best selling car lines of all time - the Taurus - into two: A slightly larger car called the 500 (which has since reclaimed the Taurus name, and just received a major makeover); and a somewhat smaller vehicle called the Fusion (for those reading this in Europe, the US Fusion is nothing like the car of the same name sold over there - the US car is more of a size and kind with the current Mondeo).

By sheer coincidence, the Fusion came out right at the time I was ready to replace my old car (a Focus). It was virtually everything I was looking for in a car at the time. Now, that doesn't mean I was "first in line" to buy one. I still did all of the appropriate comparisons, but buy one I did, and it is one of the earliest made (November 2005, according to the sticker - more on that later). I am now the owner of a 2006 Ford Fusion SE, in "Red Fire":
fusion1

In general, I have been very happy with my Fusion. It is comfortable, roomy, performs well with the 4 cylinder engine, and gets great mileage (well over 30 MPG on the highway). And, until recently, I haven't had any mechanical problems, either.

In the Driver's Seat

I don't buy a car to just look at. I buy it to drive. A lot. When you hear about warranties for "X years or Y thousand miles", you can bet your bottom dollar that I'm going to hit the miles number first. I spend a lot of time behind the wheel of my cars, and I get to know them pretty darned well. I learn every every quirky noise, every bump in the seat, every crease of the dash, on a first name basis.

I've never gotten rid of a car with less than 6 figures (100,000 miles) on the odometer. I understand the concept of "normal wear-and-tear" as well as (if not better than) anybody. I accept them as a fact of life, and if my issues were in that category, there wouldn't be a need for me to write this article. In addition, I also always buy the "best" extended warranty plan available from the manufacturer (Ford calls this their "ESP") to make sure I get to at least 100,000 miles without a major breakdown expense. Until now, I have not regretted it.

"You Will Know a Pioneer..."

I also understand the realities of product design and manufacturing. Nothing is perfect out of the gate. Issues are discovered, and changes are made. Most of the problems are caught early. Many are fixed at the factory before the cars are delivered, and 99% of the time, this fine-tuning goes unnoticed by the consumer.

But occasionally a problem isn't caught, or a design flaw that impacts durability can't be discovered, until well after the cars are sold and people are using them in the "real world". Again, most of these issues are benign, and may never be noticed (e.g. a piece of misaligned trim on the bottom of the dashboard). Now and then, though, one rises to the level of consumer awareness.

In the case of problems that could affect safety, depending on how wide-spread it is, a general or specific recall is issued. Everyone impacted is alerted, and their cars are fixed. Period. Again, if my issues were in this category, I wouldn't be writing. Or would I?

And what about problems that aren't generally safety related? These aren't ignored, but they aren't exactly widely publicized either. They are handled through a process called the "Technical Service Bulletin" or TSB. Sometimes these are referred to as "Hidden Warranties". Essentially, they only get fixed if the customer notices and complains about the specific issue covered. Of course, if you are within your normal "bumper to bumper" warranty period, this won't even be an issue. It will be fixed no questions asked.

But that would be the case even if there wasn't a "known problem" with the design, and it was simply a one-off defect in material or workmanship. A TSB might be issued with with a symptom description like "premature wear". And when the fix involves a redesigned component, you can be pretty sure that the original design itself was faulty.

A "Key" Problem

Here is where my relationship with Ford starts to get a bit shaky. As I mentioned, my car was one of the first Fusions produced. Sometimes these design flaws take a while to manifest, and detecting the problems tends to be time, not mileage sensitive. But I drive a lot, so I hit the standard warranty mileage cap ages ago.

A few months back, I ran into a problem where my key wouldn't come out of the ignition. These days, leaving one's key in the car is not the wisest of actions, so of course I went to a dealer to get it fixed. Upon diagnosing the problem, the dealer noted that the issue and solution was described in a TSB, but because I was out of standard warranty by mileage, I would have to pay the ESP deductible of $100. (All the more frustrating because the repair itself would only have been within a few dollars of that).

While I had been aware of TSB's, this incident brought them to the forefront of my attention. First, I became upset that I had to pay at all to have what was clearly a design flaw remedied. Second, I was more frustrated because when I go in for ANY service, I regularly asked if there are any outstanding recalls or service bulletins that apply to my car.

Chasing the Wild Goose

So, I did what any self-respecting, Internet-savvy geek does these days - I Tweeted about it. I caught the attention of Ford's Social Media Guru, Scott Monty (@ScottMonty), who brought me into contact with Shawn @FordCustService. After taking my issue offline with Shawn, he eventually escalated me to Joe Wiegland, Program Manger for the ESP program. While he wouldn't do anything about getting my already-paid deductible refunded, he did ask me to contact him when I was ready to have some other chronic issues, that I had chalked up to either "facts of life" or "normal" wear and tear but my new research identified to be TSB items, addressed, and he would get things straightened out.

Here I must note - I appreciate Mr. Wiegland's involvement, but I believe this shouldn't even have been made an ESP issue. These are design flaws, not strictly material and workmanship defects, and should be repaired regardless of warranty status - normal or extended.

For various personal reasons, I was unable to return to these problems until a couple weeks ago. I called Mr. Wiegland's office, but was directed to his voicemail. I left a message reminding him of my situation, and requesting a callback.

That callback never came.

Nevertheless, armed with my list of applicable TSBs (see below), I paid the dealer (Don Hinds Ford, in Fishers, Indiana) another visit. For every issue, I was rebuffed. Frequently, it was "cannot reproduce". But even when acknowledging a problem, they replied with either "not covered", or that it would only be "partially" covered, even if they could reproduce it.

So, I took back to Twitter. Just a few posts saying that I wasn't pleased with Ford. This time, I got the attention of the newly created @Ford corporate account. They said, literally: If we had a clue as to why, we might be able to help. So, I followed them, and when they (presumably auto) followed me back, I provided contact information via a Direct Message in order to discuss it offline.

They never responded.

A Blogger Scorned

I had no desire to write this article. I tried to resolve my problems privately, but didn't get any satisfaction, so I'm turning to the bit-stream. I've laid out my story in language plain enough for anyone to understand. I'll bring it to the attention of the various Ford accounts on Twitter. I will update it with any resolution - or lack thereof -that may be forthcoming.

Note: I still like Ford products in general, and my Fusion in particular. I just want it fixed.

Appendix - The Issues

Here's a list of my issues, their TSB numbers, the dealer's response, and a few comments.

Key stuck in ignition / Shifter binding condition

My listing shows it as TSB 07-2-1, but the dealer worksheet shows 07-14-7

This is the one that started it all. The title is self-explanatory. The repair consisted of replacing the shifter handle with a redesigned unit. I got charged a deductible that I don't think I should have.

2.3L Engine belt squeal - verify proper serpentine belt and tensioner

This is TSB 06-22-13

While I was at the dealer the first time, I also mentioned a pretty noisy squeak/squeal that I get when the car is cold or the air is particularly damp. Unfortunately, the car is warmed up by the time I get to the shop, so the dealer couldn't reproduce the problem.

After I came in with my list of TSB's, however, this was the one where they said even if they could reproduce it, because the repair incorporated a part the ESP doesn't cover (a belt, which is usually considered a consumable), there would be a significant charge.

According to one source "Ford has issued a newly designed shield, belt, and tensioner to correct the squealing problem. Alignment instructions for the new tensioner are included in the TSB"

Redesign a part to correct a problem, the original design was bad. The belt is part of the redesign, and therefore should be covered.

Since it only happens when cold, here's a video I made that illustrates the noise. I kept the volume of the video down so that it isn't too bad in an office. Rest assured, that in person it is VERY loud, and I can be heard coming down the street from a block away.

Video Demonstrating Squeak and Window Issue

Note: this video also includes a segment demonstrating a crunching noise made by the driver's side window. As far as I know, there isn't a TSB on that, but it is also an intermittent issue that I wanted to get on record so maybe I can get it fixed before my real ESP extended warranty expires. My gut tells me this is a power-window failure waiting to happen. Unlike the squeaking, it is most obvious when it is hot out.

Seat Bolster Wear

This is TSB 07-13-3

Here's one that really bugs me. I brought this up well over a year ago to my local dealer's service department. At the time, it hadn't yet worn through the fabric. They said that it was normal wear that they couldn't do anything about. Now I have discovered that it is anything but.

The TSB description lists the cause as a wire inside the bolster cushion that causes "premature wear". The solution is a new seat cover and a redesigned foam pad that the wire can't wear through.

Here is what I get to look at every time I get into my car, and this is the kind of thing that can only get worse.

seat

According to Hinds' service department, the ESP specifically excludes uphostery, and therefore even with this being a known issue, they can't cover it.

Again, redesign to fix means the design was flawed to begin with. Please Ford, fix this!

Rattle Noise Under Vehicle - Heat Shield

TSB 07-11-7

I can't reproduce it "on demand" but it is very disturbing when it happens. Typically during sub-freezing weather. It sounds like I have a gremlin with a jack-hammer under the car.

Cold Start Tip-in Hesitation

TSB 05-26-20

Again, I can't reproduce it on demand, but it definitely happens. Press the accelerator, and the engine skips a beat before revving up. I originally thought it was just characteristic of this particular power-train. Apparently it only happens on very early Fusions, built before 12/9/05 (like mine), and there's a fix for it. I want the fix.

Front Floor Mat Wear

TSB 06-18-14

Here's one that's been known for a long time. "Premature front driver side floor mat wear" according to the text of the bulletin. In fact, Ford did replace these for me once already. The fact that the replacements wore through just as fast means that the issue wasn't actually fixed at the time of my first replacement. Come on Ford, this is just floor mats! One would think these should have been mastered for decades...

floormat

That's It

Thank you for your time and attention. We now return you to your regularly scheduled SharePoint Blog.


Published: Sep-12-09 | 10 Comments | 0 Links to this post
Tagged as: Off-Topic