Sql Server Network Configuration (32 Bit) is empty after leave my server from a domain

Question

Hi There guy i have an issue that occurs about 2 weeks ago...

We have a Windows Server 2012 r2 running our Sql Server Production Database that has Windows Authentication credentials to login in the Micrososft Server Managment Studio and out main Software that we use to work in here...

The thing was when we join that server to our New Active Directory (we use Super Admin account to do it) we have some issues to connect the odbc of the computers so we decide to exit from the Domain that Server and go back with the common settings we have later on...

When we do that we found that we cant enter to the Sql Server Configuration Manager it gives you an error from the WMI service... That was this one...

"Cannont Connect to WMI Provider you do not have permissions or the server is unrecheable. Nota that you can manage SQL server 2005 (??? we have 2012) and later Servers with SQL Server Configuration Manager. Invalid Class [0x80070005]"

Digging some information i nthe internet i found some member that says that i need to add NETWORK SERVICE (or something like that) to an Registry Entry.. With this we could open the SQL Server Configuration Manager but when i check the SQL Server Network Configuration (32 bits) its empty and dont show my Protocols of connection from my instance... (And to be clear we have a 32 bits SQL Server Conf its not a 64 bits).

Some of the other things that i saw digging about this issue is some say that i need to recompile the sqlmgmproviderxpsp2up.mof using that command prompt "mofcomp sqlmgmproviderxpsp2up.mof"

and when i run this one the command gives me this thing...

Another thing all of my working computers are working correctly and have connection to the database all this comes because we have a linux server (that is in the same network as i) and when they try to connect to that server it trows out a connection refused error when they try to acces to the port that is open...

How can i solved that without uninstalling all my production enviroment because this is the core of my company and doing that i dont know what could come around if i doing that...

Answer 1

Hi @Mariano Dabove ,
Thanks for your reply.

where i need to put those ports... in my firewall configuration of the Server who runs the Sql Server or in the Sql Server Configuration Managment??? or in both??

As Erland mentioned, please check the port SQL Server is listening on in the SQL Server Configuration Manager->SQL Server Network Configuration-> Protocols for instance->TCP\IP properties.
By default, the default instance that SQL Server listens on is port 1433. For a named SQL Server instance, the ports that are used to talk to the SQL Server are by default dynamic.
In the TCP\IP properties dialog box of SQL Server Configuration Manager, if the TCP Dynamic Ports dialog box contains 0, indicating the Database Engine is listening on dynamic ports.

We can configure the instance to listen on a specific port, so that the appropriate port can be opened in the firewall. To assign a TCP/IP port to the SQL Server instance, please delete the 0 in the TCP Dynamic Ports dialog box and set the TCP Dynamic Ports to blank, and in the IPn Properties area box, in the TCP Port box, type the port number you want this IP address to listen on, and then click OK. Multiple ports may be specified by separating them with a comma. Please refer to this article which might help.
Then we need to add a firewall exception for the port. Please refer to this doc which might help.
Best Regards,
Amelia

---

If the answer is helpful, please click "Accept Answer" and upvote it.
Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

Answer 2

Well @AmeliaGu-MSFT good news! we could fix the .mof file in the SQL Server and we can rebuild the x64 architecture of the Database...

Now we have an issue that the other pc who is running in Linux cant conect to the database...

And when i check the IPV Values in the Protocols of my Instance i saw this things...

The correct ip of this server is not 0.248 its other so i dont know if we need to change that value to the correct one so that server could reach the database or where i need to redirect so we can have an established connection...

Right now the other server throws out a "Connection Timeout" when i try to connect with the ip and the current port i dont restart the services of the database so i dont know if this could be the cause too...

Answer 3

Hi @Mariano Dabove ,
In addition, you also can find the IP address for server in cmd using ipconfig /all:

And please try to use the ip address and port to connect to SQL Server. If there are any error message, please feel free to share us.

Best Regards,
Amelia

Answer 4

This is what ipconfig /all trows...

This is the correct ip of my server and i change that value in the server configuration network and protocols for my instance to that ip...

When we try to conecto to that ip with the port that trrows the IPAA it give us the "Connection TImeout"...

How can i run a cmd to conect to my instance from a different pc to this server using the port and ip adress (or public ip with the port) so i try to check that the connection is stablished and is not an error of the configuration of the server that now runs the other server???.

Answer 5

How can i run a cmd to conect to my instance from a different pc to this server using the port and ip adress (or public ip with the port) so i try to check that the connection is stablished and is not an error of the configuration of the server that now runs the other server???.

That's really a different question and it would be better to start a new thread. Except that this is one we answer about daily. Check the usual suspects: firewalls, is SQL Server running, does it accept remote connections, is the servername/IP address correct? The port number? Keep in mind configuration changes in this area do not take effect until SQL Server has been restarted.