ISAserver.org Monthly Newsletter of October 2008 Sponsored by: WavecrestWelcome to the ISAserver.org newsletter by Thomas W Shinder MD, MVP. Each month we will bring you interesting and helpful information on ISA Server. We want to know what all *you* are interested in hearing about. Please send your suggestions for future newsletter content to: tshinder@isaserver.org Filter and Monitor Employee Web Use
1. Will the TMG Management Console Fall Victim to PARS?I had an interesting conversation last week with someone who's been in the Microsoft computing industry for almost two decades. The topic was PowerShell and Exchange Server 2007. He was saying that he was surprised that the uptake of Exchange 2007 was much slower than he anticipated, given the significant improvements included with the new e-mail server. He suspected that the reason for the slow upgrade cycle was the new requirement for 64bit computing, thus taking away the in-place upgrade option. I said that hardware issues might be the case, but I doubted it. New hardware is relatively cheap, and when you look at the new features and capabilities included with Exchange 2007, new hardware seems to be a very low barrier to adoption. "No", I said. "It's not the hardware. It's the 'PowerShell Abdication of Responsibility Syndrome (PARS)'". PARS? What in the world is that? PARS is the reason why the Exchange Server 2007 management console is so dysfunctional. PARS is the reason what the upgrade cycle for Exchange Server 2007 is so much slower than you would expect for an otherwise impressive product. PARS is the reason why the Exchange developers and product team decided not to include a management interface on par with the Exchange 2003 management interface. PARS is a dangerous thing, because it plays into some basic insecurities a lot of Microsoft admins have regarding their skills sets. Many Microsoft admins became Microsoft admins because they preferred working with a rich graphical interface that allowed them to get their work done without having to learn a new programming or management language. These are smart people who enjoy their work with computers, but like anyone else who is not good with foreign languages, prefer to use a professionally developed operating system that is "fully baked" and does not leave it up to the customer to "finish the job". Given my background in medicine, and my understanding of the history of medicine, I have often thought the insecurities Microsoft admins have regarding command line interface management to be a strange thing. When Unix or Linux admins enter the room, the Microsoft admins often feel, or are made to feel, inferior because they do not know how to manage their machines using an arcane, undiscoverable, typo-ridden, antiquated command line interface. Why would this surprise someone coming with knowledge of medical history in the United States? Because at one time, the physician was like the Unix or Linux admin. He had to set up the X-ray machine himself, develop the X-rays himself and interpret the X-rays himself. If he needed a CBC (complete blood count), he had to count the red cells, white cells and platelets himself, he would have to do the differential himself (count different types of white cells), and manually record the results. And if blood chemistries needed to be done, he had to gather the blood himself, put together the reagents, and go through the long and laborious tasks required to figure out the levels of Sodium, Potassium, Chloride and Carbon Dioxide, as well as a few dozen more important elements and molecules. Today, all of these processes are automated with machines using computer technology. Today's physician does not need to read his own x-rays, today’s physician does not need to count his own CBCs, today's physician does not need to figure out his own blood chemistries. Machines with computer technology in them do this for him and he does not need to input a single line of code to make them work. That's right. None of the machines that physicians and technicians use require them to use a command line interface for them to work. Why? Because it would not be accepted by the customers. The customers would come back and say "Ah, excuse me. What is this? You need to finish this product before pawning it off on customers. There are supposed to be buttons to push so that everything it does works - you cannot foist your own lack of development efforts on me, your customer, and make me learn some kind of programming and scripting language. You must create a complete product and then sell it to me". You could never get away with PARS in medicine. The reason why the Exchange Team got away with PARS is because our industry is very immature. Unlike medicine, which can be considered a mature industry with a well defined division of responsibility IT has not recognized a division of responsibility that allows optimal efficiencies for practitioners. Instead, today's IT Pro has to be lab tech, x-ray tech, coulter counter, radiologist and general practitioner. Given these unrealistic expectations, you can see that any product group that leverages PARS to reduce their development costs (by creating underpowered and dysfunctional user interfaces) is doing a profound disservice to their customers. Not only that, but they are failing to help the industry mature. Why mention the horrors of PARS in the ISAserver.org newsletter? Because it is likely that the next version of the ISA firewall, The Forefront Threat Management Gateway (TMG) is going to include PowerShell support. My concern is that the ISA dev team, who I have considered the thought leaders when it comes to creating elegant, discoverable, operational and comprehensive user interface designs, will fall prey to PARS. How could a team so dedicated and so successful with management interfaces be susceptible to PARS? It would not take that much. For example, consider the stresses a dev team is under to get a product out in time. Then introduce a decision maker who does not appreciate the need to mature the industry, as medicine has matured. Finally, bring in a very small, but very vocal, subset of customers who demand command line management so that the management experience is similar to other firewalls. "Such a "perfect storm" of negative events could turn the former "best of breed" interface included with the ISA 2004 and ISA 2006 products into something akin to the hamstrung and ungainly interface included with Exchange Server 2007." So, this month's editor's corner is public plea to the TMG development team. Please, I understand that there are pressures on you to include PowerShell support for the TMG. I even admit that there might be a place where TMG support might be useful. But on the behalf of tens of thousands of ISA firewall fans, I beg of you not to abdicate your responsibility for creating a world class user interface for the TMG firewall. A user interface that allows us to get 99.6% of our tasks accomplished through the UI, and a user interface that requires us to drop down into PowerShell only one or twice a year, and only in emergency circumstances. Please, do not go down the dark path of the Exchange Server 2007 product group! HTH, Tom What do you think? Is Tom on the right track? Do you think it’s important to have a rich and comprehensive user interface? Or would it be better to reduce the usability of the management console so that the TMG team could spend more time on PowerShell integration? Let him know! Write to tshinder@isaserver.org and Tom will share the results with readers in the next newsletter. ===================== 2. ISA Server 2006 Migration Guide - Order Today!
Filter and Monitor Employee Web Use
3. ISAserver.org Learning Zone Articles of InterestWe have a great group of articles in the Learning Zone that will help you get a handle on your most difficult configuration issues. Here are just a few of the newer and more interesting articles:
4. KB Articles of the Month
5. Tip of the MonthA number of people have brought up issues relating to corrupt rules. For example, you might see something like "The item selected could not be completed due to an unexpected error" and then under the details button it says "The system cannot find the file specified". What's up with that? The problem is that a rule is corrupted and you need to delete the rule from ADAM storage, when using ISA 2006 Enterprise Edition. For details on how to delete the corrupt rule, check out this thread in our Web boards. Filter and Monitor Employee Web Use
6. ISA Firewall Links of the Month
ISA Firewall fans and writers! If you publish an article or a blog post about the ISA firewall, let me know. I'll put links to your articles and posts in the newsletter. Just send the link to tshinder@isaserver.org
7. Blog Posts
8. Ask Dr. TomQUESTION: I'm trying to arrange things so that a web server in our DMZ can get HTML pages from a web server in our internal network. I can access the web pages I need inside the network so I know that works. I have been looking in ISA Server 2000 (our current version - I know it is way out of date and we are intending to move to ISA 2006 soonish - but I am already late on getting this to work) and I am wondering if destination sets might enable me to do what I need. I have tried using Server Publishing but cannot get it to work (and cannot see how when on the DMZ server, I ask for a web page using an IP address in the internal network, the DMZ server knows where to go). I wonder if you would be able to point me in the right direction? Many thanks ANSWER: Hi Julian, Interesting question. Unfortunately, I have not seen an ISA 2000 firewall for almost three years. If I remember correctly, we needed to use packet filters and RRAS filters in order to set up a trihomed DMZ with ISA 2000. I know that we covered this issue extensively in our book, "ISA Server and Beyond", so if you can find an old copy of this book, you will find the information you need. Server Publishing will not work because that only worked with external to Internal connections. My best advice is to upgrade to ISA 2006, which was built for secure multi-networking in mind. QUESTION: Hey Tom! I have an ISA Server 2006 already configured to pass port 80 traffic to one of our servers. I need to allow port 8081 traffic on the same web server that is open for port 80. I tried copying the rule for the port 80 and changing it to 8081, but that kills all access to the web server. I tried creating a new rule and pointing it to the web server on 8081, but that also killed it. It is like the new rule throws the old one out or something (though they are both listed in the rules). How do I get ISA to allow 8081 traffic to pass to the web server? Thanks! ANSWER: When you create your new Web Publishing Rule, you need to make sure that the rule applies to a different public name or path. Otherwise, there will be collision between the two rules. For example, consider the following: Web Publishing Rule 1: Public Name: www.domain.com Web Publishing Rule 2: Public Name: www.domain.com In this example, whatever rule is higher on the firewall rule list will be the one that is triggered first. So, what you need to do is change the FQDN on the public name tab so that there is not any collision between the rules and both rules can be triggered based on FQDN. Note that I am assuming that both rules are accepting inbound connections from external hosts on TCP port 80. If the second rule is accepting connections on TCP port 8081, then you can create a second Web Listener that listens on that alternate port and then make sure that external users append the alternate port to their requests. When you do this, you can use the same public name for both rules. Got a question for Dr. Tom? Send it to tshinder@isaserver.org. Filter and Monitor Employee Web Use
TechGenix Sites
|
