Microsoft SharePoint Products and Technologies Team Blog - SharePoint, XBOX, .NET, Technology

3/6/2007 How to Upgrade an Area based on a Custom Site Definition

This post outlines the extra steps needed to upgrade a /folder/sharepoint.htm Portal Server 2003 (SPS) area. First, some background information which explains why these extra steps are needed. (For simplicity in this post I may refer to WSS 2.0 and SPS 2003 as v2 with MOSS 2007 and WSS 3.0 as v3).

The SPS 2003 area feature is built on top of Windows /folder/sharepoint.htm Server 2.0 (WSS 2.0) site feature. An SPS area, in a nut shell, is just a DB row with a backing WSS site. A SPS area as a whole provides many additional functionalities on top of a WSS site, but as far as WSS is concerned, the area backing web is just another WSS site based on a custom site definition.

WSS can’t fully upgrade a site created from a custom site definition without additional information since it doesn’t know the full extent of the customization made. So, we need to provide an upgrade definition file in order to upgrade a custom WSS site. Upgrading an SPS area is not much different. Since SPS knows how it has derived the SPS area definitions (SPS, SPSTOC, SPSTOPIC etc.) from the WSS team site definition, the SPS upgrade process can provide the upgrade definition file to WSS.

A custom SPS area, derived from one of the out-of-the-box area definitions, contains two sets of customizations as it appears to WSS, one made by SPS, and one made by the end user. In order to upgrade a custom area created from a custom area definition we would have to provide an upgrade definition file that tells WSS how to upgrade both sets of customizations. As we will see later, we are going to derive our custom upgrade definition file from the upgrade definition of the stock area which we used to create our custom area definition in v2.

The Microsoft Office /folder/sharepoint.htm Server 2007 (MOSS) publishing site that a v2 SPS area is upgrading into isn’t just the next incarnation of the area feature. It really is a whole new concept with many exciting functionalities. Let’s go over a couple that have upgrade implications. Though the concept of “ghosted” page still exists underneath the cover, it has been largely made irrelevant in MOSS due to the page layout feature. Instead of having all the code in the actual aspx page, a v3 (2007) publishing page refers to a layout page which in turn can have a .Net master page. What people typically consider as the “Chrome” or “Navigation” section of the page is in the .master page. The rest of the page, such as field controls and webpart zones, goes into the layout page. The actual field data are store with the publishing page. Webpart associations are also based on the actual publishing page. The layout page is essentially the template for the publishing pages. (More about page layout and master page in MOSS 2007.) We would have many publishing pages that are based on only a limited numbers of layout pages. We would not normally modify a publishing page directly. In fact, there isn’t much to modify. Crack open the source of a publishing page, all we see is a single code behind reference to the page assembly that takes care of the whole page layout magic:

<%@ Page Inherits="Microsoft.SharePoint.Publishing.TemplateRedirectionPage, Microsoft.SharePoint.Publishing, Version=12.0.0.0, Culture=neutral, PublicKeyToken=xxxx" %>

So, we really don’t care if the actual publishing page itself is ghosted or not since it will just have that one line of code in either case. We just need to tweak and maintain the handful of page layouts. As we will see later, we will need to modify a config file to specify a page layout for the welcome page of our custom areas as part of upgrade.

The upgrade process allows us to specify whether to reghost unghosted pages during upgrade. Neither choice is perfect. We either lose customization made on the unghosted pages or we end up with a page that doesn’t incorporate all of the v3 features and worse yet perpetuate these unghosted pages and make our life harder managing them in v3. We will have to make the call depending on what is more important to us. Every deployment is different. As we will see later, there is something better we can do for unghosted welcome pages.

Remember the C1, C2, etc placeholders in v2 SPS URL’s? They were there to separate the logical area navigation hierarchy from the physical area backing web hierarchy. WSS v2 had some limitations when it comes to moving a site. This separation in logical and physical hierarchy essentially allowed the support for area moves after creation. These limitations no longer exist in WSS v3, so these placeholders are removed as part of the upgrade process. Upgrade takes care of fixing most of the internal URL breaks as a result. For the rest and external URL’s there is a redirect service.

Comparing a v2 area site definition at “%SystemDrive%\Program Files\Common Files\Microsoft Shared\web server extensions\60\TEMPLATE\<lcid>\SPSTOPIC” and the corresponding v3 one at “%SystemDrive%\Common Files\Microsoft Shared Debug\Web Server Extensions\60\TEMPLATE\SiteTemplates\SPSTOPIC,” we immediately notice that the “Lists” folder is gone. In fact, there is only a very short “default.aspx” file containing the above mentioned code behind line and an “onet.xml” file under the “xml” folder. Instead of having the list definitions duplicated in each area site definition, they have been turned into features. Check under the “%SystemDrive%\Program Files\Common Files\Microsoft Shared Debug\Web Server Extensions\12\TEMPLATE\FEATURES” directory to see the list features among many other new v3 features. If we have defined custom list in v2, we might want to think about converting them into features as well. That way they can be used in any site instead of being bound to a particular site definition. If we do decide to featurize our list definition, then we will need to modify the upgrade definition file to tell WSS how to upgrade our existing lists into our new feature. Also, notice that the site definitions are no longer language specific. This is reflected in the upgrade definition file as well.

Now, finally we can move onto the steps. Keep in mind these are just the ones specifically related to upgrading custom areas. All the rest of the portal upgrade steps still apply. Also, make sure to have backups before attempting to upgrade. Trying the upgrade process on a test server first is also highly recommended.

We are going to assume we have a v2 custom area template at “%SystemDrive%\Program Files\Common Files\Microsoft Shared\web server extensions\60\TEMPLATE\<lcid>\SPSCUSTOM” with an ID of 10001 which was created based on the SPSTOPIC template. There are five major steps. Four of them we do after binary step up and before the actual upgrade process, and the last one we do after upgrade has completed successfully.

1. We need a webtemp xml file to map our area template name to our area template ID. This is the only place WSS looks for site template name and ID association. We should already have this file in v2. We can just move that file straight over to “%SystemDrive%\Program Files\Common Files\Microsoft Shared Debug\Web Server Extensions\12\TEMPLATE\<lcid>\XML” in v3. It is best if we created our own webtemp file instead of modifying one of the out-of-the-box ones, so just in case, here are the steps to creating a new one:

a. Create a file called webtemp*.xml (i.e. webtempcust.xml) in the above mentioned directory.

b. Add the following xml into that file:

<?xml version="1.0" encoding="utf-8"?>

</Template>

</Templates>

Notice the Hidden=”TRUE” attribute. Quite a few of the top reasons to create a custom template in v2 are no longer valid. Enforcing UI consistency is now done through .Net master page and the page layout feature. We don’t need custom template to create custom list definitions now since lists are factored out of individual site templates and into features. So, chances are we really don’t want our users to create sites out of these templates anymore. They are really just there as an upgrade vehicle.

2. We need to create the v3 equivalent of the v2 area definition. We are assuming our v2 template was created by copying and modifying the SPSTOPIC template, so we can do the same to create our v3 custom template as well.

a. Navigate to “%SystemDrive%\Program Files\Common Files\Microsoft Shared Debug\Web Server Extensions\12\TEMPLATE\SiteTemplates” directory.

b. Copy the SPSTOPIC template and rename the copy to SPSCUSTOM.

c. We can then apply the same customization we did in v2 to this newly created custom template. Obviously, we will need reapply the customization in a v3 compatible way. If we have any custom list we want to featurize. Now is a good time to do that as well.

3. In order to take advantage of the page layout feature, we will need to specify which layout page to use for our area welcome pages. Crack open the “SiteUpgraderConfigSPS.xml” file under the “%SystemDrive%\Program Files\Common Files\Microsoft Shared Debug\Web Server Extensions\12\CONFIG\UPGRADE\” directory. Here is what the file looks like:

<?xml version="1.0"?>

</PublishingPageLayoutMappings>

</SPSSiteUpgraderConfig>

We are going to add another PublishingPageLayoutMapping entry under the PublishingPageLayoutMappings node:

We are basically saying that for all welcome pages in areas created using our custom area template with ID of 10001, use customlayout.aspx as the page layout. Customlayout is just an example; we could use any name we want as long as it is unique within the page layout gallery. This layout page can be structured anyway we want. If our goal is to duplicate our v2 look and feel exactly, we can just take our v2 default.aspx page, added the v3 webpart manager control (<WebPartPages:SPWebPartManager id="m" runat="Server" /> ), and use that as our layout page. Obviously we are going to miss out on some of the v3 features since our v2 UI would not expose them.

The recommended way to create the layout page is to copy an out-of-the-box v3 one and modify the copy to suit our needs. Make sure the webzone ID’s stay the same as in v2, or we will end up with webparts in the wrong zone or moved off to the page gallery after upgrade.

If we unghosted our v2 welcome pages to apply a consistent UI using FrontPage, why not upgrade the UI changes into the page layout feature which is meant to do just that. Inspect all the unghosted pages (prescan will list all of them). Try and see if we can divide all the customizations into a few layout types. Create those layout pages, and map area templates to layout pages using the SiteUpgraderConfigSPS.xml file. Then upgrade with the reghost option enabled. This does require our customizations to match nicely with area definitions since we can only specify page layout per area template definition ID. However, if we can get the majority of them correct, we can always come back in and manually tweak the page layout of a few welcome pages after upgrade.

So, where do these new custom page layouts go? Well, since we haven’t even started the upgrade, the page layout gallery hasn’t been created yet. Hang on to these layouts, and we will upload them in step five.

4. Now, it is time to finally create our upgrade definition file. Creating this file can be as easy as searching and replacing a few strings depending on the type of customizations we did to our custom area template.

An upgrade definition file can have multiple <WebTemplate> nodes with each outlining how to upgrade sites created from a particular site template. Since we created our custom area template from the SPSTOPIC template (ID=31), we will use this WebTemplate as our starting point:

a. Open the SPSUpgradePremium.xml file (or SPSUpgrade.xml depending on your SKU) under “%SystemDrive%\Program Files\Common Files\Microsoft Shared Debug\Web Server Extensions\12\CONFIG\UPGRADE” directory and locate the < WebTemplate> node with ID=31.

b. Create an xml file in the same directory with any name and add the following xml text to the file:

<?xml version="1.0" encoding="utf-8"?>

</Config>

c. Copy the entire ID=31 <WebTemplate> from SPSUpgradePremium.xml to our new file under the <Config> node.

d. Change ID to 10001 and replace the text SPSTOPIC with SPSCUSTOM.

It is recommended that we don’t modify the existing upgrade definition file and create our own instead. Modifying any existing upgrade definition file is not supported and will cause problems when installing patches.

There are four sub-nodes in a WebTemplate node:

<Lists>: maps a list ID to the corresponding list feature ID. If we featurized any of our v2 custom list, we need to add an entry here.

<Files>: maps an old setup path (ghost path) to the new one. For example, our area template has moved from a directory under an lcid to a global directory, thus we need the following entry to tell upgrade how to fix the setup path:

Also, our lists definitions have been moved out of site definitions and their support files moved to a global directory as well, that is why we need entries like the following:

We will need to add one entry for each custom file that has its setup path moved.

<AppliedSiteFeatures>: This one is only useful if our custom template can be used to create the root site in a site collection. Since SPS v2 does not allow custom home area template, this one is irrelevant for upgrade.

<AppliedWebFeatures>: Allows us to specify what features to turn on for areas created using our custom template during upgrade. The features with their ID’s already listed here are all required for upgrade to work correctly. We can add any additional one as needed.

5. Once upgrade has finished successfully, navigate to “master page and page layouts” gallery at http://<servername>/_catalogs/masterpage/Forms/AllItems.aspx and upload the page layouts created in step three above.

Guest Post: Boxin Lee, Dev, SharePoint Product Team.

3/6/2007 What every SharePoint administrator needs to know about Alternate Access Mappings (Part 1 of 3)

Hi folks, this is Troy Starr again from the Windows SharePoint Services Test team. Today I"d like to talk about one of the most powerful, but often one of the least understood, features in Windows SharePoint Services 3.0 and Microsoft Office SharePoint Server 2007. That feature is called Alternate Access Mappings. Around here, we just call it "AAM" for short.

At the most basic level, AAM tells SharePoint how to map web requests (for example, browsing to the homepage of a SharePoint site) to the correct web application and site so that SharePoint can serve the correct content back to you. It then tells SharePoint what URL the users should be taken to as they interact with SharePoint.

Seems simple enough, doesn’t it? Those of you who are familiar with developing web applications in Internet Information Services may be wondering right now why we need such a feature since IIS can tell you what the URL of an incoming web request is. The major reason we need this is that there are common Internet deployment scenarios where the URL of a web request received by IIS is not the same URL that the end user entered. These are most common in reverse proxy publishing and load balancing scenarios.

How is this possible? Let"s consider a reverse proxy scenario. A reverse proxy is a device that sits between end users and your web server. All requests to your web server are first received by the reverse proxy device, and if those requests pass the proxy"s security filtering, the proxy will forward the requests on to your web server. Reverse proxies can perform advanced functionality such as receiving a web request over the Internet via SSL (HTTPS), but forward the request to the your server via HTTP. This is referred to as off-box SSL termination. They can also forward the request to a different port number than it was originally received on and can even change the HTTP Host header field. If SharePoint were base its links off of the URL of the request it received, the links that end users click on could be the incorrect "internal" URL rather than the correct "public" URL.

SharePoint is compatible with a variety of reverse proxy servers, but for this example we"ll take a look at a publishing rule from Microsoft"s reverse proxy software - Internet Security and Acceleration Server 2006. ISA Server 2006 includes a SharePoint publishing wizard that walks you through creating a publishing rule for SharePoint. Once the rule is created, you can modify it at any time. (The following images show a slightly modified publishing rule where the "Forward the original host header" option is turned off to help demonstrate the flexibility of AAM. If we left the "Forward the original host header" option turned on, the public hostname would also serve as the internal hostname when configuring AAM.) The first two dialogs show the "listener" and "public name" properties of the rule, which define what URL users will use to access your SharePoint site. Remember that this URL is really the URL of your reverse proxy server, which will forward the request to your SharePoint server.
listener highlighted.PNG public name highlighted.png

The end user"s URL is comprised of the public protocol, the public hostname, and the public port number.

Public Protocol	+	"://"	+	Public Hostname	+	":"	+	Public Port Number	=	Public URL
HTTPS				www.contoso.com				443		https://www.contoso.com

The next two dialogs show the "to" and "bridging" properties of the rule, which define what URL the reverse proxy server will use to forward the request to your SharePoint server.

bridging highlighted.png to highlighted.png

The SharePoint server"s URL is comprised of the internal protocol, the internal hostname, and the internal port number.

Internal Protocol	+	"://"	+	Internal Hostname	+	":"	+	Internal Port Number	=	Internal URL
HTTP				sharepoint.dmz.contoso.com				80		http://sharepoint.dmz.contoso.com

extend web application highlighted.png

Great - we"ve properly set up this reverse proxy server to receive web requests from end users at https://www.contoso.com and forward them to your SharePoint server at http://sharepoint.dmz.contoso.com. We"re halfway there! The next step is to configure your SharePoint web application and AAM to match the publishing rule above. To do this, we"ll extend an existing web application to an additional IIS Web site just for your reverse proxy"s publishing rule. Note that you"re also able to create a new web application from scratch for this publishing rule - the fields you"ll need to fill out are the same in either case.

Browse to your WSS 3.0 Central Administration site and click on the Application Management tab. Next, click "Create or extend Web application" and then click "Extend an existing Web application." Select the web application that you wish to use, and then fill out the port, host header, and SSL fields based on the internal URL properties that we defined above. In the URL field, enter the public URL that we defined above. Finally, you"ll want to select an AAM Zone to assign this extension of your web application to. There are a maximum of 5 zones available in each web application. We"ll use the Internet zone in this example, but you"re free to use any available zone. All of the zones provide the same functionality, although the Default zone will always be used for certain features such as sending administrative e-mail messages to site collection owners. When you"re finished, click OK to create the IIS Web site.

Next, you"ll want to verify that your public URL was created correctly in AAM and then add your internal URL. Unless your internal URL is the same as your public URL, this is an extra step that you must perform manually. To do this, browse to your WSS 3.0 Central Administration site and click on the Operations tab. Next, click "Alternate access mappings." Click the Alternate Access Mappings selector drop-down and select the web application that you"re publishing through your reverse proxy server. You should now see the AAM URLs assigned to your web application.

AAM before.png

As you can see, the public URL from the reverse proxy publishing rule has been assigned to your web application"s Internet zone. The final touch is to add the internal URL from the reverse proxy publishing rule to your web application"s Internet zone. To do this, click "Add Internal URLs" in the AAM toolbar, type in the internal URL, and select the same zone that you used for the public URL. In this case, that was the Internet zone. When you"re finished, click Save. You should now see the additional URL is assigned to your web application, in the same zone as the public URL of your reverse proxy publishing rule.

AAM after.png

All done! Now, when a user browses to https://www.contoso.com, the web request will be received by the proxy server and forwarded to http://sharepoint.dmz.contoso.com. SharePoint will then receive the web request, see that the URL of the request is http://sharepoint.dmz.contoso.com, find that this URL is assigned to the Contoso web application, and return the content from that web application. In addition, because the http://sharepoint.dmz.contoso.com URL is assigned to the Internet zone, SharePoint will also generate links on the pages using the public URL for that zone - https://www.contoso.com. This ensures that end users are taken to the proper URL when clicking on links on the page.

Load balancers work similarly, especially if they overwrite the end user"s original URL with the URL of the individual web server that the request is being load balanced to. To address this, just add each individual web server"s URL to AAM as an internal URL and associate them all to the same zone as end user"s public URL.

I hope that this introduction to Alternate Access Mappings was helpful to you. Please feel free to post comments to this blog entry with any questions you may have about AAM. I will be posting another blog entry soon covering common AAM mistakes and how to avoid them.

Troy Starr

3/6/2007 Configuring Database Mirroring for SharePoint Products & Technologies

Check out this new white paper which details how to configure Database Mirroring in SQL 2005 for SharePoint Server and WSS 3.0. (Includes T-SQL Commands)

Using Database Mirroring with Office SharePoint Server and Windows SharePoint Services (http://go.microsoft.com/fwlink/?LinkId=83725&clcid=0x409)

Table of Contents

Introduction to Database Mirroring

Database Mirroring Modes
Security Associated with Database Mirroring

How to Set Up Database Mirroring with SharePoint Products and Technologies

Prerequisites
Recommended Topologies
Recommend Database Limits
Performance and Scale
Setup Steps
Database Mirroring with Certifcates and Full Recovery
Setting up a Witness Server

Recovering from a Failure

Types of Failover
Automatic Failover
Manual Failover
Forced Failover (possible data loss)
Notifying SharePoint Products and Technologies when a Failover Occurs
Configuration Database and Administration Content Database
Content Database
Search Database
Shared Service Provider Database (Office SharePoint Server only)

3/2/2007 Integrating ASP.NET AJAX with SharePoint

[Cross-posting from Mike Ammerlaan"s blog. I was going to include this as part of my upcoming "Recommended Reading for March" post, but since it"s such an important and frequently asked about topic and because the info is coming from the "horse"s mouth," I thought that it deserves to be cross-posted here in full. <Lawrence />]

Microsoft ASP.NET AJAX 1.0: A Background

Microsoft ASP. NET AJAX 1.0 lets developers build Web 2.0 sites using the latest Ajax techniques.

ASP.NET AJAX extends ASP.NET 2.0 and makes several new tools and techniques available to help you build applications more quickly:

Extensions to JavaScript. ASP.NET AJAX extends the JavaScript library to bring standard object oriented concepts to JavaScript. It brings a formal type declaration system, with support for inheritance. It also provides a significant number of out of the box types, including types such as Sys.Net.WebRequest for working with web services. Finally, it helps to abstract some cross-browser issues such as XML element traversal. This makes it much easier to create robust JavaScript libraries and frameworks which are commonly needed by rich internet applications.
ASP.NET Control Extenders. Extenders are additional ASP.NET controls which can extend the functionality of existing controls with additional Ajax capabilities. A common example is an extender which allows existing textbox controls to have autocomplete functionality with no modification to the extended control. (The autocomplete extender is included with the ASP.NET AJAX Control Toolkit.)
UpdatePanels. UpdatePanels allow your existing ASP.NET controls and web parts to achieve the fluid, no-postback updates of Ajax-based applications with minimal re-coding of your control or part. Quite simply, controls within the UpdatePanel control which ordinarily would post back to update their data will now be routed through an Ajax-style callback, resulting in a silent update back to the server. This makes your application “postback” much less, making interaction with your control more seamless.

With Microsoft ASP.NET AJAX 1.0, you can build more dynamic applications that come closer to the rich style of interruption-free interaction you may see in standard client applications.

Microsoft ASP.NET AJAX 1.0 and SharePoint

Windows SharePoint Services version 3 builds much more directly on top of ASP.NET 2.0; therefore, many of the capabilities of ASP.NET AJAX work directly with SharePoint.

However, in a few cases there are some compatibility issues between ASP.NET AJAX and SharePoint which are anticipated to be addressed in the first service pack of Windows SharePoint Services. For this reason, until that first Service Pack of Windows SharePoint Services, we are unable to offer formal support through Microsoft Product Support Services for usage of ASP.NET AJAX within a SharePoint Web site. This post is intended to provide developers with some guidelines for evaluating ASP.NET AJAX and WSS3.0.

Specifically, there are some limitations on usages of the UpdatePanel in your web parts and controls. Some approaches are described below to address these limitations, but these are workarounds and as such may cause other issues in your application.
Here are some common scenarios in SharePoint you should be able to achieve with Microsoft ASP.NET AJAX 1.0:

Building a more powerful, re-usable JavaScript libraries you can use in your web controls and parts
Enabling your web services to render via JSON, resulting in easier usage in JavaScript/Ajax Applications
Building a web part that takes advantage of Extender technology to provide richer interaction styles, such as autocomplete on a textbox.
Using an UpdatePanel in your web part or control for more fluid, no postback interaction. (this will require some workarounds, however.)

Adding Microsoft ASP.NET AJAX Technology to SharePoint Pages

To extend your SharePoint site with Microsoft ASP.NET AJAX 1.0, you’ll need to perform a few steps.

First, you will need to download and install ASP.NET AJAX on servers in your farm.
Second, you need to extend web.config with some settings to enable ASP.NET AJAX technology.
Third, you will need to add the ASP.NET AJAX Script Manager into your master page to enable scenarios such as Extenders or UpdatePanels.

Installing ASP.NET AJAX on servers in your farm

You will want to install the full "ASP.NET 2.0 AJAX Extensions 1.0" from ajax.asp.net.

Extending SharePoint web.config files with Microsoft ASP.NET AJAX 1.0

Extending SharePoint web.config files with ASP.NET AJAX requires that you interleave some Ajax registration entries in-line with WSS registration entries. To do this you will need to edit your SharePoint web.config file, typically in a directory like c:\inetpub\wwwroot\wss\virtualdirectories\80.

1. Add a <sectionGroup>element to the <configSections>tag:

<configSections>
    <sectionGroup name="system.web.extensions" type="System.Web.Configuration.SystemWebExtensionsSectionGroup, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35">
      <sectionGroup name="scripting" type="System.Web.Configuration.ScriptingSectionGroup, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35">
          <section name="scriptResourceHandler" type="System.Web.Configuration.ScriptingScriptResourceHandlerSection, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" requirePermission="false" allowDefinition="MachineToApplication"/>
        <sectionGroup name="webServices" type="System.Web.Configuration.ScriptingWebServicesSectionGroup, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35">
          <section name="jsonSerialization" type="System.Web.Configuration.ScriptingJsonSerializationSection, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" requirePermission="false" allowDefinition="Everywhere" />
          <section name="profileService" type="System.Web.Configuration.ScriptingProfileServiceSection, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" requirePermission="false" allowDefinition="MachineToApplication" />
          <section name="authenticationService" type="System.Web.Configuration.ScriptingAuthenticationServiceSection, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" requirePermission="false" allowDefinition="MachineToApplication" />
        </sectionGroup>
      </sectionGroup>
    </sectionGroup>
</configSections>

2. Add a <controls> section as a child of the <system.web>/<pages> tag:

<pages>
      <controls>
        <add tagPrefix="asp" namespace="System.Web.UI" assembly="System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
      </controls>
</pages>

3. Add the following tag to the <assemblies> tag, within <compilation>:

<assemblies>
<add assembly="System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
</assemblies>

4. Add some new registrations to the end of the <httpHandlers> section:

<httpHandlers>
      <add verb="*" path="*.asmx" validate="false" type="System.Web.Script.Services.ScriptHandlerFactory, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
      <add verb="*" path="*_AppService.axd" validate="false" type="System.Web.Script.Services.ScriptHandlerFactory, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
      <add verb="GET,HEAD" path="ScriptResource.axd" type="System.Web.Handlers.ScriptResourceHandler, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" validate="false"/>
</httpHandlers>

5. Add a new registration to the HttpModules section, beneath any existing registrations:

<httpModules>
<add name="ScriptModule" type="System.Web.Handlers.ScriptModule, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
</httpModules>

6. Add a SafeControl entry for the System.Web.UI namespace from Microsoft Ajax Extensions, within the <SharePoint>/<SafeControls>section:

<SafeControls>
<SafeControl Assembly="System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" Namespace="System.Web.UI" TypeName="*" Safe="True" />
</SafeControls>

7. Finally, add the following configuration tags at the bottom of web.config, near the bottom before the end <configuration> tag:

<system.web.extensions>
    <scripting>
      <webServices>
      
      
      
      
      </webServices>
      
    </scripting>
</system.web.extensions>
<system.webServer>
    <validation validateIntegratedModeConfiguration="false"/>
    <modules>
      <add name="ScriptModule" preCondition="integratedMode" type="System.Web.Handlers.ScriptModule, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
    </modules>
    <handlers>
      <remove name="WebServiceHandlerFactory-Integrated" />
      <add name="ScriptHandlerFactory" verb="*" path="*.asmx" preCondition="integratedMode"
           type="System.Web.Script.Services.ScriptHandlerFactory, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
      <add name="ScriptHandlerFactoryAppServices" verb="*" path="*_AppService.axd" preCondition="integratedMode" type="System.Web.Script.Services.ScriptHandlerFactory, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
      <add name="ScriptResource" preCondition="integratedMode" verb="GET,HEAD" path="ScriptResource.axd" type="System.Web.Handlers.ScriptResourceHandler, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
    </handlers>
</system.webServer>

Adding a ScriptManager into a SharePoint MasterPage

Many components of ASP.NET AJAX require the inclusion of a .NET ScriptManager control within a page.

Although it may be possible in some cases to dynamically insert a script manager from within a control, in many cases the control may not be able to insert the script manager early enough in the page lifecycle depending on how the control is used, making this tricky to get right. Also, the control implementer will need to ensure that multiple instances of their control (or other controls) do not result in the addition of multiple script managers within the page. For these reasons, dynamic insertion of a ScriptManager control from another control is not recommended.

To statically embed a script manager into a page, it is recommended that you add the ScriptManager into the master page of a site.

To do this, open up the master page for your site. Typically, this will be located at <site url>/_catalogs/masterpage. You can edit this file by opening it in an editor such as Microsoft SharePoint Designer, or directly in Notepad by opening your master page library via DAV (typically \\server\<pathtosite>\_catalogs\masterpage.)

Add the following into the markup of your page. A recommended location is right beneath the WebPartManager registration (search for <WebPartPages:SPWebPartManager id="m" runat="Server" />):

<asp:ScriptManager runat="server" ID="ScriptManager1"></asp:ScriptManager>

Using UpdatePanels within SharePoint

UpdatePanels are a very useful addition to ASP.NET AJAX, and represent the simplest way to convert existing, standard ASP.NET controls and parts to take advantage of Ajax techniques. However, there are some changes within Windows SharePoint Services which may get in the way of working with ASP.NET AJAX.

Windows SharePoint Services JavaScript has a “form onSubmit wrapper” which is used to override the default form action. This work is put in place to ensure that certain types of URLs, which may contain double byte characters, will fully work across most postback and asynchronous callback scenarios. However, if your scenarios do not involve double byte character URLs, you may successful disable this workaround and gain the ability to use ASP.NET AJAX UpdatePanels.

To do this, you may need to register a client startup script which disables this workaround, in addition to resetting the default form action:

This script may be directly embedded in the page, or could be emitted by a control that uses the UpdatePanel. The following is an example of a very simple ASP.NET Web Part which uses UpdatePanel capabilities:

using System;
using System.Collections;
using System.Text;
using System.Web.UI.WebControls;
using System.Web.UI.WebControls.WebParts;
using System.Web.UI;

namespace MS.Samples
{
    public class AjaxUpdatePanelPart : WebPart
    {
        private Label label;
        private TextBox textBox;

        protected override void CreateChildControls()
        {
      base.CreateChildControls();

this.EnsureUpdatePanelFixups();

UpdatePanel up = new UpdatePanel();

            up.ID = "UpdatePanel1";
            up.ChildrenAsTriggers = true;
            up.UpdateMode = UpdatePanelUpdateMode.Conditional;

this.Controls.Add(up);

            this.textBox = new TextBox();
            this.textBox.ID = "TextBox";
            up.ContentTemplateContainer.Controls.Add(this.textBox);

            this.label = new Label();
            this.label.Text = "Enter your name.";
            up.ContentTemplateContainer.Controls.Add(this.label);

            Button button = new Button();
            button.Text = "Say Hello";
            button.Click += new EventHandler(HandleButtonClick);
            up.ContentTemplateContainer.Controls.Add(button);
        }

        private void HandleButtonClick(object sender, EventArgs eventArgs)
        {
            this.label.Text = "Hello " + this.textBox.Text;
        }

        private void EnsureUpdatePanelFixups()
        {
            if (this.Page.Form != null)
            {
                string formOnSubmitAtt = this.Page.Form.Attributes["onsubmit"];
                if (formOnSubmitAtt == "return _spFormOnSubmitWrapper();")
                {
                    this.Page.Form.Attributes["onsubmit"] = "_spFormOnSubmitWrapper();";
                }
            }

            ScriptManager.RegisterStartupScript(this, typeof(AjaxUpdatePanelPart), "UpdatePanelFixup", "_spOriginalFormAction = document.forms[0].action; _spSuppressFormOnSubmitWrapper=true;", true);
        }
    }
}

Output Caching and ASP.NET AJAX

ASP.NET AJAX infrastructure is not compatible with output caching features. This output caching infrastructure is a featured component of managed content pages such as those supported by web content management features in Microsoft Office SharePoint Server. For this reason, many scenarios which involve output cached features may not be able to take advantage of components like UpdatePanel. However, you will be able to successfully use other ASP.NET AJAX features, such as the JavaScript library, combined with your output cached pages.

Compatibility with output caching is targeted for a future release of ASP.NET AJAX infrastructure.

Conclusion

Microsoft ASP.NET AJAX 1.0 provides great building blocks for building rich Ajax-enabled applications. Combined with the power of the SharePoint platform, and knowing some of the integration limitations, you can build powerful Web2.0 applications that bring together the best of both of these technologies.

Mike Ammerlaan, Program Manager

3/2/2007 Be wary when removing or replacing the My Site link

I"ve seen a recent trend where people are either removing or replacing the My Site link that"s at the top of the page. Before doing this be sure that it is necessary because that link isn"t really a link at all it"s a server control; with functionality behind it. More than likely what you really want to do is style it, it can be style using CSS just like other server controls to match the look and feel of your site.

Besides security trimming, what other functionality does it have you ask? Well one of the coolest is it allows for personalization site skinning.

If you haven"t heard of personalization sites here"s a few topics you should read:

Plan My Sites
Configure Personalization Sites
Plan KPIs in My Site

Back to personalization site skinning, just as a personalization site connect its navigation to My Site, personalization site skinning allows you to do that on a per page basis regardless of the site template used to create the site. Personalization site skinning is most valuable when you"ve already built a highly personalized page related to your site or portal and you want to connect it to users" My Sites in a form of shared navigation.

I"m going to step back from the topic and just show you what the control can do using the OOB portal homepage as an example; notice the changes in the navigation. Look at how once a site is skinned and pinned it becomes a part of the user"s My Site navigation bar yet if you still went to the portal home page directly it look as it always does.

Figure 1: OOB portal homepage

Figure 2: Skinned and pinned portal homepage

Figure 3: My Site homepage

Give it a try on your own to get a better feel for it. Just add the MySiteView=1 query string parameter to your URL, chose pin when you hover over the navigation item and play with going back and forth between My Site and the skinned page. You can also do it for multiple pages.

So if you find this cool, then again be wary if you"re planning to replace or remove the My Site control for your page because if you do you will lose this functionality.

Greg Mattox, Program Manager

3/2/2007 Useful and (free!) SharePoint "Features" available at http://www.CodePlex.com/Features

Occasionally, I ask SharePoint professionals, who have done interesting and useful work to post a guest blog entry here, so their contributions can deservedly get more exposure within the SharePoint community. This is certainly one such case. Scot Hillier, SharePoint MVP and author of the recently published Microsoft SharePoint: Building Office 2007 Solutions in C# and VB books, has developed a bunch of very useful Features that you can leverage for your SharePoint environment. Read on and enjoy.

For developers creating solutions with SharePoint, Features are the most important and powerful capability available. Features provide an atomic deployment model that allows them to move easily from development to production. When deployed as solution files, administrators can easily roll them out to new sites without additional assistance. I often tell students and customers that they should have a bias toward creating SharePoint solutions that are based on Features first. In previous versions of SharePoint, developers generally created solutions using web parts or custom applications. In SharePoint 2007, however, all customization techniques should primarily be viewed as components of Features rather than complete solutions unto themselves. For more information on Features, go to the MSDN technical reference here.

When implementing SharePoint within an organization, I often find that I receive the same requests over and over again. For example, many organizations want to “push” alerts at groups of users whether or not they have subscribed to certain content. Others want specific customizations to lists such as the addition of presence information or tracked comments. Almost everyone wants to create new sites with a designated theme and master page. All of these requests are ideal candidates for Features because they are atomic and can be used in many situations.

This need to reuse solutions – and the recognition that many organizations need the same ones – was the motivation for my “Features” project available at www.codeplex.com/features. The goal of the project is to collect common types of Features that either solve particular problems or represent often requested functionality. The project is an evolving one that uses some of my ideas as well as contributions from the SharePoint community. I would like for others to contribute to the project either directly or by suggesting areas where Features are needed. (There are also a few dozen other SharePoint oriented projects on CodePlex worth checking out.)

Minimal Publishing Site

This Feature creates a minimal publishing site for use in MOSS that can be used as a starting point for creating public Internet sites. It is based on the Publishing template that ships with MOSS, but the style sheets, graphics, and page layouts have been removed.

Just the basics remain in the Minimal Publishing site

Print List

This Feature adds a "Print List" menu item to the "Actions" menu for every list in the site collection. This Feature is based on the sample found here and is used with the permission of the author.

A printer-friendly view of a list

Theme Changer

This Feature changes the site theme and alternate style sheet to those specified in the FEATURE.XML file. This Feature is ideal for changing the site theme and Alternate CSS when a new site is created.

Placeholder Master

This Feature adds a new master page to the gallery named "Placeholder.master". This master page shows all of the placeholders and their content in a table structure so you can easily see what content is rendered in which placeholder. This Feature is useful for understanding how placeholders are used in master pages and which ones you would have to change when creating a custom master page.

Showing placeholder content

Presence Contact List

This is a contact list modified to show presence information as a drop-down associated with the e-mail field. This Feature is based on the code posted here.

Presence information in a custom list

Content Type Hierarchy

This Feature presents the site content types in a hierarchical view. It shows the relationships between the content types, including hidden types.

Content Type Hierarchy

Log Viewer

This is a Feature for viewing the Unified Logging Service (ULS) logs through the SharePoint Central Administration site.

Viewing Log Files

Scot Hillier
http://www.shillier.com

3/2/2007 Microsoft Official Curriculum (MOC) content for SharePoint Products and Technologies now available

Hi, I’m Patrick Hines, a Technologist with Microsoft Learning. I’d like to give everyone an overview of the Microsoft Learning products for SharePoint that are now available.

Last Friday (02/23), we signed off on our new MOC (Microsoft Official Curriculum) content for SharePoint. These RTM versions of the MOC content for MOSS 2007 and WSS 3.0 are now available to CPLSs (Certified Partner for Learning Solution Centers) and MCTs (Microsoft Certified Trainers) worldwide. The MOC content is a significant addition to the eLearning lessons, MS Press books, and Microsoft Certified Professional exams for SharePoint, where were previous announced on this blog.

So, how did the MOC content get developed? Very, very carefully. J It was really exciting for me to be involved in building this content because there was a lot of input from the SharePoint Product Group and SharePoint MVPs. The original outlines and designs were reviewed by me, Arpan Shah, Mike Fitzmaurice, and Joel Oleson from the Product Group. They provided feedback for the modules that assisted us in getting this content as accurate as possible during the development phase. When developing courseware and exams, we are not always able to get Product Group SMEs to provide feedback, but these folks were very involved and committed, and that contributed toward what I feel will be an extremely successful content offering.

In December last year, we reached our Beta milestone and conducted a “beta teach” of 5060A (Implementing WSS 3.0) and 5061 (Implementing MOSS 2007). Our beta teaches usually consist of 1 MCT and about 9 students from outside of Microsoft. These are people, who meet the target audience and prerequisite requirements. Based on the review of the beta teach and additional feedback from Joel Oleson, Gabe Bratton, and Ryan Rogers (Gabe and Ryan are Supportability Program Managers in the SharePoint Product Group), we were able to make substantial fixes. Overall, it was a very successful team effort.

What were the biggest challenges? Each course had a different outside vendor, whom we had hired to develop the core content, and that added some complexity, but nothing we couldn’t manage. The vendor who created 5060A was recently brought on and trained to create Instructor Led Training (ILT). Jim Cochran (from MS Learning) was involved daily in supporting the vendor and reviewing the content for 5060A. We had to change SMEs and Technical Reviewers on 5060A. We also had to remap the content midstream to verify that it supported our MCTS (Microsoft Certied Technical Specialist) exams. The vendor who worked on 5061 was a team we had used many times in the past, so there were fewer challenges with that one compared to 5060A.

How can you take these courses? You will need to sign up for a course with your local training provider to attend these courses. I’d say book a course as soon as you can to get in early. The CPLSs (Certified Partner for Learning Solution centers) nearest you can be found by visiting this site:

http://www.microsoft.com/learning/cpls/default.mspx

Here are the Microsoft Official Curriculum Instructor Led Training courses available at CPLSs. (Note: These courses are currently being localized in French and German.)

· Implementing Windows SharePoint Services 3.0
Course 5060A: Two days.

· Implementing Microsoft Office SharePoint Server 2007
Course 5061: Three days.

In additional, here are the upcoming online courses that will be available on our eLearning site very soon.

· Collection 5403: Implementing Microsoft Windows SharePoint Services
(scheduled to be available on 3/2/2007 and includes the following courses)

o Course 5244: Introduction to Microsoft Windows SharePoint Services 3.0

o Course 5245: Planning the Microsoft Windows SharePoint Services 3.0 Environment

o Course 5246: Deploying Microsoft Windows SharePoint Services 3.0

o Course 5247: Administering Microsoft Windows SharePoint Services 3.0

o Course 5248: Maintaining and Optimizing Microsoft Windows SharePoint Services 3.0

o Course 5249: Customizing and Securing Microsoft Windows SharePoint Services 3.0

· Collection 5404: Implementing Microsoft Office SharePoint Server 2007
(scheduled to be available on 3/9/2007 and includes the following courses)

o Course 5250: Introduction to Microsoft Office SharePoint Server 2007

o Course 5251: Deploying and Configuring Microsoft Office SharePoint Server 2007

o Course 5252: Administering Microsoft Office SharePoint Server 2007

o Course 5253: Implementing Content Management Solutions by Using Microsoft Office SharePoint Server 2007

o Course 5254: Implementing Business Forms by Using Microsoft Office SharePoint Server 2007

o Course 5255: Implementing Business Intelligence Solutions in Microsoft Office SharePoint Server 2007

Patrick Hines

2/26/2007 Community Kit for SharePoint: User Group Edition 1.0 now available

The CKS:UGE was pre-announced just this past Wednesday, and the Release Candidate has already been downloaded almost 200 times! Several of you promptly sent in feedback, and I"m very pleased to announce that the final 1.0 version of the CKS:UGE is now available for download here.

After 5 months of starts and stops, the CKS:UGE 1.0 has finally reached the Release milestone thanks to the tireless and creative efforts of Shane Perran, a SharePoint MVP, on top of the initial work done by Inetium, a Microsoft Gold Certified Partner. The CKS:UGE demo site is at http://sharepoint.microsoft.com/sharepoint/cks/uge.

The first 3 user groups to implement a community website based on the CKS:UGE will each receive a dozen limited edition SharePoint logo"d thermoses to be given as prizes at their next meeting. :-)

Some of you might look at the CKS:UGE and say, "What"s the big deal? I can manually recreate the exact SharePoint site in just a few hours." Yes, you probably can, but the benefit of having such a site template is that you wouldn"t have to, and those few hours multiplied by hundreds of user groups come out to be many, many hours avoided. It"s a site admin (.STP) application template, so it"s very easy and quick to deploy even if you"re using a hoster such as one of these.

I hope that the CKS:UGE provides both a model reference and adequate motivation for others within the SharePoint community to follow suit with a CKS: Wedding Celebration Edition, a CKS: Fantasy Sports Edition, a CKS: Home Owner Association Edition, and perhaps even a CKS: Church Edition. :-)

The ultimate goal of the CKS is to make SharePoint mainstream -- pervasive as a collaborative and community oriented application platform and part of the common vernacular. So, CKS:UGE 1.0 is just the tip of the iceberg. CKS 2.0 is already being planned, and I"m looking for volunteers to join in at http://www.codeplex.com/cks. Those of you, who are long time ASP.NET developers, may liken the CKS to DotNetNuke, and I would be honored by the comparison because I sincerely admire what the DNN folks have done for the ASP.NET community.

Here are several custom web parts for the CKS 2.0 that have already been developed and whose source code will be posted on CodePlex soon.

Membership Request web part with built-in CAPTCHA:
Membership Request Management web part with integration with Active Directory to create accounts (and can be extended to integrate with other directory services):
Self-Service Password Recovery web part:
Latest Posts web part that aggregates from all Discussion Boards within a Site Collection:
Unanswered Posts web part that aggregates from all Discussion Boards within a Site Collection:

2/24/2007 Updated Installation Guide for the 20 server admin Application Templates for WSS 3.0

In order to meet our localization deadlines, we were a bit too hasty in documenting the installation instructions for the 20 server admin Application Templates, which were released only 2 days ago. Our bad for that, and we appreciate how quickly some of you in the SharePoint community let us know about your disappointment. J But I was very pleased to see people helping each other to get past the installation issues, and in particular I’d to like thank Dustin Miller, SharePoint MVP, for compiling and posting the workarounds.

We know that we have to do better than to just let this one slide, so here’s the officially updated Installation Guide. We"ll get this formally posted as a KB article or somewhere on TechNet as soon as possible. We"ve also sent this to our localization teams. If you run into any additional issues or problems, please leave a comment here.

=========================================================

To install the Application Template Core solution:

=========================================================

To deploy the Application Template Core solution on a server running Windows SharePoint Services, follow these instructions below. Note that in order to complete the following installation, you must have Administrator rights to both the Windows SharePoint Services site and server on which it is to be installed.

1. Download the solution .EXE file to your computer.

2. Run the .EXE file to unpack the template file to a location on your computer.

3. Select the solution file, ApplicationTemplateCore.wsp, from the extracted distribution. This solution file will be added to the Windows SharePoint Services solution store.

4. On the Windows command line, run "stsadm -o addsolution -filename ApplicationTemplateCore.wsp".

5. Next, run "stsadm -o deploysolution -name ApplicationTemplateCore.wsp -allowgacdeployment". Additional attributes may be required based on your Windows SharePoint Services configuration. For example:

· Standalone: [ -local | -time <time to deploy at> ]

· Farm: [ -immediate | -time <time to deploy at> ]

6. Then run "stsadm -o copyappbincontent".

7. The Application Template Core solution has now been added to the solution store and deployed on the server.

=========================================================

To install a server admin Application Template:

=========================================================

Each server admin Application Template is deployed in the Windows SharePoint Services environment as a solution. To deploy a solution on a server running Windows SharePoint Services, follow these instructions. Note that in order to complete the following installation, you must have Administrator rights to both the Windows SharePoint Services site and server on which it is to be installed.

1. Before installing any Application Template, you must first install the Application Template Core solution, ApplicationTemplateCore.wsp. If you have already installed this solution, proceed to Step 2. Otherwise, go here to download the Application Template Core solution:

2. Download the application template solution EXE file to your computer.

3. Run the EXE file to unpack the template file to a location on your computer.

4. Select the solution file, <template_name>.wsp, from the extracted distribution. This solution file will be added to the Windows SharePoint Services solution store.

5. Via command line, run "stsadm -o addsolution -filename <template_name>.wsp"

6. Next, run "stsadm -o deploysolution -name <template_name>.wsp -allowgacdeployment". Additional attributes may be required based on your Windows SharePoint Services configuration. For example:

· Standalone: [ -local | -time <time to deploy at> ]

· Farm: [ -immediate | -time <time to deploy at> ]

7. To check deployment status by browsing to WSS Central Administration, click the "Operations" tab and then click "Solution Management" under Global Configuration.

8. After the solution is marked "Globally deployed," run "iisreset" from the command line.