Technology for Mortals

I have been struggling with a problem with ActiveSync for ages now, I kept getting a 401.2 error sent to the client when they would try to get their mail (but they could get their calendar). The problem was in the ISA server configuration. When I changed ISA’s access rule to be set to “Basic” authentication instead of “No delegation, but client may authenticate directly” the problem was solved.

J.Ja

Back in March, I set up our ISA 2006 server and configured the VPN on it. Since I have a static IP address at my home office, I created an access rule in ISA server that denied all external IP addresses access to the VPN. Me being me, I didn’t test, I assumed (big mistake) that this would work. Today, I found out that this was not sufficient to restrict VPN access by IP addresses. Searching the Internet, I did not find anyone with a good tutorial on how to do this, so here is mine.

• Open up the “Routing and Remote Access” widget from “Administrative Tools”.
• Go to the “Remote Access Policies” node in the tree.
• Double click the “ISA Server Default Policy” item to bring up the properties.
• Click “Add”
• Select “Calling-Station-Id” and click “Add”.
• The Calling-Station-Id field is a regular expression. The format is to put each IP address that is allowed within parenthesis, and separate each of these blocks with a pipe character.For example:(123.111.111.112)|(111.112.143.54)

  You may also use wildcard characters. (123.111.111..*) will match all IPs starting with 123.111.111, (123.111.111.11.) will match all IPs starting with 123.111.111.11. Note that the period in the regular expressions indicates “any character” and the asterisk means “match the preceding character any number of times”. This means that instead of typing the periods into the IP addresses, you need to “escape” them with a backslash as indicated above.

J.Ja

Ever since I put up an ISA Server 2006 deployment, we noticed that Web access through it was incredibly slow. When we connected test machines directly to the Internet connection (the FiOS line that I’ve mentioned before), it was blazing fast. But outbound Web access through the ISA Server was slow slow slow. Well, I fixed it!

When I started troubleshooting it, I first looked to the Event Viewer for failures. Other than a few minor items about DNS, I didn’t see anything in there at all. We tried all of the usual diagnostics, and it was clear that network latency was not the problem. I also tried a good number of other tests, including DNS lookups, all of which looked good.

Performance monitoring showed that the local SQL Server installation (for catching the logs) was Hoovering RAM. So I got into SQL Server and capped its memory usage at 512 MB of RAM. We saw that the overall RAM consumption was down; it now ran with plenty of free memory, but the Web access was still slow. Outgoing access for all other protocols was super fast, incoming traffic was super fast. What gives?

Next, I decided to take a look at the DNS problems in Event Viewer. You can never be too careful, and who wants to have errors anyways? I fixed the problems with DNS up, and some sites seemed to improve, but the overall access was still quite slow. The trend now seemed to be that frequently accessed sites (based on hostname) were speedy, but everything else was slow. This deepened my suspicions of DNS problems.

At this point, I had nowhere else to turn to. Monitoring and performance logging told me what I already knew, that everything was fine except the retrieval of non-cached Web pages. I was typing up an email about the problem, enumerating all of the potential points of slowness and why or why I could rule them out. Everything could be ruled out easily, except for the DNS situation. Who knows what the internal DNS stack is really doing, especially when the ISA Server is its own DNS server?

So I decided to take yet another look at the DNS configuration. The configuration of the local DNS server was perfect. No problems found, no errors in Event Viewer. On a whim, I checked the DNS entries of all of the NICs. The only entry of note, was that the NIC on the LAN had an entry for an alternate DNS server, an entry for a machine that was no longer in use. That entry was put in as a “fallback” entry when the server was first installed, and it pointed to the previous firewall, in case the previous firewall had a DNS entry that we had not moved to the new DNS nameservers yet.

But how much trouble could this cause, right? After all, the lookup should be occuring on the WAN NIC, not the LAN NIC, and this is the alternate DNS server, which should never be hit anyways! Well, I removed the entry just for correctness, and BAM. Problem solved.

Microsoft, sometimes you baffle me. Why in the world would the alternate DNS server for the LAN NIC affect perforfmance on the WAN NIC, especially when the primary DNS server for all NICs is localhost, and localhost’s DNS server forwards to the WAN ISP’s DNS servers when needed? And why would this only affect Web access, and not FTP, SMTP, etc.? Regardless, if you are seeing insanely slow Web throughput on your ISA Server 2006 install, check your DNS subsystem as a whole completely before giving up.

J.Ja

For the last few months, I have been working with ISA Server 2006 in our corporate network. Before I got started, I purchased a copy of ISA Server 2006 Unleashed by Michael Noel, published by SAMS Publishing. I was hoping that this book would be a valuable asset in working with ISA Server, particularly since Tom Shinder has not updated his ISA Server 2004 book. This book missed the mark, and badly.

For me, I have a persistent problem with IT industry books. I have this ability, as many people have, to read the directions on the screen. Furthermore, I understand enough of the principles of whatever I am doing to not need a basic primer on every minor detail. Put simply, if I don’t understand what I see on the screen, I can look it up. So my needs from a book are to tell me things that I are not on the screen.

This particular book, like many other IT books, is rarely more than a screen-by-screen walk through of ISA Server. And that is disappointing to me. I don’t need a book telling me, “on this screen, enter the directory that you wish the application to be installed to.” Thanks, but I figured that out when it said, “where do you want the application to be installed?” What I need is a book that contains answers to my questions. Instead of saying, “these are your three choices” I need to know the pros and cons of the choices. When something goes wrong, or not as expected, I need to be able to turn to the book and get an authoritative answer instead of having to spend hours on search engines. And this book simply does not meet my needs.

If you are looking for an introduction to ISA Server 2006, or want to explore its feature set without having to install it, this is a good resource for you. But if you are actually working with ISA Server 2006, and need something more in-depth, you’ll want to pass. A much better title for this book would have been ISA Server 2006 Walkthrough.

J.Ja

So, after literally dozens of man-hours trying to get the VPN working in ISA Server 2006, the end culprit turned out to be… my fat fingers. When I entered the IP address for the domain controller in a “Computer” network entity (which I later added to the network groups used by access rulles), I typed it in wrong. As a result, traffic to/from the docmain controller didn’t go through in the cases where the rules should have judged it based on that incorrectly typed IP address and not some other criteria.

Nicely enough, a lot of other odd items in the event log and the ISA monitor are now cleared up too. Lesson re-learned once again: when things are mysteriously failing, check your typing before you go to Google. It’s a royal pain to back out hours of effort to fix a problem that never existed, but the fix itself could cause other issues.

J.Ja