Problem: The Kaseya server cannot talk to the SQL server after the port changes, a password reset happens on the Kaseya users in DB and/or the migration itself, which causes the server to go down.
Cause: This is caused either because of the DB server is moved to a restricted network, or there's a password reset done on the DB users; note that even the restore DB or the migration would break the server.
Resolution: We can telnet to the DB server on the configured port to see if the connection from the Kaseya server to the DB server is successful. However, this would not tell us if the SQL instance is able to connect with the supplied credentials on the kserver.ini file. Follow these steps:
- Right-click anywhere on your computer, i.e., Desktop
- Create a new text document
- Name it anything with the extension .udl (i.e. ConnectionTester.udl)
- Double click on it to open the connection tester
- Mention the Name of the server\SQL instance name, port number (i.e. KaseyaDB\KaseyaInstance,3302)
Note: If it is the default port (1433) and the default instance (i.e. MSSQLSERVER) it is not required to list them as follows:
Note: If it is a custom port, you can check the connection like this:
- 10.20.82.65 - Server's IP address.
- Kaseya - Named instance.
- 3302 - Custom port .
Applies to: All front and back-end instances.