Testing Open Ports
Al
I want to clarify a few misconceptions I (think) I have about ports,
and specifically testing whether or not they are open.
1. Whats the best way to test if a port is open on a computer. I dont
nessecarily mean testing if its open to the internet, but just on the
computer - this rules out online port scanners since many PC's will be
behind a router, and I am not testing that, but more software based
firewalls that may be running.
1a. Does a service or program have to be listening on a port to test
if its open, or is there a way for example I could open a port on a
software based firewall, and test if its open without anything
listening on that port?
2. With netstat -an what do the *.* mean?
2a. It appears to me that netstat -an only show ports that are (a)
open and (b) have a program/service listening or using it?
3. Whats the best software to do this?
Any positive replies appreciated.
-Al
Danny Sanders
2) You "close" a port by uninstalling software that uses the port.
3) You "block" a port by opening it ( see #1) and putting a firewall in
front of it.
> 1a. Does a service or program have to be listening on a port to test
> if its open, or is there a way for example I could open a port on a
> software based firewall, and test if its open without anything
> listening on that port?
See # 1. Opening a port on the firewall is different from opening a port on
a computer.
> 2a. It appears to me that netstat -an only show ports that are (a)
> open and (b) have a program/service listening or using it?
See #1.
Hypothetically, if a port is open and no one is listening to accept the
communication on the other end, is the port *really* open?
hth
DDS
"Al" <biga...@gmail.com> wrote in message
news:fe3c624c-27ad-4526...@v37g2000prg.googlegroups.com...
why?
On Wed, 30 Sep 2009 11:35:11 -0700 (PDT), Al wrote:
x-post trimmed to 24HSHD from
microsoft.public.windows.networking.firewall,24hoursupport.helpdesk
>Hi All,
>
>I want to clarify a few misconceptions I (think) I have about ports,
>and specifically testing whether or not they are open.
Reading lots :-)
Port States
http://userpages.umbc.edu/~jeehye/cmsc491b/lectures/tcpstate/sld001.htm
If you really want the low down, writing, how it works and nitty gritty
of the whole setup,
The set of 3,
http://www.amazon.com/TCP-IP-Illustrated-1-Protocols/dp/0201633469
and the UNIX set
http://www.amazon.com/Unix-Network-Programming-Sockets-Networking/dp/0131411551
The RFCs of course
http://www.faqs.org/rfcs/rfc793.html
Establishing a connection
Closing a Connection
There is plenty of code about for TCP/IP server/client apps, you could
alter one to listen on lots of ports. As well as client / server apps.
>1. Whats the best way to test if a port is open on a computer. I dont
>nessecarily mean testing if its open to the internet, but just on the
>computer - this rules out online port scanners since many PC's will be
>behind a router, and I am not testing that, but more software based
>firewalls that may be running.
You write an app to scan ports, download a port scanner to run locally.
You wouldn't be able to determine if a software firewall is active, lack
of a client / server response because a listener isn't running isn't the
same.
You may be better off testing the services list for the names of known
firewall services as well.
>1a. Does a service or program have to be listening on a port to test
>if its open, or is there a way for example I could open a port on a
Yes, that's the idea of an open (state) of a port.
>software based firewall, and test if its open without anything
>listening on that port?
No, no listner isn't a response.
>2. With netstat -an what do the *.* mean?
That would be the several places to search / read where * is for port
not established :-)
>2a. It appears to me that netstat -an only show ports that are (a)
>open and (b) have a program/service listening or using it?
Yes, otherwise ports wouldn't exist to be listed.
>3. Whats the best software to do this?
A scan, well I would use
http://nmap.org/
You need the permission of security / lan admin for this, I have heard
of a few places where it's considered a security breach to run it.
>Any positive replies appreciated.
:->
www.google.com
network port scanner
http://netsecurity.about.com/cs/hackertools/a/aafreeportscan.htm
There are many sites with security tools, and lists such as
www.tucows.com , all categories IS/IT section.
http://download.cnet.com/windows/monitoring-software/
Likely to be other links to security tools in some of my older posts in
24HSHD as well.
Me
Penn...@derrymaine.gov
>1a. Does a service or program have to be listening on a port to test
>if its open, or is there a way for example I could open a port on a
>software based firewall, and test if its open without anything
>listening on that port?
www.GRC.COM has ShieldsUP!. This statement usually starts an argument,
but it will show if you have any open ports.
--
Because you always wanted to know what happens when you hit a piano key.
http://www.concertpitchpiano.com/grandactionanimated.gif
Brian Cryer
news:fe3c624c-27ad-4526...@v37g2000prg.googlegroups.com...
>
> I want to clarify a few misconceptions I (think) I have about ports,
> and specifically testing whether or not they are open.
Danny has given an excellent overview, which covers most points.
> 1. Whats the best way to test if a port is open on a computer. I dont
> nessecarily mean testing if its open to the internet, but just on the
> computer - this rules out online port scanners since many PC's will be
> behind a router, and I am not testing that, but more software based
> firewalls that may be running.
A simple way is to use telnet.
Open a new command prompt window and enter:
telnet computerName port
using the name of the computer and port that you wish to test.
If it simply says "Connecting To computerName..." and eventually times out
then there is either nothing listening on that port or its blocked. ANY
other response indicates that something is listening on that port.
Alternatively download cryping (command line utility) and you can use it to
test a port using:
cryping computerName -port port
It will indicate whether or not it could successfully connect to the port.
You can download it here http://www.cryer.co.uk/downloads/cryping/
Hope this helps.
--
Brian Cryer
www.cryer.co.uk/brian
Gerard Bok
<not.here@localhost> wrote:
>"Al" <biga...@gmail.com> wrote in message
>news:fe3c624c-27ad-4526...@v37g2000prg.googlegroups.com...
>> I want to clarify a few misconceptions I (think) I have about ports,
>> and specifically testing whether or not they are open.
>
>Danny has given an excellent overview, which covers most points.
>
>> 1. Whats the best way to test if a port is open on a computer. I dont
>> nessecarily mean testing if its open to the internet, but just on the
>> computer - this rules out online port scanners since many PC's will be
>> behind a router, and I am not testing that, but more software based
>> firewalls that may be running.
>
>A simple way is to use telnet.
>
>Open a new command prompt window and enter:
> telnet computerName port
>using the name of the computer and port that you wish to test.
>
>If it simply says "Connecting To computerName..." and eventually times out
>then there is either nothing listening on that port or its blocked. ANY
>other response indicates that something is listening on that port.
True. But alternatively, getting nothing in return with telnet
does not imply that nothing is listening on that port :-)
(As I recently found out when attempting to ascertain if a SSL
host was listening :-)
>Alternatively download cryping (command line utility) and you can use it to
>test a port using:
> cryping computerName -port port
>It will indicate whether or not it could successfully connect to the port.
>You can download it here http://www.cryer.co.uk/downloads/cryping/
Nice tool ! Correction: very nice tool!
And it gets a respons from SSL :-)
>Hope this helps.
Certainly helped me :-)
--
met vriendelijke groet,
Gerard Bok
2Sweet
it was successful.
From the result, am i right to say that traffic flows on both ways (inbound
& outbound) are NOT blocked???
"Brian Cryer" <not.here@localhost> wrote in message
news:NcSdnbMa0IfLX1jX...@pipex.net...
�n�hw��f
with news:Ot1Mj#heKHA...@TK2MSFTNGP02.phx.gbl:
> By running "telnet" command from a Windows 2003 server to internet
> website, it was successful.
> From the result, am i right to say that traffic flows on both ways
> (inbound & outbound) are NOT blocked???
>
>
www.grc.com
Click on "ShieldsUP" and test it yourself.
Also d/l "leaktest.exe" and run that.
--
http://www.youtube.com/watch?v=COaoYqkpkUA
cageprisoners.com|www.snuhwolf.9f.com|www.eyeonpalin.org
_____ ____ ____ __ /\_/\ __ _ ______ _____
/ __/ |/ / / / / // // . . \\ \ |\ | / __ \ \ \ __\
_\ \/ / /_/ / _ / \ / \ \| \| \ \_\ \ \__\ _\
/___/_/|_/\____/_//_/ \_@_/ \__|\__|\____/\____\_\
why?
microsoft.public.windows.networking.firewall,24hoursupport.helpdesk
On Fri, 11 Dec 2009 13:05:57 +0800, 2Sweet wrote:
Just catching up?
-->>> On Fri, 2 Oct 2009 10:05:18 +0100, "Brian Cryer"
<not.here@localhost> wrote: >"Al" <bigal...@gmail.com> wrote in message
>news:fe3c624c-27ad-4526...@v37g2000prg.googlegroups.com...
>> I want to clarify a few misconceptions I (think) I have about ports,
>> and specifically testing whether or not they are open. >Danny has
>By running "telnet" command from a Windows 2003 server to internet website,
>it was successful.
>From the result, am i right to say that traffic flows on both ways (inbound
>& outbound) are NOT blocked???
Yes, think about it. If outbound didn't get to the server it couldn't
get back with an inbound message.
>
>"Brian Cryer" <not.here@localhost> wrote in message
>news:NcSdnbMa0IfLX1jX...@pipex.net...
>> "Al" <biga...@gmail.com> wrote in message
>> news:fe3c624c-27ad-4526...@v37g2000prg.googlegroups.com...
>>> Hi All,
>>>
>>> I want to clarify a few misconceptions I (think) I have about ports,
>>> and specifically testing whether or not they are open.
>>
>> Danny has given an excellent overview, which covers most points.
>>
>>> 1. Whats the best way to test if a port is open on a computer. I dont
>>> nessecarily mean testing if its open to the internet, but just on the
>>> computer - this rules out online port scanners since many PC's will be
>>> behind a router, and I am not testing that, but more software based
>>> firewalls that may be running.
>>
<snip>
Me
Mr. Majestic
> By running "telnet" command from a Windows 2003 server to internet
> website, it was successful.
> From the result, am i right to say that traffic flows on both ways
> (inbound & outbound) are NOT blocked???
>
If outbound traffic is initiated by a program running on a computer from
behind any type of firewall to a remote site, that is a solicited
traffic. The firewall is going to allow inbound traffic form a solicited
site. The firewall will block all unsolicited inbound traffic from a site.
A firewall will not block unsolicited traffic if a port on the firewall
is opened to allow unsolicited inbound traffic. As an example, port 80
being open on a firewall that a computer behind a the firewall is
listening on port 80 hosting a Web server. The client's browser must
initiate and send unsolicited inbound traffic to the Web server before
the Web server knows the client is there.
2Sweet
8080, 8443 & 443 to perform updownloading task automatically by schedule.
But always failed! I tried using IE to access, no problem) When i perform
telnet (to those ports) on the application server to the internet server.
It was successful. I feedback to the application vendor and they claimed
that i have to allow inbound traffic as well for those ports.
That is why i was wondering do i have to "allow inbound" traffic for ports
8080, 8443 & 443. But i can access the website using IE.
Is there different by using IE and Command to access the website?
"Mr. Majestic" <Maje...@Majestic7.com> wrote in message
news:HKOdnWoccb5YCr_W...@earthlink.com...
why?
x-post trimmed to 24HSHD.
On Sat, 12 Dec 2009 06:17:49 +0800, 2Sweet wrote:
>I have an application server which will access an internet website via ports
>8080, 8443 & 443 to perform updownloading task automatically by schedule.
Using MS Scheduled Tasks?
>But always failed! I tried using IE to access, no problem) When i perform
It's your firewall log that tells you exactly how it's failing or simply
that the command produces no result?
Using IE how, a URL like?
http://external.server.name:8080/
>telnet (to those ports) on the application server to the internet server.
By
telnet external.server.name 8443
>It was successful. I feedback to the application vendor and they claimed
>that i have to allow inbound traffic as well for those ports.
Sounds sensible, depends on the FW you are using. Even MS FW has port /
application to allow settings you may need to add an exception to.
>That is why i was wondering do i have to "allow inbound" traffic for ports
>8080, 8443 & 443. But i can access the website using IE.
So you haven't yet?
Check the FW permissions / inbound rule for telnet.
>Is there different by using IE and Command to access the website?
There is a difference using MS Scheduled Tasks, these don't by default
always run as the logged in user or for that matter no user if no one is
logged in. It's Local System Account or the specified user. You may have
to give Local System Account access to the executable / folder the
command requires to run.
>
>"Mr. Majestic" <Maje...@Majestic7.com> wrote in message
>news:HKOdnWoccb5YCr_W...@earthlink.com...
>> 2Sweet wrote:
>>> By running "telnet" command from a Windows 2003 server to internet
>>> website, it was successful.
>>> From the result, am i right to say that traffic flows on both ways
>>> (inbound & outbound) are NOT blocked???
>>>
>>
>> If outbound traffic is initiated by a program running on a computer from
>> behind any type of firewall to a remote site, that is a solicited traffic.
>> The firewall is going to allow inbound traffic form a solicited site. The
>> firewall will block all unsolicited inbound traffic from a site.
>>
>> A firewall will not block unsolicited traffic if a port on the firewall is
>> opened to allow unsolicited inbound traffic. As an example, port 80 being
>> open on a firewall that a computer behind a the firewall is listening on
>> port 80 hosting a Web server. The client's browser must initiate and send
>> unsolicited inbound traffic to the Web server before the Web server knows
>> the client is there.
Me
Mr. Majestic
> I have an application server which will access an internet website via
> ports 8080, 8443 & 443 to perform updownloading task automatically by
> schedule. But always failed! I tried using IE to access, no problem)
> When i perform telnet (to those ports) on the application server to the
> internet server. It was successful. I feedback to the application vendor
> and they claimed that i have to allow inbound traffic as well for those
> ports.
>
your firewall, then you have to do so. An application on your machine
where you initiate the contact to a remote site may need the ports on
your end opened on the firewall, which must be done manually by you by
setting firewall rules to open the ports.
In this case and if your firewall has the ability to set firewall rules
by port number and IP, then you open the ports to the vendor's IP only,
blocking all other IP(s).
> That is why i was wondering do i have to "allow inbound" traffic for
> ports 8080, 8443 & 443. But i can access the website using IE.
> Is there different by using IE and Command to access the website?
>
>
I think you're going to have to open the ports on the firewall to the
vendor's IP.
2Sweet
"telnet" command to remote site are successful (to those ports mentioned).
Based on the result, am i right to said that those ports (8080, 8443 & 443)
are already allowed on both inbound & outbound traffic?
"Mr. Majestic" <Maje...@Majestic.com> wrote in message
news:xqydnbnNyql7fL_W...@earthlink.com...
2Sweet
I run the "CryPing" command from my application server to ping the internet
remote site ports (8080, 8443 & 443). All results are "Successful connection
to ......"!
So am i right to said that those ports are allowed on both inbound &
outbound traffic?
"Brian Cryer" <not.here@localhost> wrote in message
news:NcSdnbMa0IfLX1jX...@pipex.net...
why?
x-post trimmed to 24HSHD from
microsoft.public.windows.networking.firewall,24hoursupport.helpdesk
On Mon, 14 Dec 2009 01:31:32 +0800, 2Sweet wrote:
>Thank for the CryPing uitility.
>I run the "CryPing" command from my application server to ping the internet
>remote site ports (8080, 8443 & 443). All results are "Successful connection
>to ......"!
>So am i right to said that those ports are allowed on both inbound &
>outbound traffic?
As sort of mentioned already, those ports are open to the application
requesting the connection.
It's assumed the sever app you still want to run isn't running
correctly.
In Windows Firewall you can set Exceptions by program / port. You can
also turn on logging, set services per network connection.
If you can figue out the conversations / how it works you can use a
packet trace tool like -
http://www.nirsoft.net/utils/smsniff.html
You don't need to install a driver, as noted on the site there are some
limitations with that.
>"Brian Cryer" <not.here@localhost> wrote in message
>news:NcSdnbMa0IfLX1jX...@pipex.net...
>> "Al" <biga...@gmail.com> wrote in message
>> news:fe3c624c-27ad-4526...@v37g2000prg.googlegroups.com...
>>> Hi All,
>>>
>>> I want to clarify a few misconceptions I (think) I have about ports,
>>> and specifically testing whether or not they are open.
>>
>> Danny has given an excellent overview, which covers most points.
>>
>>> 1. Whats the best way to test if a port is open on a computer. I dont
>>> nessecarily mean testing if its open to the internet, but just on the
>>> computer - this rules out online port scanners since many PC's will be
>>> behind a router, and I am not testing that, but more software based
<snip>
Me
Brian Cryer
news:%23NYWeoB...@TK2MSFTNGP02.phx.gbl...
> Thank for the CryPing uitility.
> I run the "CryPing" command from my application server to ping the
> internet remote site ports (8080, 8443 & 443). All results are "Successful
> connection to ......"!
> So am i right to said that those ports are allowed on both inbound &
> outbound traffic?
As others have already said, yes, if you can "cryping" or telnet
successfully to those ports then it means that something is listening on
those ports. So they are not blocked by your firewall AND an application is
listening on those ports.
--
Brian Cryer
www.cryer.co.uk/brian
Brian Cryer
One thing to add, inbound and out-bound is not quite the same. You could
have a scenario where a firewall allowed inbound connections on a port but
blocked outbound. This would allow (for example) a webserver to respond
successfully to requests on port 8080 and yet block an application that then
tried to connect out on port 8080. This is because a connection is a
conversation, you connect on port 8080 (or whatever) and can then send and
receive. It is the initial connection (inbound or outbound) which a firewall
may block. So a firewall may allow a connection in one direction but not the
other.
--
Brian Cryer
www.cryer.co.uk/brian
Brian Cryer
>I have an application server which will access an internet website via
>ports 8080, 8443 & 443 to perform updownloading task automatically by
>schedule. But always failed! I tried using IE to access, no problem) When i
>perform telnet (to those ports) on the application server to the internet
>server. It was successful. I feedback to the application vendor and they
>claimed that i have to allow inbound traffic as well for those ports.
>
> That is why i was wondering do i have to "allow inbound" traffic for ports
> 8080, 8443 & 443. But i can access the website using IE.
> Is there different by using IE and Command to access the website?
When you tested the ports 8080, 8443 and 443 using telnet (and cryping) you
were establishing that you could connect TO that server from your current
PC/server. It doesn't follow that you could necessarily connect out in the
opposite direction (because inbound and outbound rules can be different) or
that you could connect from a different PC (as it may have a different
firewall with different rules).
So, few ideas many of which I'm sure you've already tried. I'm assuming that
you are connecting from your application server to a remote server.
1. Your telnet/cryping test was from your application server to the remote
server? and not from any other pc/server?
2. What is the application that is running on your application server? or
more importantly, what account does it run under? If it is running as a
service or off the schedular then it may well be running under an account
which does not have access to the network (a security measure). So if your
application cannot connect to the ports you need then it may not be able to
connect to any network resource so check the account it is running under.
3. The windows firewall on a PC allows you to enable/block access for
individual applications. Not sure whether this is the case on a server, but
might be another area to investigate.
--
Brian Cryer
www.cryer.co.uk/brian
2Sweet
"Brian Cryer" <not.here@localhost> wrote in message
> "2Sweet" <chon...@hotmail.com> wrote in message
> news:uzyyH$qeKHA...@TK2MSFTNGP02.phx.gbl...
>>I have an application server which will access an internet website via
>>ports 8080, 8443 & 443 to perform updownloading task automatically by
>>schedule. But always failed! I tried using IE to access, no problem) When
>>i perform telnet (to those ports) on the application server to the
>>internet server. It was successful. I feedback to the application vendor
>>and they claimed that i have to allow inbound traffic as well for those
>>ports.
>>
>> That is why i was wondering do i have to "allow inbound" traffic for
>> ports 8080, 8443 & 443. But i can access the website using IE.
>> Is there different by using IE and Command to access the website?
>
> When you tested the ports 8080, 8443 and 443 using telnet (and cryping)
> you were establishing that you could connect TO that server from your
> current PC/server. It doesn't follow that you could necessarily connect
> out in the opposite direction (because inbound and outbound rules can be
> different) or that you could connect from a different PC (as it may have a
> different firewall with different rules).
>
> So, few ideas many of which I'm sure you've already tried. I'm assuming
> that you are connecting from your application server to a remote server.
>
> 1. Your telnet/cryping test was from your application server to the remote
> server? and not from any other pc/server?
Yes. telnet/cryping test from my application server to the internet remote
server.
>
> 2. What is the application that is running on your application server? or
> more importantly, what account does it run under? If it is running as a
> service or off the schedular then it may well be running under an account
> which does not have access to the network (a security measure). So if your
> application cannot connect to the ports you need then it may not be able
> to connect to any network resource so check the account it is running
> under.
I have double confirmed that it is using the correct access rights account.
>
> 3. The windows firewall on a PC allows you to enable/block access for
> individual applications. Not sure whether this is the case on a server,
> but might be another area to investigate.
Windows server firewall on both sides are not enabled.
> --
> Brian Cryer
> www.cryer.co.uk/brian
>
>
>
2Sweet
Telnet/cryping test the "outbound traffic" from application server to the
internet remote web server.
How to test the "inbound traffic" is allow???
"Brian Cryer" <not.here@localhost> wrote in message
news:15mdndBMOvEpmLvW...@pipex.net...
Brian Cryer
Are you able to run your application using the same account that YOU use? It
might be an interesting comparison.
--
Brian Cryer
www.cryer.co.uk/brian
Brian Cryer
> Ok, i will check the firewall rule again.
> Telnet/cryping test the "outbound traffic" from application server to the
> internet remote web server.
> How to test the "inbound traffic" is allow???
The important thing is that you are testing it in the direction that your
application will be using it. So if you are testing from your application
server to the remote server (which I think you've said in another post), so
the same "direction" as your application, then that is all you should need
to worry about - assuming that there are no other ports involved!! (which
there are for some protocols such as FTP.)
If you can telnet or cryping to those ports then it shows that something is
listening and that you are making a connection. From what you've said so far
makes me think that it isn't a firewall issue.
A couple of things which might be worth double checking (probably fine, but
worth a check):
1. That the IP address of the remote server is correct. Using the wrong IP
address (or DNS name or having a problem with DNS) could mean you are trying
to connect to the wrong server which might cause problems. Even if this all
works fine from the command line, double check that your application is
connecting using the correct IP address or DNS name.
2. Check that any NAT (on the remote end probably) is correct for each of
the ports - just to be sure that when you connect on say port 443 that it is
being routed internally to the correct server on the correct port. This is
probably not going to be an problem if this is an externally hosted server.
--
Brian Cryer
www.cryer.co.uk/brian
why?
x-post trimmed to 24HSHD from
On Tue, 15 Dec 2009 09:03:12 -0000, Brian Cryer wrote:
>"2Sweet" <chon...@hotmail.com> wrote in message
>news:e1Qou0Pf...@TK2MSFTNGP06.phx.gbl...
>> "Brian Cryer" <not.here@localhost> wrote in message
>> news:coydnWuu8fEolbvW...@pipex.net...
>>> "2Sweet" <chon...@hotmail.com> wrote in message
>>> news:uzyyH$qeKHA...@TK2MSFTNGP02.phx.gbl...
>>>>I have an application server which will access an internet website via
>>>>ports 8080, 8443 & 443 to perform updownloading task automatically by
>>>>schedule. But always failed! I tried using IE to access, no problem) When
>>>>i perform telnet (to those ports) on the application server to the
>>>>internet server. It was successful. I feedback to the application vendor
>>>>and they claimed that i have to allow inbound traffic as well for those
>>>>ports.
>>>>
>>>> That is why i was wondering do i have to "allow inbound" traffic for
>>>> ports 8080, 8443 & 443. But i can access the website using IE.
>>>> Is there different by using IE and Command to access the website?
>>>
>>> When you tested the ports 8080, 8443 and 443 using telnet (and cryping)
>>> you were establishing that you could connect TO that server from your
>>> current PC/server. It doesn't follow that you could necessarily connect
>>> out in the opposite direction (because inbound and outbound rules can be
>>> different) or that you could connect from a different PC (as it may have
>>> a different firewall with different rules).
>>>
<snip>
>>> 2. What is the application that is running on your application server? or
>>> more importantly, what account does it run under? If it is running as a
>>> service or off the schedular then it may well be running under an account
>>> which does not have access to the network (a security measure). So if
>>> your application cannot connect to the ports you need then it may not be
>>> able to connect to any network resource so check the account it is
>>> running under.
>>
>> I have double confirmed that it is using the correct access rights
>> account.
I wonder what that is?
>Are you able to run your application using the same account that YOU use? It
>might be an interesting comparison.
Still waiting for several answers and that's one of them :-)
From: why? <fgrirp*sgc@VAINY!Qznq.fpvragvfg.pbz>
Message-ID: <lll5i5l5kba0r51ts...@4ax.com>
-----
>8080, 8443 & 443 to perform updownloading task automatically by schedule.
Using MS Scheduled Tasks?
>that i have to allow inbound traffic as well for those ports.
Sounds sensible, depends on the FW you are using. Even MS FW has port /
application to allow settings you may need to add an exception to.
>That is why i was wondering do i have to "allow inbound" traffic for ports
>8080, 8443 & 443. But i can access the website using IE.
So you haven't yet?
There is a difference using MS Scheduled Tasks, these don't by default
always run as the logged in user or for that matter no user if no one is
logged in. It's Local System Account
You may have
to give Local System Account access to the executable / folder the
command requires to run.
-----
From: why? <fgrirp*sgc@VAINY!Qznq.fpvragvfg.pbz>
Message-ID: <s8hai5hhm206cajq1...@4ax.com>
It's assumed the sever app you still want to run isn't running
correctly.
-----
Me