Re: Connecting to Exchange...

On 2008-06-25 02:15:14 -0500, "Cliff Galiher" <cgaliher@xxxxxxxxx> said:

I really wouldn't worry about the ping issue. The truth is that ping packets are a basic troubleshooting tool and a router *shouldn't* be monkeying with them. It is routable, but forwarding via NAT requires changing the actual packet. And changing a packet intended to to troubleshoot a connectivity issue defeauts the purpose of sending the packet in the first place...as the destination suddenly becomes ambiguous. It is just not wise to do so.

I can see three easy explanations for why you are seeing the behavior you are seeing though:

1) It sounds like your ISP configured the router initially. Even if they told you that they configured it to forward "everything" to the other servers, that probably really only means TCP or UDP packets...as that *is* everything as far as the real-world is concerned. They may have configured the devices to reply to pings...so what you are seeing is the device responding, not the end server.

Already thought of this and have confirmed that it is not the case. If I disconnect a server, I can no longer ping that IP. In addition, I can confirm that the server operating system is responding to the ping via logs and not the ISP's router.


2) The actually *did* configure the device to forward eerything via NAT and it is mangling ICMP packets. The other end servers are (improperly) responding to a ping simply because they received it and aren't validating the packet address. Windows, for its many faults, has a very robust TCP/IP stack and would discard an improperly addressed packet if it doesn't think it should reply. OpenSolaris and FreeBSD behave similarly, but linux just ...doesn't care. So...if this is the case, Windows is still behaving properly and this shouldn't be regarded as a problem.

One of the "servers" is a Windows machine and it does respond to pings from the outside, although it is not really a "server" OS, just a WinXP machine hanging off the WAN with a static IP. I don't know if the TCP on WinXP Pro is the same or different than the TCP on a "server" OS. I just assumed they were the same.

3) The ISP configured the original device and the device actually PROPERLY recreates NAT ping packets and passes them to the servers, but the SBS server was not part of that initial configuration. If you've added the SBS server yourself, and reconfigured the NAT device yourself, it is possible you overlooked forwaring ICMP packets properly. That would again result in other servers working, but SBS appearing broken.

Mmm....probably not. We don't tell our ISP when we add or remove servers or what kind of servers they are, nor whether there ARE any servers on any particular IP in our range, some of which have not ever been used. We don't have access to their router configuration and I'm sure they never do anything to it, it's just simply set to pass through everything.

Truthfully, if pinging on the LAN works, but pinging over the internet doesn't...some way or another the holdup is happening in the interconnect. And I fear this led you down a false path troubleshooting RPC over HTTP. Hope this helps you addresss both problems,

I really think it still points to SBS server. It may be true that Windows "has a very robust TCP/IP stack", but even so, it should be configurable to respond if one wanted it to. Nothing has been said further here about checking Window's firewall settings to see if it is blocking the outside request. Is it possible that the firewall is blocking this? I'm not terribly concerned about the pinging issue in terms of ultimately being able to get the server up and running, but it's one of those "want to know why" issues now for me.


"Ethon Bridges" <ethonbridges@xxxxxxxxx> wrote in message news:2008062418461143658-ethonbridges@xxxxxxxxxxx
On 2008-06-24 13:41:11 -0500, "Cliff Galiher" <cgaliher@xxxxxxxxx> said:

Just to make sure I have my facts straight (if they aren't then correct them please):

1) If I read your statement correctly, you *can* ping on the LAN.

Yes.

2) Pinging from outside fails.

Yes.

3) The outside connection is, in fact, an internet connection and not a private leased line.

Yes, we have a T1 with 16 static IP's.

4) SBS cannot run DHCP because another device is. That means that SBS has a static *private* IP on your LAN.

Correct. In reality, it's not another device. We run a mixed network and have another operating system handling DHCP. In reality, there seems to be no reason for this LAN connection as it is never connected to by this method. Always by the static IP. If there were some way to not configure it, I would.

5) Your public IP is held by another device (router, gateway, firewall appliance.)

Yes. A gateway.

6) Traffic is routed to SBS via this appliance.

Yes.

If all of those things are correct then I'll make a few observations:

1) Not being able to ping "the server" is probably not a sign of a problem...and is also technically inaccurate. The device that holds the public IP is responsible for answering pings, not SBS. In many cases, particularly with consumer-grade routers, they are specifically configured to ignore pings. You can dig into this and fix it, but it probaby is not the cause of, or related to, your outlook issue.

Our gateway is configured by our T1 provider to pass through everything. We have 6 other servers on this same connection, all of them respond to pings. The ability to respond to pings is configurable on each server. Only the SBS server does not respond which leads me to believe that something not set right in SBS. There is no firewall in between at the moment other than what may have been installed by SBS during installation.

2) You mentioned in your original post that you reconfigured the SBS page to redirect to OWA. This is very likely your problem. Outlook RPC over HTTP(s) requires the "RPC" virtual directory in IIS. This is configured by default for you with SBS, but if you are redirecting all incoming traffic to another virtual directory then outlook cannot reach that RPC virtual directory. And if it can't reach it, it cannot use that functionality to tunnel to exchange via HTTP. You can verify this by temporarily disabling your redirection.

This makes sense. I will try this and let you know the results. This at least logically separates the two problems into a ping problem and an Exchange access problem.


On 2008-06-24 10:42:39 -0500, "Cliff Galiher" <cgaliher@xxxxxxxxx> said:

First, you *really* should let SBS be the DHCP server. DHCP is a complicated beast that does more than just assign IP addresses. It also has various option flags that, in SBS-land, make other components work. Your router doesn't know and doesn't care about these flags...and you will end up having problems.

For example, The SBS DHCP server will make it the NTP time server for clients. Your router won't. If the clock on the client skews too much, you get kerberos problems....can't log in. And that is just an example off the top of my head. I understand the desire to keep your server minimalist and only run exchange, but DNS and DHCP should be considered "essential" SBS components.

Unfortunately, this is not an option.


Now, on to your other questions:

1) Are you pinging and trying to connect on the LAN or across a WAN link?

Pings on LAN, does not on WAN.

2) What is the client OS?

WinXP Pro

3) Was the computer joined to the domain using the connect computer wizard?

Do you mean the server computer itself? No. If you are talking about the client computer, no, because it is never at the server location an only needs Outlook Exchange.

4) Have you applied all service packs and updates to the server AND the client?

Yes.

5) Does the server or client have any third-party security products installed? If so, what are they?

No.

Not being able to ping sounds like a firewall issue, but pinpointing where that problem lies requires answers to one or more of the questions above...

-Cliff


"Ethon Bridges" <ethonbridges@xxxxxxxxx> wrote in message news:2008062408351416807-ethonbridges@xxxxxxxxxxx
I have recently installed SBS2003 on a Dell PowerEdge server.

I cannot ping my server or connect to Exchange with Outlook, however, I can log in to Exchange/OWA via a web browser using the server's static IP or DNS name.

I am not using anything else about SBS except Exchange at this point. I have another router providing DHCP and don't want anything else running except Exchange.

I currently have the main SBS page redirected to only the OWA page.

Can anyone help me through the process of figuring out why I can't ping or access the server with Outlook?


.

Relevant Pages

  • Re: Server/Network setup question
    ... currently the users are getting IP addresses from DHCP on the router. ... SBS server a static IP address in the same range as the router. ... be in a subnet that is different from the SBS LAN (with their own Internet ...
    (microsoft.public.windows.server.sbs)
  • Re: Server/Network setup question
    ... By performing a full installation yourself, looking at what you may wish to ... IP Address/mask, same subnet as router. ... An SBS installation is complete _ONLY_ after all items in the ... My server is coming with SBS pre-installed. ...
    (microsoft.public.windows.server.sbs)
  • Re: Urgent! New router and big disaster
    ... DNS on your server is broken. ... Les Connor [SBS Community Member - SBS MVP] ... and put in the ip of the router. ... The local router has the broadband connection ...
    (microsoft.public.windows.server.sbs)
  • Re: Urgent! New router and big disaster
    ... seleting full time broadband connection. ... Les Connor [SBS Community Member - SBS MVP] ... check the router as well and unless I missed a firewall setting on it, ... Anyway the Server Ipconfig /all is this... ...
    (microsoft.public.windows.server.sbs)
  • Re: PPPoE vs Double-NAT?
    ... "Frank McCallister SBS MVP" wrote: ... > My preference is PPPoE with the External NIC Static on the Routers LAN ... ie if Router LAN is 192.168.1.1 I set the NIC to ... >> I have an SBS 2003 Premium server that I need to relocate and reconnect to ...
    (microsoft.public.windows.server.sbs)
Loading