3.2.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 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 3-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 3-2 Placement Policy for placing Users in Different Containers

3.2.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 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 using Policy Builder, show how to configure the following actions:

Using 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 eDirectory Container

Figure 3-3 Create Policy

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

Figure 3-4 Adding a User to a Distribution List

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

Figure 3-5 Removing a User from a Distribution List

Removing a User from All Distribution Lists

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

3.2.3 Setting Defaults for GroupWise Attributes

Other attributes can be set in the GroupWise account 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 (Visibility is another common 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>

3.2.4 Configuring the GroupWise UserID

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 following characters: ( ) @ . : , { } * ". The UserID must be unique within its namespace (UserID shares the same namespace as nicknames, resources, and distribution lists.) Do not use a “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.

<!--CN is used to set the GroupWise UserID.
Construct a new CN from Given Name.
--><xsl:template match="add-attr[@attr-name = ’CN’]">
<!-- ignore the current CN and create a new one -->
     <add-attr attr-name="CN">
          <value type="string">
               <xsl:value-of select="../add-attr[@attr-name=’Given Name’]/value"/>
          </value>
     </add-attr>
</xsl:template>

3.2.5 Creating Mappings for Additional Attributes

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 snap-ins. You should configure the same mappings in GroupWise as you do in the driver mappings.

3.2.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="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.

3.2.7 Deleting the GroupWise User without Deleting the eDirectory User

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.

<!-- delete the GroupWise user and clean up eDirectory when the eDirectory user has not been deleted -->
<xsl:template match="modify[@class-name=’User’ and modify-attr[@attr-name=’50000’]]">
     	<delete xmlns:gw="http://www.novell.com/dirxml/gwdriver" gw:original-event="modify">
        		<!-- copy event attributes and association -->
        		<xsl:apply-templates select="@*|association"/>
    	</delete>
</xsl:template>

3.2.8 Creating a GroupWise Nickname

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.

<!--Override the "Create Nicknames" Driver Option-->
<xsl:template match="rename">
     <xsl:copy>
          <!-- Create a GroupWise nickname. -->
          <xsl:attribute xmlns:gw="http://www.novell.com/dirxml/gwdriver" name="gw:create-nickname">true</xsl:attribute>
          <xsl:apply-templates select="@*|node()"/>
     </xsl:copy>
</xsl:template>

3.2.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 following 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>

3.2.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. 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:

<!-- User Delete Reassigns GroupWise Resource
  On an eDirectory User delete specify the GroupWise Account
  to reassign the GW resources to.
-->
<xsl:template match="delete[@class-name=’User’]">
     <!-- copy the delete through -->
     <xsl:copy>
          <!-- Specify the override resource owner on the <delete> -->
          <xsl:attribute xmlns:gw="http://www.novell.com/dirxml/gwdriver"
               name="gw:resource-owner-dn">\GWDRIVERTREE\novell\users\sales\ResourceOwner</xsl:attribute>
          <!-- copy the rest of the stuff through -->
          <xsl:apply-templates select="@*|node()"/>
     </xsl:copy>
</xsl:template>

3.2.11 Specifying a New Resource Owner on an Owner Disable or Expire

If the owner of a resource (a conference room, for instance) is disabled or expired, you can use GCVs to configure the driver to automatically assign that resource to another owner (using GCVs.) 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 style sheet, an override owner can be specified. Using the Output Transformation style sheet, 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 expired. 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 segments for disabling and expiring are:

<!-- When a GroupWise Account is Disabled also specify the GroupWise Account to reassign the GW resources to.-->
<xsl:template match="modify-attr[@attr-name=’50058’]">
     <!-- When Login Disabled is true, reassign the resource -->
     <xsl:if test="add-value//value[.=’true’]">
          <!-- copy the modify through -->
          <xsl:copy>
               <!-- Specify the override resource owner on the <modify-attr> -->
<xsl:attribute xmlns:gw=http://www.novell.com/dirxml/gwdriver
name="gw:resource-owner-dn">\GWDRIVERTREE\novell\users\sales\ResourceOwner</xsl:attribute>
               <!-- copy the rest of the stuff through -->
               <xsl:apply-templates select="@*|node()"/>
          </xsl:copy>
     </xsl:if>
</xsl:template>

<!-- User Expire to GroupWise Expire and Reassign GroupWise Resources
  When the eDirectory User Login Expiration Time attribute is modified,
  change the GroupWise Mailbox Expiration Time and
  specify the GroupWise Account to reassign the GroupWise resources to.
-->
<xsl:template match="modify-attr[@attr-name=’Login Expiration Time’]">
     <!-- copy the modify through -->
     <xsl:copy>
          <!-- copy all attributes through except for the attr-name -->
          <!-- we’ll construct the GroupWise attr-name below -->
          <xsl:apply-templates select="@*[name(.) != ’attr-name’]"/>
          <!-- now create the attr-name attribute with the GroupWise name -->
          <xsl:attribute name="attr-name">50138</xsl:attribute>
          <!-- Specify the override resource owner on the <modify-attr> -->
          <xsl:attribute name="gw:resource-owner-dn" 
               xmlns:gw="http://www.novell.com/dirxml gwdriver">\GWDRIVERTREE\novell\users\sales\ResourceOwner</xsl:attribute>
          <!-- copy the rest of the stuff through, except for what we have already copied-->
          <xsl:apply-templates select="* | comment() | processing-instruction() | text()"/>
     </xsl:copy>
</xsl:template>

3.2.12 Controlling Creation of GroupWise Accounts

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.

The recommended way to control the creation of an account is to define whether a GroupWise account is to be created; for example, by using the createGroupWiseAccount attribute.

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.

<!-- createGroupWiseAccount is used to control creation of the GroupWise Account -->
     <match-attr attr-name="createGroupWiseAccount">
          <value><![CDATA[true]]></value>
     </match-attr>

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

<!--On an eDirectory User Move add the GroupWise Post Office DN 
  based on the User’s new container-->
<xsl:template match="move[@class-name=’User’]">
     <!-- copy the Move through -->
     <xsl:copy>
          <!-- copy the attributes from the <move> element -->
          <xsl:apply-templates select="@*"/>
          <association>
               <xsl:value-of select="association"/>          </association>
          <parent>
               <xsl:attribute name="src-dn">
                    <xsl:value-of select="parent/@src-dn"/>
               </xsl:attribute>
              <!-- Specify the post office DN based on the container -->
               <xsl:choose>
                    <xsl:when test="parent/@src-dn = ’\GWDRIVERTREE\Novell\Users\Sales’">
                         <xsl:attribute name="dest-dn">
\GWDRIVERTREE\Novell\GroupWise\Post Offices\Sales PO</xsl:attribute>
                        </xsl:when>
                         <xsl:when test="parent/@src-dn = ’\GWDRIVERTREE\Novell\Users\Engineering’">
                              <xsl:attribute name="dest-dn">
\GWDRIVERTREE\Novell\GroupWise\Post Offices\Engineering PO</xsl:attribute>
                         </xsl:when>
               </xsl:choose>
          </parent>
     </xsl:copy>
</xsl:template

3.2.14 Adding Additional Attributes to Be Synchronized

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 snap-ins for these attributes to appear in the GroupWise address book.

3.2.15 Renaming Users

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.

<!-- When the attribute used to set CN changes, in this case Given Name, create   an element <new-name> to rename the GroupWise Account
-->
<xsl:template match="modify[@class-name=’User’]">
     <!-- Given Name is used the for GroupWise CN, when it changes do a rename -->
    <xsl:if test="modify-attr[@attr-name=’50091’]">
          <!-- Copy the <modify> through so all changes get made -->
          <xsl:copy>
               <xsl:apply-templates select="@*|node()"/>
          </xsl:copy>
          <!-- generate a <rename> -->
          <rename class-name="User">
               <!-- copy the attributes from the <modify-attr> element to the <rename> element -->
               <xsl:apply-templates select="@*"/>
               <!-- The object was not renamed in eDir so use src-dn for src-dn and old-src-dn -->
               <xsl:attribute name="old-src-dn">
                    <xsl:value-of select="@src-dn"/>
               </xsl:attribute>
               <!-- copy the children from the <modify> element to the <rename> element -->
               <xsl:apply-templates select="node()"/>
               <new-name>
                    <xsl:value-of select="modify-attr[@attr-name=’50091’]/add-value/value"/>
               </new-name>
          </rename>
     </xsl:if>
</xsl:template>

<!-- 
When the User object is renamed in eDirectory, the GroupWise account is not renamed since it is named by the Given Name attribute
-->
<xsl:template match="rename[@class-name=’User’]">
     <!-- Copy the rename through except new-name -->
     <xsl:copy>
          <xsl:apply-templates select="@*|node()[name() != ’new-name’]"/>
          <!-- <new-name> does not change since the GW account is named by the Given Name attribute -->
          <new-name/>
     </xsl:copy>
</xsl:template>

3.2.16 Creating a Gateway Alias

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.

<xsl:template match="add[@class-name=’User’]">
     <xsl:copy>
          <xsl:apply-templates select="@*"/> 
               <add-attr attr-name="Gateway Alias">
                    <value type="structured">
                        <component name="50140"><![CDATA[SMTP]]></component>
                         <component name="50077"><![CDATA[UserOne@novell.com]]>
                        </component>
                    </value>
               </add-attr>
           <xsl:apply-templates select="* | comment() | processing-instruction()
            | text()"/>
     </xsl:copy>
</xsl:template>

3.2.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. 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 criteria.

<xsl:template match="modify[@class-name=’User’]">
     	<xsl:copy>
          		<xsl:apply-templates select="@*|node()"/>
     	</xsl:copy>
     	<xsl:variable name="query">
          		<nds dtdversion="1.0" ndsversion="8.5">
               			<input>
                    				<query class-name="{@class-name}" event-id="query-groupwise" cope="entry">
                         					<association>
                              <xsl:value-of select="association"/>
                         					</association>
                         <!-- User Domain Name -->
                         <read-attr attr-name="50035"/>
                         					<!-- User Post Office Name -->
                         <read-attr attr-name="50062"/>
                         <!-- User Object Name -->
                         <read-attr attr-name="50073"/>
                    </query>
               			</input>
          		</nds>
     </xsl:variable>
     	<xsl:variable name="gw-data" select="query:query($destQueryProcessor, $query)//instance"/>
          		<xsl:variable name="query2">
          <nds dtdversion="1.0" ndsversion="8.5">
              			<input>
                  <query event-id="query-groupwise" scope="subtree">
                       					<search-class class-name="GroupWise Nickname"/>
                       <!-- Referenced Domain Name -->
                       					<search-attr attr-name="50068">
						                          <value>
                               <xsl:value-of select="$gw-data//attr[@attr-name=’50035’]/value"/>
                           						</value>
					                       </search-attr>
                       <!-- Referenced Post Office Name -->
                       <search-attr attr-name="50069">
						                          <value>
                               <xsl:value-of select="$gw-data//attr[@attr-name=’50062’]/value"/>
                          </value>
                       </search-attr>
                       <!-- Referenced Object Name -->
					                       <search-attr attr-name="50070">
                          <value>
                               <xsl:value-of select="$gw-data//attr[@attr-name=’50073’]/value"/>
                          						</value>
                       					</search-attr>
                       <!-- Domain Name of Nickname Record -->
                       <read-attr attr-name="50035"/>
                       			<!-- Post Office Name of Nickname Record -->
                       					<read-attr attr-name="50062"/>
                       <!-- Object Name of Nickname Record -->
					                       <read-attr attr-name="50073"/>
                  				</query>
              			</input>
          		</nds>
      </xsl:variable>
      <xsl:variable name="gw-nickname" select="query:query($destQueryProcessor, $query2)//instance"/>
</xsl:template>

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

3.2.18 Querying for a Gateway Alias

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

<xsl:template match="modify[@class-name=’User’]">
   	<xsl:copy>
	   <xsl:apply-templates select="@*|node()"/>
   	</xsl:copy>
	   <xsl:variable name="query">
      		<nds dtdversion="1.0" ndsversion="8.5">
               		<input>
		          <query class-name="{@class-name}" event-id="query-groupwise" scope="entry">
               			<association>
			        <xsl:value-of select="association"/>
			</association>
               					<read-attr attr-name="Gateway Alias"/>
			     </query>
		    </input>
		</nds>
	    </xsl:variable>
	    <xsl:variable name="gw-aliases" select="query:query($destQueryProcessor, $query)//instance"/>
</xsl:template>
</xsl:template>

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

3.2.19 Querying for Internet EMail Address

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

<xsl:template match="modify[@class-name=’User’]">
   <xsl:copy>
		      <xsl:apply-templates select="@*|node()"/>
   </xsl:copy>
   <xsl:variable name="query">
      		<nds dtdversion="1.0" ndsversion="8.5">
		     <input>
            <query class-name="{@class-name}" event-id="query-groupwise" scope="entry">
                 		<association>
			                 <xsl:value-of select="association"/>
               		  </association>
               			<read-attr attr-name="Internet EMail Address"/>
            		 </query>
         			</input>
		 </nds>
   </xsl:variable>
   <xsl:variable name="inet-address" select="query:query($destQueryProcessor, $query)//instance"/>
</xsl:template>

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

3.2.20 Synchronizing GroupWise External Users

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:

The default driver configuration does not include this customization. To implement this functionality, you should make appropriate changes to your filters, policies, and style sheets based on your business processes.

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

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

     	<add-attr attr-name="50088" >
            		<value type="string">EST</value>
      </add-attr>

3.2.21 Verifying 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.

Here is a query example with a hardcoded value helloworld@mydomain.com. Make sure to replace each instance of the hardcoded 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.

3.2.22 Setting GroupWise Client Options with the Driver

The driver allows you to set some of the environment and send options of the GroupWise client. They are set by using policies. There are many fields for the client options and they are divided up into attributes.

The structure for all attributes is the same. The policy creates the attribute, identifies the correct field, sets the value for the field, and allows you to lock the field.

<attr attr-name=""> <value type="structured"> <component name="lock-level"></component> <component name="value"></component> <component name="field"></component> </value> </attr>

The value and field components must be present. The lock-level is optional. If the lock-level is specified, it must have a value specified as well. The absence of the lock-level is the same as setting the lock-level to 0.

The lock-level locks the ability to modify the field. The lock-level is normally set through ConsoleOne snap-ins. It can be set at the user, post office, or domain level. If the field is locked at the post office, the user cannot modify the field. There are many different lock-levels:

Lock levels can be shared by a group of fields. If you want to lock one field, you must lock all fields. A value must be set, even if it is the default value for the lock to function.