But if 6.14 is working for you, you might ask yourself "why bother?" There are two good reasons to upgrade. First, if you have a problem with your GSA, and open a support ticket, the first thing your support person will say is "upgrade your GSA." You'll still receive support, so if you have a hardware failure Google will of course fix it, but for software problems you'll have to upgrade before Google examines the problem.
The second good reason to upgrade is that newer versions simply are better! Both 7.0 and 7.2 provide better performance and have lots of new and useful features. You can read about Google's 7.0 new features and 7.2 new features. We recommend that you upgrade to the newest version, 7.2, which works very well and has lots of new features not included in 7.0 - read our previous blog post if you're interested.
Preparing for the upgradeTo upgrade your GSA, you'll need an Enterprise Support Portal account to download the patches. If you don't have an account, just fill out this request form and include your GSA's appliance ID. You can find your appliance ID in the GSA admin console. Just click on the About link at the bottom of any page within the admin console. Once you can access the support portal, you can view the 7.0 release notes, the 7.0 upgrade instructions, the 7.2 release notes, the 7.2 upgrade instructions, and the upgrade matrix. (All of the links in the previous sentence require an Enterprise Support Portal login.) It's very important that you read the release notes and the upgrade instructions very carefully! You might also want to read the GSA Upgrade and Migration Handbook (PDF link).
If you'd like to upgrade to 7.2 but are using a screen scraper to interact with the GSA, you will need to rewrite that screen scraper after you upgrade - the admin console has changed significantly! If possible, you should use the admin API instead of a screen scraper, but the admin API doesn't expose all of the functionality of the admin console.
If you're currently running 6.14 and want to upgrade to 7.2, you will need to apply two sets of patches - first to move to 7.0, then to move from 7.0 to 7.2. This can be a tedious process, so you'll probably want to schedule a maintenance outage during the upgrade. Also, you'll be asked whether you want to migrate or rebuild your index when you upgrade from 6.14 to 7.0. With some software upgrades, migrating the index will stop some new features from working, but I'm not aware of any of these issues with GSA 7.0. However, you will need to have at least fifty percent free disk space on your GSA to migrate your index. Generally, we recommend that you rebuild your index, but it can take a significant amount of time to do this. Rebuilding the index requires the GSA recrawl all of your content, and you will have to resubmit all feeds and Policy ACLs. But if you plan to use Document Previews, you'll need to recrawl your content anyway. Migrating your index can take up to twenty-four hours.
Before you migrate your GSA, you should export your configuration, and Policy ACLs if you're using them. If you have multiple GSAs in a mirrored environment, you can upgrade individual GSAs without breaking mirroring, with no downtime to search as long as you direct search traffic to another member of the mirror.
Installing the upgradeTo actually install the upgrade, you'll need to go to Version Manager. This application is available on ports TCP/9941 and TCP/9942 (plaintext and HTTPS respectively). You'll need to use the original admin account to access Version Manager - other administrative accounts cannot access it. Within Version Manager, you'll see a field that accepts an HTTP URL, and a file upload field that will let you upload the file if you've downloaded it to your workstation from the Enterprise Support Portal.
|GSA 7.0 Version Manager|
We recommend that you either put the URL for the patch directly within Version Manager, or download the patch, put it on an internal web server, and put the URL for the patch's location on that web server within Version Manager. The second approach is a little bit more work, but if you have multiple GSAs it will keep you from having to download the patches to each GSA across the public internet. We recommend that you not use the file upload form, as these patches are quite large, and uploading them through your browser may fail because of the file size! If you do download the patches to put on your internal web server or to upload directly, you should validate their checksums using an MD5 tool. If you're using Windows, you can use Microsoft's File Checksum Integrity Verifier command-line tool or many other free tools. The Microsoft tool officially supports older versions of Windows but works fine on any modern version as well.
Finally, you will want to test your new index, whether you migrated or rebuilt it. The new index will be available on port 7800 for testing. The old index will still be available on ports TCP/80 and/or TCP/443, and users will search against the old index until you accept the upgrade. Once you accept the new index, it will replace the old one and users' searches will run against it. You don't want to take too long here - the admin console will only manage the new index, so you won't be able to manage the index that everyone's searching against until you accept the upgrade! If you have problems, you can revert to the previous version, but it's unlikely that you'll have any problems, fortunately.
After you've upgraded: if you've customized your front ends using the Page Layout Helper, you will need to re-save your front ends to use some of the new features - and even some of the old ones! If you've customized your front ends by editing the XSLT directly, you'll need to edit the XSLT to enable Document Previews. The code you'll need to add is in the 7.0 update instructions linked above.
Of course, as always, if you have any questions about the upgrade process, please feel free to reach out to our Google team here at Fig Leaf Software by sending an email to email@example.com.
[Note: cross-posted on the Fig Leaf Software blog]