Preparing Your GroupWise System

For a new GroupWise administrator, the prospect of upgrading the GroupWise system can be a bit daunting. Of course, even those of us who have done hundreds of upgrades run into issues occasionally. There is an entirely new “wizard” for upgrading to GroupWise 2014, and while most of you know that we’re not generally fans of wizards (except at Hogwarts) we will use the wizard in this book. Undoubtedly, it is the planning that is of utmost importance. In this chapter we will deal with the planning. It’s important to know that even those of us who have literally done hundreds of GroupWise upgrades make a point to plan out even the simplest of upgrades, making sure to check off all of the necessary steps as we go. (Danita has even been known to carry around a copy of this book to customer sites to make sure nothing is forgotten). So, do not feel like you need to keep a lot of information to perform an upgrade in your head. Keep a copy of the upgrade guide close at hand, and refer to it often during your upgrade, and you’ll be less likely to run into trouble.

Be certain to check the Errata Page for this book ( prior to your upgrade to see if there are any important updates to the process that might not have been available when you downloaded the guide.

Server Requirements

We’ll start with the technicalities! What do you need to be able to perform this upgrade? For the most part, your GroupWise 8.0 or higher server is likely to be adequate for your upgrade, but let’s look at what Novell says you need (and what our recommendations are).

All Servers

64-bit/x86 processor

Any of the following, updated to the latest Support Pack*


SUSE Linux Enterprise Server (SLES) 11, Novell Open Enterprise Server (OES) 11


Windows Server 2008 R2, Windows Server 2012, or Windows Server 2012 R2, all with the latest Service Pack

NetIQ eDirectory™ (optional)

8.8.7 or later, plus the latest Support Pack, with LDAP enabled

Microsoft Active Directory (optional)

Memory and disk space requirements are not substantially different than prior GroupWise server requirements. There are a few agent components and options that can either be installed by default (for example the document viewer agent at the POA) or additionally (such as the Calendar Publishing Host). Generally speaking, however, you will not need to upgrade your current Linux or Windows servers in order to upgrade your GroupWise systems so long as they meet the above requirements (although many sites take the opportunity to do so during the GroupWise upgrade).

You might have noticed a few interesting items in the table above. Let’s talk about a few things to do with the servers:

  • 64 bit OS is now required. Thus, regardless of the other hardware specs of your servers, if you are still running a 32 bit OS you will need to “migrate” your data from your current server to a 64 bit OS.
  • For Linux, GroupWise 2014 is supported on SLES 11, which also means OES 11.
  • NetWare is no longer an available option for GroupWise 2014 server OS. (This was discontinued with GroupWise 2012.)

Administration Requirements

ConsoleOne is not supported for GroupWise 2014 administration. As long as you have a mixed environment, you will need to keep ConsoleOne around for some administration of domains that are older than GroupWise 2014. Novell cautions against using ConsoleOne against a GroupWise 2014 domain. That said, you will need to keep ConsoleOne with GroupWise snapins around for managing Document Management Properties. We will discuss this later in the section entitled “What about Document Management?”

While there are many supported browsers for the Administration Console, in our opinion you will be happier if you simply use Firefox and do not try to force the issue with any other browser. That said, we’ve tested with Chrome and IE11. Safari on the Mac is a problem, because it seems to want a client certificate, even though one is not required, and in our testing no amount of offering a client certificate seems to be accepted.

There are some command line utilities that must be run for administration. On Linux it is best if these are run as root.

WebAccess/Monitor Application/Calendar Publishing Host Requirements

While GroupWise specific agents require a 64 bit processor, the Web based services such as WebAccess, Calendar Publisher and Monitor Application can be run on a 32 bit server – that assumes you still have any of those around!

For the Web Server running the WebAccess Application, Monitor Application, or the Calendar Publishing Host you will need one of the following:


Apache 2.2 plus:

  • Tomcat 6.0 or later (this will be added by the GroupWise installation routine if required.)
  • IBM Java 6 Runtime Environment (JRE)
  • ModProxy Module

Have your Linux repository available when you begin your installation of these products. If any required files are missing during the installation, they will be installed as needed. However, if you do not have the repository available when you begin the installation, you will need to cancel the installation and make the repositories available before restarting the installation.

Windows Server 2008 R2/2012/2012R2

Microsoft Internet Information Server (IIS) 7 or later plus:

  • Tomcat 6 or later
  • IBM Java 6 Runtime Environment (JRE)
  • Jakarta Connector 1.2 or later
  • ISAPI Support

You must manually install IIS with ISAPI support prior to the GroupWise 2014 WebAccess installation. All other items above will be installed by the GroupWise installation routine if necessary.

GroupWise Client Requirements

For the GroupWise client, a few things have changed that are important.


Here are the specifics for the 2014 client:

  • Windows XP SP 3 or better, on a 300 MHz or higher workstation with at least 128 MB of RAM
  • Windows 7 on a 1 GHz or higher workstation with at least 1 GB of RAM
  • Windows 8 or Windows 8.1 on a 1 GHz or higher workstation with at least 1 GB of RAM

Note: Windows 8 or later on a Microsoft Surface Pro tablet is not supported for use with the GroupWise client. Use GroupWise WebAccess instead.

  • 200 MB of free disk space on each user’s workstation is recommended to install the Windows client.


Novell has not updated the Linux client for GroupWise. You can use the GroupWise 8.0.2 HP3 Linux client. The only supported platform is SUSE Linux Enterprise Desktop 10. We have tested the client on various OpenSUSE versions, and even SLES 11, and it seems to perform properly. That said, however, remember that the only supported platform is SLED 10. The client will run with either KDE or GNOME.


Again, Novell has not updated the GroupWise Mac client with GroupWise 2014. You can continue to use the GroupWise 8 Mac client. Interestingly, the Mac client seems to run on the most diverse versions of the operating system when compared to either Windows or Linux! You can run the GroupWise 8 Mac client on:

  • Mac OS 10.4 through OS 10.9 Mavericks

If you are using the GroupWise Mobility Service, your Mac users might be interested in trying out TouchDown for Mac by Nitrodesk. Find out more here –

Software Distribution Directory

The Software Distribution Directory is no more! GroupWise 2014 totally does away with the Software Distribution Directory. This means that those of you who never use it will be able to delete it from your systems with impunity! For those of you who actually used the SDD, you will still be able to perform auto-update. The procedure has simply changed. Also, you can use SetupIP or a desktop management program such as Novell ZENworks Configuration Management to roll out your clients.

WebAccess Changes

If you are upgrading a system older than GroupWise 2012, before you begin your upgrade, you need to understand some very fundamental changes to WebAccess. Prior to GroupWise 2012, WebAccess always consisted of two components: The WebAccess Agent, and the WebAccess Application. The WebAccess Agent (GWINTER) was a WebAccess component that acted as a GroupWise client which gathered information from the POA and supplied the information to the WebAccess Application (the web server component). GroupWise 2012 eliminated the WebAccess Agent altogether. The GroupWise 2012 and newer WebAccess Application communicates directly to the POA via the SOAP protocol.

Because of these changes, a GroupWise 2014 WebAccess installation cannot talk directly to older GroupWise Post Office Agents. Only a GroupWise 2014 POA “speaks” the proper SOAP language that the WebAccess Application will understand. This poses some challenges to sites with many post offices that will be upgraded over an extended period of time. If you will not be upgrading all of your post offices within a short time frame (perhaps a long weekend when you can indicate that WebAccess will be largely unavailable to users), you will need to either leave your WebAccess installation at your current GroupWise version, or you will need to provide for two separate web servers to serve as WebAccess applications for your current GroupWise version and for GroupWise 2014. There are settings for the GroupWise 2014 WebAccess Application that will allow it to serve as the default WebAccess entry point into your system, and then redirect older users to the appropriate web server hosting the GroupWise WebAccess Application for your current GroupWise version.

Like GroupWise 2012, the GroupWise 2014 WebAccess does not include the WebPublisher functionality. If you need WebPublisher, you must retain an older WebAccess installation for your existing GroupWise version to continue to provide the services of WebPublisher.

Of special note, the GroupWise WebAccess Agent had a section for controlling user access to WebAccess. Now that there is no WebAccess Agent, these settings are controlled by settings in the webacc.cfg file and the gwac.xml file. It is very important if you have access control settings in your GroupWise 8 or earlier WebAccess Agent that you export these prior to beginning your upgrade.

We will go over the details in Upgrading Your GroupWise WebAccess later in this guide.

GWIA Considerations

Upgrading your GroupWise Internet Agent is a fairly simple process. However, there are some challenges that are presented if you intend to have a “mixed” system (i.e., GroupWise 2012 AND older post offices) for any length of time. Here are the issues at hand:

  • Your GWIA cannot be upgraded to GroupWise 2014 until the domain that owns it is upgraded to GroupWise 2014.
  • When using the GWIA as a POP3 or IMAP4 “client”, it is actually a client. You cannot access a GroupWise 2012 or earlier post office with the GWIA via IMAP4 or POP3, If it is attempted, you will see a “login failed: D058” in your GWIA log.
  • On the other hand, if the GWIA is being used only for SMTP services, there are no issues with a mixed system.

So, as you can see, it’s a good idea to get your post offices upgraded to GroupWise 2014 on a scheduled roll-out so that you are not surprised by any of the possible issues with mixed post offices. That said, many sites operate in a “mixed” system quite nicely for an extended period of time. You must simply make sure that your plans take the above caveats into account. If you need to have POP3 services for all users in your system, you might consider having two GWIAs – one for the GroupWise 2014 users, and one for your older post office users. If you are using IMAP4, you might consider opening up IMAP4 directly from the post office agent, rather than using the GWIA if you have a mixed system (versions 6.0 and later of GroupWise allow for IMAP4 at the post office agent).

What about Document Management?

Prior to GroupWise 2014 we would get asked about this at almost every upgrade, and our answer was always “Novell has not made any enhancements to GroupWise Document Management, but the functionality is generally the same”. We cannot say that for GroupWise 2014. It is true that Document Management still works in GroupWise 2014. It is true that you can create new Libraries in the GroupWise Administration Console. It is true that you can manage all of the Rights and run Library Maintenance through the GroupWise Administration Console.

There are some definite changes that you need to be aware of though!.

Document Properties Maintenance

There is no facility in the Administration Console to edit the Document Properties for GroupWise Libraries. There is also no facility for this in ConsoleOne on Linux. In order to edit the properties, you must run gwdpmb32.exe on Windows. This is found in the c:\novell\consoleone\1.2\bin directory on a server or workstation where ConsoleOne with the GroupWise snapins is installed.

There is no requirement that you be logged into eDirectory to run this application. It DOES have dll dependencies provided by the Novell Client installation. Thus, you will need a PC or Windows server with the Novell Client loaded, with access to the Post Office directory in order to run this application.

If you are attempting to run this application on a 64 bit Windows server (and we’ll bet you are!), you must add the gwdpmb32.exe application to your list of excluded programs in the Data Execution Prevention list. To do this, follow these steps:

  1. Go to Control Panel | System | Advanced System Settings
  2. Click on the Performance button.
  3. Click the Data Execution Prevention tab.
  4. If DEP is enabled, you must change the setting to “Turn on DEP except….”
  5. Add c:\novell\consoleone\1.2\bin\gwdpmb32.exe to the list of exceptions.

To launch the application, run

c:\novell\consoleone\1.2\bin\gwdpmb32.exe /po=<PathToPO>

so, for example,

c:\novell\consoleone\1.2\bin\gwdpmb32.exe /po=d:\grpwise\pos\calpo

Running the Document Properties Maintenance Standalone

No Application Integrations

The GroupWise 2014 client no longer provides any ODMA integrations for applications. Here are the ramifications of this:

  • Users must create all new documents from the GroupWise client. There will no longer be the ability to save a document directly into the GroupWise client from once integrated applications like Word, WordPerfect, etc. (i.e., Save or Save As will no longer invoke a GroupWise save dialog).
  • Documents must be opened from the GroupWise client. There will be no ability for a user to be in Word, for example, and choose File|Open and see a GroupWise dialog.
  • Since ODMA integrations are no longer present, a user cannot rename a GroupWise document without breaking the link to the library. For example, if a user opens “Letter to Danita” into Word from GroupWise, makes changes and then saves the document as c:\temp\lettertopaul.docx, this document will no longer be in the GroupWise library. The GroupWise client monitors the document that was opened to the temp directory through the library, and when you close that file it is returned to the library. The file name is a very important part of this process.

If you rely heavily on GroupWise Document Management with Application Integrations, you may need to keep your current GroupWise client until users can be properly trained.

Enabling the HTTP Monitor for Your Agent

We have found that there are many GroupWise sites where the HTTP (Web) Monitor is not in use. Especially with GroupWise 8 and later, these HTTP Monitors have become more and more important. If you define a userid and password for the HTTP Monitors, you can perform all of the functions that you used to perform at the GUI Consoles for your agents, as well as new functions that were not available on the GUI Consoles. If you do not have your HTTP Monitor enabled, now is a good time to do so.

In ConsoleOne, click on the GroupWise System Globe, and perform the following steps:

  1. In the dropdown list that typically shows “Users”, change the setting to “Message Transfer Agents.”
  2. Find the MTA for your domain, right-click and choose Properties.
  3. Now click on the triangle in the GroupWise tab and change to Network Address.
  4. Make special note of the HTTP port that is defined for this agent. By default, the HTTP port for the MTA is 7180. For the POA, the default port is 7181. 9850 is the default for the GWIA.
  5. If there is nothing in the HTTP port field, put 7180 (or another port of your choosing).
  6. Now, on the GroupWise tab, change to the Agent Settings screen. Scroll down to the HTTP Monitor settings. If you have never enabled the HTTP monitors for your agents, you will need to decide on a good userid and password for the HTTP monitors. Please note that this is neither an eDirectory user nor a GroupWise user. This is an entirely made up user and password solely for the use of the HTTP monitors. If all administrators in your organization will have rights to use the HTTP monitors, then it is a good idea to have the same userid and password for all agents. If you need to limit rights to some agents to various groups, set up a userid and password for each group of agents that will be monitored. Enter the userid and password that you have decided on here in this screen.
  7. Save your changes.

You should do this for all of your agents prior to beginning your upgrade so that you have access to them immediately after the upgrade if necessary. If you forget to do this, and they are needed during the upgrade, we will show you how to start the agents from the command line using the appropriate http monitor switches.

GroupWise High Availability Agent Considerations

If you are using the High Availability Agent, the settings will not come over after the upgrade. Thus, before you even install the GroupWise Administration Service, you must copy your High Availability settings so that you can re-enable the GWHA afterwards.

Edit the /etc/init.d/grpwise-ma script and find your MA_OPTIONS settings. For example, ours are:

MA_OPTIONS=”–hauser gwha –hapassword gwhapassword –hapoll 120 –httpagentuser gwweb –httpagentpassword gwweb –httpmonuser gwmon –httpmonpassword gwmon”

Save this information in a text file for use in “Re-enabling the GroupWise High Availability Agent” on page 166.

Verifying MTA Network Settings

When we install the Administration Service in the following chapter, the MTA network settings for your domains will be very important.

In ConsoleOne, click on the GroupWise System Globe, and perform the following steps:

  1. In the dropdown list that typically shows “Users”, change the setting to “Message Transfer Agents.”
  2. Find the MTA for your domain, right-click and choose Properties.
  3. Now click on the triangle in the GroupWise tab and change to Network Address.

The Admin Service will use the network address as defined on this page. If the network address is using an IP Address, then any time you are required to access the admin service during a system modification, you will need to use the IP Address. If the Network address is defined using a DNS name, then anytime you will be required to access the admin service you will need to use the DNS name. This will pertain to tasks such as adding or upgrading secondary domains or post offices that are not on the same server as the Primary domain, and installing the plugins for MMC or iManager.

Modifying Linux Network Settings

When configuring the network adaptor on SLES/OES, there is a setting in the Network Settings that reads “Assign Hostname to Loopback IP”.

Linux Network Settings

On Linux (SLES and OES) do not configure the network Card with this setting enabled. If you do, the loopback address will become the IP Address that the Admin Service binds to (“Installing the GroupWise Administration Service” on page 25), and this will prevent you from accessing the Admin Service from any process other than the Administration Console. This would affect iManager Plugin, MMC Plugin, the WebAccess Administration Console, etc.

A Quick Health Check

We hesitate to insist that major GroupWise maintenance be performed on your GroupWise system prior to the upgrade. You should ensure that your GroupWise system is in good working order, but because we feel that this should be done routinely anyway, and should not be left until the week of your upgrade! That said, there are a few things that you can do to make your GroupWise upgrade less stressful.

  • Clean up your GroupWise system. Quite honestly, there is no real technical reason to get rid of old users, empty trash and implement cleanup options, but it’s a perfect time to do so if you need to. Users are typically much more open to making cleanup changes when an upgrade is pending, simply because they accept that “changes” are coming and that might mean they need to help make the upgrade a smooth operation.

There are licensing changes that will affect some sites regarding inactive accounts. If you have inactive accounts and wish to avoid paying for “inactive” GroupWise licenses, you may wish to archive the inactive accounts and delete them. It is not our intention to fully discuss GroupWise licensing policies, as we do not sell GroupWise product, and are certainly not the experts. Contact your GroupWise sales representative if you have any questions on licensing.

  • Additionally, if you intend to integrate your existing eDirectory or Active Directory (yes, you read that right – GroupWise 2014 can integrate directly with Active Directory) with GroupWise, having a lean and clean directory will simplify some of the integration steps later. See the section below entitled “Preparing Your LDAP System” if you do intend to integrate and maintain the synchronization connection between your current eDirectory tree and GroupWise 2014.
  • Run some basic GWCheck procedures. We know that you are running routine structure and contents checks on your post offices, but it’s a good time to make sure that your routines are running properly, that there are no oddities in the logs, and that you are ready to upgrade!
  • Verify that all links between MTAs and POAs are open and communicating properly.

Preparing Your LDAP System

GroupWise 2014 has new “directory” options, which we will discuss in detail in the Chapter entitled “Directory Integration and Synchronization” If you intend to continue to synchronize eDirectory with your GroupWise system, long-term, or just short-term while you transition to Active Directory, it is recommended that you verify that your GroupWise system is configured properly for LDAP synchronization. This is not the same thing as LDAP authentication (although LDAP authentication to eDirectory provides some of the pieces we need). LDAP synchronization is the mechanism that keeps the GroupWise address book synchronized with changes made in eDirectory (for example, changing a user’s phone number, department or address, etc.). LDAP sync also permits the publishing of users’ e-mail addresses back to the directory.

By default, MTA Directory Sync is not enabled with GroupWise 2012 and prior systems. eDirectory Sync at the MTA was only needed in the case of modifying eDirectory address book attributes outside of the GroupWise enabled ConsoleOne. So long as every administrator used ConsoleOne with GroupWise snapins, eDirectory changes such as phone numbers, street address, department and other eDirectory fields were automatically written to the wpdomain.db file and then spawned out to the other domains and post offices in the system. If, however, someone were to modify these directory fields in iManager, or use a third-party help desk tool that was not GroupWise aware, the MTA could synchronize the system during a daily scheduled event. Because MTA synchronization was disabled by default, and because it was only needed in specified instances, many systems are not enabled for eDirectory Synchronization.

If you have no need for further eDirectory synchronization (for example, you are moving to Active Directory, or you wish to dissociate your users from the eDirectory and run GroupWise as an entirely stand-alone system), then the following steps are not necessary for your installation. You can skip this section and continue on with “The Upgrade Overview” on page 22.

If your current system meets the following criteria, you may want to complete this section to ensure your LDAP Synchronization is properly set up and operational.

Note: While you can integrate your upgraded GroupWise system with your eDirectory LDAP server after the upgrade, it will require a few extra steps. It’s better to get it done in your existing system.

  • Your system will remain on eDirectory.
  • You are running GroupWise 6.5 or later on Linux
  • You are running GroupWise 8 or later on Windows

If your system is on NetWare, or does not meet the Windows criteria above, you will need to perform the post upgrade integration of eDirectory. Your NetWare MTA may even be properly set up to do eDirectory synchronization, but it does not use LDAP as the mechanism. Thus, a perfectly configured NetWare system will still need some re-configuration once you have migrated and upgraded to GroupWise 2014. So, if your GroupWise system is on NetWare, or a Windows version prior to GroupWise 8, you should skip this section and jump on down further in this chapter to“The Upgrade Overview”. After your upgrade, you can go to “Correcting a Failed Directory Integration” on page 81to deal with eDirectory Integration.

Testing Your Current System

Since there are many steps involved with setting up eDirectory synchronization, before you dive in it’s probably a good idea to see if your current system is already properly configured. eDirectory Synchronization is a Scheduled Event that is created for an MTA object. However, having the MTA Scheduled Event enabled is only one small step in the configuration. In fact, this event is enabled by default, so many sites just assume that eDirectory synchronization is always working. A very simple check would be to use iManager or a version of ConsoleOne without GroupWise snapins to edit the phone number field for a user today. Tomorrow go into the GroupWise Address Book in your client and see if the phone number has changed for the GroupWise Address Book. If it has, then eDirectory synchronization is activated and working. If it has not, then you can follow the steps below to configure and test eDirectory Sync. Now remember, if you have NetWare MTAs in your system, the above test may very well work, but it would still not necessarily be configured properly, unless you also have Linux/MTAs also performing the sync. Also, if you are using other tools like the IDM driver for GroupWise, you could see your changes sync to GroupWise and assume that GroupWise’s own eDirectory synchronization is making the changes. If you have any doubts about the configuration, then the next steps should be completed.

Check the MTA Platform Settings

  1. In ConsoleOne, click on the Primary Domain in the GroupWise View. The reason we specify the Primary Domain is that since you must upgrade the Primary Domain first, it’s just less confusing to configure this MTA prior to your initial domain upgrade.
  2. Change the item dropdown to Message Transfer Agents.
  3. Choose your MTA and edit the properties.
  4. Verify that your Platform is correct. We find that many times systems have been moved from NetWare to Linux or Windows, but the Platform for the agents was not modified. Having the wrong platform designation here can cause the synchronization setup to fail.

The MTA Properties

  1. Save the change.

Check or Create your LDAP Server

Once your MTA platform has been verified, we can continue.

  1. In ConsoleOne, go to Tools|GroupWise System Operations|LDAP Servers. If you have never used LDAP Authentication for your users, or if you have never set up eDirectory Synchronization for a Linux or Windows MTA, this window might be empty. If LDAP servers exist in this section, and you are using LDAP authentication for your users, then we can generally assume that the LDAP servers are properly configured, and you can move on. If not, perform the steps below to define your eDirectory LDAP servers.

    Empty LDAP Servers List

  2. To add a new server, click Add.
  3. Give your LDAP Server a name
  4. If your server requires SSL for LDAP, check the SSL box and point to the server certificate key file for the LDAP server.
  5. Enter the IP address for your LDAP server.
  6. Most people will set their servers to Bind for the authentication method. This allows password restrictions to be honored for the logins.
  7. Click OK

If you have a single tree for your GroupWise system, you will need only configure your primary domain MTA for eDirectory synchronization. If you have multiple trees represented in your GroupWise system, you will need to configure a separate MTA (and LDAP server) for each tree. Make sure you have LDAP servers for each eDirectory tree before you move on.

Check or Configure eDirectory User Synchronization

When you have finished the LDAP server configuration, go to Tools|GroupWise System Operations|eDirectory User Synchronization. You may see multiple MTAs listed here, but as mentioned, you only need to configure one MTA per LDAP tree in order to complete the tasks at hand. In our situation, our MTAs show disabled. Even if your MTAs show enabled, it is a good idea to check the settings.

The eDirectory User Synchronization Configuration

  1. Click on the MTA you wish to configure/verify and choose Configure Agents.
  2. A list of your agents will appear. If you have never configured eDirectory synchronization it is likely that all of your agents will show “No” in the eDirectory Access. Regardless of the settings here (i.e., Enabled/Disabled or eDirectory access available/unavailable), choose your Primary Domain MTA and click Set Up eDirectory Access.
  3. Configure Agents

  4. You should see the figure in Figure 2-7 below. If you see the figure in Figure 2-8 below, your MTA is still identified as NetWare, and you will need to go back to the steps in “Check the MTA Platform Settings” above to modify the Platform and turn to this section. If your MTA really IS running on NetWare, then these steps are not useful to you. You should stop now and configure your eDirectory synchronization after the upgrade has been performed.
  5. linuxinstall040.tif

    Agent Access Control


    NetWare Agent Access Control

  6. Choose the LDAP server you wish to use for Synchronization and click Set Preferred.
  7. Browse for an LDAP user for a user who has browse rights to the user objects in your system, as well as create rights to user properties in order to publish email addresses back to the directory. We have listed the specific attributes affected in “Directory Rights Requirements” on page 63.
  8. Browse to and select the LDAP Group for your eDirectory server.
  9. Click “Set Password” and enter the password for the LDAP user you chose.
  10. linuxinstall111.tif

    LDAP Server Setup

  11. Make certain that you click “Set Preferred” here. If there is not a check box next to your LDAP server, even if there is only one listed, your sync will fail.
  12. Click Okay to return the MTA list. The eDirectory Access field for this agent should say Yes.
  13. If the State is Disabled, click the Enable button.
  14. linuxinstall042.tif

    Enable your agent

  15. You will be returned to the eDirectory User Synchronization Configuration screen. You may very well still see a status of Disabled.
  16. Click Change Assignment
  17. Click on your primary MTA that you have enabled above and click OK.
  18. Now at your final screen your MTA should show enabled.
  19. linuxinstall044.tif

    MTA is enabled

Check Or Configure Your MTA Scheduled Event

Finally we must check that a Scheduled Event is enabled for eDirectory Synchronization.

  1. In ConsoleOne, click on the Primary Domain in the GroupWise View.
  2. Change the item dropdown to Message Transfer Agents.
  3. Choose your MTA and edit the properties.
  4. On the GroupWise Tab, click on the triangle to the right, and select Scheduled Events. There will be an entry for Default eDirectory (or NDS) User Synchronization Event.
  5. Click Edit to see the details.

    The Default eDirectory User Synchronization Event

The default for this event is 1:00 a.m. local time. In order to test this now, rather than waiting until tomorrow, you can change the time. We recommend that you make this at least 30 minutes in the future, to allow for other back-end synchronization processes to have occurred before you proceed. Ours has been changed to 9:30 a.m.

  1. Click Okay, and make certain that the event is enabled (checked).
  2. If you look at your MTA log, you will see a restart command, and then you should see an entry like this:

09:19:04 F4C5 Scheduled Event Settings:

09:19:04 F4C5 Today’s eDirectory User Sync Event Times:

09:19:04 F4C5 09:30:21

If you do not see the restart command, it is helpful to manually restart the MTA.

  1. Use iManager or ConsoleOne without any GroupWise snapins to change something that needs to synchronize to GroupWise. For example, a phone number.

At the appointed time (9:30 a.m. in our case), your MTA verbose log should show something similar to the following:

09:30:21 F3C7 Start eDirectory user synchronization.

09:30:21 F3C7 Connecting to LDAP server Sync at address

09:30:21 F3C7 Checking Beta

09:30:22 F3C7 Checking Caledonia

09:30:22 F3C7 Sync Users for Domain: Caledonia

09:30:22 F3C7 Checking post office: Highlands.GW-Cal.CNC.CNC

09:30:22 F3C7 Checking Caledonia.Highlands.Nessie

09:30:22 F3C7 Update NGW: GroupWise ID:Diane.CNC



09:30:23 F3C7 Checking Caledonia.Highlands.Dominique

09:30:23 F3D7 Update Telephone Number:555-555-7368

09:30:23 F3D7 Checking Caledonia.Highlands.Joe



09:30:24 F3C7 eDirectory user synchronization finished.

Now, when we later perform our upgrade, your eDirectory synchronization should be properly configured automatically.

The Upgrade/Migration Overview

Depending on whether you are upgrading in place or moving/migrating your system, you should take a look at one of the following:

The Upgrade Overview
The Migration/Upgrade Overview

So, it’s time to get started. We would recommend that you read this entire book before you begin your upgrade. We will discuss issues throughout the book that can influence your upgrade plan, and it’s best to look at all of the options before beginning

Before we actually get down to the business of upgrading we need to discuss the new GroupWise Administration Service. The next chapter will be dedicated to that!