"I want a reason for the way things have to be . . .". Isn't that the truth! Recently I was in Barcelona, Spain for BrainShare Europe. While riding a tour bus after a long week of sessions, conversations and elbow rubbing, I started to reflect upon the week from a GroupWise perspective. Yeah, I know 'get a life'! Anyway, one of the stops on the tour bus was at "Temple de la Sagrada Familia", translated: Church of the Holy Family. This church was architected by Antoni Gaudi (pronounced: Ga Ow Dee). This is the man who coined his own style of 'more is just not enough'.

This led me to think about a European gentleman who attended one of my GroupWise presentations. His organization currently has a post office over 300GB in size! He was looking for ideas about how to manage it better. As a consultant I see this sort of situation every day - post offices so large that GWChecks take days if not weeks to finish. Customers turn to me for solutions and I in turn provide them with my wisdom and experience, for a fee of course. (Hey, a guy has to eat! Besides, being Self-Unemployed, as I like to call it, means no paycheck.) OK, back on track. The first thing I have to ask a customer is, "Do you have any email retention policies?" Once I get past the 'deer in a headlights' blank stare, I explain myself. In order to properly manage and support a GroupWise system there have to be rules. Email policies are those rules. Here are three that I recommend:

• An Email retention policy -How long must we keep email? Do we have regulatory reasons? Do we need to maintain some form of compliancy incase of lawsuits?

• An Archiving policy - How/when do we archive? Do we archive in GroupWise archive format? Or, do we use 3rd party products such as GWArchive by The Messaging Architects, to place all archives in an industry standard format like XML?

• An Email box size policy - How large should a users' mailbox be? Do we apply the policy for all users or do we have different policies for different users/post offices/etc.?

Having the rules in place makes changing your GroupWise system easier. Whether you are upgrading to the 'hot' GroupWise 7 or collapsing your existing GroupWise system to a cluster, it's easier to redesign when the sizes are smaller. Let me ask you a question:

How many times have you considered redesigning your organization's GroupWise system only to wonder how to redesign post offices? In my travels, I have seen:

• Post offices to manage certain user groups such as remote users

• Post offices for locations such as buildings

• Post offices for departments within an organization

• Post offices alphabetical or numerical user ID's

• Post offices for an entire organizations resources

• Post offices based around functions such as document management

Just to name a few. Suffice to say there are many ways to design post offices. The real question is: how do I design a post office to be both efficient and functional for an organization, and what parameters should I implement or tune to increase its stability, and performance. Well, look no further! Continuing the Consultant's Corner series on GroupWise Design, I will provide the 'Best Practices' that we travel-crazy consultants use to design/redesign and scale post offices to suit an organization's business needs.

I am not alone in my delivery of 'Best Practices' I have a long list of fellow consultants, engineers and customers that have, over the years, tested and proofed the information presented in this series of articles. And lest I forget there is Novell support, TID's, and the GroupWise community. I have just gathered it all together, tested it in the field and presented it here. Let's get started.

Post Office Design

So how many post offices do I need? That's a great question. As a consultant I spent good portion of my time just asking questions and then listening for the answers. It's amazing what I hear, and often the customer already knows what they need, but they are just too close to the problem to see it. Here are few example questions I will ask you:

• How many users do you have?

• Is your WAN distributed or centralized? (Example: Hub and spoke with a central site)

• What GroupWise client do you use?

• How are your post offices deployed (designed) now?

• What is your organization's business?

The user count is always the first place I start. I like to know how many users are accessing a GroupWise post office at any 'given moment' in time. Most of the time you can check the POA screen on the server, at the App Connections statistic then divide by 4. On average one user will take up to four App Connections. But to get a range - divide by 2 as well. Like this:

• 400 App Connections divided by 4 = 100 users

• 400 App Connections divided by 2 = 200 users

Now you have an idea. Question is, is this peak time? You have to take a reading at different times to get a good baseline of how many users are 'in' their post office. Another way I judge contiguous access is by looking at the organization's business and the number of users showing in the post office.

For this go to ConsoleOne, and right-click on the post office object, then select Information. In this case, let's say there are 1000 users listed in the post office. Of that number, 100 are inactive (have not accessed their mailbox in over 60 days). This means my net users are 900. The company is a bank. The normal business hours are 9am to 5pm Monday to Friday. With this information, I can safely say approximately 900 users may be accessing this one post office at the same moment in time.

My next thought is, what client are they using? If they say Online only -then the post office is a very busy post office. If it's Caching only, then the post office is barely breaking a sweat. And if it's all WebAccess, well the post office is yawning. The reason for this is simple. The Online client is directly connected via IP to the POA, and the POA is constantly answering client requests. The Caching client just bothers the POA when it needs "deltas" or changes, whereas the WebAccess client has the WebAccess agent doing all the work relieving the POA of a vast amount of responsibility. Take a look at the table below, Novell has provided this table for years to help scale post offices.

I know what you're thinking. Does this mean I can have all 5000 of my users in one post office? The answer is Yes and No. Allow me to apply a bit of Vulcan logic. If you have 5000 users in one post office and that post office goes down for any reason - hardware, corruption, etc. - you have just taken out the entire GroupWise system. It's the 'all eggs in one basket' syndrome. Makes sense, right? Let's dig a bit deeper into your 5000 users. Of those 5000 users let's say only 700 are in GroupWise at any given moment in time, and they only do email and very little else and mostly use WebAccess. No document management, no shared folders or address books. They are light users. Your one post office is scaled correctly. However, you still have all users on one server.

Now let's add another factor. Hold onto your hats and stay with me, I will summarize this so you get the complete concept. How big is the post office directory? If your post office directory is running on the side of 100GB, then you have a problem. I assume no document management here. With message databases and attachments driving up your post office directory size (Truly it's the attachments, as most users use email as a default document management system.), backups take longer, and schedule maintenance routines take longer. Some customers I have worked with cannot get Contents Checks to finish in a reasonable time such as a weekend because their post office directories are so large. And what about moving this data to a SAN or another server - it will take much longer. The fact is, the larger the post office directory the more difficult it is to handle as I stated previously. Does this mean GroupWise post offices do not scale? NO!!! GroupWise will handle it, but can you?

Let's get back to our scaling. So we have 5000 users in one post office and only 700 users are accessing GroupWise with the WebAccess client doing light usage but the post office directory and attachments are fast approaching 100GB in size. What should we do? Split the post office into two post offices you say? Great, but what happens in a year when you have two post offices approaching 100GB in size? My professional recommendation: Implement Email policies and archiving, as I stated previously. GroupWise should always ONLY hold the most recent emails (180 to 365 days).

Whew! Are you getting the complexity that comes with post office design and scalability? Many factors must be taken into consideration, and there is not a clear concise answer. My recommendation is that you try to have no more than 1000 users in a post office, given 50-70% are accessing GroupWise in any given moment, and given the post office directory is not too large (I like 50GB post offices or less.) and assuming they are using the Online client and are medium usage users. This is a middle of the road recommendation and will allow you to scale the post office larger but still be able to handle the size and not substantially affect users.

To summarize your 5000-user GroupWise system, I would have two post offices of 2500 users each, 350 of which are in GroupWise at the same time, and the post office directories will be 50GB or less.

FUN FACT: I once designed a 20,000-user GroupWise system for a customer on a cluster. One post office had 8000 users in it. A big no-no! Here is the rub. The users were K-4th graders with WebAccess-only access and 10MB email box size restrictions. We estimated maybe 800 users would be in the GroupWise post office at any given moment so the POA would handle the load fine. We also estimated the likelihood of all 8000 users filling up their mailboxes to capacity to be very low and even if they did it was 80GB total on a SAN.

Summary

Time to recap. The first consideration is making email policies to help reduce the GroupWise system size. Smaller parts are better. Next you have to determine just how big your post offices are, how they are accessed and the type of usage. Once you gather this information you are ready to lay out a plan. As a consultant, everything I do has a plan first, and documentation second. Then and only then do I proceed to make changes. Follow the same path and your post office redesigns will go smoothly. Ideally this article has given you a few things to think about as you move forward in sizing your GroupWise system. Hopefully, you will not . . "need a hand to help build up some kind of hope . . ."