User Tools

Site Tools


pervasive_version_11_recovering_from_a_disaster

This is an old revision of the document!


Pervasive Software Whitepaper - Pervasive Version 11

This article will help developers and end users better understand the Pervasive product authorization process and the various ways to authorize Pervasive PSQL as well as recover form a disaster using pervasive 11 unique keys

Click link below

http://www.pervasivedb.com/SiteCollectionDocuments/WP_Whitepaper_Product_Authorization_for_Pervasive_PSQL.pdf

Please inform customers after upgrading them to Pervasive 11.

Hardware Changes, Virtual Machines, Disaster Recovery, and Reusing Keys

General Rule: Deauthorize First

When uninstalling Pervasive PSQL, upgrading a server running PSQL, cloning a virtual machine or moving

Pervasive PSQL to another system – always delete (deauthorize) the PSQL key first. This way you can be

sure that the key used to authorize your copy of PSQL will not already be associated with a machine

signature and can be used to reauthorize PSQL whenever and wherever needed.

Hardware Changes

Always deauthorize (delete) the Pervasive PSQL key before making changes to hardware. Here is why.

When the PSQL engine starts, it checks to confirm that the machine signature related to that installation

of PSQL is unchanged. Changes to three or more of the attributes that make up the machine signature

will cause the key state to change from Active to Failed Validation. For virtual machines, any changes in

the machine signature attributes (except memory) will cause the key state to change to Failed

Validation. If the Failed Validation state is not corrected in a specific time period (usually 14 days but

may be different depending on PSQL version and what company created the key), the key will become

Disabled. Note: the Failed Validation key state feature is not available on releases of Pervasive PSQL

prior to v11 SP1. For those releases, the hardware changes described above will cause the key to go

directly to a Disabled state.

Disaster Recovery

If for example, a server was to loose a motherboard, required a new CPU, a new NIC then Pervasive would fail to authorize on startup and would need to be deactivated on our end using the Pervasive Portal. If this happens, Windward Administration needs to be contacted and informed that the customers Pervasive license needs to be deactivated from the portal so that it can be re-activated on the clients end.

**

__

pervasive_version_11_recovering_from_a_disaster.1385757512.txt.gz · Last modified: 2013/11/29 12:38 (10 years ago) by mrobosa