How SharePoint Portal Server Subscriptions Function with Fully Qualified Domain Name (308913)



The information in this article applies to:

  • Microsoft SharePoint Portal Server 2001

This article was previously published under Q308913

SYMPTOMS

When you use the Microsoft SharePoint Portal Server subscriptions feature, you may receive unexpected results. This article describes how SharePoint Portal Server subscriptions function and how you can customize subscriptions as an administrator.

CAUSE

Sharepoint Portal Server's subscriptions are designed to meet a varied set of subscription needs. The Uniform Resource Locators (URLs) in the subscription messages can use the network basic input and output system (NetBIOS) name, the internal fully qualified domain name (FQDN), or the external FQDN of the server. When a subscription is created in SharePoint Portal Server, the subscription information remains consistent for each user, which depends on how the user accessed the server when the subscription was first processed.

If you allow multiple access types (Microsoft Windows Internet Name Service [WINs], FQDN, extranet, and hosting) with SharePoint Portal Server, a subscription that is created that has one access type URL may not function with the others. For example, if you use FQDN without WINS, SharePoint Portal Server cannot automatically choose which form of the server name that is appropriate for a particular e-mail message recipient.

For example, assume you are in one domain and you approve a document by accessing the document through the NetBIOS name. The next person to receive the approval e-mail message is in another domain (either a parent domain or another domain entirely). The link this person receives in the approval e-mail message contains the NetBIOS name for the link. Because the recipient is in another domain, the name used in the link does not resolve and the recipient cannot access the document by clicking the link.

The following are examples of possible scenarios that you may encounter.

Scenario One - WINs and FQDN Incompatibility

If a user connects to http://advworks/workspace and subscribes a team that is geographically disbursed, some team members may receive the following error message when they click the e-mail link:
HTTP 404 - File Not Found
This behavior occurs because the subscription is created by using the WINs name, and this may not function for users outside of the WINS area (usually a domain or location). Users that are outside of the WINS area may need to resolve the computer name by using a FQDN such as http://advworks.Ourcompany.com.

Scenario Two - Users are Outside of the Firewall

If a user connects to http://advworks/Ourworkspace and subscribes to a document or another item while on the corporate Internet, all subscriptions are received with the URL links pointing to http://advworks. User subscriptions may return a "404" error message while they use the extranet.

This behavior may occur if the user is outside of the corporate firewall and accesses the portal by means of the extranet. Subscription links in their e-mail message may point to resources (computer names) that you cannot access through that URL.

RESOLUTION

To resolve these behaviors, use the following methods as appropriate:
  • Educate users about the behavior of subscriptions.
  • Have all users use the same method to access the workspace:
    • All users access the workspace by using a FQDN.
    • All users access the workspace by using the portal site.
    • All users access the workspace by using the extranet.
  • Specify the URL of the server name. SharePoint Portal Server enables administrators to control the form of the name by adding a property to the folder that contains all the workspaces on the server. You can edit this property by using Microsoft Web Storage System Explorer located in the Microsoft Web Storage System Software Development Kit (SDK). The administrator can specify that the URL use the internal FQDN or the external FQDN.

    This method affects all users. If you use this server for Intranet access, all users must authenticate every time they click a subscription message.

    For more information, refer to "Specify the Server URL to Use in E-Mail Notifications" Deploying Microsoft Sharepoint Portal Server 2001 across an Extranet white paper.

    To specify the URL of the server name:

    1. Open Web Storage System Explorer.
    2. Connect to http://NetBIOS_name/SharePoint Portal Server/workspaces:
      • Type username.
      • Type password.
      • In Web Storage System URL, type http://NetBIOS_name/SharePoint Portal Server/workspaces. For example, to connect to a server named AdvWks, type http://AdvWks/SharePoint Portal Server/workspaces.
    3. Click the node for http://NetBIOS_name/SharePoint Portal Server/workspaces to display its schema detail view.
    4. Right-click Detail View, and then click Add Property.
    5. In the Add Property dialog box, follow these steps:
      1. In Name, type urn:schemas-microsoft-com:publishing:ServerUrl

        IMPORTANT: The property name is case sensitive. Type the property name exactly as specified.
      2. In Datatype box, click string.
        • If you always want to use the NetBIOS name in e-mail messages, in the Value box, type http://NetBIOS_name.
        • If you always want to use the internal FQDN in e-mail messages, type http://internal_FQDN.
        • If you always want to use the external FQDN in e-mail messages, type http://external_FQDN.
    6. Click OK.
  • Close Web Storage System Explorer.
  • Restart MSSearch. To do so:
    1. On the Start menu, point to Programs, point to Administrative Tools, and then click Services.
    2. Right-click Microsoft Search, and then click Restart.
    NOTE: If you specify the external FQDN, users on both the intranet and the extranet must use Basic authentication or Secure Sockets Layer (SSL), which one you use depends on how you configure the server. In addition, each user must modify the host's file on their computer, or the network infrastructure must be able to resolve the external name and force the user out to the Internet and back into the intranet through the proxy.

    If you specified the internal FQDN, everyone on the intranet can click any links sent. However, users on the extranet receive an error message when they attempt to click the link in the subscription or approval e-mail message. If you have a small percentage of extranet users, you might choose to specify the internal FQDN so that the majority of your users do not need to modify the host's file.

Modification Type:MinorLast Reviewed:4/25/2005
Keywords:kbprb KB308913