What to do when it all goes wrong

Over the past couple of weeks, I've been doing battle with a 2003 Small Business Server that is out to get me. It's true... Have you ever had one of those customers that just _nothing_ goes right? Well, it's their server, and it's been this way with them on everything we do since the very beginning.

In this case, I've had to join a new laptop to their domain for a new employee. The laptop just had a fit joining through the connect computer wizard. I did all of the things that one is supposed to do: I verified that the wireless NIC was disabled, etc. Eventually, by brute force, we got it joined to the domain. Something still wasn't right.

The laptop connected to exchange with no problem, but whenever this user wanted to access a shared drive, shared printer, etc., a dialog box would open up asking her to authenticate. Nothing would work to login and authenticate. Not her username, not the administrator account information, not domain\username or domain\administrator, etc.

Soooo, it looked like a group policy problem to me, and I did a net share and noticed that the sysvol wasn't there. Not good.

I started focusing my attention on the server. The more I dug into it, the more I noticed conflicting error messages, conflicting symptoms, etc. The Sysvol would show up if I typed Net Share in the command prompt, but if I went to the run menu (from the server) and typed \\servername\sysvol, I got an error. Hmm....

I ran the SBS Best Practice Analyzer and fixed the normal stuff that showed up on that (chimney stack, etc).

Here's what I finally did to solve the problem...

1) Sacrificed a small chicken...

then, I got really serious.

- Disabled RSS as per KB 936594

- Checked for SMB signing policies in gpmc.msc

- Made the changes in Default Domain Controller Policy:

- Microsoft network client: Digitally sign communications (always) DISABLED

- Microsoft network client: Digitally sign communications (if server agrees) ENABLED

- Microsoft network server: Digitally sign communications (always) DISABLED

- Microsoft network server: Digitally sign communications (if client agrees) ENABLED

- Domain member: Digitally encrypt or sign secure channel data (always) DISABLED

- Domain member: Digitally encrypt secure channel data (when it is possible) ENABLED

- Domain member: Digitally sign secure channel data (when it is possible) ENABLED

- Domain member: Require strong (Windows 2000 or later) session key DISABLED

- Did gpupdate /force

- Client machines were able to access shares

I'm not sure what patch, etc changed some of these settings, but after doing this, I could see the sysvol locally. When I went back to the laptop, I rebooted, and had no problems with this user's machine accessing server resources.

I've never had this happen before, but am thankful it is finally resolved.

Testing elusive network problems

In the past, I’ve had quite a few customers that have ‘mysterious’ network issues in their environment. In most cases, they are elusive and difficult to track down. Seriously, it could be anything from old wiring to a faulty switch to a bad network card, etc. The first step is to create a batch file to run at the command prompt to isolate the issue. I tend to run this from each of the machines. Once I’ve executed this, I’ll break out our Test-Um network Kit (http://www.test-um.com/validator/ ) and get serious about isolating the problem.

I've copied a sample run from my network below. Here's
the rundown. Feel free to substitute your addresses in
and run the pings on your network.

Step 1 pings 127.0.0.1 to make sure your network stack
is working. If this is hosed it's most likely a
Windows problem

Step 2 pings the LAN interface of my local machine.
This should show that the adaptor is up and working.
It may be disconnected or have other problems, tho.

Step 3 pings another machine on the local network.
Tests the hub/switch, isolates for possible server
problem.

Step 4 tests the local/backend interface of the
server. If step 3 is ok then look for a bad switch
port, cable to server, other network gear in the way,
or NIC on server.

Step 5 tests local naming.

Step 6 tests the front-end/Internet connection of your
SBS server or other router. This isolates the
connection to your dsl/cable/t1/ oc3 internet
connection.

Step 7 tests internet by IP address, isolating for DNS
problems. 4.2.2.1 is verizon/genuity/ level3/whoever
they are now's public DNS servers.

Step 8 tests for named connection to internet by
pinging google.

Here's output from a similar script on my network:

STEP 1: localhost/network stack
C:\Windows\system32 >ping 127.0.0.1

Pinging 127.0.0.1 with 32 bytes of data:

Reply from 127.0.0.1: bytes=32 time<1ms ttl="128" bytes="32" ttl="128" bytes="32" ttl="128" bytes="32" ttl="128" sent =" 4," received =" 4," lost =" 0" minimum =" 0ms," maximum =" 0ms," average =" 0ms">ping 192.168.9.118

Pinging 192.168.9.118 with 32 bytes of data:

Reply from 192.168.9.118: bytes=32 time<1ms ttl="128" bytes="32" ttl="128" bytes="32" ttl="128" bytes="32" ttl="128" sent =" 4," received =" 4," lost =" 0" minimum =" 0ms," maximum =" 0ms," average =" 0ms">ping 192.168.9.50

Pinging 192.168.9.50 with 32 bytes of data:

Reply from 192.168.9.50: bytes=32 time=2ms TTL=64
Reply from 192.168.9.50: bytes=32 time=2ms TTL=64
Reply from 192.168.9.50: bytes=32 time=2ms TTL=64
Reply from 192.168.9.50: bytes=32 time=2ms TTL=64

Ping statistics for 192.168.9.50:
Packets: Sent = 4, Received = 4, Lost = 0 (0%
loss),
Approximate round trip times in milli-seconds:
Minimum = 2ms, Maximum = 2ms, Average = 2ms

STEP 4: SBS be
C:\Windows\system32 >ping 192.168.9.101

Pinging 192.168.9.101 with 32 bytes of data:

Reply from 192.168.9.101: bytes=32 time=3ms TTL=128
Reply from 192.168.9.101: bytes=32 time=2ms TTL=128
Reply from 192.168.9.101: bytes=32 time=2ms TTL=128
Reply from 192.168.9.101: bytes=32 time=2ms TTL=128

Ping statistics for 192.168.9.101:
Packets: Sent = 4, Received = 4, Lost = 0 (0%
loss),
Approximate round trip times in milli-seconds:
Minimum = 2ms, Maximum = 3ms, Average = 2ms

STEP 5: SBS by name
C:\Windows\system32 >ping lilbro

Pinging lilbro.CharlandGrap hics.local [192.168.9.101]
with 32 bytes of data:

Reply from 192.168.9.101: bytes=32 time=1ms TTL=128
Reply from 192.168.9.101: bytes=32 time=63ms TTL=128
Reply from 192.168.9.101: bytes=32 time=2ms TTL=128
Reply from 192.168.9.101: bytes=32 time=1ms TTL=128

Ping statistics for 192.168.9.101:
Packets: Sent = 4, Received = 4, Lost = 0 (0%
loss),
Approximate round trip times in milli-seconds:
Minimum = 1ms, Maximum = 63ms, Average = 16ms

C:\Windows\system32 >

STEP 6: SBS fe
C:\Windows\system32 >ping 24.177.54.186

Pinging 24.177.54.186 with 32 bytes of data:

Reply from 24.177.54.186: bytes=32 time=15ms TTL=128
Reply from 24.177.54.186: bytes=32 time=36ms TTL=128
Reply from 24.177.54.186: bytes=32 time=2ms TTL=128
Reply from 24.177.54.186: bytes=32 time=2ms TTL=128

Ping statistics for 24.177.54.186:
Packets: Sent = 4, Received = 4, Lost = 0 (0%
loss),
Approximate round trip times in milli-seconds:
Minimum = 2ms, Maximum = 36ms, Average = 13ms

C:\Windows\system32 >

STEP 7: outside by IP
C:\Windows\system32 >ping 4.2.2.1

Pinging 4.2.2.1 with 32 bytes of data:

Reply from 4.2.2.1: bytes=32 time=27ms TTL=248
Reply from 4.2.2.1: bytes=32 time=17ms TTL=248
Reply from 4.2.2.1: bytes=32 time=16ms TTL=248
Reply from 4.2.2.1: bytes=32 time=17ms TTL=248

Ping statistics for 4.2.2.1:
Packets: Sent = 4, Received = 4, Lost = 0 (0%
loss),
Approximate round trip times in milli-seconds:
Minimum = 16ms, Maximum = 27ms, Average = 19ms

STEP 8: Outside by name
C:\Windows\system32 >ping news.google. com

Pinging news.l.google. com [64.233.179. 104] with 32
bytes of data:

Reply from 64.233.179.104: bytes=32 time=73ms TTL=239
Reply from 64.233.179.104: bytes=32 time=94ms TTL=239
Reply from 64.233.179.104: bytes=32 time=115ms TTL=239
Reply from 64.233.179.104: bytes=32 time=136ms TTL=239

Ping statistics for 64.233.179.104:
Packets: Sent = 4, Received = 4, Lost = 0 (0%
loss),
Approximate round trip times in milli-seconds:
Minimum = 73ms, Maximum = 136ms, Average = 104ms

C:\Windows\system32 >