I just got IIS7 set up on a Windows Server 2008 R2 machine in VirtualBox. After doing so, I could not connect from any other client, though http://localhost worked. For that matter, I was unable to even ping the server.
After doing some research, I found that enabling File and Print Sharing on the server solved the problem, but surely there has to be a better way, and I would much prefer to learn to use the best method, rather than the easiest one.
What, specifically, should I do to enable both pinging of the server as well as access to the web server running on it?
Isn't it that the inbound web HTTP port is blocked by default? I'm not a server guru but can remember going to the firewall to allow it through. Should already be there.
Out of the box on Windows Server 2008/2008R2 firewall is installed and users cannot access resources or services on the server unless you configure exceptions to the firewall. There is one exception to this are services/resources on this server that you make available through the GUI tools (Initial Configuration Tasks Wizard, Server manager) - these automatically create firewall required exceptions for you.
So in your case either upon File and Print Sharing installation or upon using File and Print Sharing config wizard/Shared resource provision wizard (most likely the later) required firewall exception was created for you. The rule in question is: File and Printer Sharing (Echo Request – ICMPv4-In) - actually allows ping, but I guess Windows also uses it for network resources discovery and other things implied by the role you installed.
Nothing prevents you from not enabling File and Print Sharing and just enabling mentioned firewall exception manually.
Related
We have run into a problem with IIS, TLS 1.2 and domain users. I searched SO and other forums, but all possibly related topics didn't lead me to a solution.
Please don't judge the configuration, it wasn't invented by me, I just need to solve this problem.
What happens is the following:
We have an old web application, that opens an executable with Process.Start and that executable calls an external webservice. This used to work fine with TLS 1.0, but in the near future, the external webservice demands TLS 1.2.
So now we are trying to make this work, and we are almost there: we upgraded the executable's .Net Framework version to 4.7.2 and enabled TLS 1.2 on the Windows Server 2008 R2. The web app's .Net Framework version is set to 4.6.1. It seems to me that this should be everything there is to it.
And indeed, when we run the executable stand alone (not called by the web app) from the server, so owned by the domain user logged on to the server (with RDP), everything works as expected; we receive the proper answer from the web service.
Also, when we call the executable by the web app and in IIS the application pool identity is set to a build in account: ApplicationPoolIdentity, everything works as expected as well.
But, when we set the application pool identity to a dedicated domain account (so a different one than the one that executed the executable earlier), the trouble begins. Connecting the web service fails with the following exception:
System.ServiceModel.EndpointNotFoundException: There was no endpoint
listening at https://<some url>/<some webservice name>.asmx that could
accept the message. This is often caused by an incorrect address or
SOAP action. See InnerException, if present, for more details. --->
System.Net.WebException: Unable to connect to the remote server
---> System.Net.Sockets.SocketException: A connection attempt failed because the connected party did not properly respond after a
period of time, or established connection failed because connected
host has failed to respond ...
Now the question is of course, what could be causing this?
I like to believe that the failing domain account is configured correctly, but it seems it is not. Or could it be something else, that I don't even know the existence of...
EDIT:
I managed to narrow it down to a permissions issue: when the dedicated domain account runs the application stand alone, it works as it should. When the dedicated account runs it from within the IIS context (started by the web app), it doesn't work, but when the dedicated account is given admin rights, it also works as expected.
That leaves me to the question: what additional permissions does IIS need to allow this setup? Maybe in combination with TLS 1.2 thingies.
Any help would be greatly appreciated.
I'm a rookie so I'm not really acquainted with how this really works. I've downloaded SQL Server 2016 and once I log onto the Management Studio, it asks me to connect to a particular server.
I've no idea what server I should connect to. I've tried everything. Turned the firewall off, used cmd commands, (tells me that my access has been denied), registered a new server from within the studio (but nothing shows up in the Server Name drop-down) I'm really confused.
What server should I connect to?
Make sure that the server has TCP connections enabled (either following this guide https://msdn.microsoft.com/en-us/library/ms191294.aspx or by specifying /tcpenabled=1 flag to the installer).
Make sure you have remote access enabled (sp_configure N'remote access',N'1')
Make sure the firewall is configured to let you through or just disable it (only do so if the SQL Server is installed in a disposable VM): netsh advfirewall set allprofiles state off
I wrote a blog post on how to install SQL Server properly.
I'm not sure I can adequately explain my dilemma, but here goes...
Our company has its own web server at xyz.com. I have a Win 7 Pro machine running a non-HTTP server program that communicates with an iPhone app used by our field crews. The path to this machine from outside the network is abc.xyz.com, and it's set for port 5000. The app, then, is programmed to exchange data (ASCII only) with the server at abc.xyz.com:5000. The server program is written in VB, and the system works very well like that.
What I would like to do now is to add IIS to this same machine and open it on port 5001, so I can run asp.net pages that will enhance the functionality of the app for our crews. The URL would be abc.xyz.com:5001, and they will access it through their phone browsers.
I have IIS 7.5 installed on the machine, and I have started it running with the "default web site," and I have the binding set for port 5001. So far I am able to access the IIS "Welcome" page only from the same machine. I can't get it to come up on any other machine either inside or outside the network.
In searching for clues for this problem, all I read indicates that it's pretty much a snap to get a web server running on your Windows 7 machine. But it hasn't been so much a snap for me. I've checked the sharing settings and the security settings, they seem to be ok, as best I can tell.
I am hoping that someone will help me identify some obscure setting somewhere that I am overlooking and get this going. But I also even wonder if this is something that can't be done, i.e. because there's another server program using the same path running on port 5000.
By the way, I am not the network administrator. I try to avoid getting him involved because he's difficult to work with. I am hoping that this is just between me and my server.
Thanks for any insight anyone can give me.
You mention that you can access the website from the machine itself on port 5001, but you can't access the site from another computer within the same network - this suggests to me that the Windows 7 built-in firewall is blocking the request - as it's a non-standard IIS port.
You should configure the firewall to allow incoming requests on port 5001. Open a command prompt (as administrator) and run the following:
netsh advfirewall firewall add rule name='IIS Website on Port 5001' dir=in protocol=TCP localport=5001 action=allow profile=any
I found the answer elsewhere on StackOverflow. I needed to add IUSR to the list of authorized users. So far I have tested it on my iPhone browser using 3G and it came through. Seems likely that it will work from anywhere, but I'm not yet ready to declare total success.
For a distributed production client-server WCF application (self-hosted as a Windows Service with NetTcpBinding), I am adding logic to add expception to Windows Firewall during the installation via netsh command.
I have noticed that the remote communication seems to work fine whether the firewall exception is for the program (the executable) or port. In our case, the port will very rarely be something other than the default and if it is then user can manually alter config files and firewall accordingly.
My question is, whether it is better to add the exception for program OR port OR both. Are there any security considerations making one approach more desirable than the other? Virtually all of the examples for WCF show port exceptions.
Any insight would be appreciated, thanks.
Here is my summary of how I think they function:
Application exception --> grants the specified application to open any ports
Port exception --> grants any application to open the specified port
As such, which one is better suited depends on the situation. Generally, the application exception would be preferred. At the time an application attempts to open a port, the Windows Firewall (if enabled) essentially would do a check to determine if that application or the port itself has been granted an exception.
MSDN states: "[Application exception] is more secure than opening a port, because the firewall is only open while the program is waiting to receive the connection."
More detailed MSDN summary and technical articles: http://technet.microsoft.com/en-us/network/bb545423.aspx
Ultimately, the system admin for the deployed software should be aware of and/or be the one who makes the changes to the firewall. What we plan on doing is having a step in the installer where the customer can opt-out of the firewall exception but explaining that remote clients will not be able to communicate without it. And of course the manual documentation will also outline the required ports for scenarios if other software or hardware firewalls are in place and need to be manually configured.
Guys, been knocking my head against the desk (instead of the mac) for hours. I'm running VS 2008 in a parallels VM. I can access the development server in the VM if local host is used, if I use the designated ip for the VM or try to access it externally it does not work. All firewalls are off and I verified that I can access iis externally.
Any Ideas what could be wrong?
I ran into this same problem and am using a TCP tunnel to bypass it. Download this Java app & just tunnel the traffic back. No messing with IIS necessary!
http://jcbserver.uwaterloo.ca/cs436/software/tgui/tcpTunnelGUI.shtml
In command prompt, you'd then run the java app like this... Let's assume you want external access on port 80 and your standard debug environment runs on port 1088...
java -jar tunnel.jar 80 localhost 1088
Yes, it is by design. Consider using IIS instead.
The first answer is that you can't do it because the development server is specifically made to just run locally, otherwise it becomes a security risk.
The second answer is that you can get around anything, this hints that there is a way to do it using a reverse-proxy (but the post he links to seems to be dead)
EDIT : After viewing RichardOD's answer, I fear that my answer below is wrong and you can not access it using IP.
But I suggest you to go with deploying it to IIS.
The VS2008 internal web server ( which I guess is cassini ) creates a port for your app and runs a web server for your app on that port. If you want to access it from outside the machine you have to use that port in addition to IP.