Sun and OracleChannel SunHow to BuyLog InFrançais

Sun Java System Access Manager Policy Agent 2.2 Guide for Microsoft IIS 6.0 With Outlook Web Access 2007/SharePoint 2007
  Rechercher uniquement dans ce livre
Aide pour la recherche
Contenues dans
Trouver plus de documentation
Ressources d'assistance comprises
 Télécharger cet ouvrage au format PDF (1086 Ko)

Appendix A Microsoft Office SharePoint or Outlook Web Access: Deploying Agent for Microsoft IIS 6.0

This appendix provides information that enables you to deploy Agent for Microsoft IIS 6.0 in a manner that provides protection and single sign-on (SSO) to Microsoft Office SharePoint or Outlook Web Access.

Tasks that are specific to Microsoft Office SharePoint or Outlook Web Access are presented in this appendix. The aspects of the installation and configuration of this agent that do not vary when Microsoft Office SharePoint or Outlook Web Access are involved are covered in the appropriate sections, such as Chapter 3, Installing Policy Agent 2.2 for Microsoft IIS 6.0. Therefore, use this appendix in conjunction with other sections of this guide. Cross references throughout this guide, direct you to and from this appendix as necessary.

This appendix contains the following sections:

Microsoft Office SharePoint and Outlook Web Access: Installing Agent for Microsoft IIS 6.0

You can use Agent for Microsoft IIS 6.0 to provide users with authenticated access to beyond that of web sites. Specifically, you can use this agent to protect Microsoft Office SharePoint or Outlook Web Access. However, to protect these particular resources additional configuration is required. That is to say, you must configure Access Manager as described in the instructions that follow.

Microsoft Office SharePoint and Outlook Web Access: Preparing to Install the Agent

This section focuses on pre-installation steps required for Microsoft Office SharePoint and Outlook Web Access. First, you need to perform the pre-installation steps that apply generally to Agent for Microsoft IIS 6.0, then you need to perform the pre-installation steps specific to Microsoft SharePoint and Outlook Web Access.

To Prepare to Install the Agent

Implement the general pre-installation steps regarding Agent for Microsoft IIS 6.0 as covered in Preparing To Install Agent for Microsoft IIS 6.0 before completing the task that follows.

ProcédureMicrosoft SharePoint and Outlook Web Access: To Prepare for Installation

The steps described in this task are required after you perform the pre-installation steps for the basic installation on Microsoft IIS 6.0 as described in Preparing To Install Agent for Microsoft IIS 6.0.

These additional pre-installation steps are necessary to deploy a post-authentication module on Access Manager. In order to achieve SSO with Microsoft SharePoint or Outlook Web Access using Agent for Microsoft IIS 6.0, a post-authenitcation module is required to be deployed on Access Manager.

Perform the steps in this task on the Access Manager host.

Before You Begin
Caution – Caution –

When installing Agent for Microsoft IIS 6.0 to protect Outlook Web Access, prior to installing the agent, ensure that the user repositories in Access Manager and Microsoft Exchange Server are synchronized.

For Outlook Web Access 2007, this synchronization can be avoided if the Active Directory instance used by Exchange Server is used as the Access Manager user repository, using the Access Manager LDAP v3 plug-in.

Note –

This info serves as a reminder about the compatibility of this agent with versions of Access Manager when the agent is deployed to protect Microsoft SharePoint or Outlook Web Access. The following Access Manager versions are supported:

  • Access Manager 7.0 series from Patch 7 forward

  • Access Manager 7.1 series from Patch 1 forward

For more information about the compatibility of Agent for Microsoft IIS 6.0 with versions of Access Manager, see Compatibility of Policy Agent 2.2 With Specific Access Manager Versions.

The following information about Access Manager is helpful for this task:

AccessManager-base represents the Access Manager base installation directory. On Solaris systems, the default base installation directory is /opt/SUNWam.

The following is the default location of the AMConfig.properties file:

/etc/opt/SUNWam/config

  1. Set the JAVA_HOME variable to the location in which JDK binaries are installed.

  2. Execute DESgenKey.class as follows:

    # java -classpath am_sdk.jarPath com.sun.identity.common.DESGenKey

    where am_sdk.jarPath is a place holder for the path to the am_sdk.jar file.

    For example:

    java -classpath /opt/SUNWam/lib/am_sdk.jar com.sun.identity.common.DESGenKey

Key ==> cIlz47oZBJs=

    Executing the DESgenKey.class returns a string output.

    Note –

    The am_sdk.jar file, which is an Access Manager JAR file, is typically found in the lib folder of the Access Manager installation, such as /opt/SUNWam/lib in a package installation or sun/webserver7/https-hostname/web-app/hostname/amserver/WEB-INF/lib in single war file installation.

  3. Add the string produced in the previous step to a newly created text file as described in the substeps that follow.

    1. Copy the string produced in the previous step.

    2. Create a file, which for this example is named des_key.txt, in a directory of your choosing.

      The des_key.txt name is used in this guide as an example. Name the file differently if you wish.

    3. Save the copied string in the des_key.txt file.

  4. Configure the com.sun.am.replaypasswd.key property in the AMConfig.properties configuration file as described in the substeps that follow.

    1. Open the AMConfig.properties configuration file.

    2. Add the following property to the file:

      com.sun.am.replaypasswd.key

    3. Copy the string from the des_key.txt file.

    4. Add the copied string as the value of the com.sun.am.replaypasswd.key property.

      For example, if the string in the des_key.txt file is wuqUJyr=5Gc=, then the new property would be set as follows:

      com.sun.am.replaypasswd.key = wuqUJyr=5Gc=

  5. Configure a property specific to Microsoft Office SharePoint or Outlook Web Access in the AMConfig.properties file as described in the substeps that follow.

    1. Add the respective property and corresponding value to the file as indicated:

      • Microsoft Office SharePoint:

        For SharePoint, an optional property allows you to set an attribute in the Access Manager repository LDAP other than uid that allows users to log in to Access Manager to in turn log in to SharePoint:

        com.sun.am.sharepoint_login_attr_name = SharePoint-login-value

        where,SharePoint-login-value is a placeholder that represents an attribute in the user repository used by SharePoint to authenticate.

        For example:

        com.sun.am.sharepoint_login_attr_name = displayName

        For example purposes, a user has a uid of ak1234 and a displayName of andy. In this example, the user logs in to Access Manager using the uid (ak1234). However, the SharePoint repository has a record for andy, not ak1234, and the user uses andy to log in to the SharePoint application.

        Therefore, this property maps ak1234 to andy as the user accesses the SharePoint application after authenticating with Access Manager.

        In other words, this property provides a method for mapping any user attribute used by SharePoint to authenticate to the attribute used by Access Manager to authenticate.

      • Outlook Web Access

        Add the following property and value if you are installing the agent for Outlook Web Access.

        com.sun.am.iis_owa_enabled = true

    2. Save and close the AMConfig.properties file.

  6. Restart Access Manager.

  7. Deploy the post-authentication plug-in, ReplayPasswd, as described in the substeps that follow.

    This step requires the use of Access Manager Console.

    1. Log in to Access Manager as amadmin.

    2. With the Access Control tab selected, click the name of the realm you wish to configure.

    3. Click the Authentication tab.

    4. Click Advanced Properties.

      The Advanced Properties button is in the General section.

    5. Scroll down to the Authentication Post Processing Classes field.

    6. Add the text related to Authentication Post Processing Classes in the manner appropriate for the Access Manager version you are using:

      • Access Manager 7.0 series from Patch 7 forward

        For these patches of the Access Manager 7.0 series, execute the following substeps:

        1. In the Authentication Post Processing Classes field, enter the required text:

          com.sun.identity.authentication.spi.ReplayPasswd

      • Access Manager 7.1 series from Patch 1 forward

        For these patches of the Access Manager 7.1 series, execute the following substeps:

        1. In the Authentication Post Processing Classes section, enter the required text:

          com.sun.identity.authentication.spi.ReplayPasswd

        2. Click Add.

    7. Click Save.

    8. Click Log Out to log out of the Access Manager Console.

  8. Verify the deployment of the post-authentication plug-in, ReplayPasswd, as described in the substeps that follow.

    1. Stop Access Manager.

    2. Access the AMConfig.properties configuration file.

    3. Note the value of the following property before changing it to message, as indicated:

      com.iplanet.services.debug.level = message

      You must change this value back to its original value at the completion of this step.

    4. Save and close the file.

    5. Start Access Manager.

    6. Log in to Access Manager Console.

      Again use amadmin.

    7. Click Log Out to immediately log out of the Access Manager Console.

    8. Change directories to the Access Manager debug log files.

      The default location of the debug log files is /var/opt/SUNWam/debug.

    9. Verify the existence of a file named ReplayPasswd.

      The existence of this file indicates the successful deployment of the post-authentication plug-in.

    10. Reset the debug value to its original value.

    11. Restart Access Manager.

Microsoft Office SharePoint and Outlook Web Access: Installing the Agent

Once you have completed the preceding pre-installation steps, perform the actual installation as described in Installing Agent for Microsoft IIS 6.0.

Microsoft Office SharePoint and Outlook Web Access: Configuring the Agent

You should come to this section after you have installed the agent as described in Installing Agent for Microsoft IIS 6.0.

Perform the tasks that follow if you are installing Agent for Microsoft IIS 6.0 to protect Microsoft Office SharePoint or Outlook Web Access.

ProcédureMicrosoft Office SharePoint and Outlook Web Access: To Configure the Agent

  1. Verify that settings are correct in the defaultConfig file.

    If settings are incorrect, edit as required.

    For this task, the defaultConfig file is a place holder that you must replace with the name of the agent configuration file created in To Create Configuration Files: Agent for Microsoft IIS 6.0.

  2. Change to the following directory:

    PolicyAgent-base\bin

  3. Issue the appropriate command (be aware that the command is case sensitive):

    • Outlook Web Access

      cscript OwaAdmin.vbs -config defaultConfig

    • Microsoft Office SharePoint

      cscript SPAdmin.vbs -config defaultConfig
      OwaAdmin.vbs & SPAdmin.vbs

      VB scripts that can be used to install the required ISAPI filter. The OwaAdmin.vbs script installs the ISAPI filter amowafilter64.dll while the SPAdmin.vbs script installs the ISAPI filter amsharepointfilter32.dll.

      -config

      The option that allows the output to be used to configure Agent for Microsoft IIS 6.0 to protect Microsoft Office SharePoint or Outlook Web Access.

  4. Accept the default when presented with the following prompt:

    Enter the Agent Resource File Name [IIS6Resource.en]:

    The preceding prompt appears in the following context:

    Microsoft (R) Windows Script Host Version 5.6
Copyright (C) Microsoft Corporation 1996-2001. All rights reserved.

Copyright c 2004 Sun Microsystems, Inc. All rights reserved
Use is subject to license terms

Enter the Agent Resource File Name [IIS6Resource.en]:

    After you accept the default, a message such as the following should appear:

    Creating the Agent Config Directory
Creating the AMAgent.properties File
Updating the Windows Product Registry
Completed Configuring the IIS 6.0 Agent
Troubleshooting

If you experience difficulty after issuing the OwaAdmin.vbs script or the SPAdmin.vbs script, see the related troubleshooting symptom, Troubleshooting Symptom 3.

ProcédureMicrosoft SharePoint and Outlook Web Access: To Edit the Agent Properties File

This section applies to both Microsoft Office SharePoint and Outlook Web Access. For the task presented in this section, you must edit the web agent AMAgent.properties configuration file.

If you are installing this agent to protect Outlook Web Access, more configuration is required, some of which also involves editing the web agent AMAgent.properties configuration file. Those instructions are presented in Outlook Web Access Only: Configuring Agent for Microsoft IIS 6.0.

The instructions provided in this section are similar to the instructions for adding the property, com.sun.am.replaypasswd.key to the AMConfig.properties configuration file as described in Microsoft SharePoint and Outlook Web Access: To Prepare for Installation.

The same property and respective value added to the AMConfig.properties configuration file must now be added to the web agent AMAgent.properties configuration file.

For information about the location of the web agent AMAgent.properties configuration file, see Locating the Web Agent AMAgent.properties Configuration File.

  1. Open the web agent AMAgent.properties configuration file.

  2. Add the following property to the file:

    com.sun.am.replaypasswd.key

  3. Copy the string from the des_key.txt file.

    For more information on the des_key.txt file, see Microsoft SharePoint and Outlook Web Access: To Prepare for Installation.

  4. Add the copied string as the value of the com.sun.am.replaypasswd.key property.

    For example, if the string in the des_key.txt file is wuqUJyr=5Gc=, then the new property would be set as follows:

    com.sun.am.replaypasswd.key = wuqUJyr=5Gc=

  5. (Conditional) If you are configuring the agent for Microsoft SharePoint, save and close the web agent AMAgent.properties configuration file.

Next Steps

At this point, the next task to be implemented varies depending on if you are deploying this agent to protect Microsoft Office SharePoint or Outlook Web Access.

If you are installing this agent to protect Microsoft Office SharePoint, continue to the next section, Microsoft Office SharePoint Only: Configuring Agent for Microsoft IIS 6.0, to complete an additional configuration task specific to Microsoft Office SharePoint.

If you are installing this agent to protect Outlook Web Access, skip to Outlook Web Access Only: Configuring Agent for Microsoft IIS 6.0, to complete additional configuration tasks specific to Outlook Web Access.

ProcédureMicrosoft Office SharePoint and Outlook Web Access: To Add a New System Environment Variable for NSPR Threads

This is a required task. The system environment variable added in this task is used internally by the NSPR libraries.

  1. Add a new System environment variable for NSPR threads as follows:


    NSPR_NATIVE_THREADS_ONLY

    The value is as follows:

    1

  2. Restart the Microsoft IIS 6.0 server.

Microsoft Office SharePoint Only: Configuring Agent for Microsoft IIS 6.0

If you are installing Agent for Microsoft IIS 6.0 to protect Microsoft Office SharePoint, tasks specific to Microsoft Office SharePoint are required. This section provides those configuration instructions in a series of tasks.

ProcédureMicrosoft Office SharePoint: To Enable the Authentication Method to Basic

To protect Microsoft Office SharePoint with this agent you must ensure that the authentication method for the Microsoft IIS 6.0 Server is set to Basic authentication as described in this task.

  1. As an administrator, log in to Windows 2003 Server where Microsoft Office SharePoint is running.

  2. In the Microsoft Windows Start menu, choose run.

  3. Type the following: inetmgr

  4. Click OK.

  5. Expand the local computer.

  6. Expand the Web Sites folder.

  7. Right click the SharePoint site that you are protecting with the agent.

    The agent-protected SharePoint site is typically the site using port 80 (SharePoint — 80).

  8. In the options list, click Properties.

    The Default Web Site Properties dialog box appears.

  9. Select the Directory Security tab.

  10. Click Edit in the Authentication and access control section.

  11. Select Basic authentication in the Authenticated access section.

    Ensure that no other authentication option is checked.

  12. Click OK.

  13. Click OK again to close the Web site properties.

ProcédureMicrosoft Office SharePoint: To Modify the signout.aspx File to Properly Handle the Logout Process

  1. Back up the signout.aspx file.

    This file is typically available in the following directory:

    C:\Program Files\Common Files\Microsoft Shared\web server extensions\
12\TEMPLATE\LAYOUTS

  2. Open the signout.aspx file.

  3. Replace the lines of code indicated within this step.

    Original Code Snippet (replace this code snippet):
    function _spBodyOnLoad()
[
   try
   [
      document.execCommand("ClearAuthenticationCache");
   ]
   catch (e) []
   window.close();
]
    Replacement Code Snippet (Use this code snippet to replace the original code snippet):
    function _spBodyOnLoad()
[
   window.location="https://amHost:amPort/amserver/UI/Logout";
]

    Where amHost and amPort are place holders that you must replace with the fully qualified domain name (FQDN) host name and port number, respectively, of the Access Manager server.

  4. Save and close the signout.aspx file.

  5. Restart the Microsoft IIS 6.0 server using the iisreset command.

Next Steps

Now you can verify the installation of the agent as described in Microsoft Office SharePoint and Outlook Web Access: Verifying a Successful Agent Installation.

Outlook Web Access Only: Configuring Agent for Microsoft IIS 6.0

If you are installing Agent for Microsoft IIS 6.0 to provide SSO to Outlook Web Access, tasks specific to Outlook Web Access are required. This section provides those configuration instructions in a series of tasks.

ProcédureOutlook Web Access: To Edit the Agent Properties File

Before You Begin

Open the web agent AMAgent.properties configuration file if it is not already open.

  1. In the web agent AMAgent.properties configuration file, set the following property to false as shown:


    com.sun.am.notification.enable = false

  2. Add the following property with its value set to true as indicated:


    com.sun.am.policy.agents.config.iis.owa_enabled = true

  3. Add the property illustrated in this step with its value set to the URL of a local idle session timeout page.

    The value for the property in the example that follows represents the location of a local idle session timeout page (timeout.aspx). However, the instructions for creating the local idle session timeout page are presented in the task that follows: Outlook Web Access: To Create a Local Idle Session Timeout Page. You can either complete that task first or set this property now by choosing a name at this time for the local idle session timeout page and its full path.

    Example Property Setting: 


    com.sun.am.policy.agents.config.iis.owa_enabled_session_timeout_url = 
https://agentHost.domain-name:444/timeout.aspx

    The timeout.aspx page is an example timeout page name, which is used in this guide in reference to the timeout page used with Agent for Microsoft IIS 6.0 when protecting Outlook Web Access. However, timeout.aspx is only an example. You might chose to use a different page name.

  4. Save and close the web agent AMAgent.properties configuration file.

ProcédureOutlook Web Access: To Create a Local Idle Session Timeout Page

This task consists of steps that vary in specificity. These steps are to be performed on the Microsoft IIS 6.0 Server. The purpose of this task is to create a local web site to redirect timeout requests to the Access Manager timeout page.

  1. Create a new virtual server (a different web site) in the Microsoft IIS 6.0 Server administration console.

  2. For the new virtual server, create a corresponding application pool with a new document folder.

    An example name for this folder is C:\Inetpub\test.

    While the preceding example folder name is used throughout this task, it is only an example. You might chose to use a different name.

  3. Install SSL on the newly created web site.

    Tip –

    • Ensure that this web site is accessible from a browser.

    • Configure the port number.

      An example port number for this port is 444. However, 444 is only an example. You might chose to use a different port number.

    • Ensure that the Outlook Web Access server runs on a different port (therefore, for the example used in this task, not port 444).

  4. Ensure that the web site is enabled to run scripts and executable files as described in the substeps that follow:

    1. As an administrator, log in to Windows 2003 Server where Outlook Web Access Server is running.

    2. In the Microsoft Windows Start menu, choose run.

    3. Type the following: inetmgr.

    4. Click OK.

    5. Expand the local computer.

    6. Expand the Web Sites folder.

    7. Right-click Default Web Site.

      An options list appears.

    8. In the options list, click Properties.

      The Default Web Site Properties dialog box appears.

    9. Select the Home Directory tab.

    10. Under the Application settings section, in the Execute permissions drop down list, select Scripts and Executables.

  5. Create a .aspx page, such as timeout.aspx, in the folder C:\Inetpub\test.

    As explained previously, timeout.aspx is only an example. However, ensure that you use the same name for this page as used in Outlook Web Access: To Edit the Agent Properties File.

  6. Add the markup information provided in this step to the timeout.aspx file, editing the place holders as appropriate.

    In the markup information provided in this step, the following place holders apply:

    amHost

    A place holder that you must replace with the name of the host machine on which Access Manager is running.

    amHost.domain-name

    The fully qualified domain name of the Access Manager host machine.

    agentHost

    A place holder that you must replace with the name of the host machine (or the alias name, if an alias name is used instead of the actual host name) on which the agent is running.

    agentHost.domain-name

    A place holder that you must replace with the fully qualified domain name of the agent host machine.

     <%@ Page language="c#" AutoEventWireup="false"  %>

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> 

<html xmlns="http://www.w3.org/1999/xhtml">
<head>

<%
string cookieValue="";
if (Request.Cookies["UserContext"] != null)
{
   cookieValue=Request.Cookies["UserContext"].Value;
   HttpCookie myCookie = new HttpCookie("UserContext",cookieValue);
   myCookie.Expires = DateTime.Now.AddDays(-1d);
   myCookie.Path = "/";
   Response.Cookies.Add(myCookie);
}

%>

<script language="javascript">
   function RefreshParent()
   {
      gotoUrl="https://amHost.domain-name:443/amserver/UI/Logout?goto=
https://agentHost.domain-name:443/owa";
                window.location.href = gotoUrl;
                window.parent.location.href = gotoUrl;
                window.parent.parent.location.href = gotoUrl;
           window.opener.parent.location.href = gotoUrl;
   }

   function CallRefresh()
   {
      RefreshParent();
      if(!window.close())
      {
         window.close();
      }
   }
</script>


</head>
<body onload="javascript:CallRefresh()">
</body>
</html>

  7. Save and close the timeout.aspx file.

ProcédureOutlook Web Access: To Modify the logoff.aspx File to Properly Handle the Logout Process

  1. Back up the file C:\Program Files\Microsoft\Exchange Server\ClientAccess\Owa\auth\logoff.aspx.

  2. Retrieve the cookie domain name as described in the substeps that follow.

    The cookie domain name you are retrieving in this step is required in the next step for the logoff.aspx file.

    1. Log in to Access Manager as amadmin.

    2. Select the Configuration tab.

    3. Scroll as necessary to click Platform under the System Properties section.

    4. In the Current Values list, take note of name of the appropriate cookie domain.

      The Current Values list is in the Cookie Domains section. The domain name you need to record for later use is the domain where Microsoft IIS 6.0 Server is installed and running.

  3. Replace the contents of the logoff.aspx file with the markup information provided in this step.

    In the markup information that follows, amHost.domain-name and agentHost.domain-name are place holders described in the task Outlook Web Access: To Create a Local Idle Session Timeout Page. In this case, cookie-domain is a place holder that you must replace with the cookie domain name retrieved in the previous step.

    <%@ Page language="c#" AutoEventWireup="false"  %>

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> 

<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<%
string str="owa";
if (Request.Cookies["owaAuthCookie"] != null)
{
    HttpCookie myCookie = new HttpCookie("owaAuthCookie","amOwaValue");
    myCookie.Expires = DateTime.Now.AddDays(-1d);
    myCookie.Domain = ".cookie-domain";
    myCookie.Path = "/";
    Response.Cookies.Add(myCookie);
}
%>
<meta http-equiv="Refresh" content="0;url= 
https://amHost.domain-name:443/amserver/UI/Logout?goto=
https%3A%2F%2FagentHost.domain-name%3A443%2F<%=str%>%2F">
</head>
</html>

  4. Save and close the logoff.aspx file.

Next Steps

Now you can verify the installation of the agent as described in Microsoft Office SharePoint and Outlook Web Access: Verifying a Successful Agent Installation.

Microsoft Office SharePoint and Outlook Web Access: Verifying a Successful Agent Installation

This section describes the methods for verifying the installation of Agent for Microsoft IIS 6.0 to protect Microsoft Office SharePoint and Outlook Web Access. Refer to the section that applies to your deployment.

Microsoft Office SharePoint

If the agent is installed correctly, an attempt to access a protected resource results in the presentation of the Access Manager login page. Entering proper credentials at this point, successfully authenticates users, and if they have the appropriate SharePoint access rights to the resource, they are granted access. Then when users attempt to access any other application secured by the same Access Manager server, they are not prompted for authentication. They are granted or denied access to the resource depending on defined policies.

Outlook Web Access

If the agent is installed correctly, an attempt to access the Outlook Web Access URL, which is https://agentHost.domain-name/owa, results in the presentation of the Access Manager login page. Entering proper credentials at this point, successfully authenticates users and provides access to the Outlook Web Access inbox. Then when users attempt to access any other application secured by the same Access Manager server, they are not prompted for authentication. They are granted or denied access to the resource depending on defined policies.

Microsoft Office SharePoint and Outlook Web Access: Deactivating and Reactivating the Access Manager Policy Filter

If you decide to temporarily stop using Access Manager for SSO from Microsoft Office SharePoint or Outlook Web Access to other applications, you can accomplish this by deactivating the policy filter. Therefore, uninstalling the agent would not be necessary. If you are interested in uninstalling the agent instead, see Chapter 7, Uninstalling Policy Agent 2.2 for Microsoft IIS 6.0. You can deactivate the policy filter from the Microsoft IIS 6.0 Server. The assumption is that you would reactivate the filter later.

In this guide, the tasks for deactivating and reactivating the policy filter are covered for Microsoft Office SharePoint and Outlook Web Access separately as follows:

Be certain to use the appropriate instructions depending on your specific deployment.

Microsoft Office SharePoint: Deactivating and Reactivating the Access Manager Policy Filter

Two tasks follow: one for deactivating the policy filter and one for reactivating it.

ProcédureMicrosoft Office SharePoint: To Deactivate the Access Manager Policy Filter

  1. As an administrator, log in to Windows 2003 Server where Microsoft Office SharePoint is running.

  2. In the Microsoft Windows Start menu, choose run.

  3. Type the following: inetmgr.

  4. Click OK.

  5. Expand the local computer.

  6. Expand the Web Sites folder.

  7. Right-click Default Web Site.

    An options list appears.

  8. In the options list, click Properties.

    The Default Web Site Properties dialog box appears.

  9. Click the ISAPI Filters tab.

  10. Click the amspfilter filter.

  11. Click Remove.

    Caution – Caution –

    After removing the filter manually, as described in this task, if you want to reactivate it or if you want to unconfigure the agent by issuing the SPAdmin.vbs -unconfig command, you must first add the filter back manually (see Microsoft Office SharePoint: To Reactivate the Access Manager Policy Filter) with the same filter name, for example amspfilter. Otherwise, an error will be issued.

  12. Click OK.

  13. Restart the Microsoft IIS 6.0 Server.

    A method for restarting this server is to enter iisreset in a command window.

ProcédureMicrosoft Office SharePoint: To Reactivate the Access Manager Policy Filter

  1. As an administrator, log in to Windows 2003 Server where Microsoft Office SharePoint is running.

  2. In the Microsoft Windows Start menu, choose run.

  3. Type the following: inetmgr.

  4. Click OK.

  5. Expand the local computer.

  6. Expand the Web Sites folder.

  7. Right click Default Web Site.

    An options list appears.

  8. In the options list, Click Properties.

    The Default Web Site Properties dialog box appears.

  9. Click the ISAPI Filters tab.

  10. Click Add.

  11. In the Filter Name field, enter the following: amspfilter

  12. In the Executable field, enter PolicyAgent-base\bin\amsharepointfilter32.dll.

  13. Click OK.

Outlook Web Access: Deactivating and Reactivating the Access Manager Policy Filter

Two tasks follow: one for deactivating the policy filter and one for reactivating it.

ProcédureOutlook Web Access: To Deactivate the Access Manager Policy Filter

  1. As an administrator, log in to Windows 2003 Server where Outlook Web Access Server is running.

  2. In the Microsoft Windows Start menu, choose run.

  3. Type the following: inetmgr.

  4. Click OK.

  5. Expand the local computer

  6. Expand the Web Sites folder.

  7. Right click Default Web Site.

    An options list appears.

  8. In the options list, click Properties.

    The Default Web Site Properties dialog box appears.

  9. Click the ISAPI Filters tab.

  10. Click the amowafilter filter.

  11. Click Remove.

    Caution – Caution –

    After removing the filter manually, as described in this task, if you want to reactivate it or if you want to unconfigure the agent by issuing the OwaAdmin -unconfig command, you must first add the filter back manually (see Outlook Web Access: To Reactivate the Access Manager Policy Filter) with the same filter name, for example amowafilter. Otherwise, an error will be issued.

  12. Click OK.

  13. Restart the Microsoft IIS 6.0 Server.

ProcédureOutlook Web Access: To Reactivate the Access Manager Policy Filter

  1. As an administrator, log in to Windows 2003 Server where Outlook Web Access Server is running.

  2. In the Microsoft Windows Start menu, choose run.

  3. Type the following: inetmgr.

  4. Click OK.

  5. Expand the local computer.

  6. Expand the Web Sites folder.

  7. Right click Default Web Site.

    An options list appears.

  8. In the options list, click Properties.

    The Default Web Site Properties dialog box appears.

  9. Click the ISAPI Filters tab.

  10. Click Add.

  11. Enter amowafilter in the Filter Name field

    Caution – Caution –

    Putting a different name here will cause OwaAdmin -unconfig to fail during uninstallation.

  12. Enter PolicyAgent-base\bin\amowafilter64.dll in the Executable field.

  13. Click OK.

  14. Click Apply.

  15. Click OK again

  16. Restart Microsoft IIS 6.0 Server using the iisreset command.

Microsoft Office SharePoint and Outlook Web Access: Unconfiguring and Uninstalling the Agent

If you no longer require Agent for Microsoft IIS 6.0 to protect Microsoft Office SharePoint or Outlook Web Access, you can unconfigure the agent. Be aware that to uninstall the agent, you must first unconfigure it.

The task that follows in this section is similar to the task in Agent Unconfiguration for Microsoft IIS 6.0. However, this task is specific to deployments where Agent for Microsoft IIS 6.0 protects Microsoft Office SharePoint or Outlook Web Access. Though the unconfiguration task varies, the uninstallation task does not. The uninstallation task that applies to all deployments of this agent is as follows Agent Uninstallation for Microsoft IIS 6.0.

ProcédureMicrosoft Office SharePoint and Outlook Web Access: To Unconfigure Agent for Microsoft IIS 6.0

  1. Change to the directory PolicyAgent-base\bin

  2. Run the appropriate VB script to unconfigure the agent (be aware that the command is case sensitive):

    • Outlook Web Access

      cscript OwaAdmin.vbs -unconfig defaultConfig

    • Microsoft Office SharePoint

      cscript SPAdmin.vbs -unconfig defaultConfig
      OwaAdmin.vbs & SPAdmin.vbs

      VB scripts that can be used to uninstall the ISAPI filters. The OwaAdmin.vbs script uninstalls amowafilter64.dll while theSPAdmin.vbs script uninstalls amsharepointfilter32.dll.

      -unconfig

      The option that allows the output to be used to unconfigure the agent from protecting Microsoft Office SharePoint or Outlook Web Access.

      defaultConfig

      A place holder for the name of the agent configuration file created previously as described in To Create Configuration Files: Agent for Microsoft IIS 6.0.

      Each of the preceding scripts unconfigures the agent and displays the following message:


          Microsoft (R) Windows Script Host Version 5.6
    Copyright (C) Microsoft Corporation 1996-2001. All rights reserved.

    Copyright c 2004 Sun Microsystems, Inc. All rights reserved
    Use is subject to license terms

    Enter the Agent Resource File Name [IIS6Resource.en] :

    Removing the Agent Config Directory
    Removing the entries from Windows Product Registry
    Unloading the IIS 6.0 Agent
    Completed Unconfiguring the IIS 6.0 Agent

      The unconfiguration does the following:

      • Removes the agent configuration directory

      • Removes the entries from Windows registry.

      • Removes the wild card application mappings in Microsoft IIS 6.0.

  3. Accept the default when presented with the following prompt:

    Enter the Agent Resource File Name [IIS6Resource.en]:

  4. Change to the following directory: C:\Agents\.

  5. Remove the appropriate directory depending on the version of this agent.

    • The 64–bit Agent for IIS 6.0 version & the OWA 2007 version

      For these two versions of the agent, remove the following directory:

      iis_v6_x64_WINNT_agent

    • The SharePoint 2007 version

      For this version of the agent, remove the following directory:

      iis_v6_WINNT_agent

  6. Restart the Microsoft IIS 6.0 Server.

Next Steps

Once you have completed the unconfiguration process, see Agent Uninstallation for Microsoft IIS 6.0 to uninstall the agent.

Microsoft Office SharePoint and Outlook Web Access: Tasks Not Specified

Refer to the respective sections of this guide to perform tasks that are not specifically described or referenced in this appendix since such sections apply to all deployments of Agent for Microsoft IIS 6.0, including Microsoft Office SharePoint and Outlook Web Access deployments. For example, see Uninstallation of Agent for Microsoft IIS 6.0 to uninstall Agent for Microsoft IIS 6.0 whether Microsoft Office SharePoint or Outlook Web Access are involved in the deployment or not.