Novell Home

How Dave Does It: GroupWise Consolidation - Project Guidelines

Novell Cool Solutions: Trench
By Dave Muldoon

Digg This - Slashdot This

Posted: 22 Jan 2003
 

This is the second article in this series regarding consolidating your GroupWise system. The first article, entitled "Let's Talk About GroupWise Consolidation", covered many reasons why it should be considered, and potential advantages in your environment. For more information on those topics see my previous article, "Let's Talk About GroupWise Consolidation" .

With this article, I'll cover general project guidelines that I was able to utilize in my efforts consolidating thousands of users. I'll present a list of items and time frames, which most administrators should be able to use, for consolidating a GroupWise Post Office. This list has worked well within a large corporation and should be able to be used for small and medium-sized companies as well.

Fact Finding

With any project, there needs to be a phase of discovery. When looking into consolidation candidates, look at the entire Post Office as a potential candidate; all users, resources, distribution lists, etc. You may balk at the idea of moving a resource but it's actually quite easy and I'll cover that in a future article. When looking at consolidating an entire Post Office, you should look at things like:

  • Target Post Office: Double-check were the users, resources and distribution lists will be moved to. You'll need to make sure that you have this information written down, and that the location you plan on moving users to is adequate to support the new numbers.


  • POA Addressing: RCONSOLE the target Post Office and see how the POA is addressed (IP or DNS for both POA to MTA communication as well as client/server communication). Also thoroughly review the startup file for previous configurations, hard-coding of IP addresses or ports, etc. that may impact this project later.


  • Disk Space: Identify the current volume for the target Post Office and amount of space used by the GroupWise message store. Keep in mind that the target server will not increase it's message store size by this figure, but I use this figure as a total and utilize the extra space for growth and general GroupWise functionality. I prefer to keep about 40% free on my volumes to support other system downtime and outages as things within GroupWise queue up, requiring this space. In the end, I was able to use this volume space total on the existing server as part of my sales pitch, people love to hear that their area is going to have an additional 6 GB free after the process is complete and the Post Office is gone.

Communication

This may seem obvious, but end-users are often not as familiar with terms and systems as Administrators. This makes drafting a communication very important. Some administrators may have a corporate communications department to assist with this, although, I would think that's not all that common. So, when putting together this communication, take extra care in making it understandable to the least technical person receiving it, you may even wish to avoid technical terms and use them for face to face conversations with the areas involved in this project.

  • Communication template: If you're undertaking this endeavor on your network you may have a need to create something that is relatively generic or similar to "fill in the blanks" so that it can be easily reused. For example, Post Office names may change, dates and times may change, etc. But the main message won't really be all that different. Make sure this communication is complete before you contact an area regarding this consolidation effort - being prepared goes very well when building confidence in this process with the end users and their managers.

    Sample end-user communication:
    Currently your GroupWise Post Office is (candidate Post Office name). All of the users on this Post Office will be moved to the (target Post Office name) GroupWise Post Office as the (candidate Post Office name) Post Office will be closed on Date and Time (Note: This date and time is 1-2 weeks after the date of the user moves). This is in association to an ongoing effort to increase response time and performance in GroupWise.

    The user GroupWise moves will take place on Date. Your GroupWise account will be unavailable from Date/Time "A" through Date/Time "B".

    On Date "B" when logging into GroupWise, you may be prompted to enter the IP Address of your Post Office. If this occurs, the IP Address of your new Post Office will be IP Address (see attached for example - we recommend you print it out for reference).

    Additionally, there are certain things that you will need to be aware of regarding the moving of your GroupWise account to a new Post Office; they are listed in the attached document entitled "GroupWise Move Impact" (we also recommend you print this out for reference). Please review this document prior to the Date/Time "A" so that you can help eliminate any confusion or possible issues relating to the "move" of your account.

    If you encounter any problems, you may contact _______ at ______ for assistance. If you have any questions prior to the Date/Time "A" please contact _______ for assistance.

    Thank you very much for your cooperation.

Now let me explain this communication and the process behind it. The date the Post Office is closing is typically 1 -2 weeks after all of the users, resources, etc. have been scheduled and communicated to be moved. This helps eliminate potential problems with the moves, it allows the workstations to redirect the client applications faster as they still hit the Post Office that they last connected to and most importantly, it allows you to go back to the old message store if you have to.

I communicated to users that their user account moves would take place on a date like Friday, January 21st. I then would elaborate on that by providing specific times and dates that the account would be unavailable (Date "A" and Date "B") by saying that the account would be unavailable from Friday, January 21st at 7:00PM through Monday, January 24th at 7:00AM.

As for the GroupWise Move Impact document, I will cover that in entirety in my next article.

Meet with the candidate area

I don't think that you need to discuss this process with every user involved on a personal basis, but you should approach the support people in an area, specific managers or key employees. You're looking for buy-in, and potential time frames to perform this consolidation where it would be most beneficial for everyone involved. This is where your sales pitch comes in. You should use items from my previous article "Let's Talk About GroupWise Consolidation". In your meeting, cover things like consistent performance in GroupWise from anywhere, longer life on the current servers; as RAM, disk (this is the disk that was researched in the discovery phase of this process), processor and LAN traffic will be drastically reduced.

This meeting should also touch on the following:

  • Provide a copy of the "draft" message to review (from above section).


  • Have a copy of the "GroupWise Move Impact" document for review (again, this will be discussed in my next article).


  • Determine a date and time for this change.


  • Discuss communication method (email to *.PO and support staff areas, possibly adding a reminder note that would be placed on the calendar for the day of the change).


  • Discuss the ramifications of a backup job interfering. To clarify this, if a backup job is running while the user moves are being executed, the server will be severely impacted and so will the GroupWise moves. You should know and understand, backup applications require file locks on GroupWise databases (message, user and host/domain). Backup applications also require processor, RAM and disk access all of which are competing with the GroupWise application and it's moves of users, etc. If the backup is not done from the same server, it will also require network communication and will most likely hog a significant portion of the available bandwidth. Keep in mind, GroupWise is a throttled application - if the processor hits " x "% utilization, it waits; it won't hog the CPU thus preventing an abend. It's best to postpone backups on the candidate server until after the moves have completed.


  • Discuss the final clean-up phase. Final cleanup includes, removing the remaining items on disk, removing the GroupWise Agents from NDS and unloading them from the server. This is the second point the area should see a nice benefit as the server should have additional resources after GroupWise is no longer in contention for memory. This final phase occurs 1 - 2 weeks after all of the users, resources, etc. have been moved.

Prepare for the change

Notify support areas or other administrators that this change will be going to occur. This will give them a "heads-up" so they don't add or move any users to this Post Office. It also lets those support areas know that this is a sensitive area at that point in time. During the time of the change, if end-users call in to report an outage, there is nothing worse than someone trying to troubleshoot what's been set in motion by the move process.

  • Now that you've reviewed the communication with the candidate area, you should have a finalized copy to send to all users on that Post Office (Include your Help Desk, Second level support areas and other key areas that may need notification. I like to provide at minimum two weeks advance notice to end-users in case someone is out on vacation or on the road.


  • Along with this communication, attach the "GroupWise Move Impact" document. This is key to avoiding potential problems.


  • I also went overboard for the sake of the end-users and would include a screen shot of user prompt with proper IP Address or DNS name (from what was found in the discovery phase).


  • If the candidate area liked the idea, send a Reminder Note to all users on that Post Office, schedule this Reminder Note to appear on the date of the change.


  • And here's one that seems obvious, but I'll mention it anyway - mark own calendar with change date and times. So others don't schedule something else during that time. While you're doing that you should probably mark your calendar for the clean-up phase date and time; just so you don't forget.


  • Contact your backup staff regarding this change and make sure that backups will not be run during this time or that they can be run outside the window that you require for this effort.


  • Finally if you have a Change Control component within your organization, make sure to work through appropriate means to make certain those processes have been completed as well.

The Change

I'm going to assume that by this point you've done your homework or are familiar with how to move a user. For this type of change you're going to move multiple users at one time. Keep in mind, there is no rule of thumb on how many users you can move at one time (I will discuss this in a later article and provide a way to determine your own thresholds). My thoughts on this; never move more users than you can without having enough time to restore the entire system back to the way it was before you started. In my environment that computes into leaving about 24 - 28 hours of extra time when dealing with a move in the area of 125 users. (DISCLAIMER: This is on my network and Novell only suggests moving 5 users at any given time, based on worst case scenario - things get stuck in the queues or the move isn't done in a timely fashion). The reason I move this amount of users is because I've tested fully AND I created my own little process for moving those "stuck moves" in a very small amount of time. Some of you, that I've talked to personally, may know what I'm referring to, for the others all I'll say is that it involves backing up and restoring data through the Post Office queues.

Before you move the users you should do what I call "pre-validation". I use a figure of 10% for this process. What I do is proxy to 10% of the total number of users and take snapshots of the calendars or other items (in my system all calendars are set to read access for minimum user - see a previous article entitled "GroupWise Client Application Best Practices" for more information. I keep these snapshots for my post-move validation; which is where I re-proxy the same accounts to verify the move process has completed successful.

Okay, once you set the user moves in motion you'll need to monitor the entire process. This will be covered in detail in a later article.

Post-Move Follow-up

I always like to keep the lines of communication open so that everyone knows exactly what has occurred. At this point, the change has completed, all of the GroupWise entities have been moved to the target Post Office. Take some time and send out a communication to the support staff and key people and managers of the area that was moved. Let them know what happened, what you saw during the process (you'll take notes while monitoring - trust me) and give them an idea of the success of the work that was done. For example; "everything went very well with the user moves this past weekend?" That's a great way to start out with.

If you did end up with any issues or if people are having issues because of the general impact of the move (not everyone will read the GroupWise Move Impact document that was sent) you may need to get involved with some resulting issues, none of which should be major (a couple archive paths reset, a couple proxy issues - nothing major).

Change Follow-up

Now for the actual fun! You get to drop that old location right of the GroupWise map. This process has a specific order so don't get carried away.

  • First, delete the NDS/GW Object. This is important because if you delete the data store first, you have to recreate/rebuild it so that you can delete the NDS objects.


  • After the NDS objects are gone, RCONSOLE the server and edit the autoexec.ncf and REM out the GroupWise load commands. You actually have some options, you can REM out the statement or completely remove it - I like to REM it out and put in a comment that the location was consolidated. I also leave the rest of the GroupWise startup files on the server, but I edit them and REM out any load statements (just incase someone tries to load them by typing "grpwise", "startgw" or whatever you may setup.


  • I then unload the GroupWise agents running on the server as they are no longer in use. You'll see this, as there will be no connections and the log file should be almost completely unused aside from a few user redirections.


  • Remove the directory structure from the volume. I always do this manually - that's just how I like to do this.


  • Update any monitoring applications, by removing the agents from the polling cycles so they don't report an outage. Maybe you should do this first - it's up to you and how fast your support area responds to alerts.

Final Change Follow-up

Here's what everyone was waiting for, the final communication to say, your server is free of GroupWise. Let them know how much disk space is free on the server, and let them know that the change is 100% complete. You should not need to deal with GroupWise or it's processes again in relation to the server.

Summary

As you've probably figured out, my next article will be about how moving GroupWise users and resources impacts the end users. I'll provide things to watch for, things to do ahead of time and an overall end-user communication. You should be able to combine this article, my last article and the next few articles and utilize them to form a successful, workable, overall process for consolidating your GroupWise system and tuning your servers to run with large numbers of users.

Watch for more articles by Dave Muldoon, every couple of weeks, under the resources link on GroupWise Cool Solutions - http://www.novell.com/coolsolutions/gwmag/features/trenches/tr_how_dave_does_it_gw.html.


Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com

© 2014 Novell