The nice thing about standards is that there are so many to choose from

Posted on By Mark Wilson

A couple of weeks back, I wrote about Microsoft Office 2007, including the new OpenXML file format. In a recent Windows IT Pro magazine network WinInfo Daily Update, Paul Thurrott reported that the competing OpenDocument Foundation has announced a plug-in for Microsoft Office that will let users open and save documents natively in the open-source OpenDocument format (ODF), which has recently been standardised and is supported by IBM and Sun Microsystems. The plug-in, which has been in development for about a year, makes OpenDocument documents seem as if they’re native to Office. Add Adobe’s portable document format (PDF) and Microsoft’s XML paper specification (XPS – formerly codenamed Metro) into the mix and we have plenty of scope for document confusion.

Both OpenXML and ODF are open standards that are freely licensed but it remains to see whether either will become dominant. I have a feeling that we’ll have competing XML-based document standards to grapple with for many years to come.

Redirecting web proxy access when the server name changes

Posted on By Mark Wilson

Despite the problems I experienced migrating from Proxy Server 2.0 to ISA Server 2004 last night, I did have some success using a little DNS trickery to avoid changing the proxy settings on all clients (the new web proxy server has a different name to the old one). Here’s how it works:

  1. In DNS, delete the original host address (A) record for the old server.
  2. Next, create a host address record for the new server and an alias (CNAME) record with the name of the old server, pointing to the fully qualified domain name of the new server.

All DNS lookups for the old server should be redirected to the new server (via the DNS alias), allowing the proxy settings in the web browser to be updated at leisure (of course, in an Active Directory environment, they could also be updated via group policy).

Configuring network connections for ISA Server 2000/2004 (aka when proxy server migrations turn bad)

Posted on By Mark Wilson

It was supposed to be so easy. The new server was already built, with the same IP addresses as the old one. All I had to do was disconnect the NT 4.0 Proxy Server from the network and power on the new Windows Server 2003 R2 box with Internet Security and Acceleration (ISA) Server 2004 on it, then configure and test a few filter rules; but I had forgotten the first law of IT consultancy – nothing is ever straightforward – which is why I’m writing this post on the train to work after rolling back the migration and getting just 4 and a half hours sleep last night…

Firstly, I decided that the ISA Server should be joined to the Active Directory. My original plan had been that leaving it in a workgroup would be secure, but as I didn’t want to allow unrestricted anonymous (i.e. unmonitored) Internet access I’d be limited with my authentication options (either set up a RADIUS server to handle authentication or mirror the user accounts on the ISA Server). I wasn’t confident that ISA Server would work well if it was joined a domain after installation so I uninstalled ISA Server, joined the computer to the domain, and reinstalled ISA Server, plus service pack 2 and other updates.

It only took a few seconds to configure the cache and set up a firewall policy rule to allow all ports outbound access (just as a test, I could lock it down again later), add all the internal networks and enable the web proxy client, following which Internet access from the local network was restored. The trouble was that none of the machines on remote sites could access the Internet.

Suspecting a DNS issue, I began to investigate name resolution problems and (here was my mistake) questioning why no forwarders were configured on the internal DNS server (because DNS monitoring showed that the simple queries were fine, but recursive lookups were failing). If I’d been thinking clearly, I would have realised that the internal network doesn’t need to have a recursive DNS path to the ISP’s DNS servers (the proxy server should handle that on behalf of the clients) – although I do think that having a clear path from clients to the internal DNS and onwards to the ISP’s DNS is the most straightforward configuration, supporting both internal (Active Directory) and external (Internet) name resolution (and Microsoft’s advice is to configure only internal or external DNS on the ISA Server – not both).

The problem was the network configuration on the ISA server. Jim Harrison’s excellent article on configuring ISA Server interface settings is my bible when configuring the network cards on an ISA server, but I hadn’t set up the routes from the external network to my internal networks correctly. The local LAN was fine, but ISA Server was rejecting requests from remote internal networks because it didn’t understand the underlying network path (flagging a configuration error alert warning that the address range of an ISA Server network should match the address ranges routable through the associated network adapter as defined in the routing table). When I monitored the traffic flow, I could see incoming requests that were denied with no rule was given as the reason – another clue that there was a problem with the network rules.

Although the configuring ISA Server interface settings article points out that a route will be required to each internal network, I’d set the next hop as the internal interface of the ISA server, rather that the local router (the internal NIC doesn’t have a default gateway if configured correctly). Adding persistent routes for each of the internal networks (route -p add remoteinternalnetwork mask subnetmask routeripaddress) fixed the issue, after which nslookup (and web access) began to work from all sites.

Unfortunately, by the time I’d worked this out, it was too late to set up and test the various filter rules that are needed to ensure correct (authenticated) HTTP(S) and FTP browsing, SMTP e-mail, access to OWA, etc., so I decided to back out and reconnect the legacy proxy server. At least now I know that the connectivity problems are resolved, I can attempt the migration again another evening.