Tom Shinder’s ISA Server Questions of the Week
In the coming week’s we’ll be starting a ISAserver.org Questions of the Week newsletter. I’ll be using this newsletter to answer some of the questions you all send to me privately. This way, I can answer your questions and still help other people at the same time! ISAServer.org is a big community, and I want to share as much as I can with the community.
Until then, I’ll post a Questions of the Week article.
This week’s questions:
QUESTION: Name Resolution Issues in Exchange RPC Publishing
Hi Tom,
I’m (still) a big fan of the ISA-server and since the first problems/seconds also a very big fan of you and isaserver.org. On Monday I implemented the RPC filter to publish Microsoft Exchange – because of your white paper it was a great effort.
But I had a problem with the name-resolution. The customers domain is : corp.customer.de. The FQDN of the exchangeserver (also a DC) is dc.corp.customer.de. The fact that the Outlook-client is supposed to work internal and external forced me to arrange a unique name. I decided exchange.customer.de. At the internal DNS I made a new zone exchange.customer.de and I set up an “exchange” a-record at the
external DNS (no cname as you mentioned). The host was pingable from both sides.
I set up the exchange server at the outlook-client with exchange.customer.de but when the first contact was established, outlook changed the server name automtically to “dc”. I was very lucky that the internal customer-domain was a subdomain of his official internet-domain. So I was able to add the subdomain “corp” at the external dns.
Is there a way to avoide outlook to change the server-name automattically? Or can one exchange-server use several names?
ANSWER:
Good question. You’re referring to the article on RPC Exchange Server Publishing located at http://www.isaserver.org/pages/articles.asp?art=327 It sounds like you have an issue with how Outlook handles name resolution for the internal Exchange Server that’s published using the RPC Exchange Server Publishing Rule.
The Exchange Server is going to return to the client is own host name. That host name is typically the same as the machine’s NetBIOS name. So, you should make sure that the internal Exchange Server has a DNS host name that is consonant with its NetBIOS name. In the example you give, it sounds like the NetBIOS name for the machine is DC. If that’s the case, you need to create a Host (A) entry on the public DNS to resolve dc.domain.com to the external IP address that you’re using for the Exchange RPC Server Publishing Rule.
It also sounds like you’re using the same domain name for internal and external network resources. This is not nessarily a bad idea, and I’ve heard that Microsoft MCS recommends that you do it this way. However, if you do use the same domain name for internally and externally accessible services, you need to create a split DNS. A split DNS requires that you create two DNS servers with the same zone name. One DNS server is used by external network clients only, and the other DNS server is used by internal network clients only. You do NOT allow external and internal network clients to use the same DNS server.
Now, if creating the zones and host records isn’t a viable alternative for you, you can use a HOSTS or LMHOSTS file on the remote clients to resolve the name. Enter the NetBIOS name of the Exchange Server in the HOSTS file, and the IP address on the external interface of the ISA Server used for the RPC Publishing Rule, and it works a treat.
QUESTION: Switching ISPs
Hi Tom,
I have another question about ISA (somewhat related to my first question); I realize it’s a bit specific, but any help you could offer would be fantastic. (A related and more general question, if it’s easier to answer than my more specific one, is how to setup ISA servers to provide network fault tolerance.) Currently, we had one T1 connection sent through an ISA server to our LAN. We have found a better provider and want to switch from the old T1 to the new T1 without disrupting server and mail activity.
So our proposed solution is to have two ISA servers (_not_ arrayed together). ISA server 1 (ISA1) would be connected to the old T1 connection and a switch connected to our LAN. ISA server 2 (ISA2) would be connected to the new T1 connection and the same switch connected to our LAN. Since the two ISA servers are not arrayed, they would have separate IP Addresses. For each of the client computers, we could then have two gateway addresses (one for ISA1 and one for ISA2). In order to switch over from the old T1 to the new T1, we would set the metric (for gateway preference) of the new T1 so that it will be looked at before the old T1. Eventually, once the MX record of our old T1 is no longer being referenced, we can pull the plug on the old T1, and complete the cutover to the new T1. At this point, we could join ISA1 and ISA2 into an array serving the new T1 to provide fault tolerance in case one ISA server fails. Does this sound right/feasible to you? Is there a better solution? If there are any articles on the web you could point me to, that would be great as well. Again, thanks for any help.
ANSWER:
When you change ISPs, you have a couple of issues you need to address. One is the outbound access issue, and the second is the inbound access issues. Let’s look at the inbound access issue first, since it tends to be more problematic.
As you know, you need to make your internal network resources available to external network users via a publicly available DNS server. If you are using your ISPs DNS server for this purpose, you can just change the appropriate Host (A) and MX records on their DNS server to point to the new IP address on the external interface of the ISA Server.
However, if you are hosting your own public DNS servers and publishing them through ISA Server, then you’re going to need to go to your registrar and change your NS records for your authoritative DNS servers. Actually, you don’t need to change your NS records so much as you need to change the glue records that point to your published DNS servers. This is very easy to do in the Web interface over at www.nsi.com. I have to do this often these days, as the ISPs are going under at an incredible clip. It will take a few hours for the old records to time out, so you’ll see a delay before all Internet hosts can access your published DNS server and other services in your domain(s).
Now for outbound access. You could use multiple default gateways, or even use NLB and set the client systems to use the NLB address. If you don’t want to use NLB, then you can switch the clients over to the new address after you get the line put in. If you use DHCP, make the change to the appropriate scope, and then have the clients reboot or run ipconfig /renew. This depends on your user population level of competence.
I think your plan for setting up an NLB array for outbound access is a good one. Just assign the two servers’ external interfaces an IP address in your range, point both of them to use the LAN interface of the router as their default gateways, and away you go! I’ll be doing an article on outbound NLB in the near future, so keep visiting www.isaserver.org/shinder on a regular basis!
QUESTION: Multiple External Interfaces on the ISA Server
In your “Configuring ISA Server 2000” book, you have a short section on Network Fault Tolerance. I currently have two dedicated high speed connections and I want to configure them so that if one fails, the other can step in as a sort of failover solution. Is there anyway to do this without having two ISA servers? Thanks for any help.
ANSWER:
As things stand at this moment, you can’t use multiple external interfaces on the ISA Server. At the time the book was written, Microsoft was implying that you could install multiple external interfaces on the ISA Server and allow ISA Server to use them in a fault tolerance situation. Since that time, its become clear that multiple external interfaces isn’t really a viable solution.
One option is to use a hardware load balancing in front of the ISA Server. There are router solutions that allow you to plug multiple external interfaces into them to create a fault tolerant solution. You can also use a hardware load balancer, such as F5 networks BigIP. These solutions work well, but suffer from being somewhat expensive.
However, if you can wait a month or two, something really exciting is coming around the corner. Rainfiity (www.rainfinity.com) is coming out with a product called RainConnect. The RainConnect product will first be implemented as a second server that you can put in front of the ISA Server, and later will be implemented to integrate with the ISA Server machine itself. This will allow you to connect multiple external interfaces into the computer, such as a DSL and T1, or multiple DSL or T1 lines. The RainConnect product will automatically load balance the connections and provide fault tolerance. It’s a very exciting product and I expect it to be quite popular!
QUESTION: How to Repair a Corrupted Cache
Hi Thomas,
Thank you for responding to my disk cache initialization issue on the newsgroup. How do I repair the corrupted cache file?
Louise
ANSWER:
If you find that you get a lot of “cached initialization” errors appearing in your Event Viewer, it could be that your Web cache is corrupt. To fix this problem, you need to create a new Web cache file. First, stop the Web Proxy service. After stopping the Web Proxy service, go to the location on the hard disk the .cdat file is located. Delete both the folder (which strangely enough doesn’t have anything in it) and the .cdat file. After you delete the files, go back into the ISA Management console and create a new cache file. Once you configure the new cache file parameters, restart the Web Proxy service. That should fix your cache file.
The cache file can get corrupted if the server is shut down unexpectedly, like with a power failure or a hard reboot. I’ve also seen cache file corruption problems when the machine doesn’t have enough RAM. If you have only 256MB of RAM in your ISA Server, try bumping it up to 512MB or more. That seems to permanently get rid of the cache corruption problems on a lot of boxes.
