Yahoo Messenger and Internet Proxies

I hate proxies but they seem necessary in the Corporate world. Getting all the websites, programs, widgets, etc working as people want can cause much pain and suffering.

This is a simple post, but hopefully it'll save someone a few hours of frustration.

We have a group that has to use Yahoo! Messenger for chat. So I put them on our web filter/proxy, allowing the Yahoo IM access. (Note, our proxy requires NTLM/Active Directory authentication to allow traffic). Those not using Yahoo's client (like those using Pidgin) connected fine. But the official Yahoo client seemed like it wasn't passing the Windows Authentication to the proxy and not connecting. Setting the client's proxy settings to Direct Connection did not work; Yahoo was still pulling Internet Explorer's proxy settings.

After a few hours of searching, I came across this Microsoft KB article: How to Set Up Yahoo Messenger to Use Only Integrated Authentication on Your ISA Server Computer. In the article, it advises that you set your Internet Explorer settings to enable "Use HTTP 1.1 through proxy connections".

Apparently Yahoo Messenger client doesn't send a keep-alive header in it's NTLM request, thus not keeping itself authenticated. Telling it to use HTTP 1.1 forces this, since the keep-alive header is default in 1.1.

Check out the Microsoft article (linked above) for more information, but this simple checkbox fixed the issues for my users. It's not JUST for ISA; I'm not using ISA and it worked for me.

iSCSI, Windows 2003, SANSurfer, and VDS

So I have a site with two servers having identical problems, a iSCSI volume will not initialize in Window's Disk Management utility (or create a partition in DiskPart).

In the GUI Disk Management, I get the error "Logical Disk Manager: The operation did not complete. Check the System Event Log for more information on the error." In DiskPart, I get the error "The disk management services could not complete the operation." The event log doesn't have an error directly explaining these errors, but sometimes I'll get an Application Error 1004, mentioning vds.exe (Virtual Disk Service) faulted. Google and multiple forum searches don't yield much result.

A little about the setup. I have an IBM DS3300 iSCSI SAN attaching LUNs to two Dell PowerEdge 1950s via a Qlogic QLE4062c cards, using SANSurfer software. (They're not sharing a LUN, each server gets a different one).

So I won't bore you too much, I'll leave out the majority of my troubleshooting and homicidal hatred towards these two systems and just give you the answer (or at least the answer that worked for me).

Turns out that the issue lies in the Virtual Disk Service, which Microsoft has a hotfix for here: Article ID: 948699. Once I installed the fix and rebooted I was able to initialize the disk, format, label, and use.

iSCSI File Shares Disappear

A quick tip for those new to iSCSI, the Microsoft iSCSI Initiator, and using the two for file sharing.

Setting up the LUN, mapping it as a disk, and putting your file shares on it is great, but there are a few configuration steps you need to take if you experience your share settings disappear every time you reboot (even thought the files remain).

First, ensure that the Server service is dependent on the Microsoft iSCSI Initiator Service. To do this, go into the Services MMC, open the Server service properties, and check under the Dependencies tab. No Microsoft iSCSI Initiator? Open Regedit (Run - regedit.exe) and navigate to HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\lanmanserver. Find the key "DependOnService" and set it's value to MSiSCSI. The Server service is responsible for creating the shares; if this service starts up before the iSCSI LUNs are ready on the server, then the shares will not appear.

Second, make sure you set up the Microsoft iSCSI Initiator to automatically restore the connection and drive letters. Under the Targets tab, when you highlighted the target and clicked "Log On", did you check "Automatically restore this connection when the system boots"? If not, remove the connection and log it back on, this time selecting the correct option.

Third, after the drive has been set up and you assigned it a drive letter, go back into the Microsoft iSCSI Initiator software and click on the Bound Volumes/Devices tab. You'll see some funky volume path that looks like gibberish. Highlight it and click Add. Put in the drive letter you assigned and click Ok. This will cause the iSCSI Initiator service to not completely start until the volume has been mapped to the drive letter. Since the Server service now depends on the iSCSI service starting up, it'll have to wait until the volume is available before it can assign share settings.

VMWare Virtual Center and SQL 2005 Native Driver, Part 2

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.

Proxy PAC Files, How to Use With Laptops and Local Bypass

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.

vSwitches and vmnic Linking - When the NIC Name Changes

I had one of my ESX servers die over the weekend. Upon inspection (and some calls to support to verify) it seems the system board needed replacing. I pulled the machine and had it fixed. This machine has two on-board NICs and a quad-port NIC PCI-X card. When I booted up the server (after the repair) I noticed that the server tech reinstalled the quad port card into the wrong PCI-X slot. I shut down the machine and corrected the mistake.

Then I powered on the machine and plugged in the network cables. Unfortunately I could no longer access this server via network (nor could it access the network). ifconfig showed that all the NIC ports on the quad port card had different labels, going from vmnic0 and vmnic5 to vmnic10 and vmnic14. Nice, but not too much of an issue.

When you set up the service console earlier (during install), it puts the configuration in a virtual switch (such as vSwitch0) and then "links" that switch to your physical NIC (such as vmnic0). So this is what we need to do to get network connectivity. Run the command esxcfg-vswitch -l. This lists all of your virtual switches and their configuration. Look for the vSwitch that contains your Service Console port group. This is the switch you need. In this example, it is vSwitch0.

Next we need to link the vSwitch to the correct NIC. If all of the NIC ports are on the same vLAN or physical network, then this part isn't hard. But each NIC port on this card is plugged into a different vLan (set by our network switches), so it's important that I find the correct vmnic.

If you have physical access to the machine, and you need to determine which NIC port is assigned to which vmnic# label, do this:

• Unplug all network cables from the machine.
• As root, type esxcfg-nics -l in the console. This lists all the vmnic ports, the manufacturer, and link status.
• Next, take a network attached Cat5 cable and plug it into a port.
• Run the command again, noting wich vmnic show UP for the link status.
• Repeat the process for each NIC port.

(note: You can also just link each vmnic to the vSwitch, one by one, until your network access is achieved, if you don't have physical access to the machine. But, if you're not careful, that method may not be accurate.)

When you've determined the vmnic to use, linking it to the vSwitch is just one command: esxcfg-vswitch -L vmnic# vSwitch#. In my case, it was esxcfg-vswitch -L vmnic10 vSwtich0. Once I entered that, I could get on the network. Now, you can fix the rest of the nics/switches with this command, or you can connect to the server via Virtual Center and do it through the GUI.