FIM 2010 and MIM 2016 have a thing in common with regards to SQL named instances; they can’t handle the truth. In this case they can’t handle that the SQL instance is running on a port other than the default 1433 SQL port.
What do you do when you have have a friend that can’t handle the truth but that you don’t want to lie to? You tell them as much of the truth as they can handle and that’s exactly what we need to do for MIM.
In this case, truth comes in the form of an SQL alias, your friend MIM will never know the truth that it’s actually talking to SQL on a port other than 1433. Shocking!
Note: The SQL alias needs to be created in both the 32-bit and 64-bit versions, your 32-bit applications will use the 32-bit alias while the 64-bit applications use the 64-bit one (obviously).
If one application works with the alias while another one doesn’t its usually an indicator that there’s a difference between the 32-bit and 64-bit aliases in your setup.
For testing and troubleshooting purposes it is useful to create an empty file with a .udl extension, for example test.udl, and then double-click that file to launch it.
Make sure you’re testing the same provider that your application uses, the current version of the MIM Setup program seems to use the SQL OLE DB provider rather than the SQL Server Native Client.
You also need to make sure that the application you’re testing with supports the cryptographic ciphers and algorithms being used on the server end, for example; if the application requires a version of TLS that is disabled on the server side then you need to either get an update to the application or enable the cipher on the server side.
FIM errors on setup and upgrade when using a custom SQL port:
You cannot use the Transport Layer Security protocol version 1.2 to connect to a server that is running SQL Server 2014 or SQL Server 2012