Serge van den Oever [Macaw]

We sing a song when we are editing definitions. Its about being in a pit, it goes,

"Just keep digging, just keep digging, just keep digging, digging, digging".

The thing to keep in mind is that some modifications to the site def after provisioning a site will cause changes to all site. For example, changing the aspx's will cause changes to all unghosted sites, but changing which lists are provisioned and which web parts on the page (in the onet.xml) will not reflect on sites already created.

I've been doing a lot of work the past few months with sitedefs so I'll post a blog with some more details about changing things in place, aspx files, etc. which might help explain things more.

We do loads of changes to the sitedefs and we create our own, but we are also depending on the fact we can change things AFTER we create instances of the sitedefs. This is one of the big reasons to use sitedefs in the first place. Ofcourse we prevent unghosting of those sitedefs.

The thing is that Microsoft decides in all its wisdom that they consider this as "unsupported".

Whats nice is the difference in tone between the KB article and the three documents they produced on how to customize your portal, its goes from you don't want to do that because of service packs, to don't do that at all or support is withdrawn.

And just what do they mean by unsupported, is it that the changes you have made are unsupported? Or now you have changed the portal all support is withdrawn completely, your on your own, sorry about the misleading docs, but tough?

We have made absolutely monstrous changes to sharepoint, editing MySite templates, SPS template (which considering the home page can ONLY use this has to be changed to brand it), new area templates, new WEBTEMP files, changes to default areas, changes to css (because of the poor implementation of css I could not just use a seperate overriding one), ows.js changes (again somethings cant be done in custom_ows.js), new lists, I even applied a changeable skin to a custom web parts, you know when they tell you don't mess with the render method, well yup I had to do that.

We did the same to Plumtree, but at least they supported the core product and worked with us on our changes. I want more info from MS about what they mean by "unsupported" and if its your on your own with your customisations but sure we will help with the core product, well fine I expected that. but if they expect people to put in a product that essentially cannot be branded I can see that market share dissappearing.

I even miss Plumtree now.

What Microsoft says in the above quote is that making changes to a template AFTER instantiating a site based on this template is not supported. And that is what we all want: be able to change something to the template, and all sites created from this template do get these changes...

Time for Microsoft to give a reaction on this;-)

See my blog comments.

This comment is published on the weblog of Cornelius:

Hi Cornelius,

Microsoft is talking about "Supported and unsupported scenarios", and under unsupported scenarios they make the following statement: "When you work with custom site definitions or custom area definitions, the following scenarios are not supported:... You modify a custom site definition or a custom area definition after you deploy the custom site definition or the custom area definition.".

They are not differentiating between unsupported by the software, or unsupported by Microsoft support.

It is not that we are just playing around with site definitions and are messing things up. I'm talking about 20+ team development on huge SharePoint implementations. Ofcourse we test things out, not on just a virtual PC, on multiple test servers. It is not about expecting "free support".

What is it about: the model of being able to extend and modify instantiated sites over time is key to a large implementation. For example the MySite definition. Assume the implementation of an intranet for 30.000 customers, each having their own MySite. So each customer has an instantiation of the MySite site definition. It is impossible to come up with the perfect MySite definition upfront. And I can tell you: the default Microsoft implementation is NOT the implementation to go forward with for years to come. So over time new functionality is needed, based on user comments and user statistics. It is impossible to sell to your customers that you need a huge team of people to do FrontPage customizations on 30.000 sites, in the mean time ghosting all the modified MySite pages. The other approach left: modifications through code. First of all we have the ghosting issue again, second issue: we now have a site definition (which we may not modify), and after instantiating we have to do modifications through code, that should be kickstarted directly after site creation. This approach is way to complex and defeats the power of the site definition system. This is just one example, there are many more examples in a real life SharePoint implementation.

Serge,

I'm not saying that Microsoft's new stance is not a problem. In this industry, we all need to addapt to change and this just happens to be a change that hurts a whole lot. All of your points are completely valid.

What I am trying to point out though is that they still left the door open on API changes. Granted using the API to programatically push changes through all sites one at a time is not as quick and convenient as making a definition change, but we still have an avenue left for replication changes.

http://www.dtdn.com/blog/2005/05/microsoft-support-scenarios-for-custom_24.htm

Thanks
C
"You were supposed to destroy the Sith, not join them!" - Obi-Wan Kenobi

so i can't change the site definition in the home page?

By now, the commotion surrounding KB 898631 has died down somewhat, after an inital explosion of commentary. ...

By now, the commotion surrounding KB 898631 has died down somewhat, after an inital explosion of commentary. ...

cvdTry Look here!!! it's greatggz

fyt

kczit's really helped meog

<a href= http://www.angelfire.com/blog/xaloce >a cinderella story soundtrack song list</a> <a href= http://www.angelfire.com/planet/byviba >a4 co uk</a> <a href= http://www.angelfire.com/planet/nehepa >a guide to open source software for australian</a> <a href= http://www.angelfire.com/planet/guvijy >aarp medigap coverage</a> <a href= http://www.angelfire.com/funky/vodydi >a defence of poetry shelley</a>

<a href= spiritez.com ></a>

<a href= membres.lycos.fr/dertull >zx10r graphics</a>