Now that we’ve looked at the overview of the upgrade process, the first step of the actual work is to upgrade your primary domain to GroupWise 2012. If your GroupWise system is a simple one server system, or even a multi-server system managed by a single administrator, this is a pretty easy task. Your primary domain gets upgraded, and you are on your way! However, if you happen to be in a larger system where the administration is distributed across multiple departments, locations, or even continents, this becomes more complicated. The primary domain MUST upgrade first. In most larger organizations, the primary domain will be a domain that is created solely for the purpose of administration and routing. It will not own any post offices or gateways, and will reside on a separate server. This is done often in larger organizations, and if this is the case, hopefully the owner of that domain will be willing to upgrade it quickly. However, if the administrator owning the primary is not as eager as you to upgrade, then you have a few choices.
- Wait for your primary domain to upgrade
- Request that a domain in your control be promoted to primary temporarily until the location that owns the current primary domain decides to upgrade.
While in some organizations this is often seen as a political matter, the primary domain’s main purpose is to provide uniqueness of names throughout the system and replicate all changes in the system to other domains. It is generally not a problem to promote another secondary domain to primary if required in order to begin your upgrade.
How Does the Upgrade Work?
At the domain level, a GroupWise upgrade is really just a database conversion from one version to another. The former GroupWise domain database (version 5.0 through 8.0 works the same), is RECOVERED by the MTA’s administrative thread and CONVERTED to the new version. For a primary domain, this requires two simple components:
- The Message Transfer Agent software must be at GroupWise version 2012
- The dc (dictionary files) in the domain directory must be at version 2012
For a secondary domain, a futher prerequiste is that the primary domain must have been upgraded, and the secondary domain must have received the notification from the primary domain that it is now a GroupWise 2012 domain and the secondary is allowed to upgrade
We realize that this sounds simplistic, but it really is that simple. When you upgrade your domain, you are simply recreating your domain database to be a GroupWise 2012 database. This update then triggers a message to be sent to any post offices that might be owned by the domain,. If you are upgrading the primary domain, the message is also sent to any Secondary Domains that are in the system. This message updates the post offices and secondary domain databases with the information that the primary domain is now a GroupWise 2012 domain. Unless this message is properly delivered (MTAs are down, POAs are down, etc.), the other domains and post offices will not upgrade, even though they may be running the GroupWise 2012 software for their agents. We’ll discuss this more as we walk through this upgrade.
Getting Ready for the Upgrade
Once you receive your GroupWise 2012 media (typically as a download from your Customer Portal), you will of course be very anxious to get started! If you’ve gone over Preparing for Your GroupWise Upgrade, and have decided your rollout plan, possible pilot needs, and upgrade time frame, you are ready to jump in. For the Windows version, if you download the software it will most likely be in a self-extracting EXE file or a ZIP file. You can unzip it with your program of choice into your new Master SDD location. If you are downloading the Linux files, they will be in a tar.gz file. Use tar -xzf to extract it. For example, in the directory where you wish to make your Master SDD (perhaps /grpwise/gw12soft):
tar -xzf gw12.0.0-97810_full_linux_en.tar.gz
Most sites will want to place the GroupWise software in an accessible location out on the network. Where you put it is up to you, but it must be accessible from the Linux or Windows server where you will install GroupWise.
Upgrading Installing ConsoleOne
Of course, you can’t really do much of anything without the latest version of ConsoleOne and the GroupWise 2012 snapins for ConsoleOne, so that’s the first order of business. As mentioned in Chapter 2, GroupWise 2012 requires ConsoleOne® 1.3.6h or later. This is included in the GroupWise 2012 media. This also requires Java Virtual Machine (JVM) 1.5.11 or later, which is installed along with ConsoleOne. It is very important that you upgrade ConsoleOne to this version. The GroupWise 2012 snapins will not function with older versions of ConsoleOne.
If you do not have at least ConsoleOne 1.3.6h installed on your administration workstation, you should install it now. While there is an installation routine in the GroupWise setup that allows you to install ConsoleOne and the snapins during the installation of your agent software, we want to go ahead and check the schema of your eDirectory tree before we jump into the actual upgrade. If you already have ConsoleOne 1.3.6h or greater installed, you can skip to “Updating Your ConsoleOne Snapins” below.
Locations for Administering GroupWise
For those of us who are long time GroupWise on NetWare administrators, the question of where to place ConsoleOne seems very straightforward. We run it from our workstations of course! And certainly since you will have GroupWise 2012 on Windows servers or Linux servers you can continue to administer GroupWise directly from your workstation, provided that you have direct file access to the server housing GroupWise. For Windows of course this would mean that you must have file access from your workstation to your Windows server. For Linux the same thing applies, but can be much more confusing. If you are running GroupWise on OES2 Linux, you can serve up your GroupWise volume as an NCP volume (regardless of the file system you are using), and map that drive just as you would a NetWare drive. If you are running GroupWise on SLES, you would need to load SAMBA and mount the drive from your Windows workstation as though you were accessing a Windows server. UNDER NO CIRCUMSTANCES should you serve up your GroupWise volumes under Linux as an NFS mount. This can cause serious file locking issues, and ensuing corruption of your GroupWise databases.
Even though it is possible to administer your GroupWise system on Windows or Linux from your local Windows workstation, many administrators choose to run ConsoleOne directly on the GroupWise server itself. To install ConsoleOne on your Windows server, install ConsoleOne and the snapins on the Windows server the same way as you do your Windows PC. Instructions for installing ConsoleOne on both Windows and Linux follow.
In your Master SDD created above, you will find a directory called “ConsoleOne”. Run the install.exe program in this directory to install ConsoleOne on your administration server/PC. By default this is c:\novell\consoleone\1.2. If you have located this somewhere else on your PC (for example on d:), the installation routine should detect this. It is a good idea to double check this during installation to avoid having two separate versions of ConsoleOne on your server/PC unless you wish to have two versions for some special purpose. The installation will create a shortcut to ConsoleOne if this does not already exist.
In your Master SDD created above, you will find a directory called “consoleone” and a subdirectory called “Linux”. From a Linux terminal prompt, change to your Master SDD (in our example below /grpwise/gw12soft) and perform the following commands:
You will now go through the installation routine for ConsoleOne on your Linux server. ConsoleOne on Linux is launched by running /usr/ConsoleOne/bin/ConsoleOne.
Once your version of ConsoleOne is at 1.3.6h or greater, you also need to update your ConsoleOne snapins for GroupWise 2012. You can do this during your initial domain software installation (see “Installing your Agent Software” below), or you can do it manually from your SDD. Whenever you receive new GroupWise software, it is not really necessary to run the installation routine to update your GroupWise snapins. While it is convenient to do so if you are in the midst of installing the GroupWise agents anyway, if you need to roll out the snapins to multiple PCs, you can simply follow these steps:
In your Master SDD under the Admin directory, there is a C1ADMIN directory. Under there you will see directories such as bin, snapins, etc. The “simple” way to update your ConsoleOne snapins is to copy all of these directories into the c:\novell\consoleone\1.2 directory (assuming that is where you have installed ConsoleOne). Under that directory are also directories called bin, snapins, etc., and you will be prompted if you should overwrite those directories. Answering in the affirmative will copy the new snapins into the ConsoleOne structure and you will be ready to go!
NOTE: Some manual updates of the snapins might fail due to missing VS2005 runtimes. If you run into a problem with ConsoleOne after manually copying the snapins, run <SDD>\gwinst\vcredist_x86.exe.
For the most part, it is easiest in Linux to just run the install routine and choose to install the GroupWise Administration. However, this will frequently force you to upgrade all other GroupWise components on that server, so we’ll show you how to update the snapins manually. From a Linux terminal prompt, as root change to the installation directory for the snapins as follows:
rpm -Uvh NOVLc1Linuxjre-1.5.0-11.i586.rpm
rpm -Uvh novell-groupwise-admin-12.0.0-97810.i586.rpm
This will install your ConsoleOne snapins. Please note that the file names above are the file names as currently listed in the GroupWise 2012 download. These will change with new versions of GroupWise as they are made available via download. Substitute the versions of these files as necessary. If you receive an error that there are dependency problems when upgrading your snapins, you should add the –force switch to the command. For example:
rpm -Uvh –force novell-groupwise-admin-12.0.0-97810.i586.rpm
NOTE: Sometimes people ask us when they should install the GroupWise 2012 snapins in preparation for an upgrade. We usually recommend that you install the snapins when you are ready to upgrade any domain that you administer. For example, if you are on an distributed system, and there are many administrators, upgrade the snapins for the administrators as domains they manage are upgraded. While it is safe to use GroupWise 2012 snapins on older systems, you may find that the snapins for some functions will change. For example, the GWIA snapins do not check to see if you are using a GroupWise 2012 GWIA and will show you options that might not be available for a GroupWise 8 or earlier GWIA. It is just less confusing to wait until you need the GroupWise 2012 snapins to install them. That said, however, once you upgrade your primary domain to GroupWise 2012, you should use those snapins any time you access a GroupWise 2012 domain, so it will be necessary to roll these snapins out to all locations that might access the GroupWise 2012 domain.
In Chapter 2, we discussed the importance of making sure your eDirectory tree is in good health. GroupWise 2012 may need to extend your eDirectory schema, and you certainly do not want to attempt any changes to your eDirectory schema if anything is pending or problematic in the tree.
WARNING: Some of the worst “GroupWise” issues we’ve been called in to salvage had little to do with GroupWise itself, but were to fix problems that arose from making changes in the system that required modifying an unhappy eDirectory tree! While schema extensions will not likely cause any great harm to your tree if it is out of whack, it’s best to make sure that everything is replicating properly before you begin.
NOTE: Some minimal steps you can take to ensure that your tree is healthy are to do a “check synchronization status” in dsrepair from the root partition server and/or check the agent health in iMonitor.
If your tree is happy and healthy, you will need to check and possibly extend the schema (or have a more powerful admin do so if you are unauthorized to access the root of the tree). In order to extend the eDirectory schema for GroupWise 2012, you must use ConsoleOne with GroupWise 2012 snapins. In ConsoleOne, click on your eDirectory tree name (not the GroupWise “system” icon), and under Tools choose GroupWise Utilities|Check eDirectory Schema. You will be instructed to extend your tree’s schema, if necessary. Just click next and let the schema update. If you are upgrading from GroupWise 8 you should not see any extension upgrade prompt. It does not hurt to test this though!
Enabling the HTTP Monitor for Your Agent
We have found that there are many GroupWise sites where the HTTP (Web) Monitor is not in use. Especially with GroupWise 8 and later, these HTTP Monitors have become more and more important. If you define a userid and password for the HTTP Monitors, you can perform all of the functions that you used to perform at the GUI Consoles for your agents, as well as new functions that were not available on the GUI Consoles. If you do not have your HTTP Monitor enabled, now is a good time to do so.
In ConsoleOne, click on the GroupWise System Globe, and perform the following steps:
- In the dropdown list that shows “Users”, change the setting to “Message Transfer Agents.”
- Find the MTA for your domain, right-click and choose Properties.
- Now click on the triangle in the GroupWise tab and change to Network Address.
- Make special note of the HTTP port that is defined for this agent. By default, the HTTP port for the MTA is 7180.
- If there is nothing in the HTTP port field, put 7180 (or another port of your choosing).
- Now, on the GroupWise tab, change to the Agent Settings screen. Scroll down to the HTTP Monitor settings. If you have never enabled the HTTP monitors for your agents, you will need to decide on a good userid and password for the HTTP monitors. Please note that this is neither an eDirectory user nor a GroupWise user. This is an entirely made up user and password solely for the use of the HTTP monitors. If all administrators in your organization will have rights to use the HTTP monitors, then it is a good idea to have the same userid and password for all agents. If you need to limit rights to some agents to various groups, set up a userid and password for each group of agents that will be monitored. Enter the userid and password that you have decided on here in this screen.
- Save your changes.
Prepare The Domain
When you are ready to continue your upgrade, we will first check the domain to make sure that it is ready to upgrade. First, in ConsoleOne, select the domain object and choose Tools|GroupWise Utilities|System Maintenance|Validate Database. If your database shows as valid, you can proceed. If for some reason the database does NOT validate, you should rebuild it. In order to rebuild the database you must first shut down the MTA and any gateways that attach to the domain database. At this point, we are going to shut down these agents for the upgrade anyway, so if you need to rebuild your database, first follow the instructions immediately below on shutting down your agents. Once the agents are shut down, return to ConsoleOne and choose Tools|GroupWise Utilities|System Maintenance, and this time choose Rebuild Database. Linux
On Linux, you must upgrade all GroupWise components at the same time, so you need to stop all processes that are GroupWise related. This includes all GroupWise agents and gateways and GroupWise Monitor. We are assuming that you are running your agents as daemons. If, however, you are running them with their GUI consoles, unload all of the agents by shutting down the GUI consoles. Close the GroupWise Linux client if it is running on the server. Finally, to be certain that all agents and gateways are closed, type the following commands at a terminal prompt:
These are the three main scripts that control GroupWise agents and gateways on Linux (although grpwise-wa was moved into the grpwise script with GroupWise 8). You may receive errors if you are not using the grpwise-ma or grpwise-wa scripts, but it does not hurt to attempt to stop them even if you do not have these scripts installed.
After all GroupWise components have been shut down, type the following into the terminal prompt to verify that no GroupWise components are running:
ps -A | grep gw
If at this point you still see GroupWise components loaded you can kill them individually, either by pid or name – for example:
(if you show a GroupWise component with the pid 9860 running)
For Windows, you must also shut down all of your agents that access the domain database. If you are running the agents as services, go into the services console from the Control Panel, right click on the GroupWise agents, and choose stop (see ). If you are not running the agents as services, go to the agent consoles and exit via F7 or from the agent menus.
After your agents are shut down, leave them down until you are instructed to reload them below.
The Domain Upgrade Overview
With GroupWise 8, Novell created a brand new installation routine geared towards helping newer GroupWise administrators to create a GroupWise system with all of the components necessary to get GroupWise up and running. This has continued with GroupWise 2012. For example, the installation routine allows you to install not only ConsoleOne and the GroupWise Agents, but also the GWIA. This will allow a brand new GroupWise Administrator to create a new GroupWise system, including the GWIA, in one sitting, and get up and running more quickly. However, in changing the installation routine to streamline the work for a new administrator, some of our familiar installation routines have been removed, and we will have to rely more on the wizard than we might have in the past. But don’t despair! We will veer away from the wizard often enough to please the purists in the crowd!
NOTE: If Windows administrators look under the AGENTS directory, or the INTERNET/GWIA directory you will find that there are no longer any installation programs for the agents or the GWIA individually. These components must all be installed from the setup.exe file found at the root of your SDD.
Depending on your setup, you may be simply upgrading your domain during this sitting, or you may be doing more than that. If any other GroupWise components exist on the same server as your domain, you need to upgrade them now too. Let’s look at the possible scenarios.
- Simple single server – you need to do everything. You will install the MTA and POA software, upgrade the domain and then the post office, and then move to upgrading your GWIA, WebAccess, etc.
- MTA & POA on same server – one installation run will get you ready, and then we will perform the upgrade steps for both the domain and the post office on this server, and you’re done with this server.
- MTA on its own server – run the installation to install the software, and perform the steps to upgrade and verify.
- MTA with gateways such as the GWIA and WebAccess on the same server – upgrade the domain and then move to the GWIA and WebAccess upgrade
So, let’s get down to it.
In the sections above, we shut down the MTA, POA and gateways on your server. It is important that you have not reloaded any of these components since then, or if you did that you go back through the steps to unload the agents and verify that everything is down. Once the agents are unloaded, look in the root of the Master SDD we created earlier.
If you are running your agents on Windows, you must run this installation directly on the Windows server, rather than from a workstation attached to the Windows server.
In the root of the Master SDD, you will see the setup.exe program that will be used for this upgrade. When you run this program, you see the Window in Figure 5-2.
- Click on Install GroupWise System.
- Click Yes on the next screen to accept the license agreement.
- Click Next on the next screen to do a standard install. You will see the window in Figure 5-3.
- You will notice on this screen that we have many options. For our purposes, we will choose “Install Individual Components”.
- If you did not update your ConsoleOne and GroupWise snapins on this server earlier as listed above, you can choose this option here now.
- Choose GroupWise Agents as an option to install.
You will notice that at this point you could also choose to install the GWIA files as well if you needed them on this server, but we prefer to do this in a separate step, so keep this option unchecked for now.
- The next screen seems to be a holdover from the combined Windows and NetWare installation routines of the past, and has a single radio button for Windows. Just click next.
- If you checked the box in step 5 above to install GroupWise Administration, you will see the screen in Figure 5-4. We are going to create our SDDs manually, so leave only the Install administration files option checked. If you did not choose to install GroupWise Administration, jump to Step 10 below.
- At the next screen you will be prompted to verify the location of ConsoleOne. This should show the actual location of ConsoleOne as installed on the Windows Server where you are running the installation program.
- The next screen will give you the option of where to install your files on your Windows server, and options for the installation. Notice that in our example in we have chosen the option to “Install files but do not configure agents”. This is because we are performing an upgrade, and that assumes that you already have configuration files for your MTA, and that you have your server set to automatically load your GroupWise components on startup. If for some reason you need to configure your agents, uncheck this option and see the section below entitled “”. You will also need to do the configuration of your agents if for some reason you wish to change your agents from running as console applications to services. It is highly recommended that you run your agents on Windows as services, to avoid needing to log into the Windows server to activate the agents.
It is very important to note in this screen that the default installation path is c:\program files\novell\groupwise server\agents. Of course, the biggest problem with this location is that since we are reading an upgrade guide, we know that prior to GroupWise 8 the agents have been installed by default in c:\grpwise, This could cause big problems that can be easily avoided by just changing this path to the location of your current GroupWise agent files (default c:\grpwise). Of course, this will mean that your server will not have its agent software in the location that Novell is now designating as the new default. You need to decide if this is an important issue for you. We here at Caledonia will gladly admit that we didn’t care a bit, and decided it was easier to just leave the agents in our default location of c:\grpwise on our Windows server. This avoided having to remove existing services and reconfigure the agents during the installation. If you wish to replace your current location with the c:\program files location that Novell is now suggesting, then uncheck the box that says to Install the Software but do not configure the agents, and jump to the “” below.
NOTE: If you do choose to keep the new default that Novell suggests, you MUST reconfigure your agents. Otherwise there will be no startup files created for your agents in the new location, and your existing Windows services will point to the wrong location for the executable files.
- Next you will be presented with a summary screen showing your choices for the install, and the installation will proceed.
- When the installation has completed, leave both boxes (“Save settings for a future installation” and “Launch Agents Now”) unchecked (we do not want to start up our agents yet!), and click “Finish” to close the installation program.
Now that your Windows agent software has been updated, we need to move on to the actual process of upgrading the domain to GroupWise 2012. See “Performing the Domain Upgrade” below.
Running the Linux installation routine is a bit different, in that you are not allowed to pick and choose what you install when running this installation script. The script will detect what GroupWise components are already installed on this server, and it will insist that they all be updated at the same time.
In your Master Linux SDD (in our case /grpwise/gw12soft), run the install script as root. For example:
gwlinux:/grpwise # ./install
You will see the screen in Figure 5-5.
- Choose install products.
- Choose GroupWise Agents. We will take this opportunity to point out that in the Linux installation routine there are separate “install” and “configure” steps for each agent. Since we’re doing an upgrade, and typically do NOT need to configure the agents, we’ll only look at these as we need them.
NOTE: shows a number of agents installed on this server. If you have a simple, single server system, you may see all of these. If you have multiple servers, you will only see the agents required for the particular server being upgraded. With the changes to WebAccess, not only do you not see the WebAccess Agent listed (as it is now obsolete), but you do not see the WebAccess Application either. You will be required to do a separate installation for WebAccess if it is on the same server.
- You must choose Yes for this option, otherwise the installation will simply close. Choosing Yes starts the update of all agents required on this server. If there are a number of agents, this can take awhile. Once the agents are installed, exit the installation.
- At this point we are not configuring anything with this installation routine. You are upgrading an existing GroupWise system, and thus you already have startup files and startup scripts for your server. If, however, you feel a need to configure your MTA, see “Configuring your agents during installation” below.
You will notice that as you upgrade all of the components on your server, there is no notice of your WebAccess Agent, or even your WebAccess Application.
As we discussed above during the software installation, it is rare that you would need to configure your agents during a GroupWise 2012 upgrade. One reason might be that you wish to reconfigure your Windows services to run the agents from Novell’s new default Windows path.
If you feel the need to create a new a new startup file for your primary domain, you can do so during the installation of the agent software for Windows. A Linux install works slightly differently, and we will discuss that next.
When we ran through the installation routine above, we checked the box in that said to “ Install files but do not configure agents”. This bypasses the creation of the agent startup files and the defining of Windows services or shortcuts. We assume that this is the best option for an upgrade, because you should already have agent startup files and Windows services defined. However, just to be thorough, we will go through the configuration steps for you in case you are having problems, or just wish to redo these options. Let’s go through these steps now.
When you reach above, do not check the option to “Install files but do not configure agents”. Instead now When you reached step 10 above in installing your agents, there was a checkbox that said “Install but do not configure agents”. Make sure that you have not checked this box. When you click Next you have the option to “Install and Configure SNMP for GroupWise Agents” and “Install as Windows services”.
Install and Configure SNMP for GroupWise Agents
If you have SNMP installed on your GroupWise server, you can configure SNMP for the agents on this server.
Install as Windows services
It is highly recommended that you install your GroupWise agents as services on your Windows server. If you do not, you must log into the Windows server and launch the agents on startup. Otherwise the agents cannot launch and users will not be able to access GroupWise until the login takes place.
After you choose the options on this screen you will click next and be presented with the window in Figure 5-7.
While we are looking at this screen, we should explain its usage so that it’s more easily understood the next time you encounter it. There are a few misconceptions about what is done here, and what you need to put in this location, so we will try to clear those up.
First, this screen is a template for creating new agent startup files (for example the primary.mta file), and for configuring your Windows services or Windows shortcuts. Let’s take the example of our groupwise system. Our primary domain is called CNC-PRI. If we want to create a new startup file for the CNC-PRI domain, and configure Windows services and shortcuts, we would click the Add button as shown in Figure 5-8 and enter the information for our domain.
By entering this information, we are instructing the installation routine to create us a startup file called cnc-pri.mta with a /home switch of “w:\domains\cni-pri”, place it in the location of our startup files that we indicated in above, and optionally configure a Windows service for the MTA or create a Windows shortcut.
This screen will validate the location you specify and warn you if you are putting in an invalid location (for example, if you put in m:\domains\cnc-pri and that location does not contain a domain database it will complain). Interestingly enough though, if you “cancel” at this point, it will still put m:\domains\cnc-pri in the setup and will complain that the path is invalid when you click “Next” to continue the setup. You will be required to fix this to point to a valid domain location before you can complete the setup. The installation does not validate the “name” you put here and indeed, you can name things here anything you like. For example, rather than naming my startup file “cnc-pri.mta” as shown above, I could just as easily type “primary” in the name field, and the name of the file would instead be primary.mta. If you put in a name that has more than eight characters (for example Caledonia), the file name will be truncated to eight characters. So, if indeed I were to put “Caledonia” in the name of my domain field, I would have a startup file called “caledoni.mta”. If a “caledoni.mta” file already exists, I will now have a “caledoni.mt1” file in that directory.
If the domain you are configuring is the only domain on this server, and there are no post offices on this server, you are finished adding agents. If you also have a post office on this server, you can click add again, change the type to Post Office and enter the information here for your post office.
To configure the Linux agents, the steps are similar, but you approach the process somewhat differently. In Figure 5-6 you were shown how all of the Linux installation screens have both an “install” and a “configure” option. To configure a Linux agent, click on the Configure Agents option. Click next on the introduction screen and accept the license agreement. You will be presented with a window similar to Figure 5-7 (just a bit more “Linux-like”).
This screen is a template for creating new agent startup files (for example the primary.mta file), and for configuring your Windows services or Windows shortcuts. Let’s take the example of our groupwise system. Our primary domain is called CNC-PRI. If we want to create a new startup file for the CNC-PRI domain, and configure the grpwise script (provided that we checked the option above to “Launch the GroupWise agents on system startup), we would click the Add button as shown in Figure 5-8 and enter the information for our domain.
- Adding a domain for configuration on Linux
By entering this information, we are instructing the installation routine to create us a startup file called cnc-pri.mta with a /home switch of “/grpwise/domains/cni-pri”, place it in the /opt/novell/groupwise/agents/bin directory, and add the information into the gwha.conf file that will be loaded by the grpwise script on startup.
This screen will validate the location you specify and warn you if you are putting in an invalid location (for example, if you put in /groupwise/domains/cnc-pri and that location does not contain a domain database it will complain). The installation does not validate the “name” you put here and indeed, you can name things here anything you like. For example, rather than naming my startup file “cnc-pri.mta” as shown above, I could just as easily type “primary” in the name field, and the name of the file would instead be primary.mta.
If the domain you are configuring is the only domain on this server, and there are no post offices on this server, you are finished adding agents. If you also have a post office on this server, you can click add again, change the type to Post Office and enter the information here for your post office.
At this point, you have installed the software required to take your domain to GroupWise 2012, but your domain has not actually upgraded. This will not happen until you load the new software, under the proper conditions. Earlier in this chapter we saw an option on the installation routine that said “Update an Existing System” and we chose to skip that. Novell’s installation routine has improved quite a bit with GroupWise 2012, but it still expects certain aspects of every GroupWise system to be uniform, and we find that more times than not, GroupWise systems simply are not! This causes inconsistencies in the upgrade process, and it is easier for us (and you) to do these steps manually to ensure that they are done correctly in every single upgrade. This makes just for one or two fewer things to have to troubleshoot if there are problems. In order to continue our upgrade, do the following:
- In your Master SDD, there is a directory called domain. In that directory are four dc files. Copy those dc files into your domain directory (overwrite existing files if asked).
- Next in your Master SDD there is a directory called po. Copy these three dc files into the wpoffice directory under your domain, creating that directory if necessary.
- Now we will launch the MTA so that your domain can upgrade.
Windows: Even if your agents normally launch as services, it is useful to launch the MTA to the GUI console the first time, just to see that everything launches correctly. At the command prompt:
Of course, use the location of your installed agents as well as the name of your own startup file in this command.
Linux: For all Linux installations, the agents are installed to run as daemons. You can launch them under X-Windows to the GUI console during the upgrade just to see that everything loads okay. From a terminal prompt:
/opt/novell/groupwise/agents/bin/gwmta –show @domain.mta &
Your MTA should load up on your server. If you receive any errors during loading, check what the error is and see what can be done to resolve it.
When the GroupWise 2012 MTA for the domain loads, it looks for the dc file that says it is time to upgrade. The dc file is essentially a text file that contains the database schema for creating a GroupWise 2012 database. The gwdom.dc shows the version number at the very top line as #VERSION=1200. This version number at the top of the file verifies that you have the GroupWise 2012 dc file in your domain directory. If this is the primary domain, once the MTA sees the GroupWise 2012 dc file and notes that the domain is the primary domain, the MTA will launch a recovery of the database, effectively converting the domain to GroupWise 2012. If you are quick (on a small domain – not so quick on a larger one), you will be able to see the Admin Status of the Domain change to “Recovering” to show that the domain is being converted (Figure 5-10).
If you are upgrading a secondary domain, assuming the domain database has received information that the primary has been upgraded, it will also launch the recovery mechanism.
Once the status returns to “Normal” you should be able to look at the properties of the domain in ConsoleOne and see that the version is GroupWise 2012. Once the primary domain has been converted to GroupWise 2012 you can continue to upgrade the rest of your system according to your upgrade plan.
To verify that the domain is indeed version 12, you can go into ConsoleOne, right-click on the domain, look at the properties and verify that the version shows as “12”.
Where to from here?
Depending on the size and complexity of your system, and your overall upgrade plan, there are a number of “next steps” that you can take. The main rule of thumb is that you must upgrade ALL components of GroupWise that reside on the same server. Let’s look at a couple of very common configurations that you might be looking at.
Sites with a single GroupWise server have everything in one place. This is acceptable for very small sites, although we always DO recommend that a site have a second domain as a fail safe measure. That said though, today we’re upgrading, not redesigning your system, so we’ll work with what we have. Single servers in very small organizations often house the following components:
- MTA for the Primary Domain
- POA for a single Post Office
- GroupWise Internet Agent
- GroupWise WebAccess Agent
- GroupWise WebAccess Application
If this scenario fits your situation, then you will continue to upgrade each of these components in turn in future chapters. The first order of business is to get the Post Office upgraded. Because the agents installation always installs both the MTA and the POA, you will not need to go through the steps for installing the agent software again on your single GroupWise server! So, jump directly to Chapter 5 on “Upgrading Your Post Office” to continue your upgrade. The rest of the Post Office Chapter will discuss some new options for your Post Office that you might wish to enable. After you have upgraded the Post Office, move on to the chapter on upgrading your GWIA, and then on to upgrading your GroupWise WebAccess. You’ll be finished in no time!
There are as many configurations of multiple server GroupWise systems as there are GroupWise customers it seems! So, we’ll just point out a couple of typical layouts, and send you on to your next step.
Primary Domain Alone
If your primary domain resides on a server all by itself, you are finished with this server. You can stop here, or move on to upgrading any post offices that belong to this primary domain, upgrading a secondary domain server, etc. It’s possible you might wish to go ahead and upgrade your GWIA at this point, but remember that you won’t want to do this if you have users in older GroupWise post offices accessing via IMAP4 or POP3 through your GWIA. See the chapter on Upgrading Your GroupWise Internet Agent.
If your system is small, and you will be upgrading all of your post offices over a weekend (for example), and you can afford to have WebAccess down for some users while you upgrade, you might choose to upgrade your WebAccess now. If you can provide for two separate WebAccess Application servers, you can upgrade your WebAccess and make it the default web server for WebAccess while you continue to upgrade your post offices. See the chapter on Upgrading Your GroupWise WebAccess.
Primary Domain and Post Office on the Same Server
It might be that you have a small system with your primary domain and post office on one server, and another server with a secondary domain for your GWIA and WebAccess. In this situation, you will need to go ahead and upgrade your post office before you are finished with this server. Because the agents installation always installs both the MTA and the POA, you will not need to go through the steps for installing the agent software again on your single GroupWise server! So, jump directly to the section in Chapter 5 on “Upgrading Your Post Office” to continue. The rest of the post office chapter will discuss some new options for your Post Office that you might wish to enable.
Primary Domain and Gateways on the Same Server
You might also have a primary domain and gateways (such as the GWIA and/or WebAccess) on the same server, and other components on other servers. If this is the case, move on to Chapter 6, Upgrading Your GroupWise Internet Agent or Chapter 7, Upgrading Your GroupWise WebAccess.
There are very few things that can go wrong during a domain upgrade. If you find that your domain refuses to show as a GroupWise 2012 domain in ConsoleOne, do a couple of things:
- Verify that you have GroupWise 2012 snapins installed. You can get odd results in the version field of a domain if you are looking at a GroupWise 2012 domain with older GroupWise snapins.
- Double-check that you got the dc files copied into the domain directory. Open the gwdom.dc file with a text editor to verify that it is indeed the GroupWise 2012 file.
- If this is a secondary domain, verify that the secondary domain KNOWS that the primary domain is a GroupWise 2012 domain. You can do this by connecting to the secondary domain in ConsoleOne and looking at the properties of the primary domain. It should show as version 12. If the primary does NOT show as a GroupWise 2012 domain when viewed from the perspective of the secondary domain, you will need to connect to the primary domain and verify that it shows as a GroupWise 2012 domain (look in the properties of the primary). Once you have confirmed that the primary is GroupWise 2012, rebuild the secondary domain database by highlighting the secondary domain and choosing Tools|GroupWise Utilities|System Maintenance and then select “Rebuild Database”.
- Manually set off a recover of the domain database at the MTA under Options|Admin Thread|Perform DB Recovery Now? and indicate Yes.
Once you are ready to continue, just turn to the next chapter in your upgrade plan.