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
Microsoft Office SharePoint and Outlook Web Access: Configuring the Agent
Microsoft Office SharePoint Only: Configuring Agent for Microsoft IIS 6.0
Outlook Web Access Only: Configuring Agent for Microsoft IIS 6.0
Microsoft Office SharePoint and Outlook Web Access: Verifying a Successful Agent Installation
Microsoft Office SharePoint and Outlook Web Access: Unconfiguring and Uninstalling the Agent
Microsoft Office SharePoint and Outlook Web Access: Tasks Not Specified
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.
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.
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.
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.
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.
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
Set the JAVA_HOME variable to the location in which JDK binaries are installed.
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.
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.
Add the string produced in the previous step to a newly created text file as described in the substeps that follow.
Configure the com.sun.am.replaypasswd.key property in the AMConfig.properties configuration file as described in the substeps that follow.
Open the AMConfig.properties configuration file.
Add the following property to the file:
com.sun.am.replaypasswd.key
Copy the string from the des_key.txt file.
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=
Configure a property specific to Microsoft Office SharePoint or Outlook Web Access in the AMConfig.properties file as described in the substeps that follow.
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
Save and close the AMConfig.properties file.
Restart Access Manager.
Deploy the post-authentication plug-in, ReplayPasswd, as described in the substeps that follow.
This step requires the use of Access Manager Console.
Log in to Access Manager as amadmin.
With the Access Control tab selected, click the name of the realm you wish to configure.
Click the Authentication tab.
Click Advanced Properties.
The Advanced Properties button is in the General section.
Scroll down to the Authentication Post Processing Classes field.
Add the text related to Authentication Post Processing Classes in the manner appropriate for the Access Manager version you are using:
Click Save.
Click Log Out to log out of the Access Manager Console.
Verify the deployment of the post-authentication plug-in, ReplayPasswd, as described in the substeps that follow.
Stop Access Manager.
Access the AMConfig.properties configuration file.
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.
Save and close the file.
Start Access Manager.
Log in to Access Manager Console.
Again use amadmin.
Click Log Out to immediately log out of the Access Manager Console.
Change directories to the Access Manager debug log files.
The default location of the debug log files is /var/opt/SUNWam/debug.
Verify the existence of a file named ReplayPasswd.
The existence of this file indicates the successful deployment of the post-authentication plug-in.
Reset the debug value to its original value.
Restart Access Manager.
Once you have completed the preceding pre-installation steps, perform the actual installation as described in Installing Agent for Microsoft IIS 6.0.
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.
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.
Change to the following directory:
PolicyAgent-base\bin
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
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.
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.
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
If you experience difficulty after issuing the OwaAdmin.vbs script or the SPAdmin.vbs script, see the related troubleshooting symptom, Troubleshooting Symptom 3.
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.
Open the web agent AMAgent.properties configuration file.
Add the following property to the file:
com.sun.am.replaypasswd.key
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.
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=
(Conditional) If you are configuring the agent for Microsoft SharePoint, save and close the web agent AMAgent.properties configuration file.
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.
This is a required task. The system environment variable added in this task is used internally by the NSPR libraries.
Add a new System environment variable for NSPR threads as follows:
NSPR_NATIVE_THREADS_ONLY |
The value is as follows:
1
Restart the Microsoft IIS 6.0 server.
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.
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.
As an administrator, log in to Windows 2003 Server where Microsoft Office SharePoint is running.
In the Microsoft Windows Start menu, choose run.
Type the following: inetmgr
Click OK.
Expand the local computer.
Expand the Web Sites folder.
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).
In the options list, click Properties.
The Default Web Site Properties dialog box appears.
Select the Directory Security tab.
Click Edit in the Authentication and access control section.
Select Basic authentication in the Authenticated access section.
Ensure that no other authentication option is checked.
Click OK.
Click OK again to close the Web site properties.
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
Open the signout.aspx file.
Replace the lines of code indicated within this step.
function _spBodyOnLoad() [ try [ document.execCommand("ClearAuthenticationCache"); ] catch (e) [] window.close(); ]
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.
Save and close the signout.aspx file.
Restart the Microsoft IIS 6.0 server using the iisreset command.
Now you can verify the installation of the agent as described in Microsoft Office SharePoint and Outlook Web Access: Verifying a Successful Agent Installation.
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.
Open the web agent AMAgent.properties configuration file if it is not already open.
In the web agent AMAgent.properties configuration file, set the following property to false as shown:
com.sun.am.notification.enable = false |
Add the following property with its value set to true as indicated:
com.sun.am.policy.agents.config.iis.owa_enabled = true |
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.
Save and close the web agent AMAgent.properties configuration file.
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.
Create a new virtual server (a different web site) in the Microsoft IIS 6.0 Server administration console.
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.
Install SSL on the newly created web site.
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).
Ensure that the web site is enabled to run scripts and executable files as described in the substeps that follow:
As an administrator, log in to Windows 2003 Server where Outlook Web Access Server is running.
In the Microsoft Windows Start menu, choose run.
Type the following: inetmgr.
Click OK.
Expand the local computer.
Expand the Web Sites folder.
Right-click Default Web Site.
An options list appears.
In the options list, click Properties.
The Default Web Site Properties dialog box appears.
Select the Home Directory tab.
Under the Application settings section, in the Execute permissions drop down list, select Scripts and Executables.
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.
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:
A place holder that you must replace with the name of the host machine on which Access Manager is running.
The fully qualified domain name of the Access Manager host machine.
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.
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>
Save and close the timeout.aspx file.
Back up the file C:\Program Files\Microsoft\Exchange Server\ClientAccess\Owa\auth\logoff.aspx.
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.
Log in to Access Manager as amadmin.
Select the Configuration tab.
Scroll as necessary to click Platform under the System Properties section.
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.
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>
Save and close the logoff.aspx file.
Now you can verify the installation of the agent as described in 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.
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.
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.
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:
Microsoft Office SharePoint: Deactivating and Reactivating the Access Manager Policy Filter
Outlook Web Access: Deactivating and Reactivating the Access Manager Policy Filter
Be certain to use the appropriate instructions depending on your specific deployment.
Two tasks follow: one for deactivating the policy filter and one for reactivating it.
As an administrator, log in to Windows 2003 Server where Microsoft Office SharePoint is running.
In the Microsoft Windows Start menu, choose run.
Type the following: inetmgr.
Click OK.
Expand the local computer.
Expand the Web Sites folder.
Right-click Default Web Site.
An options list appears.
In the options list, click Properties.
The Default Web Site Properties dialog box appears.
Click the ISAPI Filters tab.
Click the amspfilter filter.
Click Remove.
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.
Click OK.
Restart the Microsoft IIS 6.0 Server.
A method for restarting this server is to enter iisreset in a command window.
As an administrator, log in to Windows 2003 Server where Microsoft Office SharePoint is running.
In the Microsoft Windows Start menu, choose run.
Type the following: inetmgr.
Click OK.
Expand the local computer.
Expand the Web Sites folder.
Right click Default Web Site.
An options list appears.
In the options list, Click Properties.
The Default Web Site Properties dialog box appears.
Click the ISAPI Filters tab.
Click Add.
In the Filter Name field, enter the following: amspfilter
In the Executable field, enter PolicyAgent-base\bin\amsharepointfilter32.dll.
Click OK.
Two tasks follow: one for deactivating the policy filter and one for reactivating it.
As an administrator, log in to Windows 2003 Server where Outlook Web Access Server is running.
In the Microsoft Windows Start menu, choose run.
Type the following: inetmgr.
Click OK.
Expand the local computer
Expand the Web Sites folder.
Right click Default Web Site.
An options list appears.
In the options list, click Properties.
The Default Web Site Properties dialog box appears.
Click the ISAPI Filters tab.
Click the amowafilter filter.
Click Remove.
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.
Click OK.
Restart the Microsoft IIS 6.0 Server.
As an administrator, log in to Windows 2003 Server where Outlook Web Access Server is running.
In the Microsoft Windows Start menu, choose run.
Type the following: inetmgr.
Click OK.
Expand the local computer.
Expand the Web Sites folder.
Right click Default Web Site.
An options list appears.
In the options list, click Properties.
The Default Web Site Properties dialog box appears.
Click the ISAPI Filters tab.
Click Add.
Enter amowafilter in the Filter Name field
Putting a different name here will cause OwaAdmin -unconfig to fail during uninstallation.
Enter PolicyAgent-base\bin\amowafilter64.dll in the Executable field.
Click OK.
Click Apply.
Click OK again
Restart Microsoft IIS 6.0 Server using the iisreset command.
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.
Change to the directory PolicyAgent-base\bin
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
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.
The option that allows the output to be used to unconfigure the agent from protecting Microsoft Office SharePoint or Outlook Web Access.
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.
Accept the default when presented with the following prompt:
Enter the Agent Resource File Name [IIS6Resource.en]:
Change to the following directory: C:\Agents\.
Remove the appropriate directory depending on the version of this agent.
Restart the Microsoft IIS 6.0 Server.
Once you have completed the unconfiguration process, see Agent Uninstallation for Microsoft IIS 6.0 to uninstall the agent.
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.