Share all details about your problem, including any error messages you may have received.
Hi community,
I’m planning to upgrade the SQL Server JDBC driver used in our SailPoint IIQ environment from version 8.2.2.0 to 12.10. I’d appreciate some help and best practices from anyone who’s done this before.
Specifically, I’m looking for guidance on:
How to check the currently installed JDBC driver version in the environment
Where to locate the existing JDBC JAR file in the IIQ deployment (e.g., specific path or directory)
Recommended steps for safely updating the JDBC driver (including removing the old one and restarting services)
Any important considerations or potential gotchas during or after the upgrade
Any insights, checklists, or tips would be amazing. Thanks in advance!
Stop IIQ Application Server(s): Shut down all instances of your application server where IIQ is deployed.
Download new Driver jar file:
Go to the official Microsoft JDBC Driver for SQL Server download page
{ Download version 12.10.0 that is compatible with your Java 11 (JRE11) environment. The file name will be something like mssql-jdbc-12.10.0.jre11.jar}
Place New Driver:
Copy the newly downloaded mssql-jdbc-12.10.0.jre11.jar file into the IIQ_HOME/WEB-INF/lib/ directory.
Review iiq.properties
Open IIQ_HOME/WEB-INF/classes/iiq.properties.
Pay close attention to your dataSource.url configuration. Newer JDBC drivers (especially 10.x and later) often default to encrypt=true. If your SQL Server is not configured for forced encryption or if your certificate chain isn’t trusted by the Java truststore on the IIQ server, this can cause connection failures.
Consider adding encrypt=false;trustServerCertificate=true; to your dataSource.url if you encounter connection issues after the upgrade and your SQL Server is not strictly enforcing encryption.
– Clear application server caches (e.g., Tomcat work directory)
Start IIQ Application Server(s): Start your application server instances.
note: Monitor application server and IIQ logs for errors.
Verify IIQ console access.
Monitor Logs Closely: Immediately after startup, monitor the application server logs: During startup, your application server (Tomcat) logs might indicate which JDBC drivers are being loaded, potentially showing their versions. can confirm it’s being picked up new JDBC driver.
It’s best to add the jdbc driver jar file in to your SSD build. That is, put the file in the web/WEB-INF/lib directory. That way it will be packaged in the war file when you do a build. Then deploy the war file as usual.
It’s import to follow a standard build/deploy process.
Quick follow-up: In our environment, the current JDBC driver isn’t located in the IIQ_HOME/WEB-INF/lib/ directory. Instead, it’s referenced externally via the tomcat9w.exe (which is located under Tomcat/bin) Java tab under Java Options and classpath entries.
-Djava.library.path=C:\JDBC Jar file path
Given that setup, should I:
Replace the existing .jar in that external directory with mssql-jdbc-12.10.0.jre11.jar and update the path accordingly?
Or should I move away from this external reference and instead place the new driver directly into IIQ_HOME/WEB-INF/lib/ as per standard practice?
Just want to confirm the best path forward before proceeding.
"Current Setup: External Reference via tomcat9w.exe (Classpath Entries)
How it works: Adding a JAR to tomcat9w.exe’s Java Options/Classpath entries places it on Tomcat’s common or shared classpath. This allows the JDBC driver JAR to be loaded by a parent classloader, making it available to all deployed web applications, including IdentityIQ.
Recommendation: Proceed with the first option, using the current tomcat/bin path.
Pros:
Centralized management: Only one driver copy is needed for all applications.
Best practice: Given your existing external reference and general best practices for JDBC drivers in Tomcat, maintaining this approach is the most stable path forward. This aligns with the benefits of centralized management and memory leak prevention inherent in placing JDBC drivers on Tomcat’s shared classpath. IdentityIQ, being a single application on this Tomcat instance, benefits from its database driver being managed by Tomcat’s common classloader, which is a robust approach for stability.
Action: Replace the existing .jar in that external directory with mssql-jdbc-12.10.0.jre11.jar and update the path accordingly."
I need some further assistance regarding a couple of observations in our current setup (we haven’t performed the JDBC upgrade yet):
1. Driver/DLL Version Mismatch
I noticed this in the logs:
Caused by: java.lang.UnsatisfiedLinkError: no mssql-jdbc_auth-8.4.1.x64 in java.library.path: [C:\eduPassIIQ\MSJDBCDriver\sqljdbc_8.2.2.0_enu\sqljdbc_8.2\enu\auth\x64]
This seems odd because our Java Options in tomcat9w.exe point to version 8.2.2, not 8.4.1. Is it possible that:
Some other part of the system or Tomcat classpath is referencing the 8.4.1 JDBC JAR?
If so, what’s the best way to trace where that version is being picked up from?
2. JDBC Driver Unregistration Warning
Another log entry I noticed:
WARNING ... WebappClassLoaderBase.clearReferencesJdbc:
The web application [identityiq] registered the JDBC driver [com.microsoft.sqlserver.jdbc.SQLServerDriver] but failed to unregister it when the web application was stopped.
I understand this is typically due to the JDBC driver being packaged inside the WEB-INF/lib directory, but:
We’re currently referencing the driver externally via the tomcat9w.exe Java Options classpath.
Should this warning still occur if the driver is loaded via Tomcat’s shared classloader?
Would appreciate any insights on resolving both of these before proceeding with the upgrade to version 12.10.