Re: Connecting to Exchange...

That is correct, public IP is assigned to the external NIC of SBS. Yes, we are ONLY using Exchange, and only externally, not in-house. As for ISA, I'm not even sure what that is. Is it installed with a standard install of SBS Server? Is it something I can check to see if it's installed or running?

I think I posted a question somewhere on the forums that I would have gladly ONLY installed Exchange if I could. We just happened to own a license for SBS and thought we could implement Exchange without having to "re-purchase" just an Exchange license. At this point, we are not technically online with it and it would be very easy to reinstall anything over again if needed.



On 2008-06-26 08:01:06 -0500, "Cliff Galiher" <cgaliher@xxxxxxxxx> said:

No worries, but that means (in my previous list of points) that point 5 was, in fact, wrong. And when you confirmed it was true, we started down the wrong path.

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

Yes. A gateway.

Before we go any further, can you clarify...are you assigning a PUBLIC IP to the external NIC of SBS? Of this is so then the public IP is *not* held by a gateway. It is held by SBS.

Also, just to be sure, your initial post indicates that you are ONLY using exchange with SBS. This means that ISA is *not* installed and not configured?

-Cliff

"Ethon Bridges" <ethonbridges@xxxxxxxxx> wrote in message news:2008062516561616807-ethonbridges@xxxxxxxxxxx
I guess I should have said at the beginning, SBS is installed on a Dell PowerEdge server with two ethernet interfaces. One is configured for LAN, one for WAN. There is no router in between the ISP's connection and the SBS server. Basically the SBS server is hanging right off the WAN. I just assumed this was how all SBS installations were, two ethernet interfaces. We are not using the internal LAN for anything, but SBS seems to require it even so.

So it's not really that complicated. We just take a T1 output, split it via a hub, and run several servers, IP configured manually with different public static IP's off of that. Each server machine handles it's own security/firewall if necessary.

I assumed that even our ISP's router does some sort of basic NAT, but that is just to resolve the static IP's they give us, nothing more. I apologize if I applied a skewed definition of NAT to the situation.

So in essence, the WAN port (which is not the same interface as the LAN port) will not ping, but it does get out on the internet, and OWA will work through it. The LAN port (which is not the same interface as the WAN port) will ping, I can access SBS stuff through it if I want to, it seems to work.

On 2008-06-25 11:19:23 -0500, "Cliff Galiher" <cgaliher@xxxxxxxxx> said:

Okay...now I'm a bit confused. You don't have access to their router configuration, and it is configured to pass through? This implies that you are referring to a router on *their* end of the connection, not yours, and further that this isn't using NAT.

Rereading this thread, we talked about pinging from the LAN, so I figured this server was connected to the internet via NAT, but I realize now that this may not be the case. Is this a multi-homed server?? That would be a very odd configuration considering what 'appears' to be the rest of your network layout.

As far as windows firewall blocking the ping, sure it is possible. But again, I was running under the premise that your server was using a single connection for LAN and WAN via NAT, and if you can ping on the LAN then the WAN link is, as far as SBS is concerned, absolutely no different, so the firewall being interfereing would interfere with LAN pings as well. If it is a multi-NIC server though, that answer will obviously change.

The truth is that your configuration sounds ...odd. You can't use SBS DHCP (odd) and I get a slightly different picture of your network with each reply. Don't misunderstand me, that isn't an accusation, just an observation. Troubleshooting a complex network setup via a public forum is nearly impossible because properly conveying or understanding its complexities is difficult to do in this medium.

In essence, this forum is great for admins (beginning or advanced) with specific SBS questions, but I feel we've crossed over into network troubleshooting territory with your ping issue and that isn't SBS specific. AT this point you would be better served calling in a network engineer to help figure out that issue. Forums are great for helping admins with specific questions get answered, but is not (and should not) be a replacement for professional help.

With that said, if you are still having difficulty with getting RPC over HTTP working, let me know. That still falls squarely in the realm of an SBS issue that I'd be happy to continue working on.

-Cliff


"Ethon Bridges" <ethonbridges@xxxxxxxxx> wrote in message news:200806250414408930-ethonbridges@xxxxxxxxxxx
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: So why SBS?
    ... Public folders will be in the next version.. ... The sad part of most of us is that we haven't even tried or practiced a backup/restore and we freak out over a 'single" SBS box when we haven't even tried to restore it from a harddrive. ... Exchange seems to mix its words and titles, the global/generic use of POP and SMTP for just about every Exchange function is dumb, MailEnable understands post office protocol and simple mail transfer protocol in a "meaningfull" way. ... The standard profiles in Server are quite effective assuming you add new users to the correct account in the first place and your note running more than 1 file server. ...
    (microsoft.public.windows.server.sbs)
  • Re: Easy to use second 2000 Server for Exchange?
    ... Existing Exchange 2000 server - therefore have the CALs - so no new ones are ... Frank McCallister SBS MVP ...
    (microsoft.public.windows.server.sbs)
  • Re: So why SBS?
    ... Public folders will be in the next version.. ... If SBS isn't for you...that's fine. ... Mailenable is an example of a freeware or pay for extra's, mail server. ... It is infinitly simpler to configure than Exchange once installed. ...
    (microsoft.public.windows.server.sbs)
  • Re: Email for second domain
    ... The Microsoft Exchange MTA Stacks service is normally disabled on Exchange 2003 Servers on SBS 2003. ... You can safely ignore the MTA warning messages on the SBS 2003 server. ...
    (microsoft.public.windows.server.sbs)
  • RE: Configuring exchange 2003 in SBS
    ... As I know, this is not related to per user mailbox, it refer to the mailbox ... store on the whole Exchange server. ... This newsgroup only focuses on SBS technical issues. ... What minimum requirement if I want this server for a fileserver? ...
    (microsoft.public.windows.server.sbs)