As a consultant these past 7 years, I have found myself traveling coast to coast helping organizations with their network and mostly their GroupWise systems. I have performed upgrades, redesigns, installations and clustering of GroupWise system from 50 users up to 20,000 users. In these experiences I have picked up many tips and learned tons of tricks that enhances a GroupWise system in the following areas:
- fault tolerance
I have ‘lived in’ the Novell Knowledgebase, ‘swam’ in the Novell forums, ‘strolled through’ Coolsolutions and ‘flew thru’ the NGWList.com postings. All of these are great tools to help an individuals resolve GroupWise issues as they creep up. Thing is, as a consultant I am paid to ‘not have issues’, so I take a conservative approach to GroupWise consulting, because I do not want my customers having ‘issues’ after I leave their site.
Best Practice is a consultant’s mantra. Best Practice is the lessons that were learned either from implementing a solution or from supporting a solution. Best Practice in GroupWise comes from the user community, their successes and failures. It comes from Novell product development and support. And in a consultant’s case it also comes from their peers experiences. All of these sources and their information are rolled into Best Practice.
Is Best Practice an absolute? No, never. Best Practice is a guide. It’s an art to determine when Best Practice does not fit into a specific environment. In the case of GroupWise system design, as I often love to say “Your Mileage May Vary.” In this article I will share with you the Best Practices for GroupWise domain designs, and explain the reasoning behind them.
The Primary Domain
There are many questions, as a consultant, that I must ask a customer in order to determine how to design their GroupWise system. Ultimately, though it comes down to 1 question: What is the ‘end-game’ for your GroupWise system? Restated, what do you, the customer, want to achieve with your GroupWise system? The responses I receive are varied, but in the end they lead to this one global response: “We want GroupWise to be stable and easy to manage.” To this I say ok, then we need to think (or rethink) how the system is designed starting at the top.
The ‘top’ of the GroupWise system is the Primary domain. A wise GroupWise sage (Yoda-esk in his knowledge of GroupWise), Ed Hanley, once shared this description of the Primary domain.
“The Primary domain is your ‘gold-copy’ of the GroupWise system. If you lose it, you lose the GroupWise system.”
Thankfully Novell has helped us along the way to make sure that we as administrators can recover from a loss of a Primary domain database, without Novell support. However, the Primary domain should contain no other GroupWise components. It is very important to minimize the functions of the Primary domain database. It should be used for administering the entire GroupWise system, making system-wide changes and rebuilding the GroupWise system, from a “Top-Down” point of view. The Primary domain should be isolated, and have no post offices, gateways or users within it. The Primary domain should also be solely responsible for eDirectory User Synchronization. The Primary domains MTA will perform this function as a Scheduled Event for all domains. This makes the Primary domain the ‘authoritative database’ for all things GroupWise. All secondary domains push ‘administrative messages’ directly to the Primary domain and then the Primary domain, being the authoritative database that it is, pushes out administrative messages to all other secondary domains. In this way, the Primary domain ensures all other domains have the same information and the GroupWise system is consistently in sync.
If you currently only have 1 domain in your GroupWise system, have you considered what would happen if the domain became corrupt or was unrecoverable? It would be very difficult to resolve the issue and more importantly it would take quite a while. As we all know, email is THE MOST IMPORTANT application in an organization because everyone uses it and the organization relies upon it for day to day business.
- Best Practice: Have a Primary Domain Database with no GroupWise components under it. See Figure 1.
- Best Practice: Always have at least 2 domains in your GroupWise system for fault tolerance. See Figure 1.
Figure 1: GroupWise System Design: Primary Domain with nothing under it and additional Domains for fault tolerance.
Domains, domains everywhere and not a one to link. So how many domains are needed in a GroupWise system? The answer is ‘it depends’. Definitely two domains for fault tolerance, after that it’s about the purpose. Domains and their MTA’s can be used for many different purposes.
Routing domains are centralized domains that all other domains connect to send their messages. It’s the ‘hub’ in a wagon wheel. The problem with Routing domains is that if it’s down, then no messages flow between your other domains. Therefore, a Routing domain is a point of failure. The only time I have ever seen a routing domain is when an organization has extremely slow WAN links and only wants 1 domain communicating across its WAN. Now that WAN links are so much faster, routing domains are just not needed.
- Best Practice: Avoid the use of Routing domains, unless there is a strong technical reason. See Figure 2.
Figure 2: GroupWise Domain Design: Routing Domain versus Non-Routing Domain
Special Purpose Domains
Special purpose domains are domains that are used for specific reasons such as holding a gateway. In an effort to make a GroupWise system more modular a domain is created to specifically hold just 1 gateway. This means that should something happen to that domain, only the 1 gateway is affected, not the entire GroupWise system. Let’s look at an example.
Demo Company has 1 domain that holds 2 post offices and GWIA gateway. If the domain becomes damaged or the MTA fails to load then not only is the GWIA affected but the post office is also affected. The GWIA will queue up its messages waiting for the MTA to be available for delivery to the post offices. Each post office will only be able to send email to users within the same post office. So no messages will route between post offices until the MTA is up and functional.
When I design GroupWise systems in clustered or non-clustered environments, I always make sure each gateway has its own domain. The nature of gateways is such that they can choke on a bad message or attachment and cause the parent domains MTA to fail or server they are running on to ABEND. Better to lose the one GroupWise component, such as a gateway and minimally impact the message system than to cause users to experience a GroupWise outage.
- Best Practice: Each gateway gets its own domain. See Figure 3.
Figure 3: GroupWise Domain Design: Special Purpose Domains for Gateways
Connecting the domains to each other is very important. In a multi-domain environment each domain should directly connected to all other domains in a ‘mesh topology’ style. This allows messages to flow directly from a source domain to a destination domain without ‘routing through’ a third domain. This is achieved using Link Configuration, setting the Link to ‘Direct’ and configuring the TCP/IP settings. Always use TCP/IP. One exception I will note here is that WebAccess Agents do not flow messages through their parent domain, they connect to a post office and act as a conduit ‘client’ for users. Therefore, WebAccess domains do not have to be connected directly to all other domains, but should be connected directly to the Primary domain.
- Best Practice: Directly connect all domains to each other using TCP/IP in a mesh topology style, with the exception of WebAccess Agent domains.
Figure 4: GroupWise Domain Design: Domains directly connected to other domains, except WebAccess
As you can see there are several ways to increase the availability of your organizations GroupWise system just by changing the domains design and usage. Next week, I will dig a bit deeper into the domain and its MTA, discussing the MTA configuration file and the eDirectory DOMAIN and MTA objects.