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.