A quick follow up on a post I did last December, VMWare Virtual Center and SQL 2005 Native Driver. When upgrading your VMWare Virtual Center (vCenter, whatever), it will require you to use the SQL Server Native Client 10.0 in your ODBC when using an external 2005 SQL server.
If you remember, we installed the SQL Server Native Client 10.0 during installation as asked, but couldn't get the service to run after install. To fix the issue, we had to delete the DSN and create a new one using the standard SQL Server driver with the same settings.
Before doing the upgrade, delete your current DSNs and create new ones using the Native Client 10.0 with the same exact settings. Run the upgrade, let it do its thing, then it'll fail when attempting to upgrade the Converter and Update Manager (because at this point the VirtualCenter Server service can't start with the Native 10.0 driver). That's ok, just delete the OBDC connections and recreate them using the "SQL Server" driver. Then go into the Services MMC (Start - Run - services.msc) and start the VMWare VirtualCenter Server service. Give it a few minutes to figure itself out (Virtual Center will reconfigure HA, etc). Then run the upgrade again, this time only selecting Converter and Update Manager to upgrade.
March 30, 2009
First, I *HATE* proxy .pac files. With that said, here's some tips on setting up your file.
Here's the challenge. You have a web filter/proxy in your network and you need everyone to go through it. You also need to allow unfettered access to local resources, which can sometimes cause fits with your proxy. Some examples of such fits: not being able to route back to certain local resources, having issues with with special applications that install a local http server (Google Desktop comes to mind here), access to local webservers with certain programs (Microsoft Frontpage), or local webservers that run code that the proxy doesn't like (we have a site that does a lot of perl, designed for internal use only that the proxy just has issues with).
If your client machines are local desktops or Terminal Server sessions that don't leave the network, setting up bypasses for all of this with Group Policy is easy. Just put the IP address or subnet in the Exceptions part of the Proxy Settings configuration window. But what if your clients have laptops that leave the network? Forcing them to use the VPN for web traffic is one way to work around this; it forces all Internet usage on the company machine to be accounted for in the web filter and is easy to configure in their GPO. But what if management doesn't like this option; the clients have to be filtered while in the office but can hit whatever they want when they leave? The answer to this problem is to set up a proxy .PAC file.
The PAC file allows you to configure a user's proxy in many different ways. It's a text file that is referenced by the browser for proxy configuration, and uses a JavaScript function (FindProxyForURL(url, host)) to pull this off. In this post, I'm only going to focus on my requirements to build my PAC file: determining if the user is on the office network and bypassing local resources.
There's quite a few examples of PAC files on the Internet, and I'll provide links to these sites on the bottom of this post. They're all worth a look; considering the custom nature and the many configuration options to PAC files it's a good idea to see what everyone else is doing and develop your own configuration from there.
First, let's determine a way to figure out if you're on the local network or not. Some examples I've seen attempt to determine if the machine is part of the local subnet, then bases the configuration on that. If you're like me and have a lot of different subnets (either internal vlans or different sites), that may not work. So, what I do is configure the PAC file to determine if it can communicate with the proxy. If yes, it uses it. If not, then it goes "DIRECT" to the Internet. For me, it's a simple one-liner:function FindProxyForURL(url,host) { return "PROXY 192.168.10.100:3128; DIRECT"; }
This will cause the web browser to look for the PROXY IP address (in the example 192.168.10.100:3128). If it finds it, then it uses it and you should see the traffic hit your logs. If it can't find it, it'll take a minute to time out then drop the user directly on the Internet with no proxy.
Ok, the first requirement is done; mobile users will be on the web filter while at the office and will be off of it away from the office. Now, we need to bypass local resources; a task that causes a little more fuss. Let me note that before I bash on web filters, or at least come off as bashing them, most of my local resources tested just fine with no further configuration. A lot of my monitoring tools, local wikis, etc had no issue. But some, such as our phone system configuration site, didn't work at all in testing. Your mileage may vary; for a lot of people stopping at this point would work for them just fine. But for those who do have issues, we'll continue.
Next determine the subnets you want to bypass. In this case, we'll use 10.10.1.x, 10.100.x.x, 192.168.10.x, and all local addresses 127.0.0.x).function FindProxyForURL(url,host) {
if (
(isInNet(host,"10.10.1.0","255.255.255.0")) ||
(isInNet(host,"10.100.0.0","255.255.0.0")) ||
(isInNet(host,"192.168.10.0","255.255.255.0")) ||
(isInNet(host,"127.0.0.0","255.255.255.0"))
)
return "DIRECT";
else
return "PROXY 192.168.10.100:3128; DIRECT"; }
Now, when testing, any host that uses an IP address or resolves to an IP address in the subnets you're bypassing should not show up in your logs. All other traffic should show up just fine. Make sure you set the appropriate subnet mask. The || pipes mean "OR", so you can add as much as needed.
Now, lets say you have a specific site you want to bypass, on your network or not. For example, you want to bypass traffic to your external web site, or you use a hosted email solution that has issues in your web filter. Just add the following line within the "if ( )" statement:(dnsDomainIs(host, ".bypassed_url.com")) ||
Note that there is no need to put anything more than the domain name; no need for http://, *://, or the full URL. Also, don't forget the OR (||) if you intend to put any more statements below it. Your last line in the if( ) should not have ||.
Now that all of our requirements are met it's time to save the file and test it. There are several methods of the PAC file placement involving web servers or network shares, but since the client is on a laptop I prefer to place the file locally. Save your PAC file on the local drive. Next, open Control Panel and Internet Options. Click the Connections tab and the LAN Settings button. Uncheck everything except "Use automatic configuration script". For the address, put in file://c:/PAC_file_location/name_ of_PAC_ file, example: file://c:/pxy/pxy.pac
In a future posting I'll go over how I deploy the PAC file via login script and how I use Group Policy to force my users to use the file. I may even do a write-up on blocking other browsers, such as Firefox, Chrome, Safari, and Opera.
A quick note: PAC files are read when the browser is opened. If your laptop user has an open browser then pulls their laptop off the network (hibernate) then attempts to use the same browser window off the network, it most likely will not work. They'll have to restart the browser. Same concept when they enter the network; if they were working in a browser window off the network unfiltered, the same browser window will remain in DIRECT configuration until it is restarted.
As promised, some useful links:
Wikipedia:Proxy_auto-config
Craig Johnson Consulting: Autoconfigure Scripts for Proxy Settings - good overview, but I couldn't get the if (shExpMatch(url, method to work..
Novell: Cool Solutions: Proxy Failover (without Clustering) - great article, the author dissects the code and explains it.
Jason Curnow: Writing Effective Proxy PAC Files - wow, I JUST found this site.. Read this.
Microsoft Technet: Using Automatic Configuration, Automatic Proxy, and Automatic Detection - lots of examples here.