IIS 6.0/7.0

Pages of the past creates sceptics of the present..

Corro'll Driskell — Thu, 22 May 2008 07:27:00 GMT

I have worked with many organizations building web based applications on the SharePoint Technologies platform. We have used tools such as Visual Studio, Front Page and, now, SharePoint Designer. Equally important, I present at a number of SharePoint summits across North America. The presentations delivered range from Designing and Implementation – of the various SharePoint related solutions – to branding – using SharePoint Designer. So, it is safe to say that I have quite a bit of experience in working with customers that are resistant to using SharePoint Designer as a customization (some would say branding) tool.

Many of those customers and attendees moved from the Windows SharePoint Services 2.0 platform to the Windows SharePoint Services 3.0 platform. Not only did they migrate the content, but also the skepticism associated with customizing the pages in a SharePoint environment. Or, they have heard about the nightmares associated with rendering customized - back then called unghosting - pages.Therefore, I decided to blog about the new features provided by the ASP.NET 2.0 framework and how it eliminates the problems experienced in the Windows SharePoint Services 2.0 environment. That is, Windows SharePoint Services 2.0 – due to the limitations of ASP.NET 1.1 – had a difficult time parsing pages from the database. As a result, all user requests - for SharePoint sites - were routed to the SQL Server database. All together, that means that Windows SharePoint Services 2.0 had a difficult time parsing and caching pages on the Web Front End servers.

For all that, Windows SharePoint Services 3.0 integration with ASP.NET 2.0 has been completely redesigned. First, Windows SharePoint Services 3.0 is built on ASP.NET 2.0, which provides significant enhancements over ASP.NET 1.1. Furthermore, the routing infrastructure was improved by removing the ISAPI filter and by adding an HttpModule and an HttpHandler that are registered with ASP.NET using entries in the web.config file.

When a SharePoint Administrator creates a Web Application, the SharePoint Administrator is extending an IIS web site to function as a Web application. Also, Windows SharePoint Services 3.0 adds a wildcard application map to the IIS Metabase file.

That is, all incoming HTTP requests are always processed by the ASP.NET runtime environment and are fully initialized with the ASP.NET context before the HTTP Requests are forwarded to the code that processes all Windows SharePoint Services 3.0 related requests. For the most part, the map routes are due to the wildcard application maps in the IIS Metabase. As a result, all incoming HTTP requests to the ASP.NET runtime- regardless of file types .pdf, .doc, … etc

Overall, the ASP.NET 2.0 framework addressed a number of gaps from the previous – Windows SharePoint Services 2.0 - version of SharePoint Technologies. The most notable gap addressed by the newASP.NET architecture addressed the gap related to how .aspx pages are parsed and compiled. The problem in SharePoint Technologies was that it could not leverage the .aspx page parser used by ASP.NET 1.1. The fact that Windows SharePoint Services 2.0 stored .aspx pages in the SQL Server database presented a problem. ASP.NET 1.1 worked only with pages that reside on the local file system of Web Front End servers. As a result, Windows SharePoint Services could not take advantage of the ASP.NET 1.1 page parser.

Virtual Path Providers were introduced in the ASP.NET 2.0 framework. The new framework allowed developers to write their own custom virtual providers. The value add allowed the SharePoint Product team to write a customized virtual provider – SPVirtualPathProvider - that retrieves .aspx pages from the SQL Server Database. Also, the PageParserFilter affords the SPVirtualPathProvider the capability to control how pages are parsed and compiled.

Once the SPVirtualPathProvider retrieves a .aspx page from the SQL Server database it leverages the ASP.NET 2.0’s .aspx parser. So then, Windows SharePoint Services 3.0 does not fall victim to the performance reduction, with respect to the limited page parsing, experienced by the Windows SharePoint Services 2.0 environment.

Figure 1 Page Rendering Using the SPVirtualPathProvider

In simplier terms, the perceived problems with customizing pages in a SharePoint environment has been addressed from page rendering view point. Despite the negative perception of the ASP.NET 1.1 limitations and how it affected the page rendering in the Windows SharePoint Services 2.0 environment, I think that it is time for the masses to accept the fact that ASP.NET 2.0 addressed those limitations. Whether pages are rendered from the Web Front End file system or from the SQL Server Database, ASP.NET 2.0 ensures that all pages are properly parsed.

That is just my $19.11 worth....

Technorati Tags: SharePoint Designer,FrontPate,SharePoint Technologies,Windows SharePoint Services 2.0,Windows SharePoint Services 3.0,WSS 2.0,WSS 3.0

Speaking @ Hampton Roads SQL Server User Group

Corro'll Driskell — Sun, 11 May 2008 11:26:00 GMT

All,

I am on my way to the Norfolk - Hampton Virginia area. I will speak at the Hampton Roads SQL Server User Group on Thursday, May 15th, 6:30 PM at INFOTEC. I am speaking about SharePoint Designer and InfoPath Form Services support for a number of connection scenarios. It is going to be a great presentation.

Location: (Click her for the directions)

INFOTEC

5501 Greenwich Rd
Virginia Beach, VA 23462-6540

Microsoft Office SharePoint Server Summit FAQ

Corro'll Driskell — Tue, 15 May 2007 07:16:00 GMT

NOTE: All responses for each question is based on collective feedback from ALL Mindsharp Instructors. By no means, were any questions answered exclusively by me.

During the Mindsharp Summits, there are a number of questions that are consistently asked. We, please visit www.mindsharpblogs.com for a list of Mindsharp instructors, decided to provide an answer to those questions asked. We will continue to update this posting. In order to remain up to date, We recommended that you sign up for the RSS feed for Mindsharp Blogs.

http://www.mindsharpblogs.com/MainFeed.aspx

Questions:

1. Can a Web Application (WA) be associated with multiple Shared ServiceProviders (SSP)?

Ans: a Web Application can only be associated with one Shared Service Provider (SSP). That is, a Web Application (WA) has a 1:1 relationship with an Shared Service Provide (SSP).

2. Can you configure multiple Shared Service Providers (SSP) to crawl other Web Applications (WA)?

Ans: Yes. It is possible to configure multiple Shared Service Providers (SSPs) to crawl multiple Web Applications (WA) within and between Farms.

3. Can the user profile write back to Active Directory (AD)?

Ans: Natively, there is not a two way synchronization between Active Directory (AD) and the Profile Store (PS). Currently Out of the Box (OOB), there is only a one way copy, from AD to the PS. But, you could use Microsoft Identity Integration Server (MIIS) or even script it. Yet, many of the postings refer to the one way copy as a synchronization between AD and the PS.

4. What are the implications of associating a Web Application (WA) to another Shared Service Provider (SSP)?

Ans: Most evident and noticeable is that you lose all global search scopes, audiences and related targeting on list items, navigation links/bars, Web parts, etc. Oddly enough, Excel Calculation Server (ECS), Business Data Catalog (BDC), personalization links, and office ‘save as’ integration won’t be affected, UNLESS the Web Application (WA) that was changed is the Web Application (WA) hosting the My Sites.

5. What is the Internal URL section in Alternate Access Mapping (AAM) settings? What is its purpose?

Ans: Alternate Access Mapping (AAM) is used to identify possible internal URLs that could be returned to a user. To avoid returning the incorrect URL and relative links, we would provide an entry that ensures that the appropriate Public URL is returned along with its relative links. For instance, in a load balanced scenario it is possible to return the web1 and web2 URLs. We would ensure the return of a public url by configuring an internal url for both web1 and web2 servers. In configuring the Internal URLs we ensure that the public URLs are returned and, at the same time, ensure that the relative links are reflective of the public URLs. Yet, all alerts and notifications would continue to reflect the default URL.

6. When do we create a new Web Application (WA) versus a Site Collection (SC)?

Ans: Many teach that one Web application for collaboration is a great start. Also, we would leverage the politics of an organization to force the use of more than one WA, i.e. http://portal is tightly controlled whilst http://hogwild has self-service site mgmt enabled for short-term collaboration, with http://hogwild using the broken Dead Site Delete functionality. That is, the business requirements are the drivers for determining the use of a Web Applications versus Site Collections.

7. Is there a limitation on the number of Content Databases (CD)? (We are assuming this is referencing assigning CD to a WA.)

Ans: This is really a SQL Server 2000 SP4/SQL Server 2005 issue, subject to both hardware and software limitations. For the most part, the theoretical limit is very high.

8. Can you define Site Collections (SC) in a Content Database (CD)? (We are identifying the process and options used to create a Site Collections (SC) to a specific Content Data (CD).)

Ans: Ben and Nick posted a blog referencing the creation of Site Collections (SC) in specific Content Datases. Please see posting at: http://sharepointnick.com/blog/Lists/Posts/Post.aspx?ID=17 Also, please register for the Mindsharp Premium area, http://mindsharp.com, and download Ben Curry and Kath Hugh’s whitepaper on the STSADM command line tool.

From the GUI:

1, Take the existing contentDB(s) for that web app OFFLINE (this doesn't actually take the Site Collections offline, but prevents new Site Collections from being created in the database)

2, Then, create a new ConentDB.

3, Create the new Site Collection

4, Take the step 2 content database offline. It will function normally, but refuse NEW site collections

5, Set the original contentDB online

From the command line:

Stsadm.exe –o createsiteinnewdb –url -owneremail -ownerlogin -databasename

will allow you to create a Site Collection in a dedicated content database. Don't forget to take the database offline after creation, or future sites could be created in the new database.

9. When would you recommend using Kerberos?

Ans: If your organization is using the Kerberos authentication method, you can configure MOSS’s Web Application to use the same.

10. Do all the members of the Farm have to be the same bit (32 or 64)?

Ans: No. we recommend that all servers of a similar function be the same. i.e. all WFEs serving a given Web App be the same H/W, S/W. There is not technical limitation here, just a Best Practice.

11. In the event a user is absent, Can someone else approve a task? If so, how does that affect the status of the task?

[BC] if you allowed that permission during creation. You can also assign a task to a group, so that any member of that group can approve. This is a checkbox available during creation. I STRESS the difference in the two options. The first allows anyone in the group to approve, the second option forces all members of the group to approve.

[PPS] using the same options with groups you can also setup that one member from each group must approve before approval is complete. Two from the same group would not be the same thing then as two from different groups.

[CHD] Also, any user that has approval rights on the item can approve or reject the item. Of course, the actual approver/rejector of the item name is listed. The name of the person assigned will only be listed when it is approved/rejected under their identity.

11. Does Workflow point to the document item or to the task item? (This question is referencing the assignment of workflow after it is configured on the Document Library.)

[PPS] Assignment of Workflow is to a document library, list or content type. They normally use a Task list and a History list to implement the workflow. Users typically interact with the workflow by completing tasks in a task list.

12. What is a content type? What is its purpose?

Ans: A content type is a reusable collection of settings you want to apply to a certain category of content. Content types enable you to manage the metadata and behaviors of a document or item type in a centralized, reusable way. Content types, a core concept used throughout the functionality and services offered in Microsoft Windows SharePoint Services 3.0, are designed to help users organize their SharePoint content in a more meaningful way. Content types are independent of file formats.

Microsoft. (2006). Windows SharePoint Server Solution Developer Kit (SDK). Redmond, Washington, USA.

13. What is a column? What is a columns purpose?

Ans: A site column is a reusable column definition, or template, that you can assign to multiple lists across multiple SharePoint sites. Site columns decrease re-work and help you ensure consistency of metadata across sites and lists.

Microsoft. (2006). Windows SharePoint Server Solution Developer Kit (SDK). Redmond, Washington, USA.

14. Why would I consider using a Feature?

Ans: The use of Features ensures consistency and availability. All in all, the deployment via Features makes site customization and upgrades simple. That is, Features eases the distributed deployment of specific functionality.

Microsoft. (2006). Windows SharePoint Server Solution Developer Kit (SDK). Redmond, Washington, USA.

15. Alternate Access Mapping (AAM) is used to identify Public URLs that could provide access to content. To avoid

returning the incorrect URL and relative links, you would provide an entry, Internal URLs, that ensures that the appropriate Public URL is returned along with its relative links.

It is confirmed that there are only five, configurable, (5) Alternate Access Mappings (AAM) zones per Web Applications, each zone represents a Public URL. But, that fact doesn’t limit the number of Internal URLs. The Public Urls/zones are configured when we extend a Web Application. Or, In the event we configure host headers, per Public Url/zone, in IIS. For example, Default: www.mindsharp.info, Intranet: intranet.mindsharp.info, Internet: internet.mindsharp.info, External: external.mindsharp.info and Custom: myportal.mindsharp.info.

The configuration of the Internal Url extends the possibility to support or identify other possible route a user can take to access the content. The Internal URL acts similar to an alias in DNS.

Now, when a user browses to http://www.mindsharp.info, the web request is received by the IIS server. SharePoint will then receive the web request, see that the URL of the request is http://www.mindsharp.info, find that this URL is assigned to the SharePoint web application, and return the content from that web application.

In addition, because the http://www.mindsharp.info URL is assigned to the Internal URL pointing to the http://internet.mindsharp.info Public URL of the Internet zone, SharePoint will also generate links on the pages using the Public URL for that zone –
http://internet.mindsharp.info. This ensures that end users are routed to the proper URL when clicking on links on the page. That is, SharePoint acts similar to reverse proxy servers in that they overwrite the end user's original URL with the URL of the configured Public URLs/zones.

All in all, Alternate Access Mappings' (AAM) configurations, Internal Urls and Public Urls, tells SharePoint how to map web requests to the correct web application and site so that SharePoint can serve the correct content back to the user. It then tells SharePoint what URL the users should be taken to as they interact with SharePoint.

MSDN: http://blogs.msdn.com

NOTE: All responses for each question is based on collective feedback from ALL Mindsharp Instructors. By no means, were any questions answered exclusively by me.

SharePointHandler vs. SPVirtualPathProvider: We have arrived...

Corro'll Driskell — Fri, 06 Apr 2007 20:18:00 GMT

It has been quite some time since my last post. Consequently, I have been busy, since the launch of WSS 3.0/MOSS 2007. On the contrary, I know that I could have posted at any time from any city during my travels. In any case, I have a duty to post my thoughts referencing the WSS 3.0 and MOSS 2007 technologies.

In my posting, titled: Intergration: WSS 2.0/WSS 3.0, ASP.NET 1.1/2.0 and IIS 6.0, I promised to set in motion discussions centered around the intergration of WSS 2.0/WSS 3.0 with IIS 6.0. Incidentally, that discussion is long overdue.

During my presentations, facilitations/training, I have a number of students asking questions about the differences between WSS 2.0/3.0 and SPS 2003/MOSS 2007. Furthermore, many students would like a firm understanding of the page request lifecycles. In any case, all would like to understand, “Behind the Scenes“. I thought long and hard about how to attack this subject in a fashion that would be beneficial to as many as possible.

First of all, I want to discuss the SharePointHandler - WSS 2.0/SPS 2003 - and Virtual Path Provider - WSS 3.0/MOSS 2007. In essence, I want to focus on the page request lifecycle for, both, WSS 2.0/SPS 2003 and WSS 3.0/MOSS 2007. For the most part, there are a number of articles, blogs and whitepapers out on the web that provide a solid overview of the page request lifecycle for both versions of SharePoint. I would recommend reviewing them all.

To begin, the SharePointHandler is an HTTP handler used to handle request for the WSS 2.0/SPS 2003 environment. During the install of WSS 2.0/SPS 2003, the ISAPI filter is added to the IIS 6.0. Hence, the ISAPI filter intercepts all page requests from IIS. The ISAPI filter is charged with determining the handler of a page request. For the most part, ASP.NET is the default handler for IIS. If the ISAPI filter determines that the page request is managed by WSS 2.0/SPS 2003, it forwards the request to the SharePointHandler.

In contrast, the Virtual Path Provider is the component that handles the page request for WSS 3.0/MOSS 2007 environment. Likewise, ASP.NET 2.0 retreives all page requests directly from IIS 6.0. ASP.NET 2.0 determines if the page request is destined for a Web Application, In another posting, i will extend our discussions referencing the retreival of pages from the site definitions/site templates versus the database.

In short, the processing of page requests have had a major overhall. In essence, the ISAPI fileter, found in WSS 2.0/SPS 2003, has been removed. It is not used to intercept page requests in the WSS 3.0/MOSS 2007 environment.