You can modify the existing driver policies to perform additional functionality.
Section 6.3.7, Deleting the GroupWise User without Deleting the eDirectory User
Section 6.3.10, Specifying a New Resource Owner on an Owner Delete
Section 6.3.11, Specifying a New Resource Owner on an Owner Disable
Section 6.3.13, Moving Users from One Post Office to Another Post Office
Section 6.3.14, Adding Additional Attributes to Be Synchronized
Section 6.3.21, Verifying if an E-Mail Address or Gateway Alias Is Unique
By default, the GroupWise Subscriber Placement policy puts all new users in the same post office. The Placement policy can also determine the post office based on an attribute value or the eDirectory user container.
The following example, created in Policy Builder, specifies the post office based on the eDirectory container where the user was created.
Figure 6-1 Placement Policy Specifying a Post Office Based on the eDirectory Container
The following graphic shows the policies needed to place users in the Sales container into PO1 and users in the Engineering container into PO2.
Figure 6-2 Placement Policy for placing Users in Different Containers
Distribution lists are used by organizations to assure that the appropriate individuals are included in various internal communications. Wherever possible, organizations should automatically assign new employees to these distribution lists so that they can immediately participate in the communications that are relevant to them.
Using a Subscriber Create policy when an eDirectory user is created, the GroupWise account can be added to a distribution list based on the eDirectory container. When a user is created in the Sales container, the user is added to the Sales Distribution List. When a user is created in the Engineering container, the user is added to the Engineering Distribution List.
The policies in this section, created by using Policy Builder, show how to configure the following actions:
Creating a New User as a Member of a Distribution List Based on the User’s eDirectory Container
Adding a User as a Blind Copy or Carbon Copy Participant in a Distribution List
Adding a User to a Distribution List When He or She Becomes a Manager
Removing a User from a Distribution List When the User is No Longer a Manager
Using Policy Builder, you can use these examples to create similar policies and Distribution Lists for your business rules and environment.
Figure 6-3 Create Policy
The user participates in the distribution list as a primary, blind copy, or carbon copy member. The XML attributes of gw:participation=“bc” and gw:participation=“cc” are used to set the type of membership a user has in the distribution list. If these attributes are not specified, it defaults to primary.
<modify-attr attr-name="Distribution List DN" xmlns:gw="http://www.novel.com/dirxml/gwdriver" gw:participation="bc"> <add-value> <value type="string">\IDMTREE\Novell\Users\cDL1</value> <value type="string">\IDMTREE\Novell\Users\cG1</value> </add-value> </modify-attr>
or
<add-attr attr-name="Distribution List DN xmlns:gw="http://www.novell.com/dirxml/gwdriver" gw:participation="bc"> <value type="string">\IDMTREE\Novell\Users\cDL1</value> <value type="string">\IDMTREE\Novell\Users\cG1</value> </add -attr>
To add the user as a carbon copy member, replace the attribute gw:participation=”bc” with gw:participation=“cc”.
Figure 6-4 Adding a User to a Distribution List
Figure 6-5 Removing a User from a Distribution List
Figure 6-6 Removing a User from All Distribution Lists
When a user is removed from the distribution list, the driver cleans up the Member attribute from the associated group object.
Other attributes can be set in the GroupWise account by using the Create policy. Some attributes must be set in both eDirectory and GroupWise. When the eDirectory user object contains a corresponding attribute, it must be set. It is important that attribute values are set in both eDirectory and GroupWise. If the attribute is set only in GroupWise, it could be overwritten with the value in eDirectory. You must customize the driver to update values in eDirectory; the driver does not do this by default.
The following example shows setting the Description attribute in eDirectory and GroupWise. The attribute write-back = “true” causes the attribute to also be written in eDirectory.
<?xml version="1.0" encoding="UTF-8"?> <create-rules> <create-rule class-name="User" description="GroupWise Account Required Attributes"> <!-- Description attribute is given a default value in both eDirectory and in GroupWise --> <required-attr attr-name="Description" write-back="true"> <value type="String"><![CDATA[eDirectory User synchronized by GroupWise Driver]]></value> </required-attr> </create-rule> </create-rules>
The CN attribute in eDirectory is used to name the GroupWise account. You must include this in the Create policy as a required attribute. The CN value from eDirectory can be ignored in the Subscriber Create policy and a CN based on other attributes can be generated. An example code segment from a Create policy is shown below. If you make modifications to this policy, the modify events coming from the engine also need to be modified.
When an attribute used to construct the CN is modified, a GroupWise Rename event should be generated via the policies. The UserID must be unique within a post office. If UserID is used to generate Internet EMail Address, it must be unique in the entire GroupWise system. The UserID contains 1 to 256 characters, and cannot contain the ( ) @ . : , { } * " characters. The UserID must be unique within its namespace (UserID shares the same namespace as nicknames, resources, and distribution lists.) Do not use “mapi” (reserved ID) for this value.
An Output Transformation or Event Transformation policy can monitor the attributes used to build the CN. If one of these attributes changes, a Rename event should also be generated. Any attributes used here need to be added to the list of required attributes. In this case, Rename events should still be forwarded to the driver with an empty <newname> element. See Renaming Users for more information.
<rule> <!--CN is used to set the GroupWise UserID. Construct a new CN from Given Name.--> <description>Use Given Name for GroupWise Account Name</description> <conditions> <and> <if-class-name op="equal">User</if-class-name> </and> </conditions> <actions> <!-- 'CN' and 'Given Name' must be present --> <do-veto-if-op-attr-not-available name="CN"/> <do-veto-if-op-attr-not-available name="Given Name"/> <!-- replace current CN value with the 'Given Name' value --> <do-reformat-op-attr name="CN"> <arg-value type="string"> <token-op-attr name="Given Name"/> </arg-value> </do-reformat-op-attr> </actions> </rule>
You can synchronize any attribute that can be represented as a string in eDirectory with one of twenty GroupWise generic attributes (excluding octet strings and structured attributes). You specify the eDirectory attribute you want to map in the filter. In addition, the eDirectory and GroupWise attribute names must be connected in the Schema Mapping policy.
The Schema Mapping rule code segment below connects the eDirectory attribute Location with the GroupWise attribute 55003.
<attr-name class-name="User"> <nds-name>Location</nds-name> <app-name>55003</app-name> </attr-name>
The twenty GroupWise attribute names are 50106 through 50115 and 55002 through 55011. Address book labels can be assigned to these GroupWise attributes through the GroupWise ConsoleOne® snap-ins. You should configure the same mappings in GroupWise as you do in the driver mappings.
The following query, sent to the driver, returns the number of users in dom1.po1.
<nds dtdversion="1.1" ndsversion="8.6"> <input> <query event-id="query-groupwise" scope="subtree"> <search-class class-name="User"/> <!-- Referenced Domain Name --> <search-attr attr-name="50035"> <value>dom1</value> </search-attr> <!-- Referenced Post Office Name --> <search-attr attr-name="50062"> <value>po1</value> <search-attr> <!-- return Record Count--> <read-attr attr-name="Record Count"/> </query> </input> </nds>
If you remove the post office search attr, it returns the number of users in dom1. If you remove the domain search attr, it returns the number of users in the system. This search can be altered to apply to other search criteria.
After deleting the user in GroupWise, the driver cleans up the GroupWise attributes in eDirectory. The result is the same as deleting the user with the GroupWise snap-ins and only selecting Delete from GroupWise.
You need to change the match criteria to match the needs of your environment.
<!-- You need to change the conditions to meet the needs of your system. --> <policy xmlns:gw="http://www.novell.com/dirxml/gwdriver"> <rule> <description>Delete GroupWise user but keep eDirectory user</description> <conditions> <and> <if-class-name op="equal">User</if-class-name> <if-operation op="equal">modify</if-operation> <if-op-attr name="OU" op="changing-to">inactive</if-op-attr> </and> </conditions> <actions> <do-delete-dest-object/> <do-set-xml-attr expression='../delete[@class-name="User"]' name="gw:original-event"> <arg-string> <token-text xml:space="preserve">modify</token-text> </arg-string> </do-set-xml-attr> <do-veto/> </actions> </rule> </policy>
GroupWise nicknames can be automatically created when an eDirectory User is renamed or when a GroupWise account is moved. This is controlled in iManager on the driver through the Global Configuration Value page. When you set this option to True, nicknames are automatically created when an eDirectory rename occurs or when a GroupWise account is moved. When you set this option to False, nicknames are not created. Nickname creation requires GroupWise 6.5 SP1 or higher agents to be running.You can override this option by adding code to the Output Transformation policy to specify whether a nickname should be created.
<policy xmlns:gw="http://www.novell.com/dirxml/gwdriver"> <rule> <description>Create GroupWise Nickname</description> <conditions> <and> <if-operation op="equal">rename</if-operation> <if-class-name op="equal">User</if-class-name> </and> </conditions> <actions> <do-set-xml-attr expression="." name="gw:create-nickname"> <arg-string> <token-text xml:space="preserve">true</token-text> </arg-string> </do-set-xml-attr> </actions> </rule> </policy>
The following examples show two ways to create a nickname record. The first specifies the post office in which the nickname is created in the <dest-dn> attribute (this implies the domain). The second example uses <add-attr> nodes to specify the domain and post office.
The nickname can contain 1 to 256 characters, and cannot contain the ()@.:,{}*" characters. It must be unique within its namespace (nicknames share the same namespace as users, resources, and distribution lists.)
<add class-name="GroupWise Nickname" dest-dn="Novell\dirxml\groupwise\xmlPO" event-id="0" > <!-- Domain of user this nickname refers to --> <add-attr attr-name="50068" > <value type="string">xmlDom</value> </add-attr> <!-- Post Office of user this nickname refers to --> <add-attr attr-name="50069" > <value type="string">xmlPO</value> </add-attr> <!-- user this nickname refers to --> <add-attr attr-name="50070" > <value type="string">Usern1</value> </add-attr>
<!-- name of nickname record --> <add-attr attr-name="50073" > <value type="string">nn1</value> </add-attr> </add> OR <add class-name="GroupWise Nickname" event-id="0" > <!-- Domain of user this nickname refers to --> <add-attr attr-name="50068" > <value type="string">xmlDom</value> </add-attr> <!-- Post Office of user this nickname refers to --> <add-attr attr-name="50069" > <value type="string">xmlPO</value> </add-attr> <!-- user this nickname refers to --> <add-attr attr-name="50070" > <value type="string">Usern1</value> </add-attr> <!-- Domain of nickname record --> <add-attr attr-name="50035" > <value type="string">xmlDom</value> </add-attr> <!-- Post Office of nickname record --> <add-attr attr-name="50062" > <value type="string">xmlPO</value> </add-attr> <!-- name of nickname record --> <add-attr attr-name="50073" > <value type="string">nn1</value> </add-attr> </add>
If the owner of a resource (a conference room, for instance) is deleted, the driver automatically assigns that resource to another owner. You must designate a default user for all resource assignments. At the time the resource is assigned, if the driver detects no default user account, it creates the default user account and assigns the resource to that user.
Through a policy, you can specify an override owner. Using the Output Transformation policy, the eDirectory User delete is selected. The special attribute, gw:resource-owner-dn, is used to notify the shim of the override resource owner. This special attribute is specified on the <delete> element. Resources are always reassigned on a delete. The new owner must already exist in GroupWise and be in the same post office as the user being deleted. If a failure occurs using the override owner, the resources are automatically assigned to the default user specified in the driver options. The XSLT code segment is:
<policy xmlns:gw="http://www.novell.com/dirxml/gwdriver"> <rule> <description>Specify Resource Owner DN for User Delete</description> <conditions> <and> <if-operation op="equal">delete</if-operation> <if-class-name op="equal">User</if-class-name> </and> </conditions> <actions> <do-set-xml-attr expression="." name="gw:resource-ownerdn"> <arg-string> <token-text xml:space="preserve">\GWDRIVERTREE\novell\users\sales\ResourceOwner</token-text> </arg-string> </do-set-xml-attr> </actions> </rule> </policy>
If the owner of a resource (a conference room, for instance) is disabled, you can use GCVs to configure the driver to automatically assign that resource to another owner. In this process, you can designate a default user for all resource assignments. At the time a resource is being reassigned, if the driver detects no default user account, it creates a default user account and assigns it as the resource owner only if the Reassign Resource Ownership driver GCV is set to True.
When an eDirectory User Login Disabled attribute is set, the GroupWise resources of the disabled or expired account can be assigned to another GroupWise account. Normally, the new owner is a default user specified in the Default Resource Owner UserID parameter. Through a policy, an override owner can be specified. Using the Output Transformation policy, the eDirectory User login disable is selected. The special attribute, gw:resource-owner-dn, is used to notify the shim of the override resource owner. This special attribute is specified in the <modify-attr> element.
The resources are assigned to the override owner even when the Reassign Resource Ownership GCV is set to False. The new owner must already exist in GroupWise and be in the same post office as the user being disabled. If a failure occurs using the override owner, the resources are automatically assigned to the default user specified in the Driver Options. The policy for disabling is:
<policy xmlns:gw="http://www.novell.com/dirxml/gwdriver"> <rule> <description>Specify Resource Owner DN for User Delete</description> <conditions> <and> <if-operation op="equal">modify</if-operation> <if-op-attr name="50058" op="changing-to">true</if-op-attr> <if-class-name op="equal">User</if-class-name> </and> </conditions> <actions> <do-set-xml-attr expression="." name="gw:resource-ownerdn"> <arg-string> <token-text xml:space="preserve">\GWDRIVERTREE\novell\users\sales\ResourceOwner</token-text> </arg-string> </do-set-xml-attr> </actions> </rule> </policy>
There might be situations where an eDirectory user is created and you do not want to create a corresponding GroupWise account. In addition, not all eDirectory users initially have a GroupWise account. You can use the driver to control the creation of GroupWise accounts.
One way to control the creation of an account is to trigger the account creation using an extended attribute such as createGroupWiseAccount.
The eDirectory schema must be extended to include the attribute createGroupWiseAccount. When the createGroupWiseAccount attribute is set to True, the GroupWise account is created. When the createGroupWiseAccount attribute is set to False, the GroupWise account is not created. Changing the value from False to True causes the GroupWise account to be created.
The createGroupWiseAccount attribute must be added to the Create policy as a required attribute and also added to the Subscriber Filter.
<rule> <description>Require createGroupWiseAccount attribute</description> <conditions> <and> <if-class-name op="equal">User</if-class-name> </and> </conditions> <actions> <do-veto-if-op-attr-not-available name="createGroupWiseAccount"/> </actions> </rule> <rule> <description>Check createGroupWiseAccount attribute</description> <conditions> <and> <if-class-name op="equal">User</if-class-name> <if-op-attr name="createGroupWiseAccount" op="not-equal">true</if-op-attr> </and> </conditions> <actions> <do-veto/> </actions> </rule>
You can also use the global configuration value Default Sync Source: eDir Container/Subtree to select what part of the tree you want to synchronize to GroupWise.
When a style sheet is not configured to move GroupWise accounts, we recommend that you use the GroupWise 7 snap-ins (or higher) for user moves.
When the Output Transformation style sheet is configured to move GroupWise accounts, we recommend that user moves be made in eDirectory and that the driver assign the object to a new post office in GroupWise. The XSLT code segment for the Output Transformation policy is shown below. The dest-dn attribute on the parent element specifies the new post office.
<rule> <description>Move User to GW PostOffice</description> <conditions> <and> <if-operation op="equal">move</if-operation> <if-class-name op="equal">User</if-class-name> </and> </conditions> <actions> <do-if> <arg-conditions> <and> <if-xpath op="true">parent/@src-dn="\GWDRIVERTREE\Novell\Users\Sales"</if-xpath> </and> </arg-conditions> <arg-actions> <do-set-xml-attr expression="parent" name="dest-dn"> <arg-string> <token-text xml:space="preserve">\GWDRIVERTREE\Novell\GroupWise\Post Offices\Sales PO</token-text> </arg-string> </do-set-xml-attr> </arg-actions> </do-if> <do-if> <arg-conditions> <and> <if-xpath op="true">parent/@src-dn="\GWDRIVERTREE\Novell\Users\Engineering"</if-xpath> </and> </arg-conditions> <arg-actions> <do-set-xml-attr expression="parent" name="dest-dn"> <arg-string> <token-text xml:space="preserve">\GWDRIVERTREE\Novell\GroupWise\Post Offices\Engineering PO</token-text> </arg-string> </do-set-xml-attr> </arg-actions> </do-if> </actions> </rule>
You can map up to twenty user eDirectory attributes to generic GroupWise attributes and display them in the address book. For these attributes, you use the ranges 50106-50115 and 55002-55011. You must first add these eDirectory attributes to the filter. You must configure these attributes in the GroupWise ConsoleOne snap-ins for these attributes to appear in the GroupWise address book.
We recommend that you rename users by changing the naming attribute in eDirectory and letting the driver rename the GroupWise account. When CN is the naming attribute (this is the default), no special style sheet coding is required for a rename process. However, the GroupWise MailboxID can be built from attributes other than CN. When one of these attributes is modified, the GroupWise account should also be renamed. The XSLT code segment is shown below. In this example, the eDirectory attribute Given Name is used to name the GroupWise account. When Given Name is modified, a GroupWise rename is generated. In the second template below, <xsl:template match=“rename[@class-name=’User’]”> handles the case where the eDirectory User object was renamed. In this case the <rename> command is passed through to the driver. The empty <new-name/> element blocks the driver from renaming the GroupWise account. Even though the GroupWise account is not renamed, the rename event must pass to the driver.
We do not recommend that you use the GroupWise snap-ins to do a rename. However, if the user is renamed using the GroupWise snap-ins, it must be done with GroupWise 6.5 SP1 or higher. If you use an older version of the GroupWise snap-ins, it can cause the driver to generate errors.
(placed in the subscriber event transform, or subscriber command transform) <rule> <description>Rename User if Given Name is changing</description> <conditions> <and> <if-operation op="equal">modify</if-operation> <if-op-attr name="Given Name" op="changing"/> <if-class-name op="equal">User</if-class-name> </and> </conditions> <actions> <do-rename-dest-object> <arg-string> <token-op-attr name="Given Name"/> </arg-string> </do-rename-dest-object> </actions> </rule>
(placed in the subscriber event transform) <rule> <description>Veto Rename User operations</description> <conditions> <and> <if-operation op="equal">rename</if-operation> <if-class-name op="equal">User</if-class-name> </and> </conditions> <actions> <do-veto/> </actions> </rule>
The following XSLT code segment shows how to create a gateway alias in the Output Transformation policy. Your code is responsible for generating the value of attributes 50140 and 50077.
<rule> <description>Create GW Gateway Alias attribute for new user</description> <conditions> <and> <if-operation op="equal">add</if-operation> <if-class-name op="equal">User</if-class-name> </and> </conditions> <actions> <do-add-dest-attr-value class-name="User" name="Gateway Alias"> <arg-value type="structured"> <arg-component name="50140"> <token-text xml:space="preserve">SMTP</token-text> </arg-component> <arg-component name="50077"> <token-text xml:space="preserve">UserOne@novell.com</token-text> </arg-component> </arg-value> </do-add-dest-attr-value> </actions> </rule>
The following Output Transformation policy shows how to query for GroupWise nicknames.The search-attrs in this style sheet are optional. They are used to scope the search. When you specify a post office name (50069), you must also specify a domain name (50068). More than one nickname can be returned.
For example, User2a is renamed to User2b, then renamed to User2c. There will be two nickname records (User2a and User2b) which both reference User2c. This code sample queries the User of the current event for nicknames. You should use a different match criterion.
<rule> <description>Query for User's GroupWise Nicknames</description> <conditions> <and> <if-operation op="equal">modify</if-operation> <if-class-name op="equal">User</if-class-name> </and> </conditions> <actions> <do-set-local-variable name="gw-user-name"> <arg-node-set> <token-query class-name="User" scope="entry"> <arg-association> <token-association/> </arg-association> <arg-string> <token-text xml:space="preserve">50035</token-text> </arg-string> <arg-string> <token-text xml:space="preserve">50062</token-text> </arg-string> <arg-string> <token-text xml:space="preserve">50073</token-text> </arg-string> </token-query> </arg-node-set> </do-set-local-variable> <do-set-local-variable name="gw-nickname"> <arg-node-set> <token-query class-name="GroupWise Nickname"> <arg-match-attr name="50068"> <arg-value> <token-xpath expression="$gw-user-name//attr[@attr-name='50035']/value"/> </arg-value> </arg-match-attr> <arg-match-attr name="50069"> <arg-value> <token-xpath expression="$gw-user-name//attr[@attr-name='50062']/value"/> </arg-value> </arg-match-attr> <arg-match-attr name="50070"> <arg-value> <token-xpath expression="$gw-user-name//attr[@attr-name='50073']/value"/> </arg-value> </arg-match-attr> <arg-string> <token-text xml:space="preserve">50035</token-text> </arg-string> <arg-string> <token-text xml:space="preserve">50062</token-text> </arg-string> <arg-string> <token-text xml:space="preserve">50073</token-text> </arg-string> </token-query> </arg-node-set> </do-set-local-variable> </actions> </rule>
<nds dtdversion="1.1" ndsversion="8.6"> <source> <product build="20020409_1220" instance="GroupWise ZDS Driver" version="1.0a Beta">DirXML Driver for GroupWise</product> <contact>Novell, Inc.</contact> </source> <output> <instance class-name="GroupWise Nickname" event-id="0"> <attr attr-name="50035"> <value type="string">TaoDom</value> </attr> <attr attr-name="50062"> <value type="string">TaoPO</value> </attr> <attr attr-name="50073"> <value type="string">User2b</value> </attr> </instance> <instance class-name="GroupWise Nickname" event-id="0"> <attr attr-name="50035"> <value type="string">TaoDom</value> </attr> <attr attr-name="50062"> <value type="string">TaoPO</value> </attr> <attr attr-name="50073"> <value type="string">User2a</value> </attr> </instance> <status level="success"/> </output> </nds>
The following XSLT code segment shows how to query in the Output Transformation policy for a gateway alias.
<rule> <description>Query for User's GroupWise Gateway Alias</description> <conditions> <and> <if-operation op="equal">modify</if-operation> <if-class-name op="equal">User</if-class-name> </and> </conditions> <actions> <do-set-local-variable name="gw-alias"> <arg-node-set> <token-query class-name="User" scope="entry"> <arg-association> <token-association/> </arg-association> <arg-string> <token-text xml:space="preserve">Gateway Alias</token-text> </arg-string> </token-query> </arg-node-set> </do-set-local-variable> </actions> </rule>
<nds dtdversion="1.0" ndsversion="8.5"> <source> <product version="1.0 SP1 Beta, 20020307_1205">GroupWise ZDS Driver</product> <contact>Novell, Inc.</contact> </source> <output> <instance class-name="User" event-id="0" src-dn="TaoDom.TaoPO.User1{106}DFD036A0-0776-0000-A246-4100F0001300"> <association>TaoDom.TaoPO.User1{106}DFD036A0-0776-0000-A246-4100F0001300<association> <attr attr-name="Gateway Alias"> <value type="structured"> <component name="50140">SMTP</component> <component name="50077">UserOne@novell.com</component> </value> </attr> </instance> <status level="success"/> </output> </nds>
The following XSLT code segment shows how to query in the Output Transformation policy for the Internet Email Address generated by GroupWise.
<rule> <description>Query for User's GroupWise Internet E-mail Address</description> <conditions> <and> <if-operation op="equal">modify</if-operation> <if-class-name op="equal">User</if-class-name> </and> </conditions> <actions> <do-set-local-variable name="gw-email-address"> <arg-node-set> <token-query class-name="User" scope="entry"> <arg-association> <token-association/> </arg-association> <arg-string> <token-text xml:space="preserve">Internet EMail Address</token-text> </arg-string> </token-query> </arg-node-set> </do-set-local-variable> </actions> </rule>
<nds dtdversion="1.1" ndsversion="8.6"> <source> <product build="20020502_1251" instance="GroupWise Driver" version="1.0a Beta">DirXML Driver for GroupWise</product> <contact>Novell, Inc.</contact> </source> <output> <instance class-name="User" event-id="0" src-dn="TaoDom.TaoPO.User2{106}5B8C40F0-0E79-0000-9ADA-350037009300"> <association>TaoDom.TaoPO.User2{106}5B8C40F0-0E79-0000-9ADA-350037009300</association> <attr attr-name="Internet EMail Address"> <value type="string">User2@domain.com</value> </attr> </instance> <status level="success"/> </output> </nds>
In your business, you might have several different e-mail applications. Although not all employees will have GroupWise e-mail accounts, you want the GroupWise address book to contain all employee information. The driver has the ability to create GroupWise external users, which enables the driver to obtain data from other e-mail systems (via the Identity Vault) and display it in the GroupWise address book. The users in the Identity Vault can be assigned to a GroupWise External Post Office.
If you are using multiple e-mail systems (GroupWise and NetMail®/Notes/Exchange) you can create external users and external post offices to add the users in the non-GroupWise systems to the GroupWise address book.
To synchronize data between external e-mail systems and GroupWise, your implementation must meet the following conditions:
External users must be assigned to or be created in an external post office. These users do not have a GroupWise mailbox.
External post offices must belong to a non-GroupWise domain.
The default driver configuration does allow for this customization. To implement this functionality, you must select the following options during the configuration of the driver:
There are three ways you can specify placement when creating external users:
In the Placement rule, you can specify the DN of an eDirectory object associated with the external post office. For additional information, refer to Creating External Post Offices.
Identify the external post office by Specifying an External Post Office in an Add Event.
Create a user in an organizational unit associated with the External GroupWise Post Office. For more information, see Include Policies for eDirectory OrgUnit to GroupWise External Post Office Synchronization?.
When creating accounts in eDirectory for a non-GroupWise user, make sure the attribute gw:classification=“external” is part of the Add event. The attribute can be used on the User object and on the Post Office object. If you have selected the options of Include Policies for GroupWise External Entity Synchronization? and Include Policies for eDirectory OrgUnit to GroupWise External Post Office Synchronization? during the configuration of the driver, the attribute is automatically part of the Add event.
You can modify the Schema Mapping policy or Output Transformation policy so that it modifies the class name of the user based on some criterion, such as the parent container name. The external users were formerly a separate class. The preferred method is to add the attributes instead of adding a new class. These two methods are mutually exclusive.
When a new GroupWise external user is added to GroupWise, the driver creates an association on the User object in the Identity Vault. If the non-GroupWise user’s information changes in the Identity Vault, the driver synchronizes those changes to GroupWise. If the association key is altered or deleted, the connection is broken, and the driver does not synchronize any changes made to the User object in the Identity Vault to GroupWise.
If you do not use the driver to create an external post office, you need to generate the following information in the XML Add event. You must replace the external post office name and non-GroupWise domain values with names specific to your system.
<!-- The external post office name to which the user belongs. --> <add-attr attr-name="50062"> <value type="string"><![CDATA[External post office name]]></value> </add-attr>
<!-- The non-GroupWise domain name to which the external post office belongs. --> <add-attr attr-name="50035"> <value type="string"><![CDATA[Non-GroupWise domain name]></value> </add-attr>
NOTE:If you include the additional XML in the Add event, the value in your Placement policy is overridden.
There are two ways you can create external post offices:
Let the driver create a GroupWise external post office and associate it to an eDirectory object, such as an Organizational Unit (recommended). Select Include Policies for eDirectory OrgUnit to GroupWise External Post Office Synchronization? during the configuration of the driver.
Create an external post office through ConsoleOne.
NOTE:Before you can create an external post office, you must create a non-GroupWise domain in ConsoleOne.
There are two ways you can specify placement when creating external post offices:
In the Placement policy, you can specify the name of the non-GroupWise domain in which to create the external post office.
Identify the non-GroupWise domain by generating XML code to specify the non-GroupWise domain. For additional information, refer to Specifying a Non-GroupWise Domain in an Add Event.
You can generate the following information in the XML Add event. You must replace the non-GroupWise domain value with the name specific to your system. If you use the configuration option of Include Policies for eDirectory OrgUnit to GroupWise External Post Office Synchronization?, the driver does this automatically. If you do not use this option, you need to use the following information to manually specify a Non-GroupWise domain in an Add event.
<!-- The non-GroupWise domain name to which the external post office belongs. --> <add-attr attr-name="50035"> <value type="string"><![CDATA[Non-GroupWise domain name]></value> </add-attr>
NOTE:If you include the additional XML in the Add event, the value in your Placement policy is overridden.
If you associate the external post office with an Organizational Unit, you must also map the OU attribute to the CN attribute for the Organizational Unit class, and the driver will use that attribute value for the post office name.
NOTE:The Schema Mapping policy has a mapping for the OU attribute on the User class. Do not change the User class mapping.
When creating external users, you should use the DN of the Organizational Unit in the Placement policy. When an external post office is added, you should specify the GroupWise domain to which the external post office belongs:
When you create an external post office with the driver, GroupWise uses the default time zone setting on the non-GroupWise domain. If you want to change the time zone setting for the post office, generate the following XML in the Add event. Insert the appropriate time zone value in place of EST.
<add-attr attr-name="50088" > <value type="string">EST</value> </add-attr>
The GroupWise driver has a special query that allows you to see if a proposed Internet e-mail address or gateway alias is unique. If the address is unique, a success status without an instance node is returned. If the address is not unique, the record owning the conflicting address is returned.
A query example follows, with a hard-coded value helloworld@mydomain.com. Make sure to replace each instance of the hard-coded value with your value.
<query event-id="query-groupwise" scope="subtree">
<search-class class-name="User"/>
<search-attr attr-name="Internet EMail Address">
<value>helloword@mydomain.com</value>
</search-attr>
<!-- Domain Name of Object -->
<read-attr attr-name="50035"/>
<!-- Post Office Name of Object -->
<read-attr attr-name="50062"/>
<!-- Object Name of Object -->
<read-attr attr-name="50073"/>
</query>
If there is a gateway alias with this value, you receive the following:
<instance class-name="GroupWise GateWay Alias" event-id="0"> <attr attr-name="50035"> <value type="string">gwdom</value> </attr> <attr attr-name="50062"> <value type="string">gwpo</value> </attr> <attr attr-name="50073"> <value type="string">User3</value> </attr> </instance>
The value of the <attr attr-name> elements give the name of the user to which the gateway belongs.
If an existing user owns the Internet e-mail address, you receive the following:
<instance class-name="User" event-id="0" src-dn="gwdom.gwpo.User3"> <association>gwdom.gwpo.User3{106}7F7B2F70-0434-000-A0DE-DB0019009700</association> <attr attr-name="50035"> <value type="string">gwdom</value> </attr> <attr attr-name="50062"> <value type="string">gwpo</value> </attr> <attr attr-name="50073"> <value type="string"User3</value> </attr> </instance>
Only one instance is returned, even if there are multiple conflicts.