So why would you in good conscience would you want to redesign/re-architect your existing GroupWise system and then possibly move all mailboxes? Well, here are a few answers for you:
1. The "old-world" design has 1 Post Office per domain.
2. GroupWise Administration is now centralized.
3. You want to increase fault-tolerance and high availability with clustering.
4. You need to decrease the overall administration demands.
5. The LAN/MAN/WAN design has changed - more bandwidth is available or needed.
6. You're bored and need a project to show your value to the boss (OK, not really).
The point is that I have seen many reasons for organizations to consolidate their GroupWise system. The most frequent reason is centralization and disaster recovery. Once a GroupWise system is centralized into a data center and onto a cluster, its administration is easier and disaster recovery more manageable. Such things as Business Continuity Clusters (BCC), aka a cluster of clusters, as well as SAN implementations are driving the most valuable application in an organization to be consolidated/centralized - GroupWise.
Factors to Consider
First you must consider if your current LAN/MAN/WAN design and bandwidth can handle the traffic. Remember, once you pull a GroupWise post office from a remote site to central data center, there will be an increase in bandwidth. There are three ways to handle this at the client level:
1) Online Client: If the WAN link is big enough, let users use Online client mode with a direct IP connection to the post office. Assuming no WAN outage, all will be fine.
2) Caching Mode Client: If the WAN link is in the middle range, and bandwidth is there but not in abundance, Caching mode will work fine. Now the initial building of the cache can zap the WAN, so it's better to prime the cache before pulling the post office back into the data center.
3) WebAccess Client: If your WAN link is heavily used or bandwidth is low, convert most users to WebAccess. Yes, there are disadvantages of WebAccess at the user level, so you will need to investigate those for your environment. But if you design it correctly (see my Cool Solutions article on Highly Available WebAccess), you will have a great solution that can run even if the WAN is out. This assumes your remote sites have individual/redundant Internet links. And you do not have to support a desktop client.
Once the LAN/MAN/WAN has been considered, look at the GroupWise design. Does the current implementation make sense? Is your current GroupWise system built around a remote site and not around the organization's departments?
Let me present a few examples.
Example 1 - A School
Imagine a K-12 school of 500 users, with a T1 (1.54Mbps) Wide Area Network (WAN) that connects one high school, two middle schools, and four elementary schools, along with the central Administration building. The school has eight post offices, each under its own domain located at each site. Each domain also has one WebAccess Agent tied to one WebAccess Application per site. Figure 1 shows the school's network design, while Figure 2 shows the current GroupWise design.
Figure 1: School's current network design: Hub and Spoke T1 network
Figure 2: School's Current GroupWise design: Each school with its own domain, post office, and gateway
An interesting thing about schools and designing GroupWise, is that there are many ways to do it. As you have seen, the old design took the site approach, designing the GroupWise system around each school. This has merit when administering GroupWise based upon sites. But consider this: distribution lists are an effective way to handle 80% or more of the site administration. And realistically, teachers are teachers in a school - they will all have the same sort of rights or be managed in the same way. So why not design a GroupWise system around the category of teacher or the structure of the school system?
There are elementary, middle, and high schools. Each category has an administration staff, a working staff (Custodians, grounds keepers, etc.), and teachers. Because the entire GroupWise user population is only 500, it is possible to consolidate all users into 1 post office for the entire school system; but then management of sets of users may have to be more individualized. For example, if you want to lock down mailbox sizes for users based upon Administrative Staff and Teachers, you would have to manage it at the individual level if you had just one post office.
Therefore, the school determined it required a division of school categories. A single new domain is created called Schools, and under it are three post offices: ElementaryPO, MiddlePO and HighPO. In each of these post offices are the respective administration, working staff and teachers. This design also sets up the school to implement the design further in the future, to include students again based upon their category.
The Admin domain is kept, as well as its post office, since the school system administration such as the superintendent will be managed differently from teachers. And because this eliminates so many domains, post offices, and gateways, it naturally eliminates servers as well. All of this leads to a smaller GroupWise system design, centralized at the administration building and ready for clustering if desired.
Lastly, the school created a new Primary Domain free of post offices and gateways and used exclusively for eDirectory User Synchronization and GroupWise Administration. They also built 3 new gateway domains, 2 for WebAccess and 1 for GWIA. See Figure 3 below.
Figure 3: School's new GroupWise design: Streamline the post offices and centralize the gateways
Here's a recap of the benefits:
Example 2 - A Corporation
This next example is a different look from the traditional network designs. It includes two hubs on the WAN, for a corporation.
The Corporation has 4,000 users, with a national Wide Area Network (WAN) that contains two data centers connected to each other with a high-speed link. The data centers are within the corporate offices on each coast. The WAN is run across the phone company's backbone. Each remote site has local access to the phone company's network. The Corporation has 10 post offices spread across the U.S. equally distributed east and west of the Mississippi river. Part-time administrators at each remote site manage the GroupWise domain and post office for that location. Each of the T1 (1.54Mbps) remote sites has approximately 30 users, while the slower sites (768 and 512Kbps) have 10 users each. Figure 4 shows the Corporation's network design, while Figure 5 shows the current GroupWise design.
Figure 4: Corporation's current network design: Two data centers and mostly T1 speeds with just 2 slower links
Figure 5: Corporation's current GroupWise design: A domain and post office for every site
In this scenario, the Corporation has 2 data centers one on each coast of the USA, and the remote connecting sites are evenly dispersed, with most having the same link speeds. An evaluation of the WAN traffic across the T1 remote links found them under utilized. This allows the Corporation to consider redesigning their GroupWise system by consolidating almost all post offices into one of the two data centers. Furthermore, they can implement clustering at each data center for further fault tolerance.
Now let's look at the final design. Under the DCWEST domain, 3 new remote site post offices are built. These represent the 3 sites with T1 WAN speeds. The 4th site has a 512Kbps connection, therefore consolidating it to a central data center is not advised. This is because end users will notice a degradation in GroupWise performance with the online client, especially when large attachments are sent. Even the use of the Caching Mode client would have a noticeable decrease in performance. Only by forcing the end users at the slow WAN link site to WebAccess only could they see the same performance. The Corporation however is not ready to force users to WebAccess only.
The DCEAST domain is much the same as the DCWEST with remote site post offices implemented under it. And just as in the West Coast data center, the East Coast has 1 GWIA and 2 WebAccess gateways. Also, the slower remote site is kept as it was, because of the aforementioned end user performance issues. See Figure 6 below.
Figure 6: Corporation's new GroupWise design: Consolidate the remote site (T1) post offices into one of two data centers and domains
In the future, the corporation can increase WAN link speeds as needed, and consolidate the 2 remaining slower sites. Or, they can consider implementing a Highly Available WebAccess design and force a large part of their end users to WebAccess only. For client distribution, the SETUP IP feature for GroupWise will help manage the client version distribution.
By redesigning GroupWise in this manner, the corporation can eliminate almost all of the remote site administrators. Such an administration model often leads to database inconsistencies and improper GroupWise administration. Basically, there are 'too many cooks in the kitchen' for GroupWise administration. Consolidating the system into the new design will reduce that number down to 2 or 3 total administrative staff.
Here's a recap of the benefits:
Disposable Domains and Gateways
Let me just touch on one last thing. Quite often in redesigns/consolidations, part of the idea is to get rid of domains. Remember - the more domains, the more synchronization issues between domains, and the longer a top-down rebuild can take. But as you look over the examples, you will see that sometimes the net amount of domains may stay the same, and only the post office domains (those holding post offices) decreases. Well, this is because it is considered Best Practice to create a domain to hold just a gateway - sometimes just 1 gateway.
The reason? Simple: if that gateway gets screwed up, you can delete the gateway and recreate it. The same goes for its domain: if the gateways domain gets screwed up, is inconsistent or completely out of sync with other domains, and you cannot seem to fix it - then just delete it and start over. Often it takes less time to properly delete a domain and gateway and reinstall it than it does to troubleshoot and fix it. That said, there are technical reasons for domains specific to just gateways. A gateway must have a direct UNC path to its parent domain. This means it is not TCP/IP enabled to its parent domain. Therefore, when a gateway is running, it is directly connected to its parent via a 'file lock' on the databases. If a gateway gets hosed, the database can get hosed as well.
And the last point on this is about clustering. When you cluster GroupWise gateways, you always want the gateway to run on the same volume (cluster resource) as its parent domain. That way, during failover they travel together.
User Moves
OK, now that you have the new design, how do you get the user mailboxes into the new design? Move them, of course. You cannot move a post office under a new domain, but you can move individual mailboxes to a new post office. This can be a huge undertaking. I know, because I have done it on several occasions. At one customer I moved more than 12,000 mailboxes. The good news is, the newly moved mailboxes were CLEAN and free of corrupted messages. Keep this in mind if you redesign.
So, consider the idea of redesigning your GroupWise system with an eye for centralization and/or clustering. Keep in mind the concept of a Post Office domain to house post offices, gateway domains to hold gateways and you will be fine. Also, if you are lucky enough to attend Brainshare AND you read this article, you should still attend my session on consolidations. There is a ton more detail, not to mention my off-beat humor.
To wrap it up, take a good look at your GroupWise system. See if it's a bit bloated or oversized, and reconsider its design. It's likely you can centralize and consolidate it. And sing along with us ... "C'mon people now, smile on your brother (GroupWise system), everybody get together (at Brainshare), try to love one another (GroupWise and Novell) right now."
As always, I can be reached at: Gregg@HinchmanConsulting.com, if you have any comments, article ideas or just want to help a quirky consultant support his GroupWise habit.
Support
Documentation
Learning Services
Partner Programs