5.3 Modifying Policies

You can modify the existing driver policies to perform additional functionality.

5.3.1 Specifying the GroupWise Post Office

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 Identity Vault user container.

Figure 5-1 shows a policy created in Policy Builder that specifies the post office based on the Identity Vault container where the user was created.

Figure 5-1 Placement Policy Specifying a Post Office Based on the Identity Vault Container

Figure 5-2 shows the policies needed to place users in the Sales container into PO1 and users in the Engineering container into PO2.

Figure 5-2 Placement Policy for Placing Users in Different Containers

5.3.2 Specifying Distribution Lists

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 Identity Vault user is created, the GroupWise account can be added to a distribution list based on the Identity Vault 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 the Policy Builder, show how to configure the following actions:

In the Policy Builder, you can use these examples to create similar policies and Distribution Lists for your business rules and environment.

Creating a New User as a Member of a Distribution List Based on the User’s Identity Vault Container

Figure 5-3 Create Policy

Adding a User as a Blind Copy or Carbon Copy Participant in a Distribution List

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”.

Adding a User to a Distribution List When He or She Becomes a Manager

Figure 5-4 Adding a User to a Distribution List

Removing a User from a Distribution List When the User is No Longer a Manager

Figure 5-5 Removing a User from a Distribution List

Removing a User from All Distribution Lists

Figure 5-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.

5.3.3 Setting Defaults for GroupWise Attributes

Other attributes can be set in the GroupWise account by using the Create policy. Some attributes must be set in both the Identity Vault and GroupWise. When the Identity Vault user object contains a corresponding attribute, it must be set. It is important that attribute values are set in both the Identity Vault and GroupWise. If the attribute is set only in GroupWise, it could be overwritten with the value in the Identity Vault. You must customize the driver to update values in the Identity Vault; the driver does not do this by default.

The following example sets the Description attribute in the Identity Vault and GroupWise. The attribute write-back = “true” causes the attribute to also be written in the Identity Vault.

<rule> 
 <description>GroupWise Account Required Attributes</description> 
   <conditions> 
     <and> 
       <if-class-name op="equal">User</if-class-name> 
     </and> 
   </conditions> 
      <actions> 
         <do-set-default-attr-value name="Description" write-back="true"> 
           <arg-value type="string"> 
              <token-text xml:space="preserve">eDirectory User synchronized by GroupWise Driver</token-text> 
          </arg-value> 
         </do-set-default-attr-value> 
       </actions> 
</rule>

5.3.4 Configuring the GroupWise UserID

The CN attribute in the Identity Vault is used to name the GroupWise account. You must include this in the Create policy as a required attribute. The CN value from the Identity Vault can be ignored in the Subscriber Create policy and a CN based on other attributes can be generated. An example of 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>
  <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>

5.3.5 Creating Mappings for Additional Attributes

You can synchronize any attribute that can be represented as a string in the Identity Vault with one of twenty GroupWise generic attributes (excluding octet strings and structured attributes). You specify the Identity Vault attribute you want to map in the filter. In addition, the Identity Vault and GroupWise attribute names must be connected in the Schema Mapping policy.

The Schema Mapping rule code segment below connects the Identity Vault 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.

5.3.6 Getting a Record Count from a Query

The following query, sent to the driver, returns the number of users in dom1.po1.

<nds dtdversion="2.0" ndsversion="8.x">
       <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.

5.3.7 Deleting the GroupWise User without Deleting the Identity Vault User

After deleting the user in GroupWise, the driver cleans up the GroupWise attributes in the Identity Vault. 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>

5.3.8 Creating a GroupWise Nickname

GroupWise nicknames can be automatically created when an Identity Vault 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 Identity Vault 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.

5.3.9 Creating a GroupWise Nickname Record

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.)

Example 1

<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>

Example 2

<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>

5.3.10 Specifying a New Resource Owner on an Owner Delete

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 to substitute for the default user. Using the Output Transformation policy, the Identity Vault 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 with the override owner, the resources are automatically assigned to the default user specified in the driver options. The DirXML Script 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>

5.3.11 Specifying a New Resource Owner on an Owner Disable

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 Identity Vault 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 to substitute for the default user. Using the Output Transformation policy, the Identity Vault 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 with 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>

5.3.12 Controlling Creation of GroupWise Accounts

There might be situations where an Identity Vault user is created and you do not want to create a corresponding GroupWise account. In addition, not all Identity Vault 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 by using an extended attribute such as createGroupWiseAccount.

The Identity Vault schema must be extended to include the createGroupWiseAccount attribute. 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>

5.3.13 Moving Users from One Post Office to Another Post Office

When a style sheet is not configured to move GroupWise accounts, we recommend that you use the GroupWise 8.0 or higher snap-ins for user moves.

When the Output Transformation style sheet is configured to move GroupWise accounts, we recommend that user moves be made in the Identity Vault and that the driver assign the object to a new post office in GroupWise. The DirXML script 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>

5.3.14 Adding Additional Attributes to Be Synchronized

You can map up to twenty user Identity Vault 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 Identity Vault 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.

5.3.15 Renaming Users

We recommend that you rename users by changing the naming attribute in the Identity Vault 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. In Example 1 below, the Identity Vault attribute Given Name is used to name the GroupWise account. When Given Name is modified, a GroupWise rename is generated. In Example 2 below, the Identity Vault User object is renamed. 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.

Example 1

(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>

Example 2

(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>

5.3.16 Creating a Gateway Alias

The following DirXML Script 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>

5.3.17 Querying for a Nickname

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. This creates two nickname records (User2a and User2b) that both reference User2c. The following DirXML Script sample code queries the User of the current event for nicknames.

Code Sample

<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>

Result

<nds dtdversion="4.0" ndsversion="8.x">
   <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>

5.3.18 Querying for a Gateway Alias

The following DirXML Script code segment shows how to query in the Output Transformation policy for a gateway alias.

Code Sample

<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>

Result

<nds dtdversion="4.0" ndsversion="8.x">
     <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>

5.3.19 Querying for Internet EMail Address

The following DirXML Script code segment shows how to query in the Output Transformation policy for the Internet Email Address generated by GroupWise.

Code Sample

<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>

Results

<nds dtdversion="4.0" ndsversion="8.x">
   <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>

5.3.20 Synchronizing GroupWise External Users

In your business, you might have several different e-mail applications. Although not all employees 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.

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 following sections explain how to implement this functionality:

Creating External Users

There are three ways you can specify placement when creating external users:

  • In the Placement rule, you can specify the DN of an Identity Vault 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 the Synchronize eDir OrgUnit to GroupWise External Post Office configuration option in Table A-8.

When you create accounts in the Identity Vault for a non-GroupWise user, make sure that gw:classification=“external” attribute 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 Synchronize GroupWise External Entity Objects and Synchronize eDir OrgUnit to GroupWise External Post Office options during driver configuration, 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.

Specifying an External Post Office in an Add Event

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.

Creating External Post Offices

There are two ways you can create external post offices:

  • Let the driver create a GroupWise external post office and associate it to an Identity Vault object, such as an Organizational Unit (recommended). Select Synchronize eDir OrgUnit to GroupWise External Post Office option during driver configuration.

  • 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.

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 Synchronize eDir OrgUnit to GroupWise External Post Office configuration option, 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>

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 you create 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>

5.3.21 Verifying if an E-Mail Address or Gateway Alias Is Unique

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. Ensure that you 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.