Aimless Ramblings from a Blithering Lunatic . . .

Just another Microsoft MVPs site

Category: 556

Killing off ISA

Earlier today Susan blogged about upgrade season in her office, and getting ready to migrate from SBS 2003 to 2008.  In that post, she talked about uninstalling ISA and mentioned a post that Kevin has on that subject.  I thought I’d take a moment to expand a little bit on Kevin’s post and add a few thoughts from my own battle scars with removing ISA.

First and foremost – Kevin mentions removing the ISA firewall client from all of your PCs before you remove ISA from the server.  I cannot overstate how crucial this step is.  The ISA 2004 firewall client uninstaller wants access to the original installation MSI, which lives in a share on your SBS box.  This share is actually the Clients folder in the ISA installation directory.  So what happens when you remove ISA from your SBS?  You guessed it – the mspclnt share with the firewall client installation files is removed, which means any firewall clients still installed on PCs are not going to be happy when you try to remove them and they can’t find the MSI.

Since the Clients folder under the ISA installation folder is typically only about 5MB, I copy this folder to a safe spot on the server – usually my Tech directory where we keep various utilities and scripts.  Here’s why – more and more, customers are backing up their workstations whether via Acronis / StorageCraft / Windows Home Server.  We may find ourselves at a point in the not so distant future after removing ISA that we need to restore a PC from an image taken before ISA was removed, and need to remove the firewall client again.  Or we may discover a forgotten PC / laptop that we missed removing the firewall client from.  There’s all sorts of scenarios – but by keeping the Clients folder in-tact, we can share that out with the original mspclnt share name at any time and be able to uninstall the firewall client just like ISA was still installed on the server.  Without the mspclnt share, you have a very VERY ugly path in front of you, and it is safe to say that you may end up facing the decision of living with the firewall client still on the machines, or wiping & re-installing the OS . . .

Second – Kevin also makes a brief mention about proxy settings.  When you uninstall the firewall client from a PC, it will automatically disable proxy settings for the user account that is running the uninstall, but not for any other users on the machine.  So if you have a PC that multiple users log in to, or if you are running a terminal server, be prepared for some proxy pain.  I actually have a little VBScript that disables proxy settings for the current user by changing the value of the HKCU\Software\Microsoft\Windows\CurrentVersion\InternetSettings\ProxyEnable key from 1 to 0.  I modify my login script to call the VBScript, in effect ensuring proxy gets disabled for each user when they log in to each machine.  

The other aspect with proxy settings to keep in mind are your server-side applications.  Unless you modified your ISA firewall policy to allow unauthenticated outbound http access from the server itself, you most likely specified proxy information for apps like Trend Micro’s Worry-Free Business Security or even WSUS – so that they can download their updates automatically.  After removing ISA, you no longer have a proxy server, which means apps configured to use a proxy aren’t going to be able to get out to the internet.  As a result, you stop getting automatic updates for things like A/V.  So you will need to manually update the connection settings in these apps to remove the proxy settings previously defined.

So – here’s my quick checklist for removing ISA from your network & installing a hardware firewall:

  1. Prep your hardware firewall in a lab setting.  Enter in all public IP info, disable DHCP, and create all of our inbound rules.  It’s best to do this while ISA is still installed & working, so you can refer to the rules in ISA to make sure you don’t miss any necessary inbound rules for your environment.
  2. Backup your ISA configuration.  While we’re moving away from ISA permanently, if we do encounter an issue with the new hardware solution where something isn’t working that was working with ISA, the ISA backup is an XML file that is relatively easy to read to see what rules you had and what they did without having to reinstall & restore ISA on your SBS.
  3. Open up your outbound access in ISA by creating the proverbial ALL/ALL/ALL rule.  In other words, create a new access rule in ISA allowing All outbound traffic via all protocols for all users/computers.  Much of the internet access in ISA on SBS is dependent on users being members of the Internet Users security group.  The firewall client on the PCs is what actually passes user info to the ISA server so it can check group membership.  Once we remove the firewall client from PCs, ISA isn’t going to be getting user info and some stuff that worked before isn’t going to work now.  If you only have 5 PCs and are moving from ISA to your hardware firewall on a Sunday when no one is working, you might be able to skip this step.  But if you have a larger number of PCs, etc. this helps to insure you don’t disrupt users’ internet access too much while removing the firewall client . . .
  4. In my case, I update my domain login script to call my DisableProxy.vbs script at this point.
  5. Uninstall the firewall client from ALL PCs.  Again – see my notes above.  Your life will be MUCH simpler if you insure the firewall client is completely removed from all PCs before removing ISA from your server.
  6. Copy the contents of the mspclnt share (%programfiles%\Microsoft ISA Server\Clients by default) to a safe location on the server, and plan to keep this folder safe for some time  [:)]
  7. Follow Kevin’s steps 3-9 to remove ISA from the server.
  8. When you re-run the CEICW, it should automatically update the DHCP scope option on the server to use the internal IP of the new hardware firewall as the default gateway setting.  If you have any devices that are using static IP addresses, you will need to manually update those with the new gateway.  (HINT:  Take a few extra minutes to create DHCP reservations for each device using a static IP, and change those devices to DHCP – so if you have another network reconfiguration in the future, all you have to do is reboot those devices instead of reconfigure [:)].    For all of your other DHCP devices, you will want to run an ipconfig /release followed by an ipconfig /renew to update their IP settings so they pull the new gateway, or you can reboot them as well.  HINT 2 – PSTools are your friend.  Create a batch file with the two ipconfig commands, and use PSExec to push & execute the batch file on all machines in the domain from the server.  5 minutes tops to update the IPConfig on all domain machines (that are online) instead of sneakernetting . . .
  9. ALSO – if you followed Jim Harrison’s steps to configure auto-detection of proxy settings on your SBS LAN, you want to remove the wpad A record from your internal AD domain forward lookup zone in DNS – otherwise you may have devices pulling proxy settings for pointing to your non-existent proxy server via auto-detect.

So that’s my addendum to Kevin’s excellent post

 

P.S. . . .   and if you haven’t decided on a hardware firewall yet, I highly recommend Calyptix devices.  These are the standard devices we are implementing when migrating customers to SBS 2008.

Taking the Plunge

I did it.  No – hell didn’t freeze over, and no – pigs aren’t flying.  But yes, I just recently did some network reconfiguration here at the office, moving from a dual-nic SBS Premium setup with ISA 2004 to a single-nic setup with a hardware router/firewall instead.   Gasp!  The horror! . . .

I’ll admit that for a long time I thought it would be a cold day in hell before you could pull ISA from my dead hands – but I would also be lying if I didn’t tell you that I definitely had a love/hate relationship with ISA – and it usually depended on the hour as to whether I was loving it or hating it.

So what is my thinking?  You know, if someone figures that one out would you please clue me in? smile_teeth    

Like most technology decisions, this was motivated by business needs – both the business needs of our clients as well as our own business needs to profitably deliver quality services to our clients.  First – we’re seeing an increased demand in managed security with the SMB client.  Second – we are continuously looking for ways to increase productivity and gain efficiency.  Third, we’re revamping our product offerings to better line up with our core business as an MSP by adding products that allow for additional recurring revenue opportunities.

So, the big question is what did we decide on to replace ISA 2004 in our office?  CheckPoint’s Safe@Office 500W Unified Threat-Management device.  Now why did this solution win out?

1)   Affordability / Flexibility.  The CheckPoint has several base models to choose from (wired or wireless with 5/25/Unlimited clients)  And nice add-on services including gateway anti-virus, anti-spam, web content filtering, etc.  The base models make it affordable to get this device into smaller clients who wouldn’t normally consider ISA.  Additionally, the add-on services allow clients to purchase features cafeteria-style and provide us with additional recurring revenue.

2)   Efficiency in Management.  CheckPoint offers their Security Management Portal for centralized management of these devices.  Their SMP was designed and built from the ground up for target MSPs and how we work: 

      *   Everything you can configure locally via the device can also be configured centrally from the SMP.  Additionally, with the SMP we can create groups with common configurations and apply those group settings to multiple devices very quickly and easily. 

      *   The SMP also streamlines setting up site-to-site VPNs between devices.  Simply build your VPN community in the SMP and pick the devices you want to belong to that community, then the SMP will generate the necessary configuration and push out to each of the devices.  This also allows you to have IPSec VPNs between devices that can only get dynamic public IPs.  When one device’s IP changes, it notifies the SMP which automatically updates the configuration on the other devices in the VPN community. 

      *   The SMP allows you to customize both administrative and customer-facing reports, so you can change the layout, the content, and even the look and feel to match your branding.  Customer-facing reports offer a lot of nice, colorful graphs which make sense to CXO level individuals at your clients. 

      *    The SMP is available either in a hosted solution, or in a purchase and run on your own server setup.

From a technical standpoint, there are pros and cons to both ISA and the CheckPoint (or other hardware firewalls).  There are a lot of things that ISA does better than many hardware devices – primarily web publishing, with its ability to inspect http traffic and route requests based on HTTP host headers, as well as providing egress filtering that integrates with Active Directory.  Where ISA falls short is when you have a service provider who needs to efficiently manage multiple installations at different customer sites with different needs.  Sure, I could probably build a repository of management scripts, and use Level Platforms’ Managed Workplace to push those scripts out to our managed client base, but why recreate the wheel – and run the risk of having to recreate those scripts as subsequent generations of ISA are released? 

Also, I will admit that I am beginning to question the feasibility of ISA on SBS.  I still don’t fully buy in to some people’s arguments that ISA on SBS is inherently insecure.  I’m beginning to question the feasibility of ISA on SBS not because of the security implications, but of the added complexity in setup and administration.  If you look at the SMB space and the SBS customer – their needs are changing.  Two years ago we could sell an SBS Premium to a customer who relied on Exchange and file shares.  In that scenario, adding ISA to the mix wasn’t that complicated or that big of a deal.  The customers we’re encountering today are looking for much more diverse and mature solutions.  Our typical SBS-based deployment is now a multiple-server environment.  SBSers are doing more with Exchange – particularly in terms of mobility, depending on SharepPoint for workflow management, version controls and increased collaboration, instead of simply document storage.  Our SBS clients are also much more likely to be running at least one Line-Of-Business app – in our experience most likely Dynamics GP and/or Dynamics CRM.

When you start putting all of this on to one box, change management becomes a bit of a challenge to say the least.  And even us long-time ISA fans have to admit that ISA is usually the first thing to come up when we start thinking about moving services off our SBS.  But investing in another box, plus another Windows Server license, plus ISA is often hard to swallow – especially when you look at it from a customer perspective and include services to install and configure that box.  From a business standpoint, when you compare that option to a solution like the CheckPoint that offers a significantly lower entry point, provides the MSP with a mechanism to recurring revenue, and provides a pre-build solution to efficiently manage a large number of devices from one central location, and it becomes a bit of a no-brainer.

Now the question is just how well this is going to work.  We’re now at 4 days since CheckPoint has replaced ISA in our office, and so far so good.  I’ll be sure to report back on my post-ISA experiences  smile_regular

The compromise of SBS . . .

I’m sure that most people here are aware that there are circles in the IT community where SBS is a punchline.  One of the most common assertations is that ISA on SBS is a security compromise.  So I figured it was time to address this head on.


Is ISA on SBS a security compromise?  Completely – because the mere notion of a firewall on Windows is a security compromise at best . . . we should all be running a SonicWall or Cisco Pix if we really want security.     Sorry, I couldn’t resist a little jab  :^)


Seriously – is ISA on SBS a compromise?  Absolutely – because SBS itself is a compromise.  Which is why it fits so well in the small business space, because each and every small business is a living, breathing example of compromise on a daily basis.  You can’t truly appreciate or understand Small Business Server if you don’t understand small business.  And you can’t understand small business if you haven’t experienced it. 


I can’t help but wonder if the people who look down on SBS with disdain have truly experienced small business.  Have they laid awake at night worrying about making payroll – knowing that their employees have families to feed and mortgages to pay?  Do they realize that for many small businesses, money could be spent in several different places – so that server upgrade often relates to not being able offer the raises or bonuses we’d like, or offering additional benefits.  We have to take care of our employees and our customers, but we also have to invest in our businesses to insure our long-term ability to take care of our employees and our customers.  We can’t afford an imblanace either way – literally.  So each day is a compromise.


Would I love to be able to follow ‘best practices’?  Absolutely.  But look at the average small business with 25 users or less . . .  how would I be helping them by deploying a DC, a secondary DC, an ISA server, a front-end Exchange box, a back-end Exchange box, a file & print server, a Sharepoint box and a LOB server?  Not only would there be extensive cost at deploying that sort of solution, but extensive cost to maintain and administer that set up.


Let’s face it – SBS customers aren’t shopping for ISA server any more than they’re shopping for Exchange.  What they’re looking for is a solution that let’s the work smarter.  Does the small business owner care about running ISA on their DC?  Nope – not in the least.  The fact is that it isn’t realistic to sell that client a separate ISA server – simply put, the costs outweigh the benefits.  


Is ISA on SBS a compromise?  Sure – it’s a compromise between the benefits of the full product and great pricing of an integrated bundle.  I will be the first one to admit that in a perfect world ISA would always run on its own dedicated box.  In the small business arena, that just isn’t going to happen in an overwhelming number of cases.  So the question facing most small businesses isn’t whether or not they should run a dedicated ISA box in addition to their SBS, but whether they should run ISA on SBS or stick with their $39 Linksys router.


So what’s the bigger security compromise and risk for the small business – running ISA on their SBS or sticking with a low-end nat-ing router?  Because down here in the trenches – that’s the reality.

SBS SP1 + ISA 2004 = No DHCP?

Last week, we were installing SBS SP1 for one of our SBS Premium customers.  Naturally, we upgraded their ISA 2000 to ISA 2004, which went very smoothly.  The only problem was that after the upgrade to ISA 2004 was complete, none of their workstations could pull an IP via DHCP.  We verified that the DHCP Server service was running, and tried restarting the DHCP Server service, as well as rebooting the server – both to no avail.


Well, it turns out that this is at least partially my fault.  You see, when I set up ISA 2000, I never let ISA build the LAT table for me – I always manually specified the internal address range I wanted.  So for an SBS using the default IP of 192.168.16.2, I would specify a LAT of 192.168.16.1 to 192.168.16.254.


ISA 2004 varies from ISA 2000 in that it firewalls all network interfaces, including the internal interface.  My DHCP problem was that DHCP requests happen via the broadcast address of .255 – since my LAT entry ended at .254 – ISA blocked the traffic, so the DHCP Server never received the client request, and the client thus was unable to pull an IP via DHCP.


SO – if you encounter this problem, open your ISA Management console, and expand <servername> | Configuration | Network.  Select the Internal network, and edit it to include .255 

SP1 straight from the horse’s mouth . . .

Ok, so Charlie (Anthe – Release Manager for the next version of SBS) isn’t a horse, but you get the idea . . . .


SBS SP1 will include:


Windows 2003 SP1
Exchange 2003 SP1
MSDE SP4
SQL Server SP4 (Premium)
ISA 2004 (Premium)
Windows Sharepoint Services SP1


And on the desktop side:

Windows XP SP2
ActiveSync 3.7.1

And yes Virginia – IT WILL BE AVAILABLE FOR ONLY SHIPPING & HANDLING!!!


Charlie also indicated that there will be a public beta for SP1, although they don’t know when it will be available or how it will be offered.  The target release date is to release at the same time as Windows 2003 SP1.

ISA Rocks!

Ok – for anyone who has hung around microsoft.public.backoffice.smallbiz2000 and microsoft.public.windows.server.sbs, you probably realize that I’m a really big ISA fan.  While I’m not necessarily against hardware firewalls, I’m constantly irked by the people who automatically discount ISA because it isn’t a hardware firewall.  I’m so sick of the snot-nosed drivel ‘…but it runs on a Windows server and I can’t trust anything running on Windows to protect me.’  


BULL!   That just makes my blood boil.  And anyone paying attention to security trends knows that our threat vectors are increasingly from our own users versus the ‘traditional’ external hacks.  That’s one of the reasons why I love ISA – its AD integration for advanced internet access policies for user/group membership, etc.  And that’s just the tip of the iceberg for the features in ISA 2004. 


For those of you who are also big ISA fans and want a little ammo for the next time you encounter ‘that’ hardware firewall guy (and you know who I’m talking about – we’ve all got ’em), check this article out:


ISA Firewall Fairy Tales – What Hardware Firewall Vendors Don’t Want You to Know (v1.02):
http://isaserver.org/articles/2004tales.html