On Site Definitions, or How I Learned to Stop Worrying and Love KB 898631

By now, the commotion surrounding KB 898631 has died down somewhat, after an inital explosion of commentary. Serge's first post seemed to be the initial spark that lit the tinder, and I suspect that his was but the most immediately recognizable voice and certainly the loudest, where many other voices and opinions remain OTW (off-the-web) and therefore unnoticed. It's undeniably a topic that has made a lot of waves, both outside and inside Microsoft walls.

I'll go ahead and open myself up for criticism, I suppose, by noting that I drafted the initial "informal" version of these rules, which then became the basis for the KB article. The "rules" themselves have almost all been in place as part of the SDK in various places for quite a while but have been more or less A) unnoticed or B) ignored. Serge's second post on the topic includes a few lines from an email I wrote, which essentially says the same thing:

"The statement that appears to be making the most waves on Serge's blog -- "You modify a custom site definition or a custom area definition after you deploy the custom site definition or the custom area definition" -- was already in place in the SDK (https://msdn.microsoft.com/library/en-us/spptsdk/html/tsovGuidelinesCustomTemplates_SV01018815.asp?frame=true) before this KB article was published; this KB article was, more or less, a reminder and summary of the "rules" that had already been defined in various places throughout the SDK."

So, a couple of things to point out, here. First, although these things were already extant in the SDK, they were NOT well-placed, well-organized, or in any way easy to comprehend in a unified way. The mention of site definition rules were scattered throughout the SDK in a number of different places -- the one above being just one of several. Additionally, when discussing site definitions, the SDK previously used language -- which we've since changed -- that was simply not forceful enough (e.g., using the term "recommendations" rather than "requirements"). The purpose of the SDK language changes and the article above was to bring all of the site definition "Rules and Regulations" into a simple, easy-to-understand article that would lay down the facts once and for all (or...at least, for the time being). 

Because we wanted this to be the "official" statement on site definition rules, we did what good Microsoft employees do; we argued about it -- sometimes loudly :) -- amongst ourselves. Then, we got final word buyoff from the product group folks who are ultimately responsible for implementing these things. It's fair to say that there were very strong and vocal arguments about nearly all of these items, but particularly about the item above, "changing a site or area definition after it has been deployed." Lots and lots of people love being able to make a change to a central site definition and have that change automatically populated throughout any sites that have been created using that definition. No doubt, that's a cool thing.

Unfortunately, it is not something that the product was designed to do. The folks who wrote and designed this product don't like the idea, and have strong enough concerns about the stability of the product when used in such a way that they've been willing to continue to tell us that it is unsupported even in the face of fairly strong external *and* internal pressures. We decided that we'd rather have the SharePoint community upset about the support policy itself than have folks in the SharePoint community find themselves in unsupported scenarios or with unexpected and potentially unsupported problems precisely because Microsoft hadn't done a good enough job getting out the message about supportability where site and/or area definitions are concerned.

All that being the case, what some other of my colleagues and MVPs have said is true; there remain supported ways to make changes to a wide number of sites in a SharePoint deployment -- the object model/API being the foremost among them. Is this a perfect answer? Of course not! Making a global change by modifying a line or two in the ONET.XML file sure is easier than writing 100 lines of OM/API code to do the same thing. Anyone who has ever tried to do something as conceptually simple as copy a list from one site to another with the OM/API knows that simplicity is in the eye of...well, no one. But we are assured that if any problems occur when running our OM/API code, it will be 100% supportable -- and that, Martha would say, is a good thing.

Here's hoping the situation improves in future versions of the product. :)

-R

Comments

• Anonymous
  June 06, 2005
  Ryan has an excellent post on the infamous 898631 KB Article, worth a read, and worth noting that this...

• Anonymous
  January 25, 2007
  The comment has been removed

• Anonymous
  January 27, 2007
  The comment has been removed

• Anonymous
  January 27, 2007
  The comment has been removed

• Anonymous
  January 31, 2007
  Superb! (I wrote something else and then I read below that I aint supposed ter. So I deleted it.)

• Anonymous
  March 14, 2007
  Du musst ein Fachmann sein - wirklich guter Aufstellungsort, den du hast!

• Anonymous
  March 18, 2007
  luogo grande:) nessun osservazioni!

• Anonymous
  March 19, 2007
  Great site! Good luck to it's owner!