Preparing the New GroupWise Server

In this guide we assume that you have already installed and prepared your new Linux or Windows server for the move of your GroupWise system.

While we do not intend to go through all of the steps of installing and configuring your new server, we will point out a few requirements and recommendations. The bulk of this chapter will focus on moving a GroupWise system to Linux, simply because for most non-Linux administrators this is more of a challenge. If you are a NetWare or Windows administrator, you already know how to map drives and access Windows. While we feel that the section below dedicated to understanding the benefits of Linux is useful for everyone to read, if you are set on moving your system to Windows (even just from one Windows server to another), you can skip to the section on “Reusing an Existing Data Volume” on page 35.

Why Move to Linux?

The following section is dedicated to primarily helping sites on NetWare make a decision between Linux and Windows for their new GroupWise servers. That said, there will also be sites currently running GroupWise on Windows servers that might choose to move to Linux. If so, this next section will be useful for them as well. In any event, we think this is an important section to ponder as you make your decision to more your GroupWise system.

There are really two components to the “why” of running GroupWise on Linux. One is the technical (i.e., how does running GroupWise on Linux benefit us from an IT perspective), and the other is more political or even emotional.

The Case for Linux

There are many reasons why Linux enthusiasts, consultants, Novell, and even IT departments tout Linux over Windows. Here are a few that are most often cited:

  • Improved stability: Linux typically has fewer operating system faults of its own, and individual applications generally do not bring an entire Linux server down. Whereas on NetWare, an administrator could choose to run a particular application in its own address space to minimize the overall impact that an errant application might have on the server, Linux applications run this way by default. So if a particular application on Linux crashes, it is unlikely to bring the entire system down with it.
  • GroupWise High Availability Agent: GroupWise on Linux has access to the GroupWise High Availability Agent, which allows GroupWise Monitor to work with the GWHA to ensure that agents are always running, and restart them if necessary.
  • Better application fault handling and recovery: GroupWise agents restart in seconds on Linux. So, if you do have a post office agent or such crash, the high availability agent (or other script) can bring it back up quickly.
  • Core files are generated very quickly as well. Each application on a Linux server can be set to generate a core file if you are having problems, and you can be back up and running within minutes (Novell says seconds, but we all know that humans also only work so fast!), and deal with getting the core file to Novell after everyone is back working in GroupWise.
  • Database stability: According to Novell IS&T, they see far fewer database corruption issues in GroupWise databases due to hardware crashes or power problems. For whatever reason, Linux seems to manage “closing” GroupWise files more effectively during routine operation, and thus fewer files are left open to cause issues.
  • Automation: While certainly some scripting can be used on Windows to provide ease of administration, this cannot come close to the flexibility of Linux to design management scripts, health check scripts, code deployment scripts, coredump management scripts, backup scripts and the like.

So, as you can see, there are many good reasons to move to Linux from a purely technical standpoint. However, the political and organizational reasons why a company moves to Linux are often more intangible.

The question of “why” an organization moves to Linux is very important, but often not given nearly enough thought in our experience. It’s a given that if GroupWise currently resides on NetWare have to move somewhere. NetWare is no longer a supported platform for GroupWise agent components.

GroupWise is and has always been a somewhat rare exception to the Novell application offerings. GroupWise has always been available as a multi-platform product, and has been less tied to NetWare than any other Novell product (there are some other exceptions as well, but we aren’t going to get into those!!). eDirectory is also available on multiple platforms, but it seems to always be less for its own sake than to allow things like GroupWise and other Novell applications to exist on other platforms. For example, while eDirectory runs on Windows, we know of very few sites that use eDirectory as the primary directory for their Windows only networks. When eDirectory appears on a Windows server, it’s almost always to support a product like GroupWise without needing a NetWare or OES server in the mix.

There is no doubt that Linux is the true present and future of Novell products. That said, small companies where there is little or no Linux administrative experience should think good and hard about making this move before they are really ready. When customers ask us if they should move GroupWise to Linux, we have two important questions:

  • Who in your organization knows Linux well enough to administer GroupWise on that platform?
  • Why do you see moving to Linux as an important business decision?

Here are some of the most common scenarios:

  1. We can’t run GroupWise 2012 on Netware, so we must move. It doesn’t matter that we have no Linux experience at all, our salesperson says it just needs to be done, and we’ll be able to deal with it. Our secretary who knows how to reboot the NetWare server when we’re having trouble will be able to do the same with the Linux server, won’t she?
  2. With the changes in GroupWise 2014, it’s time to move on, and Linux seems the obvious choice. We’re looking at moving things over slowly, perhaps promoting our GWIA domain to primary and upgrading it first, and getting our feet wet before we move our post offices to Linux. Our administrators are working with Linux in a testing environment, and we should be in a good position with our Linux knowledge by the time we complete our migration.
  3. We have a comprehensive plan to move all of our mission critical operations to Linux. We have a lot of experience in the area. We have other applications and processes running on Linux now, so adding GroupWise to Linux will be easy for the Linux administrators. Hopefully the GroupWise administrators will not have too many problems, but we have a good set of people to support them if there are issues.
  4. We have our current GroupWise system on Windows, and wish to dismiss eDirectory altogether. However, we feel we could see some real performance gains with Linux, and wish to move our GroupWise system from Windows to Linux. We have administrators who understand Linux, and believe this could be a good move!
  5. We have to do something. We don’t want to move to Windows, we have to move GroupWise to something. We don’t have much choice here, and I think we’ll send the GroupWise administrators to a couple of Linux classes and then plan to get everything moved over during the upcoming long weekend about two months from now.

While you might think that the first scenario above is the most scary for us, it’s really not as frightening a situation as you might think. Certainly, we have small GroupWise customers who have no network administrators or GroupWise administrators on site, and rely on consultants to handle all of their networking needs just like the customer in the first scenario. For those, generally NetWare is just as foreign a concept as Linux. They don’t know Fat32 from NSS from NTFS; eDirectory from Active Directory. In many ways, for those customers, moving to Linux is all about the expertise of their consultants. If the consultant understands Linux, and can get to the office quickly when there is a problem, then the situation is not much different than with the current NetWare servers.

The second scenario is one that we like to see. For sites that currently have no Linux, bringing up a Linux server and installing a GWIA is very good practice, and gives the administrator something to cut his/her teeth on without having to worry about that all important post office with those databases full of information that we all need! Since GWIA SMTP is essentially a “pass through” process, there is very little catastrophic that can happen by moving a GWIA to a Linux server. Certainly, a site could experience some downtime of Internet e-mail if that new Linux server isn’t well understood, but actual data loss is unlikely. Of course, if you wish to put WebAccess or a POP3/IMAP4 GWIA on Linux before you upgrade all of your post offices, you will need to leave your current POP3/IMAP4 GWIA and WebAccess in place to service those older GroupWise post offices until after the upgrade is complete.

Perhaps the most appealing and frustrating things about a move to Linux for folks in the second scenario is that like NetWare, once you get the Linux server installed and working to your satisfaction, it just seems to run. This is very appealing, because you don’t worry that much about whether or not the system is working. It’s also very frustrating though, because this also means that there is very little opportunity to learn by doing a process over and over again! Years ago, when we first began our work with GroupWise on Linux, it took us months to remember things as simple as how to install an RPM! Danita had to write everything down, and look at her notes constantly in the beginning, because it was often weeks, if not months between times that she needed to truly “fix” something on the Linux servers. She ended up formatting her laptop hard drive and installing Linux on it, with VMWare for Windows, so that she would have to be confronted with Linux every day in order to learn it. Not everyone will be as ambitious as that in order to learn Linux, but we have to say, it really worked! As a side note, while a Mac isn’t Linux, you can learn a lot about Linux commands in the Mac terminal!

The third scenario is more common for large networks. We occasionally find a small to mid-sized company that has a good deal of Linux experience, but the typical organization that will have a lot of Linux experience on-site is a bit larger. The general downside with these installations is that the Linux administrator has a lot of Linux experience, but does not understand GroupWise, and the GroupWise administrator has a lot of GroupWise experience, but does not understand Linux. This can result in a lot of confusion in and of itself. So while this is generally a “happier” situation than some, it does not ensure clear sailing for the GroupWise migration. It will be necessary for the GroupWise administrator to learn some Linux in order to deal with management of the server, but it’s a nice warm feeling to know that someone in the organization will be able to help with critical issues (and maybe even just some hand holding).

The last scenario seems to be the most disconcerting though. There are many sites that are feeling a “push” to do something. They have enough Novell enthusiasts on the team to avoid a move to Exchange, and feel like moving GroupWise to Windows would be a “step down” or maybe even opening a door to a future move to Exchange. They are accustomed to the ease of managing GroupWise, and somehow feel like it should just be a “breeze” to get to Linux. It’s likely that no one in their office has ever touched Linux. While the perfect solution would be to hire a Linux administrator and bring him/her up to speed on GroupWise, that is threatening to the current administrators, and they are often willing to just say “I know I can do that” and then try to cram in as much Linux experience as they can in the next two months in order to avoid risking their authority in the department, or even their very jobs, by bringing in a new “Linux expert”.

In these scenarios, we always recommend a step back, and an assessment of just what can be done in order to bring the situation under control. If there is truly good management support to bring in Linux, then we try to slow down the push for the ultimate move and recommend a graduated solution such as the second scenario above. In some cases, we will flat out recommend that the customer move GroupWise to Windows if the Linux skills of the organization seem minimal, with little likelihood of changing in the near future.

Now, let’s be clear: We at Caledonia think that Linux is really the way to go for GroupWise. That said, however, there are some situations where a move to Linux just does not seem to make sense or even be prudent. In those cases, we caution customers against making rash decisions for the “big move” based on what “everyone else is doing”. After all, we didn’t all move to Exchange just because “everyone else is doing it”. Thus, if moving GroupWise to Windows seems more reasonable for a customer, we have a section in this book for that as well!

Developing Linux Skills

The primary purpose of this Section of our book is to assist you in moving your GroupWise system to Linux. It is beyond the scope of this book to teach you everything there is to know about Linux! That said, there were be times when we give you hints about how to facilitate Linux commands, expound upon the differences between Linux mount points and mapped drives and drive letters, case sensitivity and other sundries. We will try our best to cover all of the “gotchas” of moving to Linux. You will need to bring a certain level of Linux expertise to this party though.

In our discussion above of the move to Linux, one of the major considerations was the Linux expertise of those in your organization who will be managing the GroupWise system. Unless you fall into scenario #1 above, having someone on your staff who really understands Linux is crucial. If you fall into either scenario #2 or #4 above, it’s important to find ways to improve the Linux skills in your office. There are various ways to do this.

Using Linux to Learn It

As mentioned before, hands on use of Linux is by far the best way to learn Linux. Here are a few ideas about how to learn Linux better:

  • Put Linux on your workstation: We know this seems to be the most drastic of any of the possibilities, but it certainly gets the job done. We have found that with Linux in a virtual machine on an administrator’s Windows workstation, the administrator is rarely forced to use Linux. On the other hand, with Linux as the primary desktop OS, there isn’t much choice but to learn to install RPMs frequently, learn Linux command line utilities, etc. Linux at the desktop is really the “fast track” to learning about Linux on a daily basis.
  • Put Linux in a virtual machine on your workstation: You can either put a desktop version of Linux in a VM and try out things like the GroupWise client for Linux, OpenOffice for writing reports, etc, or you could install a Linux server product into the VM and learn to install web server components, play with user permissions and the like.
  • Set up a full blown Linux test lab: Some mid-sized to larger companies will not even consider their move to Linux for GroupWise without a full test lab. This is a very good way to get to know GroupWise on Linux before you actually make the move. If you have External Document Storage Locations for GroupWise Document Management, we highly recommend that you build a test lab and model your current system to ensure a smooth migration.

Studying Linux

There are many excellent resources for Linux available. We can’t even begin to list them all. Novell has some wonderful self-study kits; there are many good Internet resources; books galore. Find something that makes sense to you and have good reference materials at hand so that you can look up issues when they pop up. Don’t forget the folks at http://forums.novell.com to help with both GroupWise and Linux issues.

Special Considerations for Linux

Before we start, we will outline some of the special concerns about moving to Linux, and then we will start moving.

Here are a few things to consider before and during your move to Linux:

  • You have two general options for GroupWise on Linux. You can choose SUSE Linux Enterprise Server (SLES) or Open Enterprise Server (OES). There are benefits to each, which will be discussed below.
  • Linux has many more options for file systems, and depending on the version of Linux you use (SUSE Linux Enterprise Server or Open Enterprise Server) you will have different possibilities for file systems. We will discuss file systems in detail below.
  • Linux is case-sensitive. GroupWise on Linux will expect all file names and directories to be all lower case. We will discuss options for getting there later in this chapter. Even if you choose to use NSS with Long Namespace, we still recommend that you follow the instructions to ensure your GroupWise databases are all lowercase.
  • Linux isn’t always easily accessible, at least not in the way you’ve become accustomed to with NetWare or Windows. Since GroupWise 2014 uses a web based Administration Console, this is not as important as in the past. However, as you will see in “The GroupWise Administration Console” on page 115, there will be times when command line utilities are needed, so at a minimum GroupWise Administrators will need terminal access to the GroupWise servers.
  • Post Offices with DMS have three important issues to deal with:
    • Document Storage Locations need to be redefined when you move them. You must make sure to indicate not only the UNC value for the document storage location, but also the “Linux” location for the documents. (Some sites prefer to move their documents under the post office before making a move to Linux, and quite honestly, if this is at all possible, it is our preference at this time. We will discuss the pros and cons of this as well when we discuss moving GW DMS to Linux).
    • There is no Document Properties Maintenance applet available with GroupWise 2014. Thus, if you run GroupWise on SLES, you will need to enable Samba and access the post office via the Document Properties Maintenance application on Windows to make changes to your document properties. If you are on OES, you can use NCP for access to the GroupWise databases.
    • There is no GroupWise “Import/Export” applet for ConsoleOne on Linux. Many DMS sites use this tool for importing documents, fixing document number issues and the like. You would need to run ConsoleOne on Windows in order to use this applet. This, of course, would require that eDirectory remain in your system.

Once you have chosen your Linux distribution, you will need to make sure that a few items are installed when you install the server. While we do not intend to go through all of the steps of installing and configuring your Linux server, we will point out a few requirements and recommendations for the Linux server.

For OES, make sure that the following options are installed:

  • NCP™ server
  • eDirectory™
  • Linux user management (if you wish to LUM enable your adminstrators for easy access to the GroupWise directories)
  • ncpfs to move your GroupWise domain from NetWare (while there are other ways of accessing NetWare servers from Linux, this is still our preference, especially with administrators who might not be familiar with CIFS and the like on NetWare).

For SLES, make sure the following options are installed:

  • ncpfs to move your GroupWise domain from NetWare (see above).

The Great Linux File System Debate

When moving to Linux from NetWare or Windows, perhaps the most confusing issue is which file system to use. While both Windows and NetWare have multiple file systems (NSS vs. Traditional, NTFS vs. FAT), it has become fairly common for sites to simply use NSS on NetWare and NTFS on Windows without much thought about it. Linux has many file systems. Here are some of the file systems you will hear about:

  • EXT2
  • EXT3
  • XFS
  • NSS
  • BTRFS

Let’s talk about each of these in more detail.

  • EXT2: This is essentially the second generation of the “Extended File System” for Linux, and was the default file system for many distributions until EXT3 came along. It is still often used for boot partitions and places where journalling isn’t terribly important.
  • EXT3: This is the third generation of the “Extended File System” and includes journalling (i.e., changes are logged to a journal so that they can be replayed in case of a power outage or other failure, thus helping to prevent corruption in such cases). EXT3 is very popular and stable. It is, however, somewhat slow, especially when dealing with a lot of very small files (which is a common situation for GroupWise). That said, EXT3 is Novell’s stated recommendation for GroupWise 2012 systems.
  • EXT3 with HTree: EXT3 has an optional function that creates additional indexes for the system, which can speed up the access of files tremendously. This would seem to be a very useful function for GroupWise. However, the nature of how these indexes are written worries the GroupWise developers. While some smaller sites have enabled HTree without incident, there continues to be some question as to whether data truncation is possible when HTree is used on EXT3. For this reason, Novell obviously discourages the use of HTree on GroupWise systems. We defer to the engineers on this one. Caledonia does not wish to be the “source of authority” that promotes HTree only to later find out that it causes even one customer to lose vital GroupWise data! Use something else. It is important to note that SLES 11/OES11 with EXT3 has HTree turned on by default.
  • XFS: XFS is a robust file system that provides for very fast access for large file systems and large files. Many GroupWise sites use XFS and are happy with it. Novell supports it, but has not done extensive testing.
  • NSS: Technically, NSS is only available on OES Linux (we say technically, because there are of course possible ways of compiling SLES to allow for NSS, but when we speak of NSS we typically expect that you are running OES). While NSS on OES1 posed some problems, not only for GroupWise, OES2 NSS seems quite stable for GroupWise systems. Some sites will be very tempted to use NSS if for no other reason than their current NSS partitions can easily be converted over to their new Linux system without having to actually “move” the data (i.e., the Linux server will simply read the NSS drive that was on NetWare before). That said, “converted” NSS volumes will suffer many performance problems that a new NSS volume, configured with GroupWise in mind would not have.
  • BTRFS: Known colloquially as Butter FS, this system is also seen as an up-and-coming contender for GroupWise systems. Novell also has stated they will “support” BTRFS, but do not test it.

Technically, while Novell Clustering Services is available for all supported file systems on OES 2, NSS will be the fastest for GroupWise in a cluster.

Perhaps the one reason why we would love NSS is the option of salvage. However, Novell recommends that if you use NSS for GroupWise, you turn off salvage!

Our recommendation for the file system depends in good part on where the GroupWise data will reside, and which Linux OS you choose. Here are, then, our recommendation:

  • NSS for OES
  • EXT3 (no HTree) on SLES

NSS for OES

Our testing has shown that the following NSS setup is the best configuration for GroupWise:

  • create a new NSS volume
  • disable salvage at create time so no salvageable files will ever have existed on the volume
  • change the default name space (again so none ever existed any other way) to UNIX
  • enable the noatime option for your volume in /etc/fstab

volname vol_mountpoint nssvol noauto,rw,name=volname,noatime 0 0

Our friends at NDS8 (http://www.nds8.co.uk) have seen as much as a 50% performance increase with this configuration over a “reused” NetWare NSS volume. So, while it is very convenient for sites moving from NetWare to Linux to not “move” the data, the very rich NSS features are largely unneeded for GroupWise, and there will be tradeoffs that might outweigh the initial time savings on the migration of data.

If you do choose to keep your current NSS volume, make sure that you do the following:

  • Files and directories should be converted to all lowercase
  • Turn off salvage completely
  • enable the /noatime command in NSSCON

The conversion to lowercase can be done fairly quickly with free or shareware Windows utilities, or Linux scripts that change the case. We prefer a simple Windows utility called Change Case. It can be found at many download sites with a quick “google”.

Even knowing that we recommend against it, some sites will choose to “reuse” their current GroupWise NSS volume to avoid the downtime of a copy of the data. It is beyond the scope of this book to cover all aspects of moving an NSS pool/volume from a NetWare server to a Linux server. There is ample documentation for this process found on the Novell documentation site at http://www.novell.com/documentation/oes2/stor_nss_lx_nw/data/bt8gbxo.html.

There is of course one other reason to put GroupWise on NSS on your Linux server, and that is simply “comfort level”. Most NetWare administrators who are unfamiliar with Linux have a certain sense of security leaving their GroupWise systems on NSS. We are not going to argue with that!

All in all, NSS seems to be the best choice for GroupWise if you have it available, especially for clustering. It will be fast and stable. It will not, however, behave exactly as you are accustomed to on NetWare, especially if you take the recommendations to heart to pare down the NSS options for your GroupWise volume.

EXT3 for SLES

EXT3 is becoming the preferred file system for GroupWise on Linux when NSS is not available. It certainly has some speed issues, but we are not convinced that the benchmarks comparing EXT3 and other file systems are that noticeable in daily usage on GroupWise. Additionally, EXT3 is the default file system on OES 11/SLES 11 for native Linux partitions, and it is likely that this will remain the case for some time. There is one huge caveat that you must remember though: as tempting as the idea of HTree on EXT3 might seem, do not risk your GroupWise system to this indexing method. In the future, this could change, but as of the time of this writing, we cannot stress enough that this is a dangerous combination.

NOTE: Remember that HTree is now enabled by default, so you should consider this when creating your new volumes.

Understanding Linux Mount Points

As we discussed above, we are not going to “teach you Linux” in this book. There are, however, various Linux concepts and ideas that we will expound upon and Linux Mount Points is one of those concepts.

If you wish to copy data directly from a NetWare or Windows server to the Linux server, you need to be able to see the data on the NetWare or Windows server from the Linux server.

In the NetWare world, for a NetWare or Windows server to access a volume on another server, everything is done via UNC paths (\\server\volume\path), or NetWare pathing (such as SERVER/VOLUME:\Path). Windows can also use UNC paths for the connection, or map a drive letter to the remote location.

Linux doesn’t really use UNC paths for anything. In order for Linux to access a file system on another server, Linux simply “mounts” that file system into its own file system hierarchy. In some ways, this is similar to how a Windows server (or workstation) might assign a drive letter to a volume on another server. If you mount \\gwserver\gwvol\gwdata to g: you now know that you can bypass entering all of the path to the server, and simply go to “g:” to access the GroupWise data volume.

Likewise, in Linux, a “mount point” is created for the \\gwserver\gwvol\gwdata location, and then you simply navigate to that directory on your Linux server and you see all of the files on the NetWare volume that you have mounted.

Traditionally, Linux puts all of the “external mount points” into the directory structure under /mnt. There is no technical requirement for putting your mount points in /mnt, but it is a nice, standardized location for them, so we will use that for our examples.

So, let’s say that we wanted to be able to see all volumes on our NetWare server where the current GroupWise system resides. We could create a /mnt/netware directory for the structure, or we might prefer to create directories by server name. If we were to choose the latter, we might create a directory called /mnt/gw1 for a NetWare server called “gw1”. The following are instructions on how to mount volumes from a NetWare server into the Linux file system.

To mount the NetWare volumes into our Linux file system, we would perform the following steps:

  • On the Linux server, open up a terminal window.
  • su root” to become root for this session.
  • Create a directory structure for your mount point. For our purposes, we have created /mnt/gw1 as the mount point for our NetWare server.
  • We have chosen to connect to our NetWare server via ncpfs. To mount the NetWare server via ncpfs, issue the following command (remember, we instructed you to install ncfps earlier in this section)

ncpmount -S server -A 123.123.123.123 -U userid -P password /mnt/gw1

replacing your server name for “server” and your server’s IP address for 123.123.123.123. For example

ncpmount -S gw1 -A 192.168.100.200 -U danita.cnc -P password /mnt/gw1

NOTE: You might wonder about the “user.context” vs. “.user.context” in this example. While “.user.context” works on some versions of Linux, it fails on others. In our testing, “user.context” has always worked on all versions. You might keep this in mind if you experience any problems authenticating with ncpmount.

This will actually mount all volumes from the NetWare server to this location. So, if we cd to /mnt/gw1 we will see a directory called SYS, one called GWDATA, and any other volumes that are on that server.

Dealing with Linux Case Sensitivity

If you look at your current GroupWise domain and post office directories, you will notice that many files and directories are in all uppercase, and many are all lowercase. It is important to know that while both NetWare and Windows “respect case” during the “save” process, neither of them “discriminate case” upon reading. Now, this might be a long way around saying they are not “case-sensitive,” but it’s an important concept to understand. Let’s take an example. If a user is creating a WordPerfect document and chooses “File|Save As,” typing in MyLetter.WPD will show the “case” distinctions in this document name when viewed in Windows Explorer or from a command prompt. However, another document named myletter.wpd cannot be saved in the same folder without overwriting the existing document.

Linux, however, is absolutely case-sensitive. MyLetter.WPD, myletter.WPD, MYLETTER.WPD and myletter.wpd are four distinct file names. All four documents can legally exist in the same Linux directory as separate and distinct files. This is not a huge problem when moving domains and post offices to Linux, except that you must be aware of the issue and deal with it. All files and directories for the Linux domain and post office must be all lowercase, otherwise the agents will simply not see the “proper” file and will fail to load. Prior to loading the POA on Linux, we will need to change the case of all files and directories for the post office. During the migration of the data using Novell’s DBCopy utility, we can use the “migrate” switch to force all file names to lowercase. Thus, any migration that we do, other than the possibility of reusing an existing NSS volume that we discussed above, will automatically change the case for us. If you wish to reuse your existing NSS volume on your Linux server, you can use a Windows utility called “Change Case” or you can use a Linux script to do the change for you.

NOTE: If you are using NSS volumes for your GroupWise data on Linux, you can enable the “Long Namespace” option. This essentially removes the case sensitivity from the volume. If you do that, you might think that you would not need to change the case of the GroupWise files. However, we have found multiple instances where things fail because of case in this situation. You must ensure that the case be changed for all GroupWise data on Linux. Also, if all of your data on Linux is lowercase, moving the system to a new, non-NSS volume during a disastery recovery situation would give you more options.

The easiest thing to do is simply download a free Windows utility called “Change Case”. There are Linux scripts that can do this as well, but we recognize that most people reading this book are new to Linux, and we want to make this as painless as possible. There are many locations for this Change Case utility, and we do not wish to favor one download site over another. So just google for “change case utility”. The download file generally is chgcse31.zip. If you have difficulty finding this utility, e-mail us at info@caledonia.net and we will point you in the right direction. The important thing is that no matter what you use to change the case of GroupWise directories, all files and subdirectory names must be all lowercase. Additionally, make sure that you unload your MTA and any associated gateways and kick everyone out of ConsoleOne before you attempt to change the case so that there will be no access conflicts.

Reusing an Existing Data Volume

Depending on your server configuration, you may choose to reuse your existing GroupWise Data Volume and avoid copying data altogether. This is especially true if you are using attached storage such as a SAN. If you are moving Linux to Linux or Windows to Windows, this is very practical. It is even possible to reattach your existing NetWare NSS volume to OES if you decide that is in your best interest. We specifically discussed the issues with reusing an NSS volume above in “NSS for OES” on page 31.

In any event, depending on the age and suitability of your current storage systems, your existing GroupWise Data Volume may be perfectly suitable for use on your new server. In “Moving a GroupWise Domain” on page 53 and “Moving GroupWise Post Offices” on page 159 we assume that you are in fact copying the data from one server to another. If this is not the case, you can treat the new server as an in-place upgrade, with the exception of needing to change the IP addresses of your agents, and changing the file locations of the databases if required.

It is outside the scope of this Guide to cover the specifics of attaching storage to your servers. We will assist you with upgrading GroupWise once your data is in place though!

Making GroupWise Servers Accessible for File Copy and Administration

GroupWise is one of those applications where we rarely worry about giving users access to the actual file structure. Administrators, however, occasionally need physical access to the domain database and often to the post office databases and files themselves.

Linux: There are three ways to manage this:

  • Use ssh utilities to access the GroupWise server.
  • Use Samba on SLES to access the GroupWise directories from Windows.
  • Use NCP on OES2 to access the GroupWise directories from Windows.

We particularly recommend that SSH be available for various purposes.

Windows: For Windows you generally simply need to create a Windows share that can be accessed from other Windows workstations and/or servers.

eDirectory

eDirectory is no longer a required component of GroupWise. If you are moving your GroupWise system to OES, you will still have eDirectory available, and can continue to Integrate your GroupWise system with eDirectory as you see fit. For more information on the Directory, see “Directory Integration and Synchronization” on page 61.

One of the big questions when installing a new SLES or Windows server is whether to integrate with eDirectory or Active Directory, or have no Directory integration at all and use the native GroupWise Directory. If you will be retiring all NetWare and/or OES servers with this migration, you should decide whether you wish to keep eDirectory in your network. Here are few reasons why you would no longer need eDirectory in your network:

  • You are essentially a Windows shop and will be integrating with Active Directory only.
  • You are a small business, and really have no external directory needs at all.
  • For whatever reason, you choose to use the GroupWise Directory, an no longer have a need or desire for eDirectory in your network.

Running your GroupWise Agents as Linux Daemons/Windows Services

Perhaps one of the most difficult transitions for GroupWise Administrators (especially those running GroupWise on NetWare), is getting used to the idea that you will no longer have a GUI console for your agents. While many Windows administrators are accustomed to running their agents as services with no console screens, this is a very foreign concept to GroupWise Administrators who run GroupWise on NetWare. This is something that you simply must accept. No amount of arguing or begging will change the fact that while there are GUI Consoles on Linux and Windows that can be used for testing, you should rarely (we’d rather say never) use the GUI Console for the agents in production on a Linux or Windows server. In order to use the GUI Consoles, the user running the GroupWise agents must always be logged into the Linux or Windows server. This is not something that is recommended by Novell or Caledonia, and it is definitely seen as a taboo by both Windows and Linux administrators. You will need to learn to love the HTTP Monitors for the GroupWise agents. If you have never used the HTTP monitors before, we’ll walk through enabling them, and looking at their features.

The GroupWise Server Migration Utility

Novell has a utility called the GroupWise Server Migration Utility. The purpose of the utility is to facilitate the move of GroupWise systems from NetWare or Windows to Linux. In this guide, partly because we wish to avoid installing an “older” version of GroupWise on your new GroupWise server, and partly because we think understanding the move is important, we will teach you how to move your GroupWise system to your new server entirely by hand. We think this is the best way to approach the move. That said, however, there are people who just like to have a GUI and a Utility to assist them through such moves. While we will not use the GroupWise Server Migration Utility in this guide, we will not be hurt if you decide to use the utility for your move. The knowledge about what happens “behind the scenes” in a move to a new server that you will gain from this book will help you should anything go wrong during the use of the migration utility. So, if when the time comes to do the move you decide to use the migration utility, hopefully you will be able to approach the migration tasks with increased confidence in your abilities and better understanding of the processes behind the migration. Understand though, that the Migration Utility will not perform a move and an upgrade simultaneously. The only way to use the Migration Utility is to migrate at your current version of GroupWise to Linux, and then after the system is running on Linux, perform an upgrade. Thus, realistically the migration utility is only useful for sites upgrading from GroupWise 8 or GroupWise 8. That said, we can do this migration and subsequent upgrade quite seamlessly without needing an additional upgrade step in the middle, and that is what we propose to do in this guide!

With the initial server preparation done, we can now start our GroupWise components move. We will begin with a domain move in the next chapter.