Sunday, August 31, 2008
#
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…
Wednesday, August 27, 2008
#
Issue Summary:
When a user in any site collection attempts to add a CQWP to a page, and uses that webpart to render items from list type “Announcements” or “Issues”, the resulting list items are displayed, but produce a “List Does Not Exist” error when clicked. To understand why this happens, we need to better understand how the webpart is processing this request. If you look carefully, you will notice that rather than the webpart providing a direct link to each item, as would be expected, instead it provides a link to a _layouts page which hangs off the <Root> Site Collection for that Web Application, called “CopyUtil.aspx”. Further analysis indicates that this page receives the querystring parameters provided by the CQWP and does some processing in order to locate the proper site, web, list, and item, after which it forwards the user to that item’s display form. As part of its processing, it does some security checks to ensure that the requesting user has what it known as “Limited Access”, which provides view access to specific list libraries such as the mater page and layouts gallery. The reason it does this is so that it can be sure the user will have the permissions needed to pull any needed master pages or layouts, etc. needed to view the target item. Interestingly enough, it doesn’t perform these checks against those libraries in the target site, but rather the libraries which exist in the <Root> Site Collection. If the requesting user doesn’t have access to those libraries, the call fails, returning the “List Does Not Exist” error as described above. Not so helpful, but this is how it works…
Forensic Analysis:
As the problem was isolatable to the production environment, and could not be replicated in any development or integration environments, we did some comparisons the production environments to see if we could reproduce it. The results of those tests, using testing site collections setup for this purpose indicated that the effect could not be reproduced. We consulted the database folks and had them recheck and compare the database permissions between those environments to ensure the proper application pool accounts had the needed content db access, and that the permissions were equivalent between the two environments. Everything checked out, and no differences could be identified. We then set our focus on the permissions of the root site collection itself, and discovered that if a specific test user was granted viewer rights to the root site collection, the effect was eliminated. After performing a detailed group by group analysis of the root site collection security for all environments, we were able to locate the primary causal discrepancy. The issue was related to the membership of an OOTB delivered site group called “Style Resource Users”. This is a limited access group that ships with the site collection. When a new site is created, this group comes with “All NT Authenticated Users”, however this can be optionally removed to further secure (or in our case, break) the environment. Based on our assessment, it appears whoever setup the root site collections elected to futrhur secure these sites in this fashion by removing the group.
Resolution:
As a single unit test, we were able to temporarily add NT Auth Users to the group and verify that:
A) The Problem was resolved
B) The user still received an “Access Denied” when visiting the root site collection directly
Recommendation:
It is recommended that the membership of the “Style Resource Users” group be audited in all root site collections in all web application in all production environments, to ensure that NT Auth Users is present, and all other user accounts or group have been removed. After this change, which is in alignment with the design and the automation, the above error should no longer be present.
Please let me know if there are any questions. Thanks!
Thursday, August 21, 2008
#
With the whirlwind of activity surrounding the recent release of our new book, Office SharePoint Server 2007 Best Practices, as well as the time it took to write it, I haven't been able to blog much lately. But now that the book is out, and I have my presentations prepared to the upcoming 1st Annual SharePoint Best Practices Conference, I'm ready to get back to blogging and contributing to the community online.
I'd like to thank all my friends at Mindsharp, Microsoft, and Chevron for all your support over the past 2 years. Working within the SharePoint community has and continues to be very rewarding. Having been approached recently by my friends from Microsoft regarding my interest in becoming a SharePoint MVP, I wanted to craft this post as a means of providing a brief rundown of what all I have been up too, and what I have planned for the remainder of the year.
In the past two years, I have been involved in the following major projects and presentations:
- Technical Development Lead, SharePoint Service, Chevron (One of the largest Office SharePoint Server 2007 deployments)
- Contributing Author, Office SharePoint Server 2007 Best Practices, Microsoft Press (Curry & English, 2008)
- Houston SharePoint Users Group, Chevron Project Lessons Learned (Q&A Panel)
- Mindsharp Blogs (when and where I could from a IP standpoint and while writing the book with Ben and Bill)
My planned community involvement for the remainder of the year (so far):
- Presenting 3 Sessions at the 1st Annual SharePoint Best Practices Conference in Washington DC
o Developing an Information Architecture
o Optimizing Information Security (IT Pro)
o Team Development for Delivering Complex SharePoint Projects
- In the scheduling stage to deliver the last of the above three presentations for the following user groups:
o Chevron SharePoint Users Community
o Phoenix SharePoint Users Group
o Houston SharePoint Users Group
I’m also in the process of looking for some opportunities and contacts regarding additional opportunities at conferences, radio shows, podcasts, and publications. My focus through the end of the year will be on team development for SharePoint, with a specific focus on how a team can leverage MSF, ALM, and VSTS to lay the foundation needed for delivering successful project and product/service outcomes.
If anyone has any ideas, thoughts, or feedback, please feel free to reach out to me via email: mark@solutionsmark.com
Friday, March 14, 2008
#
Let's assume that you have a medium sized SharePoint Server 2007 farm with two WFEs behind an F5 “BIG IP” LTM.
The host name for each configured web application resolves to the Virtual IP (VIP) on the F5, which in turn performs it's sophisticated load balancing function and routes the traffic to one of the two designated WFEs for processing.
Naturally, you would visited F5's web site and followed this deployment guide when creating your configuration profile and HTTP pool. And would assume that all is well, right? Well, mostly, but maybe not...
During testing, you begin to notice that some requests are getting dumped on the HTTP response, which is causing the browser to provide a 404 error. After some investigation, you realize that this abnormality only occurs under very specific, yet obscure, conditions. In my case, I had a custom SharePoint feature which included a WebContol which was loading as a CustomAction in the document library list ViewToolbar. This WebControl performed some configuration settings adjustments similar to those described in my post entitled “Using a Delegate Control Feature to Reconfigure OOTB Site Definitions“. Upon completing the execution of the changes included in my class, I tagged the list to avoid future re-execution of that passage, and performed a page redirect to reload the page so the user would see the new settings.
This is where things got very interesting...
It turns out that I only had the browser 404 when the request traffic was flowing through the F5 LTM. If I set a local host entry on the client, my WebControl would do it's work, reload the page, and everything was just fine. Even more perplexing was the fact that with the custom feature de-activated, initial list library loads flowing through the F5 occurred without error as well. Very strange indeed...
So, a few fine colleagues and I began the lengthy process of sniffing the traffic using Net Mon on both the client and the server in order to find out exactly what was happening. What we found was both slightly confusing, and very unexpected. To set this up, let's go back to the F5 Deployment guide I referenced earlier. In section 1-8, the guide lays out the steps for creating the HTTP pool. Step 6 states:
6. In the Settings section, check the Custom box for Redirect Rewrite, and from the Redirect Rewrite list, select Matching.
Well, it turns out that Redirect Rewrite is an interesting little feature indeed. SOL9612 on the F5 support site (requires registration) describes the specifics of this setting, which is so quickly passed over in the deployment guide it isn't even funny.
Basically, when a requested URI does not include a trailing slash (a forward slash, such as /, at the end of the URI), some web servers generate a courtesy redirect. That sounds like an OK thing, right? Sure, but guess what, and this is the “Gottcha“...
In BIG-IP LTM version 9.x you can configure an HTTP profile to rewrite URLs so that redirects from an HTTP server specify the HTTPS protocol.
Whoa, what just a minute! That doesn't even sound like the same feature. how did we go from slashes to protocol redirection. Hmmmm.... As it turns out, the Redirect Rewrite options available are as follows:
-
Choose All to rewrite any HTTP 301, 302, 303, 305, or 307 redirects to HTTPS
-
Choose Matching to rewrite redirects when the path and query URI components of the request and the redirect are identical (except for the trailing slash)
-
Choose Node to rewrite redirects when the redirect URI contains a node IP address instead of a host name, and you want the system to change it to the virtual server address
So, basically, if we follow the settings recommendations included within the deployment guide referenced above, we inadvertently setup the F5 in such a way that any redirect with a matching referrer, such as the one I had placed in my WebControl, will cause the HTTP response coming from the WFE to be rewritten by the F5 as an HTTPS response... as a courtesy, of course :)
Ok, back to the deployment guide one more time... Above the step by step in section 1-8, there is a short disclaimer as well as a note written in italics. These state the following:
Important:
If you are using the WebAccelerator module, we recommend you configure an HTTP profile based off of the default HTTP profile, and only change the Redirect Rewrite option to Match. Any other settings in this case are optional.
-and-
The following procedure shows one way to optimize the Microsoft SharePoint 2007 configuration that has been tested in real-world scenarios by F5, and shown to give the greatest improvement. These procedures and the specific values given in some steps should be used as guidelines, modify them as applicable to your configuration.
So, what the fine print is really saying here is:
- If we are using the WebAccelerator module, we should NOT set the Redirect Rewrite options to Matching, but rather set it to Match, which interestingly enough is not a listed option in the above referenced support article on the F5 support site, nor (as is the case with all the options for this setting) is it listed or explained anywhere in the deployment guide.
- These settings, including step 6, and their specific recommended values should be used (only) as guidelines, and may require modification in your environment.
Well, in the case of a SharePoint implementation, while I can see some value in the whole trailing slash detection thing, I can't see many cases where I would want HTTP traffic being converted into HTTPS traffic, at least not in this case. Upon changing the Redirect Rewrite setting to None, everything works fine again and the browser errors disappear (magic!).
On a side note, I think it is worth mentioning that if you are doing development of custom components for your SharePoint implementation, and you plan on using an F5 LTM, you might want to avoid performing redirects, especially in cases where you are simply trying to reload the current page for the user. Although, hopefully you find this post first, and simply adjust the settings to resolve the issue entirely.
-Mark
Please feel free to send any thoughts, comments, or questions to mark@solutionsmark.com