This post keys off an earlier post, entitled Using a Delegate Control Feature to Reconfigure OOTB Site Definitions (aka, The AdditionalPageHead / PropertyBag Trick) , where I discussed the use of delegate controls for the purpose of performing on-the-fly rolling configuration changes to sites over time. In that post, I was specifically referring to the use of delegate controls within the context of a specific site type or template, where the delegate control feature was stapled to that specific template. Since then, I have expanded my use of delegate controls to include changes that need to be made across an entire farm. Along the way, I ran into the following issue:
Issue Summary
When creating a meeting workspace from a new calendar event, the user is forwarded to a page where they pick the template for the new workspace. As it turns out, the new site they are creating has already been created as an “Un- template-ed Site”, which is basically a site which uses the “STS” WebTemplate with a Configuration value of “-1”. When a site is in this state, the user can use the template picker to select a template, and then the provisioning process will complete with the selected type/template site having been created.
The problem was, in my case, the user was getting an access denied error when presented with the templatepicker.aspx page. Even providing them direct access via web app policy resulted in the selected template returning a variation on “this site is already template, in order to re-template, please delete the site and start over”.
As it turns out, the create a new meeting workspace via a new calendar event scenario actually passes the user’s http request to the un- template-ed site which then forwards the user to the template picker. Prior to the forward, my global delegate control was performing some propertybag tagging of the SPWeb object. For whatever reason, this tagging activity was invalidating the un- template-ed state of the site, and consequently making the system think the site has already been template-ed.
Resolution
In the end, the resolution was to detect the STS#-1 site within the code of my delegate control, and do nothing. Then when the template is selected and processed, and the WebTemplate#Configuration combination is updated, the code contained in the global delegate will fire and the processing will occur as intended.
I’m left wondering when, if and where else I might run into similar issues. Any feedback is much appreciated…