Hello everyone! I'm basically new in managing Windows 2008 Server R2. I'm trying to open a port for a specific application in Windows Firewall (in domain group policies), so I create an "inbound rule" allowing traffic to the specific port. The problem is that the connection is not working. I disabled the firewall, I turn down the antivirus, and the connection is somehow blocked. When I run netstat -an and add the filter to show the "listening" ports, the port that I opened before in the inbound rules is not appearing. I tried with other ports and the results are the same. Any idea of what could be the problem? Thanks in advance!

Use tcpview from Sysinternal/Microsoft to view the process that have open ports. Verify the process in question actually has the port open. If not fix the process configuration/installation as needed.

I'm trying to open a port for a specific application in Windows Firewall (in domain group policies), so I create an "inbound rule" allowing traffic to the specific port. Which is usually the way to go; just ensure to correctly specify the port/protocol and the scope for your rule The problem is that the connection is not working. I disabled the firewall, I turn down the antivirus, and the connection is somehow blocked. When I run netstat -an and add the filter to show the "listening" ports, the port that I opened before in the inbound rules is not appearing. This has nothing to do with the firewall, assuming you're dealing with a TCP port, try running the following netstat -oan|find "LISTEN" then check if the port you want to publish is shown as "LISTENING" if that isn't the case, then there is no application listening on such a port, so, even if you open it up in the firewall, connections to such a port will fail... since there's nothing there to "pick up the phone", so, first of all ensure that the application which should listen on that port is started and working correctly and that the port is shown in "LISTENING" state, next, create and enable your firewall rule Notice that, in case you're unsure about the port used by the app, the above netstat output will still help you; just fire up the task manager and check the process ID for your app, then look at the netstat list and find out which ports belonging to that same PID are in "listening" state HTH

Hi Gunner, thanks a lot for your response. I run tcpview and the proccesses in question are in "Linstening" state.

Thanks ObiWan for your response. Yes I was confusing about that, I thought netstat will show the blocked or allowed ports in firewall. Ok I get it now. The application i'm using uses a TCP port (that is actually "listening" with the command you mention). To be specific I'm trying to access remotely from a pc in the same lan to a server running SQL Analysis Services. Because I'm using a named instance, I need to allow traffic through TCP port 2382, so this port is "listening" but still has no access from another pc. I know this is another topic, but I want to determine if this is a firewall problem or a SSAS problem.

Thanks ObiWan for your response. Yes I was confusing about that, I thought netstat will show the blocked or allowed ports in firewall. Ok I get it now. The application i'm using uses a TCP port (that is actually "listening" with the command you mention). To be specific I'm trying to access remotely from a pc in the same lan to a server running SQL Analysis Services. Because I'm using a named instance, I need to allow traffic through TCP port 2382, so this port is "listening" but still has no access from another pc. I know this is another topic, but I want to determine if this is a firewall problem or a SSAS problem. Ok, so, start by ensuring your firewall rule is in place and also ensure to enable firewall logging for both, dropped and accepted connections, then, move to another computer (the "client" if you want) and download this program then unzip it into whatever suitable folder and, from a command prompt run the following sl -bpt 2382 192.0.2.1 replacing "192.0.2.1" with your server's IP, the above will scan the server to check if the port 2382 is open (for more infos see the scanline docs); if that isn't the case, go back to the server and check the firewall log, if it's the firewall which blocked the connection you'll see an entry in the log, if, otherwise there won't be any entry, then the "filtering" happens somewhere else [edit] Forgot; check which IP the port is bound to; if it's listening on 0.0.0.0 then it will answer on any IP but if it's shown as listening on 127.0.0.1 then... I don't think you'll be able to connect to that port from another host :) - also, check the MS SQL security settings and ensure that the analysis service was configured to accept connections from external hosts otherwise the port may even be open/listening, but the service will refuse external connections

Just for testing, I turned off the firewall. So I ran scanline from the client and the port is opened. With the firewall turned off (even stopped the service) I still can't access the SSAS server. The server is listening on 0.0.0.0. I have a question, where else the "filtering" could be happening? I can access SQL Database Engine, but not Analysis Services. I found this thread http://social.msdn.microsoft.com/forums/en-US/sqlanalysisservices/thread/fe56b6a6-dd02-4488-acba-df2f81aaa098/ a couple days ago, and my problem is exactly the same, because that thread has no response for the problem I thought it might be a Firewall or security problems. I will try to reopen that thread.

Well, things can't be worst now! Now I can't access the Database engine! Yesterday I was able to connect to the SQL Database Server with Excel, now I can't, I don't know what I've changed!

Just for testing, I turned off the firewall. So I ran scanline from the client and the port is opened. With the firewall turned off (even stopped the service) I still can't access the SSAS server. The server is listening on 0.0.0.0. Does the port appear open when the firewall is turned ON ? I have a question, where else the "filtering" could be happening? Well, not so easy to tell, it depends from "what is between" your server and the client, including hardware (network appliances) and software (e.g. ipsec policies...) I can access SQL Database Engine, but not Analysis Services. I found this thread http://social.msdn.microsoft.com/forums/en-US/sqlanalysisservices/thr ead/fe56b6a6-dd02-4488-acba-df2f81aaa098/ a couple days ago, and my problem is exactly the same, because that thread has no response for the problem I thought it might be a Firewall or security problems. I will try to reopen that thread. Hmm... did you look at the "SQL server attack surface configuration" ? See, that tool may just forbid connection coming from whatever external IP address if the services are configured to only allow local connections also, and since you're at it, check the SQL server network configuration and try disabling the use of dynamic ports (see the SQL server help for details)

Yes, the port appears open when the firewall is turned on as well. And yes, I checked the surface configuration, and I disabled the dynamic ports, so I'm using a fixed port. Today I tried something else. I tred to connect to another computer that is running Windows 7 and has SQL Server installed and has the exact same configuration as the server. This laptop is on the same LAN as the server. So, I built a cube in that laptop and when I tried connecting remotely it connects with no problems! So, definetly, is not a SQL Server configuration problem, I think the problem is with some secuirity problems in Windows 2008. As I said before, this is a test server so there's another roles running like Active Directory and DNS. I remember that when I installed SQL Server on the server it warns me that it was not recommended to install SQL Server on the same server running a DNS, but I don't know if that could be the problem. Thanks again!

Yes, the port appears open when the firewall is turned on as well. And yes, I checked the surface configuration, and I disabled the dynamic ports, so I'm using a fixed port. Today I tried something else. I tred to connect to another computer that is running Windows 7 and has SQL Server installed and has the exact same configuration as the server. This laptop is on the same LAN as the server. So, I built a cube in that laptop and when I tried connecting remotely it connects with no problems! So, definetly, is not a SQL Server configuration problem, I think the problem is with some secuirity problems in Windows 2008. As I said before, this is a test server so there's another roles running like Active Directory and DNS. I remember that when I installed SQL Server on the server it warns me that it was not recommended to install SQL Server on the same server running a DNS, but I don't know if that could be the problem. Thanks again! Hmmm that "on the same LAN" makes me wonder; are you referring to the same "subnet" or to the fact that the computer is in the same AD domain ? See, in the first case the issue may be due to some "limitation" imposed by either the firewall or the SQL server "IP allow" lists; in the second the issue may be related to the fact that SQL server is using integrated (AD) authentication and the client machine is unable to correctly authenticate Now, given that the issue doesn't seem to be related to "network" (you wrote that the port is open) you may try opening a discussion on the SQL server forum to try solving the issue (in such a case... please post your results here, they may be useful to others with the same kind of issue)

Yes. They're on the same domain. I'm really urged do deploy cubes so what i did was installing SQL Server on another server running Windows 2008, and now it works well with no problems! I'm assuming that the problem was installing SQL Server on the same server running Active Directory, Group Policies and DNS Services. Thanks a lot for all your help!

Just found out the problem! It turns that the PC from where I was trying to connect to the server was connected to the domain but it was still running on a "local" user Windows profile, so I logged off and logged in with an administrator domain account and then I finally could connect with no problems. I think the issue was as you said before, SQL server is using AD authentication, and the client not. I thought that setting up "Impersonation info" to the domain administrator account was enough for that, but that wasn't. Thanks for your help again.

So the problem wasn't the ports, it was a logon problem. Go to this thread for the complete solution. http://social.technet.microsoft.com/Forums/en-US/sqlanalysisservices/thread/f6a915c6-87e3-4376-8161-158e4c8591ab