Re: SBS 2003 Setup recommendation

Hey Stephen

Your suggestion about MTU looks very interesting. I have just tried doing
the ping -l and found that all packets above 992 is beeing fragmented. Now
if i want to lower the MTU I find serveral guides how to edit registry.

That is ok, but where should I change this MTU size to make this work?

1. (PDC) On the SBS2003 in hosting center?
2. (SDC) Fileserver in local LAN?
3. On all client computers?
4. In the Cisco PIX (Hardware VPN?)
5. In Cicso Software CPN client?
6. In the router/firewall?

In all 6 location or just some of them?

Thank you so far!

Regards
Anders

"stephen" <stephen@xxxxxxxxxxxxxxx> wrote in message
news:ef6HwkreGHA.1792@xxxxxxxxxxxxxxxxxxxxxxx
Anders wrote:
Hi

We want something lige the following setup: http://pings.dk/sbssetup.gif

SBS2003 is hosting in a remote locaiton and host mail and is PDC. Our
main department (Department A) connectes to the SBS2003 server over
VPN/internet. Department A has a SPC (Seconday DC) that is replicated
agaist SBS2003 server. Out setup is running now but is incredible
unstable and slow. It is NOT a bandwidth problem since the
upload/download bandwidth on the internet connection is almost never full
utilized.

The Start button on clients (Windows XP) often hangs (a system process is
running wild). Sometime Outlook 2003 hangs for 2-4 minutes and locs the
PC. Again. the internet connection is only moderatly used. The clients do
use the SBS2003 as PDC which maybe is not optimal but a slow setup would
for now be MUCH better than a unstable and hanging setup.

Things to notice:
--------------
SDC is Primary DNS server. (Is that OK?)
The setup has no WINS server (Is that nesscary? If yes were should it be
placed?)
Sometime two clients hang simultaneously while a third placed next to the
two other runs perfectly (for some time).

Hope someone can spot a critical setup error or has suggestions to how we
can "debug" our setup. We get no event errors on server/clients other
than "Application hang error" when outlooks stop responding.

Thanks in regards
Anders Jacobsen

Two things I would check are DNS and MTU issues.

IPSec adds a small overhead the size of a packet which would make packets
for the default MTU of 1500 needing to be fragmented. If path mtu
discovery is being used then the packets are sent with the DF packet set.
Misconfigured firewalls/routers may block the ICMP packets that should be
returned to tell the sender to drop the MTU. The result is stalled/slow
connections. One fix is to drop the mtu on all machines in the lan. You
can also fix misconfigured firewalls/routers under your control. You may
be able to control the used at your edge devices. You can test if large
packets can pass over your VPN with ping -l <size> and you can determine
the mtu with ping -f -l <size>.

If you can't pass large packets over the VPN, it may be a limitation of
the VPN hardware and not necessarily an MTU issue. (See KB below).

DNS is another source of trouble. I would double check your configuration
and, if possible, set up some sort of network sniffer to see if you're
getting good replies to the DNS queries being sent out.

Removing EDNS support (dnscmd /config /enableednsprobes 0), forcing
kerberos to use tcp instead of udp
(http://support.microsoft.com/kb/244474/en-us) can also solve some
mysterious networking problems.

-- stephen




.