Installation, Upgrade, and System Configuration
Know the file set before you touch a server
IdentityIQ is a Java web application deployed to a servlet container (commonly Tomcat) and backed by a relational database. The datasource, dialect and connection pool live in iiq.properties; logging is configured in log4j2.properties; console and batch scripts resolve paths from IIQ_HOME. Encrypted values - application passwords, secret questions, some attribute values - depend on the keystore file iiq.dat. In a multi-node deployment every node shares one database but must hold an identical copy of iiq.dat and run the same patch level.
Upgrade sequence that questions reward
Back up the database and copy iiq.dat; run the schema upgrade from the console (or the supplied upgrade script) with the application stopped; deploy the new WAR or exploded directory; start and confirm the reported version; then verify plugins, custom rules and any compiled classes still work. Plugins should be checked for compatibility before, not after, the upgrade.
Traps
- Regenerating or forgetting
iiq.dat: existing encrypted attributes silently fail to decrypt and logins using secret questions break. - Running the schema upgrade while other nodes stay live, producing lock errors and a half-upgraded schema.
- Timezone mismatch between the JVM (
user.timezone) and the database, which shifts task and certification timestamps. - Database character set or collation that is not UTF-8 / not case-insensitive, breaking correlation on mixed-case values.
Rule of thumb
If the application starts but cannot decrypt a password or a secret question stops working after a migration, inspect iiq.dat first; if dates look wrong, inspect timezone before touching any data.