What's New in Windows SharePoint Services 2.0 Service Pack 2
Microsoft Windows SharePoint Services Service Pack 2 (SP2) is now available as a download from the Microsoft Download Center. It is also included with Microsoft Windows Server 2003 R2. Windows SharePoint Services SP2 adds the following functionality to Windows SharePoint Services SP1:
Support for IP-bound virtual servers
Support for advanced extranet configurations
Kerberos authentication enabled by default
Support for Microsoft ASP.NET 2.0
Support for Microsoft Windows Server 2003 64-bit implementations
Support for SQL Server 2005
Support for Active Directory Federation Services (ADFS)
Service Pack 2 also includes the changes from Service Pack 1 and all hotfixes that have been released since Service Pack 1.
Note
Additional hotfixes might be released between the time that SP2 is completed and the time when SP2 is released. To ensure you have all the latest hotfixes, be sure to check for the availability of any additional hotfixes.
Windows SharePoint Services and Windows Server 2003 R2
Windows SharePoint Services is now included as a server role in R2 of Windows Server 2003. Installation of Windows SharePoint Services is now available from the following:
Manage Your Server
Configure Your Server Wizard
Windows Components Wizard
Support for IP-bound virtual servers
Previous releases of Windows SharePoint Services did not support assigning static IP addresses to virtual servers extended with Windows SharePoint Services. Instead, it was required that you use host headers and configure all virtual servers with an IP address setting of All Unassigned.
This limitation, as described in Microsoft Knowledge Base article KB 830342: "Soap:Server Exception of Type Microsoft.SharePoint.SoapServer.SoapServerException" Message Appears When You Try to Edit a Portal by Using FrontPage, prevented the ability to host multiple virtual servers on which Secure Sockets Layer (SSL) is enabled on one Web server. In Windows SharePoint Services Service Pack 2, this limitation has been removed, and Windows SharePoint Services now supports assigning a static IP address to a virtual server that has been extended with Windows SharePoint Services.
Note
Windows SharePoint Services SP2 does not support IP-bound virtual servers that were deployed in scalable hosting mode, as described in the Server Farm Scalable Hosting Mode Deployment (Windows SharePoint Services 2.0) topic of the Windows SharePoint Services Administrator's Guide.
Support for advanced extranet configurations
Organizations who want to implement extranet deployments for Windows SharePoint Services often use a reverse proxy and load balancers to protect and manage access to the virtual server front ends. This type of advanced extranet configuration could alter the protocol, host header, or port of the request before it reaches the server running Windows SharePoint Services. Several functions within Windows SharePoint Services generate links and e-mail messages based on the protocol, host header, and port of the request as it is received by the server running Windows SharePoint Services. If the protocol, host header, or port were altered, the wrong URL would be returned to the client.
Windows SharePoint Services, prior to Service Pack 2, does not support the type of advanced extranet configuration described above. Configurations that changed the protocol, host header, or port caused Windows SharePoint Services to return the wrong URL to the client. This is because Windows SharePoint Services generated replies based on the host header (protocol, host, and port) received in the client request.
To demonstrate how this advanced extranet configuration behaved prior to Windows SharePoint Services SP2, the following diagram and example describe the process of a client request that is sent over an SSL connection that is terminated on a reverse proxy server.
.gif "Diagram of URL mapping")
The following steps describe this process:
In SSL termination, the client sends a request to the server using SSL. In this example, the URL is https://adatum.com.
The reverse proxy server converts the request from SSL (HTTPS) to HTTP and passes it to the server running Windows SharePoint Services as https://adatum.com.
Because Windows SharePoint Services received the request as an HTTP request it generates HTTP links, rather than HTTPS (SSL) links on the page that will be returned to the client. In this example, Windows SharePoint Services uses https://adatum.com as the base for the links on the pages it returns.
The reverse proxy server then converts the reply back into HTTPS and forwards it to the client. However, the links on the page within the reply are still HTTP links, which is incorrect for the user because they need to be HTTPS links.
Windows SharePoint Services SP2 solves this problem by providing support for advanced extranet configurations. However, this support is not enabled by default. To enable this support, you must use the following command line operations, which are new with Windows SharePoint Services SP2, to map the incoming URL and substitute the outgoing URL.
Note
Scalable hosting mode is not supported with advanced extranet configurations. For more information, see Server Farm Scalable Hosting Mode Deployment (Windows SharePoint Services 2.0).
Note
Links within alerts work with advanced extranet configurations, only if the user subscribed to the alert after this support was enabled. If the user subscribes to the alert before this feature is configured, the alert will continue to use the wrong URL (HTTP instead of HTTPS) in its links even after advanced extranet configuration support is enabled.
The new command line operations supported in stsadm.exe are:
Addalternatedomain
Addzoneurl
Deletealternatedomain
Deletezoneurl
Enumalternatedomains
Enumzoneurls
The following sections describe these command line operations.
Addalternatedomain
Configures the incoming URL and maps it to a URL zone. For each Web request, Windows SharePoint Services determines the protocol, host header, and port of the request and looks for a matching incoming URL that was previously entered using this command line operation. If a matching incoming URL is found, Windows SharePoint Services then determines which zone will be used to format the outgoing response. Note that you can perform a separate zone mapping for each virtual server.
Example Syntax:
stsadm.exe –o addalternatedomain –url https://sharepoint:1234 –urlzone default –incomingurl https://sharepoint.internal.adatum.com:1234
The following table describes the properties associated with this command line operation.
| Property | Description |
|---|---|
-url |
URL of the virtual server as it is displayed on the Virtual Server List page in the SharePoint Central Administration site. If the virtual server is bound to a specific IP address or to a specific host header in Microsoft Internet Information Services (IIS), you can also use that IP address or host header as the value for this property. .gif "Note") Note:
The value of this property is displayed in the Virtual Server List in SharePoint Central Administration.
|
-urlzone |
Specifies which one of the five zones with which the outgoing URL is associated. The possible values for this property are: default, internet, intranet, extranet, or custom. |
-incomingurl |
URL for any requests that come from the reverse proxy server or client to the Web server. You can map multiple incoming URLs to the same URL zone. |
Note
Windows SharePoint Services uses a linear search to look-up the URL. If too many incoming URLs are added, performance could be affected.
Addzoneurl
Adds a URL to a zone and specifies the URL to return to the client.
Example Syntax:
stsadm.exe –o Addzoneurl –url https://sharepoint:1234 –urlzone default –zonemappedurl https://www.adatum.com
Note
There can be only one outgoing URL per URL zone. This example uses the default URL zone.
Note
Windows SharePoint Services SP2 introduces new behaviors associated with an outgoing URL that is mapped to the default zone. Specifically, when you turn on Self-Service Site Creation for a particular virtual server, the SSSC announcement that is posted to the root site will contain a link to the SSSC page using that outgoing URL that you mapped, rather than the URL listed in the IIS metabase. In addition, when an administrative alert e-mail message is generated, the e-mail message will contain links based on the outgoing URL you mapped, rather than the URL listed in the IIS metabase. This behavior does not apply to outgoing URLs that are mapped to any zone, other than the default zone.
The following table describes the properties associated with this command line operation.
| Property | Description |
|---|---|
-url |
URL of the virtual server as it is displayed on the Virtual Server List page in the SharePoint Central Administration site. If the virtual server is bound to a specific IP address or to a specific host header in IIS, you can also use that IP address or host header as the value for this property. Note:
The value of this property is displayed in the Virtual Server List in SharePoint Central Administration.
|
-urlzone |
Specifies which one of the five zones with which the outgoing URL is associated. The possible values for this property are: default, internet, intranet, extranet, or custom. Note:
You can associate only one outgoing URL with a URL zone for a particular virtual server.
|
-zonemappedurl |
URL used in Web pages or e-mail messages going from the Web server to the reverse proxy server or the client. This URL is the one that can be reached by the end user. This step ensures that the end user sees the correct URL when the URL is returned from the server to the client. |
Deletealternatedomain
Deletes an incoming URL from a URL zone.
Example Syntax:
stsadm.exe –o deletealternatedomain -url https://sharepoint:1234 -incomingurl https://sharepoint.internal.adatum.com:1234
The following table describes the properties associated with this command line operation.
| Property | Description |
|---|---|
-url |
URL of the virtual server as it is displayed on the Virtual Server List page in the SharePoint Central Administration site. If the virtual server is bound to a specific IP address or to a specific host header in IIS, then you can also use that IP address or host header as the value for this property. |
-incomingurl |
URL for any requests that come from the reverse proxy server or client to the Web server. You can map multiple incoming URLs to the same URL zone. Note:
You use this property with the deletealternatedomain operation to specify which incoming URL you want to delete.
|
Deletezoneurl
Deletes an outgoing URL from a URL zone.
Example Syntax:
stsadm.exe –o deletezoneurl -url https://sharepoint:1234 –urlzone default
The following table describes the properties associated with this command line operation.
| Property | Description |
|---|---|
-url |
URL of the virtual server as it is displayed on the Virtual Server List page in the SharePoint Central Administration site. If the virtual server is bound to a specific IP address or to a specific host header in IIS, then you can also use that IP address or host header as the value for this property. |
-urlzone |
Specifies which one of the five zones with which the outgoing URL will be associated. The possible values for this property are: default, internet, intranet, extranet, or custom. Note:
You use this property with the deletezoneurl operation to specify which zone the outgoing URL belongs to that you want to delete.
|
Important
After using command line operations to add or delete URLs, you must restart IIS on each server running Windows SharePoint Services in your server farm for your changes to take effect. To restart IIS, use the following syntax from the command prompt: iisreset.exe /noforce
Enumalternatedomains
Lists the incoming URLs and which URL zones and outgoing URLs they are mapped to.
Example Syntax:
stsadm.exe –o enumalternatedomains –url https://sharepoint:1234
The following table describes the property associated with this command line operation.
| Property | Description |
|---|---|
-url |
URL of the virtual server as it is displayed on the Virtual Server List page in the SharePoint Central Administration site. If the virtual server is bound to a specific IP address or to a specific host header in IIS, then you can also use that IP address or host header as the value for this property. |
Enumzoneurls
Lists the outgoing URLs and which URL zones they are mapped to.
Example Syntax:
stsadm.exe –o enumzoneurls –url https://sharepoint:1234
The following table describes the property associated with this command line operation.
| Property | Description |
|---|---|
-url |
URL of the virtual server as it is displayed on the Virtual Server List page in the SharePoint Central Administration site. If the virtual server is bound to a specific IP address or to a specific host header in IIS, you can also use that IP address or host header as the value for this property. |
Example: Understanding URL Mapping
This example builds on the earlier reverse proxy example, but with URL mapping applied, using the command line operations described earlier. In this example, the administrator uses the addalternatedomain command line operation to map the incoming URL (https://adatum.com) to the Extranet zone and also uses the Addzoneurl command line operation to map the outgoing URL (https://adatum.com) to the Extranet zone.
The following steps and the following figure describe this process:
The client sends a request to the server over SSL by using the https://adatum.com URL.
The reverse proxy server intercepts the request and forwards it to Windows SharePoint Services as https://adatum.com (non SSL).
Windows SharePoint Services looks up the zone associated with this incoming URL to determine the outgoing URL to use, and then generates links on the page (to be returned to the client) using the https://adatum.com URL and sends the reply to the reverse proxy server.
The reverse proxy server then forwards the reply to the client with links on the pages based on the https://adatum.com URL, which is correct for the client.
For more information about advanced extranet configurations, see the Introduction to Reverse Proxy Configurations (Windows SharePoint Services 2.0).
Kerberos authentication enabled by default
Earlier releases of Windows SharePoint Services changed the default authentication method from Kerberos authentication to NTLM. Windows SharePoint Services SP2 does not change the default IIS authentication settings.
The ability to choose either Kerberos authentication or NTLM authentication is available in both the SharePoint Central Administration application and the stsadm.exe command-line utility. You choose an authentication type when you create the SharePoint Central Administration virtual server, extend a virtual server, or extend a virtual server and map it to an existing virtual server.
For the stsadm.exe command line, there is a new optional parameter: exclusivelyusentlm. If this parameter is not specified, then the virtual server is not modified and retains its original authentication configuration which by default is Kerberos authentication.
Support for ASP.NET 2.0
Windows SharePoint Services SP2 now supports both Microsoft ASP.NET 1.1 and Microsoft ASP.NET 2.0. You can also run ASP.NET 1.1 and ASP.NET 2.0 side-by-side on different virtual servers running Windows SharePoint Services SP2, to support solutions or Web Parts that require one version or the other.
Windows SharePoint Services SP2 provides the same feature/functionality when running on ASP.NET 2.0 as it does when running on ASP.NET 1.1. Support for ASP.NET 2.0 is Windows SharePoint Services SP2 does not include integration with the new ASP.NET 2.0 Web Part framework. This means that if you deploy a Web Part built in ASP.NET 2.0 to a virtual server running Windows SharePoint Services SP2, this Web Part will function as a Web form control.
ASP.NET 2.0 restricts the permissions of pages, Web Parts, and controls to run with minimal privileges. For example, code from assemblies in the global assembly cache (GAC) which previously ran with full trust will now run with minimal privileges. This lockdown is incompatible with Windows SharePoint Services and will require you to use the stsadm.exe utility to upgrade the web.config settings in order for Windows SharePoint Services to function properly.
For more information refer to the configuration section of the Windows SharePoint Services Administrator Guide and the Knowledge Base article 894903: You receive a "The Windows SharePoint Services virtual server has not been configured for use with ASP.NET 2.0.xxxxx.0" error message.
If the operating system on which you install Windows SharePoint Services includes only ASP.NET 2.0 (for example, all editions of Windows Server 2003 R2), you can download, install, and register ASP.NET 1.1 with IIS 6.0.
Support for 64-bit editions
To run Windows SharePoint Services SP2 on the 64-bit editions of Windows Server 2003, you must run IIS in 32-bit emulation mode.
When you install Windows SharePoint Services SP2 on the 64-bit editions of Windows Server 2003 R2 from Manage Your Server, the Configure Your Server Wizard, or from Add/Remove Windows Components, you can choose to run IIS in 32-bit emulation mode. You can also change this setting by using the adsutil.vbs utility from the command prompt.
For information about configuring IIS for 32-bit emulation mode, see Configuring IIS for 32-bit emulation mode in Preparing Front-End Web Servers for Windows SharePoint Services 2.0.
When you install Windows SharePoint Services SP2 on 64-bit versions of Windows Server 2003, you can choose either the Typical option (which installs WMSDE SP4 on the server in which you are installing Windows SharePoint Services) or you can choose to use a Microsoft SQL Server 2000 database.
Support for SQL Server 2005
Starting with Windows SharePoint Services Service Pack 2 (SP2), Microsoft SQL Server 2005 is supported. Note however, that Windows SharePoint Services SP2 does not support the database encryption or Snapshot isolation mode features of SQL Server 2005. For information about upgrading from SQL Server 2000 to SQL Server 2005, see the Considerations for Upgrading from SQL Server 2000 to SQL Server 2005 section in Upgrade Considerations (Windows SharePoint Services 2.0). For information about upgrading from WMSDE to SQL Server 2005, see Migrating from WMSDE to SQL Server 2005 (Windows SharePoint Services 2.0).
Support for ADFS
Starting with Windows SharePoint Services Service Pack 2 (SP2), Windows SharePoint Services offers limited support for Active Directory File System (ADFS). All Windows SharePoint Services SP2 features accessed from a Web browser such as Microsoft Internet Explorer fully support ADFS. However, Windows SharePoint Services features accessed from a client application compatible with Windows SharePoint Services, such as Microsoft Office Word, offer limited support for ADFS. For information about the details about what is and isn't supported, see Microsoft Knowledge Base article KB 912492: Windows SharePoint Services and SharePoint Portal Server 2003 Support boundaries for Active Directory Federation Services.