Checkpoint R65 Upgrade Guide

Upgrade Guide
Version NGX R65
701313 February 13, 2007

© 2003-2007 Check Point Software Technologies Ltd.
All rights reserved. This product and related documentation are protected by copyright and distributed under licensing restricting their use, copying,
distribution, and decompilation. No part of this product or related documentation may be reproduced in any form or by any means without prior written
authorization of Check Point. While every precaution has been taken in the preparation of this book, Check Point assumes no responsibility for errors or
omissions. This publication and features described herein are subject to change without notice.
RESTRICTED RIGHTS LEGEND:
Use, duplication, or disclosure by the government is subject to restrictions as set forth in subparagraph (c)(1)(ii) of the Rights in Technical Data and Computer
Software clause at DFARS 252.227-7013 and FAR 52.227-19.
TRADEMARKS:
©2003-2007 Check Point Software Technologies Ltd. All rights reserved. Check Point, AlertAdvisor, Application Intelligence, Check Point Express, Check Point
Express CI, the Check Point logo, ClusterXL, Confidence Indexing, ConnectControl, Connectra, Connectra Accelerator Card, Cooperative Enforcement,
Cooperative Security Alliance, CoSa, DefenseNet, Dynamic Shielding Architecture, Eventia, Eventia Analyzer, Eventia Reporter, Eventia Suite, FireWall-1,
FireWall-1 GX, FireWall-1 SecureServer, FloodGate-1, Hacker ID, Hybrid Detection Engine, IMsecure, INSPECT, INSPECT XL, Integrity, Integrity Clientless
Security, Integrity SecureClient, InterSpect, IPS-1, IQ Engine, MailSafe, NG, NGX, Open Security Extension, OPSEC, OSFirewall, Policy Lifecycle Management,
Provider-1, Safe@Home, Safe@Office, SecureClient, SecureClient Mobile, SecureKnowledge, SecurePlatform, SecurePlatform Pro, SecuRemote, SecureServer,
SecureUpdate, SecureXL, SecureXL Turbocard, Sentivist, SiteManager-1, SmartCenter, SmartCenter Express, SmartCenter Power, SmartCenter Pro,
SmartCenter UTM, SmartConsole, SmartDashboard, SmartDefense, SmartDefense Advisor, Smarter Security, SmartLSM, SmartMap, SmartPortal,
SmartUpdate, SmartView, SmartView Monitor, SmartView Reporter, SmartView Status, SmartViewTracker, SofaWare, SSL Network Extender, Stateful Clustering,
TrueVector, Turbocard, UAM, UserAuthority, User-to-Address Mapping, VPN-1, VPN-1 Accelerator Card, VPN-1 Edge, VPN-1 Express, VPN-1 Express CI, VPN-
1 Power, VPN-1 Power VSX, VPN-1 Pro, VPN-1 SecureClient, VPN-1 SecuRemote, VPN-1 SecureServer, VPN-1 UTM, VPN-1 UTM Edge, VPN-1 VSX, Web
Intelligence, ZoneAlarm, ZoneAlarm Anti-Spyware, ZoneAlarm Antivirus, ZoneAlarm Internet Security Suite, ZoneAlarm Pro, ZoneAlarm Secure Wireless Router,
Zone Labs, and the Zone Labs logo are trademarks or registered trademarks of Check Point Software Technologies Ltd. or its affiliates. ZoneAlarm is a Check
Point Software Technologies, Inc. Company. All other product names mentioned herein are trademarks or registered trademarks of their respective owners. The
products described in this document are protected by U.S. Patent No. 5,606,668, 5,835,726, 6,496,935, 6,873,988, and 6,850,943 and may be protected by
other U.S. Patents, foreign patents, or pending applications.
For third party notices, see: THIRD PARTY TRADEMARKS AND COPYRIGHTS.
Contents
Preface Who Should Use This Guide.............................................................................. 12

Related Documentation .................................................................................... 14
More Information ............................................................................................. 17
Feedback ........................................................................................................ 17
Chapter 1 Introduction to the Upgrade Process

Documentation ................................................................................................ 20
NGX License Upgrade ...................................................................................... 21
Contract Verification ........................................................................................ 22
Management Plug-in Infrastructure.................................................................... 22
Supported Upgrade Paths and Interoperability .................................................... 23
Upgrading Management Servers ................................................................... 23
Backward Compatibility For Gateways ........................................................... 24
Obtaining Software Installation Packages ........................................................... 25
Terminology .................................................................................................... 26
Upgrade Tools ................................................................................................. 28
Upgrading Successfully .................................................................................... 28
Chapter 2 Upgrading Licenses for Products Prior to NGX

Overview of NGX License Upgrade ..................................................................... 30
Introduction to License Upgrade ....................................................................... 31
Software Subscription Requirements ................................................................. 32
Licensing Terminology...................................................................................... 33
The License_Upgrade Tool................................................................................ 34
Tool Location ............................................................................................. 34
Tool Options............................................................................................... 35
Simulating the License Upgrade........................................................................ 36
Performing the License Upgrade ....................................................................... 37
License Upgrade Methods............................................................................ 37
Deployment with Licenses Managed Centrally Using SmartUpdate................... 39
Deployment with Licenses Managed Locally .................................................. 44
Trial Licenses ............................................................................................. 47
Troubleshooting License Upgrade ................................................................. 48
Contract Verification ........................................................................................ 57
Chapter 3 Service Contract Files

Introduction .................................................................................................... 59
Working with Contract Files .............................................................................. 60
Installing a Contract File on SmartCenter server.................................................. 60
On a Windows Platform ............................................................................... 61
On SecurePlatform, Linux, and Solaris .......................................................... 65
Table of Contents 5
On IPSO .................................................................................................... 68
Installing a Contract File on a Gateway .............................................................. 69
On a Windows Platform ............................................................................... 69
On SecurePlatform, Linux, and Solaris Gateways............................................ 76
On IPSO .................................................................................................... 81
Managing Contracts with SmartUpdate .............................................................. 82
Managing Contracts .................................................................................... 82
Updating Contracts ..................................................................................... 84
Chapter 4 Upgrading a Distributed Deployment

Introduction .................................................................................................... 86
Pre-Upgrade Considerations.............................................................................. 88
License Upgrade to NGX R65 ...................................................................... 88
Web Intelligence License Enforcement.......................................................... 88
Upgrading Products on a SecurePlatform Operating System ............................ 89
VPN-1 UTM Edge Gateways Prior to Version 5.0 ............................................ 89
Upgrading SmartCenter Server .......................................................................... 91
Using the Pre-Upgrade Verification Tool ........................................................ 91
SmartCenter Upgrade on a Windows Platform ................................................ 94
SmartCenter Upgrade on SecurePlatform ...................................................... 95
Gateway Upgrade on UTM-1 ........................................................................ 97
Gateway Upgrade on UTM-1 using the WebUI ............................................... 98
SmartCenter Upgrade on Pre-R54 Versions of SecurePlatform......................... 99
SmartCenter Server Upgrade on a Solaris Platform ....................................... 103
SmartCenter Upgrade on a Linux Platform................................................... 105
SmartCenter Upgrade on an IPSO Platform ................................................. 107
Upgrading VPN-1 Express CI R57 SmartCenter Server.................................. 109
Upgrading a SmartCenter High Availability Deployment ................................ 110
Upgrading the Gateway .................................................................................. 111
Upgrading a Clustered Deployment ............................................................. 111
Upgrading the Gateway Using SmartUpdate ................................................ 112
Gateway Upgrade Process on a Windows Platform ........................................ 116
Gateway Upgrade on SecurePlatform .......................................................... 118
Upgrade on SecurePlatform NG FP2, FP3, or FP3 Edition 2 ......................... 119
Gateway Upgrade on a Solaris Platform ....................................................... 121
Gateway Upgrade on an IPSO Platform ....................................................... 122
Upgrading the VPN-1 Express CI R57 Component to R65............................ 124
Chapter 5 Backup and Revert for VPN-1 Power/UTM

Introduction .................................................................................................. 126
Backing Up Your Current Deployment .............................................................. 127
Restoring a Deployment.................................................................................. 128
SecurePlatform Backup and Restore Commands ............................................... 129
Backup .................................................................................................... 129
Restore .................................................................................................... 131
SecurePlatform Snapshot Image Management .................................................. 132
Snapshot ................................................................................................. 133
Revert...................................................................................................... 134
6
Reverting to Your Previous Deployment ............................................................ 135
Chapter 6 Upgrading a Standalone Deployment

Introduction .................................................................................................. 140
Upgrading versions 4.0 and 4.1 ................................................................. 140
Pre-Upgrade Considerations ............................................................................ 141
License Upgrade to NGX............................................................................ 141
Upgrading Products on a SecurePlatform Operating System .......................... 141
Reverting to Your Previous Software Version ................................................ 142
Using the Pre-Upgrade Verification Tool ...................................................... 142
Standalone VPN-1 Gateway Upgrade on a Windows Platform.............................. 144
Standalone VPN-1 Gateway Upgrade on SecurePlatform .................................... 145
Uninstalling Packages ............................................................................... 147
Standalone Upgrade on UTM-1 ....................................................................... 148
Standalone Upgrade on UTM-1 using the WebUI .............................................. 150
VPN-1 Gateway Upgrade on Pre-R54 SecurePlatform Versions ........................... 151
Uninstalling Packages ............................................................................... 153
Standalone VPN-1 Gateway Upgrade on a Solaris Platform................................. 154
Standalone VPN-1 Gateway Upgrade on an IPSO Platform ................................. 156
Uninstalling Previous Software Packages..................................................... 158
VPN-1 Express CI R57 to NGX R65 on SecurePlatform ..................................... 159
Upgrading a Standalone Deployment to R65 ............................................... 159
Chapter 7 Advanced Upgrade of SmartCenter Servers & Standalone Gateways

Introduction .................................................................................................. 162
Migrate Your Current SmartCenter Configuration and Upgrade............................ 163
Introduction ............................................................................................. 163
Advanced Upgrade on a Windows Platform .................................................. 163
Advanced Upgrade on a Linux Platform....................................................... 164
Advanced Upgrade on SecurePlatform ........................................................ 168
Advanced Upgrade on an IPSO Platform ..................................................... 170
Advanced Upgrade on a Solaris Platform ..................................................... 172
Migration to a New Machine with a Different IP Address ............................... 176
Migrate Your Current VPN-1 Gateway Configuration & Upgrade .......................... 178
Advanced Upgrade on a Windows Platform .................................................. 178
Advanced Upgrade on a Linux Platform....................................................... 180
Advanced Upgrade on SecurePlatform ........................................................ 184
Advanced Upgrade on an IPSO Platform ..................................................... 186
Advanced Upgrade on a Solaris Platform ..................................................... 188
Chapter 8 Upgrading ClusterXL Deployments

License Upgrade to NGX................................................................................. 194
Tools for Gateway Upgrades ............................................................................ 195
Planning a Cluster Upgrade ............................................................................ 196
Permanent Kernel Global Variables ............................................................. 196
Ready State During Cluster Upgrade/Rollback Operations ............................. 197
Upgrading OPSEC Certified Third-Party Cluster Products .............................. 197
Table of Contents 7
Minimal Effort Upgrade on a ClusterXL Cluster ................................................. 198
Zero Downtime Upgrade on a ClusterXL Cluster ................................................ 199
Supported Modes...................................................................................... 199
Full Connectivity Upgrade on a ClusterXL Cluster .............................................. 202
Understanding a Full Connectivity Upgrade ................................................. 202
Supported Modes...................................................................................... 203
Performing a Full Connectivity Upgrade ...................................................... 204
Chapter 9 Upgrading Provider-1

Introduction .................................................................................................. 208
Supported Versions and Platforms .............................................................. 208
Provider-1/SiteManager-1 Terminology........................................................ 209
Before You Begin ...................................................................................... 209
Provider-1/SiteManager-1 Upgrade Tools ......................................................... 210
Pre-Upgrade Verifiers and Fixing Utilities .................................................... 210
Installation Script ..................................................................................... 211
pv1_license_upgrade................................................................................. 213
license_upgrade........................................................................................ 213
cma_migrate ............................................................................................ 214
migrate_assist .......................................................................................... 217
migrate_global_policies ............................................................................. 218
Backup and Restore .................................................................................. 218
Provider-1/SiteManager-1 License Upgrade ...................................................... 220
Overview of NGX License Upgrade .............................................................. 220
Introduction to License Upgrade in Provider-1 Environments......................... 221
Software Subscription Requirements .......................................................... 222
Understanding Provider-1/SiteManager-1 Licenses....................................... 222
Before License Upgrade ............................................................................ 224
Choosing The Right License Upgrade Procedure .......................................... 229
System-Wide License Upgrade, Before Software Upgrade ............................. 231
System-Wide License Upgrade Using the Wrapper........................................ 235
System-Wide License Upgrade, After Software Upgrade................................ 236
License Upgrade for a Single CMA.............................................................. 239
License Upgrade Using the User Center ...................................................... 245
SmartUpdate Considerations for License Upgrade ........................................ 246
Troubleshooting License Upgrade ............................................................... 246
Provider-1/SiteManager-1 Upgrade Practices .................................................... 251
In-Place Upgrade...................................................................................... 251
Replicate and Upgrade .............................................................................. 254
Gradual Upgrade to Another Machine ......................................................... 255
Migrating from a Standalone Installation to CMA ......................................... 257
MDS Post Upgrade Procedures................................................................... 260
Upgrading in a Multi-MDS Environment ........................................................... 261
Pre-Upgrade Verification and Tools ............................................................. 261
Upgrading a Multi-MDS System ................................................................. 262
Restarting CMAs ............................................................................................ 265
Restoring Your Original Environment................................................................ 266
Before the Upgrade................................................................................... 266
8
Restoring Your Original Environment........................................................... 266
Renaming Customers ..................................................................................... 267
Identifying Non-Compliant Customer Names................................................ 267
High Availability Environment .................................................................... 267
Automatic Division of Non-Compliant Names............................................... 267
Resolving Non-Compliance ........................................................................ 268
Advanced Usage ....................................................................................... 269
Changing the MDS IP Address and External Interface........................................ 271
IP Address Change.................................................................................... 271
Interface Change ...................................................................................... 271
SmartDefense in Provider-1 ............................................................................ 272
Chapter 10 Upgrading SmartLSM ROBO Gateways

Planning the ROBO Gateway Upgrade .............................................................. 274
ROBO Gateway Upgrade Package to SmartUpdate Repository............................. 275
License Upgrade for a VPN-1 Power/UTM ROBO Gateway .................................. 276
Using SmartLSM to Attach the Upgraded Licenses....................................... 276
License Upgrade on Multiple ROBO Gateways ............................................. 277
Upgrading a ROBO Gateway Using SmartLSM .................................................. 278
Upgrading a VPN-1 Power/UTM ROBO Gateway ........................................... 278
Upgrading a VPN-1 UTM Edge ROBO Gateway ............................................ 280
Upgrading a VPN-1 Power/UTM ROBO Gateway In Place .............................. 281
Using the Command Line Interface.................................................................. 282
SmartLSM Upgrade Tools .......................................................................... 282
Upgrading a VPN-1 Power/UTM ROBO Gateway Using LSMcli ....................... 284
Upgrading a VPN-1 UTM Edge ROBO Gateway Using LSMcli ........................ 285
Using the LSMcli in Scripts ....................................................................... 286
Chapter 11 Upgrading Eventia

Overview ....................................................................................................... 290
Upgrading Eventia Reporter ............................................................................ 290
For Standalone Deployments...................................................................... 290
For Distributed Deployments ...................................................................... 291
Advanced Eventia Reporter Upgrade ........................................................... 293
Enabling Eventia Analyzer after Upgrading Reporter ..................................... 294
Upgrading Eventia Analyzer ............................................................................ 296
Upgrading Eventia Analyzer to NGX R65 ..................................................... 296
Verifying the Events Database Has Been Moved ........................................... 298
Enabling Eventia Reporter ......................................................................... 298
Index........................................................................................................... 305
Table of Contents 9
10
Preface P
Preface
In This Chapter
Who Should Use This Guide page 12

Related Documentation page 14
More Information page 17
Feedback page 17
11
Who Should Use This Guide

This guide is intended for administrators responsible for maintaining network
security within an enterprise, including policy management and user support.
This guide assumes a basic understanding of
• System administration.
• The underlying operating system.
• Internet protocols (IP, TCP, UDP, and so on).
• Summary of Contents
Chapter Description
Chapter 1, “Introduction to This chapter introduces the upgrade process.
the Upgrade Process”
Chapter 2, “Upgrading This chapter covers licensing issues as regards
Licenses for Products Prior to NGX.
NGX”
Chapter 3, “Service Contract This chapter covers Service Contract Files
Files”
Chapter 4, “Upgrading a This chapter covers upgrading a distributed
Distributed Deployment” deployment; that is, where the enforcement
points and SmartCenter server are installed on
separate machines.
Chapter 5, “Backup and This chapter covers the backup and revert
Revert for VPN-1 process.
Power/UTM”
Chapter 6, “Upgrading a This chapter covers upgrading a standalone
Standalone Deployment” deployment, where the enforcement point and
the SmartCenter server are installed on the same
machine.
Chapter 7, “Advanced This chapter covers Advanced upgrade
Upgrade of SmartCenter procedures for SmartCenter Server and
Servers & Standalone Standalone Gateways.
Gateways”
Chapter 8, “Upgrading This chapter covers upgrade issues relating to
ClusterXL Deployments” ClusterXL.
12
Chapter Description
Chapter 9, “Upgrading This chapter covers upgrade issues regarding
Provider-1” Provider-1.
Chapter 10, “Upgrading This chapter covers upgrading SmartLSM ROBO
SmartLSM ROBO Gateways” Gateways.
Chapter 11, “Upgrading This chapter covers upgrading Eventia Reporter.
Eventia”
Preface 13
Related Documentation
The NGX R65 release includes the following documentation
TABLE P-1 VPN-1 Power documentation suite documentation
Title Description
Internet Security Product Contains an overview of NGX R65 and step by step
Suite Getting Started product installation and upgrade procedures. This
Guide document also provides information about What’s
New, Licenses, Minimum hardware and software
requirements, etc.
Upgrade Guide Explains all available upgrade paths for Check Point
products from VPN-1/FireWall-1 NG forward. This
guide is specifically geared towards upgrading to
NGX R65.
SmartCenter Explains SmartCenter Management solutions. This
Administration Guide guide provides solutions for control over
configuring, managing, and monitoring security
deployments at the perimeter, inside the network, at
all user endpoints.
Firewall and Describes how to control and secure network
SmartDefense access; establish network connectivity; use
Administration Guide SmartDefense to protect against network and
application level attacks; use Web Intelligence to
protect web servers and applications; the integrated
web security capabilities; use Content Vectoring
Protocol (CVP) applications for anti-virus protection,
and URL Filtering (UFP) applications for limiting
access to web sites; secure VoIP traffic.
Virtual Private Networks This guide describes the basic components of a
Administration Guide VPN and provides the background for the
technology that comprises the VPN infrastructure.
14
TABLE P-1 VPN-1 Power documentation suite documentation (continued)
Title Description
Eventia Reporter Explains how to monitor and audit traffic, and
Administration Guide generate detailed or summarized reports in the
format of your choice (list, vertical bar, pie chart
etc.) for all events logged by Check Point VPN-1
Power, SecureClient and SmartDefense.
SecurePlatform™/ Explains how to install and configure
SecurePlatform Pro SecurePlatform. This guide will also teach you how
Administration Guide to manage your SecurePlatform and explains
Dynamic Routing (Unicast and Multicast) protocols.
Provider-1/SiteManager-1 Explains the Provider-1/SiteManager-1 security
Administration Guide management solution. This guide provides details
about a three-tier, multi-policy management
architecture and a host of Network Operating Center
oriented features that automate time-consuming
repetitive tasks common in Network Operating
Center environments.
TABLE P-2 Integrity Server documentation
Title Description
Integrity Advanced Explains how to install, configure, and maintain the
Server Installation Integrity Advanced Server.
Guide
Integrity Advanced Provides screen-by-screen descriptions of user
Server Administrator interface elements, with cross-references to relevant
Console Reference chapters of the Administrator Guide. This document
contains an overview of Administrator Console
navigation, including use of the help system.
Integrity Advanced Explains how to managing administrators and
Server Administrator endpoint security with Integrity Advanced Server.
Guide
Integrity Advanced Provides information about how to integrating your
Server Gateway Virtual Private Network gateway device with Integrity
Integration Guide Advanced Server. This guide also contains information
regarding deploying the unified SecureClient/Integrity
client package.
Preface 15
TABLE P-2 Integrity Server documentation (continued)
Title Description
Integrity Advanced Provides information about client and server
Server System requirements.
Requirements
Integrity Agent for Linux Explains how to install and configure Integrity Agent
Installation and for Linux.
Configuration Guide
Integrity XML Policy Provides the contents of Integrity client XML policy
Reference Guide files.
Integrity Client Explains how to use of command line parameters to
Management Guide control Integrity client installer behavior and
post-installation behavior.
16
More Information
More Information
• For additional technical information about Check Point products, consult Check
Point’s SecureKnowledge at https://secureknowledge.checkpoint.com/.
• View the latest version of this document in the User Center at

http://www.checkpoint.com/support/technical/documents
Feedback
Check Point is engaged in a continuous effort to improve its documentation. Please
help us by sending your comments to:
cp_techpub_feedback@checkpoint.com
Preface 17
Feedback
18
Chapter 1
Introduction to the Upgrade
Process
In This Chapter
Documentation page 20
NGX License Upgrade page 21
Contract Verification page 22
Management Plug-in Infrastructure page 22
Supported Upgrade Paths and Interoperability page 23
Obtaining Software Installation Packages page 25
Terminology page 26
Upgrade Tools page 28
Upgrading Successfully page 28
19
Documentation
Documentation
This guide covers all available upgrade paths for Check Point products from
VPN-1/FireWall-1 NG forward. This guide is specifically geared towards upgrading
to NGX R65. The R65 release focuses on:
• Increased performance
• End point security
• Central management
• Interoperability
Before you begin:
• Make sure that you have the latest version of this document by checking in the
User Center at:
• It is a good idea to have the latest version of the NGX R65 Release Notes
handy. Download them from:
For a new features list, refer to the “NGX R65 What’s New Guide”:
20
NGX License Upgrade
NGX License Upgrade

To upgrade to NGX R65, product versions prior to NGX R60 require a new NGX
license. The new NGX License is available from version NGX R60.
Note - NGX R60 and later products do not require a license upgrade.
The license upgrade procedure can be performed if you have purchased any of the
Enterprise Software Subscription services. License upgrade will fail for products
and accounts for which you do not have software subscription.
You can manage your accounts, licenses, and Enterprise Support Programs
coverage (under Support Programs from the User Center at:
http://usercenter.checkpoint.com
License upgrade is performed by means of an easy to use tool that automatically
upgrades both locally and centrally managed licenses. Using the tool, you can
upgrade all licenses in the entire managed system. License upgrade can also be
performed manually, per license, in the User Center.
The automatic license upgrade tool enables you to:
1. View the status of the currently installed licenses. On a SmartCenter server (or
a CMA, for Provider-1), you can also view the licenses in the SmartUpdate
License Repository.
2. Simulate the license upgrade process.
3. Perform the actual license upgrade process.
During the license upgrade, all eligible licenses are gathered and sent in SSL
encrypted format to the User Center. Upgraded licenses are returned from the User
Center, and automatically installed. The license upgrade process adds only NGX
licenses. Old licenses and non-eligible licenses (e.g., evaluation licenses or
licenses that pertain to IP addresses no longer in use) remain untouched.
Chapter 1 Introduction to the Upgrade Process 21

Contract Verification
When run on a SmartCenter server (or a CMA, for Provider-1), the license upgrade
process also handles licenses in the SmartUpdate License Repository. After the
software upgrade, SmartUpdate is used to attach the new NGX licenses to the
gateways.
The license upgrade process varies according to the type of deployment:
• License upgrade for VPN-1 Pro/Express deployments is described in Chapter 2,
“Upgrading Licenses for Products Prior to NGX” on page 29.
• License upgrade for Provider-1 deployments is described in
“Provider-1/SiteManager-1 License Upgrade” on page 220.
• License upgrade for SmartLSM deployments is described in: “License Upgrade
for a VPN-1 Power/UTM ROBO Gateway” on page 276
For the latest NGX license upgrade information and downloads, check:
http://www.checkpoint.com/downloads/quicklinks/utilities/ngx/license_upgrade.html
Contract verification is now an integral part of the Check Point licensing scheme.
Before upgrading to the latest version, your licensing agreements are verified
through the User Center.
See: “Service Contract Files” on page 59” for more information.
Management Plug-in Infrastructure

NGX R65 introduces an additional infrastructure that enables the use of
management plug-ins. The new plug-ins archetecture introduces the ability to
dynamically add new features and support for new products. When upgrading to
R65, you are given the opportunity to install the Connectra Management NGX
plug-in, which enables the central management of Connectra NGX R62CM
gateways.
22
Supported Upgrade Paths and Interoperability
Supported Upgrade Paths and

Interoperability
Management servers and gateways exist in a wide variety of deployments. Consult
Table 1-1and Table 1-2 to determine which versions of your management server
and gateways can be upgraded to NGX R65.
Upgrading Management Servers

The following management versions can be upgraded to SmartCenter Server NGX
R65:
Table 1-1 Upgradeable management versions
Release Version
NGX VPN-1 Power/UTM NGX R62
VPN-1 Pro/Express NGX R61
VPN-1 Pro/Express NGX R60A
NG VPN-1 Pro NG R55W
VPN-1 Pro/Express NG With Application Intelligence R55
VPN-1 Pro/Express NG R55P
VPN-1 Pro/Express NG FP3
Express CI R57 (Advanced Upgrade only)
GX 2.5
VSX VSX 2.0.1
VSX NG AI
VSX NG AI Release 2

Backward Compatibility For Gateways
Backward Compatibility For Gateways

NGX R65 management supports backward compatibility for the following gateway
versions:
Table 1-2 Supported gateways
Release Version
NG VPN-1 Pro NG R55P
VPN-1 Pro NG R55W
Express CI R57
GX 2.5, 2.5, NGX
VSX VSX 2.0.1
VSX NG AI
VSX NG AI Release 2
VSX NGX
InterSpect NGX
Connectra NGX R62
Note - NGX R65 cannot manage gateway versions NG, NG FP1, or NG FP2
Upgrading versions 4.0 and 4.1

Upgrading from versions prior to NG (4.0-4.1) is not supported. To upgrade
FireWall-1 versions 4.0-4.1, upgrade the installed version to VPN-1 NG R55 (refer
to the NG with Application Intelligence R55 Upgrade Guide). Once the VPN-1 NG
R55 upgrade is complete, perform an upgrade to NGX R65.
24
Obtaining Software Installation Packages
Obtaining Software Installation Packages

NGX R65 software installation packages for Solaris, Windows, Linux and
SecurePlatform are available on the product CD.
NGX R65 software packages for Nokia:
• IPSO 4.1
• IPSO 4.2
are available from:
http://www.checkpoint.com/techsupport/downloads.jsp

Terminology
Terminology
Advanced Upgrade: In order to avoid unnecessary risks, it is possible to migrate the
current configuration to a spare server. The upgrade process is then performed on
the migrated server, leaving the production server intact.
ClusterXL: A software-based load sharing and high availability solution for Check
Point gateway deployments. It distributes traffic between clusters of redundant
gateways so that the computing capacity of multiple machines may be combined to
increase total throughput. In the event that any individual gateway becomes
unreachable, all connections are re-directed to a designated backup without
interruption. Tight integration with Check Point's SmartCenter management and
enforcement point solutions ensures that ClusterXL deployment is a simple task for
VPN-1 administrators.
Distributed Deployment: A distributed deployment is performed when the gateway
and the SmartCenter server are deployed on different machines.
Gateway or Check Point Gateway: A gateway is the VPN-1 engine which actively
enforces the Security Policy of the organization.
In Place Upgrade: In Place upgrades are upgrades performed locally.
LSM: Large Scale Manager. SmartLSM enables enterprises to easily scale, deploy,
and manage VPNs and security for thousands of remote locations.
Management Virtual System (MVS): A default Virtual System created by the VSX
installation process during installation. The MVS:
• Handles provisioning and configuration of Virtual Systems and Virtual Routers.
• Manages Gateway State Synchronization when working with clusters.
Package Repository: This is a SmartUpdate repository on the SmartCenter server
that stores uploaded packages. These packages are then used by SmartUpdate to
perform upgrades of Check Point Gateways.
ROBO Gateways: A Remote Office/Branch Office Gateway.
ROBO Profile: An object that you define to represent properties of multiple ROBO
Gateways. Profile objects are version dependent; therefore, when you plan to
upgrade ROBO Gateways to a new version, first define new Profile objects for your
new version. In general, it is recommended that you keep the Profile objects of the
previous versions until all ROBO Gateways of the previous version are upgraded to
the new version. For further information about defining a ROBO Profile, refer to the
Defining Policies for the Gateway Profile Objects chapter in the CheckPoint R65
SmartLSM Administration Guide.
26
Terminology
Security Policy: A Security Policy is created by the system administrator in order to

regulate the incoming and outgoing flow of communication.
SmartCenter Server: The SmartCenter server is used by the system administrator to
manage the Security Policy. The databases and policies of the organization are
stored on the SmartCenter server, and are downloaded from time to time to the
gateways.
SmartConsole Clients: The SmartConsole Clients are the GUI applications that are
used to manage different aspects of the Security Policy. For example, SmartView
Tracker is a GUI client used to view logs.
SmartDashboard: A GUI client that is used to create Security Policies.
SmartUpdate: A tool that enables you to centrally upgrade and manage Check Point
software and licenses.
Standalone Deployment: A standalone deployment is performed when the Check
Point components that are responsible for the management of the Security Policy
(the SmartCenter server and the gateway) are installed on the same machine.
Virtual Routers: Independent routing domains within a VSX Gateway that function
like physical routers.
Virtual System: A routing and security domain featuring firewall and VPN
capabilities supported by a standard Check Point Gateway. Multiple Virtual Systems
can run concurrently on a single VSX Gateway, isolated from one another by their
use of separate system resources and data storage.
VSX Clustering: The connection of two or more VSX Gateways in such a way that if
one fails, another immediately takes its place. A single VSX Gateway contains
multiple Virtual Routers and Virtual Systems.

Upgrade Tools
Upgrade Tools
Various upgrade tools are provided for migration and compatibility verification of
your current deployment. These tools help you successfully upgrade to NGX R65.
The upgrade tools can be found in the following locations:
• in the NGX R65 $FWDIR/bin/upgrade_tools directory.
• http://www.checkpoint.com/downloads/quicklinks/utilities/ngx/utilities.html
Upgrading Successfully
If you encounter unforeseen obstacles during the upgrade process, contact your
Reseller or our SecureKnowledge support center at:
https://secureknowledge.checkpoint.com
28
Chapter 2
Upgrading Licenses for
Products Prior to NGX
In This Chapter
Overview of NGX License Upgrade page 30

Introduction to License Upgrade page 31
Software Subscription Requirements page 32
Licensing Terminology page 33
The License_Upgrade Tool page 34
Simulating the License Upgrade page 36
Performing the License Upgrade page 37
29
Overview of NGX License Upgrade

To upgrade to NGX, you must first upgrade licenses for all NG products to NGX
licenses. NGX products do not require a license upgrade.
and accounts for which you do not have a software subscription.
You can manage your accounts, licenses, and Enterprise Support Programs
coverage (under Support Programs) from the User Center at:
http://usercenter.checkpoint.com
upgrades both locally and centrally managed licenses. Using the tool you can
upgrade all licenses in the entire managed system.
License upgrade can also be performed manually, per license, in the User Center.
For instructions, refer to the Step by Step guide to the User Center at:
https://usercenter.checkpoint.com/pub/usercenter/faq_us.html.
For instructions on upgrading licenses for Provider-1 and SmartLSM deployments,
refer to:
• “Provider-1/SiteManager-1 License Upgrade” on page 220.
• “License Upgrade for a VPN-1 Power/UTM ROBO Gateway” on page 276.
For the latest NGX license upgrade information and downloads, check:
30
Introduction to License Upgrade
Introduction to License Upgrade

Licenses are required for the SmartCenter server and for the gateways. No license
is required for the SmartConsole management clients.
The license upgrade procedure uses the license_upgrade command line tool,
making it simple to automatically upgrade licenses without having to perform a
manual upgrade through the Check Point User Center at:
https://usercenter.checkpoint.com.
Version 4.1 licenses cannot be upgraded directly to NGX R65. You must first
upgrade the license to NG and then to NGX. License upgrade from version 4.1 to
NG can be done only from the User Center website. It is not supported by the
upgrade tool.
Chapter 2 Upgrading Licenses for Products Prior to NGX 31

Software Subscription Requirements

and accounts for which you do not have a software subscription.
You can see exactly the products and accounts for which you have software
subscriptions by viewing your User Center account at:
In the Accounts page, Enterprise Contract column, and in the Products page,
Subscription and Support column, if the account or product is covered, the
expiration date is shown. If a product is not covered, the entry says Join Now, with
a link to get a quote for purchasing Enterprise Support.
You can purchase an Enterprise Software Subscription for the entire account, in
which case all the products in the account will be covered, or you can purchase
Enterprise Software Subscriptions for individual products.
32
Licensing Terminology
Licensing Terminology
The license upgrade procedures use specialized licensing terminology. It is
important to understand the terminology in order to successfully perform the
license upgrade.
• License Upgrade: The process of upgrading the license version from NG to
NGX.
• Software Upgrade: The process of upgrading Check Point software to version
NGX.
• License Repository: A repository on the SmartCenter server that stores licenses
for Check Point products. It is used by SmartUpdate to install and manage
licenses on Check Point Gateways.
• Wrapper: The wizard application on the Check Point CD that allows you to
install and upgrade Check Point products and upgrade licenses.

The License_Upgrade Tool
The License_Upgrade Tool

The license_upgrade tool enables you to:
• View the status of the currently installed licenses. On a SmartCenter server (or
a CMA, for Provider-1), you can also view the licenses in the SmartUpdate
License Repository.
• Simulate the license upgrade process.
• Perform the actual license upgrade process.
During the license upgrade, all eligible licenses are gathered and sent in SSL
encrypted format to the User Center. Upgraded licenses are returned from the User
Center, and automatically installed. The license upgrade process adds only NGX
licenses. Old licenses and non-eligible licenses (e.g., evaluation licenses or
licenses that pertain to IP addresses no longer in use) remain untouched.
When run on a SmartCenter server (or a CMA, for Provider-1), the license upgrade
tool also handles licenses in the SmartUpdate License Repository. After using the
tool, SmartUpdate is used to attach the new NGX licenses in the License
Repository to the gateways.
Tool Location
The license_upgrade tool can be found in one of the following locations:
• On the NGX product CD at <Specific_platform>\
• In the Check Point Download site at:
http://www.checkpoint.com/downloads/quicklinks/utilities/ngx/license_upgrade.h
tml
• It is also part of the NGX installation, located at $CPDIR/bin.
34
Tool Options
Tool Options
The license_upgrade command line tool has a number of options. To view all of the
options, run:
license_upgrade
Table 2-1 lists the available options:
Table 2-1 license_upgrade tool options
Option Meaning
[L] Displays the licenses installed on your machine.
[S] Sends existing licenses to the User Center website to simulate the
license upgrade to verify that it can be performed. No actual upgrade
is performance and no new licenses are returned.
[U] Sends existing licenses to the User Center website to perform an
upgrade and (by default, in online mode) installs them on the
machine.
[C] Reports whether or not there are licenses on the machine that need to
be upgraded.
[O] Performs license upgrade on a license file that was generated on a
machine with no Internet access to the User Center.
[V] Displays log of last license upgrade or last upgrade simulation.

Simulating the License Upgrade

Before performing the license upgrade, it is recommended to simulate the license
upgrade. This enables you to find and solve potential problems in upgrading
specific licenses. The simulation is an exact replica of the license upgrade process.
It sends existing licenses to the User Center website to verify that the upgrade is
possible, however, no actual upgrade is performed and no new licenses are
returned. If the actual license upgrade fails for some reason, error messages are
displayed and available in a log file, which can be used for troubleshooting.
Note - License upgrade simulation can only be performed on a machine with Internet
connectivity to the Check Point User Center.
To simulate the license upgrade:

1. Copy the license_upgrade tool from <Specific_platform>\ on the NGX product CD,
or from the Check Point Download site at
tml
2. Place the license_upgrade tool on the NG machine.
3. To simulate the license upgrade, run the license_upgrade tool option:
[S] Simulate the license upgrade.
4. Be sure to address all reported issues, so that the actual license upgrade will
succeed for all licenses.
For further assistance:
• Refer to “Troubleshooting License Upgrade” on page 48.
• Refer to SecureKnowledge at https://secureknowledge.checkpoint.com.
36
Performing the License Upgrade
Performing the License Upgrade

In This Section
License Upgrade Methods page 37

Deployment with Licenses Managed Centrally Using SmartUpdate page 39
Deployment with Licenses Managed Locally page 44
Trial Licenses page 47
Troubleshooting License Upgrade page 48
License Upgrade Methods

There are two methods of upgrading licenses to NGX in a VPN-1 Power/UTM
deployment. The right method to use depends on how you manage your licenses:
• Centrally, from the SmartCenter server by means of SmartUpdate, or
• Locally at the Check Point machine.
If you use SmartUpdate to manage your licenses, you can update all the licenses in
your managed system in a single procedure.
For both methods, the upgrade is performed using the license_upgrade tool.
For each method, the actual procedure that is used depends on whether or not the
machine on which the license upgrade is to be run is online or offline. An online
machine is one with Internet connectivity to the Check Point User Center.
It is highly recommended to perform the license upgrade before performing any
software upgrade. This ensures that the products continue to function after the
software upgrade. However, if necessary, the software upgrade can be performed
first.
Note - Version 4.1 licenses cannot be upgraded directly to NGX. You must first upgrade
software and licenses to version NG.

License Upgrade Methods
Table 2-2 lists the Check Point licenses that are upgraded for each license upgrade
method:
Table 2-2
License License Upgrade for Licenses Upgraded
Management
Method
Centrally managed Entire managed System • Local machine licenses
using (Run upgrade tool on (for SmartCenter)
SmartUpdate SmartCenter server)
• License Repository
(for gateways)
Locally managed Gateway • Local machine licenses
SmartCenter server • Local machine licenses
Standalone gateway • Local machine licenses
deployment, containing both (for SmartCenter and
a SmartCenter and a gateway).
gateway(that manages no
remote gateways).
What Next?
Select the right procedure for you:
• “Deployment with Licenses Managed Centrally Using SmartUpdate” on page 39
• “Deployment with Licenses Managed Locally” on page 44
38
Deployment with Licenses Managed Centrally Using SmartUpdate
Deployment with Licenses Managed Centrally

Using SmartUpdate
In This Section
Introduction to Using SmartUpdate page 39

License Upgrade for an Online SmartCenter page 40
License Upgrade for an Offline SmartCenter page 41
Introduction to Using SmartUpdate

In distributed deployments with multiple gateways, SmartUpdate must be used to
distribute licenses from the SmartCenter to the gateways after performing the
license upgrade.
With SmartUpdate, you can manage all licenses for Check Point packages that are
managed by the SmartCenter server, throughout the organization. SmartUpdate
provides a global view of all available and installed licenses, and enables you to
perform operations on Check Point Gateways, such as adding new licenses,
attaching licenses, and deleting expired licenses.
Note - SmartUpdate license management capabilities are free of charge.
After the SmartCenter server is upgraded, SmartUpdate must be used to complete

the License Upgrade process. When SmartUpdate is opened, the upgraded licenses
are imported into the License Repository and are assigned to the appropriate
gateway.
License Statuses in SmartUpdate

SmartUpdate indicates whether a license is Attached or Unattached, and the
license State, as follows:
• An Attached license is associated with the gateway in License Repository, and is
installed on the remote enforcement gateway. In order for the NGX software to
work, a valid NGX license must be attached.
• An Unattached license is not installed on any enforcement gateway.

A license can be in one of the following States:

• Assigned: An NGX license that is associated with the enforcement gateways in
the License Repository, but is not yet installed on the gateways as a
replacement for an existing NG license.
• Obsolete: An NG license for which a replacement NGX license is installed on an
NGX enforcement gateway.
• Requires Upgrade: An NG license that is installed on an NGX machine, and for
which no replacement upgraded license exists.
• No NGX license: An NG license that does not need to be upgraded, or one for
which the license upgrade failed.
License Upgrade for an Online SmartCenter

Use this procedure to upgrade the licenses of the entire distributed deployment to
NGX before the software upgrade, for a deployment with an online SmartCenter
server.
An online SmartCenter server is one with Internet connectivity to the Check Point
User Center Web website:
Note - If the license upgrade is performed before the software upgrade, Check Point
products generate warning messages until all the software on the machine has been
upgraded. Refer to “Error: “License version might be not compatible”” on page 48 for
details.
To upgrade licenses for an online SmartCenter:

1. On the SmartConsole GUI machine, open SmartUpdate, connect to the
SmartCenter server, and select Licenses > Get all licenses. This ensures that the
License Repository is updated.
2. Copy the license_upgrade tool from <Specific_platform>\ on the NGX product CD,
or from the Check Point Download site:
tml
3. Place the license_upgrade tool on the SmartCenter NG machine.
40
4. On the SmartCenter server, perform the license upgrade procedure by running

license_upgrade tool (on SecurePlatform, you must be in expert mode).
Note - License upgrade using the CD Wrapper does not work for SmartCenter machines on
Windows platforms with via-proxy Internet connectivity.
5. Select the [U] option. This does the following:

• Collects all the licenses that exist on the machine.
• Fetches updated licenses from the User Center.
• Installs new licenses on the local machine.
• Upgrades any existing Management High Availability licenses on the
SmartCenter machine,
6. Perform the software upgrade to NGX on both the SmartCenter machine and the
SmartConsole GUI machine.
7. On the SmartConsole GUI machine, open SmartUpdate, and connect to the
SmartCenter server. The updated licenses are displayed as Assigned. Use the
Attach assigned licenses option to attach the assigned licenses to the gateways.
8. Perform the software upgrade to NGX on the gateway machine(s).
9. Delete obsolete licenses from the NGX gateways. On the SmartConsole GUI
machine, open SmartUpdate and connect to the SmartCenter server. In the
License Repository, sort by the State column, select all the Obsolete licenses,
Detach them, and then Delete them.
License Upgrade for an Offline SmartCenter

Use this procedure to upgrade the licenses of the entire distributed deployment
before the software upgrade, where the SmartCenter server is offline.
An offline SmartCenter server is one that does not have Internet connectivity to the
Check Point User Center website:
upgraded. For additional information, refer to “Error: “License version might be not
compatible”” on page 48.

To upgrade a license for an offline SmartCenter:

1. On the SmartConsole GUI machine, open SmartUpdate and connect to the
SmartCenter server. Select Licenses > Get all licenses. This ensures that the
License Repository is updated.
2. Copy the license_upgrade tool from <Specific_platform>\ on the NGX CD, or from
the Check Point Download site at:
3. Place the license_upgrade tool on the offline SmartCenter server NG.
4. On the offline SmartCenter, run license_upgrade. (On SecurePlatform, you
must be in expert mode.)
5. From the menu:
• Press [U] to run the upgrade operation.
• Press [N] to specify that you do not have an Internet connection.
• Press [E] to copy the licenses to a license file.
• Enter the name of the license package file to be created.
• Press [Q] to quit the license upgrade tool.
6. Copy the license package file from the offline SmartCenter to any online
machine. The online machine does not need to be a Check Point-installed
machine.
7. Copy the license_upgrade tool to the online machine from the location
specified in step 2.
8. Run the license_upgrade tool on the online machine:
• Press [O] to run the upgrade operation in offline mode.
• Enter the name of the exported file with the location of the package file
that is the result of step 5.
• Enter the name of the file to be created with all the upgraded licenses
(output file name).
• Press [Y] when asked “Is this machine connected to the Internet?”.
• Press [Y] if you are connected to the Internet via a proxy and supply the
proxy IP port and username password, or press [N] if you are not connected
via proxy and continue with the upgrade.
• Enter the username and password of your User Center Account.
New licenses are fetched from the User Center and placed in a cache file.
42
9. Copy the cache file (with the new licenses) to the offline SmartCenter. Copy the
file to the same directory as the license upgrade tool.
10. Run the license_upgrade tool on the offline SmartCenter:
• Press [N] when asked “Is this machine connected to the Internet?”.
• Press [I] to import the output file (with the upgraded licenses) to the
SmartCenter.
• Enter the output file name with all the upgraded licenses.
11. To check if currently installed licenses have been upgraded, return to the main
menu and press [C].
This displays the number of upgraded licenses on the machine and whether the
original NG licenses have a replacement NGX license.
12. Perform the software upgrade to NGX on both the SmartCenter machine and the
SmartConsole GUI machine.
13. On the SmartConsole GUI machine, open SmartUpdate and connect to the
SmartCenter server. The updated licenses are displayed as Assigned. Use the
Attach assigned licenses option to attach the assigned licenses to the gateways.
15. Delete obsolete licenses from NGX gateways. At the SmartConsole GUI
machine, open SmartUpdate and connect to the SmartCenter server. In the
License Repository, sort by the State column, select all the Obsolete licenses,
Detach them, and then Delete them.
Note - SmartUpdate indicates whether a license is Attached or Unattached, and the license
state.
For details, refer to “License Statuses in SmartUpdate” on page 39.

Deployment with Licenses Managed Locally

In This Section
License Upgrade for an Online Machine page 44

License Upgrade for an Offline Machine page 45
License Upgrade for an Online Machine

Use this procedure to upgrade the licenses on a single online NG machine before
the software upgrade.
An online machine is one with Internet connectivity to the Check Point User Center
website https://usercenter.checkpoint.com.
The single machine can be a SmartCenter server, a gateway, or a standalone
gateway containing a SmartCenter server and a gateway.
upgraded. For additional information, refer to “Error: “License version might be not
compatible”” on page 48.
To upgrade licenses for an online machine:

tml
2. Place the license_upgrade tool on the online NG machine.
3. On the online machine, perform the license upgrade procedure by running the
license_upgrade tool (on SecurePlatform, you must be in expert mode).
Note - License upgrade using the CD Wrapper does not work for SmartCenter machines on
Windows platforms with via-proxy Internet connectivity.
4. Press [U] to run the upgrade operation. This does the following:
• Collects all the licenses that exist on the machine.
• Installs new licenses on the local machine.
44
• On a SmartCenter machine, if Management High Availability licenses exist,

they are upgraded.
5. Perform the software upgrade to NGX.
6. Find out which license on the machine are obsolete. Run
cplic print
7. Delete the obsolete licenses from the machine. For each obsolete license, run
cplic -del <license_signature>
License Upgrade for an Offline Machine

Use this procedure to upgrade the licenses for a single offline machine before the
software upgrade.
An offline machine is one that does not have Internet connectivity to the Check
Point User Center website https://usercenter.checkpoint.com.
The single machine can be a:
• SmartCenter Server
• Gateway
• Standalone Gateway containing a SmartCenter Server and a gateway.
products will generate warning messages until all the software on the machine has been
upgraded. For details, refer to “Error: “License version might be not compatible”” on
page 48.
To upgrade licenses for an offline machine:

tml
2. Place the license_upgrade tool on the offline machine.
3. On the offline machine, run license_upgrade. (On SecurePlatform, you must be
in expert mode.)
4. From the menu:
• Press [N] to specify that you do not have an Internet connection.
• Press [E] to copy the licenses to a license file.

• Enter the name of the license package file to be created.

• Press [Q] to quit the license upgrade tool.
5. Copy the license package file from the offline machine to any online machine.
The online machine does not need to be a Check Point-installed machine.
6. Copy the license_upgrade tool to the online machine. The tool is located at the
location specified in step 2.
7. Run the license_upgrade tool on the online machine:
• Press [O] to run the upgrade operation in offline mode.
• Enter the name of the exported file with the location of the package file
that is the result of step 5.
• Enter the name of the file to be created with all the upgraded licenses
(output file name).
• Press [Y] when asked “Is this machine connected to the Internet?”.
• Press [Y] if you are connected to the Internet via a proxy and supply the
proxy IP port and username password.
• Press [N] if you are not connected via proxy, and continue with the
upgrade.
• Enter the user and password of your User Center Account.
The new licenses are fetched from the User Center and placed in a cache file.
8. Copy the cache file (with the new licenses) to the offline machine. Copy the file
to the same directory as the license_upgrade tool.
9. Run the license_upgrade tool on the offline machine:
• Press [N] when asked “Is this machine connected to the Internet?”.
• Press [I] to import the output file (with the upgraded licenses) back to the
SmartCenter.
• Enter the output file name with all the upgraded licenses.
10. To check if currently installed licenses have been upgraded, return to the main
menu and press [C].
This shows the number of upgraded licenses on the machine and whether the
original NG licenses have a replacement NGX license.
11. Perform the software upgrade to NGX on the offline machine.
46
Trial Licenses
12. To find out which licenses on the machine are obsolete, run cplic print.
13. Delete the obsolete licenses from the machine. For each obsolete license, run
cplic -del <license_signature>
Trial Licenses
Every Check Point product comes with a Trial License that allows unrestricted use
of the product for 15 days.
After the software upgrade, the Trial License continues to work for the remaining
days of the license. There is no need to upgrade the Trial License.
The Trial License does not work if you migrate your current SmartCenter
configuration to a new machine and then upgrade the new machine to NGX.

Troubleshooting License Upgrade

License upgrade is usually a smooth and easy process, however, there are a few
predictable cases where you may encounter problems. Use this section to solve
those license upgrade problems.
In This Section
Error: “License version might be not compatible” page 48

Evaluation Licenses Created in the User Center page 49
Evaluation Licenses Not Created in the User Center page 49
Licenses of Products That Are Not Supported in NGX page 50
License Enforcement on Gateway is Now on SmartCenter Server page 51
License Not in Any of Your User Center Accounts page 52
User Does Not Have Permissions on User Center Account page 52
SKU Requires Two Licenses in NG and One License in NGX page 53
SmartDefense Licenses page 54
License Upgrade Partially Succeeds page 54
Upgraded Licenses Do Not Appear in the License Repository page 55
Cannot Connect to the User Center page 55
Error: “License version might be not compatible”
Note - This error is also covered in SecureKnowledge solution sk30478.
Symptoms
• Error: Warning: Can't find .... in cp.macro. License version might be
not compatible
• Error occurs with commands such as cplic print, cpstop, cpstart, and fw
ver.
48
Cause
This error occurs in any situation where a licensed version is not compatible with
the version installed on a machine, for example, an NGX license on an NG
machine. This error typically occurs when the license on the target machine is
upgraded to NGX before the software is upgraded from a previous NG version to
NGX.
If the license upgrade is performed before the software upgrade, Check Point
upgraded. Refer to “License Upgrade Methods” on page 37 to determine the
upgrade path that best applies to your current configuration.
Resolution
Upgrade the software to version NGX. Errors should not appear after the upgrade.
Note that these errors do not affect the functionality of the version NG software.
Evaluation Licenses Created in the User Center

Symptoms
User Center message (Error code: 106):
No license upgrade is available for evaluation product.
Cause
Evaluation licenses are not entitled to a license upgrade.
Resolution
Evaluation licenses cannot be upgraded. If you do not need the evaluation license,
delete it. If you do need it, contact Account Services at US +1 817 606 6600
(option 7) or e-mail AccountServices@ts.checkpoint.com.
Evaluation Licenses Not Created in the User Center

Symptoms
User Center message (Error code: 151):
Your license contains a Certificate Key (CK) which is not found in
User Center.

Cause
The evaluation licenses do not exist in the User Center. Evaluation licenses are not
entitled to a license upgrade.
An evaluation license can be identified by examining the license string. Evaluation
licenses may contain one of the following strings in the Features description:
CK-CP
or
CK-CHECK-POINT-INTERNAL-USE-ONLY
Resolution
Evaluation licenses cannot be upgraded. If you do not need the evaluation license,
delete it. If you do need it, contact Account Services at US +1 817 606 6600
(option 7) or e-mail AccountServices@ts.checkpoint.com.
Licenses of Products That Are Not Supported in NGX

Symptoms
User Center Message (Error code: 154):
This product is not upgradeable to NGX version and therefore a
license upgrade is not needed. The product continues to be
supported in its NG Release
Cause
VPN-1 Net and VPN-1 SmallOffice are not supported in NGX; therefore, the User
Center generates an error message if an attempt is made to upgrade the license for
these products.
The affected SKUs are:
• VPN-1 Net Family SKUs: CPVP-VNT and LS-CPVP-VNT families
• SmallOffice family SKUs: CPVP-VSO and LS- CPVP-VSO families
Resolution
Contact Account Services at US +1 817 606 6600 (option 7) or e-mail
AccountServices@ts.checkpoint.com.
50
License Enforcement on Gateway is Now on

SmartCenter Server
Symptoms
The license enforcement of NG gateway is now performed by the NGX
management SmartCenter server. Perform Change IP operation in User
Center and install the NGX license on the SmartCenter server.
Cause
The enforcement of NG gateway features is now performed by the NGX Smartcenter
server. For example, the licensing model of QOS (formerly FloodGate-1) for VPN-1
UTM was altered in NGX, and VPN-1 UTM NGX gateways with QoS require an
appropriate license to be installed on the SmartCenter server. In this scenario, the
license upgrade is not handled automatically. The affected SKU family for QoS is:
CPXP-QOS.
Resolution
If you have an NG Express gateway with a QoS (FloodGate-1) license, or in any
other instance where this problem occurs, proceed as follows:
1. Perform a license upgrade at the User Center website to generate a new
license.
2. Install the new, upgraded license on the NGX management machine (even if
you do not upgrade the gateway).
3. Upgrade the gateway.
4. Delete the unneeded license from the gateway in one of two ways:
• From the command line, run:
cplic del <license_signature>
• Using SmartUpdate, select the unneeded license, Detach it, and then Delete
it.

License Not in Any of Your User Center Accounts

Symptoms
User Center Message (Error Code 17):
This license is not in any of your accounts. Run the license
upgrade again with the username that owns this license in the User
Center.
Cause
This specific license does not exist in any of the accounts that belong to this user.
Resolution
Run the tool again with the appropriate username.
Note that each time you run the tool with a different username, upgraded licenses
from the User Center are added to a cache file located on your machine. This file
contains the successfully upgraded licenses from previous runs.
If the partially successful license upgrade was performed via the Wrapper, then,
after the Wrapper has finished, run the license upgrade again via the command
line, using the appropriate username.
User Does Not Have Permissions on User Center

Account
Symptoms
User Center Message (Error Code 19):
This license is in your account but you are not authorized to
upgrade licenses in this account because you have just view-only
permissions. Run license upgrade again with a username that is
authorized to change the license in the User Center.
Cause
This user is not authorized to change this license in the User Center.
Resolution
Run the tool again with the appropriate username.
52
Note that each time you run the tool with a different username, upgraded licenses
from the User Center are added to a cache file located on your machine. This file
contains the successfully upgraded licenses from previous runs.
If the partially successful license upgrade was performed via the Wrapper, then,
after the Wrapper has finished, run the license upgrade again via the command
line, using the appropriate username.
SKU Requires Two Licenses in NG and One License in

NGX
Symptoms
This license is no longer needed in the version you are upgrading
to. It can be safely removed from the machine after the software
upgrade.
Cause
The NG version of SecureClient requires two licenses: one license for the gateway
and one for the SmartCenter server. In NGX, only the management license is
needed. The gateway license (CPVP-VPS-1-NG) is no longer needed because it is
incorporated in the VPN-1 license. The relevant SKU families are:
• CPVP-VSC
• LS- CPVP-VSC
• CPVP-VMC
• LS-CPVP-VMC
• CPVP-VSC-100-DES-NG
Resolution
After the software upgrade, delete the unneeded gateway license from the machine.
Do this in one of two ways:
• From the command line, run:
cplic del <license_signature>
• Using SmartUpdate, select the unneeded license, Detach it, and then Delete it.

SmartDefense Licenses
Symptoms
SmartDefense License is not needed on the gateway.
Cause
In NGX, enforcement of SmartDefense licenses is handled by the User Center. The
affected SKU families are SU-SMRD and SU-SMDF.
Resolution
Delete the unneeded license from the machine.
License Upgrade Partially Succeeds

Symptoms
The license upgrade fails for some of the licenses but succeeds for others.
Cause
The license upgrade may fail for some licenses and succeed for others. A license
may fail to upgrade for a number of reasons. For example, you may not have an
Enterprise Subscription contract for the licensed product. For additional reasons
why the license upgrade may fail, refer to “Troubleshooting License Upgrade” on
page 48.
Resolution
After solving some or all of the licensing problems referred to in the error log, run
the license_upgrade tool. This upgrades the licenses for which the problem has
been solved.
The tool can be found in one of the following locations:
• On the CD at <Specific_platform>
• In the Check Point Download site at:
tml
54
When the license_upgrade tool is run several times, the results are cumulative.
This means that if the upgrade of some licenses failed and the tool is run again:
• Licenses that have been successfully upgraded to NGX remain unchanged.
• Licenses that failed to upgrade in a previous run and were now successfully
upgraded are added to the machine.
For example, if the license upgrade failed because there was no Enterprise
Software Subscription contract for the licensed product, purchase Software
Subscription for those products and then run the tool again to fetch the new
licenses from the User Center website.
Upgraded Licenses Do Not Appear in the License

Repository
Symptoms
The upgraded license does not appear in the SmartUpdate License Repository.
However, the license_upgrade tool log indicates that the license upgrade
succeeded.
The license upgrade was performed on the NGX machine, after the software
upgrade to NGX.
Cause
The file with the upgraded licenses that was fetched from the User Center cannot
be imported into the SmartUpdate License Repository while SmartUpdate is open.
Resolution
Close any SmartUpdate GUI client that is running, and run
license_upgrade import -r
The upgraded licenses are imported into the SmartUpdate License Repository.
Cannot Connect to the User Center

Symptom
Failed to connect to the User Center.

Cause
Access to port HTTPS-443 is not allowed through the firewall. Access to the User
Center requires this port to be open.
Resolution
Open port HTTPS-443 in the firewall.
For example, in a deployment with one main firewalled gateway, and other gateways
for branch offices within the organization, open HTTPS-443 in the main gateway
for all the branch office gateways behind it.
56
Contract verification is an integral part of the Check Point Licensing scheme. See
“Service Contract Files” on page 59 for more information.

58
Chapter 3
Service Contract Files
In This Chapter
Introduction page 59
Working with Contract Files page 60
Installing a Contract File on SmartCenter server page 60
Installing a Contract File on a Gateway page 69
Managing Contracts with SmartUpdate page 82
Introduction
Before upgrading a gateway or SmartCenter server to NGX R65, you need to have a
valid support contract that includes software upgrade and major releases registered
to your Check Point User Center account. The contract file is stored on SmartCenter
Server and downloaded to VPN-1 Power/UTM gateways during the upgrade process.
By verifying your status with the User Center, the contract file enables you to easily
remain compliant with current Check Point licensing standards.
59
Working with Contract Files
Working with Contract Files

As in all upgrade procedures, first upgrade your SmartCenter server or
Provider-1/SiteManager-1 before upgrading the gateways. Once the management
has been successfully upgraded and contains a contract file, the contract file is
transferred to a gateway when the gateway is upgraded (the contract file is retrieved
from the management).
Note - Multiple user accounts at the User Center are supported.
Installing a Contract File on SmartCenter

server
The following section covers obtaining and installing the contract file for
SmartCenter server:
• On a Windows Platform
• On SecurePlatform, Linux and Solaris
• On IPSO
60
On a Windows Platform
When upgrading SmartCenter server, the upgrade process checks to see whether a
contract file is already present on the server. If not, the main options for obtaining
a contract are displayed:
You can:
• Download a contracts file from the User Center
If you have Internet access and a valid user account, you may download a
contract file directly from the User Center. The contract file obtained
through the user center contains contract information for all of your
accounts at the User Center. The contract file obtained through the user
center conforms with the terms of your licensing agreements.
i. Click Next.
Chapter 3 Service Contract Files 61

ii. Enter your User Account credentials.
If the connection succeeds but the downloaded contract file does not
cover the SmartCenter server, a message informs you that the
SmartCenter server is not eligible for upgrade.
However, the absence of a valid contract file will not prevent the
upgrade from taking place. Once the upgrade is complete, contact your
local support provider to obtain a valid contract.
• Import a local contract file
If the server being upgraded does not have Internet access, then:
i. On a machine with Internet access, browse to:
https://usercenter.checkpoint.com/usercenter/index.jsp
ii. Log in to the User Center
iii. Browse to Support.
62
iv. On the Downloads page, in the Service Contract File Download section,
click Download Now:
v. Transfer the downloaded file to the management server. After selecting

Import a local contracts file, you can then browse to the location where
you stored the contract file:

If the contract file does not cover the SmartCenter server, a message
informs you that the SmartCenter server is not eligible for upgrade.
However, the absence of a valid contract file will not prevent the
upgrade from taking place. Once the upgrade is complete, contact your
local support provider to obtain a valid contract.
vi. Click Next to continue with the upgrade process
• Continue without contract information
Select this option if you intend to obtain and install a valid contract file at
a later date. Note that at this point your gateway is not strictly eligible for
an upgrade; you may be in violation of your Check Point Licensing
Agreement, as shown in the final message of upgrade process:
For more information, see: “Managing Contracts with SmartUpdate” on

page 82.
64
On SecurePlatform, Linux, and Solaris

When upgrading SmartCenter server, the upgrade process checks to see whether a
contract file is already present on the server. If not, the main options for obtaining
a contract are displayed:
You can:
If you have Internet access and a valid user account, then download a
through the user center conforms with the terms of your licensing
agreements. If you choose to download contract information from the User
Center, you are prompted to enter your:
• User name
• Password

• Proxy server address (if applicable):
However, the absence of a valid contract file will not prevent the upgrade
from taking place. Download a valid contract at a later date using
SmartUpdate (see: “Managing Contracts with SmartUpdate” on page 82 for
more information on using SmartUpdate).
iii. Browse to Support
66
click Download Now:
Transfer the downloaded file to the management server. After selecting

Import a local contracts file, enter the full path to the location where you
stored the file:
However, the absence of a valid contract file will not prevent the upgrade

On IPSO
from taking place. Download a valid contract at a later date using

SmartUpdate (see: “Managing Contracts with SmartUpdate” on page 82 for
more information on using SmartUpdate).
Agreement, as shown in the final message of the upgrade process:

page 82.
On IPSO
Contract verification on IPSO is not interactive. When upgrading an IPSO
SmartCenter server to NGX R65, the upgrade process will check to see if there is a
valid contract already present on the SmartCenter server. If a contract is not
present, the upgrade process proceeds as normal. After successfully upgrading the
gateway, the following message is displayed:
The upgrade process requires a valid contract file in order to
verify that your gateway complies with Check Point licensing
agreements. While the absence of a contract file does not prevent
this upgrade, it is recommended that you obtain a contract file via
SmartUpdate (Licenses & Contracts menu -> Update Contracts).
For further details see:
http://www.checkpoint.com/ngx/upgrade/contract/
At the earliest opportunity, obtain a valid contract file from the Check Point user
center.
68
Installing a Contract File on a Gateway
Installing a Contract File on a Gateway

The following section covers obtaining and installing the contract file for gateways:
• On a Windows Platform
• On SecurePlatform, Linux and Solaris
• On IPSO
After accepting the End User License Agreement (EULA), the following message is
displayed:

After clicking Next, the upgrade process checks to see if a valid contract file is
installed on the gateway. If no contract file exists, the upgrade process attempts to
retrieve a contract file from the SmartCenter Server that manages the gateway. If a
contract file cannot be retrieved from SmartCenter server, the main options for
obtaining a contract file for the gateway are displayed:
You can:
agreements.
70
i. Enter your User Account credentials.
If the connection succeeds but the downloaded contract file does not
cover the gateway, the following message appears:
However, this will not prevent the upgrade from taking place.

If a valid contract is available, the following message is displayed:
ii. After clicking Next, the upgrade process continues.

72
click Download Now:
v. Transfer the downloaded file to the gateway. After selecting Import a

local contracts file, you can then browse to the location where you stored
the file:
vi. Click Next.

If the local contract file does not cover the gateway, the following
message is displayed:
However, this will not prevent the upgrade from taking place. If the
contract file covers the gateway, the following message is displayed:
vii. Click Next to continue with the upgrade process
74

Agreement, as shown in the final message of upgrade process:

page 82.

On SecurePlatform, Linux, and Solaris Gateways

After accepting the End User License Agreement (EULA), the following message is
displayed:
The upgrade process searches for a valid contract on the gateway. If a valid
contract is not located, the upgrade process attempts to retrieve the latest contract
file from the SmartCenter server that manages the gateway. If a valid contract file
is not located on the SmartCenter server, the main options for obtaining a contract
file for the gateway are displayed:
76
You can:
agreements. If you choose to download contract information from the User
Center, you are prompted to enter your:
• User name
• Password
• Proxy server address (if applicable):

If, according to information gathered from your User Center account, your
gateway is not eligible for upgrade, the following message is displayed:
You may still upgrade the gateway but are advised to download a valid contract
at a later date using SmartUpdate (see: “Managing Contracts with
SmartUpdate” on page 82 for more information on using SmartUpdate).
78

click Download Now:

Transfer the downloaded file to the gateway. After selecting Import a

local contracts file, enter the full path to the location where you stored
the file:
If the contract file does not cover the gateway, a message informs you
that the gateway is not eligible for upgrade. However, the absence of a
valid contract file will not prevent the upgrade from taking place. Once
the upgrade is complete, contact your local support provider to obtain a
valid contract.
Agreement, as shown in the final message of the upgrade process:
80
On IPSO

page 82.
On IPSO
Contract verification on IPSO is not interactive. When upgrading an IPSO gateway
to NGX R65, the upgrade process will check to see if there is a valid contract
available on the SmartCenter server that manages the gateway. If none is available,
the upgrade process proceeds. After successfully upgrading the gateway, the
following message is displayed:
The upgrade process requires a valid contract file in order to
verify that your gateway complies with Check Point licensing
agreements. While the absence of a contract file does not prevent
this upgrade, it is recommended that you obtain a contract file via
SmartUpdate (Licenses & Contracts menu -> Update Contracts).
For further details see:
http://www.checkpoint.com/ngx/upgrade/contract/
At the earliest opportunity, obtain a valid contract file from the Check Point user
center.

Managing Contracts with SmartUpdate
Managing Contracts with SmartUpdate

Once you have successfully upgraded SmartCenter server, you can use
SmartUpdate to display and manage your contracts. From the License management
window, it is possible to see whether a particular license is associated with one or
more contracts:
Managing Contracts
The license Repository window in SmartUpdate displays contracts as well as regular
licenses:
Clicking on a specific license shows the properties of the license:
82
Managing Contracts
Clicking Show Contracts displays the contracts associated with this license:
Selecting a specific contract, then Properties displays the contract’s properties,

such as contract ID and expiration date as well as which licenses are covered by
the contract:

Updating Contracts
Updating Contracts
Licenses & Contracts on the File menu has enhanced functionality for handling
contracts:
• Licenses & Contracts > Update Contracts
This option installs contract information on SmartCenter server. Each time you
purchase a new contract, use this option to make sure the new contract is
displayed in the license repository:
• Licenses & Contracts > Get all Licenses

a. Collects licenses of all gateways managed by the SmartCenter server
b. Updates the contract file on the server if the file on the gateway is newer
84
Chapter 4
Upgrading a Distributed
Deployment
In This Chapter
Upgrading SmartCenter Server page 91
Upgrading the Gateway page 111
85
Introduction
Introduction
This chapter describes the process of upgrading a distributed deployment to NGX
R65. A distributed deployment consists of at least one SmartCenter server and one
or more gateways. The SmartCenter server and gateway do not reside on the same
physical machine. Since backward compatibility is supported, a SmartCenter server
that has been upgraded to NGX R65 can enforce and manage gateways from
previous versions. In some cases, however, new features may not be available on
earlier versions of the gateway.
The NGX R65 SmartCenter server can manage the following gateways:
Release Version
VPN-1 Pro NG R55W
Express CI R57
GX 2.5, 2.5, NGX
VSX VSX 2.0.1
VSX NG AI
VSX NG AI Release 2
VSX NGX
InterSpect NGX
Connectra NGX R62
NGX R65 is not backwardly compatible with:

• VPN-1 Pro/Express NG
• VPN-1 Pro/Express NG FP1
• VPN-1 Pro/Express NG FP2
86
Introduction

Chapter 4 Upgrading a Distributed Deployment 87

Pre-Upgrade Considerations
In This Section
License Upgrade to NGX R65 page 88

Web Intelligence License Enforcement page 88
Upgrading Products on a SecurePlatform Operating System page 89
VPN-1 UTM Edge Gateways Prior to Version 5.0 page 89
License Upgrade to NGX R65

Before upgrading the software, it is highly recommended to upgrade licenses for all
NG products. NGX R65 with licenses from previous versions will not function. If
necessary, the license upgrade can be performed after the software upgrade. For
details, refer to Upgrading Licenses for Products Prior to NGX page 29 .
Use of the Pre-Upgrade verification tool can reduce the risk of incompatibility with
the deployment to NGX R65. It is used to test the current VPN-1 gateway prior to
upgrading to NGX R65. The Pre-Upgrade verification tool produces a detailed
report indicating the appropriate actions that should be taken before performing an
upgrade to NGX R65 (refer to “Using the Pre-Upgrade Verification Tool” on
page 91).
Web Intelligence License Enforcement

A gateway or gateway cluster requires a Web Intelligence license if it enforces one
or more of the following protections:
• Malicious Code Protector
• LDAP Injection
• SQL Injection
• Command Injection
• Directory Listing
• Error Concealment
• ASCII Only Request
• Header Rejection
• HTTP Methods
88
The actual license required depends on the number of Web servers protected by the
gateway or gateway cluster.
For NGX R60 and later versions, if the correct license is not installed, it is not
possible to install a Policy on any gateway. When upgrading, be aware of this
change of behavior. For additional information, refer to the Web Intelligence chapter
in the CheckPoint R65 Firewall And SmartDefense Administration Guide.
Upgrading Products on a SecurePlatform Operating

System
Upgrading to NGX R65 on a SecurePlatform operating system for versions prior to
NGX R60 requires upgrading both the operating system and the installed software
products.
To upgrade products installed on SecurePlatform, refer to the “SmartCenter
Upgrade on SecurePlatform” on page 95.
The process upgrades all of the installed components (Operating System and
software packages) in a single upgrade process. No further upgrades are required.
VPN-1 UTM Edge Gateways Prior to Version 5.0

Before you upgrade your deployment to NGX R65, it is recommended that VPN-1
UTM Edge gateways should be at least version 5.0.
By default, SmartCenter NGX R65 is compatible with VPN-1 UTM Edge gateways
5.0 and above.
Enabling Policy Enforcement on Pre-version 5.0 VPN-1

UTM Edge Gateways
In order to control and enforce policies on earlier versions of the VPN-1 UTM Edge
gateways, you must perform the following a workaround on the upgraded
SmartCenter server.
Once the workaround is complete, new NGX R65 features may not be available to
VPN-1 UTM Edge gateways prior to 5.0.
To perform the workaround:
1. Edit the /var/opt/CPEdgecmp/conf/SofawareLoader.ini file for Solaris, or the
%FWDIR%\FW1_EDGE_BC\conf\SofawareLoader.ini file for Windows.

2. In the [Server] section, add the following:

TopologyOldFormat=1
3. Save and close the file.
The change takes effect without running the commands cpstop and cpstart.
90
Upgrading SmartCenter Server

This section describes how to upgrade a SmartCenter server to NGX R65.
Upgrades can be performed incrementally so that you do not have to upgrade the
SmartCenter server and all of the gateways at the same time. Once the SmartCenter
server is upgraded, you can still manage gateways from the previous version, even
though the gateways may not support the new features. You can upgrade the
gateways at your convenience.
the deployment to NGX R65. It is used to test the current SmartCenter server prior
to upgrading to NGX R65. The Pre-Upgrade verification tool produces a detailed
report indicating the appropriate actions that should be taken before performing an
upgrade to NGX R65 (refer to “Using the Pre-Upgrade Verification Tool” on
page 91).
There are two upgrade methods available for the SmartCenter server:
• Upgrade your Production SmartCenter Server
Perform the upgrade process on the production SmartCenter server (refer to the
procedures in this section).
• Migrate and Upgrade to a New SmartCenter Server
Perform a migration process (refer to “Migrate Your Current VPN-1 Gateway
Configuration & Upgrade” on page 178) of the currently installed version to a
new server, and upgrade the migrated system.
Using the Pre-Upgrade Verification Tool

Pre-upgrade verification runs automatically (or manually if desired) during the
SmartCenter upgrade. Pre-upgrade verification performs a compatibility analysis of
the currently installed SmartCenter server and its current configuration. A detailed
report is provided, indicating appropriate actions that should be taken before and
after the upgrade process.

Usage:
pre_upgrade_verifier.exe -p SmartCenterPath -c CurrentVersion
-t TargetVersion [-f FileName] [-w]
or
-i[-f FileName][-w]
-p Path of the installed SmartCenter Server (FWDIR)
-c Currently installed version
-t Target version
-i Check originality of INSPECT files only
-f Output in file
-w Web format file
Where the currently installed version is one of the following:
For Release Version is:

NGX NGX_R62
NGX_R61
NGX_R60A
NGX_R60
NG NG_R55
NG_R55P
NG_R55
NG_R54
NG_FP3
NG
GX GX_2.5
VSX VSX_2.0.1
VSX_NG_AI
VSX_NG_AI_Release_2
The target version is: NGX_R65.

-f redirects the standard output to a file.
92
Action Items Before and After the Pre-Upgrade Process

• errors - Items that must be repaired before and after performing the upgrade. If
you proceed with the upgrade while errors exist, the upgrade will fail.
• warnings - Items that you should consider repairing before and after performing
the upgrade.

SmartCenter Upgrade on a Windows Platform

This section describes the upgrade process using the NGX R65 CD. It is
recommended to back up your current configuration before you perform the
upgrade process. For additional information, refer to Chapter 3: “Backup and
Revert for VPN-1 Power/UTM”. If a situation arises in which a revert to your
previous configuration is required, refer to “Revert” on page 134 for details.
To perform an upgrade on a Windows platform:
1. Access your NGX R65 CD.
2. Execute the Installation package.
3. After accepting the EULA, verify your contract information.
For more information on contracts, see: “Installing a Contract File on
SmartCenter server” on page 60
4. From the Upgrade Options screen, select Upgrade.
5. When the pre-upgrade verification recommendation appears, select whether or
not the Pre-upgrade verification tool should be executed (refer to “Using the
Pre-Upgrade Verification Tool” on page 91). Pre-upgrade verification performs a
compatibility analysis of the currently installed SmartCenter server and of its
current configuration. A detailed report is provided, indicating appropriate
actions that should be taken before and after the upgrade process. The tool can
be used manually as well.
6. From the Upgrade Options screen, select Upgrade again.
Another verification is run.
7. When prompted, reboot your SmartCenter server.
Uninstalling Packages
Uninstall Check Point packages on the Windows platform using the Add/Remove
applet in the Control Panel. Check Point packages need to be uninstalled in the
opposite order to which they were installed. Since CPsuite is the first package
installed, it should be the last package uninstalled.
94
SmartCenter Upgrade on SecurePlatform

Upgrading to NGX R65 on a SecurePlatform operating system requires updating
both the operating system and the installed software products. The procedure in
this section applies to SmartCenter versions:
• R62
• R61
• R60A
• R60
• R55W
• R55
• R54
For details on upgrading SecurePlatform versions prior to R54, refer to
“SmartCenter Upgrade on Pre-R54 Versions of SecurePlatform” on page 99.
The process described in this section upgrades all of the components (Operating
System and software packages) in a single upgrade process. No further upgrades
are required.
Refer to the CheckPoint R65 SecurePlatform/SecurePlatformPro Administration
Guide for additional information.
If a situation arises in which a revert to your previous configuration is required,
refer to “Reverting to Your Previous Deployment” on page 135 for details.
To perform an upgrade on a SecurePlatform:
1. Insert CD1 of the NGX R65 media kit into the CD drive.
2. At the command prompt, enter patch add cd.
3. Select SecurePlatform NGX R65 Upgrade Package (CPspupgrade_R65.tgz).
4. Enter y to accept the checksum calculation.
5. When prompted, create a backup image for automatic revert.
Note - Creating the snapshot image can take up to twenty minutes, during which Check
Point products are stopped.
6. The welcome message is displayed. Enter n.

7. Accept the license agreement, and verify your contract information.

For more information on contracts, see: “On SecurePlatform, Linux, and Solaris
Gateways” on page 76
8. Three upgrade options are displayed:
• Upgrade
• Export SmartCenter configuration
• Perform pre-upgrade verification only
i. Run the pre-upgrade verification script, and follow the
recommendations contained in the pre-upgrade verification results.
Repeat the process until you see Your configuration is ready for upgrade.
ii. Export the SmartCenter configuration.
iii. Upgrade the installation.
9. Enter c to agree to the license upgrade.
The license upgrade process also handles gateway licenses in the SmartUpdate
License Repository. Select one of the following:
• Enter [L] to view the licenses installed on your machine.
• Enter [C] to check if currently installed licenses have been upgraded.
• Enter [S] to simulate the license upgrade.
• Enter [U] to perform the license upgrade, or generate a license file that can
be used to upgrade licenses on a machine with no Internet access to the
User Center.
• Enter [O] to perform the license upgrade on a license file that was
generated on machine with no Internet access to the User Center.
• Enter [Q] to quit.
10. Select a source for the upgrade utilities.
Either download the most updated files from the Check Point website or use
the upgrade tools contained on the CD. The exported configuration is
automatically imported during the upgrade process.
11. Open SmartUpdate and attach the new NGX licenses to the gateways.
Check Point packages need to be uninstalled in the opposite order to which they
were installed. Since CPsuite is the first package installed, it should be the last
package uninstalled.
96
Run the rpm -e <package name> to view a list of all the installed packages.
Gateway Upgrade on UTM-1

this section applies to UTM-1.
are required.
Refer to the CheckPoint R65 SecurePlatform/SecurePlatformPro Administration
Guide for additional information.
1. Install an external CD-ROM drive to the appliance by running the following
commands:
mkdir /mnt/cdrom
modprobe usb-storage
modprobe usb-uhci
mount /dev/scd0/mnmt/cdrom

• Upgrade


User Center.
Gateway Upgrade on UTM-1 using the WebUI

To upgrade your appliance:
1. Download an upgrade package, as directed. If you already downloaded the file,
you can skip this step.
2. Select the upgrade package file.
3. Click Upload package to appliance.
4. Click Start Upgrade.
98
5. Before the upgrade begins, an image is created of the system and is used to
revert to in the event the upgrade is not successful. The Save an Image before
Upgrade page, displays the image information.
Click Next.
6. In the Safe Upgrade section, select Safe upgrade to require a successful login
after the upgrade is complete. If no login takes place within the configured
amount of time, the system will revert to the saved image.
Click Next.
7. The Current Upgrade File on Appliance section displays the information of the
current upgrade.
To begin the upgrade, click Start.
SmartCenter Upgrade on Pre-R54 Versions of

SecurePlatform
this section applies to the following SmartCenter versions:
• NG
• NG FP2
• NG FP3
• NG FP3 Edition 2
For details on upgrading later SecurePlatform versions, refer to “SmartCenter
Upgrade on SecurePlatform” on page 95.
are required. Upgrading pre-R54 versions requires an upgrade of the patch
command.
To perform an upgrade on pre-R54 versions of SecurePlatform:
1. Insert the SecurePlatform NGX R65 CD into the CD drive.
2. Enter the expert mode: # expert.

3. Mount the CD and upgrade the patch command using the following syntax:
# mount /mnt/cdrom
# patch add /mnt/cdrom/SecurePlatform/patch/CPpatch_command_*.tgz.

For more information on contracts, see:“On SecurePlatform, Linux, and Solaris
• Upgrade
ii. Export the SmartCenter configuration
iii. Upgrade the installation
license repository. Select one of the following:
100

User Center.


Open SmartUpdate and attach the new NGX licenses to the gateways.
Note - The "patch add cd" command presents three options: run the pre-upgrade
verification script; export the SmartCenter configuration; upgrade the installation.
If you select the first option, the command exits after performing the pre-upgrade
verification. To select the second or third options, you need to run the "patch add cd"
command again.
were installed. Since CPsuite is the first package installed, it will be the last
Run the rpm -e <package name> to view a list of all the installed packages.
102
SmartCenter Server Upgrade on a Solaris Platform

recommended that you back up your current configuration before you perform an
To perform an upgrade on a Solaris machine in a production environment:
1. Insert CD3 of the NGX R65 media kit into the CD drive, and mount the CD.
2. Run UnixInstallScript.
The wrapper welcome message is displayed.
3. Enter n.
4. Enter y to agree to the End-user License Agreement, and verify your contract
information.
5. Select upgrade.
(It is also possible to upgrade using an imported configuration.)
6. Enter n.
Although the NGX R65 upgrade utilities are on the NGX R65 CD, it is
recommended to download the latest tools from the Check Point website at:
http://www.checkpoint.com/downloads/quicklinks/utilities/ngx/utilities.html
8. The pre-upgrade verification process runs automatically. View the results and
follow any recommendations. Then, run the pre-upgrade verifier again. This
message is displayed: The pre-Upgrade Verification was completed successfully.
Your configuration is ready for upgrade.
9. To perform the upgrade, select Upgrade installed products.
To install additional products, select Upgrade installed products and install new
products. You are prompted to select the products from a list. Enter n.
10. Enter n to validate the products to install.
The products are upgraded. Wait until the successful message is displayed.
11. Enter e to exit.

12. Reboot.
were installed. Since CPsuite is the first package installed, it will be the last
Run the pkgrm command to view a list of the installed packages.
104
SmartCenter Upgrade on a Linux Platform

recommended that you back up your current configuration, before you perform an
upgrade process.
To perform an in-place upgrade:
2. From the root directory, run UnixInstallScript.
3. Enter n.
information.
5. Select upgrade.
6. Enter n.
Although the R65 upgrade utilities are on the NGX R65 CD, it is recommended
to download the latest tools from the Check Point website:
9. To perform the upgrade, specify Upgrade installed products.
To install new products, select Upgrade installed products and install new
products, select the products, and enter n.
The products are upgraded.
12. Reboot.

Run the rpm -e <package name> to view a list of the installed packages.
106
SmartCenter Upgrade on an IPSO Platform

Before beginning the upgrade process:
• It is recommended that you back up your current configuration, in case the
upgrade process is unsuccessful. IPSO has its own backup and restore facility.
For additional information, refer to the Nokia Network Voyager Reference Guide.
• Download and run the pre-upgrade verifier (PUV) for IPSO from:
For details on using the PUV, refer to “Using the Pre-Upgrade Verification Tool”
on page 91.
To perform an upgrade on an IPSO Platform:
1. From the Check Point website, download the NGX R65 upgrade package:
IPSO_Wrapper_R65.tgz
2. Enter the Network Voyager and open a CLI console.
Note - For NGX R65, you must first install either IPSO 4.1, 4.2
3. Click System Configuration > Install New IPSO Image (Upgrade).

The New Image Installation Upgrade window opens.
4. Enter the following information:
Enter URL to the image location
Enter HTTP Realm (for HTTP URLs only)
Enter Username (if applicable)
Enter Password (if applicable)
5. Click Apply.
You are informed that the file download and image installation may take some
time.
6. Click Apply.
7. The new image installation process begins. Click the provided link to get the
upgrade status.

8. When the upgrade is complete, click the link to the IPSO Image Management
page.
The IPSO Image Management window opens.
9. Under the title Select an image for next boot, select the last downloaded image.
10. Click Test Boot.
11. Access the CLI console to see when the Reboot is complete. Once the Reboot
is complete, go back to the Network Voyager to verify that the image was set
properly.
12. In the Network Voyager, click Refresh and log in.
13. If you are not returned to the last window you were in, click
System Configuration > Manage IPSO Images.
You should be able to see that the relevant IPSO Image is selected.
14. Select Commit testboot and click Apply.
15. Access the CLI console and log in.
16. Perform an FTP using bin mode to transfer the IPSO_Wrapper_R65.tgz package.
17. Type newpkg -S -m LOCAL -n <CPsuite package path> -o $FWDIR and press Enter.
This command:
• Deactivates previous Check Point packages but does not delete them.
• Finds the upgrade tools in $FWDIR and performs an import/export operation
to preserve the previous configuration.
When the process is complete, you should receive a message indicating that the
process was successful, along with a reminder to update your contract
information. For more information on contracts, see: “On IPSO” on page 81.
18. Log off the console connection, and then log back on to set the environment
variables.
19. Start the installed products by running cpstart.
Note - The previous Check Point packages remain installed but deactivated. Should the
need arise, the previous packages can be activated through the Network Voyager.
108
Upgrading VPN-1 Express CI R57 SmartCenter

Server
A VPN-1 Express CI R57 SmartCenter server upgrade is manually performed using
the upgrade_import and upgrade_export tools located on the product CD or in the
$FWDIR\bin\upgrade_tools directory.
Upgrading SmartCenter Server Component to R65

This section describes how to perform an advanced upgrade on an additional
SmartCenter server via a spare machine.
To upgrade a SmartCenter server component:
1. Locate the upgrade_import and upgrade_export tools in the
$FWDIR\bin\upgrade_tools directory. (The tools are also available on the
product CD.)
2. Select Export in Upgrade Options.
If you opt to perform the Export procedure manually, make sure that you are
using the NGX R65 Export tool.
3. Select the destination path of the configuration (.tgz) file.
Wait while exporting database files.
4. Copy the exported.tgz file to the new SmartCenter server.
5. Insert the NGX R65 CD into the new SmartCenter server.
6. Select Installation using Imported Configuration (Windows) or Advanced Upgrade
(Solaris) in the Installation Options.
This option prompts you for the location of the imported .tgz configuration file
and then automatically installs the new software and utilizes the imported .tgz
configuration file.
Warning - The configuration file (.tgz) file contains your security configuration. It is highly
recommended to delete it after completing the import process.

Upgrading a SmartCenter High Availability

Deployment
To upgrade a SmartCenter server high availability deployment:
1. Before you perform the Upgrade process, synchronize all the SmartCenter
servers (select Policy > Management High Availability).
2. Perform the Upgrade process on both SmartCenter servers (refer to the relevant
upgrade process below).
3. Using the SmartDashboard GUI client, connect to one of the SmartCenter
servers.
4. In the General page of each of the SmartCenter server's Gateway Properties
window, set the correct Check Point Products Version.
This can also be done by clicking the Get Version button in the specific objects’
properties page.
5. Once again, synchronize all the SmartCenter servers (select Policy >
Management High Availability).
6. Repeat steps 3 and 4 for each additional SmartCenter server.
110
Upgrading the Gateway

There are two upgrade methods available:
• SmartUpdate Upgrade: Allows you to centrally upgrade and manage Check
Point software and licenses.
• Local Upgrade: Performs a local upgrade on the gateway itself.
In This Section
Upgrading a Clustered Deployment page 111

Upgrading the Gateway Using SmartUpdate page 112
Gateway Upgrade Process on a Windows Platform page 116
Gateway Upgrade on SecurePlatform page 118
Upgrade on SecurePlatform NG FP2, FP3, or FP3 Edition 2 page 119
Gateway Upgrade on a Solaris Platform page 121
Gateway Upgrade on an IPSO Platform page 122
Upgrading a Clustered Deployment

You can select one of the following options, when upgrading a Clustered
deployment:
• Minimal Effort Upgrade: Select this option if you have a period of time
during which network downtime is allowed. The minimal effort method is
much simpler because the clusters are upgraded as gateways and therefore
can be upgraded as individual gateways.
• Zero Downtime: Select this option if network activity is required during the
upgrade process. The zero downtime method assures both inbound and
outbound network connectivity at all times during the upgrade. There is
always at least one active member that handles traffic.
For additional information, refer to “Upgrading ClusterXL Deployments” .

Upgrading the Gateway Using SmartUpdate

SmartUpdate is an optional module for VPN-1 that automatically distributes
software packages and remotely performs upgrades of gateways and various OPSEC
products. It provides a centralized means to guarantee that the latest software
versions are used throughout the enterprise network. SmartUpdate takes
time-consuming tasks, which could otherwise be performed only by experts, and
turns them into simple point and click operations.
The following products can be upgraded to NGX R65:
• VPN-1 Pro Gateways
• SecurePlatform
• Performance Pack
• SmartView Monitor (as part of the NGX R65 software package)
• Eventia Reporter
• UserAuthority Server
• PolicyServer (as part of the NGX R65 software package)
• QoS (as part of the NGX R65 software package)
• Nokia OS
• UTM-1
SmartUpdate Options
SmartUpdate is the primary tool used for upgrading Check Point gateways. The
following features and tools are available in SmartUpdate:
• Upgrade All Packages: This feature allows you to upgrade all packages installed
on a gateway. For IPSO and SecurePlatform, this feature also allows you to
upgrade your operating system as a part of your upgrade. In NGX R65,
SmartUpdate's “Upgrade all Packages” supports HFAs, i.e., it will suggest
upgrading the gateway with the latest HFA if a HFA package is available in the
Package Repository. "Upgrade All" is the recommended method. In addition,
there is an advanced method to install (distribute) packages one by one.
• Add Package to Repository: SmartUpdate provides three “helper” tools for
adding packages to the Package Repository:
• From CD: Adds a package from the Check Point CD.
• From File: Adds a package that you have stored locally.
112
• From Download Center: Adds a package from the Check Point Download
Center.
• SmartUpdate’s Get Check Point Gateway Data: This tool updates SmartUpdate
with the current Check Point or OPSEC third-party packages installed on a
specific gateway or for your entire enterprise.
• Check for Updates: This feature, available from the SmartDashboard Tools
menu, locates the latest HFA on the Check Point Download Center, and adds it
to the Package Repository.
Configuring the SmartCenter Server for SmartUpdate

To configure the SmartCenter server for SmartUpdate:
1. Install the latest version of SmartConsole, including SmartUpdate.
Note - SmartUpdate is available as part of Smartcenter Power.
2. Define the remote Check Point gateways in SmartDashboard (for a new

SmartCenter server installation).
3. Verify that your SmartCenter server contains the correct license to use
SmartUpdate.
4. Verify that the Administrator SmartUpdate permissions (as defined in the
cpconfig configuration tool) are Read/Write.
5. To enable SmartUpdate connections to the gateways, make sure that Policy
Global Properties > FireWall > Firewall Implied Rules > Accept SmartUpdate
Connections (SmartUpdate) is selected. By default, it is selected.

Add Packages to the Package Repository

Use SmartUpdate to add packages to and delete packages from the Package
Repository:
• directly from the Check Point Download Center website (Packages > Add > From
Download Center...),
• by adding them from the Check Point CD (Packages > Add > From CD...),
• by importing a file (Packages > Add > From File...).
When adding the package to the Package Repository, the package file is transferred
to the SmartCenter server. When the Operation Status window opens, you can verify
the success of the operation. The Package Repository is then updated to show the
new package object.
Gateway Upgrade Process Using SmartUpdate

To update a gateway using SmartUpdate:
1. From SmartUpdate > Packages > Upgrade All Packages select one or more
gateways and click Continue.
The Upgrade All Packages window opens, and in the Upgrade Verification list you
can see which gateways can or cannot be upgraded.
• To see a list of which packages will be installed on the gateways that can be
upgraded, select the gateway and click the Details button.
• For an explanation as to why a gateway cannot be upgraded, select the
relevant gateway and click the Details button.
2. From the list provided, select the gateways that can be upgraded and click
Upgrade.
Note - The Allow reboot... option (selected by default) is required in order to activate
the newly installed packages.
The Operation Status pane opens and shows the progress of the installation.
Each operation is represented by a single entry. Double click the entry to open
the Operation Details window, which shows the operation history.
The following operations are performed during the installation process:
• The Check Point Remote Installation Daemon connects to the Check Point
gateway.
• Verification for sufficient disk space.
114
• Verification of the package dependencies.

• The package is transferred to the gateway if it is not already there.
• The package is installed on the gateway.
• Enforcement policies are compiled for the new version.
• The gateway is rebooted if the Allow Reboot... option was selected and the
package requires it.
• The gateway version is updated in SmartDashboard.
• The installed packages are updated in SmartUpdate.
Using SmartUpdate NGX R65 to Upgrade Prior Versions

SmartUpdate NGX R65 can be used to upgrade the following pre-R65 versions to
R65:
• R54
• R55
• R55W
• R55P
• R60
• R60A
• R61
To upgrade a gateway to a pre-R65 version:
1. Add the corresponding packages to the Package Repository.
2. Right-click the gateway and select Distribute Package...
3. Select the relevant package from the list provided and click Distribute.
Repeat steps 2 to 3 for each package that should be installed on the gateway.
Note - It is also possible to use SmartUpdate to install HFAs on gateways from previous
versions (for example, R54 and later).

Gateway Upgrade Process on a Windows Platform

This section describes the upgrade process using the NGX R65 Installation CD.
To upgrade a gateway in a Windows platform:
4. Select one of the following upgrade options:
• Download Most Updated Upgrade Utilities (recommended method).
This download provides the most recent upgrade code available.
• I have already downloaded and extracted the Upgrade Utilities. The files are on
my local disk.
This option should be used when software packages have been previously
downloaded. This method is useful when Internet access is not available
from the SmartCenter server machine.
• Use the CD version.
not the Pre-upgrade verification tool should be executed (refer to the “Using
the Pre-Upgrade Verification Tool” on page 91). The Pre-upgrade verification
tool performs a compatibility analysis of the currently installed gateway and its
current configuration. A detailed report is provided, indicating the appropriate
7. When prompted, reboot the gateway.
116
8. When the upgrade process is complete, do the following:

a. Using SmartDashboard, log in to the NGX R65 SmartCenter server that
controls the upgraded gateway.
b. Open the gateway object properties window that represents the upgraded
gateway and change the version to NGX R65.
c. Perform Install Policy on the upgraded gateway.

Gateway Upgrade on SecurePlatform

both operating system and software products installed. SecurePlatform users
should follow the relevant SecurePlatform upgrade process. The upgrade process is
supported for:
• R62
• R61
• R60A
• R60
• R55W
• R55
• R54
For details on upgrading gateway versions prior to R54, refer to “Upgrade on
SecurePlatform NG FP2, FP3, or FP3 Edition 2” on page 119.
The process described in this section upgrades all components (Operating System
and software packages) in a single upgrade process. No further upgrades are
required. Refer to the CheckPoint R65 SecurePlatform/SecurePlatformPro
Administration Guide for additional information.
Upgrading SecurePlatform Using a CD Rom

This section describes how to upgrade SecurePlatform R54 and later versions using
a CD ROM drive.
To upgrade SecurePlatform using a CD:
1. Log in to SecurePlatform (expert mode is not necessary).
2. Apply the SecurePlatform NGX R65 upgrade package: # patch add cd.
3. Select the SecurePlatform upgrade package (CPspupgrade_R65.tgz)
4. Enter y to accept the MD5 checksum calculation.
118
A Safe Upgrade will be performed. Safe Upgrade automatically takes a

snapshot of the entire system so that the entire system (operating system and
installed products) can be restored if something goes wrong during the Upgrade
process (for example, hardware incompatibility). If the Upgrade process detects
a malfunction, it automatically reverts to the Safe Upgrade image.
When the Upgrade process is complete, upon reboot you are given the option to
manually start the SecurePlatform operating system using the upgraded version
image or using the image created prior to the Upgrade process.
6. After you complete the upgrade process, do the following:
b. Open the gateway object properties window for the upgraded gateway and
change the version to NGX R65.
Upgrade on SecurePlatform NG FP2, FP3, or FP3

Edition 2
Upgrading to NGX R65 over a SecurePlatform operating system requires updating
both the operating system and the installed software products. SecurePlatform
users should perform the relevant SecurePlatform upgrade process.
The process described in this section upgrades all components (Operating System
and software packages) in a single upgrade process. No further upgrades are
required.
Refer to CheckPoint R65 SecurePlatform/SecurePlatformPro Administration Guide
for additional information.
This procedure describes how to upgrade SecurePlatform NG FP2, FP3, or FP3
Edition 2. Upgrading pre-R54 versions requires an upgrade of the patch command.
To upgrade SecurePlatform NG FP2, FP3, or FP3 Edition 2:
1. Insert the SecurePlatform NGX R65 CD into the drive.
2. Enter the expert mode: # expert.
# mount /mnt/cdrom

4. Apply the SecurePlatform NGX R65 upgrade package using a CD ROM drive
with the following command:
# patch add cd.
You are prompted to verify the MD5 checksum.
5. Answer the following question:
Do you want to create a backup image for automatic revert? Yes/No
If you select Yes, a Safe Upgrade is performed.
Safe Upgrade automatically takes a snapshot of the entire system so that the
entire system (operating system and installed products) can be restored if
something goes wrong during the Upgrade process (for example, hardware
incompatibility). If the Upgrade process detects a malfunction, it automatically
reverts to the Safe Upgrade image.
manually start the SecurePlatform operating system using the upgraded version
image or using the image created prior to the Upgrade process.
b. Open the gateway object properties window that represents the upgraded
gateway and change the version to NGX R65.
120
Gateway Upgrade on a Solaris Platform

recommended that you back up your current configuration before you perform an
Revert for VPN-1 Power/UTM”.
refer to “Revert” on page 134 for details.
To upgrade a gateway on a Solaris platform:
2. From the root directory of the cd, run UnixInstallScript.
3. Enter n.
4. Enter Y. to agree to the End-user License Agreement and verify your contract
information. For further information on contracts, see:“On SecurePlatform,
Linux, and Solaris Gateways” on page 76
5. Select upgrade.
6. Enter n.
While the NGX R65 upgrade utilities are on the NGX R65 CD, it is
recommended to download the latest tools from the Check Point website.
follow any recommendations. Then, run the pre-upgrade verifier again. The
following message is displayed: The pre-Upgrade Verification was completed
successfully. Your configuration is ready for upgrade.
9. Select Upgrade installed products.
11. Enter e to exit
12. Reboot.


Gateway Upgrade on an IPSO Platform

This section describes the steps that should be performed when performing an
upgrade on an IPSO Platform for versions 4.1 or 4.2
To upgrade a gateway on an IPSO platform:
4. Click Apply.
You are informed that the file download and image installation can take a long
time.
5. Click Apply.
6. The new image installation process starts. Click the provided link to view the
upgrade status.
7. When the upgrade is complete, click the link to the IPSO Image Management
page.
9. Click testboot.
122
Testboot is a special reboot process that permits the user to roll back to a
previous image should problems arise.
10. Access the CLI console to monitor the reboot process. Once the reboot is
complete, return to the Network Voyager and verify that the image was set
properly.
13. In the window that opens, select Commit testboot and click Apply.
Note - If you do not commit the testboot within five minutes of the test completing, the
platform automatically reboots to the previous image.

15. Using bin mode, transfer the package via FTP.
On flash-based platforms, Nokia recommends creating a directory under /var
and downloading the package to it. This directory is deleted when the upgrade
is complete and the system is rebooting, ensuring that the installation package
does not consume flash memory.
The package is loaded and the products are upgraded. When the process is
complete, you should receive a message indicating that the process was
successful.
17. Log off from the console connection, then log back on to set the environmental
variables.
18. Log on to the Network Voyager, and confirm that the following packages are
enabled:
• Check Point VPN-1 Power/UTM NGX R65
• Check Point CPinfo
19. Verify that the older packages are disabled.
20. Return to the CLI console and type Reboot.

Upgrading the VPN-1 Express CI R57 Component

to R65
Upgrading a VPN-1 Express CI R57 gateway component to NGX R65 is not
supported. Perform a fresh NGX R65 installation (refer to the CheckPoint R65
Internet Security Products Getting Started Guide).
124
Chapter 5
Backup and Revert for VPN-1
Power/UTM
In This Chapter

Backing Up Your Current Deployment page 127
Restoring a Deployment page 128
SecurePlatform Backup and Restore Commands page 129
SecurePlatform Snapshot Image Management page 132
Reverting to Your Previous Deployment page 135
125
Introduction
Introduction
Before you perform an upgrade process, you should back up your current
configuration. The purpose of the backup process is to back up the entire
configuration, and to restore it if necessary, for example, in the event that the
upgrade process is unsuccessful.
To back up your configuration, use the Export utility tool of the version for which
you are creating a backup file. For example, if you are backing up NG with
Application Intelligence R55, use the NG with Application Intelligence Export utility
tool. The backup file contains your current system configuration (for example,
objects, rules, and users) and can be used to restore your previous configuration if
the upgrade process fails. The restoration procedure restores the configuration in
effect when the backup procedure was executed.
Note - Operating system level configurations (for example, network configuration) are not
exported.
If you are performing an upgrade process on SecurePlatform, you do not have to

back up your configuration using the Export utility. SecurePlatform provides the
option of backing up your configuration during the Upgrade process.
126
Backing Up Your Current Deployment
Backing Up Your Current Deployment

To back up your current deployment:
1. In the original SmartCenter server, insert the product CD for the version you are
backing up.
2. Select the Export option in the installation wizard, or use the Export tool located
in the relevant operating system directory on the product CD.
Once the Export utility process is complete, the configuration file is created in
the chosen destination path in a tar gzipped format (.tgz).
Warning - The configuration file (.tgz) contains your product configuration. It is highly
Chapter 5 Backup and Revert for VPN-1 Power/UTM 127

Restoring a Deployment
Restoring a Deployment
To restore a deployment:
1. Copy the exported.tgz file to the target SmartCenter server.
2. In the SmartCenter server, insert the product CD for the version being restored.
3. Using the available options, perform an installation using an imported
configuration file.
128
SecurePlatform Backup and Restore Commands
SecurePlatform Backup and Restore

Commands
In This Section
Backup page 129

Restore page 131
SecurePlatform NGX provides a command line or Web GUI capability for

conducting backups of your system settings and products configuration.
The backup utility can store backups either locally on the SecurePlatform machine
hard drive, or remotely to a TFTP server or an SCP server. The backup can be
performed on request, or it can be scheduled to take place at set intervals.
The backup files are kept in tar gzipped format (.tgz). Backup files, saved locally,
are kept in /var/CPbackup/backups.
The restore utility is used for restoring SecurePlatform settings and/or product
configurations from backup files.
Expert permissions are required to perform the backup and restore procedures.
Backup
This command is used to back up the system configuration. You can also copy
backup files to a number of SCP and TFTP servers for improved backup robustness.
The backup command, when run by itself without any additional flags, uses default
backup settings and performs a local backup.
Syntax
backup [-h] [-d] [-l] [--purge DAYS] [--sched [on hh:mm <-m DayOfMonth>
| <-w DaysOfWeek>] | off] [[--tftp <ServerIP> [-path <Path>]
[<Filename>]] |
[--scp <ServerIP> <Username> <Password> [-path <Path>][<Filename>]] |
[--file [-path <Path>][<Filename>]]

Backup
Parameters
Table 5-1 Backup Parameters
Parameter Meaning
-h obtain usage
-d debug flag
-l Enables VPN-1 log backup (By default, VPN-1 logs
are not backed up.)
--purge DAYS Deletes old backups from previous backup attempts
[--sched [on hh:mm <-m Schedule interval at which backup is to take place
DayOfMonth> | <-w
• On - specify time and day of week, or day of
DaysOfWeek>] | off]
month
• Off - disable schedule
--tftp <ServerIP> [-path List of IP addresses of TFTP servers, on which the
<Path>][<Filename>] configuration is to be backed up, and optionally the
filename
--scp <ServerIP> List of IP addresses of SCP servers, on which the
<Username> configuration is to be backed up, the username and
<Password>[-path <Path>] password used to access the SCP server, and
[<Filename>] optionally the filename
--file [-path When the backup is performed locally, specify an
<Path>]<Filename> optional filename
130
Restore
Restore
This command is used to restore the system configuration.
Syntax
restore [-h] [-d][[--tftp <ServerIP> <Filename>] |
[--scp <ServerIP> <Username> <Password> <Filename>] |
[--file <Filename>]]
Parameters
Table 5-2
Parameter Meaning
-h obtain usage
-d debug flag
--tftp <ServerIP> IP address of TFTP server, from which the
[<Filename>] configuration is restored, and the filename
--scp <ServerIP> IP address of SCP server, from which the
<Username> <Password> configuration is restored, the username and
[<Filename>] password used to access the SCP server, and the
filename
--file <Filename> Specify a filename for restore operation, performed
locally
For additional information about the backup and restore utilities, refer to the
System Commands section in the CheckPoint R65
SecurePlatform/SecurePlatformPro Administration Guide.

SecurePlatform Snapshot Image Management
SecurePlatform Snapshot Image

Management
In This Section
Snapshot page 133

Revert page 134
SecurePlatform provides the option of backing up the entire SecurePlatform

operating system and all of its products using the snapshot command.
A snapshot of the system can be taken manually using the snapshot command or
automatically during an upgrade procedure using the SafeUpgrade option.
The snapshot and revert commands can use a TFTP server or an SCP server to
store snapshots. Alternatively, snapshots can be stored locally.
132
Snapshot
Snapshot
This command creates a snapshot file. The snapshot command, run by itself
without any additional flags, uses the default backup settings and creates a local
snapshot.
Syntax
snapshot [-h] [-d] [[--tftp <ServerIP> <Filename>] |
Parameters
Table 5-3 Snapshot Parameters
Parameter Meaning
-h obtain usage
-d debug flag
--tftp <ServerIP> IP address of the TFTP server, from which the
<Filename> snapshot is taken, as well as the filename of the
snapshot
--scp <ServerIP> IP address of the SCP server, from which the
<Username> <Password> snapshot is taken, the username and password
<Filename> used to access the SCP server, and the filename of
the snapshot
--file <Filename> When the snapshot is made locally, specify a
filename

Revert
Revert
This command reboots the system from a snapshot file. The revert command, run
by itself without any additional flags, uses default backup settings, and reboots the
system from a local snapshot.
revert [-h] [-d] [[--tftp <ServerIP> <Filename>] |
Parameters
Table 5-4 Revert Parameters
Parameter Meaning
-h obtain usage
-d debug flag
--tftp <ServerIP> IP address of the TFTP server, from which the
<Filename> snapshot is rebooted, as well as the filename of the
snapshot
--scp <ServerIP> IP address of the SCP server, from which the
<Username> <Password> snapshot is rebooted, the username and password
<Filename> used to access the SCP server, and the filename of
the snapshot
--file <Filename> When the snapshot is made locally, specify a
filename
The revert command functionality can also be accessed from the Snapshot image
management boot option.
134
Reverting to Your Previous Deployment

In This Section
To an Earlier Version on a Nokia Platform page 135

To an Earlier Version on a Windows Platform page 136
To an Earlier Version on a Solaris Platform page 136
To an Earlier Version on a SecurePlatform page 136
To an Earlier Version on a Linux Platform page 136
ICA Considerations page 137
To revert to version active before NGX R65 VPN-1 Power/UTM, perform the relevant
procedures described in this section.
Note - Make sure to remove all NGX R65 products and compatibility packages before
removing the NGX R65 CPsuite.
To an Earlier Version on a Nokia Platform

To revert to a prior software version on a Nokia platform:
• If you are reverting to an NG or NGX version that is compatible with your
current IPSO version, deactivate the NGX R65 products, making sure to
deactivate VPN-1 Power/UTM last, and then reactivate the previous product
versions.
or
If you are reverting to an NG version that requires an earlier IPSO version, do
the following:
1. On the IPSO Image Management page in Network Voyager, select the earlier
IPSO image and reboot.
When you revert to the earlier image, IPSO automatically reverts to the
saved configuration set associated with that image.
2. On the Manage Packages page, confirm that the previous versions of Check
Point packages are enabled and the NGX R65 versions are disabled.
Note - On flash-based platforms, the NGX R65 packages no longer appear in the Manage
Packages page since they were never part of the previous configuration set.

To an Earlier Version on a Windows Platform

To revert to a prior software version on a Windows platform:
• In the Add/Remove Programs applet, select Check Point VPN-1 Power/Express
NGX R65.
To an Earlier Version on a Solaris Platform

To revert to a prior software version on a Solaris platform:
• Run the command: pkgrm CPsuite-R65.
To an Earlier Version on a SecurePlatform

To revert to a prior software version on a SecurePlatform:
1. On SecurePlatform machines, enter expert mode to uninstall the package.
2. Run the command: rpm –e CPsuite-R65-00.
To an Earlier Version on a Linux Platform

To revert to a prior software version on a Linux platform:
• Run the command: rpm –e CPsuite-R65-00.
136
ICA Considerations
Once the Revert process is complete, certificates issued during the use of NGX
R65 remain valid. While these certificates are valid, they cannot yet be managed
by the Internal CA.
To resume management of older certificates after the Revert process:
1. Back up the InternalCA.NDB and ICA.crl files (located in the $FWDIR/conf
directory) and all *.crl files (located in the $FWDIR/conf/crl directory) from
the version prior to NGX R65 (for example, from NG with Application
Intelligence R55) to a location of your choice.
2. Copy the NGX R65 InternalCA.NDB, ICA.crl and the *.crl files (located in
the $FWDIR/conf directory) from the current NGX R65 version and use them to
overwrite the files (for example, the NG with Application Intelligence R55 files)
in the location specified in step 1 (in the $FWDIR/conf directory).
Note - If the Upgrade process was performed on a machine that runs a different operating
system than the original machine, the InternalCA.NDB file must be converted after it is
copied to the reverted environment. To do this, run the ‘cpca_dbutil d2u’ command
line from the reverted environment.
3. Once the Revert process is complete, use the ICA Management Tool to review
certificates created using NGX R65 in the reverted environment (for example,
the NG with Application Intelligence R55 environment). For example, the
subject to which a specific certificate was issued may no longer exist. In such
a case, you may want to revoke the specific certificate.
For additional information, refer to The Internal Certificate Authority (ICA) and
the ICA Management Tool chapter in the R65 SmartCenter Administration Guide.

138
Chapter 6
Upgrading a Standalone
Deployment
In This Chapter

Pre-Upgrade Considerations page 141
Standalone VPN-1 Gateway Upgrade on a Windows Platform page 144
Standalone VPN-1 Gateway Upgrade on SecurePlatform page 145
Standalone Upgrade on UTM-1 page 148
Standalone Upgrade on UTM-1 using the WebUI page 150
VPN-1 Gateway Upgrade on Pre-R54 SecurePlatform Versions page 151
Standalone VPN-1 Gateway Upgrade on a Solaris Platform page 154
Standalone VPN-1 Gateway Upgrade on an IPSO Platform page 156
VPN-1 Express CI R57 to NGX R65 on SecurePlatform page 159
139
Introduction
Introduction
This chapter describes the process of upgrading a VPN-1 standalone deployment to
NGX R65. A standalone deployment consists of the SmartCenter server and
gateway installed on the same system. Since backward compatibility is supported,
a SmartCenter server that has been upgraded to NGX R65 can enforce and manage
gateways from previous versions. In some cases, however, new features may not be
available on earlier versions of the gateway.
The NGX R65 SmartCenter server can manage the following gateways:
Release Version
VPN-1 Pro NG R55W
Express CI R57
GX 2.5, 2.5, NGX
VSX VSX 2.0.1
VSX NG AI
VSX NG AI Release 2
VSX NGX
InterSpect NGX
Connectra NGX R62
Note - NGX R65 cannot manage gateway versions NG, NG FP1, or NG FP2
Upgrading versions 4.0 and 4.1

140
In This Section
License Upgrade to NGX page 141

Upgrading Products on a SecurePlatform Operating System page 141
Reverting to Your Previous Software Version page 142
VPN-1 Express CI R57 to NGX R65 on SecurePlatform page 159
License Upgrade to NGX

Before upgrading the software, it is highly recommended to upgrade licenses for all
NG products. NGX R65 with licenses from previous versions will not function. If
details, refer to:“Upgrading Licenses for Products Prior to NGX” on page 29.”
the deployment to NGX R65. It is used to test the current VPN-1 gateway prior to
upgrading to NGX R65. The Pre-Upgrade verification tool produces a detailed
report of what should be done before performing an upgrade to NGX R65 (refer to
“Using the Pre-Upgrade Verification Tool” on page 142).”
Upgrading Products on a SecurePlatform Operating

System
Upgrading to NGX R65 over a SecurePlatform operating system requires upgrading
both the operating system and the installed software products.
To upgrade products installed on SecurePlatform, refer to Standalone VPN-1
Gateway Upgrade on SecurePlatform.
This process upgrades all the installed components (Operating System and software
packages) in a single upgrade process. No further upgrades are required.
Chapter 6 Upgrading a Standalone Deployment 141

Reverting to Your Previous Software Version

Before you perform an upgrade process you should back up your current
SecurePlatform configuration. The purpose of the back up process is to back up the
entire SecurePlatform configuration, and to restore it if necessary, for example, in
the event that the Upgrade process is unsuccessful.
Warning - For all operating systems except SecurePlatform, an NGX R65 upgrade cannot
be reverted to its previous version, once it is complete.
To back up your configuration, use the SecurePlatform snapshot and revert

commands (for additional information, refer to “SecurePlatform Backup and
Restore Commands” on page 129).”
Using the Pre-Upgrade Verification Tool

Pre-upgrade verification runs automatically (or manually if desired) during the
VPN-1 upgrade. Pre-upgrade verification performs a compatibility analysis of the
currently installed deployment and its current configuration. A detailed report is
provided, indicating the appropriate actions that should be taken before and after
the upgrade process. This tool can also be used manually.
Usage:
-t TargetVersion [-f FileName] [-w]
or
-i[-f FileName][-w]
-p Path of the installed SmartCenter server (FWDIR)
-c Currently installed version
-t Target version
-i Check originality of INSPECT files only
-f Output in file
-w Web format file
142
Where the currently installed version is one of the following:
For Release Version is:

NGX NGX_R62
NGX_R61
NGX_R60A
NGX_R60
NG NG_R55
NG_R55P
NG_R55
NG_R54
NG_FP3
NG
GX GX_2.5
VSX VSX_2.0.1
VSX_NG_AI
VSX_NG_AI_Release_2
The target version is: NGX_R65.
Note - -f redirects the standard output to a file.
Action Items Before and After the Pre-Upgrade Process

• errors - Items that must be repaired before and after performing the upgrade. If
you proceed with the upgrade while errors exist, the upgrade will fail.
• warnings - Items that you should consider repairing before and after performing
the upgrade.

Standalone VPN-1 Gateway Upgrade on a Windows Platform
Standalone VPN-1 Gateway Upgrade on a

Windows Platform
It is recommended that before you perform an upgrade process, you should back up
your current configuration, in case the upgrade process is unsuccessful. For
additional information, refer to Backing Up Your Current Deployment page 127.
be reverted to its previous version once it is complete.
To perform an upgrade on a Windows platform:

3. Agree to the EULA and verify your contract information.
For more information on contracts, “On a Windows Platform” on page 69
not the Pre-upgrade verification tool should be executed (refer to “Using the
Pre-Upgrade Verification Tool” on page 142). Pre-upgrade verification performs
a compatibility analysis of the currently installed VPN-1 gateway and of its
current configuration. A detailed report is provided, indicating appropriate
7. When prompted, reboot your VPN-1 server.
Uninstall Check Point packages on the Windows platform using the Add/Remove
applet in the Control Panel. Check Point packages need to be uninstalled in the
opposite order to which they were installed. Since CPsuite is the first package
installed, it should be the last package uninstalled.
144
Standalone VPN-1 Gateway Upgrade on SecurePlatform
Standalone VPN-1 Gateway Upgrade on

SecurePlatform
this section applies to the following gateway versions:
• R62
• R61
• R60A
• R60
• R55W
• R55
• R54
For details on upgrading SecurePlatform versions prior to R54, refer to “VPN-1
Gateway Upgrade on Pre-R54 SecurePlatform Versions” on page 151.
are required.
be reverted to its previous version once it is complete.
To perform an upgrade on a SecurePlatform server:

Note - Creating the snapshot image can take up to twenty minutes, during which time
Check Point products are stopped.

7. Accept the license agreement, and verifying your contract information.

For more information on contracts, “On SecurePlatform, Linux, and Solaris
• Upgrade
User Center.
10. Select a source for the upgrade utilities
Either download the most updated files from the Check Point website for use
146

Standalone Upgrade on UTM-1

this section applies to UTM-1.
are required.
Refer to the CheckPoint R65 SecurePlatform/SecurePlatformPro Administration Guide
for additional information.
1. Install an external CD-ROM drive to the appliance by running the following
commands:
mkdir /mnt/cdrom
modprobe usb-storage
modprobe usb-uhci
mount /dev/scd0/mnmt/cdrom

• Upgrade
148

User Center.
Open SmartUpdate and attach the new NGX licenses to the gateways.

Standalone Upgrade on UTM-1 using the WebUI
Standalone Upgrade on UTM-1 using the

WebUI
To upgrade your appliance:
1. Download an upgrade package, as directed. If you already downloaded the file,
you can skip this step.
2. Select the upgrade package file.
3. Click Upload package to appliance.
4. Click Start Upgrade.
5. Before the upgrade begins, an image is created of the system and is used to
revert to in the event the upgrade is not successful. The Save an Image before
Upgrade page, displays the image information.
Click Next.
6. In the Safe Upgrade section, select Safe upgrade to require a successful login
after the upgrade is complete. If no login takes place within the configured
amount of time, the system will revert to the saved image.
Click Next.
7. The Current Upgrade File on Appliance section displays the information of the
current upgrade.
To begin the upgrade, click Start.
150
VPN-1 Gateway Upgrade on Pre-R54 SecurePlatform Versions
VPN-1 Gateway Upgrade on Pre-R54

SecurePlatform Versions
both operating system and software products installed. The following procedure is
for gateway versions:
• NG
• NG FP2
• NG FP3
• NG FP3 Edition 2
The process described in this section will result with an upgrade of all components
(Operating System and software packages) in a single upgrade process. No further
upgrades are required.
Warning - Once an NGX R65 upgrade is complete for all operating systems except
SecurePlatform it cannot be reverted to its previous versions.
For additional information, refer to the R65 SecurePlatform/SecurePlatformPro

Administration Guide.
Upgrading pre-R54 versions requires an upgrade of the patch command.
To perform an upgrade on pre-R54 versions of SecurePlatform:
1. Insert the SecurePlatform NGX R65 CD into the CD drive.
2. Enter the Expert mode: # expert.
# mount /mnt/cdrom
6. Select SecurePlatform NGX R65 Upgrade Package (CPsupgrade_R65.tgz).


• Upgrade
User Center.
152

Standalone VPN-1 Gateway Upgrade on a Solaris Platform
Standalone VPN-1 Gateway Upgrade on a

Solaris Platform
To perform an upgrade on a Solaris Platform:
3. Enter n.
information.
5. Select upgrade.
6. Enter n.
Although the NGX R65 upgrade utilities are on the NGX R65 CD, it is
recommended to download the latest tools from the Check Point website.
9. To perform the upgrade, select Upgrade installed products.
12. Reboot.
154
Standalone VPN-1 Gateway Upgrade on a Solaris Platform
13. After you complete the upgrade process:


Standalone VPN-1 Gateway Upgrade on an IPSO Platform
Standalone VPN-1 Gateway Upgrade on an

IPSO Platform
This section describes the upgrade process on an IPSO Platform. It is
upgrade process, for example, in the event that the upgrade process is
unsuccessful. IPSO has its own back up and restore facility. For additional
information, refer to the Nokia Network Voyager Reference Guide.
If a situation arises in which a revert to your previous configuration is required refer
to “Reverting to Your Previous Deployment” on page 135 for details.
To perform a gateway upgrade on an IPSO platform:
1. From the Check Point website, download the NGX R65 upgrade package:
IPSO_Wrapper_R65.tgz
Note - For NGX R65, you must first install either IPSO 4.1 or 4.2

5. Click Apply.
You are informed that the file download and image installation may take some
time.
6. Click Apply.
A message is displayed indicating that the new image installation process has
started.
7. When you receive a Success message, click UP > UP > Manage IPSO Images.
156
9. Click Test Boot.
10. Access the CLI console to see when the Reboot is complete. Once the Reboot
is complete, go back to the Network Voyager to verify that the image was set
properly.
13. Select Commit testboot and click Apply.
15. Perform an FTP using bin mode to transfer the IPSO_Wrapper_R65.tgz package.
This command:
• Deactivates previous Check Point packages but does not delete them.
• Installs NGX R65 products but does not activate them.
• Finds the upgrade tools in $FWDIR and performs an import/export operation
to preserve the previous configuration.
Once the process is complete, a message is displayed indicating that the
process was successful.
17. Type Reboot and press Enter.
18. From a console connection, run cpconfig.
19. Select a product:
• Check Point Power for headquarters and branch offices
• Check Point UTM for medium-sized businesses
20. Select an installation type, Stand Alone or Distributed.
21. Select Enterprise SmartCenter from the selection list.
22. Specify the SmartCenter type as Primary or Secondary.
23. Add Licenses.
24. Configure an administrator name and password.

25. Configure the GUI clients and hosts which can access the SmartCenter server
using SmartConsole.
26. Configure Group Permissions.
27. Configure a pool of characters for use in cryptographic operations. Type
randomly until the progress bar is full.
28. Configure the Certificate Authority, and save the CA’s Fingerprint to a file.
29. Start the installed products.
If you opt not to start the installed products at this time, they can be started later
by running cpstart.
Note - The previous Check Point packages remain installed but deactivated. Should the
need arise, the previous packages can be activated using the Network Voyager.
30. Use SmartUpdate to obtain a valid contract.

“On IPSO” on page 81 for more information.
Uninstalling Previous Software Packages

If you are reverting to an NG or NGX version that is compatible with your current
IPSO version, deactivate the NGX R65 products, making sure to deactivate VPN-1
Power/UTM last. Then, reactivate the previous product versions.
If you are reverting to an NG version that requires an earlier IPSO version:
1. From the IPSO Image Management page in the Network Voyager, select the
earlier IPSO image and reboot.
When you revert to the earlier image, IPSO automatically reverts to using the
saved configuration set associated with that image.
2. On the Manage Packages page, confirm that the previous versions of Check
Point packages are enabled and the NGX R65 versions are disabled.
Note - On flash-based platforms, the NGX R65 packages will no longer appear in the
Manage Packages page since they were never part of the previous configuration set.
158
VPN-1 Express CI R57 to NGX R65 on SecurePlatform
VPN-1 Express CI R57 to NGX R65 on

SecurePlatform
Upgrading an existing VPN-1 Express CI R57 requires a manual process using the
upgrade_import and upgrade_export tools located on the product CD in the
relevant platform directory, or in $FWDIR\bin\upgrade_tools.
Note - This upgrade from VPN-1 Express CI R57 to NGX R65 is only supported for
SecurePlatform.
Upgrading a Standalone Deployment to R65

This section describes how to perform an advanced upgrade on a spare machine.
To perform an advanced upgrade on a spare machine:
1. Locate the upgrade_import and upgrade_export tools in the
$FWDIR\bin\upgrade_tools. (The tools are also available on the product CD.)
2. Select Export in Upgrade Options.
using the NGX R65 Export tool.
3. Select the destination path of the configuration (.tgz) file.
Wait while the database files are exported.
4. Copy the exported.tgz file.
5. Insert the NGX R65 CD.
6. Select Installation using Imported Configuration (Windows) or Advanced Upgrade
(Solaris) in the Installation Options.
This option prompts you for the location of the imported .tgz configuration
file. It then automatically installs the new software and utilizes the imported
.tgz configuration file
Warning - The configuration file (.tgz) contains your security configuration. It is highly

VPN-1 Express CI R57 to NGX R65 on SecurePlatform
160
Chapter 7
Advanced Upgrade of
SmartCenter Servers &
Standalone Gateways
In This Chapter

Migrate Your Current SmartCenter Configuration and Upgrade page 163
Migrate Your Current VPN-1 Gateway Configuration & Upgrade page 178
161
Introduction
Introduction
There are a number of reasons for performing an advanced upgrade, for example if
you need to:
• Upgrade to NGX R65 while replacing the Operating System on which the
current SmartCenter is installed.
• Upgrade to NGX R65 while migrating to a new server.
• Upgrade to NGX R65 while avoiding unnecessary risks to the production
SmartCenter server in case of failure during the upgrade process.
To avoid unnecessary risks, it is possible to migrate the current configuration of the
production SmartCenter server, to a new SmartCenter server.
162
Migrate Your Current SmartCenter Configuration and Upgrade
Migrate Your Current SmartCenter

Configuration and Upgrade
In This Section

Advanced Upgrade on a Windows Platform page 163
Advanced Upgrade on a Linux Platform page 164
Advanced Upgrade on SecurePlatform page 168
Advanced Upgrade on an IPSO Platform page 170
Advanced Upgrade on a Solaris Platform page 172
Migration to a New Machine with a Different IP Address page 176
Introduction
This section describes the advanced upgrade procedure for SmartCenter. The
advanced upgrade procedure involves two machines. The first machine is the
working production machine. The second machine is off-line, and only contains the
operating system. The SmartCenter server is freshly installed on the second
machine and the configuration of the first machine is imported.
When migrating to a new SmartCenter server, the destination server should have the
same IP configuration as the original SmartCenter server. If you are migrating to a
new machine with a different IP address, see: See “Migration to a New Machine
with a Different IP Address” on page 176.
Advanced Upgrade on a Windows Platform

To perform an advanced upgrade on a Windows platform:
1. Insert the NGX R65 CD into the production SmartCenter server.
2. Accept the license agreement and click next.
3. Under Upgrade Options, select Export.
If you opt to perform the Export procedure manually, make sure you are using
the NGX R65 Export tool. The upgrade_export tool is located on the product CD
under the windows directory.
Chapter 7 Advanced Upgrade of SmartCenter Servers & Standalone Gateways 163

4. When prompted, download the most recently updated upgrade utilities from the
Check Point website.
If this is not possible, select Use the upgrade utilities from the CD.
5. Perform the Pre-Upgrade Verification.
6. Select the destination path for the configuration (.tgz) file.
Wait until the database files are exported.
8. Insert the NGX R65 CD into the target SmartCenter server.
9. Do one of the following:
• Perform a fresh install of SmartCenter server and import the configuration
file. When prompted, select Installation using Imported Configuration. This
option prompts you for the location of the imported .tgz configuration file
and then automatically installs the new software and utilizes the imported
.tgz configuration file.
• Perform a fresh install of SmartCenter server, and manually import the
configuration file using the upgrade_import tool on the NGX R65 CD.
Advanced Upgrade on a Linux Platform

Advanced upgrade on a Linux Platform involves one of the following:
• Performing a new installation, and manually importing a previously exported
configuration, or:
• Performing a new installation and upgrade through the wrapper. The wrapper
automatically performs the install, and the upgrade_import process.
Performing a New Installation (Manually Importing the

Configuration)
To perform a new installation and manually import the configuration:
164
3. Enter n.
4. Enter y to agree to the End-user License Agreement.
5. Select the products:
• Check Point Power (for headquarters and branch offices)
• Check Point UTM (for medium-sized businesses)
6. Enter n.
7. Select New installation as the installation option.
8. Enter n.
9. From the list of products, select SmartCenter.
10. Enter n.
11. Specify the SmartCenter type to install:
• Primary SmartCenter
• Secondary SmartCenter
• Log server
12. Enter n.
14. After product installation, the Check Point Configuration Program opens. Use
the Check Point Configuration program to:
a. Add licenses: The Check Point Configuration Program only manages local
licenses on this machine. The recommended way of managing licenses is
through SmartUpdate.
b. Configure GUI clients: A list of hosts which will be able to connect to this
SmartCenter server using SmartConsole.
c. Configure group permissions: Specifies a group name.
d. Configure a pool of characters: For use in cryptographic operations. Type
e. Configure the Certificate Authority: Saves the CA’s Fingerprint to a file.
f. Start the installed products.
15. Log in again to the root account to set the new environment variables.
16. Transfer the exported configuration to the new Solaris installation, for example
through FTP.

17. Change directory to /opt/CPsuite-R65/fw1/bin/upgrade tools

Make sure that the upgrade tools in this directory are the R65 upgrade tools,
taken from the installation CD or downloaded from the Check Point website:
18. Run ./upgrade_import <name_of_exported_configuration_file.tgz>
19. Enter y to stop all Check Point services.
The license upgrade wrapper runs.
20. Enter c to continue, or q to quit.
If you choose to continue, refer to “Upgrading Licenses for Products Prior to
NGX” on page 29.
21. Wait for the message: upgrade_import finished successfully!
22. Enter y to restart Check Point Services.
Performing a New Installation

To perform a new installation and upgrade using the Wrapper:
3. Enter n.
5. Select products:
6. Enter n.
7. For the installation option, select Installation Using Imported Configuration.
8. To import a SmartCenter configuration and upgrade it, enter the path to, and
name of, the compressed file that contains the exported configuration. Enter n.
NGX” on page 29.
166

While the R65 upgrade utilities are on the NGX R65 CD, it is recommended to
download the latest tools from the Check Point website:
11. Enter n.
follow the recommendations.
13. Enter n.
14. Specify an upgrade option:
• Upgrade installed products
• Upgrade installed products and install new products
15. Enter n.
18. Reboot.
20. To start Check Point Services, run: cpstart.

Advanced Upgrade on SecurePlatform

To perform an advanced upgrade on SecurePlatform:

7. Accept the license agreement.
• Upgrade
ii. Export the SmartCenter configuration
iii. Upgrade the installation
User Center.
168

Advanced Upgrade on an IPSO Platform

Advanced upgrade involves performing a new installation and manually importing a
previously exported configuration.
To perform an advanced upgrade on an IPSO platform:
1. On the production machine, download the latest NGX R65 upgrade tools, and
transfer them to $FWDIR/bin/upgrade_tools.
(You need the latest NGX R65 upgrade tools to perform the export operation.)
2. On the production machine, run upgrade_export.
3. Transfer the resulting .tgz file to the second, off-line machine.
4. On the second, off line machine, download from the Check Point website the
NGX R65 upgrade package: IPSO_Wrapper_R65.tgz
5. From the command prompt, run:
newpkg –S –m LOCAL –n <path_to>/IPSO_Wrapper_R65.tgz>
The package and products are installed but not activated.
6. Reboot.
9. Select the installation type: Stand Alone or Distributed.
10. Select Enterprise SmartCenter from the list.
12. Add Licenses.
14. Configure the GUI clients and hosts which can access the SmartCenter server
management component.
170
18. When prompted, do not start the installed products.

19. From $FWDIR/bin/upgrade_tools, run upgrade_import.
20. Reboot.

Advanced Upgrade on a Solaris Platform

To perform an advanced upgrade on a Solaris platform:
3. Enter n.
6. Enter n.
8. Enter n.
9. From the list of products, select SmartCenter.
10. Enter n.
• Log server
12. Enter n.
172

16. Transfer the exported configuration to the new Solaris installation, for example,
using FTP.
17. Change the directory to /opt/CPsuite-R65/fw1/bin/upgrade tools.
Make sure that the upgrade tools in this directory are the R65 upgrade tools
taken from the installation CD or downloaded from the Check Point website.
NGX” on page 29.
Performing a Solaris Installation and Upgrade

To perform a new Solaris installation and upgrade using the wrapper:
3. Enter n.
5. Select products:
6. Enter n.
7. For the installation option, select Installation Using Imported Configuration.

The license upgrade wrapper runs. The license upgrade process may take some
since, as all the licenses are gathered and sent in SSL-encrypted format to the
Check Point User Center.
NGX” on page 29.
download the latest tools from the Check Point website.
11. Enter n.
13. Enter n.
15. Enter n.
18. Reboot.
174

Migration to a New Machine with a Different IP

Address
Due to the nature of licenses (which are associated with IP addresses), when
migrating your current SmartCenter configuration, verify that the destination server
has the same IP configuration as the original SmartCenter.
The following two sections explain the steps that should be performed when the
new SmartCenter has a different IP address.
Before Migrating Your Original SmartCenter Server

To prepare to migrate a SmartCenter server to a new machine:
1. On the original SmartCenter server, add rules that will allow the new
SmartCenter to access the gateways it will manage. To do this create a
SmartCenter object that represents the new SmartCenter’s IP address:
Manage > Network Objects > New… > Check Point > Host/Gateway and in the
General Properties tab select Secondary SmartCenter Server in the Check Point
Products section.
2. On the original SmartCenter server, create a security rule that allows FW1 (TCP
256), CPD (TCP 18191) services, and FW1_CPRID (TCP 18208) services to
originate from the new SmartCenter server whose destination is all available
gateways.
3. Install the new security policy on all .
4. Perform the appropriate process to migrate your original SmartCenter server.
After Migrating Your Original SmartCenter Server

To complete the process of migrating a SmartCenter server to a new machine:
1. Update the SmartCenter licenses with the new IP address. If central licenses
are used for the , they should also be updated with the new IP Address. Refer
to the Upgrading Licenses for Products Prior to NGX page 29 for additional
information.
2. Use the cpstart command to start the new SmartCenter .
3. Access the new SmartCenter using SmartDashboard.
4. On the new SmartCenter , remove the object you created to represent the new
SmartCenter ’s IP address (refer to step 1 in the previous section).
176
5. On the new SmartCenter update the primary SmartCenter object so that its IP
Address and topology match its new configuration.
On the DNS , map the SmartCenter ’s DNS to the new IP address.

Migrate Your Current VPN-1 Gateway Configuration & Upgrade
Migrate Your Current VPN-1 Gateway

Configuration & Upgrade
In This Section:
Advanced Upgrade on a Windows Platform page 178

Advanced Upgrade on a Linux Platform page 164
Advanced Upgrade on SecurePlatform page 184
Advanced Upgrade on an IPSO Platform page 170
Advanced Upgrade on a Solaris Platform page 172
This section covers the advanced upgrade procedure for VPN-1 gateways. The
advanced upgrade procedure involves two machines. The first machine is the
working production machine. The second machine is off-line, and only contains the
operating system. The SmartCenter server is freshly installed on the second
machine and the configuration of the first machine is imported.
Advanced Upgrade on a Windows Platform

To perform an advanced upgrade on a Windows platform:
1. Insert the NGX R65 CD into the production Gateway.
2. Accept the license agreement and click Next.
3. Under Upgrade Options, select Export.
using the NGX R65 Export tool. The upgrade_export tool is located on the
product CD under the Windows directory.
4. When prompted, download the most updated upgrade utilities from the Check
Point website.
If this is not possible, select Use the upgrade utilities from the CD.
5. Perform the Pre-Upgrade Verification.
6. Select the destination path for the configuration (.tgz) file.
Wait until the database files are exported.
8. Insert the NGX R65 CD into the target SmartCenter server.
178
9. Do one of the following:

• Perform a fresh install of the VPN-1 gateway, and import the configuration
file. When prompted, select Installation using Imported Configuration. This
option prompts you for the location of the imported .tgz configuration file
and then automatically installs the new software and utilizes the imported
.tgz configuration file.
• Perform a fresh install of VPN-1 gateway, and manually import the
configuration file using the upgrade_import tool on the NGX R65 CD.

Advanced Upgrade on a Linux Platform

Advanced upgrade involves either:
• Performing a new installation, and manually importing a previously exported
configuration, or:
• Performing a new installation and upgrade through the wrapper. The wrapper
automatically performs the install, and the upgrade_import process.
To perform a new installation and manually import the configuration:
3. Enter n.
• Check Point Power (for headquarters and branch offices)
• Check Point UTM (for medium-sized businesses)
6. Enter n.
8. Enter n.
9. From the list of products, select SmartCenter and VPN-1 Power/UTM
10. Enter n.
• Log server
12. Enter n.
14. After the installation is complete, the Check Point Configuration Program
opens. Use the Check Point Configuration program to:
180
16. Transfer the exported configuration to the new solaris installation, for example
through FTP.
NGX” on page 29.
To perform a new installation and upgrade using the wrapper:
3. Enter n.


6. Enter n.
7. Select Installation Using Imported Configuration, for the installation option.
NGX” on page 29.
download the latest tools from the Check Point website:
11. Enter n.
13. Enter n.
15. Enter n.
17. After the installation is complete, the Check Point Configuration Program
182

18. Reboot.

Advanced Upgrade on SecurePlatform

To perform an advanced upgrade on SecurePlatform:

7. Enter y to agree to the license agreement.
• Upgrade
User Center.
184

Advanced Upgrade on an IPSO Platform

Advanced upgrade involves performing a new installation and manually importing a
previously exported configuration.
To perform an advanced upgrade on an IPSO platform:
1. On the production machine, download the latest NGX R65 upgrade tools, and
transfer them to $FWDIR/bin/upgrade_tools.
(You need the latest NGX R65 upgrade tools to perform the export operation.)
2. On the production machine, run upgrade_export.
3. Transfer the resulting .tgz file to the second, off-line machine.
4. On the second, off line machine, download from the Check Point website the
NGX R65 upgrade package: IPSO_Wrapper_R65.tgz
5. From the command prompt, run:
newpkg –S –m LOCAL –n <path_to>/IPSO_Wrapper_R65.tgz>
The package and products are installed but not activated.
6. Reboot.
9. Select the installation type: Stand Alone.
10. Select Enterprise SmartCenter and VPN-1 Power/UTM from the selection list.
12. Add Licenses.
14. Configure the GUI clients and hosts that can access the SmartCenter server
management component.
186
18. When prompted, do not start the installed products.

19. From $FWDIR/bin/upgrade_tools, run upgrade_import.
20. Reboot.

Advanced Upgrade on a Solaris Platform

To perform an advanced upgrade on a Solaris platform:
3. Enter n.
6. Enter n.
8. Enter n.
9. From the list of products, select SmartCenter, and VPN-1 Power/UTM.
10. Enter n.
• Log server
12. Enter n.
b. Configure GUI clients: A list of hosts that will be able to connect to this
188

16. Transfer the exported configuration to the new solaris installation, for example
through FTP.
NGX” on page 29.
Performing a New Solaris Installation and Upgrade

To perform a new Solaris installation and upgrade using the wrapper:
3. Enter n.
6. Enter n.

7. To import a SmartCenter configuration and upgrade it, select Installation Using

Imported Configuration as the installation option.
8. Enter the path to, and name of, the compressed file that contains the exported
configuration. Enter n.
The license upgrade wrapper runs. The license upgrade process may take some
time while all the licenses are gathered and sent in SSL-encrypted format to
the Check Point User Center.
NGX” on page 29.
download the latest tools from the Check Point website.
11. Enter n.
13. Enter n.
15. Enter n.
17. After product installation is complete, the Check Point Configuration Program
b. Configure GUI clients: A list of hosts that will be able to connect to this
190

18. Reboot.

192
Chapter 8
Upgrading ClusterXL
Deployments
In This Chapter
License Upgrade to NGX page 194

Tools for Gateway Upgrades page 195
Planning a Cluster Upgrade page 196
Minimal Effort Upgrade on a ClusterXL Cluster page 198
Zero Downtime Upgrade on a ClusterXL Cluster page 199
Full Connectivity Upgrade on a ClusterXL Cluster page 202
193

To upgrade to NGX R65, you must first upgrade licenses for all NG products. NGX
R65 with licenses from versions previous to NGX will not function.
It is highly recommended to upgrade licenses before upgrading the software. If
additional information, refer to “Upgrading Licenses for Products Prior to NGX” on
page 29.
194
Tools for Gateway Upgrades
Tools for Gateway Upgrades

• SmartUpdate’s Upgrade All Packages Feature: This feature allows you to
upgrade all packages installed on a gateway. For IPSO and SecurePlatform, this
feature also allows you to upgrade your Operating System as a part of your
upgrade.
• SmartUpdate’s Add Package to Repository: SmartUpdate provides three tools
for adding packages to the Package Repository:
• From CD: Adds a package from the Check Point CD.
• From File: Adds a package that you have stored locally.
• From Download Center: Adds a package from the Check Point Download
Center.
• SmartUpdate’s Get Check Point Gateway Data: This tool updates SmartUpdate
with the current Check Point or OPSEC third party packages installed on a
specific gateway or throughout your entire enterprise.
Chapter 8 Upgrading ClusterXL Deployments 195

Planning a Cluster Upgrade

When upgrading ClusterXL, the following options are available to you:
• Minimal Effort Upgrade: Select this option if you have a period of time
during which network downtime is allowed. The minimal effort method is
much simpler because the clusters are upgraded as gateways and therefore
can be upgraded as individual gateways.
• Zero Downtime: Select this option if network activity is required during the
upgrade process. The zero downtime method assures both inbound and
outbound network connectivity at all time during the upgrade. There is
always at least one active member that handles traffic.
• Full Connectivity Upgrade: Choose this option if your gateway needs to
remain active and your connections must be maintained. Full Connectivity
Upgrade with Zero Down Time assures both inbound and outbound network
connectivity at all time during the upgrade. There is always at least one
active member that handles traffic and open connections are maintained
during the upgrade.
Note - Full Connectivity Upgrade is supported between minor versions only. For further
information, refer to “Full Connectivity Upgrade on a ClusterXL Cluster” on page 202 and
the NGX R65 Release Notes.
When upgrading from R55W to NGX R65, refer to NGX R65 Release Notes for
details about support of Web Intelligence and VoIP Application Intelligence features
on Load Sharing Clusters.
Permanent Kernel Global Variables

When upgrading each cluster member, verify that changes to permanent kernel
global variables are not lost (see: sk26202). For example, if “fwha_mac_magic” and
“fwha_mac_forward_magic” were set to values other than the default values, then
verify these values remain unchanged after the upgrade.
196
Ready State During Cluster Upgrade/Rollback

Operations
When cluster members of different versions are present on the same
synchronization network, cluster members of the previous version become active
while cluster members of the new (upgraded) version remain in a special state
called Ready. In this state, the cluster members with the new version do not
process any traffic destined for the cluster IP address. This behavior is the
expected behavior during the upgrade process.
To avoid such behavior during an upgrade or rollback, physically or using ifconfig,
disconnect the cluster interfaces and the synchronization network of that cluster
member before beginning.
Upgrading OPSEC Certified Third-Party Cluster

Products
• When upgrading Nokia clustering (VRRP and IP Cluster), follow either one of
the available procedures (that is, zero downtime or minimal effort).
• When upgrading other third-party clustering products, it is recommended that
you use the minimal effort procedure.
Zero downtime upgrade is not supported using the regular procedure. The third
party may supply an alternative upgrade procedure to achieve a zero downtime
upgrade.
• For a complete understanding of the upgrade procedure, refer to the third-party
vendor documentation before performing the upgrade process.

Minimal Effort Upgrade on a ClusterXL Cluster
Minimal Effort Upgrade on a ClusterXL

Cluster
If you choose to perform a Minimal Effort Upgrade, meaning you can afford to have
a period of time during which network downtime is allowed, each cluster member is
treated as an individual gateway. In other words, each cluster member can be
upgraded in the same way as you would upgrade an individual gateway member. For
additional instructions, refer to “Upgrading a Distributed Deployment” on page 85.
198
Zero Downtime Upgrade on a ClusterXL Cluster
Zero Downtime Upgrade on a ClusterXL

Cluster
Supported Modes
Zero Downtime is supported on all modes of ClusterXL, including IPSO’s IP
clustering and VRRP. For additional third-party clustering solutions, consult your
third-party solution’s guide.
To perform a zero downtime upgrade, first upgrade all but one of the cluster
members.
To upgrade all but one of the cluster members:
1. Run cphaconf set_ccp broadcast on all cluster members. This changes the
cluster control protocol to broadcast instead of multicast and ensures that
during the upgrade the new upgraded members stay in the Ready state as long
as a previous version member is active.
In previous versions, a message prompts you to reboot the cluster members in
order to fully activate the change. This message should be ignored, no reboot is
required.
2. Suppose that cluster member A is the active member, and members B and C
are standby members. In Load Sharing mode, randomly choose one of the
cluster members to upgrade last. Ensure that the previously upgraded NGX
licenses are attached to members B and C.
3. Attach the previously upgraded licenses to all cluster members (A, B and C) as
follows:
• On the SmartConsole GUI machine, open SmartUpdate, and connect to the
SmartCenter server. The updated licenses are displayed as Assigned.
• Use the Attach assigned licenses option to Attach the Assigned licenses to
the cluster members.
4. Upgrade cluster members B and C in one of the following ways:
• Using SmartUpdate
• In Place
When the upgrade of B and C is complete, reboot both of them.

5. Continue with the process according to one of the following scenarios:

• If you are upgrading from NG with Application Intelligence (R54 and
above), skip to step 6. When machines B and C are up again, change the
cluster version in SmartDashboard to NGX R65.
• If you are running SmartUpdate, skip to step 8. SmartUpdate compiles and
installs an updated policy on the new member, once it is rebooted.
6. Installing the policy:
If you are upgrading from NG with Application Intelligence (R54 and above),
install the policy on the cluster. The policy will be successfully installed on
cluster members B and C, and will fail on member A.
Be aware that policy installation on the old Check Point gateway may cut
connections for services that do not survive the policy installation.
This can be avoided by configuring the Check Point Gateway > Advanced >
Connection Persistence tab to either Keep all connections or Keep data
connections. For complete instructions, click the help button in the Connection
Persistence tab.
Note - Do not change any cluster parameters from the current policy at this time. For
example, if the cluster is running in New High Availability mode, do not change it to LS.
Changes can be made after the upgrade process is complete.
7. If you are upgrading from a previous version, perform the following steps:
a. From the Policy Installation window, clear the For Gateway Clusters, install on
all the members, if it fails do not install at all option located under the Install
on each selected Module independently option.
b. Install the security policy on the cluster.
The policy will be successfully installed on cluster members B and C, and
will fail on member A.
8. Using the cphaprob stat command (executed on a cluster member), verify that
the status of cluster member A is Active or Active Attention. The remaining
cluster members will have a Ready status. The status Active Attention is given
if member A’s synchronization interface reports that its outbound status is
down, because it is no longer communicating with other cluster members.
9. When upgrading versions prior to NGX, execute the fw ctl setsync off
command on Cluster member A.
10. Execute the cphastop command on cluster member A. Machines B and/or C
start to process traffic (depending on whether this is a Load Sharing or High
Availability configuration).
200
11. It is recommended that you do not install a new policy on the cluster until the
last member has been upgraded. If you must install a new policy, perform the
following steps:
a. Run cpstop on the old Check Point gateway.
b. Run fw ctl set int fwha_conf_immediate 1 on all new Check Point
gateways.
c. Install the policy.
Note - It is recommended that you minimize the time in which cluster members are
running different versions.
To upgrade the final cluster member:

1. Upgrade cluster member A by either:
• Using SmartUpdate
• In Place
2. Reboot cluster member A.
3. Run cphaconf set_ccp multicast followed by cphastart on all cluster
members. This returns the cluster control protocol to multicast (instead of
broadcast).
This step can be skipped if you prefer to remain working with the cluster
control protocol in the broadcast mode.

Full Connectivity Upgrade on a ClusterXL Cluster
Full Connectivity Upgrade on a ClusterXL

Cluster
ClusterXL clusters can be upgraded while at the same time maintaining full
connectivity between the cluster members.
Understanding a Full Connectivity Upgrade

The Full Connectivity Upgrade (FCU) method assures that synchronization is
possible from old to new cluster members without losing connectivity. A full
connectivity upgrade is only supported from NGX R65 to a future minor version that
specifically supports FCU.
Connections that have been opened on the old cluster member will continue to
“live” on the new cluster member.
In discussing connectivity, cluster members are divided into two categories:
• New Members (NMs): Cluster members that have already been upgraded. NMs
are in the “non-active” state.
• Old Members (OMs): Cluster members that have not yet been upgraded. These
cluster members are in an “active state” and carry all the traffic.
202
Supported Modes
FCU is supported on all modes of ClusterXL, including IPSO’s IP clustering and
VRRP. Legacy High Availability is not supported in FCU. For other third-party
support, refer to the third-party documentation.
Full Connectivity Upgrade Prerequisites

Make sure that the new member (NM) and the old member (OM) contain the same
firewall policy and product installation. During the upgrade, do not change the
policy from the last policy installed on the Check Point Gateway prior to its
upgrade. Make sure that the upgraded version is at least NGX or higher.
Full Connectivity Upgrade Limitations

• This upgrade procedure is equivalent to a failover in a cluster where both
members are of the same version. Therefore, whatever would not normally
survive failover, will not survive a Full Connectivity Upgrade. This includes:
• Security servers and services that are marked as non-synced
• Local connections
• TCP connections that are TCP streamed
• The exact same products must be installed on the OM and on the NM.
For example, it is not possible to perform an FCU from a Check Point Gateway
that has Floodgate-1 installed to a newer Check Point Gateway that does not
have Floodgate-1 installed. Verify the installed products by running the
command fw ctl conn on both cluster members.
An example output on the NM:
Registered connections modules:
No. Name Newconn Packet End Reload Dup Type Dup Handler
0: Accounting 00000000 00000000 d08ff920 00000000 Special
d08fed58
1: Authentication d0976098 00000000 00000000 00000000 Special
d0975e7c
3: NAT 00000000 00000000 d0955370 00000000 Special d0955520
4: SeqVerifier d091e670 00000000 00000000 d091e114 Special
d091e708
6: Tcpstreaming d0913da8 00000000 d09732d8 00000000 None
7: VPN 00000000 00000000 d155a8d0 00000000 Special d1553e48
Verify that the list of Check Point Gateway names is the same for both cluster
members.

• All the Gateway configuration parameters should have the same values on the
NM and the OM. The same rule applies to any other local configurations you
may have set.
For example, having the attribute block_new_conns with different values on the
NM and on the OM might cause the FCU to fail since gateway behavior cannot
be changed during the upgrade.
• A cluster that performs static NAT using the gateway’s automatic proxy ARP
feature requires special considerations: cpstop the old Check Point Gateway
right after running cphastop. Running cphastop is part of the upgrade
procedure described in “Zero Downtime Upgrade on a ClusterXL Cluster” on
page 199. Failure to do this may cause some of the connections that rely on
proxy ARP to fail and may cause other connections that rely on proxy ARP not
to open until the upgrade process completes. Note, however, that running
cpstop on the old Check Point Gateway rules out the option to rollback to the
OM while maintaining all live connections that were originally created on the
OM.
Performing a Full Connectivity Upgrade

The procedure for updating a cluster with full connectivity varies according to the
number of members in the cluster.
To upgrade a cluster with two members:
Follow the steps outlined in “Zero Downtime Upgrade on a ClusterXL Cluster” on
page 199. Before you get to step 10 on page 200 (executing cphastop), run the
following command on the upgraded member:
fw fcu <other member ip on sync network>(e.g. fw fcu 172.16.0.1).
Then continue with step 10 on page 200.
To upgrade a cluster with three or more members:
Choose one of the following two methods:
1. Upgrade the two NMs, following the steps outlined in “Zero Downtime Upgrade
on a ClusterXL Cluster” on page 199. Before you get to step 10 on page 200
(executing cphastop), run the following command on all the upgraded
members: fw fcu <other member ip on sync network> then continue with step
10 on page 200 on the single OM.
or
204
2. First upgrade only one member, following the steps outlined in “Zero Downtime
Upgrade on a ClusterXL Cluster” on page 199. Before you get to step 10 on
page 200 (executing cphastop), run the following command on all the upgraded
members: fw fcu <other member ip on sync network>. Then continue with
step 10 on page 200 on all remaining OMs.
For more than three members, divide the upgrade of your members so that the
active cluster members can handle the amount of traffic during the upgrade.
Note - cphastop can also be executed from the Cluster object in the SmartConsole. Once
cphastop is executed, do not run cpstart or cphastart again or reboot the machine.
Monitoring the Full Connectivity Upgrade

Displaying Upgrade Statistics (cphaprob fcustat)
cphaprob fcustat displays statistical information regarding the upgrade process.
Run this command on the new member. Typical output looks like this:
During FCU....................... yes
Number of connection modules..... 23
Connection module map (remote -->local)
0 --> 0 (Accounting)
1 --> 1 (Authentication)
2 --> 3 (NAT)
3 --> 4 (SeqVerifier)
4 --> 5 (SynDefender)
5 --> 6 (Tcpstreaming)
6 --> 7 (VPN)
Table id map (remote->local)..... (none or a specific list,
depending on configuration)
Table handlers ..................
78 --> 0xF98EFFD0 (sip_state)
8158 --> 0xF9872070 (connections)
Global handlers ................. none
The command output includes the following parameters:

During FCU: This should be “yes” only after running the fw fcu command and
before running cphastop on the final OM. In all other cases it should be “no”.
Number of connection modules: Safe to ignore.
Connection module map: The output reveals a translation map from the OM to the
NM. For additional information, refer to “Full Connectivity Upgrade Limitations” on
page 203.

Table id map: This shows the mapping between the gateway’s kernel table indices
on the OM and on the NM. Having a translation is not mandatory.
Table handlers: This should include a sip_state and connection table handlers. In
a VPN-1 Power/UTM configuration, a VPN handler should also be included.
Global handlers: Reserved for future use.
Display the Connections Table (fw tab -t connections -u [-s])

This command displays the “connection” table. If everything was synchronized
correctly the number of entries in this table and the content itself should be
approximately the same in the old and new cluster members. This is an
approximation because between the time that you run the command on the old and
new members new connections may have been created or perhaps old connections
were deleted.
Note - Not all connections are synchronized. For example, local connections and services
that are marked as non-synched.
Options
-t - table
-u - unlimited entries
-s - (optional) summary of the number of connections
For further information on the fw tab -t connections command, refer to the
“Command Line Interface” Book.
Making Adjustments After Checking the Connection Table

It is safe to run the fw fcu command more than once. Be sure to run both cpstop
and cpstart on the NM before re-running the fw fcu command. The reason for
running cpstop and cpstart is that the table handlers that deal with the upgrade
are only created during policy installation (cpstart installs policy).
206
Chapter 9
Upgrading Provider-1
In This Chapter

Provider-1/SiteManager-1 Upgrade Tools page 210
Provider-1/SiteManager-1 License Upgrade page 220
Provider-1/SiteManager-1 Upgrade Practices page 251
Upgrading a Multi-MDS System page 262
Restarting CMAs page 265
Restoring Your Original Environment page 266
Renaming Customers page 267
Changing the MDS IP Address and External Interface page 271
SmartDefense in Provider-1 page 272
207
Introduction
Introduction
This chapter describes methods and utilities for upgradingProvider-1/SiteManager-1
to R65.
In This Section
Supported Versions and Platforms page 208

Provider-1/SiteManager-1 Terminology page 209
Before You Begin page 209
Supported Versions and Platforms

The direct upgrade of the MDS to NGX R65 is supported from the following
versions:
Release Version
NG VPN-1 Pro NG R55W
The following versions need to be upgraded to a more recent version before they
can be upgraded to NGX R65:
• NG FP3 HF2: If you have NG FP3 Edition 1, NG FP3 Edition 2, NG FP3
Edition 3 or NG FP3 HF1, first install the Provider-1/SiteManager-1 NG FP3
HF2 Hotfix or the Hotfix Accumulator Build (HFA).
• NG FP2: Upgrade to FP3 or above in order to upgrade to R65.
• NG FP1 HF1: Upgrade to FP3 or above in order to upgrade to R65.
The latest information regarding supported platforms is always available in the
Check Point Release Notes at:
http://www.checkpoint.com/support/technical/documents/index.html
208
Provider-1/SiteManager-1 Terminology
Provider-1/SiteManager-1 Terminology
Before discussing Provider-1/SiteManager-1 upgrades and licensing, it is worth
reviewing some important Provider-1/SiteManager-1 terms.
• The Multi-Domain Server (MDS) houses Provider-1 system information. It
contains details of the Provider-1 deployment, its administrators, and Customer
management information.
• The MDS has two flavors. The Manager, which runs the Provider-1 deployment,
and the Container, which holds the Customer Management Add-Ons (CMA). The
Manager and Container can be installed on the same server, or separately.
• A Customer Management Add-On (CMA) is the Provider-1 equivalent of the
SmartCenter server for a single Customer. Through the CMA, an administrator
creates Security Policies and manages the Customer modules.
Before You Begin

Before performing a Provider-1/SiteManager-1 upgrade, it is recommended that you
read:
• the latest Provider-1/SiteManager-1 release notes:
http://www.checkpoint.com/support/technical/documents/docs_prov1.html
• the latest Check Point suite release notes:
http://www.checkpoint.com/support/technical/documents/
If you are upgrading a multi-MDS environment refer, to “Upgrading a Multi-MDS System” on
page 262”.
Chapter 9 Upgrading Provider-1 209

Provider-1/SiteManager-1 Upgrade Tools
Provider-1/SiteManager-1 Upgrade Tools

This section describes the different upgrade and migrate utilities, and explains
when and how each of them is used.
In This Section
Pre-Upgrade Verifiers and Fixing Utilities page 210

Installation Script page 211
pv1_license_upgrade page 213
license_upgrade page 213
cma_migrate page 214
migrate_assist page 217
migrate_global_policies page 218
Backup and Restore page 218
Pre-Upgrade Verifiers and Fixing Utilities

Before performing the upgrade of Provider-1/SiteManager-1, Check Point verifies
the readiness of your current version for the upgrade. Provider-1/SiteManager-1
upgrade script, mds_setup, runs a list of pre-upgrade utilities. The utilities search
for well known upgrade problems that might be present in your existing installation.
The output of the utilities is also saved to a log file. Three types of messages are
generated by the pre-upgrade utilities:
• Action items before the upgrade: These include errors and warnings. Errors
have to be repaired before the upgrade. Warnings are left for the user to check
and conclude whether they should be fixed or not. In some cases, it is
suggested that fixing utilities should be run during the pre-upgrade check, but
in most cases the fixes are done manually from SmartDashboard. An example of
an error to be fixed before the upgrade is when an invalid policy name is found
in your existing installation. In this case, you must rename the policy.
• Action items after the upgrade: These include errors and warnings, which are to
be handled after the upgrade.
• Information messages: This section includes items to be noted. For example,
when a specific object type that is no longer supported is found in your
database and is converted during the upgrade process, a message indicates that
this change is going to occur.
210
Installation Script
The Provider-1/SiteManager-1 Pre-Upgrade Verifier uses Provider-1/SiteManager-1

specific verifications as well as verifications checked by SmartCenter’s Pre-Upgrade
Verification Tool. Refer to “Using the Pre-Upgrade Verification Tool” on page 91.
Installation Script
Starting from NG with Application Intelligence, use the mds_setup installation
script for MDS.
Note - When installing MDS on SecurePlatform, the installation is performed using the
SecurePlatform installer on the CD. Do not execute the mds_setup script directly. For
additional information, refer to “Provider-1/SiteManager-1 Upgrade Practices” on page 251.
To run mds_setup:
1. Mount the Provider-1 CD from the relevant subdirectory.
2. Change the directory to the mounted directory.
3. Browse to either the Solaris or Linux directory, depending on the operating
system of your MDS machine.
4. Run the installation script: ./mds_setup.
When mds_setup is executed, it first checks for an existing installation of MDS:
• If no such installation exists, mds_setup asks you to confirm a fresh
installation of MDS.
• If a previous version of MDS is detected, you are prompted to select one of
the following options (Pre-Upgrade Verification Only, Upgrade or Backup)
listed below.
5. Exit all shell sessions. Open a new shell in order for the new environment to be
set.

Installation Script
Pre-Upgrade Verification Only

Pre-Upgrade Verification Only enables you to run pre-upgrade verification without
upgrading your existing installation. No fixing utilities are executed. Use this option
at least once before you upgrade. It provides you with a full report on upgrade
issues, some of which should be handled before the upgrade. In a multi-MDS
environment, the pre-upgrade verification must be run on all MDSes (and MLMs)
before upgrading the first MDS.
Upgrade
When the upgrade option is used, mds_setup runs the Pre-Upgrade Verifier and if
no errors are found, the upgrade process proceeds. In case of errors, mds_setup
stops the installation until all the errors are fixed. In some cases, mds_setup
suggests automatically fixing the problem using a fixing utility. Fixing utilities that
affect the existing installation can also be executed from the command line. You
can choose to stop the installation and execute the fixing utility from the command
line. There are two important things to remember after changing your existing
installation:
• Verify your changes in the existing installation before you upgrade.
• Synchronize global policies. If you make changes in global policies, reassign
these global policies to customers. If you have a multi-MDS environment:
• Synchronize databases between MDSs in High Availability.
• Synchronize databases between CMAs in High Availability.
• Install the database on CLMs.
Backup
Prior to performing an upgrade, back up your MDS. The backup option from
mds_setup runs the mds_backup process (refer to mds_backup). Backup is also
used for replication of your MDS to another machine. Manual operations are
necessary if you are switching IP addresses or network interface names. For
additional information, refer to “Changing the MDS IP Address and External
Interface” on page 271.
212
pv1_license_upgrade
pv1_license_upgrade
The pv1_license_upgrade command line tool is used to perform license upgrade for
Provider-1.
Provider-1/SiteManager-1 NGX cannot function with NG licenses. It is
recommended to upgrade all Provider-1/SiteManager-1 NG licenses to NGX before
upgrading software to NGX.
When the tool is run on the MDS, upgraded licenses are obtained from the Check
Point User Center website for the MDS and for all the CMAs on the MDS. The tool
makes it simple to automatically upgrade licenses, eliminating the need to do so
manually though the User Center.
The pv1_license_upgrade tool can be found in the following locations:
• Provider-1 R65 CD at: <platform>/LicenseUpgrade/
• R65 installation at: /opt/CPmds-R65/system/license_upgrade/
• Check Point Download site at:
license_upgrade
The license_upgrade command line tool is used to perform license upgrade for a
single CMA. It is the same tool as is used to perform license upgrade in
SmartCenter environments. License upgrade is required when upgrading from
versions prior to NGX.
The license_upgrade tool can be found in the following locations:
• Provider-1 R65 CD at: <platform>/LicenseUpgrade/
• R65 installation at: /opt/CPmds-R65/system/license_upgrade/
• Check Point Download site at
tml
• The license_upgrade tool can be run either as a command line with
parameters, or in Wizard mode, which allows you to choose options from a
menu. To run the tool in Wizard mode, run: license_upgrade.

cma_migrate
Table 9-1 lists some of the more commonly used tool options.
Table 9-1 license_upgrade Tool Options
Wizard Mode Command line Meaning

Option option
[S] license_upgrade Sends existing licenses to User Center Web
simulate site to simulate the license upgrade in order
to verify that it can be performed. No actual
upgrade is done and no new licenses are
returned.
[U] license_upgrade Sends existing licenses to the User Center
upgrade Web site to perform upgrade and (by
default, in online mode) installs them on
the machine.
[C] license_upgrade Reports whether or not there are licenses on
status the machine that need to be upgraded.
By default, on a CMA, each operation is performed on the licenses in the License

Repository as well as on the licenses that belong to the local machine.
cma_migrate
This utility is used to import an existing SmartCenter server or CMA into a
Provider-1/SiteManager-1 MDS so that it will become one of its CMAs. If the
imported SmartCenter or CMA is of a version earlier than the MDS to which it is
being imported, then the Upgrade process is performed as part of the import. The
available versions are listed in “Supported Versions and Platforms” on page 208.
Bear in mind that the source and target platforms may be different. The platform of
the source management to be imported can be Solaris, Linux, Windows,
SecurePlatform or IPSO.
Before running cma_migrate, create a new customer and a new CMA. Do not start
the CMA, or the cma_migrate will fail.
Usage
cma_migrate <source management directory path> <target CMA FWDIR
directory>
214
cma_migrate
Example
cma_migrate /tmp/orig_mgmt_dir
/opt/CPmds-R65/customers/cma2/CPsuite-R60/fw1
The first argument (<source management directory path>)specifies a path on the

local MDS machine, where the data of the source management data resides. Use
migrate_assist to build this source directory or build it manually. Set the structure
under the source management directory as described in Table 9-2.
Table 9-2 Source Management Structure
directory contents
conf This directory contains the information that
resides under $FWDIR/conf of the source
management.
database This directory contains the information that
resides under $FWDIR/database of the source
management.
log This directory contains the information that
resides under $FWDIR/log of the source
management or is empty if you do not wish to
maintain the logs.
conf.cpdir This directory is required when the source
management is NG FP1 or higher. It contains
the information that resides under $CPDIR/conf
of the source management.
The second argument (<target CMA FWDIR directory>) is the FWDIR of the newly
created CMA.
Note - To run the cma_migrate utility from the MDG, right-click a CMA and select Import
Customer Management Add-on from the menu.
When running cma_migrate, pre-upgrade verification takes place. If no errors are

found, then the migration continues. If errors are found, changes must be
performed on the original SmartCenter server.
The original Certificate Authority and putkey information is maintained when using
cma_migrate. This means that the SmartCenter server that was migrated using
cma_migrate should not re-generate certificates to gateways and SIC should
continue to work with gateways from version NG and later. However, if the IP of the
CMA is different than that of the original management, then putkey should be

cma_migrate
repeated between the CMA and entities that connect to it using putkey information.
Use putkey -n to re-establish trust. For additional information on putkey, refer to
the Check Point Command Line Interface documentation.
If you have VPN with externally managed gateways (or Global VPN-1 Communities),
maintain the original FQDN of the management so that the CRL server location is
not changed. This is not a requirement for a VPN between Check Point internal
gateways.
The default FQDN of a CMA is its IP address, therefore if you migrated from CMA
and changed its IP address, you should change its FQDN to the new IP address by
executing:
mdsenv <CMA>, cpconfig, option 4 - Certificate Authority
If your intent is to split a CMA into two or more CMAs, reinitialize their Internal
Certificate Authority so that only one of the new CMAs employs the original ICA:
1. mdsstop_customer <CMA NAME>
2. mdsenv <CMA NAME>
3. Remove the current Internal Certificate Authority by executing the fwm
sic_reset command. This may require some preparation that is described in
detail from the command prompt and also in the Secure Knowledge solution
sk17197.
4. Create a new Internal Certificate Authority by executing:
mdsconfig -ca <CMA NAME> <CMA IP>
5. Run the command: mdsstart_customer <CMA NAME>
216
migrate_assist
migrate_assist
This utility is a helper utility for cma_migrate. It can be used to pull the original
management directories to the current disk storage using FTP.
When you finish running migrate_assist, it is possible to run cma_migrate (refer to
“cma_migrate” on page 214), the input directory of which will be the output
directory of migrate_assist.
Usage
migrate_assist <source machine name/ip> <source FWDIR folder> <user name>
<password> <target folder>[<source CPDIR folder>]
Example
To import a SmartCenter server with the IP address 192.168.0.5 of version NG
FP3, use the following command:
migrate_assist 192.168.0.5 /opt/CPfw1-53 FTP-user
FTPpass/EMC1/opt/CPshared/5.0
Where /EMC1 is the name of the directory created on the MDS server machine,
migrate_assist accesses the source machine and imports the source FWDIR and
CPDIR folders to the specified target folder according to the structure described
above. The user name and password are needed to gain access to the remote
machine via FTP. The source CPDIR parameter is required in case the original
management is NG FP3 and higher.
Note - migrate_assist does not affect the source database, however it is highly
recommended to stop it before running migrate_assist so that no SmartConsole Clients
accidentally edit the database during migration.

migrate_global_policies
migrate_global_policies
The migrate_global_policies utility transfers (and upgrades, if necessary) a global
policies database from one MDS to another.
If the global policies database on the target MDS has polices that are assigned to
customers, migrate_global_policies aborts. This is done to ensure that the Global
Policy used at the Customer's site is not deleted.
Note - When executing the migrate_global_policies utility, the MDS will be stopped.
The CMAs can remain up and running.
Usage
migrate_global_policies <path global policies conf database>
<path global policies conf database> specifies the directory path where
the global policies files, originally taken from the MDS's $MDSDIR/conf, are
located.
Note - Migrate_global_policies fails if there is a global policy assigned to a

Customer, Do not to create and assign any Global Policy to a Customer before you run
migrate_global_policies.
Backup and Restore

The purpose of the backup/restore utility is to back up an MDS as a whole,
including all the CMAs that it maintains, and to restore it when necessary. The
restoration procedure brings the MDS to the state it was when the backup
procedure was executed. The backup saves both user data and binaries. Backup
and restore cannot be used to move the MDS installation between platforms.
Restoration can be performed on the original machine or, if your intention is to
upgrade by replicating your MDS for testing purposes, to another machine. When
performing a restoration to another machine, if the machine’s IP address or
interface has changed, refer to “Changing the MDS IP Address and External
Interface” on page 271” for instructions on how to adjust the restored MDS to the
new machine.
218
Backup and Restore
During backup, it is okay to view data but do not write using MDGs, GUIs or other
clients. If the Provider-1/SiteManager-1 system consists of several MDSes, the
backup procedure takes place manually on all the MDSes concurrently. Likewise,
when the restoration procedure takes place, it should be performed on all MDSes
concurrently.
mds_backup
This utility stores binaries and data from your MDS installation. Running
mds_backup requires super-user privileges. This utility runs the gtar command on
the root directories of data and binaries. Any extra information located under these
directories is backed up, except from files that are specified in mds_exclude.dat
($MDSDIR/conf) file. The collected information is wrapped in a single zipped tar file.
The name of the created backup file comprises the date and time of the backup,
followed by the extension .mdsbk.tgz. For example: 13Sep2002-141437.mdsbk.tgz.
The file is placed in the current working directory, thus it is important not to run
mds_backup from one of the directories that is to be backed up. For example, when
backing up an NG FP3 MDS, do not run mds_backup from /opt/CPmds-61 since you
cannot zip the directory in which you need to write.
Usage
mds_backup
mds_restore
Restores an MDS that was previously stored with mds_backup. For correct operation,
mds_restore requires a fresh installation of an MDS from the same version of the
MDS to be restored.
Usage
mds_restore <backup file>
$MDSDIR/bin/set_mds_info -b -y

Provider-1/SiteManager-1 License Upgrade
Provider-1/SiteManager-1 License Upgrade

In This Section
Overview of NGX License Upgrade page 220

Introduction to License Upgrade in Provider-1 Environments page 221
Software Subscription Requirements page 222
Understanding Provider-1/SiteManager-1 Licenses page 222
Before License Upgrade page 224
Choosing The Right License Upgrade Procedure page 229
System-Wide License Upgrade, Before Software Upgrade page 231
System-Wide License Upgrade Using the Wrapper page 235
System-Wide License Upgrade, After Software Upgrade page 236
License Upgrade for a Single CMA page 239
License Upgrade Using the User Center page 245
SmartUpdate Considerations for License Upgrade page 246
Troubleshooting License Upgrade page 246

To upgrade to R65, you must first upgrade licenses for all NG products. NGX
cannot function with NG licenses.
and accounts for which you do not have software subscription. Log in to
http://usercenter.checkpoint.com to manage your accounts, licenses, and Enterprise
Support Programs coverage (under Support Programs).
upgrades both locally and centrally managed licenses. Using the tool you can
upgrade all licenses in the entire managed system. License upgrade can also be
performed manually, per license, in the User Center.
220
Introduction to License Upgrade in Provider-1 Environments
The automatic license upgrade tool enables you to:

• View the status of the currently installed licenses. On a CMA, you can also view
the licenses in the SmartUpdate License Repository.
• Simulate the license upgrade process.
• Perform the license upgrade process.
During the license upgrade, all eligible licenses are gathered and sent in
SSL-encrypted format to the User Center. Upgraded licenses are returned from the
User Center, and automatically installed. The license upgrade process adds only
NGX licenses. Old licenses and non-eligible licenses (e.g., evaluation licenses, or
licenses that pertain to IP addresses no longer used) remain untouched.
When running on a CMA, the license upgrade process also handles licenses in the
SmartUpdate License Repository. After the software upgrade, SmartUpdate is used
to attach the new NGX licenses to the gateways.
For instructions on upgrading licenses for VPN-1 Power/UTM and SmartLSM
deployments, refer to:
• “Upgrading Licenses for Products Prior to NGX” on page 29.
• “License Upgrade for a VPN-1 Power/UTM ROBO Gateway” on page 276.
For the latest information and downloads regarding NGX license upgrade, check:
Introduction to License Upgrade in Provider-1

Environments
Provider-1/SiteManager-1 NGX cannot function with NG licenses. It is
recommended to upgrade all Provider-1/SiteManager-1 NG licenses to NGX before
upgrading the software to NGX.
The license upgrade procedure for Provider-1/SiteManager-1 uses the
pv1_license_upgrade command line tool or the MDS Wrapper (both run on the
MDS). These tools make it simple to automatically upgrade licenses without having
to do so manually through the Check Point User Center website
Licenses for versions prior to NG cannot be upgraded directly to NGX. You must
first upgrade to NG and then upgrade the licenses from NG to NGX.


The license upgrade procedure is available to purchasers of any of the Enterprise
Software Subscription services. License upgrade will fail for products and accounts
for which you do not have software subscription.
You can see exactly the products and accounts for which you have software
subscription by viewing your User Center account. In the Accounts page, Enterprise
Contract column, and in the Products page, Subscription and Support column, if the
account or product is covered, the expiration date is shown. If a product is not
covered, the entry says Join Now, with a link to get a quote for purchasing
Enterprise Support.
You can purchase Enterprise Software Subscription for the entire account, in which
case all the products in the account will be covered, or you can purchase
Enterprise Software Subscriptions for individual products.
Understanding Provider-1/SiteManager-1 Licenses

Provider-1/SiteManager-1 Licensing
The MDS Manager has:
• Licenses for the MDS itself (MDS licenses), in the cp.license file. An example
of an MDS license is one that specifies how many CMAs may be configured.
• MDS License Repository (MDS Repository). This is a mirror (that is, a read-only
copy) of the CMA license repositories. All CMA license actions are reflected in
the MDS License Repository.
The MDS Container has:
• Licenses for the MDS Container itself, in the cp.license file. This license
specifies, among other things, how many CMAs may be configured in the
Container.
• For each CMA, licenses for the CMA itself (CMA licenses), in the cp.license
file. An example of a CMA license is one that specifies how many Gateways the
CMA can manage.
• For each CMA, the CMA license repository (CMA Repository) in the licenses.C
file. This is a repository of Gateway licenses.
Licenses in the CMA Repository are managed using the SmartUpdate component of
the Multi-Domain GUI (MDG). SmartUpdate is used to connect to the MDS
Manager and manage the MDS Repository.
222
Understanding Provider-1/SiteManager-1 Licenses
License Upgrade Example

Licenses are upgraded on a per machine basis. During the license upgrade process,
all licenses on a machine are upgraded. On an MDS computer with a combined
Manager and Container, the following are upgraded:
• MDS licenses for both the manager and Container.
• For each CMA, the CMA licenses.
• For each CMA, the CMA Repository.

Before License Upgrade

The following sections describe the steps to be taken before performing the license
upgrade:
• “Finding out Whether a License Upgrade is Required” on page 224
• “Simulating the License Upgrade” on page 225
• “Provider-1 Pro Add-Ons for MDS License Upgrade” on page 225
• “Managing VPN-1 Power VSX With Provider-1” on page 226
For further assistance, refer to SecureKnowledge at
https://secureknowledge.checkpoint.com, or contact the Check Point Reseller that
provided your licenses.
Finding out Whether a License Upgrade is Required

On the MDS machine, check whether or not the MDS licenses and the licenses in
the MDS Repository need to be upgraded, without making any modifications.
To determine if a license upgrade is required:
• Do one of the following:
• Run the console command pv1_license_upgrade status. The
pv1_license_upgrade tool is located on the Provider-1 R65 CD at
<platform>/LicenseUpgrade/.
• Run the mds_setup wrapper, and then choose the pre-upgrade verification
option.
This results in the following:
• For each license, a check determines whether or not a license upgrade is
required.
• A report is produced that contains action items to be performed before and
after the upgrade, and general information. The action items can be
informational, warnings, or errors. If license upgrade is required, error
messages are generated.
It is highly recommended to deal with all the reported issues, so that the
license upgrade can proceed smoothly.
Note - If there are NGX licenses on the pre-NGX MDS machine that have not been
upgraded (for example, without an NG license pair), they are not be included in the
pv1_license_upgrade tool’s report.
224

On the MDS machine, simulate the license upgrade in order to find and solve
potential problems in upgrading specific licenses. The simulation does not make
any modifications.
To simulate the license upgrade:
• Run the console command pv1_license_upgrade simulate.
Provider-1 Pro Add-Ons for MDS License Upgrade
Note - This section only applies if the Provider-1Pro Add-Ons for MDS are installed.
License Upgrade for the Pro Add-Ons for MDS must be performed either manually
via the User Center, or via the Check Point Account Services department.
To understand this issue, some background information is needed.
Pro Add-Ons for MDS is a bundled product that extends the SMART management
capabilities of multiple CMAs by adding SmartUpdate, SmartDirectory, and
SmartView Monitor. Table 9-3 shows the part numbers of Pro Add-ons for MDS.
Table 9-3 Part Numbers of Pro Add-ons for MDS
Pro Add-ons for MDS
Customer Version Part Number
10 NG CPPR-PRO-10-NG
Generating Licenses for the CMA Pro Add-on

Licenses for the CMA Pro Add-on for MDS are generated in the User Center.
To generate licenses for the CMA Pro Add-on:
1. Perform the Activate License operation on the Pro bundled product, using the IP
address of the first CMA, to generate the license for this CMA. For each
additional CMA, perform the Change IP operation on the bundled product, and
change to the IP address of this CMA.
2. Install each generated license on its respective CMA.

3. At the end of the license generation process, the User Center shows a license
with the IP address of the last CMA for which the Change IP operation was
performed.
Upgrading CMA Pro Add-on Licenses
To upgrade the CMA Pro Add-on licenses:
1. On the MDS machine, run the appropriate console command:
• If the MDS is directly connected to the User Center, run:
pv1_license_upgrade upgrade
• If the MDS is connected to the User Center via a proxy, run:
pv1_license_upgrade upgrade -y <proxy:port> -w <user_name:pwd>
The proxy port number is optional. The username and password (if any) are
for the proxy machine.
2. Save the following information:
• Log Files generated by the tool. The location of the files is printed to the
screen when running the tool.
• The cache file generated when running the tool, $CPDIR/conf/lic_cache.C.
3. Contact Account Services at US +1 817 606 6600 (option 7) or e-mail
AccountServices@ts.checkpoint.com, and provide them with the above
information.
Managing VPN-1 Power VSX With Provider-1
Note - This section only applies if the Virtual Systems Extension - CMA Bundle is installed.
To allow Provider-1 to manage VPN-1 Power VSX, the “Virtual Systems Extension -
CMA Bundle” product is required. If the Virtual Systems Extension - CMA Bundle
is older than VSX NG AI Release 2, automatic license upgrade is not available.
License upgrade must be performed manually via the User Center, or via the Check
Point Account Services department.
To understand this issue, some background information is needed.
Customers purchase multiple CMAs to manage either one VSX Virtual System (VS)
with each CMA, or manage a VS cluster with each CMA.
The purchased part numbers are shown in Table 9-4.
226
Table 9-4 Virtual Systems Extension - CMA Bundles

Virtual Systems Extension - CMA Bundles (Primary VSX-CMA)
Gateways Version Part Number
C10 NG CPPR-VSX-CMA-C10-NG
The customer receives two licenses:

• One license for the Provider-1 MDS Container product in Table 9-5 (depending
on the number of VSs in Table 9-6). This license allows you to define the
purchased number of CMAs.
Table 9-5 Provider-1 MDS Container
Prov ide r- 1 MDS C onta ine r
C ustom e r Ve rsion Part Num be r
25 NG CPPR- MDS- C25- NG
• One license for the Provider-1 CMA product in Table 9-10 (to be installed on
the CMA), that specifies the size of the VS cluster that the CMAs are allowed to
manage. A license for a VS cluster of 1 Gateway allows the CMA to manage one
VS, A license for a VS cluster of 2 Gateways allows the CMA to manage a
cluster of two VSs, and so on.
Table 9-6 Provider-1 CMA
Provider-1 CMA (Primary CMA)
1 NG CPPR-CMA-1-NG
2 NG CPPR-CMA-2-NG
4 NG CPPR-CMA-4-NG

Generating Licenses for the Provider-1 CMA Product

Licenses for the Provider-1 CMA product are generated in the User Center.
To generate licenses for the Provider-1 CMA product:
1. Perform the Activate License operation on the Provider-1 CMA product, using
the IP address of the first CMA, to generate the license for this CMA. For each
3. When the license generation process is complete, the User Center shows a
license with the IP address of the last CMA for which the Change IP operation
was performed.
Upgrading Provider-1CMA Bundle Licenses
To upgrade the Provider-1 CMA-Bundle licenses:
The proxy port number is optional. Username and password (if any) are for
the proxy machine.
• Log Files generated by the tool. The location of these files is printed to the
information.
228
Choosing The Right License Upgrade Procedure

There are various ways to upgrade licenses in a Provider-1/SiteManager-1
environment. This section explains some of the considerations that you should take
into account before deciding which procedure is right for you.
Decision #1: License Upgrade Before or After Software

Upgrade
It is highly recommended to perform the license upgrade before performing any
software upgrade. This ensures that the software continues to function after the
software upgrade. However, if necessary, the software upgrade can be done first.
Decision #2: License Upgrade for Entire System (Single

or Multi-MDS) or Single CMA
It is possible to upgrade licenses either for the entire Provider-1/SiteManager-1
environment (all MDS licenses, CMA licenses, and CMA Repository licenses), or a
single CMA (CMA licenses and CMA Repository licenses).
Upgrading the entire Provider-1/SiteManager-1 environment is the recommended
way to upgrade licenses. The procedure uses the SmartUpdate license management
capabilities, which are free of charge.
Upgrading licenses for a single CMA may be required if you do not wish to upgrade
the licenses on other CMAs at this time, for example if the licenses for other CMAs
have already been upgraded. Note, however, that the software upgrade occurs for
all CMAs at the same time, when the MDS is upgraded.
Decision #3: License Upgrade for an Online or Offline

Machine
The license upgrade procedure depends on how the machine on which the
procedure is to be performed is connected to the Check Point User Center website.
The possibilities are:
• Direct Internet connectivity (online).
• Via-proxy Internet connectivity (online via proxy).
• No Internet connectivity (offline).
License upgrade using the mds_setup wrapper works only for online machines with
direct Internet connectivity to the Check Point User Center.

What Next?
Once you have made the above three decisions, you can then decide which of the
following procedures is the right one for you.
• “System-Wide License Upgrade, Before Software Upgrade” on page 231
• “License Upgrade for an Online MDS” on page 231
• “License Upgrade for an Offline MDS” on page 232
• “System-Wide License Upgrade Using the Wrapper” on page 235
(applies to an online MDS version NG)
• “System-Wide License Upgrade, After Software Upgrade” on page 236
• “License Upgrade for an Online MDS” on page 236
• “License Upgrade for an Offline MDS” on page 237
• “License Upgrade for a Single CMA” on page 239
• “License Upgrade for an Online MDS, Before Software Upgrade” on
page 239
• “License Upgrade for an Offline MDS, Before Software Upgrade” on
page 240
• “License Upgrade for an Online MDS, After Software Upgrade” on
page 242
• “License Upgrade for an Offline MDS, After Software Upgrade” on
page 243
230
System-Wide License Upgrade, Before Software Upgrade
System-Wide License Upgrade, Before Software

Upgrade
In This Section
License Upgrade for an Online MDS page 231

License Upgrade for an Offline MDS page 232
License Upgrade for an Online MDS

Use this procedure for an online MDS of version NG.
An online machine is one with Internet connectivity to the Check Point User Center
Web site https://usercenter.checkpoint.com.
details.
To perform the license upgrade on an online MDS:

1. Copy the pv1_license_upgrade tool to the MDS version NG machine. Copy them
from the locations specified in “pv1_license_upgrade” on page 213.
2. Run the appropriate command line tool at the MDS (On SecurePlatform, you
must be in expert mode):
the proxy machine.
This does the following:
• Collects all the licenses that exist on the MDS machine.
• Verifies that all licenses can be upgraded, both for MDS and CMAs.
• Builds a temporary cache file containing the NGX licenses.

3. Perform the software upgrade to NGX on the MDS Manager, MDS Container,
and the MDG.
4. Start the MDS by running:
mdsenv
mdsstart
5. Run the following command line tool on the MDS:
pv1_license_upgrade import -c <cache file name>
The default cache file location is $CPDIR/conf/lic_cache.C. This imports the
NGX licenses from the cache file to the CMA Repositories of every CMA.
7. Connect to the MDS using the SmartUpdate component of the MDG, and for
each CMA, delete all obsolete licenses from the NGX gateways.
License Upgrade for an Offline MDS

This procedure upgrades licenses in the entire system, and applies to an offline
MDS of version NG. An offline MDS is one with no Internet connectivity to the
Check Point User Center Web site.
details.
To perform the license upgrade on an offline MDS:

1. Copy the pv1_license_upgrade tool to the MDS version NG machine. Copy them
from the locations specified in “pv1_license_upgrade” on page 213.
2. On the offline MDS, run the following command line tool:
pv1_license_upgrade export -z <package_file>
On SecurePlatform, run the command in expert mode. The export command
packs all licenses on the machine, for all CMAs and the MDS into a single
package file.
3. Copy the package file (containing the licenses) from the offline MDS to the
online machine. The online machine does not need to be a Check
Point-installed machine.
232
4. Copy the license_upgrade tool to the online machine. The tool is located at
<platform>/LicenseUpgrade/ on the R65 CD, and in the Check Point Download
site at:
tml
5. Run the appropriate command line tool at the online machine:
• If the online machine is directly connected to the User Center, run:
license_upgrade upgrade -i <input_file> -c <cache_file>
• If the online machine is connected to the User Center via a proxy, run:
license_upgrade upgrade -y <proxy:port> -i <input_file> -c <cache_file>
Where <input_file> is the package file that is the result of step 2. This
fetches new licenses from the User Center and puts them in a cache file.
• Use the [O] Wizard mode option.
6. Specify the package file that is the result of step 2 and the requested cache
file. This fetches new licenses from the User Center and puts them in a cache
file.
7. Copy the cache file (with the new licenses) back to the offline MDS machine.
8. Start the MDS by running
mdsenv
mdsstart
9. Run following command line on the offline MDS:
pv1_license_upgrade import -c <cache_file>
The default cache file location is $CPDIR/conf/lic_cache.C. This imports the
new CMA and MDS licenses to the MDS.
and the MDG.

11. Run following command line on the upgraded offline MDS:

This imports the new licenses into the CMA license repositories on the MDS.
each CMA, delete all obsolete licenses from NGX gateways.
234
System-Wide License Upgrade Using the Wrapper
System-Wide License Upgrade Using the Wrapper

This license upgrade procedure applies to an online MDS version NG. An online
machine is one that has a direct Internet connection to the Check Point User
Center Web site.
To perform the license upgrade using the Wrapper:
1. At the MDS, run mds_setup and choose the Upgrade option.
2. The pre-upgrade verification begins.
• Note the location of the messages generated by the verification tool:
/opt/CPInstLog/verification_tools_report
• The license upgrade status on the MDS and the CMAs is checked.
• Details are published in log files as to whether or not the license upgrade is
needed for each CMA.
• If a license upgrade is required, you are given the choice to upgrade
licenses via the User Center before the software upgrade. To do so, you are
required to supply your User Center account credentials. If the online
machine is connected to the User Center via a proxy, provide the proxy
details.
• The new licenses are fetched from the User Center and installed.
3. The mds_setup wrapper then proceeds with the software upgrade.
4. Run the following command line tool on the MDS:
The default cache file is $CPDIR/conf/lic_cache.C. This imports the NGX
licenses from the cache file to the CMA Repositories of every CMA.

System-Wide License Upgrade, After Software Upgrade
System-Wide License Upgrade, After Software

Upgrade
In This Section
License Upgrade for an Online MDS page 236

License Upgrade for an Offline MDS page 237
License Upgrade for an Online MDS

This procedure is not recommended. NGX software with NG licenses will not
function.
Use this procedure for an online MDS of version NG. An online machine is one with
Internet connectivity to the Check Point User Center Web site
To perform a license upgrade for an online MDS:
and the MDG.
2. Run the following command line tool at the MDS (On SecurePlatform, you must
be in expert mode):
the proxy machine.
• Collects all the licenses that exist on the MDS machine.
• Verifies that all licenses can be upgraded, both for MDS and CMAs.
• Builds a temporary cache file containing the NGX licenses.
• Installs upgraded licenses for the MDS and CMAs.
236
3. Start the MDS by running:

mdsenv
mdsstart
4. Run the following command line tool at the MDS:
pv1_license_upgrade import -C <cache file>
License Upgrade for an Offline MDS

This procedure is not recommended. NGX software with NG licenses will not
function.
This license upgrade procedure applies to an MDS version NG, with no Internet
connectivity to the Check Point User Center Web site.
To perform a license upgrade on an offline MDS:
and the MDG.
2. On the offline MDS, run the following command line tool:
pv1_license_upgrade export -z <package_file>
On SecurePlatform, run the command in expert mode. The export command
packs all licenses on the machine, for all CMAs and the MDS into a single
package file.
3. Copy the output file package (containing the licenses) from the offline MDS to
an online machine. The online machine does not need to be a Check
4. Copy the license_upgrade tool to the online machine. The tool is located at
<platform>/LicenseUpgrade/ on the R65 CD, and in the Check Point Download
site at:
tml

5. Run the appropriate command line tool on the online machine:

• If the online machine is connected to the User Center via a proxy:
license_upgrade upgrade -y <proxy:port> -i <input_file> -c
<cache_file>
fetches new licenses from the User Center and puts them in a cache file.
• Use the [O] option of the Wizard mode, and specify the package file that is
the result of step 2, and the requested cache file. This fetches new licenses
from the User Center and puts them in a cache file.
6. Copy the cache file (with the new licenses) back to the offline MDS machine.
7. Start the MDS services by running:
mdsenv
mdsstart
8. Run the following command line on the offline MDS:
This imports the new local machine licenses to the MDS and the CMAs.
9. Restart the MDS services by running:
mdsenv
mdsstart
10. Rerun the following command line on the offline MDS:
This imports the new licenses into the CMA license repositories on the MDS.
238
License Upgrade for a Single CMA

In This Section
License Upgrade for an Online MDS, Before Software Upgrade page 239
License Upgrade for an Offline MDS, Before Software Upgrade page 240
License Upgrade for an Online MDS, After Software Upgrade page 242
License Upgrade for an Offline MDS, After Software Upgrade page 243
License Upgrade for an Online MDS, Before Software

Upgrade
Use this procedure to upgrade licenses for a single CMA on an online MDS version
NG machine. An online machine is one that has Internet connectivity to the Check
Point User Center Web site https://usercenter.checkpoint.com.
License upgrade operations occur both before and after the software upgrade. The
license upgrade for the single CMA occurs before the software upgrade. After the
software upgrade, licenses for all CMAs are imported into the NGX CMA
Repositories.
The software upgrade occurs for all CMAs at the same time, when the MDS is
upgraded.
details.
To perform a license upgrade for an online MDS, before a software upgrade:

1. Copy the pv1_license_upgrade and the license_upgrade tools to the MDS
version NG machine. Copy them from the locations specified in
“pv1_license_upgrade” on page 213 and “license_upgrade” on page 213.
2. On the MDS machine, enter the environment of the single CMA
mdsenv <cma_name>
3. Run the appropriate command line tool on the MDS:
• If the MDS machine is directly connected to the User Center, run:
license_upgrade upgrade
• If the MDS machine is connected to the User Center via a proxy, run:

license_upgrade upgrade -y <proxy:port> -w <user_name:pwd>

The proxy port number is optional. Username and password (if any) are for the
proxy machine.
OR:
Use the [U] Wizard mode option.
• Collects all the licenses that exist on the CMA.
• Installs an upgraded license for the CMA, and saves upgraded CMA
Repository licenses on the CMA.
4. Upgrade the software on the MDS.
mdsstart
6. Import new licenses of all CMAs into the NGX CMA Repositories by running:
pv1_license_upgrade import -C <cache file>
License Upgrade for an Offline MDS, Before Software

Upgrade
This procedure explains how to upgrade licenses for a single CMA on an offline
MDS version NG machine, that is, one that does not have Internet connectivity to
the Check Point User Center Web site https://usercenter.checkpoint.com.
License upgrade operations occur both before and after the software upgrade. The
license upgrade for the single CMA occurs before the software upgrade. After the
software upgrade, licenses for all CMAs are imported into the NGX CMA
Repositories.
240
To perform a license upgrade on an offline MDS, before a software upgrade:

1. Copy the license_upgrade tool to the MDS version NG machine from the
locations specified in “license_upgrade” on page 213.
2. At the MDS machine, enter the environment of the single CMA
mdsenv <cma_name>
3. Copy the licenses from this machine to a file using one of the following
methods. On SecurePlatform, run the command in expert mode:
• Run the appropriate command line tool on the offline target machine:
license_upgrade export -z <package_file>
The export command packs all licenses on the machine into a single
package file.
• Use the [U] wizard mode option.
4. Copy the output file package (containing the licenses) from the offline target
machine to any online machine. The online machine does not need to be a
Check Point-installed machine.
5. Copy the license_upgrade tool to the online machine.
<cache_file>
fetches new CMA licenses from the User Center and puts them in a cache
file.
• Use the [O] wizard mode option.
7. Specify the package file package that is the result of step 3 and the requested
cache file. This fetches new licenses from the User Center and puts them in a
cache file.
8. Copy the cache file (with the new CMA licenses) to the offline target machine.

9. Run appropriate command line tool on the offline target machine:

license_upgrade import -c <cache_file>
OR
Use the [U] wizard mode option.
10. Upgrade the software on the MDS.
mdsstart
12. Import new licenses of all CMAs into the NGX CMA Repositories. Run the
command
License Upgrade for an Online MDS, After Software Upgrade

Use this procedure if the following conditions apply:
• The MDS software (including all CMAs) is already upgraded.
• MDS licenses are already upgraded to NGX, while the single CMA licenses and
CMA Repository licenses remain to be upgraded.
• The MDS machine has Internet connectivity to the Check Point User Center
Web site https://usercenter.checkpoint.com.
To perform the license upgrade:
1. Make sure that the CMA is running. The following command shows the status of
all CMAs:
mdsstat
mdsenv <cma_name>
3. Run the appropriate command line tool on the MDS:
• If the MDS machine is directly connected to the User Center, run:
license_upgrade upgrade
• If the MDS machine is connected to the User Center via a proxy, run:
license_upgrade upgrade -y <proxy:port> -w <user_name:pwd>
242
The proxy port number is optional. Username and password (if any) are for the
proxy machine.
OR use the [U] wizard mode option.
• Collects all the licenses that exist on the CMA.
• Install new licenses on the CMA.
License Upgrade for an Offline MDS, After Software

Upgrade
This procedure assumes that:
• The MDS software (including all CMAs) is already upgraded.
• MDS licenses are already upgraded to NGX, while the single CMA licenses and
CMA Repository licenses remain to be upgraded.
• The MDS machine does not have Internet connectivity to the Check Point User
Center Web site https://usercenter.checkpoint.com.
To perform the license upgrade:
mdsenv <cma_name>
2. Copy the licenses from this machine to a file using one of the following
commands. On SecurePlatform, run the following command in expert mode.
Run the following command line tool on the offline MDS:
license_upgrade export -z <package_file>
OR use the [U] wizard mode option.
The export command packs all licenses on the machine into a single file
package.
3. Copy the output file package (containing the licenses) from the offline MDS to
any online machine. The online machine does not need to be a Check

• Copy the license_upgrade tool to the online machine. The tool is located at
<platform>/LicenseUpgrade on the R65 CD, and in the Check Point Download
site at
tml
<cache_file>
fetches new CMA licenses from the User Center and puts them in a cache file.
OR
Use the [O] wizard mode option.
Specify the output file package that is the result of step 2. This fetches new
CMA licenses from the User Center and puts them in a cache file.
5. Copy the cache file (with the new CMA licenses) to the MDS machine.
6. Run following command on the MDS machine:
mdsenv <cma_name>
7. Run following command line on the offline target machine
OR
The new CMA licenses are installed on the CMA.
8. Start the CMA services by running
mdsstart_customer <cma name>
9. Import new licenses of this CMA into the NGX CMA Repositories. Run
mdsenv <cma name>)
244
License Upgrade Using the User Center
10. Run the following command line on the offline target machine:
OR
License Upgrade Using the User Center

License upgrade can be performed manually in the User Center. For instructions,
refer to the Step by Step guide to the User Center at
https://usercenter.checkpoint.com/pub/usercenter/faq_us.html
Licenses that are manually upgraded to NGX in the User Center, and are then
manually added to the license Repository, are not be Assigned to any Gateway. The
license must be manually attached to the Gateway using SmartUpdate.

SmartUpdate Considerations for License Upgrade
SmartUpdate Considerations for License Upgrade

In SmartUpdate NG, the Licenses > Upgrade… menu item is intended for license
upgrades from version 4.1 to NG. Do not use it to upgrade NG licenses to NGX.

License upgrade is usually a smooth and easy process. There are a few predictable
cases where you may encounter some problems. Use this section to solve those
license upgrade problems.
In This Section
Provider-1 Pro Add-Ons for MDS License Upgrade page 225

Managing VPN-1 Power VSX With Provider-1 page 226
Provider-1 Pro Add-Ons for MDS License Upgrade

Symptoms
• Automatic license upgrade only succeeds for the license with the IP address of
the last CMA for which the Change IP operation was performed.
• License upgrade fails on all other licenses
• User Center Message (Error Code 118):
The IP in the license string does not match the license IP in User
Center. Perform Change IP operation in User Center or contact
Customer Advocacy at US +1 817 606 6600, option 7 or e-mail
Cause
To understand this issue, some background information is needed:
Pro Add-Ons for MDS is a bundled product that extends the SMART management
capabilities of multiple CMAs by adding SmartUpdate, SmartDirectory, and
SmartView Monitor.
246
Table 9-7 Part numbers of Pro Add-ons for MDS

Pro Add-ons for MDS
The CMA Pro Add-on licenses are generated in the User Center is as follows:
1. Perform the Activate License operation on the Pro bundled product, using the IP
address of the first CMA, to generate the license for this CMA. For each
performed.
Only this last license is upgraded by the license upgrade process.
Resolution
the proxy machine.
information.

Managing VPN-1 Power VSX With Provider-1

Symptoms
• Automatic license upgrade only succeeds for the license with the IP address of
the last CMA for which the Change IP operation was performed.
• License upgrade fails on all other licenses.
• User Center Message (Error Code 118):
The IP in the license string does not match the license IP in User
Center. Perform Change IP operation in User Center or contact
Customer Advocacy at US +1 817 606 6600, option 7 or e-mail
Cause
To understand this issue, some background information is needed:
The customer purchases multiple CMAs in order to manage either one VSX Virtual
System (VS) with each CMA, or manage a VS cluster with each CMA.
The purchased VSX part numbers are listed in Table 9-8.
Table 9-8 Virtual Systems Extension - CMA Bundles
Virtual Systems Extension - CMA Bundles (Primary VSX-CMA)
The customer receives two licenses:

One license for the Provider-1 MDS Container product in Table 9-9 (depending on
the number of VSs in Table 9-8). This license allows you to define the purchased
number of CMAs.
248
Table 9-9 Provider-1 MDS Container

Provider-1 MDS Container
25 NG CPPR-MDS-C25-NG
One license for the Provider-1 CMA product in Table 9-10 (to be installed on the
CMA), that specifies the size of the VS cluster that the CMAs are allowed to
manage. A license for a VS cluster of 1 Gateway allows the CMA to manage one VS,
A license for a VS cluster of 2 Gateways allows the CMA to manage a cluster of two
VSs, and so on.
Table 9-10 Provider-1 CMA
Provider-1 CMA (Primary CMA)
1 NG CPPR-CMA-1-NG
2 NG CPPR-CMA-2-NG
4 NG CPPR-CMA-4-NG
Provider-1 CMA product licenses are generated in the User Center is as follows:
1. Perform the Activate License operation on the Provider-1 CMA product, using
the IP address of the first CMA, to generate the license for this CMA. For each
performed.
Only this last license is upgraded by the license upgrade process.
Resolution


The proxy port number is optional. The username and password (if any) are
for the proxy machine.
3. Contact Account Services at US +1 817 606 6600, option 7 or e-mail
information.
250
Provider-1/SiteManager-1 Upgrade Practices
Provider-1/SiteManager-1 Upgrade
Practices
In This Section
In-Place Upgrade page 251

Replicate and Upgrade page 254
Gradual Upgrade to Another Machine page 255
Migrating from a Standalone Installation to CMA page 257
MDS Post Upgrade Procedures page 260
In-Place Upgrade
The in-place upgrade process takes place on the existing MDS machine. The MDS
with all CMAs are upgraded during a single upgrade process.
License upgrade is also required when upgrading from versions prior to NGX.
Provider-1/SiteManager-1 NGX cannot function with licenses from versions prior to
NGX. It is therefore highly recommended to upgrade all Provider-1/SiteManager-1
NG licenses to NGX before upgrading the software to NGX.
Note - When upgrading Provider-1 to R65, all SmartUpdate packages on the MDS
(excluding SofaWare firmware packages) are deleted from the SmartUpdate Repository.
1. Run the Pre-upgrade verification only option from mds_setup. In a multi-MDS

environment, perform this step on all MDSes (refer to “Upgrading in a
Multi-MDS Environment” on page 261 for details).
2. Make the changes required by the pre-upgrade verification, and if you have
High Availability, perform the required synchronizations.
3. Test your changes:
a. assign global policy
b. install policy
c. verify logging (through SmartView Tracker)
d. view status (through MDG or SmartView Monitor)
4. Back up your system either by selecting the backup options in mds_setup or by
running mds_backup.

In-Place Upgrade
5. Perform the license upgrade procedure prior to the MDS software upgrade as
detailed in “System-Wide License Upgrade, Before Software Upgrade” on
page 231. Follow the procedure for an online MDS or an offline MDS, as
applicable.
6. Perform the in-place upgrade.
• For Solaris and Linux, use mds_setup (for additional information, refer to
“Installation Script” on page 211).
• For SecurePlatform, run patch add cd (See “Upgrading to NGX R65 on
SecurePlatform” on page 252).
7. Perform the license upgrade procedure after the MDS software upgrade as
detailed in “System-Wide License Upgrade, Before Software Upgrade” on
page 231. Follow the procedure for an online MDS or an offline MDS, as
applicable.
8. After the upgrade completes, retest using the sub-steps in step 3 above.
Upgrading to NGX R65 on SecurePlatform

This section describes how to upgrade SecurePlatform R54 and later versions using
a CD ROM drive.
To perform an upgrade on SecurePlatform:
1. Log in to SecurePlatform (expert mode is not necessary).
2. Apply the SecurePlatform R65 upgrade package:
# patch add cd.
3. You are prompted to verify the MD5 checksum.
4. Answer the following question:
Do you want to create a backup image for automatic revert? Yes/No
If you select Yes, a Safe Upgrade is performed.
Safe Upgrade automatically takes a snapshot of the entire system so that the
entire system (operating system and installed products) can be restored if
something goes wrong during the Upgrade process (for example, hardware
incompatibility). If the Upgrade process detects a malfunction, it automatically
reverts to the Safe Upgrade image.
start the SecurePlatform operating system using the upgraded version image or
using the image prior to the Upgrade process.
252
In-Place Upgrade
Upgrading a Pre-NGX Version(on Linux 22) to NGX R65

(on RedHat Enterprise Linux 3.0)
This procedure is required if you intend to upgrade a Linux 22 platform machine —
installed with a Provider-1 version prior to NGX — to RedHat Enterprise Linux 3.0
with Provider-1 R65.
To upgrade to R65 from previous NGX versions, refer to “In-Place Upgrade” on
page 251.
To perform the upgrade:
1. For each CMA, create a backup folder that contains subfolders (as described in
Table 9-2 on page 215). These folders are used for backing up data files from
a previously installed MDS version. These folders and their content must be
accessible from the NGX machine after the operating system upgrade.
2. Create an additional folder for the global policy data by backing up all files in
$MDSDIR/conf.
3. Perform a fresh RedHat Enterprise Linux 3.0 installation.
4. Perform a fresh installation of R65 MDS on the target machine. For additional
information, refer to “Installation Script” on page 211.
5. Create customers and CMAs with the names used in the previous Provider-1
setup. Do not start the CMAs.
6. Use migrate_global_policies to import the global policies backed up in step 2
(refer to“migrate_global_policies” on page 218 for additional information).
7. Migrate all the original CMAs’ data into the newly created CMAs (from the
backup folders created in step 1), either by using Import Customer Management
Add-on from the MDG or cma_migrate (refer to “cma_migrate” on page 214) for
each CMA.

Replicate and Upgrade
Replicate and Upgrade

Choose this type of upgrade if you intend to change hardware as part of the
upgrade process or if you want to test the upgrade process first. The existing MDS
installation is copied to another machine (referred to as the target machine) by
using the mds_backup and mds_restore commands.
To perform the Replicate and Upgrade process:
1. Back up your existing MDS. This can be done by running mds_backup or by
running mds_setup and selecting the Backup option.
2. Install a fresh MDS on the target machine.
To restore your existing MDS, first install a fresh MDS on the target machine
that is the exact same version as your existing MDS.
Note - The target machine should be on an isolated network segment so that gateways
connected to the original MDS are not affected until you switch to the target machine.
3. Restore the MDS on the target machine. Copy the file created by the backup
process to the target machine and run mds_restore, or run mds_setup and
select the Restore option.
4. If your target machine and the source machine have different IP addresses,
follow the steps listed in “IP Address Change” on page 271 to adjust the
restored MDS to the new IP address. If your target machine and the source
machine have different interface names (e.g. hme0 and hme1), follow the steps
listed in “Interface Change” on page 271 to adjust the restored MDS to the
new interface name.
5. Test to confirm that the replication has been successful:
a) Start the MDS.
b) Verify that all CMAs are running and that you can connect to the MDS with
MDG and Global SmartDashboard.
c) Connect to CMAs using SmartDashboard.
6. Upgrade your MDS. Stop the MDS on the target machine and employ an
In-Place Upgrade (for additional information, refer to “In-Place Upgrade” on
page 251).
254
Gradual Upgrade to Another Machine

In a gradual upgrade, CMAs are transferred to another MDS machine of version
R65, one CMA at a time.
In a gradual upgrade, the following information is not retained:
• Provider-1/SiteManager-1 Administrators
To do: Redefine and reassign to customers after the upgrade.
• Provider-1/SiteManager-1 SmartConsole Clients
To do: Redefine and reassign to customers after the upgrade.
• Policy assignment to customers
To do: Assign policies to customers after the upgrade.
• Global Communities statuses.
To do: execute the command:
mdsenv; fwm mds rebuild_global_communities_status all
To perform a gradual upgrade:
1. Install MDS of the target version onto the target machine.
2. When the upgrade is from a version prior to NGX, refer to “System-Wide
License Upgrade, Before Software Upgrade” on page 231. Follow the procedure
for an online MDS or an offline MDS, as applicable.
3. Copy the following file to the target MDS:
$CPDIR/conf/lic_cache.C
All NGX version CMA and MDS licenses reside in cp.license, and all licenses
appear in the cache.
4. On the target MDS, create a customer and CMA but do not start the CMA.
5. Use the migrate_assist utility to copy the CMA directories and files for each
CMA from the source machine to the destination machine. For additional
information, refer to “migrate_assist” on page 217. This process transfers the
NGX licenses for both the CMA and the CMA Repository.
6. Use cma_migrate to import the CMA. For additional information, refer to
“cma_migrate” on page 214.

7. Start the CMA and run:

mdsenv
mdsstart
8. To import the licenses that were upgraded to the CMA database from the cache
file, which was copied from the NG version MDS, run:
If not all licenses were successfully upgraded on the version NG MDS, perform
the license upgrade for a single CMA, either “License Upgrade for an Online
MDS, After Software Upgrade” on page 242, or “License Upgrade for an Offline
MDS, After Software Upgrade” on page 243.
9. Use migrate_global_policies to import the global policies.
Gradual Upgrade with Global VPN Considerations

A gradual upgrade process in an MDS configuration that uses the Global VPN
Communities (GVC) is not fundamentally different from the gradual upgrade
process described above, with the following exceptions:
1. Global VPN community setup involves the Global database and the CMAs that
are managing gateways participating in the global communities. When gradually
upgrading a GVC environment, split the upgrade into two parts:
• one for all the CMAs that do not participate in the GVC
• one for CMAs that do participate with the GVC
2. If some of your CMAs have already been migrated and some have not and you
would like to use the Global Policy, make sure that it does not contain gateways
of non-existing customers. To test for non-existing customers, assign this Global
Policy to a customer. If the assignment operation fails and the error message
lists problematic gateways, you have at least one non-existing customer. If this
occurs:
a. Run the where used query from the Global SmartDashboard > Manage >
Network Objects > Actions to identify where the problematic gateway(s) are
used in the Global Policy. Review the result set, and edit or delete list items
as necessary. Make sure that no problematic gateways are in use.
b. The gateways must be disabled from global use:
i. From the MDG’s General View, right-click a gateway and select Disable
Global Use.
256
Migrating from a Standalone Installation to CMA
ii. If the globally used gateway refers to a gateway of a customer that was
not migrated, you can remove the gateway from the global database by
issuing a command line command. First, make sure that the Global
SmartDashboard is not running, and then execute the command:
mdsenv; remove_globally_used_gw <Global name of the gateway>
3. When issuing the command: migrate_global_policies where the existing
Global Policy contains Global Communities, the resulting Global Policy
contains:
• the globally used gateways from the existing database
• the globally used gateways from the migrated database
As a result of the migration, the Global Communities are overridden by the
migrated database.
4. The gradual upgrade does not restore the Global Communities statuses,
therefore, if either the existing or the migrated Global Policy contains Global
Communities, reset the statuses from the command line (with MDS live):
mdsenv; fwm mds rebuild_global_communities_status all

This section describes how to migrate the management part of a standalone
gateway to a CMA, and then manage the standalone gateway (as a module only)
from the CMA.
Note - If you want the option to later undo the separation process, back up the standalone
gateway before migrating.
Before migrating the management part of the standalone gateway to the target
CMA, some adjustments are required before the standalone is exported to the CMA:
1. Make sure that:
• FTP access is allowed from the MDS machine (on which the target CMA is
located) and the standalone machine. (This is only necessary if you plan to
use migrate_assist.)
• The target CMA is able to communicate with and install policy on all
managed modules.
2. Add an object representing the CMA (name and IP address) and define it as a
Secondary SmartCenter server.
3. Install policy on all managed gateways.

4. Delete all objects or access rules created in steps 1 and 2.

5. If the standalone gateway has VPN-1 installed:
• Clear the VPN-1 option in the Check Point Products section of the
Standalone gateway object. You may have to first remove it from the Install
On column of your rulebase (and then add it again).
• If the standalone gateway participates in a VPN-1 community, in the VPN
tab, remove it from the community and erase its certificate. Note these
changes in order to undo them after the migration.
6. Save and close SmartDashboard. Do not install policy.
7. To migrate the management part to the CMA, run:
migrate_assist <Standalone_GW_NAME><Standalone_GW_FWDIR><username>
<password><target_dir><Standalone_GW_CPDIR> command.
Note - The last parameter <Standalone_GW_CPDIR> is mandatory when running
migrate_assist on NG versions.
8. Create a new CMA on the MDS, but do not start it.
9. Migrate the exported database of the standalone gateway into the CMA. Use
cma_migrate or the import operation from the MDG, specifying as an argument
the database location you used as <target_dir> in the migrate_assist
command.
10. To configure the CMA after the migration, start the CMA. On the CMA, launch
SmartDashboard.
11. In SmartDashboard, under Network Objects, locate:
• An object with the Name and IP address of the CMA which is the primary
management object (migrated). Previous references to the standalone
management object now refer to this object.
• An object for each gateway managed previously by the standalone station
(except for the gateway on the standalone machine).
12. Edit the Primary Management Object and remove all interfaces (Network Object
> Topology > Remove).
13. Create an object representing the gateway on the standalone machine (From
New > Check Point > Gateway), and:
• Assign a Name and IP address for the gateway.
• Select the appropriate Check Point version.
• Select the appropriate Check Point Products you have installed.
258
• If the object previously belonged to a VPN-1 Community, add it back.

• Do not initialize communication.
14. Run Where Used on the primary management object and, in each location,
consider changing to the new gateway object.
15. Install the policy on all modules, except for the standalone gateway. You may
see warning messages about this module because it is not yet configured.
These messages can be safely ignored.
16. Uninstall the standalone gateway.
17. Install a gateway only on the previous standalone machine.
18. From the CMA SmartDashboard, edit the gateway object created in step 12 and
establish trust with that gateway.
19. On the same object, define the gateway's topology.
20. Install the Policy on the gateway.

MDS Post Upgrade Procedures
MDS Post Upgrade Procedures

When upgrading an MDS machine from one of the supported versions, perform the
following procedure immediately after completing the upgrade.
To perform post upgrade procedures:
1. Open a root command line on the MDS (either on a console or via ssh).
2. Set the MDS environment and stop all services by typing mdsenv;mdsstop.
3. Go to the $MDSDIR/conf/mdsdb/ directory and make a backup of the
objects_5_0.C file before it is changed. For example:
#cd $MDSDIR/conf/mdsdb/
#cp objects_5_0.C /tmp
4. Use the vi text editor to manually edit the objects_5_0.C file in the $MDSDIR/
conf/mdsdb/ directory.
5. Find the line statement :use_sites. For example:
/:use_sites
6. Edit the value and change it from true to false. For example:
:use_sites (false)
7. Save the file and exit.
8. Start the MDS services by running mdsenv;mdsstart.
260
Upgrading in a Multi-MDS Environment
Upgrading in a Multi-MDS Environment

In This Section
Pre-Upgrade Verification and Tools page 261

Upgrading a Multi-MDS System page 262
Multi-MDS environments may contain components of High Availability in MDS or at

the CMA level. It may also contain different types of MDSes: managers, containers,
or combinations of the two. In general, High Availability helps to reduce down-time
during an upgrade.
This section provides guidelines for performing an upgrade in a multi-MDS
environment. Specifically, it explains the order of upgrade and synchronization
issues.
Pre-Upgrade Verification and Tools

Run pre-upgrade verification on all MDSes before applying the upgrade to a
specific MDS by choosing the Pre-Upgrade Verification Only option from mds_setup
(for additional information, refer to “Pre-Upgrade Verifiers and Fixing Utilities” on
page 210). Start upgrading the first MDS, only after you have fixed all the errors
and reviewed all the warnings on all your MDSes.

Upgrading a Multi-MDS System

In This Section
MDS High Availability page 262

Before the Upgrade page 263
After the Upgrade page 263
CMA High Availability page 264
MDS High Availability

Communication between Multi-Domain Servers can only take place when the
Multi-Domain Servers are of the same version. In a system with a single Manager
MDS, there is a period of time when the Container MDSes are not accessible. If
more than one Manager MDS exists, follow these steps:
1. Upgrade one Manager MDS. All other containers are managed from the other
Manager MDS.
2. Upgrade all container MDSes. Each Container MDS that you upgrade is
managed from the already upgraded Manager MDS.
3. Upgrade your second Manager MDS.
Following these steps promises continuous manageability of your container MDS.
While containers do not accept SmartCenter connections, the CMAs on the
container MDSes do. This means that even if you cannot perform global operations
on the container MDS, you can still connect to the CMAs that reside on it.
Note - MLMs in a multi-MDS system need to be upgraded to the same version as the
Manager and Container MDSs.
262
Before the Upgrade

1. Perform pre-upgrade verification for all MDSes.
2. Where the MDS version is pre-NGX, perform a license upgrade. Refer to
“System-Wide License Upgrade, Before Software Upgrade” on page 231, up to
and including step 5.
Note that as an alternative to running pv1_license_upgrade upgrade on all
MDSs, you can use the cache file generated on one MDS, on other MDSs, by
copying it to the other MDSs and running
3. If the pre-upgrade verifier requires a modification to the global database, then,
after modifying the global database, all other MDSes should be synchronized.
4. If this modification affects a global policy that is assigned to customers, then
the global policy should be reassigned to the relevant customers, in order to
repair the error in the CMA databases.
5. If a modification is required at the CMA level, then if it exists after modifying
the CMA database, synchronize the mirror CMA. If the customer also has a CLM
(on MLM), install the database on the CLM to verify that the modification is
applied to the CLM as well.
Note - When synchronizing, make sure to have only one active MDS and one active CMA for
each customer. Modify the active MDS/CMA and synchronize to Standby.
After the Upgrade

Complete the License upgrade to NGX. Continue with “System-Wide License
Upgrade, Before Software Upgrade” on page 231, from step 7.
After upgrading an MDS or an MLM in a multi MDS environment, the CMA/CLM
object versions (located in the CMA database) are not updated.
In this case, when using SmartDashboard to connect to a CMA after the upgrade,
additional CMA/CLMs are displayed with the previous version.
If the CMA identifies the CLM version as earlier then the current CLM version, the
following scenario takes place:
• A complete database installation from the CMA on the CLM does not take place
and as result, IP addresses and services are not completely resolved by the
CLM.

To update the CLM/CMA objects to the most recent version, verify that all active
CMAs are up and running with valid licenses and that SmartDashboard is not
connected. At this time, the following should be run on each MDS after upgrading
all MLMs/MDSs: mdsenv
To update all CLM/CMA objects, run:
$MDSDIR/scripts/mds_fix_cmas_clms_version -c ALL
To update CLM/CMA objects that are located on a specific MLM/MDS, (in case
other MDSs were not yet upgraded) run:
$MDSDIR/scripts/mds_fix_cmas_clms_version -c ALL -n <MLM/MDS name>
After running this utility, remember to synchronize all standby CMAs/SmartCenter
backups.
CMA High Availability

CMA High Availability can help minimize the period of management downtime
during upgrade. While upgrading one of the MDS containers in the High Availability
configuration, others can be used for managing enforcement points. The CMAs
hosted on these MDSs need to be synchronized and defined as Active in order to do
so.
After successfully upgrading one of the MDS containers, its CMAs can become
Active management servers for the duration of time required to upgrade the others.
The synchronization between the two CMAs in a High Availability configuration
takes place only after MDS containers hosting both of them are upgraded. If policy
changes are made on both CMAs during the upgrade process, after the upgrade one
of the configurations overrides another and the collisions need to be resolved
manually.
After the upgrade is completed on all the MDS containers, the High Availability
status of the CMAs appears as Collision. To resolve this, every CMA High Availability
pair needs to be synchronized. During the synchronization process, changes from
one of the CMAs override the changes made to another.
To migrate CMA/SmartCenter High Availability deployment, use the migrate utility
(refer to cma_migrate page 214), where the imported database is the primary
CMA/SmartCenter Server, after verifying that it is synchronized.
Likewise, perform these steps if you want to migrate your current High Availability
environment to a CMA High Availability on a different MDS. Then, continue with a
High Availability deployment (refer to the High Availability chapter in the Check
Point Provider-1/SiteManager-1 Administration Guide).
264
Restarting CMAs
Restarting CMAs
After completing the upgrade process, CMAs should be started sequentially using
the command mdsstart -s.

Restoring Your Original Environment

In This Section
Before the Upgrade page 266

Restoring Your Original Environment page 266
Before the Upgrade

Pre-upgrade utilities are an integral part of the upgrade process. In some cases,
you are required to change your database before the actual upgrade can take place
or the Pre-Upgrade Verifier suggests you execute utilities that perform the required
changes automatically. Even if you decide to restore your original environment,
keep the changes you made as a result of the pre-upgrade verification.
Prepare a backup of your current configuration using the mds_backup utility from
the currently installed version. Prepare a backup as the first step of the upgrade
process and prepare a second backup right after the Pre-Upgrade Verifier
successfully completes with no further suggestions.

To restore your original environment:
1. Removing the new installation:
a. If the installation finished successfully, execute the mds_remove utility from
the new version. This restores your original environment just before the
upgrade, after the pre-upgrade verification stage.
b. If the installation stopped or failed before its completion, manually remove
the new software packages. It may be easier for you to remove all Check
Point installed packages and a perform fresh installation of the original
version.
2. Perform mds_restore using the backup file.
266
Renaming Customers
Renaming Customers
In This Section
Identifying Non-Compliant Customer Names page 267

High Availability Environment page 267
Automatic Division of Non-Compliant Names page 267
Resolving Non-Compliance page 268
Advanced Usage page 269
Previous Provider-1 versions allowed customer names or CMA names in Check Point
2000 to contain illegal characters, such as spaces and certain keyword prefixes. In
NG with Application Intelligence, all customer names must adhere to the same
restrictions as CMA names or any other network objects.
Identifying Non-Compliant Customer Names

The mds_setup utility performs several tests on the existing installation before an
upgrade takes place. One of the tests is a test for customer names compliance with
the new naming restrictions. If all customer names comply with the restrictions, no
message is displayed. When a non-compliant customer name is detected, it is
displayed on the screen, detailing the reason why the name was rejected.
High Availability Environment

In an MDS High Availability environment, non-compliance is detected on the first
MDS you upgrade. The mds_setup utility identifies non-compliant names as more
than a single MDS. Since this is non-compliant, an error message is issued.
Automatic Division of Non-Compliant Names

If the number of customers with non-compliant names is large, the translation task
may automatically divide into several sessions. By default, all the intermediate work
is saved.

Resolving Non-Compliance
Resolving Non-Compliance
During the upgrade procedure, after selecting Option 2 - Upgrade to NGX R65 on the
mds_setup menu, the resolution of compliant names is performed. The translation
prompt is only displayed if a non-compliant name is detected.
Note - Nothing is changed in the existing installation when translating customer names.
Any changes are applied only to the upgraded installation.
Translation prompt - Enter a name to replace the non-compliant name, or enter the
'-' sign to get a menu of additional options. The new name is checked for naming
restrictions compliance and is not accepted until you enter a compliant name.
Additional Options Menu Edit another name - The customer names are presented in
alphabetical order. Choose this option to edit a customer name that was already
translated, or any other customer name.
Skip this name - Choose this option if you are not sure what to do with this name
and want to come back to it later. The upgrade cannot take place until all
non-compliant customer names are translated.
Quit session and save recent translations - Choose this option if you want to save
all the work that was done in this session and resume later.
Quit session and throw away recent translations - Choose this option if you want to
abort the session and undo all the translations that you entered during this session.
Return to translation prompt - Choose this option if you want to return to the
customer name you were prompted with when you entered '-'.
Note - The pre-upgrade tool allows only non-compliant customer names to be translated.
If the session is exited before all the translations are done, the mds_setup utility
exits with an error message stating that the MDS verification failed. To return to the
tool, simply run mds_setup again and choose Option 2 - Upgrade to NGX R65.
High Availability
After completing the translations on the first MDS, copy the following files to the
other MDSes. If the MDSes are properly synchronized, no additional work is
required.
268
Advanced Usage
Files to be copied:
/var/opt/CPcustomers_translated.txt
/var/opt/CPcustomers_translated.md5
When running the tool a second time, the customer names that have already been
translated are shown before the first non-compliant name is displayed. This is also
the case when running on an additional MDS.
Advanced Usage
An advanced user may choose to directly edit the translation file,
/var/opt/CPcustomers_translated.txt. In this case, all the translations are
verified when mds_setup is run again.
Translations file format - The file is structured line-wise. Each line's meaning is
indicated by its first character. An empty line is ignored. Any line that does not
obey the syntax causes the file to be rejected with an appropriate message.
Table 9-11 Line Prefixes

Line Prefix Meaning Comment
# A comment line. May be inserted anywhere.
- Existing non-compliant Must exactly match an
name. existing non-compliant
name, otherwise it will be
rejected.
+ A translation for the If the entry does not
preceding '-' line. comply with the naming
restrictions, it is ignored.

Advanced Usage
The '-' and '+' lines must form pairs. Otherwise, the file is rejected.
If the translations file is manually modified, the mds_setup detects it and displays
the following menu:
1. Use the translations file anyway - Choose this option only if an authorized
person modified it. This option reads the file, verifies its content and uses the
translations therein.
2. Ignore the translations file and generate a new one - Choose this option to
overwrite the contents of the file.
3. Quit and leave the translations file as it is - Choose this option to exit
mds_setup and leave the translations file as is for now. Run mds_setup again
when you are sure that option 1 or option 2 is suitable.
270
Changing the MDS IP Address and External Interface
Changing the MDS IP Address and External

Interface
In This Section
IP Address Change page 271

Interface Change page 271
IP Address Change
If your target machine and the source machine have different IP addresses, follow
the steps listed below it to adjust the restored MDS to the new IP address.
To change the IP address:
1. The MDS must be stopped. Stop the MDS by running mdsstop.
2. Change the IP address in $MDSDIR/conf/LeadingIP file to the new IP address.
3. Edit the $MDSDIR/conf/mdsdb/mdss.C file. Find the MDS object that has the
source MDS IP address and change its IP address to the new IP address. Do
not change the name of the MDS.
4. Install a new license on the target MDS with the new MDS IP address.
5. For multiple MDS/MLM environments, repeat steps 1 to 4 on each MDS/MLM
for the MDS/MLM for which you changed the IP.
Interface Change
If your target machine and the source machine have different interface names (e.g.,
hme0 and hme1), follow the steps listed below to adjust the restored MDS to the new
interface name.
To change the interface:
1. Change the interface name in file $MDSDIR/conf/external.if to the new
interface name.
2. For each CMA, replace the interface name in $FWDIR/conf/vip_index.conf. For
example, if this is an NG FP3 installation and you have a CMA named cma1,
edit /opt/CPmds-53/customers/cma1/CPfw1-53/conf/vip_index.conf.

SmartDefense in Provider-1
SmartDefense in Provider-1
When upgrading to R65, the previous SmartDefense configuration of the Customer
is overridden on the first Global Policy Assign.
It is recommended to save each Customer’s Security Policy so that the settings can
be restored after upgrade. To do so, from the MDG, go to Customer Configuration
window > Assign Global Policy tab, and enable Create database version.
272
Chapter 10
Upgrading SmartLSM ROBO
Gateways
In This Chapter
Planning the ROBO Gateway Upgrade page 274

ROBO Gateway Upgrade Package to SmartUpdate Repository page 275
License Upgrade for a VPN-1 Power/UTM ROBO Gateway page 276
Upgrading a ROBO Gateway Using SmartLSM page 278
Using the Command Line Interface page 282
273
Planning the ROBO Gateway Upgrade
Planning the ROBO Gateway Upgrade

When you upgrade your SmartCenter server, it is recommended to upgrade the
ROBO gateways managed by SmartLSM so that they are compatible with the latest
features and functionalities. This chapter describes how to upgrade your ROBO
gateways.
The general workflow for upgrading ROBO gateways comprises the following steps:
1. For VPN-1 Power/UTM ROBO gateways, in SmartDashboard, define new
SmartLSM Profile objects for the new version and install the respective policies
on these objects. This Install Policy operation only compiles the policy, it does
not send it to any gateway. The compiled policy is automatically fetched later
by the relevant ROBO gateways, following their upgrade.
2. Add the upgrade package to the SmartUpdate package repository.
For additional information, refer to “ROBO Gateway Upgrade Package to
SmartUpdate Repository” on page 275.
3. For VPN-1 Power/UTM ROBO gateway versions prior to NGX, upgrade ROBO
Gateway licenses from version NG to NGX. For additional information, refer to
“License Upgrade for a VPN-1 Power/UTM ROBO Gateway” on page 276.
4. Upgrade your ROBO Gateways in one of the following ways:
• Using SmartLSM (refer to “Upgrading a ROBO Gateway Using SmartLSM”
on page 278)
• Using the SmartLSM Command Line Interface
(refer to “Upgrading a VPN-1 Power/UTM ROBO Gateway Using LSMcli” on
page 284).
When upgrading VPN-1 Power/UTM ROBO gateways, the upgrade process removes
the initial Plug & Play license from your gateway. Trying to perform a remote
upgrade on a gateway without a valid NGX license will succeed, but this gateway
will not be able to load the correct policy after the upgrade. Make sure that all
gateways have valid permanent NG and NGX licenses installed before the upgrade.
274
ROBO Gateway Upgrade Package to SmartUpdate Repository
ROBO Gateway Upgrade Package to

SmartUpdate Repository
Once you have launched SmartUpdate, add the packages needed for the upgrade to
the SmartUpdate package repository. VPN-1 UTM Edge Firmware packages are
added the same way.
For details on how to add packages to the Package Repository, refer to the
SmartUpdate chapter of the R65 SmartCenter Administration Guide.
Chapter 10 Upgrading SmartLSM ROBO Gateways 275

License Upgrade for a VPN-1 Power/UTM ROBO Gateway
License Upgrade for a VPN-1 Power/UTM

ROBO Gateway
The general workflow for upgrading ROBO gateway licenses to NGX comprises the
following steps:
1. Upgrade the licenses using any of the procedures described in “Upgrading
Licenses for Products Prior to NGX” on page 29. Upgrading SmartCenter
licenses also upgrades all ROBO Gateway licenses.
2. Upgrade the software on the ROBO Gateway, as described in “Upgrading a
ROBO Gateway Using SmartLSM” on page 278.
3. Use SmartLSM to Attach the upgraded licenses to each ROBO Gateway, one
ROBO at a time, as described in “Using SmartLSM to Attach the Upgraded
Licenses” on page 276.
Using SmartLSM to Attach the Upgraded Licenses

To attach the upgraded licenses:
1. On the SmartConsole GUI client machine, open SmartLSM.
2. For each ROBO Gateway, open the Edit VPN-1 Power/UTM ROBO Gateway window,
and select the Licenses tab. All licenses that are attached to this ROBO
gateway are shown. If the license upgrade succeeded, the window will report
that: There are un-attached licenses that are assigned to this ROBO.
3. Add those licenses that are assigned to this ROBO from the SmartLSM License
Repository to the Licenses window. You can do this by performing one of the
following two options. The first way is easier:
• Click Add these licenses to the list.
• Click Add, and then select those licenses that are assigned to this ROBO.
The added assigned licenses are shown grayed-out because they are not yet
attached.
4. Click OK to attach the Assigned Licenses to this ROBO.
The ROBO gateway now has both NG and NGX licenses. The Licenses window
shows that the NGX license is Attached, and the NG license is Obsolete,
meaning that it is no longer needed. The NG license is useful because if you
need to downgrade the Gateway version, the Gateway will keep on working.
5. Repeat from step 2 for each ROBO gateway.
276
License Upgrade on Multiple ROBO Gateways
License Upgrade on Multiple ROBO Gateways

You can use scripting to upgrade licenses on multiple ROBO gateways. For
additional information, refer to “Example: License Upgrade on Multiple ROBO
Gateways” on page 287.

Upgrading a ROBO Gateway Using SmartLSM
Upgrading a ROBO Gateway Using SmartLSM

In This Section
Upgrading a VPN-1 Power/UTM ROBO Gateway page 278

Upgrading a VPN-1 UTM Edge ROBO Gateway page 280
Upgrading a VPN-1 Power/UTM ROBO Gateway In Place page 281
Upgrading a VPN-1 Power/UTM ROBO Gateway

There are two methods for upgrading a VPN-1 Power/UTM Gateway, the Full
Upgrade and the Specific Install.
Full Upgrade
This method automatically performs all the required checks and actions for you.
When it successfully completes, the upgraded ROBO Gateway is ready for use. This
is the recommended method to upgrade VPN-1 Power/UTM ROBO Gateways.
To perform a full upgrade:
1. From SmartLSM, select the line representing the VPN-1 Power/UTM ROBO
Gateway to be upgraded.
2. Select Actions > Packages > Upgrade All Packages. This selection can also be
done through the right-click menu, or the Upgrade All Packages icon in the
toolbar.
The upgrade process begins with a verification stage, checking which version is
currently installed on the gateway and whether the required packages exist in
your Package Repository. When it completes, a Verification Details window
opens, showing you the verification results.
3. Select Change to a new Profile after upgrade, and select the appropriate new
SmartLSM Profile from the list.
4. Select Allow reboot if required.
5. Click the Continue button.
The Upgrade process begins. Its stages and completion status can be seen in
the Action Status pane, at the bottom of SmartLSM. The entire progress report
can be seen at any time by viewing the Action History (right-click on the
respective line in the Action Status pane, and select Action History).
278
Specific Installation
This method can be used to install a specific product on a ROBO Gateway.
To perform a specific installation:
gateway you want to upgrade.
2. Select Actions > Packages > Get Gateway Data to fetch information about
Packages currently installed on the VPN-1 Power/UTM ROBO gateway.
3. Select Actions > Packages > Distribute Package… or right-click menu, and
select Distribute Package…, or click the icon in the toolbar.
The Distribute Package window opens. This window displays the relevant
packages from the Package Repository that can be installed on your VPN-1
Power/UTM ROBO gateway.
4. In the Distribute Package window, select the package you want to install.
You can then select one of the following actions:
• Distribute and install packages
• Only distribute packages (install later)
• Install previously distributed packages
5. The Allow Reboot if required option should be selected only when upgrading
VPN-1. If you do not select this option, manually reboot the gateway from its
console. The gateway is rebooted after the package installation is completed.
Note - If you are doing a step-by-step upgrade, do not select Allow Reboot if required.
6. If the operating system is SecurePlatform, you can select Backup image for
automatic revert, in case the installation does not succeed.
7. The option Change to a new profile after install lets you select the SmartLSM
Profile that will be assigned to the package upon installation. When upgrading
the VPN-1 Power/UTM ROBO gateway, you must provide a suitable SmartLSM
Profile from the target version. If you are installing a package that does not
require changing the SmartLSM Profile of the VPN-1 Power/UTM ROBO
gateway, this field remains disabled.
8. Click the Start button.

Upgrading a VPN-1 UTM Edge ROBO Gateway
9. The Install process begins. Its stages and completion status can be seen in the
Action Status pane, at the bottom of SmartLSM. The whole progress report can
be seen at any time by viewing the Action History (right-click on the respective
line in the Action Status pane, and select Action History).
Note - You can verify if the installation will succeed before actually upgrading the ROBO
Gateway by choosing Actions > Packages > Verify Installation.
Upgrading a VPN-1 UTM Edge ROBO Gateway

To upgrade the gateway:
1. From SmartLSM, select the line representing the VPN-1 UTM Edge ROBO
gateway you want to upgrade, and choose Edit > Edit ROBO gateway… This
selection can also be done through the right-click menu, or the Edit ROBO
gateway icon in the toolbar, or by double-clicking the ROBO line.
2. Select the Firmware tab.
3. Select the Use the following firmware option, select the desired firmware from
the list, and click OK. The VPN-1 UTM Edge ROBO gateway fetches and installs
the new firmware the next time it automatically checks for updates. In order for
the firmware upgrade to take effect immediately, restart the ROBO Gateway by
selecting Actions > Restart gateway.
280
Upgrading a VPN-1 Power/UTM ROBO Gateway In Place
Upgrading a VPN-1 Power/UTM ROBO Gateway In

Place
You can upgrade a ROBO gateway In Place (from the ROBO gateway's console), just
like an In Place upgrade of a regular gateway. Following the upgrade, update the
new version on the SmartLSM side, and select a new SmartLSM Profile for the
gateway.
To upgrade a gateway In Place:
gateway you just upgraded, and select Edit > Edit ROBO gateway… or right-click
the Edit ROBO gateway icon in the toolbar, or double-click the ROBO line. The
Edit window opens in the General tab.
2. From the Version menu, select the new version of the upgraded gateway.
3. From the Profile menu, select a new SmartLSM Profile for the upgraded
gateway.
4. Click OK to close the window.
5. The policy and properties of the new SmartLSM Profile are applied on the
ROBO Gateway the next time it automatically checks for updates. In order for
the SmartLSM Profile change to take effect immediately, restart the ROBO
Gateway by selecting Actions > Restart Gateway.

Using the Command Line Interface
Using the Command Line Interface

In This Section
SmartLSM Upgrade Tools page 282

Upgrading a VPN-1 Power/UTM ROBO Gateway Using LSMcli page 284
Upgrading a VPN-1 UTM Edge ROBO Gateway Using LSMcli page 285
Using the LSMcli in Scripts page 286
SmartLSM Upgrade Tools

LSMcli
The LSM Command Line Interface (LSMcli) is an alternative to SmartLSM. LSMcli
provides the ability to perform SmartLSM operations from a command line or through
a script. It also enables you to upgrade a ROBO Gateway. When used in scripts it
allows you to perform batch upgrades.
The LSMcli tool is contained in the SmartCenter installation package on the
SmartCenter server machine. It can be run on your SmartCenter server, or it can be
copied to and run on another host with the same operating system. The host does
not need to be a Check Point-installed machine, but it must be:
• Defined on the SmartCenter server as a GUI Client.
• Use the same Operating System as the SmartCenter server.
• Reachable through the network from the SmartCenter server.
For general usage and help, type the command LSMcli --help.
282
SmartLSM Upgrade Tools
The LSMcli command line arguments are fully described in the Command Line
Reference chapter of the R65 SmartLSM Administration Guide. A partial list of
arguments is shown in Table 10-1, which lists only the arguments that are
important for performing upgrades.
Table 10-1 LSMcli Command line arguments for upgrades

Argument Meaning
-d (Optional) Run the command with debug output.
Server The IP or hostname of the SmartCenter server.
User The username and password of a SmartCenter Administrator.
Password
ROBO The name of the ROBO Gateway to be upgraded.
-F Firmware The firmware version of the VPN-1 UTM Edge ROBO
Gateway.
-P=Profile (Optional) The SmartLSM Profile name the ROBO Gateway
will be mapped to after a successful upgrade.
You must specify the new SmartLSM Profile when upgrading
the VPN-1 version. This is not necessary when installing
Hotfixes or other packages.
-boot (Optional) Use this option only when upgrading VPN-1. If
you do not use this option, manually reboot the gateway from
its console.
-DoNotDistribute (Optional) Install previously distributed packages.
Product To view the list of packages available in the repository, use
Vendor the ShowRepository LSMcli command.
Version
SP (Command usage is described in the R65 SmartLSM
Administration Guide).
Export
The export tool is located in your SmartLSM application, under File > Export to File.
Use this tool to export a ROBO Gateway’s properties into a text file that you can
turn into a script in order to perform batch upgrades.

Upgrading a VPN-1 Power/UTM ROBO Gateway Using LSMcli

Using LSMcli
For descriptions of the command line arguments for the following commands, refer
to Table 10-1 on page 283.
To verify that a Full Upgrade of a ROBO Gateway will succeed, execute:
LSMcli [-d] <Server> <User> <Password> VerifyUpgrade <ROBO>
To perform a Full Upgrade of a ROBO gateway, execute:

LSMcli [-d] <Server> <User> <Password> Upgrade <ROBO> [-P=Profile]
[-boot]
To see which product packages are available in your package repository, execute:
LSMcli [-d] <Server> <User> <Password> ShowRepository
To verify that a Specific Install on a ROBO gateway will succeed, execute:

LSMcli [-d] <Server> <User> <Password> VerifyInstall <ROBO>
<Product> <Vendor> <Version> <SP>
To perform a Specific Install on a ROBO gateway, execute:

LSMcli [-d] <Server> <User> <Password> Install <ROBO> <Product>
<Vendor> <Version> <SP> [-P=Profile] [-boot] [-DoNotDistribute]
To only distribute a package, execute:

LSMcli [-d] <Server> <User> <Password> Distribute <ROBO> <Product>
<Vendor> <Version> <SP>
To view a list of packages that can be installed on a specific ROBO gateway,

execute:
LSMcli [-d] <Server> <User> <Password> GetCandidates <ROBO>
To get data about a specific ROBO gateway, execute:

LSMcli [-d] <Server> <User> <Password> GetInfo <ROBO>
Note - It is recommended to use the Full Upgrade method to upgrade VPN-1 Power/UTM
ROBO Gateways.
284
Upgrading a VPN-1 UTM Edge ROBO Gateway Using LSMcli
Example: Upgrading a Single VPN-1 Power/UTM ROBO

Gateway
% LSMcli MyServer John mypassword VerifyUpgrade ROBO17
% LSMcli MyServer John mypassword Upgrade ROBO17 -P=MyNewProfile
Where:
MyServer = the name of my SmartCenter server.
John = the administrator’s name.
mypassword = the administrator’s password.
VerifyUpgrade = the Full Upgrade verification command.
Upgrade = the Full Upgrade command.
ROBO17 = the VPN-1 Power/UTM ROBO Gateway to be upgraded.
MyNewProfile = the new SmartLSM Profile that ROBO17 will be mapped to after
the upgrade.
Upgrading a VPN-1 UTM Edge ROBO Gateway Using

LSMcli
For descriptions of the command line arguments for the following commands, refer
to Table 10-1 on page 283.
To see which product packages are available in your package repository, execute:
LSMcli [-d] <Server> <User> <Password> ShowRepository
To upgrade a VPN-1 UTM Edge ROBO gateway, execute:

LSMcli [-d] <Server> <User> <Password> ModifyROBO VPN1Edge <ROBO>
[-P=Profile] [-F=Firmwarename]
If you want the firmware update to take effect immediately, execute:

LSMcli [-d] <Server> <User> <Password> Restart <ROBO>

Using the LSMcli in Scripts
Example: Upgrading a Single VPN-1 UTM Edge ROBO

Gateway
% LSMcli MyServer John mypassword ModifyROBO VPN1Edge
ROBO101-P=EdgeNewProfile -F=4.0.23
% LSMcli MyServer John mypassword Restart ROBO101
Where:
MyServer = the name of my SmartCenter server.
John = the administrator's name.
mypassword = the administrator's password.
ModifyROBO VPN1Edge = the command to modify a property on a VPN-1 UTM
Edge ROBO gateway.
ROBO101 = the Edge ROBO Gateway to be upgraded.
EdgeNewProfile = the new SmartLSM Profile that ROBO101 will be mapped to
after the upgrade (optional).
4.0.23 = the name of the new Firmware package.
Restart = the command to restart the gateway.

Scripting can be very handy when you want to upgrade multiple ROBO Gateways in
batches.
Example: Using the LSM CLI to write a script to

upgrade multiple ROBO Gateways
Create the following script and run it:
LSMcli MyServer John mypassword Upgrade ROBO17 -P=MyNewProfile
LSMcli MyServer John mypassword Upgrade ROBO18 -P=MyNewProfile
LSMcli MyServer John mypassword Upgrade ROBO19 -P=MyOtherProfile
286
Example: License Upgrade on Multiple ROBO Gateways

To upgrade licenses on multiple ROBO Gateways, create a script that runs the
LSMcli command with the AttachAssignedLicenses option on all ROBO Gateways.
The AttachAssignedLicenses option is equivalent to doing step 3 and step 4 on
page 276 in SmartLSM.
The command is:
LSMcli [-d] <Server> <User> <Password> AttachAssignedLicenses VPN1
<ROBO>
For example:
LSMcli MyServer John mypassword AttachAssignedLicenses VPN1 ROBO17

288
Chapter 11
Upgrading Eventia
In This Chapter
Overview page 290

Upgrading Eventia Reporter page 290
Upgrading Eventia Analyzer page 296
289
Overview
Overview
Eventia Reporter of version R56 and higher can be upgraded to R65.
Eventia Analyzer of version 1.0 and higher can be upgraded to R65.
Upgrading Eventia Reporter

For Standalone Deployments
A Standalone Deployment upgrade refers to a previous Eventia Reporter version
that is installed on a SmartCenter Server.
To upgrade Eventia Reporter in a Standalone Deployment perform the following
steps:
In This Section
Windows Platform page 290

Solaris / Linux Platform page 291
SecurePlatform page 291
Windows Platform
1. In order to begin the installation, login as an administrator and launch the
wrapper by double-clicking on the setup executable.
2. Agree to the License Agreement and click Forward.
3. Select Upgrade and click Forward.
4. Continue following the instructions.
The instructions that appear will differ according to your deployment.
5. Indicate whether to add new products by selecting the Add new products option
and click Forward.
A list of the products that will be upgraded appears. Click Forward.
Depending on the components that you have chosen to install, you may need to
take additional steps (such as installing other components and/or license
management).
290
For Distributed Deployments
6. Verify the default directory, or browse to new location in which Eventia Reporter
will be installed.
7. Verify the default directory, or browse to new location in which the output files
created by Eventia Reporter’s output will be generated.
Click Next and reboot the machine in order to complete the installation of the
Eventia Reporter and to continue with the next phase of the installation.
8. Launch SmartDashboard.
9. Install the Security Policy, (Policy > Install) or install the database (Policy >
Install Database) in order to make the Eventia Reporter fully functional.
Solaris / Linux Platform

1. In order to begin the installation, mount the CD on the relevant subdirectory
and launch the wrapper as follows:
2. In the mounted directory, run the script: UnixInstallScript.
3. Read the End-User License Agreement (EULA) and if you accept click Yes.
4. Continue from step 3 on page 290 in order to complete the process.
SecurePlatform
1. After you install SecurePlatform from the CD, select the Eventia Reporter
product from cpconfig or from the SecurePlatform Web GUI.
2. Continue from step 3 on page 290 in order to complete the process.

A Distributed Deployment upgrade refers to a previous Eventia Reporter version that
is installed on a dedicated machine and an Eventia Reporter Add-on installed on a
SmartCenter Server or MDS (for versions prior to R63).
To upgrade Eventia Reporter in a distributed deployment, install NGX R65 on the
old Reporter Server and migrate the previous add-on from the SmartCenter Server
to the Reporter Server.
Upgrade Eventia Reporter to the new NGX R65

1. Before upgrading, open the Eventia Reporter client.
Chapter 11 Upgrading Eventia 291

2. Go to Management > Consolidation > Sessions and stop all consolidations

sessions by selecting Stop > Terminate. Verify that all the consolidation sessions
have a Stopped status before closing Eventia Reporter.
3. Run cpstop and wait till the mysql and log_consolidator processes stop.
4. Install NGX R65 on the previous Reporter Server.
Migrate the Add-on to the Eventia Reporter Server

To upgrade from versions prior to R63, export and import Add-On.
Prior Eventia Reporter Add-on version that contain Eventia Reporter definitions and
statuses should be copied to the machine on which Eventia Reporter is installed.
To migrate the add-on to the Eventia Server:
1. Run cpstop on both the target machine (Eventia Reporter) and the original
machine (the Add-on machine).
2. Copy the script evr_addon_export from the directory $RTDIR/conf in the R65
Eventia Reporter Server to the SmartCenter or MDS Server.
3. Invoke evr_addon_export on the SmartCenter or MDS Server.
This generates a file called evr_addon_tables.tgz in the same location as
evr_addon_export.
4. Copy evr_addon_tables.tgz to the $RTDIR/bin directory on the target R65
Eventia Reporter Server.
5. On the Eventia Reporter Server run svr_install --import
evr_addon_tables.tgz.
6. Run cpstart on both the target and original machine.
7. Open the Eventia Reporter client and start the Consolidation Sessions if
needed.
Note - After upgrading Eventia Reporter, the GUI client must be defined on the Eventia
Reporter Server. To do this run cpconfig and select GUI Clients.
Note - After upgrading Eventia Reporter in a Provider-1 environment you should select a
customer(s) that will initiate a synchronization with the CMA of the selected customer. To
do this select Tools > Customer Activation in the Eventia Reporter client, select the relevant
customers and click OK.
292
Advanced Eventia Reporter Upgrade
Advanced Eventia Reporter Upgrade

To perform a full export that includes all of the Eventia Reporter data:
1. On the original (SmartCenter) machine, run cpstop.
2. Back up the database data. The location of the database data files is specified
in the mysql configuration file my.ini (Windows) or my.cnf (all other
platforms). The mysql configuration file is located in the directory
$RTDIR/Database/conf/.
3. With a text editor, open the mysql configuration file. Locate the lines:
• datadir=
• innodb_log_group_home_dir=
• innodb_data_file_path=
Copy the directory paths pointed to by these entries. For example, the default
entries for a Windows installation are:
[mysqld]
datadir="C:/Program
Files/CheckPoint/EventiaReporter/R60/ReportingServer/Database/data"
innodb_log_group_home_dir="C:/Program
Files/CheckPoint/EventiaReporter/R60/ReportingServer/Database/log"
innodb_data_file_path = ibdata1:10M:autoextend:max:40G
The third entry, innodb_data_file_path, records database files that were added
or moved to absolute locations (for example, if the command
UpdateMySQLConfig -A or UpdateMySQLConfig -M has been applied). These files
should be copied as well.
Make sure to copy the database data files to a location that is accessible from
the target machine, and when copying directories, include their
sub-directories.
4. Back up any company logo image file(s) in $RTDIR/bin.
5. Back up any custom distribution scripts in $RTDIR/DistributionScripts.
6. Run the CD wrapper and perform the Export operation.
7. On the target machine, run the Advanced Upgrade procedure.
8. Run cpstop.
9. Delete the content of the target directories datadir and
innodb_log_group_home_dir.

Enabling Eventia Analyzer after Upgrading Reporter
10. Copy the database files from the backup to the target machine.
11. If the original SmartCenter server is of a version prior to NGX R65, the
database needs to be upgraded.
To upgrade the database:
a. Open a console and cd to the installation directory bin.
For Windows, the default location is C:\Program
Files\CheckPoint\EventiaSuite\R65\bin
For other platforms, the default location is /opt/CPrt-R65/svr/bin
b. Run the following script:
• For Windows: evr_upgrade_db
• For other platforms: ./evr_upgrade_db
12. If necessary, modify the following fields in the mysql configuration file to match
the locations of the database data files:
• datadir=
• innodb_log_group_home_dir=
• innodb_data_file_path=
The locations were copied in step 3.
Note - Make sure that the paths are written in Unix format, with a forward (/) slash between
directories
13. Copy your company logo image file(s) to $RTDIR/bin.

14. Copy your distribution scripts to the directory $RTDIR/DistributionScripts. (Be
sure to verify that the script is supported in the platform to which you are
migrating.)
15. Run cpstart.
16. Start a consolidation session in the Management tab of the Eventia Reporter
Client.

After upgrading Eventia Reporter from a previous version, only the Eventia Reporter
components will be enabled. To enable the Eventia Analyzer components (analyzer
or correlation unit) as well, run:
294
1. cpstop
2. evconfig
While running evconfig, enable Analyzer Server or the Correlation Unit.
3. cpstart

Upgrading Eventia Analyzer
Upgrading Eventia Analyzer

The process consists of:
• Upgrading Eventia Analyzer to R65
• Verifying that the events database has been successfully moved to its new
location
• Enabling Eventia Reporter (optional)
Upgrading Eventia Analyzer to NGX R65

Eventia Analyzer can be upgraded to NGX R65:
• Directly from version NGX R63
• Indirectly from any version prior to NGX R63.
a. If you wish to upgrade from version 1.0, first upgrade to version 2.0, then
upgrade to R63, and then to R65.
b. If you wish to upgrade from version 2.0, first upgrade to R63 then to R65
For more detailed information on upgrading to R63, see the
CheckPoint_R63_EventiaSuite_UpgradeGuide.pdf
Prerequisites
Before upgrading to Analyzer NGX R65, note the path to the current database file:
$RTDIR/events_db/events.sql, where $RTDIR is a variable that contains the path
of the previous Eventia Analyzer installation.
In R63, the default path:
• For Windows is C:\Program Files\CheckPoint\EventiaSuite\R63
• For Unix platforms is /opt/CPrt-R63
This path is changed during the upgrade process.
Upgrading Analyzer on SecurePlatform

1. Insert the R65 installation CD into the disk drive and run patch add cd.
2. Confirm the MDS checksum.
3. Select whether to create a backup image for automatic revert (recommended).
4. The Welcome message is displayed.
296
Upgrading Eventia Analyzer to NGX R65
5. Read and accept the license agreement.

6. Select the first option: upgrade.
7. Download or import a service contract file, or choose to continue without one.
8. Select a source for the NGX R65 upgrade utilities.
9. Select Upgrade Installed Products.
10. Validate the products in the products list.
11. Reboot once the upgrade is complete.
Upgrading Analyzer on a Windows Platform

1. Insert the NGX R65 Installation disk into the disk drive.
2. Read and Accept the license agreement.
3. Select upgrade option.
5. If necessary, upgrade your license.
7. Perform the pre-upgrade verification check.
8. Decide whether to install additional Check Point products.
10. Decide whether to copy log files now or manually copy them later.
11. Select a destination location.
12. Once the upgrade has completed, reboot.
Upgrading Analyzer on Solaris and Linux

1. Insert the NGX R65 installation CD into the disk drive.
2. Run: UnixInstallScript.
3. Read and accept the license agreement.
4. Select the upgrade option.
7. Select to upgrade installed products.

Verifying the Events Database Has Been Moved

9. Once upgrade has completed, login again to the root account.
10. Run cpstart to activate the installed products.
Verifying the Events Database Has Been Moved

When upgrading from R63 to R65, the events database is moved (not copied) from
its R63 location to a new R65 location. This should occur automatically during the
upgrade process, so there is no need to run upgradeDB.
To verify that the database has been correctly moved:
1. Navigate to the R63 $RTDIR/events_db/. The events.sql database file should
no longer exist in this directory
2. Navigate to the R65 $RTDIR/events_db/ directory. The events.sql should be
here
If the move has failed, move the database manually
Moving the Events Database

To manually move the events database:
1. Run: cpstop.
2. Move the file events.sql manually, from R63 $RTDIR/events_db/ to R65
$RTDIR/events_db/.
3. Run: cpstart.
Enabling Eventia Reporter

After upgrading Eventia Analyzer from a previous version, only the Eventia Analyzer
components (Analyzer or correlation unit) will be enabled. To enable all
components of Eventia Reporter run:
1. cpstop
2. evconfig
3. Enable Eventia Reporter
4. cpstart
298
THIRD PARTY TRADEMARKS AND COPYRIGHTS
Entrust is a registered trademark of Entrust Technologies, Inc. in the United States and other countries. Entrust’s logos and Entrust
product and service names are also trademarks of Entrust Technologies, Inc. Entrust Technologies Limited is a wholly owned subsidiary
of Entrust Technologies, Inc. FireWall-1 and SecuRemote incorporate certificate management technology from Entrust.
Verisign is a trademark of Verisign Inc.
The following statements refer to those portions of the software copyrighted by University of Michigan. Portions of the software copyright
© 1992-1996 Regents of the University of Michigan. All rights reserved. Redistribution and use in source and binary forms are
permitted provided that this notice is preserved and that due credit is given to the University of Michigan at Ann Arbor. The name of the
University may not be used to endorse or promote products derived from this software without specific prior written permission. This
software is provided “as is” without express or implied warranty. Copyright © Sax Software (terminal emulation only).
The following statements refer to those portions of the software copyrighted by Carnegie Mellon University.
Copyright 1997 by Carnegie Mellon University. All Rights Reserved.
Permission to use, copy, modify, and distribute this software and its documentation for any purpose and without fee is hereby granted,
provided that the above copyright notice appear in all copies and that both that copyright notice and this permission notice appear in
supporting documentation, and that the name of CMU not be used in advertising or publicity pertaining to distribution of the software
without specific, written prior permission.CMU DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO EVENT SHALL CMU BE LIABLE FOR ANY SPECIAL, INDIRECT
OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS,
WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION
WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
The following statements refer to those portions of the software copyrighted by The Open Group.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO
EVENT SHALL THE OPEN GROUP BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF
CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
DEALINGS IN THE SOFTWARE.
The following statements refer to those portions of the software copyrighted by The OpenSSL Project. This product includes software
developed by the OpenSSL Project for use in the OpenSSL Toolkit (http://www.openssl.org/).
THIS SOFTWARE IS PROVIDED BY THE OpenSSL PROJECT `ÀS IS'' AND ANY * EXPRESSED OR IMPLIED WARRANTIES,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE OpenSSL PROJECT OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT,
INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
POSSIBILITY OF SUCH DAMAGE.
The following statements refer to those portions of the software copyrighted by Eric Young. THIS SOFTWARE IS PROVIDED BY ERIC
YOUNG `ÀS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR
CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. Copyright © 1998 The Open Group.
299
The following statements refer to those portions of the software copyrighted by Jean-loup Gailly and Mark Adler Copyright (C)
1995-2002 Jean-loup Gailly and Mark Adler. This software is provided 'as-is', without any express or implied warranty. In no event will
the authors be held liable for any damages arising from the use of this software. Permission is granted to anyone to use this software for
any purpose, including commercial applications, and to alter it and redistribute it freely, subject to the following restrictions:
1. The origin of this software must not be misrepresented; you must not claim that you wrote the original software. If you use this
software in a product, an acknowledgment in the product documentation would be appreciated but is not required.
2. Altered source versions must be plainly marked as such, and must not be misrepresented as being the original software.
3. This notice may not be removed or altered from any source distribution.
The following statements refer to those portions of the software copyrighted by the Gnu Public License. This program is free software;
you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software
Foundation; either version 2 of the License, or (at your option) any later version. This program is distributed in the hope that it will be
useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE. See the GNU General Public License for more details.You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
The following statements refer to those portions of the software copyrighted by Thai Open Source Software Center Ltd and Clark Cooper
Copyright (c) 2001, 2002 Expat maintainers. Permission is hereby granted, free of charge, to any person obtaining a copy of this
software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the
rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom
the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be
included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY
KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A
PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE
FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
GDChart is free for use in your applications and for chart generation. YOU MAY NOT re-distribute or represent the code as your own.
Any re-distributions of the code MUST reference the author, and include any and all original documentation. Copyright. Bruce
Verderaime. 1998, 1999, 2000, 2001. Portions copyright 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002 by Cold Spring
Harbor Laboratory. Funded under Grant P41-RR02188 by the National Institutes of Health. Portions copyright 1996, 1997, 1998,
1999, 2000, 2001, 2002 by Boutell.Com, Inc. Portions relating to GD2 format copyright 1999, 2000, 2001, 2002 Philip Warner.
Portions relating to PNG copyright 1999, 2000, 2001, 2002 Greg Roelofs. Portions relating to gdttf.c copyright 1999, 2000, 2001,
2002 John Ellson (ellson@graphviz.org). Portions relating to gdft.c copyright 2001, 2002 John Ellson (ellson@graphviz.org). Portions
relating to JPEG and to color quantization copyright 2000, 2001, 2002, Doug Becker and copyright (C) 1994, 1995, 1996, 1997,
1998, 1999, 2000, 2001, 2002, Thomas G. Lane. This software is based in part on the work of the Independent JPEG Group. See the
file README-JPEG.TXT for more information. Portions relating to WBMP copyright 2000, 2001, 2002 Maurice Szmurlo and Johan Van
den Brande. Permission has been granted to copy, distribute and modify gd in any context without fee, including a commercial
application, provided that this notice is present in user-accessible supporting documentation. This does not affect your ownership of
the derived work itself, and the intent is to assure proper credit for the authors of gd, not to interfere with your productive use of gd. If
you have questions, ask. "Derived works" includes all programs that utilize the library. Credit must be given in user-accessible
documentation. This software is provided "AS IS." The copyright holders disclaim all warranties, either express or implied, including but
not limited to implied warranties of merchantability and fitness for a particular purpose, with respect to this code and accompanying
documentation. Although their code does not appear in gd 2.0.4, the authors wish to thank David Koblas, David Rowley, and
Hutchison Avenue Software Corporation for their prior contributions.
Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You
may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0
The curl license
COPYRIGHT AND PERMISSION NOTICE
Copyright (c) 1996 - 2004, Daniel Stenberg, <daniel@haxx.se>.All rights reserved.
Permission to use, copy, modify, and distribute this software for any purpose
with or without fee is hereby granted, provided that the above copyright
notice and this permission notice appear in all copies.
300
LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OF
THIRD PARTY RIGHTS. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES
OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Except as contained in this notice, the name of a copyright holder shall not be used in advertising or otherwise to promote the sale, use
or other dealings in this Software without prior written authorization of the copyright holder.
The PHP License, version 3.0
Copyright (c) 1999 - 2004 The PHP Group. All rights reserved.
Redistribution and use in source and binary forms, with or without modification, is permitted provided that the following conditions are
met:
1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.
3. The name "PHP" must not be used to endorse or promote products derived from this software without prior written permission. For
written permission, please contact group@php.net.
4. Products derived from this software may not be called "PHP", nor may "PHP" appear in their name, without prior written permission
from group@php.net. You may indicate that your software works in conjunction with PHP by saying "Foo for PHP" instead of calling it
"PHP Foo" or "phpfoo"
5. The PHP Group may publish revised and/or new versions of the license from time to time. Each version will be given a distinguishing
version number. Once covered code has been published under a particular version of the license, you may always continue to use it
under the terms of that version. You may also choose to use such covered code under the terms of any subsequent version of the
license published by the PHP Group. No one other than the PHP Group has the right to modify the terms applicable to covered code
created under this License.
6. Redistributions of any form whatsoever must retain the following acknowledgment:
"This product includes PHP, freely available from <http://www.php.net/>".
THIS SOFTWARE IS PROVIDED BY THE PHP DEVELOPMENT TEAM `ÀS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE PHP DEVELOPMENT TEAM OR ITS CONTRIBUTORS BE LIABLE FOR ANY
DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
This software consists of voluntary contributions made by many individuals on behalf of the PHP Group. The PHP Group can be
contacted via Email at group@php.net.
For more information on the PHP Group and the PHP project, please see <http://www.php.net>. This product includes the Zend
Engine, freely available at <http://www.zend.com>.
This product includes software written by Tim Hudson (tjh@cryptsoft.com).
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED
WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR
ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED
TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF
THE POSSIBILITY OF SUCH DAMAGE.
Copyright (c) 1998, 1999, 2000 Thai Open Source Software Center Ltd
301
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the
"Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish,
distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to
the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of
the Software.
LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN
NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Copyright © 2003, 2004 NextHop Technologies, Inc. All rights reserved.
Confidential Copyright Notice
Except as stated herein, none of the material provided as a part of this document may be copied, reproduced, distrib-uted,
republished, downloaded, displayed, posted or transmitted in any form or by any means, including, but not lim-ited to, electronic,
mechanical, photocopying, recording, or otherwise, without the prior written permission of NextHop Technologies, Inc. Permission is
granted to display, copy, distribute and download the materials in this doc-ument for personal, non-commercial use only, provided you
do not modify the materials and that you retain all copy-right and other proprietary notices contained in the materials unless otherwise
stated. No material contained in this document may be "mirrored" on any server without written permission of NextHop. Any
unauthorized use of any material contained in this document may violate copyright laws, trademark laws, the laws of privacy and
publicity, and communications regulations and statutes. Permission terminates automatically if any of these terms or condi-tions are
breached. Upon termination, any downloaded and printed materials must be immediately destroyed.
Trademark Notice
The trademarks, service marks, and logos (the "Trademarks") used and displayed in this document are registered and unregistered
Trademarks of NextHop in the US and/or other countries. The names of actual companies and products mentioned herein may be
Trademarks of their respective owners. Nothing in this document should be construed as granting, by implication, estoppel, or
otherwise, any license or right to use any Trademark displayed in the document. The owners aggressively enforce their intellectual
property rights to the fullest extent of the law. The Trademarks may not be used in any way, including in advertising or publicity
pertaining to distribution of, or access to, materials in
this document, including use, without prior, written permission. Use of Trademarks as a "hot" link to any website is prohibited unless
establishment of such a link is approved in advance in writing. Any questions concerning the use of these Trademarks should be
referred to NextHop at U.S. +1 734 222 1600.
U.S. Government Restricted Rights
The material in document is provided with "RESTRICTED RIGHTS." Software and accompanying documentation are provided to the
U.S. government ("Government") in a transaction subject to the Federal Acquisition Regulations with Restricted Rights. The
Government's rights to use, modify, reproduce, release, perform, display or disclose are
restricted by paragraph (b)(3) of the Rights in Noncommercial Computer Software and Noncommercial Computer Soft-ware
Documentation clause at DFAR 252.227-7014 (Jun 1995), and the other restrictions and terms in paragraph (g)(3)(i) of Rights in
Data-General clause at FAR 52.227-14, Alternative III (Jun 87) and paragraph (c)(2) of the Commer-cial
Computer Software-Restricted Rights clause at FAR 52.227-19 (Jun 1987).
Use of the material in this document by the Government constitutes acknowledgment of NextHop's proprietary rights in them, or that of
the original creator. The Contractor/Licensor is NextHop located at 1911 Landings Drive, Mountain View, California 94043. Use,
duplication, or disclosure by the Government is subject to restrictions as set forth in applicable laws and regulations.
Disclaimer Warranty Disclaimer Warranty Disclaimer Warranty Disclaimer Warranty
THE MATERIAL IN THIS DOCUMENT IS PROVIDED "AS IS" WITHOUT WARRANTIES OF ANY KIND EITHER EXPRESS OR IMPLIED.
TO THE FULLEST EXTENT POSSIBLE PURSUANT TO THE APPLICABLE LAW, NEXTHOP DISCLAIMS ALL WARRANTIES,
EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A
PARTICULAR PURPOSE, NON INFRINGEMENT OR OTHER VIOLATION OF RIGHTS. NEITHER NEXTHOP NOR ANY OTHER
PROVIDER OR DEVELOPER OF MATERIAL CONTAINED IN THIS DOCUMENT WARRANTS OR MAKES ANY REPRESEN-TATIONS
REGARDING THE USE, VALIDITY, ACCURACY, OR RELIABILITY OF, OR THE RESULTS OF THE USE OF, OR OTHERWISE
RESPECTING, THE MATERIAL IN THIS DOCUMENT.
Limitation of Liability
302
UNDER NO CIRCUMSTANCES SHALL NEXTHOP BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL, INCIDENTAL OR
CONSEQUENTIAL DAMAGES, INCLUDING, BUT NOT LIMITED TO, LOSS OF DATA OR PROFIT, ARISING OUT OF THE USE, OR THE
INABILITY TO USE, THE MATERIAL IN THIS DOCUMENT, EVEN IF NEXTHOP OR A NEXTHOP AUTHORIZED REPRESENTATIVE HAS
ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. IF YOUR USE OF MATERIAL FROM THIS DOCUMENT RESULTS IN THE NEED
FOR SERVICING, REPAIR OR CORRECTION OF EQUIPMENT OR DATA, YOU ASSUME ANY COSTS THEREOF. SOME STATES DO
NOT ALLOW THE EXCLUSION OR LIMITATION OF INCIDENTAL OR CONSEQUENTIAL DAMAGES, SO THE ABOVE LIMITATION OR
EXCLUSION MAY NOT FULLY APPLY TO YOU.
Copyright © ComponentOne, LLC 1991-2002. All Rights Reserved.
BIND: ISC Bind (Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC"))
Copyright 1997-2001, Theo de Raadt: the OpenBSD 2.9 Release
PCRE LICENCE
PCRE is a library of functions to support regular expressions whose syntax and semantics are as close as possible to those of the Perl 5
language. Release 5 of PCRE is distributed under the terms of the "BSD" licence, as specified below. The documentation for PCRE,
supplied in the "doc" directory, is distributed under the same terms as the software itself.
Written by: Philip Hazel <ph10@cam.ac.uk>
University of Cambridge Computing Service, Cambridge, England. Phone:
+44 1223 334714.
Copyright (c) 1997-2004 University of Cambridge All rights reserved.
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions
are met:
* Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
* Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.
* Neither the name of the University of Cambridge nor the names of its contributors may be used to endorse or promote products
derived from this software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED
WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR
ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED
TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
Eventia Reporter includes software whose copyright is owned by, or licensed from, MySQL AB.
303
304
Index
A G MDS environment 260

MDS High Availability 267
MDS services 260
Administrators 255 Global Communities 257
mds_backup 219
Global VPN Communities 256
mds_remove 266
mds_setup 267
B migrate_assist 217
H migrate_global_policies 218
backup 129 migration process 91
Backup and Restore 218 High Availability 110, 251, 261, Minimal Effort Upgrade 111,
Backup of system settings 129 268 196
High Availability MLM 263
Environment 267 Multi-MDS environments 261
C MVS 26
CLM 212, 263 I

Clustered deployment 111 N
ClusterXL 26, 196 In Place Upgrade 26
CMA 212, 216, 218, 253, 255, Internal Certificate Authority 216 Nokia clustering 197
263, 271 IPSO Platform 107, 122, 156 Nokia OS 112
cma_migrate 214
cprid 114
CRL 216
L O
License Repository 33 Operation Status 114
E License Upgrade 33 OPSEC 112, 113, 195
License Upgrade Tool Options 35
errors 93, 143 License_upgrade 34
Evaluation licenses 49 Licensing
Eventia Analyzer 290 Web Intelligence 88 P
Eventia Reporter 112, 290 Local Upgrade 111
LSM 26 Package Repository 26, 278
Expert mode 99, 118
LSMcli commands 282 patch command 100
Performance Pack 112
Plug & Play 274
F PolicyServer 112
M Pre-upgrade utilities 266
FQDN 216 Pre-upgrade verification 88, 91,
Full Connectivity upgrade 202 Management plug-ins 22 94, 116, 141, 142, 144, 212,
MD5 checksum 120 261, 263
MDS 211, 212, 218, 219, 254, Pre-upgrade verifier 211
271 Products 89
February 2007 305

Provider-1/SiteManager-1
upgrade 209
U
Upgrade tools 28
UserAuthority 112
Q UserAuthority Server 112
UTM-1 112
QoS 112
V
R
Virtual Routers 27
release notes link 20 Virtual System 27
remote upgrade 274 VPN-1 distributed
restore 129 deployment 140
ROBO Gateway 26, 274, 278, VPN-1 Edge Firmware
280 package 275
ROBO Profile 26 VPN-1 Gateways 112
VPN-1 Server 144
VSX Clustering 27
S VSX Gateway 27
Safe Upgrade 119, 120, 252

SCP 129 W
SecureClient 53
SecurePlatform 41, 42, 44, 45, warning 93, 143
89, 95, 97, 99, 112, 118, Web Intelligence
141, 145, 148, 151, 231, Licensing 88
232, 236, 237, 241, 243 What’s New link 20
Security Policy 26 Wrapper 33
Service Contract Files 59
SmartCenter Server 27
SmartConsole Clients 27, 255
SmartDashboard 27
Z
SmartDefense 272 Zero Downtime 111, 196
SmartLSM 273
SmartUpdate 27, 39, 112, 195,
200, 246
SmartUpdate Upgrade 111
SmartView Monitor 112
Software Upgrade 33
T
TFTP 129, 132
Translation prompt 268
306

Checkpoint R65 Upgrade Guide

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Checkpoint R65 Upgrade Guide

Hochgeladen von

Copyright:

Verfügbare Formate

Upgrade Guide

Version NGX R65

701313 February 13, 2007

RESTRICTED RIGHTS LEGEND:

Preface Who Should Use This Guide.............................................................................. 12

Chapter 1 Introduction to the Upgrade Process

Chapter 2 Upgrading Licenses for Products Prior to NGX

Chapter 3 Service Contract Files

Chapter 4 Upgrading a Distributed Deployment

Chapter 5 Backup and Revert for VPN-1 Power/UTM

Chapter 6 Upgrading a Standalone Deployment

Chapter 7 Advanced Upgrade of SmartCenter Servers & Standalone Gateways

Chapter 8 Upgrading ClusterXL Deployments

Chapter 9 Upgrading Provider-1

Chapter 10 Upgrading SmartLSM ROBO Gateways

Chapter 11 Upgrading Eventia

Who Should Use This Guide page 12

Who Should Use This Guide

TABLE P-1 VPN-1 Power documentation suite documentation

TABLE P-1 VPN-1 Power documentation suite documentation (continued)

TABLE P-2 Integrity Server documentation

TABLE P-2 Integrity Server documentation (continued)

• View the latest version of this document in the User Center at

NGX License Upgrade

Chapter 1 Introduction to the Upgrade Process 21

Management Plug-in Infrastructure

Supported Upgrade Paths and

Upgrading Management Servers

Chapter 1 Introduction to the Upgrade Process 23

Backward Compatibility For Gateways

Upgrading versions 4.0 and 4.1

Obtaining Software Installation Packages

Chapter 1 Introduction to the Upgrade Process 25

Security Policy: A Security Policy is created by the system administrator in order to

Chapter 1 Introduction to the Upgrade Process 27

Overview of NGX License Upgrade page 30

Overview of NGX License Upgrade

Introduction to License Upgrade

Chapter 2 Upgrading Licenses for Products Prior to NGX 31

Software Subscription Requirements

Chapter 2 Upgrading Licenses for Products Prior to NGX 33

The License_Upgrade Tool

Table 2-1 license_upgrade tool options

Chapter 2 Upgrading Licenses for Products Prior to NGX 35

Simulating the License Upgrade

To simulate the license upgrade:

Performing the License Upgrade

License Upgrade Methods page 37

License Upgrade Methods

Chapter 2 Upgrading Licenses for Products Prior to NGX 37

Deployment with Licenses Managed Centrally

Introduction to Using SmartUpdate page 39

Introduction to Using SmartUpdate

Note - SmartUpdate license management capabilities are free of charge.

After the SmartCenter server is upgraded, SmartUpdate must be used to complete

License Statuses in SmartUpdate

Chapter 2 Upgrading Licenses for Products Prior to NGX 39

A license can be in one of the following States:

License Upgrade for an Online SmartCenter

To upgrade licenses for an online SmartCenter:

4. On the SmartCenter server, perform the license upgrade procedure by running

5. Select the [U] option. This does the following:

License Upgrade for an Offline SmartCenter