GroupWise 8 Design Services
GroupWise 8 Design Services
Often system administrators and implementers do not think of applications or their components as services. However when an application is married to the resources of the environment in which it exists it is easier to envision as a service. Once understood Information Technology services often exist in several infrastructure layers that all benefit from planning.
Any GroupWise deployment should be planned prior to implementation. Sometimes the application of this concept by the administrators of smaller systems is done so too casually. Often small systems grow into larger systems for a plethora of reasons. It is often difficult, sometimes very difficult, to implement best practices in an expanding system with legacy design hurdles in the way.
IP address and DNS name spaces
If possible it is helpful to design the IP and DNS name spaces for your GroupWise services. This may seem like an unnecessary effort but often when analysing issues being able to identify system conversations is made much easier and more importantly faster.
Similarly when the DNS names for GroupWise agents are standardized the system becomes more intuitive to manage and administer. Existing agent schemes can be deduced without reference and new agent deployment schemes already exist.
As well as making the back end services easier to use for administrators the front end services are made easier for users to consume as well. If users can intuitively deduce their POA DNS name in the rare occasions they need to it also reduces the load on Help Desks for example.
In summary there can be a lot of potential return for the implementing a simple standard in any size environment.
Documentation policies and standards
Organizational specific documentation bears many similar long term benefits as well. Imagine how much harder implementing, configuration, and troubleshooting tasks would be without vendor documentation and resources like this very wiki.
The documentation of internal systems is often avoided due to the amount of time it takes to initially produce and maintain it. However if the larger view is taken in producing such documentation can significantly reduce the support efforts for existing staff and supplement the training efforts of new or junior staff.
NCP and non-clustered OES servers POSIX partitions used for GroupWise domains and gateways should utilize NCP shares for their domain file systems. This will be the most likely configuration as these are usually non-clustered servers with local storage configured as RAID devices, so there will be no secondary disk to implement NSS.
Whenever possible utilize NetWare Core Protocol (NCP) to access GroupWise information stores. This simplifies administration greatly especially when administrators and support staff utilize Windows based instances of ConsoleOne. Samba is often touted as a viable option but it's use should be avoided. Whereas it will technically work the file system semantics, file locking behaviour, and performance leave much to be desired. The end result minimally will be annoyances due to performance or database corruption at the worst. The Network File System (NFS) protocol for accessing GroupWise information stores should not be used for system administration.... ever.
Enable "Cross Protocol File Locking" on all NCP enabled servers hosting GroupWise file systems.
LDAP service information
Enabling LDAP authentication for your GroupWise system is often done to reduce the number of passwords users and administrators have to deal with. There are some additional security considerations to manage as a result when using LDAP authentication that are discussed in the following section.
It is important to understand that the LDAP conversation occurs between the GroupWise Post Office Agent (POA) and eDirectory. More specifically the eDirectory server(s) specified as the LDAP server target(s).
If LDAP authentication is used it should be used over SSL without exception. The only technical requirement necessary to implement secure LDAP authentication for GroupWise POA's outside the normal LDAP server configuration procedures is the placement of the LDAP server trusted root certificate(s). Technically this is the Certificate Authority public key certificate for your target eDirectory tree. As with any flat statement there is always one exception. When the POA runs on the same server as the LDAP service packets do not cross the wire and thus SSL is superfluous.
The default locations for obtaining a copy of your eDirectory CA public key (LDAP root) certificate are:
For Linux Servers: /etc/opt/novell/certs/SSLCerts.der
For NetWare servers: SYS:\Public\RootCert.der
The default locations GroupWise POA's expect to find SSL certificates are:
For Linux servers: /opt/novell/groupwise/agents/lib/nldap
For NetWare and Windows servers: POA installation directory
Netware POA LDAP application information
When you install the NetWare POA software, updated or even specific versions of the LDAPSDK, LDAPSSL and LDAPX NLMs are installed as well. These versions of the NetWare LDAP applications are intended for use with your version of the POA software. It is best to maintain the alignment of these application file versions whenever possible. Even if your GroupWise implementation uses stand alone servers the GroupWise information stores and application files should not be installed to the SYS: volume.
If the included LDAP application files are placed in the same directory as the agent application files the POA will auto-load them from that location. If you install the POA software using the GroupWise installation wizard this will be done for you. If you manually copied the agent files to the target location you will want to be sure you copy the files from the ..\AGENTS\NETWARE\LDAP directory from a GroupWise SDD or CD to the target install directory.
Note the graphic below. This verifies the POA loaded the LDAP application files from the agent install directory.
Note the potential difference in the dates for the LDAP application file LDAPX.NLM. If you are using LDAP authentication against your eDirectory back-end you will most likely want the most appropriate, if not the most recent, LDAP application performing those tasks.
Please see the section of this wiki dedicated to security content GroupWise 8 Best Practices Security Wiki page
Implementing service demarcations
Often isolating services is not considered when implementing system components that are intended to inter-operate. However ensuring that components that are more prone to failures or heavy loads do not share resources with those responsible for user service experiences always improves system performance and stability.
Service demarcations can be both logical and physical. Logical demarcations are primarily implemented in configurations and physical in host limitations.
Dedicate different resources for systems and humans
A simple idea but very beneficial nonetheless. Contention for resources is the most likely cause behind most performance issues. A good example is do not allow heavily loaded services to share computational resources with another heavily loaded service or one that is likely to negatively impact the end user experience.
Implement service ACLs when possible
ACL's are one of the simplest concepts almost all administrators can implement regardless of system size. Restricting a service consumption to a known set of hosts not only improves service efficiency, but improves service security and can produces metrics that can be used for service capacity management.
Agent network addresses
The use of service isolation, clustering, HA, and load balancing all have the side effect of increasing the IP address footprint of a service. All the more reason to plan out the name spaces to be used. When possible assign a dedicated IP address to each agent in your system. For example if a POA, MTA, and GWIA all share a given host all agents, the host, and clustered volume (if applicable) should have different IP addresses and DNS names.
Third party and mobile clients
Applications that do not offer a "managed" ingress point to your GroupWise data store.
Non-native clients have the ability to consume a huge amount of system resources. The large scale use of unmanaged third party client applications, including POP/IMAP and embedded mobile device clients, can negatively impact gateway and post office agent performance. Some certainly are not configured by users, administrators or programmers with efficiency in mind. Heavy use by these components should be anticipated and accounts used by them should be placed on dedicated post offices (Service Post Offices) and if possible dedicated domains (Service Domains).
Administrative and Trusted applications
Applications that do offer a "managed" ingress point to your GroupWise data store.
The concept of a "Service Domain" can be very useful. Many modern enterprise mail systems interact and inter-operate with other enterprise applications. Trusted applications like Blackberry Enterprise Server and GWAVA products are good case points. Dedicating a domain to such applications may seem unnecessary but it adds an additional level of control for GroupWise administrators. If the trusted application is misbehaving or is administered by another party and misbehaving you have the ability to limit "its" ability to interact with your system.
This is extremely useful in the case of Novell Identity Management connectivity.
General Software Distribution Directory Concepts
Its easy to think of a GroupWise Software Distribution Directories (SDD) as a simple software repository. GroupWise SDDs not only facilitate the distribution of agent and client software within a GroupWise system they also are key to system upgrade procedures. This means that they should be planned and managed as well as any other component within your system.
GroupWise systems use the concept of SDDs to act as online repositories that are used to install GroupWise systems, agents, clients, and other GroupWise service software. A single GroupWise system can have more than one GroupWise SDD and often does. Each SDD is intended to be version specific. For example a GroupWise 7 SDD should contain only GroupWise 7 software components and a GroupWise 8 SDD should only contain GroupWise 8 software components.
GroupWise SDDâ€™s are implemented using two components. The actual file systems that contains the software and the GroupWise system reference defining the network path(s) to the SDD. The file system component consists of a parent directory, usually called â€˜softwareâ€, that contains an expected set of files and directories. The GroupWise system reference is created using the GroupWise ConsoleOne snapins and is written to domain and post office databases so the GroupWise system and itsâ€™ agents are aware of the SDD(s).
GroupWise SDDâ€™s are utilized to install and update client software. This is facilitated by assigning a SDD to a GroupWise post office and granting file system rights to the respective GroupWise POA object or proxy user to the assigned SDD.
GroupWise SDDâ€™s are also utilized to install and update agent and service software as well as install new GroupWise systems. In NetWare and Windows environments the SDD can be accessed and utilized remotely using standard UNC and network drive mapping conventions. In Linux environments there are some caveats for remote access to consider.
Implementing separate SDDs for client and system use is a practical design aspect in medium, large, and enterprise systems.
Linux software distribution configuration for servers
Linux servers inject some complexity into the traditional remote SDD access and software installation methods. Foremost with Linux implementations software distribution and software installation are different. GroupWise software installations are performed locally on Linux servers as a standard. This means that the SDD has to come to the server. This contrasts with the traditional method where the administrator can access a remote SDD on one server from a workstation and perform a remote installation on a completely different server. GroupWise SDDâ€™s can be made remotely accessible over network aware file protocols like NFS but remote software installations are still not practical.
Having a SDD on every Linux server hosting GroupWise components that will need to be periodically updated, or performing installations using CD media is neither practical nor efficient. One possibility is to place the GroupWise SDD used for Linux servers on a highly available clustered NCP accessible or POSIX file system. This file system could also be made available over the NFS protocol for import to remote servers to perform software installations. This configuration model should allow the GroupWise SDD to be mounted on any Linux server participating in the cluster and even those outside the cluster.
The model for a clustered GroupWise SDD accessible over NCP, POSIX, and NFS means is displayed below. This model leverages the OES Linux NCP share technology using NCS. NCS scripts are also used to exports all of the POSIX file systems for import on remote non-clustered servers.
The details for configuring NCS NFS scripts can be found in Using NFS to extend GroupWise SDD hosted on Linux
Consider placing tag files within Linux SDDs that identify the software versions for usability concerns. With Linux you have the potential of having a "text view" of a SDD. If the SDD is a special purpose or partial SDD determining the software version may be a bit more work. Placing an empty text file in the SDD that reflects the software version is an easy usability aspect to implement.
It is important to note that this does not take into account client auto-update services. For client updates, even those used for IP based auto-updates, consider using the Oracle Cluster File System (OCFS) for placing special client SDDs where clustered Linux POAs will always have local access to them. Linux POAs on stand alone servers that participate in client auto-update services would still require dedicated local SDDs.
NetWare software distribution configuration for servers
GroupWise SDDâ€™s for NetWare GroupWise software components are always placed NCP file systems which are available via UNC conventions and network drive mapping to Windows based computers. This effectively diminishes some of the benefit any high availability file systems bring to the table for hosting SDDs. Centralized special purpose repositories are an easily attainable goal using these components.
Client SDDs can more easily maintained separately from server SDDs in this model for both organizational and security reasons. The fact that the POAs can be assigned rights to, and remotely access SDDs using UNC conventions, greatly simplifies SDD design considerations. There can easily be client SDDs for manual installations, single user web based installations, and multi-user auto-update installations.
SDD placement considerations
SDD placement should be on a file system that is accessible to the post office agent (POA) regardless of the agent platform.
Linux: On a supported file system mounted on the same server on which the POA is running where the appropriate POA user rights can be assigned
NetWare: On a NSS file system reachable using UNC conventions where the appropriate NCP file system rights can be assigned
Windows: On a NTFS file system reachable using UNC conventions or mapped to a local drive letter on the same server on which the POA is running where the appropriate NCP file system rights can be assigned
Client SDD Considerations
Client SDDs have a different purposes than system SDDs in most mature systems. The clients only perspective on SDDs are client software information and updates.
Client IP Auto-update Considerations
Client SDDs can also be implemented on web servers for use with GroupWise IP based auto-update services for Windows based clients. The following platforms and web server software can be used.
Linux: Apache 2
NetWare: Apache2 or Novonyx
Windows: Apache2 or IISx
Clients that participate in IP auto-update services do not have to only have to authenticate to GroupWise as they normally would.
The GroupWise client auto-update service requirements and configurations are well on the Novell docuemntion site here
It is also worth mentioning that one of the major benefits of the IP based auto-update is that all of the required software is downloaded to the client machine before the local update process begins. This means that if the software delivery is interrupted, or being transmitted over a slow link there are no issues with handicapped clients due to an install that prior to completing.
This is of special value in the case of clients connected with wireless.
Using "Micro-SDDs" for IP based client updates
Virtually all system administrators should be leveraging GroupWise's ability to update Windows client software over TCPIP using "SetupIP.exe".
The fact that Linux and Apple Macs still cannot participate in the automatic client updates is annoying to say the least. Regardless it is still the case so we'll move on.
SetupIP has the ability to load balance auto-update operations over several software sources. These software sources themselves could easily be confused with "micro-SDDs" as they can contain as few as 2 to 3 files. However this is not technically the case as a POA cannot evaluate the file system and determine software versions or transfer the required libraries to the client to initiate the auto-update process. It is actually a simple software source from which to pull files from that is unknown to the GroupWise system.
Conversely a micro-SDD can be properly configured, and more importantly managed, within a GroupWise system. This means it to be target able by a POA and, with a file footprint of less than 500kb, it can still fully participate in the required client auto-update conversations and processes. If you have numbers of, or the need for numbers of, specialized client SDDs this can be an exciting proposition.
The details for configuring a client micro-SDD can be found in Setting up a GroupWise micro-SDD
Load balancing technologies
Organisational needs and policies will dictate whether load balancing and/or High Availability technologies should be used. However it is recommended that they should be implemented when possible.
Larger GroupWise systems are more concerned with service load balancing than smaller ones. Primarily because a heavily loaded system even when properly designed and configured can, and will, experience failures. Also because any type of load balancing will require multiple agent instances.
Common service load balancing models used are:
- Hardware: Uses dedicated hardware and virtual service network addresses to perform load balancing
- Software: Uses special application software and virtual service network addresses to perform load balancing
- Native: Uses load balancing facilities built into the application being load balanced to achieve or mimic load balanced behaviour
- Blended: Uses a combination of two or more of the referenced methods to achieve the desired load balancing results.
High Availability technologies
Large and small GroupWise systems can benefit from High Availability (HA) technologies. Whereas load balancing centres on system load levelling HA centres on service availability. Contrary to load balancing implementations HA implementations focus on making a single agent instance consistently available.
Common service HA models used are:
- Uses special software and shared storage technologies to ensure application files and information stores can be moved to other hosts in the event of a host failure. OES Windows
- Uses special applications or engines to monitor services and perform actions on a host, such as restarting and application or sending alarms, in the event of a service failure.
Native Load Balancing
- GroupWise does not offer many â€œnativeâ€ load balancing options. Rather it does offer native â€œredirectionâ€ services for gateways and High Availability options for agents on the NetWare and Linux platforms. The exception is the behaviour of WebAccess where cross-linked Agents and Applications will adjust to load balance and for failure.
Third Party Requirements
Backup and restoration technologies
These are base guidelines for the backup of a GroupWise system:
Back up the Novell GroupWise Information Store nightly.
The information store is everything under the post office directory. This includes the OFUSER, OFMSG, OFFILES, OFWORK and GWDMS directory structures.
Whatever backup strategy you currently use, consider that many GroupWise database files remain open continuously and may even be in use (written to) during your backup. Your strategy should allow for the capture of these open files. GroupWise provides a Target Service Agent (TSA) for open file backups.
For more information, refer to the GroupWise Target Service Agent TSAFSGW in the Online Documentation.
- Note: The TSAFSGW is the modern hack to provide Backup tools with a view of GroupWise that they used to see with GWTSA. The active element of the TSA is part of the TSAFS and is activated using the enablegw=yes switch when starting the TSAFS. As this setting is persistent it need only be done once. This TID explains in greater detail.
Provide fault tolerance for the primary domain.
Run Reduce Only on the information store at least weekly to manage the sizes of the GroupWise. Again, there is no need to do this if expire/reduce is running.
Back up each domain database nightly.
Domain databases are part of the administration system, and if they are damaged, they can be rebuilt from the primary domain database. If, however, changes made to a domain database have not been replicated to the primary yet, a simple rebuild may result in the loss of those administrative records (user objects, distribution lists, etc.) Having a recent backup to synchronize these records will make the rebuild more complete.
Manually back up the primary domain database prior to and immediately following any major system changes.
If you are merging systems, adding large numbers of users, or making other dramatic changes, use the DBCopy tool to capture the domain database before and after the changes have been made. This will make it possible for you to back out if necessary.
- Note: There is one unique product that will backup a GroupWise system in an optimal fashion, GWAVA Reload. Please refer to the GroupWise 8 Active Partners Page for additional information on this third party product.
- NOTE: As GroupWise encrypts and compresses all data held in a Post Office, Domain or Gateway an Anti-Virus application set to scan those files systems will find nothing and cause service failures due to file locking. DO NOT DO IT!
Novell GroupWise is not as susceptible to viruses as other vendors' products; however, as a messaging product, GroupWise can transport viruses. Novell recommends that customers implement virus protection solutions at every entry point of their network. Viruses sent in from Internet messages pose the greatest threat.
There are two primary standard methodologies for Anti-Virus & Anti-Spam protection, either using a cloud based service to relay between the internet and GroupWise or using an SMTP relay hosted within the data centre.
Many different vendors have made products specifically written to integrate with Novell GroupWise to protect your GroupWise system from virus-laden messages from the Internet. Please refer to the GroupWise 8 Active Partners Page for additional information on third party products.