test

Oracle Waveset 8.1.1 Resources Reference

Resource Configuration Notes

This section provides instructions for configuring the following Active Directory resources for use with Waveset, including the following:

Waveset Gateway Location

Unless the LDAP Hostname resource attribute is set, the Gateway will perform a serverless bind to the directory. In order for the serverless bind to work, the Gateway needs to be installed on a system that is in a domain and that “knows” about the domain/directory to be managed. All Windows domains managed by a gateway must be part of the same forest. Managing domains across forest boundaries is unsupported. If you have multiple forests, install at least one gateway in each forest.

The LDAP Hostname resource attribute tells the Gateway to bind to a particular DNS hostname or IP address. This is the opposite of a serverless bind. However, the LDAP Hostname does not necessarily have to specify a specific domain controller. The DNS name of an AD domain can be used. If the Gateway system’s DNS server is configured to return multiple IP addresses for that DNS name, then one of them will be used for the directory bind. This avoids having to rely on a single domain controller.

Some operations, including pass-through authentication and before and after actions, require that the Gateway system be a member of a domain.

Waveset Gateway Service Account

By default, the Gateway service runs as the local System account. This is configurable through the Services MMC Snap-in.

If the gateway is used by an Active Directory adapter which has Exchange Server 2007 support turned on the account which is used to run the gateway must have special privileges.

The account must be a domain account from the domain which has Exchange Server 2007 installed. The account used must also be a member of the standard Exchange Server 2007 group Exchange Recipient Administrators. The account performs all Exchange Server 2007-specific actions by the gateway. It will not use the administrative account specified in the resource.

This limitation in the allowed gateway account is caused by limitations in the Exchange Server 2007 API.

When this is not configured correctly, a PowerShell error message similar to “PowerShell exception: Access to the address list service on all Exchange 2007 servers has been denied.” will be displayed, followed by a stack trace.

If you run the Gateway as an account other than Local System, then Gateway service account requires the “Act As Operating System” and “Bypass Traverse Checking” user rights. It uses these rights for pass-through authentication and for changing and resetting passwords in certain situations.

Most of the management of AD is done using the administrative account specified in the resource. However, some operations are done as the Gateway service account. This means that the Gateway service account must have the appropriate permissions to perform these operations. Currently, these operations are:

The Authentication Timeout resource attribute (provided for pass-through authentication only) prevents the adapter from hanging if a problem occurs on the Gateway side.

When performing before and after action scripts, the gateway may need the Replace a process level token right. This right is required if the gateway attempts to run the script subprocess as another user, such as the resource administrative user. In this case, the gateway process needs the right to replace the default token associated with that subprocess.

If this right is missing, the following error may be returned during subprocess creation:

"Error creating process: A required privilege is not held by the client"

The Replace a process level token right is defined in the Default Domain Controller Group Policy object and in the local security policy of workstations and servers. To set this right on a system, open the Local Security Policies application within the Administrative Tools folder, then navigate to Local Policies > User Rights Assignment > Replace a process level token.

Out of Office Messages

The outOfOfficeEnabled and outofOfficeMessage account attributes can be used to enable the out of office autoreply function and set the out-of-office message, respectively. These can be used for Exchange 2000 or 2003 accounts. These attributes are only set on account updates and not account creates.

The adapter requires that the Messaging Application Programming Interface (MAPI) be installed on the gateway machine. There are at least two ways to install the MAPI subsystem. The simplest way is to install the Microsoft Outlook client on the gateway machine. No other configuration is necessary.

Another way is to install the Exchange System Management Tools, which are located on the Exchange Server CD. The management tools are installed as a component of the normal Exchange Server install. However, this installs the MAPI subsystem files, but it does not complete the configuration.

The mapisvc.inf file (typically located in c:\winnt\system32) contains the available MAPI services, and it must be updated to include the Exchange message service entries. The msems.inf file, which is contained in the gateway zip file, contains the entries that need to be merged into the mapisvc.inf file to configure the Exchange message server. The msems.inf file can be merged into the mapisvc.inf file manually using a text file editor such as notepad. Alternatively, a tool named MergeIni.exe is available on the Microsoft Platform SDK and can be found in the Windows Core SDK in the Microsoft SDK\Bin directory.

Use the following command to run MergeIni:

MergeIni msems.inf -m

Out of Office attributes cannot be retrieved when the msExchHideFromAddressLists attribute is enabled. If a user form attempts to display the Out of Office attributes when msExchHideFromAddressLists is true, the values will be undefined. The sample Active Directory user form contains logic that prevents Waveset from displaying Out of Office attrbutes when msExchHideFromAddressLists is enabled.

Exchange Server 2007 does not support setting the Out Of Office message for a user. The messages are no longer stored as part of the user entry and form a part of the user’s mailbox. Outlook or Outlook Web Access should be used by the end user to manage the Out of Office replies.

Requirements for Exchange Server 2007

Exchange Server 2007 provides a supported provisioning API using the Exchange Management Shell only. The shell provides a command line interface to manage and provision users and servers. It is built on top of Microsoft Windows PowerShell.

The gateway must be run on a Microsoft Windows 32-bit operating system. In addition, the following items must be installed on the gateway machine:

These requirements are discussed in more detail in the following sections.

Microsoft Exchange Server 2007 “Management Tools,” 32-Bit

The Exchange management shell is a part of the management tools for Exchange. Microsoft does not support running Exchange Server 2007 on a 32-bit version of Windows in a production environment. An exception is made for the Management Tools, as documented in the “Exchange Server 2007 System Requirements.”

Install only the 32-bit version of the Management Tools on the gateway machine. Installing the 32-bit version of the tools on a 64-bit version of the operating system, or installing both versions of the tools can lead to unpredictable behavior.

The 32-bit version of the management tools can be downloaded from the Microsoft website:

http://go.microsoft.com/fwlink/?LinkID=82335

The version of the tools you download and install should correspond to the Exchange Server 2007 version installed in the rest of the Exchange environment.

Before starting the installation of the management tools make sure that Microsoft Windows PowerShell 1.0 and Microsoft .NET 2.0 Framework

The two required packages have been installed:

Microsoft Windows PowerShell 1.0

The Exchange management tools are implemented as an extension, or snapin, of Microsoft PowerShell. Currently only PowerShell version 1.0 is supported and needs to be installed on the server:

http://go.microsoft.com/fwlink/?LinkID=75790&clcid=0x09

The PowerShell environment logs messages to the event viewer. There are two event logs created for PowerShell in a standard installation: the “PowerShell” and “Windows PowerShell” event logs. The “PowerShell” event log is used when the gateway creates a PowerShell runtime environment. When a write operation fails to write to the event log, the PowerShell environment will not start up, and all PowerShell-related actions of the gateway will fail. To prevent this failure, you should monitor and clean up the event log regularly or configure it to overwrite messages.

Microsoft .NET 2.0

To use PowerShell, you must install the Microsoft .NET 2.0 Framework. This Framework is not installed by default and can be downloaded from the Microsoft Download Center at:

http://www.microsoft.com/downloads/details.aspx?familyid=0856EACB-4362-
4B0D-8EDD-AAB15C5E04F5