Problems With Context Menu Handlers

Symptom
When right-clicking on a file in Windows XP, the context menu takes over four minutes to be displayed.  Right-clicking on a folder exhibited normal behavior and was not affected.

Background
Context Menu Handlers can load from several areas in the registry.  One set of keys that control the menu creation when right-clicking on a file is located in:
HKEY_CLASSES_ROOT\*\shellex\ContextMenuHandlers

Troubleshooting
In this particular case, the end user had been putting up with this for a couple of weeks and was at wits end by the time he finally pulled me aside and asked me to take a look.  I was to happy oblige  as I  was tired of troubleshooting Citrix issues and was ready to look at something different for a few minutes. 

Start by making a backup copy of the entire ContextMenuHandlers subkey by right-clicking on the key and selecting Export.
Remove each key subkey under ContextMenuHandlers until you locate the offending entry.
It’s probably a good idea to export a copy of each subkey before you delete it.  That makes it easier to re-add the non-offending subkey after you’ve isolated the issue.

In my case, it was the “Open With” subkey that was causing the problem.  As soon as it was removed, the menu displayed immediately when right-clicking a file.

After rebooting the PC, I tried importing the “Open With” key back into it’s proper location.  Much to my surprise everything still worked correctly.

Reassign a vswif to a new vmnic

The VMware host in my lab is a Dell GX620 running ESX3.51 U2.  It has three NIC’s:
The embedded Broadcom BCM5751 Gigabit Adapter  (vmnic0)
3Com 3C905C-TX 10/100 Adapter  (vmnic1)
Intel 8254N Dual Port Gigabit Adapter  (vmnic2 and vmnic3)

The 3C905 isn’t entirely VMware compatible.  It can be used as a service console connection but will not function as a virtual machine uplink on a vSwitch.  It will always show disconnected.

I want to reassign the service console vswif to the 3Com adapter, keep the same IP address and move the service console port group to a new vSwitch.

VMware doesn’t like having two service console connections with different IP addresses in the same subnet, so I have two options.

1.  Create a service console connection in a different subnet and access the host from that subnet using the VIclient.
2.  Enter the commands directly on the host console.

I recommend option two.  Keep in mind that this process temporarily disrupts network communications to the host via the service console IP.

After obtaining physical access to the host’s console (or network access via a DRAC or ILO), log in and su - to establish root.

Remove vswif0 from vSwitch0
esxcfg-vswif -d vswif0  –ip=192.168.68.35  –netmask=255.255.255.0  –portgroup=SCX

Remove the SCX port group from vSwitch0
esxcfg-vswitch –del-pg=SCX vSwitch0

Create a new vSwitch for the service console;
esxcfg-vswitch -a vSwitch3

Assign the 3Com adapter to the newly created vSwitch
esxcfg-vswitch -L vmnic1 vSwitch3

Add the SCX port group to vSwitch3
esxcfg-vswitch -A SCX vSwitch3

Add vswif0 to the SCX port group and assign the IP address and subnet mask
esxcfg-vswif –add –ip=192.168.68.35 –netmask=255.255.255.0 –Portgroup=SC2 vswif0

Restart the VMware management service
service mgmt-vmware restart

Here’s vSwitch0, still connected to vmnic0 but minus the service console

And here’s the new vSwitch3 with the service console reassigned to vmnic1

Experimenting with STP and PortFast

Some STP Basics
On most Cisco Catalyst switches, STP is enabled on all ports by default.   Port initialization requires upwards of 30 seconds to complete, and can take as long as 50 seconds.
This thirty second “delay” can be attributed to the time required for the port to transition from Listening to Learning and finally to Forwarding.
The Listening and Learning transitions each require about 15 seconds.
This transition period can be painful for end users waiting to gain access to the network.  To the untrained IT person it can be misdiagnosed as “some sort of network issue”.

PortFast to the Rescue
Portfast shortens the Listening and Learning states allowing the link to transition to the Forwarding state in as little as three seconds.
This translates to quicker access to the network for the end user when they power on their PC, connect a laptop to a wired port, etc.
Enabling PortFast does not disable STP on the port, it simply allows us to get to the Forwarding state much faster.

Let’s enable PortFast on switch ports 1 – 4 using the spanning-tree portfast command.  IOS provides a reminder of the possible consequences.

Looping ports Fa0/2 and Fa0/3 reveals that we still have adequate loop protection as Fa0/3 transitions to a Blocking state within ~2 seconds.  Other hosts on the switch are not affected.
In this scenario, PortFast protects against mistakes made in the wiring closet or on the off chance that two access ports would become looped under a desk.  (don’t laugh, I’ve seen it happen)
Here’s a partial output from the show spanning-tree command.

Note that Fa0/3’s Role has changed to Back.  This is helpful information as it indicates that two or more ports on the same bridge are connect together.
Fa0/3’s Status has changed to BLK, effectively blocking the loop condition .

The Tech Savvy End-User
Let’s say an end user wants to add a couple of extra network ports to their cubicle.  Instead of calling the help desk and being questioned as to what unauthorized device they are trying to connect to your LAN, they pick up an unmanaged switch from local retailer and connect it to their access port, Fa0/2.  (for the sake of this post let’s assume we’re not MAC locking ports on the switch)

What happens when two ports on the parasite switch connected to access port Fa0/2 become looped?  This partial output from show spanning-tree provides some info.

This should generate a call to the help desk as Fa0/2 immediately transitions to a Blocking state, preventing traffic from the looped parasite switch from entering the network.
Role is indicating Designated (DESG) which means that Fa0/2 is not looped with another port on this switch.  The Type field provides additional information.  Self-looped is a good indicator that something interesting is happening on Fa0/2.  No other hosts on the access switch were impacted.

Conclusions
PortFast is a great feature and can be enabled without compromising loop protection.  You should think twice about ever disabling spanning-tree.  I’ve seen a looped parasite switch bring down a 400 node network where spanning-tree had been disabled or wasn’t available on the particular switches the client has deployed.  Yet another argument for purchasing quality switches for your infrastructure.