In order to use GroupWise Mobility Service, you need to be on one of the following versions of GroupWise:
- GroupWise 2012 Support Pack 2 or later
- GroupWise 8 Support Pack 2 Hot Patch 3 or a later Hot Patch, on Linux or Windows (no NetWare)
- GroupWise 2014 (Windermere), when it ships
It is suggested that you be on the most current version of GroupWise, as many functions and features have been optimized for the newest Post Office Agents.
You will need to create a trusted application (see “Creating the Trusted App”) in your GroupWise system for GroupWise Mobility Service. Additionally, any Post Office Agent that services mobile users must have SOAP enabled. It is recommended that the POA also have SSL enabled for SOAP to secure data traversing the network.
Your GroupWise system must have Internet Addressing enabled.
GroupWise Mobility Service is not compatible with GroupWise 7 or older systems.
The server requirements for GroupWise Mobility Service are fairly straightforward:
- SUSE® Linux Enterprise Server (SLES) 11 64-bit, plus currently SP2 and SP3 (you cannot use a 32-bit SLES server for Mobility)
- 64-bit/x86 processor
- 2.2 GHz processor; multi-processor system recommended
- 4 GB RAM (Novell says this will support 300-750 devices, depending on usage) up to 8 GB of RAM for a maximum of 750 user/1000 devices
- 45 GB system partition
- 200 GB data partition (preferably mounted as /var)
- Static IP Address
- Available Public IP Address that will listen on port 443*
- DNS host name for device synchronization. For example, have your DNS provider set a host name of gw.company.com for the Public IP Address you designate for your Mobility Service
As a SLES Add-On, it is assumed that GroupWise Mobility Service will be installed as an “appliance” so to speak, with no other processes running on the server.
Note that in our testing for very small systems, we have run GroupWise Mobility Service in a virtual machine with only 2 GB of RAM, and a much smaller hard drive.
The hard drive space will really depend on how many users you are providing services for, and how much data they have. The bulk of the data for GroupWise Mobility Service is stored in /var/lib/pgsql. The log directory is /var/log/datasync. It can be useful to configure your SLES server with /var as a separate partition for future expansion needs. You might even partition /var/lib/datasync/syncengine/attachments as an entirely separate partition as well, due to the larger needs for attachments. GMS is very I/O intensive. Thus, for larger and extremely active systems, we even suggest to have different storage channels per partition.
We highly encourage that you create your GroupWise Mobility Service as a Virtual Machine when possible. Mobility comes out with updates more often than many other components in your GroupWise system, and it is of great convenience to simply snapshot your system, upgrade and be off and running, knowing that if a particular build exhibits bad behavior you can simply roll back to a machine a couple of days old, and lose very little data. Since the Mobility is a “pass between”, all that rolling back would lose is individual user configuration that has happened in the meantime, such as choosing which address books to synchronize.
* Most sites these days have more than one public IP address in their IP range. While there are some convoluted workarounds, if you intend to have both GroupWise WebAccess and GroupWise Mobility Service, you really need to have two different public IP addresses that can separately listen on port 443. It is a great inconvenience to users to require a non-standard port for WebAccess SSL, and many mobile devices simply will not work if you try to use a port other than 443.
GroupWise Mobility Service needs to talk to a “GroupWise” directory. This can be eDirectory via LDAP, or the GroupWise directory itself. GroupWise Mobility Service does not actually support any LDAP directories other than eDirectory. We will discuss Directory considerations later in this chapter.
In general, any device that can support Microsoft Exchange ActiveSync Protocol 2.5 through 12.1 can use GroupWise Mobility Service 2.0 to some extent. There are, of course, a myriad of such devices out there. A small listing includes:
- Android 4.1.x or later
- Apple iOS 6.2 and 7.x
- Blackberry 10
- Symbian 9.x
- Windows Phone 7.8
- Windows 8 (Phone, Tablet, and Desktop)
A number of third-party ActiveSync applications have been tested by Caledonia, including NitroDesk’s Touchdown (iOS/Android/Mac/Windows), Fixmo’s SafeZone, AstraSync for BlackBerry and NotifyLink’s ActiveSync client. Your mileage may vary!
For all other devices, while they may be supported, there is a great deal of difference in the functionality from one device to another. Novell has a Wiki that is user contributed to help with connectivity issues for various devices. You can find information at http://wiki.novell.com/index.php/GroupWise_Mobility_Devices. It is recommended that you peruse this Wiki for information on devices that your users might wish to connect to GroupWise Mobility Service. Of course, it is also very helpful for the rest of the community if you and your users update this Wiki with information from your own experience that might be useful to the community as a whole.
Basic Overview of GroupWise Mobility Service Operation
In addition to a new name, there are a few changes to names of components and processes for GroupWise Mobility Service 2.0.
With Data Synchronizer, you had “connectors”. An engine in the middle allowed disparate systems to talk to each other. So, for the earlier Mobility Pack, there was a GroupWise Connector and a Mobility Connector. These have been replaced with a GroupWise Sync Agent and a Device Sync Agent. And as an aside, you can no longer “delete” these Agents, as you could (accidentally, and with unhappy consequences) the individual Connector in the 1.x version.
Also, the system had many references to “datasync” throughout. And while Novell has changed the main scripts to start and stop the Mobility service from “datasync” and “rcdatasync” to “gms” and “rcgms” respectively, you will find that most directory structures and underlying scripts and processes will still use the “datasync” references.
GroupWise Mobility Service has five basic components that are installed:
- Synchronization Engine: The middle-man. This Engine still exists, but is not as active as in prior versions. The Synchronization Engine’s main function is to provide the mechanism for the sync agents to communicate with each other. With GMS 2.0, however, the agents talk directly to each other whenever possible.
- GroupWise Sync Agent: The GroupWise Sync Agent listens by default on port 4500, talks to the Post Office Agent via SOAP, and saves its data into a PostgreSQL database.
- Device Sync Agent: The Device Sync Agent listens on port 443 and talks to devices via Microsoft Exchange ActiveSync protocol. This allows GroupWise to communicate with any ActiveSync enabled device as though the device were talking to an Exchange ActiveSync server.
- Mobility Admin Console: Administration of the system after installation is performed through a Web Admin tool. The Mobility Admin Console runs by default on port 8120 on GroupWise Mobility Service. This port can be changed, and we will go over that in the chapter entitled “Administering GroupWise Mobility Service”. Novell lists Internet Explorer 10 or later, Firefox 20 or later, Safari 6 or later and Google Chrome 26 or later as supported browsers for administration. Not only is the Mobility Admin Console used by the administrator for defining and administering GroupWise Mobility Service, this Console can also be used by end users to change and refine the address books and folders synchronized by the Service.
- Monitor Service: The Monitor Service can alert the administrator to events and problems with GroupWise Mobility Service, including the availability of POAs and other processes.
Multiple GroupWise Mobility Services
As Novell suggests, a single server running GroupWise Mobility Service can manage up to 750 users with 1000 devices. Your mileage may vary here, and it’s possible to exceed these limits, depending on usage. If you have more than 750 users who need access to GroupWise Mobility Service, and you find your performance lacking as you exceed these numbers, you can install multiple servers running GroupWise Mobility Service. In addition to overall “load” of the system, you might choose to have multiple servers running GroupWise Mobility Service to accommodate users in remote sites without sending all of the data to one server.
Directories and GroupWise Mobility Service
Throughout the product installation and configuration you will see references to both LDAP (Lightweight Directory Access Protocol) and GroupWise when defining your “Directory” for access. There are two different considerations here when choosing your Directory:
- User Provisioning
- User Authentication
There are some historical considerations that will be useful to discuss here, and then we can decide how you will choose your Directory type for each option.
First let’s talk about GroupWise and authentication in general. As you probably know, GroupWise can use either native GroupWise authentication or LDAP authentication to validate user access to the Post Office. There are generally two reasons why a company chooses LDAP authentication over GroupWise authentication. The first is users do not need to remember two different passwords, and the second is that password restrictions can be enforced for GroupWise accounts. GroupWise can theoretically authenticate to any LDAP server, including both eDirectory and Active Directory. For GroupWise 2012 and prior, eDirectory is automatically integrated with GroupWise, and Active Directory can be used as the LDAP source by populating the LDAP field for each user manually. Beginning with GroupWise 2014 (Windermere), Active Directory will be supported as a Directory source for integration with GroupWise.
GroupWise Mobility Service started out as a module in Novell Data Synchronizer. This was a product that used eDirectory as its provisioning source. The initial version of Data Synchronizer Mobility Pack could only use eDirectory for provisioning AND authentication. This posed some problems, as sites using GroupWise authentication at the POA would find that users had different eDirectory passwords than their GroupWise passwords. The user had to use the eDirectory password for authentication from devices, and not the “email” password. This was very confusing for many users.
Version 1.1 of the Mobility Pack introduced GroupWise authentication. From that point, a site could use the GroupWise passwords for devices. Provisioning users still required the eDirectory LDAP server though. The addition of GroupWise authentication also allowed sites who used AD as their GroupWise LDAP authentication server to implement the Mobility Pack server. Essentially, with Version 1.1, the Mobility Pack could simply query the POA for authentication, and no matter which password the POA was configured to use (GroupWise or LDAP), the POA would be in charge of the authentication.
There is little doubt that the “decoupling” of GroupWise from eDirectory with GroupWise 2014 (the next version of GroupWise which will ship shortly after GroupWise Mobility Service 2.0) prompted some major changes to GroupWise Mobility Service. If sites will no longer need ANY third-party directory service to install and manage a GroupWise system, GroupWise Mobility Service has to address the needs of a “standalone” GroupWise system.
Additionally, since “External Entities”, “Unassociated Users” and “Resources” have no LDAP passwords, the only way you can use those entities in GroupWise Mobility Service is to use GroupWise authentication as your source.
Finally, if you choose to use LDAP as your provisioning type, you will define your administrators from the LDAP server, and use the LDAP passwords for logging into the Web Console. If you use GroupWise provisioning, you will use the root user of the GMS server itself.
So, what do you choose? While we’re not sure that it’s a stated direction at this point, it seems pretty likely that LDAP is only available here as a “transitional” choice. In other words, it’s quite possible that in the future LDAP will no longer be a choice for provisioning and/or authentication. It’s our opinion that the simplest setup is to use GroupWise for both provisioning and authentication. Some sites upgrading from older versions of the Mobility Pack will no doubt choose to just “leave” things the way they are. That said, the simplicity of using GroupWise for both provisioning and authentication cannot be overlooked. Moving forward, we certainly recommend that you move away from LDAP for your provisioning and authentication.
The Device Sync Agent is based on Microsoft Exchange ActiveSync Protocol Version 12.1. You can find a comparison of various ActiveSync versions here: http://en.wikipedia.org/wiki/Comparison_of_Exchange_ActiveSync_Clients. In addition to the standard two-way synchronization of mail, calendars and contacts, a few items are noteworthy:
- Calendar Notes are generally synchronized to devices as All-Day-Appointments, as they have been with most synchronization products in the past, including the older GroupWise Mobile Server, Blackberry Enterprise Server, and even desktop synchronization tools like Intellisync Desktop.
- Calendar item attachments are not synchronized with the Mobility Service. This is a GroupWise only feature by and large. Outlook, for example, does not have the ability to have attachments on calendar items. Thus, while you may have attachments on GroupWise calendar items, they will not synchronize to the devices.
- Supported attachments will be downloaded to devices, according to the size limitations set by administrators. If an attachment is too large, users receive a text attachment indicating that the real attachment was not downloaded.
- Some devices cannot view messages “forwarded as attachment”. WebAccess must be used for these devices to view an attached message that has been forwarded in this manner.
- GroupWise Mobility Service initially gathers the past 3 days of mail (from all folders) for the user to synchronize. Users can request additional (or fewer) days of mail from their devices. While GroupWise Mobility Service by default contains mail from all folders, mail is only delivered to devices when requested. Typically the “Inbox” (i.e., the GroupWise Mailbox folder) is synchronized to all devices, and mail from other folders only is synchronized when the user accesses said folder. Users can log into the Web Portal and limit the folders that are delivered to Mobility.
- GroupWise Mobility Service supports synchronization of contact photos when supported by the device.
- GroupWise Mobility Service will send calendar items from all calendars in the user’s mailbox (except for calendars to which the users are a sharee and not the owner). Depending on the device, these will be aggregated into a single calendar, or represented as individual calendars as they are in the GroupWise client.
- Shared folders and shared calendars are not supported except for the owner of the folder or calendar. For shared calendars, the GroupWise Calendar Publishing Host can be a good workaround for devices that have the ability to subscribe to “Internet Calendars.” Beginning with Version 1.2.5 of GroupWise Mobility Service, Resources can by synchronized, so moving shared calendars to Resources as owners can help with this, by allowing all users access to “log in” as the Resource on their devices as a secondary ActiveSync user configuration.
What’s Changed in GroupWise Mobility Service since our last book.
Here’s a rundown of how GroupWise Mobility Service has changed over the past few years. All version 1.x was known as Data Synchronizer Mobility Pack. With version 2.0, the name has changed simply to GroupWise Mobility Service.
This was the initial release of GroupWise Mobility Service, and was the introduction of ActiveSync to GroupWise. The biggest “oddity” to this version was that LDAP authentication for the devices caused great confusion. Users had to enter their eDirectory password “to receive mail” even if their GroupWise password was different.
- This version increased the number of supported users to 300.
- At this point, GroupWise authentication was added, allowing sites that did not use LDAP authentication (or even sites that used AD authentication) to provide the “GroupWise” password for the devices.
- Novell also added the ability to choose whether some folders were never synced to devices, thus cutting down on the “clutter” of folders on devices that would not collapse folder trees. This also cut down on the amount of data sent to GroupWise Mobility Service, but I don’t think that’s what excited the users the most.
- This version also enabled “discussion notes” (i.e., posted email notes) to be synchronized to devices.
- Version 1.1 also brought about security policies for device passwords.
- An “oversize” text file was replaced for attachments that were too large to send to the device, alerting users that an attachment exists for the email.
- Supported users increased to 500.
- Reply/Forward icons were fixed so that the GroupWise Client would show that items were replied to or forwarded from the devices.
- HTML Mail was added for iOS devices.
- This version added a delivery failure message that would alert the device user that a message sent could not make it to GroupWise. The most common reason for this would be your mailbox was overlimit and you have no “sending rights”.
- Archived items that use “stubbing” protocols no longer have the stubbed subject sent to the devices.
- Task synchronization was added as a “preview” option.
- This version added a “poll now” button to the LDAP Group polling in the Global Settings.
- A disk-space monitoring tool was added to stop sync processing if the disk space taken reached 90%. This took some administrators by surprise, and I fended many support questions about this one.
For the most part, this version was bug fixes and stability enhancements. The most notable new change was:
- The administrator can now limit the number of devices a user can connect to GroupWise Mobility Service.
- SLES 11 SP2 gained support with this version.
- Zenworks Mobility Management Integration was added.
- Log File storage was optimized.
The biggest changes to note in this version are:
- Users and Groups are no longer defined under each connector, but as a whole for the entire system.
- A new Global Status Monitor was in preview and has been greatly expanded on in version 2.0.
- New devices can be quarantined, so that new devices do not just pop onto GroupWise Mobility Service without warning.
- Inactive Devices can be removed from the system automatically after a specified time period.
- Resources can be synchronized.
- You can access the WebConsole as root, in case LDAP is down and your LDAP administrator is unavailable.
- There were two different 1.2.5 builds that were publicly available – 250 and 299.
- GroupWise Mobility Service 2.0 has been redesigned as an “ActiveSync Only” process, which is no longer part of the modular Novell Data Synchronizer.
- New Administration Console that is streamlined for the single purpose of Mobility.
- Scaled for larger systems (750 users/1000 devices per server)
- New Monitoring Dashboard that provides single-glance status of system, devices and users.
- New troubleshooting options with “MCheck”.
- Server AutoDiscovery support
- Email Alert notifications for both service outages and device quarantine notifications.
- ActiveSync 12.1 Support was added. This allows newer devices that ONLY support ActiveSync 12.x and newer to work with GroupWise Mobility Service.
- Task sync has been taken out of “preview” mode and added to full support.
- GroupWise Phone Messages are now synchronized.
- Users can choose the address book where new contacts should be added.
- GroupWise 2014 support (when GroupWise 2014 ships)
- Removal of dependencies on LDAP through GroupWise provisioning
- Reporting capabilities
- SLES 11 SP3 is only officially supported with GroupWise Mobility Service 2.0. The 1.2.5 Mobility Pack could technically run on SP3, but there is no official support for SP3 and the 1.x version.
In the next section, we will begin our preparations for GroupWise Mobility Service installation.