You don't need the ODBC Agent or ODBC Server to make JDBC connections. They're basically legacy services for people still using MS Access or some other really old DB.

As for service startup order, no need to write a script! Just use the DependOnService registry key, as described here. You can do this using .reg files, or by using the sc tool.

https://serverfault.com/questions/24821/how-to-add-dependency-on-a-windows-service-after-the-service-is-installed

Finally, like @Charlie Arehart , I don't think this has anything to do with your JDBC connection. The problem is that Azure forces you (I think) to use TLS/SSL to connect to Azure's version of SQL Server. I honestly am not an expert on Azure so this is just a guess, but if I were designing a DB service for the cloud I'd force the use of TLS too. Also, it's not clear to me whether you're using Azure SQL or a "regular" SQL Server installed in an Azure VM. TLS connections depend on a lot of stuff working correctly, and it sounds to me like the JVM running ColdFusion doesn't support whatever TLS requirements you have. Can you find out what your JVM is, exactly? You should be able to see that in CF Administrator. You should first try Charlie's suggestion to ignore certificate validity in your datasource custom settings, though.

Dave Watts, Eidolon LLC

Michael, I would propose a VERY different cause and solution, having nothing to do with the order of startup of the cf services.

(Indeed, none of those other services have anything to do with jdbc, so I can't see at all how the order cihd possibly matter. But you seem confident on that, so I'd like to leave that alone for now.) 

Instead, the issue seems to be about your making a secure (tls) connection to the db server--the one whose use in a dsn is getting the error. 

Can you try first adding this connection string to that dsn? 

ValidateServerCertificate=false

Does it prevent the error, regardless of startup order? If so, that confirms its a problem about your cf (and it's Java version) having an issue with the db server and its certificates/tls configuration (or it could be something else fronting it, whether a load balancer, firewall, or other thing that may be handling the tls termination).

Getting the correct ultimate solution may require different effort, but at least you'll know where to pay that attention.

Let us know how things go, or if you maybe learn something new.