while (alive) { writeCode(); }

Small But Wonderful

2009-11-01T14:35:00Z

ASP.NET 4.0 includes a new member on the HttpResponse class - RedirectPermanent. Baked in support for issuing HTTP 301's? Yay!

Funtastic: disk2vhd

2009-10-30T01:08:00Z

Have you ever gotten your system to a state that you absolutely love - all your apps and utilities loaded, Visual Studio instaled, etc. - and find that you need to load Potentially Deadly Beta Software v0.8? Have you ever cringed at the thought that loading such software runs the risk of screwing up hours of work getting your machine configured just right?

Enter disk2vhd. Those crazy SysInternals guys, they are wicked smart. This free (!) utility can convert the drive that you are currently booted in to into a VHD. Once there, you can do all kinds of fun stuff. Load it up in Hyper-V. Configure Windows 7/2008 R2 VHD boot with it. All sorts of stuff. Load Deadly Beta Software on it.

Just generally go crazy.

http://technet.microsoft.com/en-us/sysinternals/ee656415.aspx

SharePoint 2010 and Kernel Mode Authentication

2009-10-29T23:43:00Z

When IIS 7.0 shipped with Windows Server 2008, one of the many new features included this new doodad called Kernel Mode Authentication. Enabled by default, KMA moved authentication operations performed by IIS out of user mode and into the kernel. This had tremendous performance benefits! Additionally, when KMA was enabled, IIS no longer used the application pool identity for Kerberos ticket decryption - instead, it would use the machine account. This greatly simplified single server installations, as you wouldn't need an SPN configured to perform Kerberos authentication to your web application if your web application used the same name as the machine.

Unfortunately, relying on the machine account for ticket decryption is entirely incompatible with web farms of any kind - SharePoint 2007 included. It's obvious why - SharePoint web applications running in a farm configuration do not use the machine name for their web application, they'll typically use a central DNS entry and host headers on each of the Web Front Ends. As a result, the ticket request from the browser client to Active Directory would pass an SPN that wouldn't have a match of any sort, causing a Kerberos ticket failure on the client. As a result, SharePoint 2007 environment deployed on Windows 2008 had to configure their web applications to use the application pool identity for ticket decryption if Kernel Mode Authentication was to remain enabled.

Due to a variety of factors, SharePoint 2010 will provision web applications with Kernel Mode Authentication disabled by default. This will give you the IIS 6.0 behavior of leveraging application pool identities for ticket decryption, and will generally simplify web application management.

Trivia: Shared Service Providers

2009-10-17T02:24:00Z

Every SSP that is created in a farm is represented to the world by a virtual directory configured beneath the Office Server Web Services web application that's configured on every node within a SharePoint farm.

The Office Server Web Services web application is associated to the OfficeServerApplicationPool. If you popped open IIS Manager, you'd probably note that the OfficeServerApplicationPool executes under the NETWORK SERVICE account. Each SSP in the farm will be represented by a virtual directory configured beneath this web application; the virtual directory is named with the name of the SSP, so if your farm runs an SSP named SharedServices1, looking underneath the Office Server Web Services web application would reveal a virtual directory named SharedServices1, associated to an application pool with the same name. That application pool runs under the identity of the SSP service account it executes for.

The Office Server Web Services web application is bound to port 56737 and 56738. Sound familiar? You configured a half dozen custom-format SPNs (two for each member of your farm) on your SSP service account when you configured your farm for Kerberos authentication. Right?

The Beta Zone

2009-07-22T03:57:00Z

I like things that break. I like new things. In the world of software, new things, also known as beta things, tend to break quite often, which made me and my Windows Home Server backups a little too familiar with each other.

Enter Windows 7 and Boot from VHD.

Now granted, I could've always dual booted, but a dual-boot system is sort of a big commitment. That disk space is gone, and there just isn't an easy way to get it back. With boot from VHD, if I need it, I dump it on my hard drive, if not, I can shuffle it off to larger stores without losing all my setup time. I can get it to a state I like, then copy that off for safe keeping, like after I've loaded Visual Studio 2010 Beta 1 on it, but before I've done something hideous to the OS.

Scott Hanselman has a post with a pretty decent guide that covers the basics of boot from VHD. Read all about it here.

Also, for the record, I never use any fancy Windows 7/Windows 2008 R2 install media tricks to install an OS on a VHD. Download the Windows AIK and be introduced to the joys of ImageX. With ImageX, you can select the Windows install image (from the source media install.wim), and lay the bits down on the VHD without having to run through the full installer. First boot, it's very similar to a sysprep experience.

Windows 7 FTW!

Why User Testing Is So Important

2009-05-09T19:06:00Z

I recently placed an order with a company for something my wife and I had been discussing quite a bit. We were quite excited to finally order this particular item. I was duly impressed when, about an hour after I placed my order, I actually received an automated phone call from the company informing me that the order had been placed and asking me to confirm my details associated with the order, to prevent the possibility of someone signing me up for this particular service without my knowledge. A nice touch in the age of identity theft.

A week went by, and I had rearranged my entire weekend to be able to accept delivery on Saturday. I waited. And waited. And no one ever showed up. Frustrated, I went downstairs to the home office to pull out the order confirmation email that I had recieved earlier in the week, so I could dig out the customer service phone number and the order number.

The email, with a subject line of "Order Confirmation for Order #1234567", surprised me a bit. The top contained the standard order confirmation stuff - a restatement of the items I had ordered, the subtotal, tax, expected delivery date, etc. At the bottom of the email, however, I was surprised to find the following paragraph:

"We're sorry, but due to an error while processing your credit card, your order cannot be fulfilled at this time. If you do not contact us within 10 days, we will cancel this order."

This sentence was actually crammed between a sentence thanking me for my order, and a block of legalese.

I was flabergasted.

After a brief chat with their customer service folks, it turns out that I must have mistyped my credit card number. This raises three issues, for me:

People have been doing realtime processing and validation of credit cards for twenty years or more. It's a commodity skill. Why didn't the user interface catch that mistake? Even something as simple as a mod-10 check would have found this particular error.
Why would the email not be titled something such as "Order Not Processed - Please Contact Us" or something similar? Why make the customer dig through the response to determine their order status, when the initial subject indicates that all is well?
Given the companies obvious infrastructure for placing order-driven outbound calls (such as the one I received verifying that it was actually me that placed the order) why didn't they leverage that same system to inform me of my mistake?

The issue here is that they obviously never user tested their confirmation emails through all the possible use case scenarios. Granted, I should have read the email end to end, but it also should have been much more obvious that there was something that was going to prevent the succesfuly completion of my order. It shouldn't be this difficult to give someone money.

So, the lesson here is to user test as much as you possibly can - especially those elements that require the user to perform some action. And especially when it might interfere with your ability to accept money from someone.

My Favorite Interview Question

2009-05-09T09:22:00Z

I've given plenty of interviews in my day. Almost all of them have been for highly technical positions; typically software development. Of all the interview questions I've ever asked, this one is my absolute favorite:

"Write a function that can take the derivative of a single variable polynomial of any order. Perform this operation using the smallest number of operations possible."

Now, normally the people freak - and that's okay. They hear "derivative" and start flailing around, their brain short circuiting from the stress of the interview situation, until they aren't entirely certain if a derivative is a mathematical construct or the pet name of a certain species of spotted owl. I would typically continue on to give them an example of a taking a derivative, just to refresh their memory. I also tell them that the function can take whatever input they feel is neccessary. I then give them 15 minutes to work on this.

No one has ever come close to answering the question right. Well, one guy did, and I hired him. Of the rest of the people that I hired, they all got close - but here's the trick. The question wasn't about finding the right answer. The question was about finding out how your brain worked by a) stressing you and b) requiring you to think logically under that stress.

Anyone care to take a stab at it? Brownie points for the first person to get it right. :)

You Never Know What You Don't

2009-05-08T04:00:00Z

I was once asked by a colleage at a previous employer what skills would be required to implement and maintain a piece of software we sold. After thinking about this a bit, I wrote back with three points:

Software Development Experience
Motivation
Interest

The answer I received in reply isn't fit to print.

A well planned project includes a list of tasks that need to be accomplished in a given order, and sets expectations as to the timeframe those tasks should require. It's an artform or sorts. Some tasks come in quicker than the estimate, some longer, but the goal of project management is to manage the margins. Basically, to keep tabs on where everything is and where everything is trending so that you can adjust your long term plans before you get so deep into it you'll never ship.

In this particular case, this software package required both infrastructure/operational elements and development elements. Infrastruture and operations were pretty much the same as most apps - database servers, network connectivity, load balancers, etc. The development elements were also pretty much the same for any customization effort - knowledge of the API would of course be helpful, but isn't strictly required. You'll pick things up as you prepare for the project, and the timeline assumes someone is new to the product.

The answer this person wanted was that we needed people with experience deploying, customizing, and supporting the product. The challenge was, the client in question had never deployed, customized, or supported the product. The only way the client was going to get those skills was by doing, with someone who had done it before walking behind everyone, prodding them along and keeping them inside the margins.

That's just how products are adopted. Sometimes you get an opportunity to send a bunch of people to a training class, and if you can swing it, that's great - a definite help. But training classes and the real world seldom intersect in a way that improves delivery - if anything, they serve to highlight to the person the fundamentals of the product they are deploying or customizing. You know know what you don't know, and know what questions to ask. This is also the goal of project preperation, where you plan out activities in detail and send people off with manuals and documentation in the bags. In many instances, training represents a different sort of documentation delivery.

And for the record, I'm not knocking formal training. Consider this - in college, you bought this big expensive text book. If you were dilligent, you could have read the text book end to end, taken the exam, and passed. You could have taught yourself. Or, you could take your textbook and attend class, where your teacher explains the things in the text book to you, and shares his or her own personal experiences. Now product training and documentation may not have the wide gap in knowledge adoption that say, a calculus class and a calculus text book might have, but the same thing goes.

Self-Policing of Content

2009-01-28T06:03:00Z

One of the most common questions I hear from Human Resources folks surounds content management of My Sites and Team Sites. Specifically, managing innapropriate content. There are lots of things in SharePoint that can help restrict people from doing things - security, workflow, blocked file types, and more - but it becomes a bit unclear when it comes time to restrict people from placing innapropriate content in the environment. Take images for example. It would be foolhardy to make, say JPEGs a blocked file type, but filling up your content databases with pictures of peoples weddings is something you really don't want to see happen. What to do?

My favorite technique for combating these types of issues is to implement a global feedback link. These links serve as a listening system for innapropriate content - implemented as a delegate control, they can be activated at the web application level, and statically linked to a document library where additional details regarding the policy violation can be collected. It's a great way of using SharePoint to manage SharePoint, is pretty simple to implement, and leverages the collective power of your audience to self manage policy violations.

I hang my head, and I feel shame.

2008-12-20T07:32:00Z

Wow. My last post was when? Scott Hanselman posts 18 times per day, while in Africa, and I haven't posted since August?

I hang my head, and I feel shame.

Well, in my own defense, I have spent a great deal of time over the last four months looking at the inside of airports. Ever been to Denver International? It's gorgeous. Kansas City International? Exceptionally functional. Not pretty, but it works, and it works well.

Continuing my, series, here are a few more myths about SharePoint I'd like to burn down.

#3 You shouldn't have a content database larger than 50GB

People have misinterpreted a lot of guidance on this topic over the years. Implying that SharePoint shouldn't have a database larger than X size implies that there is some pre-determined upper bound to the size of a SQL Server database, which just isn't so. A SharePoint content database can scale to whatever size your SQL Server infrastructure can support, which means that if you've got some crazy 64 processor SQL Server with 512GB of RAM, you can have yourself a big ole' honkin' content database.

Now, before everyone starts building out huge SQL Server infrastructures, let's take a close look at that SLA you agreed to. You know, the one that says you'll be able to restore the system within four hours of an outage? Now, go talk to your storage management people. What do they say about how they are backing up your databases? Mirror SAN? Same building? Going to tape?

The deal with content database size is all about the rapidity with which you can recover the database. Personally, I'm nothing but happy if I can keep the database to 50GB or less. Normally, this is very achievable with a sufficiently developed site taxonomy - but more on that later.

More to come - and this time, you won't have to wait four months. I hope. :)

Dispelling SharePoint Myths

2008-08-01T17:45:00Z

I've heard numerous myths about SharePoint. Some were scary. Others, funny. Regardless, for your reading pleasure, I'm going to spend the next few posts talking about some of my favorites, with an aim to dispell them.

#1 SharePoint Is More Than An ASP.NET Application

SharePoint is a wonderful product. But - and this is important - SharePoint is an ASP.NET application. Repeat after me. SharePoint is an ASP.NET application. Keep repeating that until you believe it.

I can't tell you how many times I'm asked if there is some "secret sauce" involved in turning an IIS web application into a SharePoint web application. There isn't. Let me break it down for you.

In SharePoint 2003, when SharePoint extended an IIS web application, it registered a custom ISAPI filter to intercept page request handling. This, in turn, would be handed to the ASP.NET page processing pipeline for further manipulation before finally returning the requested page or error to the client. The ISAPI extension was a bit of magic, but didn't do anything that a normal ISAPI extension couldn't do. There wasn't anything special about it, other than the fact that it was written for you. That was it.

The ISAPI extension did pose some problems, though. The ISAPI extension had to be the first ISAPI extension in the list of ISAPI extensions executed for a given web application. Getting that ISAPI extension out of order could cause problems if other, "downstream" ISAPI extensions processed things funny. As a result, for SharePoint 2007 the ISAPI extension was removed and a wildcard application map was added that mapped all requests to IIS for a SharePoint extended web application to the ASP.NET page processing pipeline.

Normally, only files that end in a specific extension are mapped to the aspnet_isapi DLL (and thus the ASP.NET page processing pipeline). Things like .aspx, .config files, etc. For a SharePoint extended virtual server, a wildcard mapping is added that maps everything to the ASP.NET engine. In the web.config file for a SharePoint site, two HTTP handlers are added to the ASP.NET engine that enable SharePoint to process the request like a SharePoint request. These two HTTP modules are the SPRequest module and PublishingHttpModule.

Take a look at the web.config file for a SharePoint site. In the HttpModules section, you'll see two entries that look like this:

These two modules obviate the need for the ISAPI extension. This is what enables SharePoint to serve content that isn't stored on the filesystem, like documents, images, pages, etc. These modules intercept the ASP.NET page request and retrieve that data from the SharePoint content database(s) associated with the web application, instead of letting IIS do the heavy lifting by grabbing it from the filesystem.

So, when SharePoint "extends" an IIS web application, what it's really doing is adding a wildcard mapping to the standard ASP.NET processing DLL. All requests get handed to aspnet_isapi.dll, the same DLL that ships with ASP.NET proper and the same DLL that gets a request for one of your normal ASPX pages. SharePoint then drops a web.config file in the IIS web sites directory that adds a few HTTP modules to process the request further, retrieving things from the database, and serving SharePoint content. That's it. That's all there is. Tada. You're done.

#2 You Can't (Or It's Hard To) Host Non-SharePoint Sites Beneath A SharePoint Web Application

See item #1. SharePoint is an ASP.NET application. The same rules apply to all ASP.NET applications. Many people encounter challenges trying to put their own, non-SharePoint ASP.NET application in a virtual directory beneath a SharePoint site. It's broken, you get funny errors, and the like. What's causing this?

Normally, it's just a byproduct of the way web.config files work. Web.config files inherit from each other. So, if you have a SharePoint web application, you create a virtual directory beneath that web application, drop your web.config and such for your custom ASP.NET application in there, what's happening is your web.config file for your custom app is inheriting all the settings specified in the parent web application. Since your app probably doesn't know about many of the SharePoint DLL's, you get a bunch of funny errors because your ASP.NET application is trying to load SharePoint's HTTP modules, configuration sections, and more. The answer? Judicious use of <clear/> statements.

In ASP.NET, all web.config files inherit from something (save the top config file, machine.config). So, when you create a new web application and put your site there, it works, because it's inheriting from the systems machine.config, and you are used to that. Even if you didn't know that that is what it was doing, your app behaves as you'd expect it to because it's grabbing config values that you expect it to have. Ever wonder why you can just type <system.web> in your config file, and ASP.NET knows what to do with that? Believe it or not, there isn't any special processing that the ASP.NET engine does to "know" about a <system.web> config section in a web.config file. The configuration handler for a <system.web> section is defined in the machine.config file on the system. This is the same syntax and approach that you would use to declare your own custom configuration section, and the same syntax and approach that SharePoint uses to defines its custom sections (i.e. the SafeControl section). For more information on custom configuration sections, see my MSDN article "Configure This: Parameterize Your Apps Using XML Configuration In The .NET Framework 2.0".

Back to your ASP.NET application that you want to live beneath a SharePoint site. Your app is inheriting a bunch of settings that doesn't make sense for it - things like SafeControl sections, authentication and authrorization sections, site map providers, connection strings, and more. The answer? Take a look at the parent SharePoint web.config, and use <clear/> and <remove/> statements in your web.config to get rid of the settings that you don't need or want. Tada.

A note of caution: if you <clear/>, for example, the connection strings section, know that you are not only clearing the connections strings that SharePoint defined, but you are also clearing the connection strings that the machine.config file defined. The connection strings section has inherited settings all the way to the top, and when you clear it, you clear all inherited configuration values. This might not matter to you, but it's something to watch.

That's it for now. I'll post more later, as I've got myself a ton of these!

ICallbackEventHandler

2008-06-06T22:45:00Z

How to use ICallbackEventHandler to write AJAX controls without AJAX.NET. Walkthough of a People Picker look-a-like control....(read more)