Ran across one today that hasn’t been documented to death in the ether, so it’s worth sharing. Bottom line, if you install Windows Sever 2003 SP2 and have ISA on the box, you dang well better follow KB927695 and disable Receive Side Scaling on your NICs. even better, don’t do the hack in the registry, just modify the properties of the NIC to disable the setting. Here’s another reason why:

I was working with someone who was having a number of problems on his new SBS box. We got a number of them fixed, then we were trying to join a workstation to the domain. He had tried many variations of this previously, but all had failed. Once we resolved his IIS issues, we decided to see what would happen with the ConnectComputer wizard.

Problem 1: You can’t get to the ConnectComputer wizard. We continually got a “page cannot be found” error when trying to connect to http://server/conectcomputer, just like the Add Client Workstation wizard says to do. We could access the page at http://internalIP/connectcomputer, but this doesn’t always work, either. We were finally able to get the page to load and at least get through the main portion of the wizard using https://server/connectcomputer/

Problem 2: The ConnectComputer wizard encountered errors and could not complete. This happened at the end of the wizard as it was trying to change network settings to initiate the reboot that would join the machine to the domain, etc., etc., etc. We looked in the client-side log for the ConnectComputer wizard (which is in C:\Program Files\Microsoft Windows Small Business Server\Clients\SBSNetSetup.log, by the way) and found the following error in the log:

NetJoinDomain() failed [1727]

Google found only a few posts about this specific error, mostly having to do with trying to join a workstation over a VPN when ISA is involved. Well, this server had ISA installed, but this is a local workstation and not over a VPN. Also worth noting is that it’s the first workstation to join the domain. But I digress. We followed the advise about turning off Strict RPC checking in ISA (which I regularly forget to do and hate that I have to in the first place) but that had no effect. Just when I was about to punt, I discovered that SP2 had been installed on the box.

Yes, the dreaded Windows 2003 Server SP2. The one that has actually been causing more issues than MS cares to admit right now. And the only reason he installed it when he built the server? Because it was listed in Microsoft Updates through the web, and since it’s up there, it must be safe to install, right? In this case, I certainly wouldn’t have installed it, but that’s just me. Oops, digressing again.

So I reviewed the Official SBS Blog for stuff about SP2 and found the note on the Receive Side Scaling. The server had broadcomm NICs (which have issues in themselves), so I went into the NIC settings through Network Connection Properties and disabled Receive Side Scaling on both the internal and external NIC. Viola! ConnectComputer not only ran successfully, but we were able to access it through http://server/connectcomputer without SSL.

I’ll be darned if I can understand exactly why changing this setting when SP2 and ISA are on the box had this type of impact on local networking, but as soon as I changed it, everything worked. I liken this to the other bizarre resolution where changing the internal name on a security group allows the Connect to the Internet wizard to run correctly (look down at the last entry in the thread for the real resolution) – can’t explain fully why it works, but it does.

Moral of the story – read everything about SP2 on the SBS blog and even if you think you may not be affected, look at each one of the items listed there. Or don’t put SP2 on any of your boxes just yet. The latter is the direction I’m taking when I have an option.

I’ve been fighting a rash of internal DHCP issues for clients running ISA 2004 SP2 on SBS 2003. Amy Babinchak noted this a while back in her blog, and I’ve been working with her to iron out the issues. One item I ran across this morning seems to tie the problem to a Restrited Access rule. The jury is still out on the why and the root cause of the issue, but I noted one change that I made to one set of rules that allowed DHCP to work correctly on the internal network afterward.

The rules that had been created followed this pattern: Set of domain URLs that the creator of the rule did not want to allow internal workstations to access; default action on the rule was “deny”; applied to all protocols and all users. In one case, I modified the rules to apply to all protocols except those listed, and I included DHCP Request and DHCP Reply in the exceptions list. Once I applied those changes, DHCP started working internally again.

Granted, these rules were high in the order processing, and if they had been lower in the order list, possibly even behind the Protected Network Access rule, we might not have seen the behavior. But something about the way those rules were created seemed to deny internal workstations access to DHCP.

I still have other sites with DHCP issues that I’ve only been able to get around by following the instructions in Amy’s post. But there has been some rumblings about denied access rules, so we’re starting down that road first to see what’s happening.

I’ll post updates here as I get them. Stay tuned…