Another Successful SharePoint Saturday in the Books

I'm back and settled after SharePoint Saturday, Columbus. There was plenty of SharePoint knowledge to be had, with 6 tracks and over 20 speakers.

My session was "Who's Afraid of SharePoint Designer". There were only a few slides - which you can download here, if you like. Most of the session was taken up demonstrating some of the governance features of SharePoint Designer 2007 and 2010.

I would like to give a warm thank you to the organizers, sponsors, and (of course) the attendees for making the day as great as it was!

Back to My Old Stomping Grounds...

When I was a "wet behind the ears" high school graduate, I ended up attending Ohio Institute of Technology (OIT) to study Electronics Engineering Technology. While I was there, OIT became DeVry Institute of Technology, Columbus. Today it is known as DeVry University, Columbus and offers a whole lot more than electronics. I ultimately ended up living and working in Columbus for many years, and it holds a special place in my heart.

Today, I'm pleased to announce that I've been selected to present at the SharePoint Saturday in Columbus, Ohio. This takes place on August 14th, 2010 at The Conference Center at OCLC. Click on the link or logo above for all the details, including registration, a list of the other presenters, as well as the Twitter feed of #SPSColumbus commentary.

A SharePoint Saturday is a free to attend event that serves as a mini SharePoint conference. SPS Columbus will be an educational, informative & lively day filled with sessions from respected SharePoint professionals & MVPs, covering a wide variety of SharePoint-oriented topics.  SharePoint Saturday is FREE, open to the public and is your local chance to immerse yourself in SharePoint!

So, if you're in Central Ohio, and interested in SharePoint - whether you need the latest information on SharePoint 2010 or are still trying to make the best use of SharePoint 2007, this is the place to be! I hope to see you there...

Yes, It's True - I'm Officially Certifiable!

Much like designing software, Microsoft goes through a pretty significant effort to develop certification examinations. The most public stage of that process is the  Beta phase. Members of the public are invited to take a special version of the exam. After these folks take the test, the questions are evaluated for how accurately they predict whether someone actually knows what they're talking about.

Last month, I took the configuration (667) and administration (668) beta exams for SharePoint Server 2010. Over the last two days, the results for these have been released. I'm happy to say that, based on my answers to the questions that survived validation, I have passed both exams. That gives me the right to use the following logo:

Minimizing Your Footprint

I recently participated in an MVP chat, and we got an interesting question about SharePoint storage requirements. I answered the question as well as possible given the chat format, but the issue really deserves a more thorough treatment.

Reading through the SharePoint 2010 system requirements you quickly come across one that seems a bit strange. SharePoint is asking for 80 Gigabytes of hard disk space! We all know that SharePoint itself isn't that big, so where is that requirement coming from? Not only that, but where is that space actually required? And, can it be moved around?

Here's the kicker - SharePoint itself doesn't actually "require" that space, Windows does (in a way). But, SharePoint knows this, and will give you warnings in Central Administration if your C: partition doesn't have double your "physical" RAM free. This is because when Windows crashes, it creates a memory dump on the system volume, and needs free space to do it. In addition, Windows sets up a hard drive cache for swapping chunks of memory around - that's also usually around double your RAM. Further, if you have a hibernation file on your hard drive, that's also going to be the size of your RAM. Finally, you need the space that Windows, SharePoint, and any other applications actually do take up. And a little bit of buffer, so you can actually do some work.

If you've got 8 GB of RAM (the minimum recommended for a SharePoint production environment), that adds up pretty quickly. Hence, the storage requirements. Now, some of these pieces can be easily shifted around in Windows. Most servers don't need a hibernation file, for example, and you can easily move the swap file and dump locations onto other volumes. Then you can go into Central Administration's Health Monitoring to tell SharePoint to not monitor the drive space, so you don't get the warning (I haven't found a way to tell SharePoint to monitor a different drive, unfortunately). But there is still more going onto drive C: than many corporate Windows Server administrators like.

SharePoint Stuff you Can and Can't Move

Let's get this out of the way right up front. You can't tell SharePoint where to install certain things. The core of SharePoint - the "SharePoint root" or "14 hive" - is always going to be installed on your system drive (usually C:), in "\program files\common files\Microsoft shared\Web Server Extensions". That's where it goes. You can't configure this during Setup. You can't move it after the fact. Learn it. Live with it. Embrace it. Love it.

Other stuff, however, can be controlled. Just not always easily. Let's get the easy stuff taken care of.

• Your SharePoint content (the stuff you actually store in your sites) is going into SQL Server. You usually have full control over this, but there are lots of articles discussing SQL Server configuration so I'm not going to go into the gory details here.
• On versions of SharePoint other than Foundation, you can configure where certain non-core SharePoint components are stored during Setup. That's where things like search indexes go. But that doesn't change the location of the SharePoint root as described above.
• You can control where SharePoint stores certain log files. By default, those go into the SharePoint root, but they can be configured in Central Administration to be stored just about anyplace you please. Given how large these can grow, you almost certainly want to move them, and enable compression on the target folder.

SharePoint is also dependent upon Windows' Internet Information Services (IIS). When you activate the Web Server and/or Application Server roles on Windows Server 2008 and 2008 R2, several IIS components are pre-configured to be hosted on the system drive - most notably the INETPUB folder (which hosts your SharePoint Web Applications) and the IIS log files that get stored in the Windows\System32 folder (which can also become huge). In versions of Windows prior to 2008, it was an easy enough task to tell IIS to move these to another location. Not so with IIS 7.x and Windows Server 2008. Try as hard as you might, you won't find that configuration information in the management console.

Fortunately, these things can be moved. Unfortunately, moving them can only be done through the command line, and the commands to do it aren't trivial. The best instructions I've found for this are on IIS Program Manager, Thomas Deml's, Blog. In this, he not only describes the commands needed, but gives you a batch file to move the IIS root. Unfortunately, even Program Managers aren't immune from typos, and his batch file actually contains a couple of extra "\" characters. I've corrected the file, and made it available for download here. This batch file should be run after you install the SharePoint prerequisites, but before the actual SharePoint setup. Just as with the SharePoint logs, you should compress the folder you're storing the IIS logs in.

Summary

That's about it. SharePoint's requirements do state that you need 80GB of hard drive, but as you have seen, that statement is a little fuzzy about the why and where you need it. Although the default is drive C, many corporations have policies limiting what you do on the C drive. In this article, I've described how you can move many of these items around. I hope this has given you the information you need, or at least food for thought.

"Bring It On! (But Please, Give us Real Food...)"

Dateline, New Orleans LA

We're halfway through Tech-Ed 2010 (North America). Tech-Ed is Microsoft's broadest-based, and (historically) one of its best attended shows. A number of clear trends are emerging.

The biggest, and most obvious, is - Tech-Ed is Back! Last year was one of the smallest Tech-Ed conferences I'd ever been to. And while everyone had a good time, there was an undercurrent of concern. Granted, the economy was in the dumpster, but some folks were questioning whether it was a blip or a long-term trend. But this year's conference is almost as well attended as the massive "Boston 'T' (as in Technology) Party" I wrote about several years ago. Maybe more.

People are ready to move forward. After a couple years of hunkering down, and making do with older systems, it is clear that many folks are ready to embrace the future. In the SharePoint booth, even though it has only been officially available for a few weeks, I'm seeing plenty of interest in migration to SharePoint Server 2010 from long-time SharePoint users. Add in side notes of folks saying they're upgrading (or have just upgraded) many other elements of their technology stacks, and it looks like the slump is coming to an end. IT is usually on the leading edge of a recovery, and from what I'm seeing we could be heading into some pretty good times.

The watchword is "value". Just because they want to move forward, they aren't charging ahead "willy-nilly". People want value for their money, and there is more of a "we want to do it right this time" attitude than I have seen in some previous conferences. They're willing to invest in the future, as long as there is a clear destination. No more just throwing some technology at the users to see what sticks.

The "value" is there. Not only in the Microsoft technologies, but in the offerings from the wide array of vendors set up at the expo, I'm seeing a lot more polish than flash. Even in the more cutting edge tools, like services in the cloud, and the forthcoming Windows Phone 7, the emphasis is on doing the real jobs that real users need to do.

An army, even an army of geeks, moves on its stomach! The conference dining offerings have been a mixed bag this year. The lunches have been (at least in my opinion) pretty decent so far. However, the consensus is that the so-called "continental" breakfast served each day has been a non-starter. Even folks from "the" Continent were complaining. In addition, there has been a distinct lack of fresh fruit - both during the meals, and the session breaks. Break fare in general has been as sparse as the breakfasts. As hot and muggy as the weather is, I have yet to see a single frozen treat from this conference.

And that, in essence is the message of this show. Like New Orleans itself, the economy seems to be on the mend after a major jolt. The road ahead is laid out. We (at least most of us) have our packs loaded up. We need to move forward, but we want to do it right, and we need the resources (food) to do it.

We're ready for what ever the future has in store, so bring it on!

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:

1. The Search service application is configured to use the Server Farm/Database Access account as the default content access account.
2. 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.

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.

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:

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?

Get the Lowdown in Party Town!

For 2010, Microsoft's biggest public educational event of the year has moved to the Big Easy - New Orleans, Louisiana. There, you'll find it easy to get the latest on the biggest technologies Microsoft has introduced over the last year, from Windows 7, to SQL Server, to Office and SharePoint 2010. 21 technical tracks lead to over 700 different sessions, hands on labs, and other educational interactions. You're sure to find plenty of ways to fill your time, and your brain!

One of those is the Technical Learning Center, or TLC.  The TLC is an array of dozens stations constantly manned with both internal Microsoft and external experts - MVP's, MCT's, and product team members - all ready, willing, and able to answer your questions. I'm pleased to announce that I'll be joining them in the SharePoint area.

So, come on down and join us! Get the details here. And if you haven't already signed up, what are you waiting for - Mardi Gras? Well, we've got that too!

Stop the Presses!

Microsoft has announced the discovery of a cross-site scripting vulnerability in the SharePoint 2007 (and WSS 3.0) Help system. Although they are still investigating the root cause and working on a long-term solution, they have provided a workaround which will mitigate the only known (at the time of this writing) attack vector. You can read the details of the vulnerability and a server-side workaround in Security Advisory 983438. The Security team have also posted some more explanations about this class of vulnerability and some client-side mitigations in this blog post.

A Little More Info

The vulnerability is what is known as an "injection attack". Essentially, arbitrary JavaScript can be run by being passed as a carefully crafted parameter to the built-in SharePoint Help page. This script will run in the context of the current user's client session, and can therefore perform any actions against the SharePoint site that the user could.

This does not turn the user into an administrator, or otherwise elevate their own privileges. As far as I can tell, it does not (as some reports have suggested) expose the user's password. Update: This is with the default SharePoint authentication. Custom authentication methods could potentially store credentials in an accessible manner. I have no way to test that scenario, but any attacker would need intimate knowledge of how that authentication module worked in order to exploit it. So, while your passwords are probably safe, this vulnerability could allow an attacker to probe for and read any information in SharePoint that the user does have access to, or to vandalize or destroy information the user is permitted to update. Therefore, for the time being I strongly suggest disabling the help.aspx file in the Layouts folder of your SharePoint servers, either by following the instructions in the security advisory or through other means. (At this time, I don't suggest just deleting the file.)

Update #2

It has been pointed out that, although the attack itself cannot (usually) directly glean the user's credentials, an injected script could prompt an unsuspecting user into providing them, thinking the request was coming from your site. This does not change my advice (applying the mitigation procedures), but it should increase your priority in doing so.

Some SharePoint News

Life has been a bit hectic around here, but I haven't disappeared. Here's a quick rundown of some recent and upcoming events.

First, the big news -

SharePoint 2010 is Available!

Not all editions, but you can get the most popular parts if you are a subscriber to MSDN or TechNet Plus:

• Microsoft Office 2010 Professional Plus
• Microsoft SharePoint Foundation 2010 (this replaces Windows SharePoint Services)
• Microsoft SharePoint Server 2010 (this replaces MOSS. You can get keys for Standard or Enterprise edition)
• Office Web Apps (Web-based versions of Word, Excel, PowerPoint, and OneNote)
• Microsoft SharePoint Designer 2010

Look for launch events all over the place throughout the summer!

You Have Two Chances to for Live Chat Online with MVP's!

The other news for this week is that there are not one, but two MVP real time chats with your favorite SharePoint MVP's. The first one is tomorrow (Tuesday, April 27) at 4:00pm Pacific time (7:00pm Eastern). The second chat is Wednesday at 9:00am Pacific (12 noon Eastern). Check out the MVP Program Blog for details of where to sign in and who'll be online when, but I can tell you that I'll be online for the Wednesday Chat!

That's all for now. I'll see you there!

Stalking the Ruby-hearted Gleamcatcher

Updated 4/19 to use a picture of the real ring rather than the catalogue image...

OK, so this still isn't the article on incoming SharePoint email that I promised. That article (which will be cross-posted at EndUserSharePoint.com) is still coming, as is an article for Microsoft's Get the Point! blog. But from a personal standpoint, this is even more important.

Over the Easter holiday weekend, I proposed to my girlfriend, Brenda, while we were on a nature walk. Essentially, I set it up so that on our walk we would be seeking out the nesting site of the very rare "Ruby-hearted gleamcatcher." It turned out that the "gleamcatcher" was actually a ruby and diamond pendant, and the "nest" was its box, which I had previously nestled in a tree.

After I gave it to her, I figured she would be a little disappointed, since we had been discussing the idea of marriage for a while. So, I mentioned that the reason I chose that particular pendant was that it went along so nicely with the ring I had in my pocket (pictured above). I took it out and placed it on her finger, asking her to join me forever on that great nature walk of life (OK, those weren't quite the words I used, but they should have been).

To make a long story short, she said "Yes!", so on August 1st...

We're Getting Married!

(Note: Brenda is a much more private person than I am, and doesn't like her picture taken, so sorry, no pix at this time. Maybe for our wedding site once I have that set up.)

Wrox in the Worx (uh, Works...)

If you've been following my tweets lately, you'll have noticed me mentioning writing a few times. I'm pleased to announce that, in cooperation with my co-authors Asif Rehmani and Bryan Philips, I'm working on a new SharePoint Designer book. Like our previous book, it will be a Wrox title. In this case, however, it will be "Beginning SharePoint Designer 2010".

This change in series, from Professional to Beginning, means that it will include a bit more basic information, and more hands-on examples; but that doesn't mean it will be any less comprehensive. We'll still be covering workflows, site and page design, governance, and all of the other things that make SharePoint Designer 2010 a great tool, not only for graphics folks, but information workers as well!

I also want to emphasize that this will not make the older book, Professional SharePoint Designer 2007, obsolete. If you are still working with a SharePoint 2007 or WSS 3.0 site, or web sites based on FrontPage extensions or other non-SharePoint web technology, then SPD 2007 is still the tool for you. SharePoint Designer 2010 will only work with SharePoint 2010 servers.

Oh, Speaking of SharePoint 2007, I'm almost done with my next major post, wherein I'll be discussing the ins and outs of email enabling SharePoint lists. You won't want to miss it!

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!

Watch this Space!

My Session

Nevertheless, there were 20 sessions, in four tracks. My session was the first of the day in the "No-code solutions" track. I gave an Introduction to SharePoint Designer 2010 (click the link to download a PDF of the presentation). I touched on many of the key features, but gave special emphasis to how you could easily configure SharePoint to disable the "dangerous" functions (modifying master pages, and editing or un-ghosting pages). This, along with SPD's new emphasis on business process integration, makes it a great tool to give to your business analysts and information workers, without needing to worry about them "messing up" your corporate branding or making their sites unusable.

Collaboration and Camaraderie

Of course, the big benefit of coming to a smaller conference is getting actual face-to-face time with the presenters, without the pressure of competing with thousands of others who want the same thing.

And let's not forget drawing for door prizes!

In the end, knowledge was shared, connections were formed, and a good time was had by all.

I'm really looking forward to the next one!

P.S. In case you missed it earlier, here is a link to a PDF of my presentation.

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.

On the Road Again...

Well, 2010 has just barely gotten started, and SharePoint Saturday's are already in full swing. I'm pleased to announce that I've been selected to present at the SharePoint Saturday in Indianapolis, Indiana. This takes place on January 30th, 2010, at the Gene B. Glick Junior Achievement Center. Click on the link or logo above for all the details, including registration, a list of the other presenters, as well as the Twitter feed of #SPSIndy commentary.

A SharePoint Saturday is a free to attend event that serves as a mini SharePoint conference. You get some of the same world-class speakers and content found at the big events like Tech-Ed. If you're in the Indianapolis area, and want to know more about SharePoint, this is not something you'll want to miss.

The Obligatory Year-end Report

It is now the last week of December, and you know what that means. Lying in wait among the crumpled wrapping paper, danced-out sugarplums, and pine needles (not to mention the feathers and other "presents" from all those birds your true love gave to you) you'll find year-end wrap-ups from every corner imaginable.

This is mine. :) I'll get to the more general stuff in a moment, but there was one personal SharePoint-related thing that stood out for me in 2009, and that happened the very first day.

I Became a Published Author

While I (along with Asif and Bryan) did all of the work in 2008, my book Professional Microsoft Office SharePoint Designer 2007 was officially released by Wrox Press on January 1st of 2009 (December 31st, 2008 in some markets). I'm honored by the very positive reviews, and want to thank everyone who has purchased it.

Ironically, its importance is going to continue on into 2010, and possibly beyond. While SharePoint 2010 is top-of-mind for many people right now, the fact is that SharePoint 2007 is going to be around for a long time to come. But, SharePoint Designer 2010 cannot work with SharePoint 2007 sites, so SPD 2007 will still be needed if you want to customize older SharePoint sites. Since SPD is now a free download, there isn't much in the way of printed documentation, other than (you guessed it) third party books - like mine.

The Year of the "Community Conference"

One amazing thing that stood out about 2009 was the popularity of independent SharePoint-related conferences and seminars. I personally presented at two - the "Best Practices SharePoint Conference" in San Diego, and the "SharePoint Technology Conference" in Boston.

But the big trend was the emergence of the "SharePoint Saturday" mini-conferences. These are one-day, free to attend conferences, that are held all over the world. Here you will find breakout sessions by the very same experts that present at the larger venues, like Tech-Ed and the official Microsoft SharePoint Conference. Check out the SPS site, and plan to attend one of these events near you!

And, of course, no mention of the "Community Conference" would be complete without mentioning the "Conference Community" on Twitter. This is a bit less formal, but essentially you will find a play-by-play for almost every conference being happily tweeted by the attendees with hash tags like #SPC09, or #SPSINDY.

SharePoint 2010

Of course, the big news was the announcement of Office and SharePoint 2010, and the availability of the public beta. The official release is currently set for the "first half" of calendar 2010. As many articles have pointed out already, much has changed. There will probably still be some significant changes between now and the final release, though what they might be, nobody can say.

Other Significant Events

Some of the other SharePoint things that happened to me in 2009

• I became Michael Gannotti's very first "Backseat Driver"
• I was once again awarded as a Microsoft MVP for SharePoint Server
• I autographed and gave away almost 500 copies of my book while working the Microsoft Technical Learning Center booth at Tech-Ed in Los Angeles

SharePoint, the Target

No post about SharePoint in 2009 would be complete without some mention of another buzzphrase that started appearing in 2009 - "SharePoint Killer". Almost every new application that had the slightest thing to do with collaboration or content management seemed to earn headlines of "Is X the Next SharePoint?" or "Y will make SharePoint Obsolete". From Google Sites to Google Wave. From Drupal, to Alfresco, to the classic DotNetNuke. Yet while each may have one area where it shines, none of them really has the versatility or power to match SharePoint, assuming they are even truly comparable.

Blog Highlights

For those of you new to my blog, here are some of the articles I wrote this year that you might find particularly interesting:

• Press F1 - SharePoint Help is on the Way
• Selecting Editors in SharePoint Designer
• Something Old In Something New
• Binary Free SharePoint Twitter Search Web Part
• A Hidden Gem - the Preview Pane View in SharePoint
• Wiki-in-the-Box - Is SharePoint Wiki Really that Bad?
• On Babies, Bathwater, and SharePoint Designer
• Discovering the Setup User Account - A SharePoint "Whodunit?"
• SharePoint on a Shoestring
• Office 2010 - A Quick Look
• Advanced Calculations in SharePoint Designer Workflow (Part 1)
• Calculated Columns and SPD Workflow Part 2
• Indexing SharePoint List Columns
• Knowing Your Limitations
• A Free SharePoint Org Chart Web Part
• SharePoint Virtualization

Looking Ahead

With the planned official release of SharePoint 2010, 2010 the year looks like it will be just as exciting as 2009. One thing that is very clear is that Microsoft is putting a lot more effort into the supporting infrastructure for SharePoint. From native support in Visual Studio, to online documentation, to partner training.

While people may have been shocked by SharePoint's meteoric rise, nobody is going to be surprised by its continuing momentum.

"You Must Un-learn what You Have Learned!"

The public beta of SharePoint 2010 has been out for a few weeks now. Many people are discovering and blogging about some of the great new features you're going to find. Yet there have also been some significant changes to existing features. These are things you may have been using every day in SharePoint 2007 and WSS 3.0, but which in SharePoint 2010 have moved or changed in ways could cause confusion to experienced users.

In this article I'm going to focus on changes the typical end-user would see. In future articles I'll talk about changes for site owners and administrators.

If it Ain't Broke…

SharePoint 2007 took a lot of heat for having certain "quirks" in its user interface design. For 2010, much as they did for the Office clients in 2007, Microsoft put a lot of R&D into what it would take to make SharePoint easier for typical users. This resulted in a lot of changes.

Human beings are creatures of habit. With certain notable exceptions, we don't much like change. Despite having worked through a non-intuitive learning curve, or sometimes because of it, we would rather keep doing things the way we are used to than learn new ways - even if those ways are better.

...Fix it Anyway

Only time will tell if the changes Microsoft made truly are for the better, but they've definitely been made. Let's start by looking at the basic team site page in SharePoint 2010 side by side with its SharePoint 2007 equivalent:

At first glance, they're pretty similar. The WSS logo has been replaced with a "real" picture, but there's still a banner, title area, quick launch, and content space. But look a little closer. The Site Actions menu has moved. No big deal there - lots of custom master pages move that around. But, the new placement is comparable to the Backstage/File menu in the new Office 2010 client applications, thus making it a "natural" place for users to look for "application"(site)-wide functions. This analogy becomes even more obvious when some of the other tabbed interface options start showing up. (You'll see that later in the article.)

Where's MySite?

Another subtle change is the "personal" section of the banner. In SharePoint 2007, you had separate entries for User ID, links, and a direct link to your "My" site.

All of these options are now accessed through the menu under your name. There is also no reference to My "Site", rather it simply calls it your "Profile".

I think the hope here, is that by de-emphasizing the "independent site" aspect of the profile and personal storage, while actually expanding its function (the new profile features could fill up several articles on their own), resistance to deployment in certain enterprises would be reduced.

Bread-Crumbling Navigation

Getting around from site to site, and from place to place within a site, has received a LOT of attention in SharePoint 2010. In many cases, this has meant "reimagining" the concept of a breadcrumb.

In the case of 2007 site navigation, a breadcrumb stretched across the top of the page content area:

For large site hierarchies, this could become unwieldy as it stretched across the page. For 2010, Microsoft replaced it with a folder icon in the tab banner, which produces an indented hierarchical view of your current location:

Going the other direction, in SharePoint 2007 lists and libraries selecting a view was accomplished by selecting it from a drop-down list on the toolbar.

In SharePoint 2010, there is no list toolbar. While you can drill into the ribbon and find the view settings, then select your view, that's a lot of clicking. Fortunately, Microsoft has turned the title panel into an in-site breadcrumb. When looking at a list or library, the last item in that breadcrumb is the name of the current view. If you look carefully, you'll notice that there is a "down triangle" arrow. That's your hint that this element is actually a dropdown menu, where you'll find all of your view selecting goodness.

Tied up with a Ribbon

Of course, the rest of the stuff that used to live on a list or library's toolbar:

has been moved into the Library tab of the new ribbon interface:

By the same token, individual items that lived in an individual item's dropdown:

have been moved into the Documents (or other appropriate item's) tab:

Note: In this case, the individual item dropdown is still there as well.

Summary

Some folks say, "The more things change, the more they stay the same". There have been a lot of changes in SharePoint 2010. While there are some things that have stayed the same, they are actually in the minority. In this article, I have gone over some of the many changes to "carry over" functionality you will find when moving from SharePoint 2007 to SharePoint 2010. There are many more than I could hope to address in a single posting. I hope, however, that this article has given you some ideas of where to look if you can't find your favorite function where it used to be.

The Fix is In, Thanks to Tom Resing

I have great news, thanks to fellow SharePointer Tom Resing. In my previous post I mentioned the problems the Community Kit for SharePoint:Enhanced Blog Edition has with the new link tracking parameters FeedBurner just started adding to their links.

In that post, I talked about the trials and tribulations of trying to get CKS:EBE working by installing an updated version. It turns out there was another approach to the problem. Although Google made the change to FeedBurner effective by default, Tom pointed out that they do offer an option to turn it off.

The Quick Fix

So, for those of you using both FeedBurner and CKS:EBE, here's the scoop. On the left menu in your FeedBurner Feed Stats Dashboard, in the Services section, is an option called "Configure Stats":

When you select Configure Stats, you have a section called "Reach", which has several options. You need to uncheck the box for "Track Clicks as a traffic source in Google Analytics":

That's all there is to it! Save the settings, and everything should be back to "normal".

Of course, it would have been nice if Google had posted a more conspicuous notice that they were making this change, and where it could be configured. It would have been even nicer if they had made the change "opt in" instead of "opt out".

Nevertheless, what's done is done. You should now be able to click through from my RSS feed directly to the articles you are interested in.

I apologize for any inconvenience.

At Least They Didn't Burn the Turkey

Just a quick note before I run off for the Thanksgiving holiday (USA). If you have been a subscriber to my RSS feed, you may have noticed a problem clicking through to my blog posts lately. This is because of a change that FeedBurner made a few weeks ago. They added extra parameter information to the connection string of links back to the blog.

This is theoretically a good thing, as it allows site logging to better determine where visitors are coming from. However, this blog uses the Community Kit for SharePoint: Enhanced Blogging Edition (CKS:EBE). The way CKS:EBE handles URLs doesn't allow it to correctly interpret these additional parameters. This resulted in broken page displays. You can still eventually navigate back to the right page, but it isn't as convenient as it should be.

I have just tested a patched version of CKS:EBE to resolve that problem. While the patch for the FeedBurner problem seems to work correctly, there are significant issues with other changes to the patched build of CKS:EBE. I noticed that my tag cloud was no longer resizing the keyword links to their proportions, for example, and there were major authentication problems. These glitches are bad enough that I decided to retract the update.

I apologize for the inconvenience. Rest assured, I'll continue working on getting links from FeedBurner working (without breaking everything else).

In the mean time, Have a Happy Turkey Day!

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.

Enhancing a CodePlex Project

In this article, I'm going to get a bit more technical than is my normal wont. In fact, I'm going to go into Visual Studio, and show you some C# code as well.

(Waiting a few minutes for folks who know me to pick their jaws up off the floor, or even find some smelling salts... Yes, Virginia, I really can program when I have to. :) I just very rarely have to.)

That doesn't mean I'm going to be building this project from scratch. Far from it. So, if you're looking for info on how to build a .wsp solution package, this isn't the article for you. I am going to talk a bit about user choice, web part properties, a programming technique called "recursion", and the SharePoint API (in particular, accessing the User Profile store).

What I'm going to do is show you how to fulfill a very common business requirement by starting with a fairly simple CodePlex project, and tweaking it until it is something that does just what you need.

A Common Request

Virtually every client I've implemented SharePoint for has asked for an organizational chart. The problem is, there aren't very many org chart web parts out there for SharePoint, and those that are, tend to have issues (usually performance) - especially if you have a fairly large organization.

SharePoint Server 2010 finally makes a really cool organization chart part of the package. It is Silverlight based, and works pretty fast. Unfortunately, that's 2010, and it is going to be a while before many companies are ready to deploy it. We need something that will work for "today".

Finding the CodePlex Project

So what do you do? Well, a quick online search reveals that there is indeed an org chart part on CodePlex, called (quite originally) "OrgChartPart". This was written by Rodney Viana. Looking at the specs, it sounds promising:

• It reads profile information from SharePoint
• It uses a free JavaScript Org Chart rendering engine
• And of course, it is free, too!

What's not to like?

There is a bit, as it turns out, but let's start with the good. Installing the OrgChartPart is a breeze. Download the .wsp file from CodePlex, install it with the "stsadm -o addsolution" command, and deploy it to your web application(s). You will then need to add the part to your web part gallery (there is a feature that does this, or you can do it manually), then add it to a page. (I suggest you add it to a web part page that has nothing else on it, for reasons you will see in a moment.) This takes 5 minutes, tops.

The web part reads your MOSS profile store, and emits the chart. Just like that, you're done!

On the surface, that doesn't sound too bad. But dig a little deeper, and you find a big red flag - the author warns that you shouldn't use the part if you have more than 500 profiles in your organization. Of course, if you have more than 500, you've got a problem.

But even if you have fewer than 500 profiles, you might not like the results. Consider the following clip of the chart initially rendered by this part:

This is a pretty complicated organization - it doesn't fit on the screen, and it is completely expanded by default. But, there's another issue. The chart looks a little "top heavy". That's because the Active Directory includes a number of accounts that aren't actually users, and therefore don't have associations in the hierarchy. Looking closer, you can see that Patricia Doyle, the CEO, has conference rooms as peers! There's also some clipping of titles and departments.

Note: This is technically a problem with the Active Directory and/or its import. In theory, you could set up the AD/Profile import to exclude non-person entities. But, that's another story... :)

Looking Under the Hood

Still, even with those issues, you can see the potential in this part.

Note: Most of the remainder of this article discusses how the OrgChartPart was originally implemented, and how I updated it. If you just want the end results, you can download the original source from CodePlex, plus my replacement OrgChartPart.cs file and rebuild the solution. (I have also given the code updates to Rodney, who may update the actual CodePlex project.)

Fortunately, as with most CodePlex projects, we have access to the source code. I downloaded the source and opened the project in Visual Studio. What we see is, the part is actually quite simple. There is one .cs file (the two in the image below include my edited version, plus the original) and the ECOTree JavaScript library. ECOTree is what actually does the heavy lifting of drawing the chart. By default, OrtChartPart uses just a fraction of the power of this library (follow the link above for more details).

There is also a "departmentconfig.xml" file hiding in the Layouts folder of the 12 hive. Hmmm...

Looking at the code itself, we find there are four main functional areas beyond the basics needed to render a web part:

1. Handling that department file
2. Crawling the profile store
3. Building a profile render block
4. Building the chart

Now, We Tweak

In the rest of this article, I'm going to look at each of the sections I described above, tell you how the original code worked, and show you what I did to update them. While I won't embed the entire source in the article, you can easily download it if you want to examine everything in context.

On the Department File

For now, I'm just going to say that while the idea of mapping the department information in the profile to department home pages is admirable, the way it was implemented was causing some serious performance issues, and would be a long-term maintenance headache. Therefore, I commented out the two lines that actually make use of it (249 and 267 in my updated file), and replaced the link rendering with a simple text rendering. Here are the original and replaced lines from the updated code ( 267, 268).

//this.department = config.Find(EmptyIfNull(Profile[PropertyConstants.Department]));
this.department = EmptyIfNull(Profile[PropertyConstants.Department]);

"config.Find" is part of a config object that is defined elsewhere in the code. For purposes of this article, though, we're just going to ignore it.

Crawling the Profile Store

The profile crawl itself takes place in a function called PopulateOrg(). Examining this routine, a few things stand out.

First, there are two different ways for nodes to be added to the chart. One uses information read from a user's profile, the other feeds static information into a node. (This is used primarily to display an error message, if needed.)

Second, the population routine reads the entire profile store in one fell swoop. Combined with the inefficiency of the department link mapping mentioned above, this is a big part of the performance limiting the part to organizations with 500 or fewer profiles.

Finally, hidden in this routine (but commented out) is a nice little set of sample data.

At its core, an organization is a hierarchy. A hierarchy is made of parents and children. Technically, as long as you know the parent of each node, you can manually construct the organization. This is the approach originally taken by this web part.

foreach (UserProfile pf in pmManager)
{
     Details dt = new Details();
     dt.AddProfile(pf, this.Page.Request);

     if (dt.TrimFullName != String.Empty)
         employeeList.Add(dt);

}

However, a UserProfile object itself has methods for listing its children and ancestors directly. This means that we can easily start at any point in the tree, and generate the organization descendent from it, as well as the chain of command above it.

The ancestors are represented in a single collection, called through the GetManagers() method. The first level of children are just as easily retrieved with the GetDirectReports() method. However, if we want more than one level of child, we would then need to call the GetDirectReports() method for each child returned in the previous call.

If you try doing this with loops, things can get complicated pretty quickly. However, there is a simple way to to handle an arbitrary number of child nodes, to an arbitrary depth. This is a technique called "recursion". Essentially, you create a function that calls itself. In order to keep it from running forever, one of the parameters that should be passed to a recursive function should be a "depth" limiter. Within the function, the child calls decrement this limiter, and stop calling when it reaches a threshold level. In my update, I create the recursive function addChildren(). This takes the starting profile, and the depth limiter as parameters.

protected void addChildren(UserProfile Parent, int levels)
{
    try
    {
        foreach (UserProfile pf in Parent.GetDirectReports())
        { 
           Details dt = new Details();
            dt.AddProfile(pf, this.Page.Request, false);

            if (dt.TrimFullName != String.Empty)
            {
                employeeList.Add(dt);
                if (levels > 0)
                    addChildren(pf, levels - 1);
            }
        }
    }
    catch (Exception ex)
    {
        AddInList("1", "", "Error", "", ex.Message); 
    }
}

Notice also that I have added a parameter to the AddProfile method of the details (dt) object. This third parameter allows me to force the profile being added to act as a root, or top-level, node. (This is used for the management chain of command.)

Giving Your Users Choices

Looking at the stuff I've described in the preceding section, there is something very different from the original implementation - instead of crawling the whole profile store, I crawl a specified subsection. That requires two pieces of input - the node I plan to start with, and how deep I want to crawl.

Fortunately, when you create SharePoint Web parts, you can easily allow the user to enter configuration information. In this case, I am actually going to give the user three options. The third will allow the user to show the sample data instead of the active directory. (Naturally, I uncommented the sample population section, and wrapped the two population methods in an if...else block.)

To add a property to a web part, you add some descriptive information to say how the property is to be displayed. You also set up a public property variable to appear in the configuration pane, and a private variable to use in your code. The private variable can include a default value. The public property includes a get and a set block. While these three properties simply take the value as given, you will see later that this isn't the only option.

[Personalizable(PersonalizationScope.Shared)]
[WebBrowsable(true)]
[System.ComponentModel.Category("Org Chart Settings")]
[WebDisplayName("StartProfile")]
[WebDescription("Enter the top user to display:")]
public string StartProfile
{
    get
    {
        return startProfile;
    }
    set { startProfile = value; }
}
private string startProfile;

[Personalizable(PersonalizationScope.Shared)]
[WebBrowsable(true)]
[System.ComponentModel.Category("Org Chart Settings")]
[WebDisplayName("ChartDepth")]
[WebDescription("Subordinate levels to display:")]
public int ChartDepth
{
    get
    {
        return chartDepth;
    }
    set { chartDepth = value; }
}
private int chartDepth = 1;

[Personalizable(PersonalizationScope.Shared)]
[WebBrowsable(true)]
[System.ComponentModel.Category("Org Chart Settings")]
[WebDisplayName("Show Sample Data")]
[WebDescription("Show sample data instead of profile info:")]
public bool ShowSample
{
    get
    {
        return showSample;
    }
    set { showSample = value; }
}
private bool showSample = true;

This is how the properties look in the Web part configuration pane. The "CacheTime" parameter was included in the original part (though it is unused in the code). I'll discuss the "Left To Right" parameter later.

You might also notice that I set the default value of showSample to true. This allows the user to place the web part on the page and see a reasonable representation of its function, without needing to first set the start point and depth.

Note: The chart initially renders with only the first layer of children open. I expanded it for this screen shot.

Rendering a Profile

Each node on the chart is constructed of HTML. The HTML is assembled in the ReturnItem() function.

I wanted to enable two functions not already present - showing the user's profile picture, and allowing the user to "re-home" the chart on another node in order to enable navigation of the entire organization in convenient sections. This meant I needed to add two properties to the details object, and then add the code to display these properties appropriately in the chart.

In order to make the re-home function work, I added an override to the StartProfile. Essentially, if there is a rootuser query string parameter, the profile specified there will be used instead of the one set in the web part property. The SetRoot link calls the current page with rootuser set to the selected profile.

In addition to the actual HTML, however, the look of the node contents are controlled by styles defined in the ECOTree.css file. In order to allow the picture to render, as well as permitting the text to fit, I needed to modify the .econode class in this file as follows.

.econode {
    text-overflow: clip;
    font-family: Verdana, Geneva, Arial, Helvetica, sans-serif;
    font-size: xx-small;
        color: White;
    padding: 2px;
}

Rendering the Chart

Just as we built up a node by assembling the HTML, the chart itself is built by assembling JavaScript. One of the things I did was to examine the functions provided by the ECOTree library. I found that it offered a lot of flexibility that wasn't currently in use. I felt the most important was the ability to set the orientation. Here's where that "Left to Right" checkbox comes into play. The library uses a parameter .RO_TOP or RO_LEFT to decide whether the chart is top to bottom, or left to right.

This is the code that reads and sets that web part parameter:

[Personalizable(PersonalizationScope.Shared)]
[WebBrowsable(true)]
[System.ComponentModel.Category("Org Chart Settings")]
[WebDisplayName("Left To Right")]
[WebDescription("Root at left, otherwise at top:")]
public bool RootLeft
{
    get
    {
        if (chartOrient == "LEFT")
        {
            return true;
        }
        else
        {
            return false;
        }
    }
    set
    {
        if (value)
        {
            chartOrient = "LEFT";
        }
        else
        {
            chartOrient = "TOP";
        }
    }
}
private string chartOrient = "TOP";

This demonstrates the kind of things you can do with the get and set blocks of a parameter. The user gets to the see the checkbox that represents a binary choice, but the internal variable is a string, meaning that we can render the part simply appending the string value without inserting an "if" block.

myTree.config.iRootOrientation = ECOTree.RO_");
sb.Append(chartOrient);
sb.Append(@";

The Results

The image below shows you how the revised chart looks with the same profile store shown in the first image.

This is a much more manageable presentation. It allows the user to drill into the organization as needed, and since we set the starting node on our CEO, those conference rooms who don't report to anybody are nowhere to be found.

I hope this article has shown you how easy it is to stand upon the shoulders of giants when looking for features to add to SharePoint. I built upon the CodePlex OrgChartPart, which itself leveraged the ECOTree charting library.

There are many more things you could do with this web part. You could add options to select the color of the nodes, for example. Or give users a check-box to render the entire organization at once, as the original part did.

The options are limited only by your imagination!

Buried in Bureaucracy and Rebuffed

Note: This is a follow-up piece to my "In a Fix with Ford" article. See that if you need some additional background.

Where does one begin a tale of woe? For that, my friends, is what we have here. Six weeks ago, I wrote my original article with high hopes that I could prevail upon Ford to do the right thing, and fix the known design problems with my early production 2006 Ford Fusion. Little did I know that I had about as much chance of success as Don Quixote in tilting at windmills.

An Apology to the Messenger

First, I want to express my appreciation to Marq Boggs, Service Manager at Don Hinds Ford, in Fishers, IN. He had the great misfortune of being bearer of the bad news that Ford had no intention of fixing my car's problems. In my initial article, it may have seemed that I was "killing the messenger" by placing a big part of the blame on his dealership. That was not my intent, and if it was taken that way, I humbly apologize.

In fact, Marq has been of great assistance: first, in confirming that my car does indeed suffer from every one of the issues described in my first article; second, in taking it upon himself to address one of the problems by flashing my car's computer with up-to-date firmware; and finally, in chasing through some of the bureaucracy at Ford in an effort to find someone willing to address my problems.

Unfortunately, he was not successful.

Pointing Fingers, Hot Potatoes, and Monkeys in the Middle

The implication here is, that Ford has refused to repair my car. Interestingly, Ford customer service's own reply to me (I'll call it the "kiss-off" letter - others might choose a more colorful term) seems to imply that the dealership was the one with the final say in the matter:

Dear Woodrow Windischman,
We have looked into this matter and our records indicate that a decision has been made by your servicing dealership.  In addition, they suggested that you take your vehicle to the selling dealership and see if they would provide additional assistance.  Please be advised that the CRC can not overturn this decision.  However, to ensure our records are complete we have documented your feedback.
We would like you to know that we understand your concern and that we appreciate the time that you have taken to write us about this issue. 

(Emphasis added)

I talked to Marq again to see what was going on. It seems that each dealer is allocated a certain amount of "customer loyalty" money by Ford. This is supposed to be used to provide exceptional services to the dealer's customers. The official bottom-line position of Ford was that they weren't going to pay to fix my car, but if the dealer wanted to, they could provide the repairs out of these loyalty funds. Here's the rub - I didn't buy my car from Don Hinds, and I'm not really local (for now, I'm just in Indy on a contract), meaning future purchase prospects are limited as well. So, there really isn't a good reason for them to use a big chunk of these (rather scarce) resources on my car. I can understand this, and there are no ill-feelings from me on this account.

What about my "selling dealership" (Rice Ford, in Warsaw, IN - where I actually bought my car)? Well, I spoke to Bud Shanks, the service manager, and there was good news and bad news. The good news is, he and Mr. Rice agree that Ford should be responsible for fixing my car. The bad news is, they agree that Ford should be responsible for fixing my car. Therefore they don't feel it is appropriate to tap their loyalty funds for my repairs either. There is another complication - as I mentioned, I'm on a contract that has me over 100 miles away from the dealership during normal shop hours. In order for me to take my car there for service, I would need to take at least a day away from work, thus negating a big part of any benefit from having the repair covered.

How to Make a Billion Dollars

A company is more than its most recent marketing campaigns. I was proud of the fact that Ford didn't accept bail-out money from the government last year. I remember their "Quality is Job 1" campaign. I remember when they used to offer lifetime warranties on repair service. Notwithstanding the (truly minor) problems at issue here, I've been very happy with the service my Fusion has given me.

It is ironic that just a few days after I got their final kiss-off, Ford announced that they had made about $1,000,000,000 (that's one billion dollars) in profit during the quarter of my discontent. This during one of the worst economic downturns in recent memory. (No, how ever much the media likes to portray it that way, it isn't even close to the "real" depression of the 30's, or even the "stagflation" times of the late 70's. Doesn't anyone remember the double-digit mortgage interest rates?)

According to my experiences, and based on conversations with the dealers, a big part of this profit has been made by cutting back on the service and support provided to its customers and dealer base. Yet this "reputation" for quality and service is one of the reasons Ford was able to make sales while others were foundering.

The Big Picture

Everyone involved here agrees that it should be Ford's responsibility to fix my car. Everyone, that is, except Ford themselves.

Of course, whether paid for by Ford or not, I need to get my car fixed. This whole adventure started when I had to pay an ESP extended warranty deductible for a repair on my shifter, who's design was changed due to the very problem I suffered from. That case was made even more frustrating by the fact that the deductible was almost the entire cost of the repair. That ESP is still in place, and some of the issues I'm having are covered under that plan. Of course, I'll have to pay another deductible. In the end, given the cost of the ESP to begin with, I'll end up having paid the entire cost of the repairs, and then some.

If you've followed my blog for the last few months, you know that my life has been filled with highs and lows lately. In the grand scheme of things, is getting a few non-life threatening car repairs paid for all that important? Not really.

But that still doesn't make the way Ford has been treating its dealers and customers "right".

SharePoint Conference 2009 Wrap-up

The show is over, but the adventure is only beginning. As stated before, SPC09 in Las Vegas was the coming out party for SharePoint 2010. While we will still have to wait a few weeks for stable bits to play with, over 7000 attendees came away with a treasure trove of knowledge and documentation.

In my previous installments, I talked about the venue, the atmosphere, and the keynotes. I've also touched on some of the new Office integration story.

Of course, the star of the show was SharePoint 2010 itself. So, I'm going to dedicate the rest of this post to a punch-list of changes/improvements. I know I've missed a few (or more than a few) new elements, or misunderstood a detail or two, but even so the list is impressive. You'll see that the SharePoint team at Microsoft have not been resting on their laurels during the three years we've been waiting. Over the next few months, I'll fill in more details on the individual features, correct what I got wrong, or update you on the inevitable feature changes as things get closer to release.

The Basics

It seems Microsoft can't release a new version of SharePoint without tweaking the names a bit. Just as "SharePoint Portal Server" and "SharePoint Team Services" became "Microsoft Office SharePoint Server (MOSS)" and "Windows SharePoint Services (WSS)" in the 2007/3.0 wave, For 2010/4.0, they're simply called "SharePoint Server" and "SharePoint Foundation" respectively.

The Public Beta of SharePoint 2010 is to be released in November 2009.

The actual product release is planned for the first half of 2010.

It is still "SharePoint". Although many weaknesses have been addressed, core functionality remains essentially similar, with lists, libraries, site model, etc... Since "form follows function", many of the visual elements will be very familiar.

Infrastructure and Administration

• Requires 64bit throughout the stack
• Windows Server 2008 as a baseline OS
• Complete redesign of Central Admin
• Shared Services: No more monolithic "Shared Services Provider". Instead things formerly grouped under an SSP are individual Shared Service Applications.
• Search architecture changes: index role can be spread across multiple servers
• "Normal" SharePoint search now scale-tested to around 100 million items.
• Business Data Catalog transformed into Business Connectivity Services, and becomes part of SharePoint Foundation (no more enterprise CAL required).
• BCS info becomes available throughout the Office 2010 suite, not just SharePoint, and offers read/write capability.
• FAST Search is available as an add-on for Enterprise CAL users at per-server pricing.
• Enterprise-wide metadata support
• Lists are more scalable, and can be "external" to the SharePoint content database. Admin can set maximum returned items to prevent bogging the system down.
• Servers can be upgraded without enabling the new UI by default. Site owners can then switch over when their members are ready for the change.
• AD Group Policies can prevent installation of SharePoint on unapproved systems.
• Even more databases.
• Better auditing and reporting in-box.
• "License" logging to see which features are used.
• Allowed to read log/report database to build custom reports.

Client Facing

• UI: No IE6 support for collaboration/team sites. Can still make IE6 friendly publishing sites.
• Firefox 3.x is a Level 1 browser.
• "Accessible" CSS-based layouts, and XSLT-based list views.
• Table-based layouts are gone
• Cleaner, modernized themes.
• Ribbons are primary control mechanism, just like Office.
• There is no longer a separate basic "Wiki" site type in SharePoint Foundation. (However, there is now a publishing-based "Enterprise Wiki" site in SharePoint Server.)
• All team sites can have wiki functionality enabled, and made the default.
• Theme colors can be imported from PowerPoint themes for compliance with corporate standards.
• The GroupBoard template is available out of the box.
• List lookups can pull multiple fields
• List lookups support referential integrity (blocking/cascading deletes)
• Field validation

Social

• Major overhaul of profiles and My Sites.
• Includes "status" functionality (i.e. FaceBook/Twitter style updates)
• Unique org-chart presentation
• "Folksonomy" to support user-created shared tags in addition to Enterprise "Taxonomy" metadata.
• Can tag non-SharePoint content

Search (Standard)

• Improved handling of metadata
• Faceting (now called "refinement") is built-in
• Social input to ranking

Search (FAST)

• All standard SP Search features
• Deep refinement (polls entire result set to get actual counts)
• Concept metadata from unstructured content
• User-role tailored result sets.
• Massive scalability
• Superset of standard SP Search API
• Managed through the same admin UI

SharePoint Designer 2010

• Complete UI redesign, based on SharePoint "artifacts" rather than file structure.
• SPD 2010 tied to SP 2010. Will not work on older versions or non-SharePoint sites, and old SPD won’t work against SP 2010 sites.
• Much better Visual Studio integration – exports Solutions that can be imported into VS for both site designs and workflows.
• SPD Workflows can be independent of specific lists.
• SPD Workflows can easily be exported into either Visio 2010 or Visual Studio 2010
• Finer administrative control over what SPD users can do.
• Page model is the same, but many changes based on new CSS layouts and Theme engine.

Development

• The "platform" aspect of SharePoint receives a lot of emphasis with this version
• Use Visual Studio 2010 for full visual web part design and other SharePoint integration points
• Can install SharePoint on a client OS (Vista or Windows 7, 64-bit) for dev sandbox.
• Much better developer documentation out of the gate
• Client Side object model to make Silverlight controls and web parts easier to develop.
• REST, ATOM, and other web service interfaces fully supported.

Conclusion

In his keynote and his write-up from a couple weeks ago, Jeff Teper pointed out that the vision and purpose of SharePoint hasn't really changed much from the original 1-page proposal over 10 years ago. Yet the implementation of that vision has grown by leaps and bounds over the succeeding versions. I hope I have shown you that SharePoint 2010 will continue in that tradition. As I said earlier, I'm sure I've missed things. These were just the elements that stuck out as I was going through sessions and reading material. But I have to admit, I'm excited.