다음을 통해 공유

Supportable Customizations: Don't Panic

  • 아티클

I’ve been at a lot of conferences in the past few months, and the question I was asked most often had to have been around what we support and don’t support when it comes to site and portal customizations, modifcations to site definitions, and so on.  The thing that spawned these questions is this article on TechNet.  In a nutshell, it suggests in pretty strong words that if you modify our out-of-the-box site definitions, we won’t support them anymore, and that if you create new site definitions, we won’t support changes to them once you’ve actually created even one site based on them.

Don’t panic.  You’re not in trouble.  You can still customize site definitions.  Allow me to explain…

1. What We Mean By “Support”

When we say something is supported, we mean a number of things, including (a) it’s our code, so (b) we’ve tested it an know how it’s supposed to behave, and (c) when you’re having trouble making it behave as designed, we’ll help you fix it, and (d) it conforms to our expectations as to what has been placed where so we can automate changes to it (very important when applying service packs).

If you modify a site definition, then it becomes your code, at least in part.  We won’t know what you did, and we won’t know how your changes will affect performance, stability, or security.  But that doesn’t mean that you’re all alone if you choose to customize a site, an area, or a site definition.

2. You Can Still Put Yourself Back Into a Supportable State At Will

If you encounter a problem that will require support, and you’ve customized WSS or SPS into an unsupportable state, and you can roll back your changes, and the problem is still there — then we’ll work with you to fix it.  What that means is that you should take note of the changes and customizations you make so you can remove and reapply them at will.  It’s more work, but it’s worth it (especially if we’d otherwise be overwriting your changes when we install a service pack).

And, of course, if the problem goes away when you roll back your changes, then the problem is with your changes.  But even then, you’re not out in the cold — you still have options…

3. Actually, Microsoft Has a Support Vehicle for Custom Code

Product Support Services and/or standard Premier Support are designed to support our code.  The aforementioned statement on supportability pertains to what they’ll do for you because they know what our products do and how to make them behave the way they were designed to behave.  But they’re not the only support vehicle Microsoft offers.

We also have Premier Support for Developers (PSFD).  They support your code when you develop with our APIs, tools, or platforms.  They charge by the hour, not by the incident, but they’ll support anything you write, customize, etc.  PSFD will work with you on custom site definitions, Web Parts, and just about everything else.

So, for maximum supportability when you need to customize your sites, I’d urge you to (a) keep track of your changes and plan to be able to remove and reapply them, (b) work out a PSFD agreement (get in touch with your Microsoft office for details).

And above all, don’t panic.

Comments

  • Anonymous
    August 06, 2005
    Your description of rolling back changes seems to assume people are modifying the stock SharePoint templates, which is highly discouraged. Most developers building their own site definitions are working off of their own templates, not the stock site definitions... there isn't anything to "roll back" to.

    Can you describe an example where someone developing a custom site definition (not tweaking a stock definition) would be supported without going the PSFD (or MCS) route?

  • Anonymous
    August 07, 2005
    Jason, a brand new site definition is, by definition (no pun intended), your code, not ours.

    Like a smart client written with WinForms, a custom Web app written with ASP.NET, or a site defintion written with XML (and much more), it's custom code, and the correct vehicle for that from MS is PSFD (for reactive, problem/solution work) or MCS (for proactive, design/advice/proof-of-concept work).

  • Anonymous
    August 10, 2005
    The other side of this is the stance that once a site is deployed based on a site definition, it is not supported to change that site definition even if it's "ours". From the way I read the KB article, there is no grey area here - even minor changes are unsupported.

    Do you have any comments as far as options in this situation?

  • Anonymous
    September 12, 2005
    Mike Fitzmaurice has provided a very nice explanation about the boundaries for Microsoft Support. A very...

  • Anonymous
    April 20, 2008
    PingBack from http://stocks-options-trading.info/trading-strategy/?p=870

  • Anonymous
    January 20, 2009
    PingBack from http://www.hilpers.com/1080942-aufbau-einer-sps-topologie

  • Anonymous
    June 09, 2009
    PingBack from http://insomniacuresite.info/story.php?id=4154