Deploy a VMware Appliance

System requirements vary by the appliance generation. For appliance system requirements, see Imprivata OneSign Supported Components in the Imprivata Environment Reference.

The release introduction history of supported appliances is: 

• Imprivata OneSign 7.11 and later releases require G4 (fourth generation) appliances.

• Imprivata OneSign 7.10 introduced the General Availability (GA) release of the G4 appliance to all customers, including for G3 or G2 enterprise migrations to G4.

  Imprivata OneSign 7.10, 7.9, and 7.8 support either G3 or G4 appliances, but not both G3 and G4 appliances on the same enterprise.

• Imprivata OneSign 7.8 introduced the Controlled Availability (CA) release of the G4 appliance to select customers or on request. 

• All maintained releases of Imprivata OneSign, up to 7.10, require G3 appliances.

Unsupported

The following virtual appliance configurations are not supported:

• The cloning of appliance virtual machines is not supported.

• Infrastructure-level snapshots of appliance virtual machines are not supported.

Considerations for Storage Level RAID Protection

While most customers will want to use RAID 5, Imprivata recommends RAID 1+0 or RAID 10 for any appliances that are experiencing a challenge with throughput, especially G4 database appliances.

G4 Appliances

The number of appliances appropriate for a G4 enterprise depends on many factors, including user counts, authentication methods, and other issues.

First, consider the two G4 appliance types and the limits on their numbers per enterprise:

• Database appliances host the databases, perform database replication, service endpoint agent requests, and contain all audit data.

  • Enforced maximum of two database appliances per enterprise.

  • The first two appliances configured are always database appliances.

• Service appliances exclusively service endpoint agent requests.

  • Recommended maximum of four service appliances per enterprise.

• Recommended maximum of six total appliances per enterprise. Adding more appliances beyond six typically does not yield performance improvements.

• No audit appliances.

For G4 appliances, Imprivata recommends three standard deployment options: two-, four-, and six-appliance enterprises. The two-appliance enterprise offers three different CPU and RAM configuration options for scale.

Recommended Options	2 Appliance Enterprise			4 Appliance Enterprise	6 Appliance Enterprise
Database appliances	2	2	2	2	2
CPUs per appliance	4	8	8	8	8
RAM (GB) per appliance	8	16	32	16	16
Service appliances				2	4
CPUs per appliance				2	2
RAM (GB) per appliance				8	8
Total appliance CPUs in enterprise	8	16	16	20	24
Total appliance RAM in enterprise	16	32	64	48	64
Number of user sessions supported (in optimal conditions)	22,000 to 28,000	28,000 to 36,500	36,500 to 47,500	47,500 to 62,000	62,000 to 80,000+

• The base two-appliance G4 enterprise, having 4 CPUs and 8 GB RAM per appliance, totaling 8 CPUs and 16 GB RAM for the enterprise, can be equated to a base two-appliance G3 enterprise that can accommodate 22,000 to 28,000 user sessions.

  Each additional column or step in the G4 table above yields approximately a 30% improvement in throughput.

• Odd numbers of appliances are recommended only when migrating from a G3 or G2 enterprise to a G4 enterprise, when the original enterprise has an odd number of appliances.

  • Migrations require the same number of G4 appliances in your new G4 enterprise as you have in your existing G3 or G2 enterprise, to support the enterprise export from G3 or G2 and import into G4.

  • For a migration with an odd number of appliances, after you transition your G4 enterprise to production, Imprivata recommends that you transition to a standard deployment configuration.

• Selecting an optimal enterprise configuration depends on knowing your total number of users and endpoints in your environment, usage patterns to identify peak activity periods, and disaster recovery needs that may stretch the topologies and halve the resources for active/active type setups.

  There are many factors that affect performance including authentication types, multi-factor authentication methods, EPCS (electronic prescription of controlled substances) workflows, underlying hardware options for hosting the virtual machines that host the appliances, underlying network topology, and more.

  Newer high performing systems may yield better throughputs, and conversely older systems may yield poorer performance.

• For customers with active G3 enterprises larger than two appliances, the rule of thumb is to first count the total number of CPUs in your current deployment. Then in the G4 table above, in row Total appliance CPUs in enterprise, find a G4 configuration with a matching CPU count.

G3 Appliances

The number of appliances appropriate for a G3 (third generation) enterprise depends on numerous factors, including user session counts, authentication methods, network topology, site configuration, and failover requirements.

• In general, using the fewest appliances necessary to meet these requirements is optimal.

• Only add appliances for redundancy or disaster recovery.

• Before adding appliances to the enterprise, consider scaling up by adding cores to the appliance beyond the preset two cores.

• The maximum number of cores per appliance is eight (8).

• Include audit appliances in the active mix of appliances servicing authentication requests.

• Approximately 11,000 to 14,000 user sessions can be supported per appliance, depending on workflows.

Examples

• For 22,000 to 28,000 user sessions, use an enterprise of two appliances, with two cores each.

• For 28,000 to 48,000 user sessions, use an enterprise of two to three appliance, with four cores each.

• For 48,000 to 100,000 user sessions, use an enterprise with three appliances, with four to eight cores each.

Beginning with Imprivata OneSign 7.2 SP1, the Imprivata appliance now supports the initial assignment of the following:

• IP address, subnet mask, and default gateway.

• DNS servers.

• NTP servers from the NTP Pool Project.

To deploy the appliance:

1. From your fulfillment letter, download and extract the Imprivata Virtual Appliance RAR file.

   NOTE: If deploying to VMware ESXi 6.7, deploy one appliance at a time. Deploying multiple appliance in parallel can result in the process timing out.

2. In the vSphere Client, click File > Deploy OVF template.

3. Follow the OVF Deploy Template wizard to complete the deployment. Consider the following:

   • ESXi 6.7 only — Select both the OVF and VMDK files.

   • When prompted to customize Networking Properties, either select DHCP if enabled in your environment, or leave all values blank and then later network the appliance using the appliance configuration (setup) wizard.

   • When prompted to review the settings, be sure that Power on after deployment is not selected before you finish the deployment.

To disable the vApp options:

1. In the vSphere Client, right-click the virtual appliance, click Edit Settings, and open the Options tab.

2. Click vApp options, and select Disable.

   A message appears that prompts you to confirm the action.

3. Click Yes, and then click OK.

To add the appliance to the network:

1. Power on the appliance, and open the console to start the appliance initialization scripts.

   • The initialization scripts run in the background and do not display progress. The time to complete is approximately 15 minutes.

   • The Imprivata Appliance Console displays the IP address, subnet mask, and gateway that is initially assigned to the appliance.

2. (Optional, or if DHCP is unavailable on your network) If required, you can add or change the network configuration manually:

   1. At the login prompt type menu, and then press Enter.

   2. Type 1, and then press Enter to assign or reassign the values.

      NOTE: If you receive a database error message when trying to log in, the appliance has not finished initializing.

3. Exit the Imprivata Appliance Console.

4. In a web browser, enter https://<appliance_IP_address>:81 to complete the setup using the appliance configuration (setup) wizard.

Verify that the files were not corrupted during download.

1. In the Imprivata Virtual Appliance RAR file, there should be three files:

   • .mf - a manifest files, containing checksums for the OVF and VMDK files.

   • .ovf - the virtual machine template file, containing a description of the virtual machine.

   • .vmdk - the virtual machine hard disk file.

2. Open the .mf file in a text editor. It is formatted similar to the following example:

   SHA1(imprivata6.2.ovf)= a956be53480a2d6f4ca43a9c6ef46fba2e326150
   SHA1(system-disk1.vmdk)= a2bedcb3bfb14e7bbbf5ad481d58104aa1ec79ba

3. Run a hash of each of these two files to verify the resulting checksums against the contents of the manifest file.

   Use the following PowerShell command to get the file hash and convert it to lower case for easy comparison:

   $(Get-FileHash .\imprivata6.2.ovf -Algorithm SHA1 | Select -ExpandProperty Hash).ToLower()

4. Compare the output of the PowerShell command with the checksum in the manifest file.

   • If the checksums match, it confirms that the download is good and that the extracted files are good.

   • If the checksums do not match, it indicates that the files may be corrupted and may indicate a problem with either the extraction or download process.

Recommended Steps

1. Do not delete the existing RAR archive; it may still be usable.

2. Download the archive again, using an alternate browser from the original download method. While the download is in process, you can recheck the original file:

   1. Use a different extraction utility to extract the original RAR archive. The choice of extraction utility may affect the outcome when extracting large archives.

   2. Run the checksum process on the newly extracted files to determine whether the files are good.

      • If the checksums match, cancel the new download.

      • If the checksums do not match, continue the new download and repeat the verification process.

If you experience problems deploying the OVF file, consider the following:

• When deploying, select only the OVF and VMDK files, not the MN (manifest) file.

  The hypervisor may attempt to run a checksum on the manifest file, which does not contain a checksum for itself.

• Use the vSphere Web Client on Google Chrome, not Internet Explorer, to run the deployment.

  Internet Explorer has a maximum file size limit of 4GB, which may truncate the VMDK during the upload, causing the error:

  The checksum(s) from the provided manifest file do not match 
  the content of the file(s).

• If you still experience problems, deploy the files using the vSphere command line tool instead of the Web Client.

  Example

  ovftool.exe -ds=VMFS005_3PAR109 --net:"Network 1”=”Network A VLAN 432" 
  -n=WSLXIMP1901 "D:\Temp\S3x64\Imprivata5.5hf1demo_OVF10.ovf" 
  vi://adminrb@100.64.0.25/

  Syntax

  ovftool --net: "source_network_name"="destination_network_name" 
  -ds="destination_datastore" -n="destination_virtual_machine_name" 
  "vi://domain\username@source_vcenter_fqdn/source_datacenter_name/
  virtual_machine_name/virtual_machine_folder/virtual_machine" 
  "vi://domain\username@destination_vcenter_fqdn/host/cluster_name"