Revision for “Upgrading Your GroupWise Domain” created on December 10, 2013 @ 07:15:02
Upgrading Your GroupWise Domain
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.
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:
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.
<a id="Anchor-34"></a>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 <a>“Updating Your ConsoleOne Snapins”</a> 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.
<a id="Anchor-26"></a>Updating Your ConsoleOne Snapins
<a id="Anchor-26"></a><a id="Anchor-26"></a>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 <a>“Installing your Agent Software”</a> 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.
<a id="Anchor-19"></a>LD_LIBRARY_PATH= and add /usr/ConsoleOne/bin: near the beginning of the line as part of the path.Extending your eDirectory Schema
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:
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)
<a id="Anchor-19"></a>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.
So, let’s get down to it.
<a id="Anchor-27"></a>Installing your Agent Software
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.
<a id="Anchor-27"></a>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 <a>Figure 5-2</a>.
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.
<img alt="install4.tiff" src="file:///Volumes/Data/danita/Documents/publishing/gw2012upg/DomainChpt-web-images/install4_opt.jpeg" width="693" height="518" />
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 <a>Figure 5-5</a>.
<a id="Anchor-12"></a>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.
<a id="Anchor-28"></a><a id="Anchor-37"></a>Configuration of your Agents during installation
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.
<a id="Anchor-37"></a>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 <a>Figure 5-7</a>.
<a id="Anchor-23"></a>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 <a>Figure 5-8</a> and enter the information for our domain.
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 <a>Figure 5-6</a> 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 <a>Figure 5-7</a> (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 <a>Figure 5-8</a> and enter the information for our domain.
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.
<a id="Anchor-29"></a>Performing the Domain Upgrade
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:
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.
<a id="Anchor-29"></a>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 (<a>Figure 5-10</a>).
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.
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:
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:
Once you are ready to continue, just turn to the next chapter in your upgrade plan.