The bgcolor Attribute Doesn't Work in Internet Explorer

There is a bug that impacts all versions of Internet Explorer.  These are the conditions that must exist in order for the problem to occur:

1. An HTML element must be using the deprecated bgcolor attribute.  This will likely be a table, tr, or td element.
2. The color must be specified using the hexadecimal short notation, i.e.  #123 instead of #112233

Internet Explorer cannot read short-notation hexadecimal colors in this particular property.  It will instead improvise by applying a background color of black.

The simple solution is to not use the bgcolor attribute, but if you have no control over the markup, use a full-length hexadecimal value instead.  If you're working in an application where you have no control over the markup or the value of this property but can apply CSS with a style sheet, slap the developers in the face and attempt to target the elements to override the color.  Don't try to use attribute selectors though (see here for more information).

CSS Attribute Selectors and IE 7

If you've tried to use attribute selectors in IE 7 and found it to be quite spotty, you're not alone.  Here's a brief illustration of just what I mean:

tr[height="50%"] { background: #fff; }

Though this bit of CSS will work in virtually any browser, it will not work in IE7.  But these will:

div[height="50%"] { background: #fff; }
tr[height] { background: #fff; }

Aside:  It's important to note that a DOCTYPE has to be specified in order for attribute selectors to work at all in IE7.

So what's the deal?

I created a test page to reproduce these issues and verified them in IE 7.  Then, I opened the page in IE 9, opened the DOM inspector (F12), and changed the Browser and Document modes to IE 7.  Voila, the attribute selector issues are reproducible there as well.  I found that unchecking the selector in the CSS pane and checking it again actually caused the selector to work.

This is pure speculation, but I believe the cause of these inconsistencies is that IE 7 will complete the loading of a webpage before certain attribute selectors have had enough time to resolve against the DOM.

In any case, the elements can be targeted through a number of other, more effective means, and luckily for us, the user base for IE 7 is currently at just 1.53% (Source: StatCounter).

Why are Awesome and Awful Opposites?

If you have ever watched one of Derren Brown's psychological manipulation videos, one word may come to mind as you stare dumbfoundedly into the television screen: Awesome. But I personally don't think 'Awesome' suffices. I think 'awe-most' is more appropriate. But why not just use the word 'Awful' instead? Oh, wait a minute... That completely changes the meaning!

The term 'awful' has been around for centuries, long before 'awesome' was conjured. Three hundred years ago, the term 'awful' had the same meaning as our present-day term 'awesome.' You can see this by reading literature written during colonial times, such as Autobiography by Benjamin Franklin or Journal by John Woolman. So what changed?

The semantics of words in the English language are just as susceptible to change as any other language component, so long as we continue to use the language, anyway. For example, consider the term 'nice.' In the 18th century, this meant foolish or stupid. Now it means pleasing and kind. In the 15th century, the term 'brave' meant cowardice, but now it means courageous. In the 13th century, the term 'girl' meant a young person of either sex, but now it's specific to a female child. The list goes on and on.

So the next time you find yourself in awfully gay spirits whilst reading Shakespearean literature, consider researching the historical meanings of the words, lest you contrive an unduly haphazard interpretation. ;-)

Stay classy, fellow bloggers.

Mobsync, Like N-Sync for the Mob

After today's encounter with Mobsync and COM+, I am left scratching my head and looking about in disarray.  This doesn't happen often, but I am sure glad when it does because it beats sitting in a lecture hall 'attempting' to learn about the intricacies of Windows communication subsystems.

It all started when I received a call yesterday from one of my clients.  She couldn't access her network drives.  Of course, the client doesn't actually say this; more commonly I hear much more detailed descriptions like, "Micah, my shit don't work!" or "My icon disappeared.  When are ya gonna be here?"  So I setup an appointment for this morning.

From the way she described the issue, she couldn't access some network resources.  She could still get her email from the Exchange server as well as access the Internet.  Her mapped drives wouldn't open, however.  She received this error message when trying to open them:

Her network drive is not accessible because the parameter is incorrect?  Well, that doesn't happen every day...

When navigating through Entire Network -> Microsoft Windows Network -> Domain, the following error message was seen:  (replace 'Network' with the domain name)




Stranger yet, when trying to open the UNC path from the Run dialog box, the classic "The network path was not found" message appears.

This was the only user who experienced this issue, and she only experienced the issue on this computer.  Just to rule out the network as a possible cause, I cleared the DNS cache (ipconfig/flushdns) and the ARP table (arp -d *).  I pinged the server by name and the server responded without issue.  I checked the ARP and DNS tables and saw that the IP address and name resolved correctly.  There aren't any extra entries in the hosts file and the DNS server is dynamically set via DHCP to the server--the same as every workstation in the network.

These are the errors seen in the Application event log:

Event ID 4356 seems to give the most details.  The GUID {41E90F3E-56C1-4633-81C3-6E8BAC8BDD70} belongs to COM Event Subsystem.  The second GUID {6295DF2D-35EE-11D1-8707-00C04FD93327} belongs to Mobsync, the Microsoft Synchronization Manager, a component of Internet Explorer used for offline file synchronization.  HRESULT 8000401A means that there is not a domain controller to which a connection may be made.

I spent several hours exhausting many options in resolving this issue.  I upgraded from XP SP2 to SP3, IE6 to IE8, and ran all the latest updates, thinking that mobsync would be updated along the way and the issue resolved.  This wasn't the case, however.  I even installed Hotfix KB885887.  No pain, no gain.

In Component Services within Administrative Tools in the Control Panel, I drilled down to the Mobsync component and set the security settings in the properties dialog box to their defaults as well, but like all the rest of my attempts at saving the day, it failed.

After this, I thought that perhaps the COM+ catalog became corrupt.  Per this article, I logged into safe mode and backed up the clbcatq.dll file in the System32 folder and removed the contents of the %windir%\Registration folder.  Then I deleted the registry key HKLM\Software\Microsoft\COM3 and restarted the computer.  After restarting, I removed the Registration folder altogether and opened the Add/Remove Windows Components setup program.  Simply click Next caused COM+ to be reinstalled.  While the network drives were accessible at this time, the problem came back as soon as I restarted the computer again.

Since I had already made it to four and a half hours at this point, I decided to follow the advice of this page and unregister mobsync.dll from the COM+ Event System by running "regsvr32 "%systemroot%\system32\mobsync.dll" /u".  While the network drives were accessible once again at this point, the issue wasn't truly resolved.  After all, I heard that if this component is not available, data corruption may occur if the PC belongs to a domain (like this one.)  Luckily, there are Shadow Copies and tape backups, just in case something does go awry.

If I am wrong in thinking that there is an issue with mobsync, then I may need to re-evaluate the network and check for any issues that may exist between the server and the PC by using a sniffer utility.

Update 4 June 2010:


Despite mobsync being deregistered, the issue reoccurred.  The only error messages found in the event log on the PC were related to Group Policy not being applied.  I used the network sniffer application that comes with Windows Server 2003 and recorded all traffic going to and from the PC from the time the PC was turned on until the user had logged in and reached the desktop.  Everything seemed to be just fine except for several error messages seen in the SMB frames from the server to the PC regarding invalid arguments.

All in all, the final solution was to blow away the user's profile and start fresh.  The issue hasn't reoccurred since.  Additionally, another recording of the network traffic going to and from that PC showed no SMB errors any longer.  The root cause is profile-specific and likely resulted from a corrupt user registry hive.

Stay classy fellow bloggers.

Key Repeats in VMWare?

Lately, I've been working on a custom Linux system in VMWare ESXi.  I have a somewhat uncommon setup, however.  I use the Infrastructure Client within an RDP session to administer my virtual machines.

Many times, especially over connections with high latency, an issue occurs when typing that causes a single key strike to register an unpredictable amount of times (well, theoretically, it is predictable, but that is far out of the scope of this post.)

I solved this issue by performing the following steps (Please note that the virtual machine will need to be powered off to perform these steps):

1. Open the vSphere Client and login to the VMWare server
2. Go to the Inventory and expand the list of virtual machines
3. Right-click the virtual machine you want to make the change to and select Edit Settings...
4. Select the Options tab.  Under Settings -> Advanced -> General, select Configuration Parameters...
5. Select Add Row.  In the Name column, type in keyboard.typematicMinDelay.
6. I used the value of 1000000.  This creates a delay in registering key presses.  Therefore, the higher the value, the longer you have to hold a key down for it to register more than once.  (Think of it this way: k[pause]kkkkk)

Stay classy, fellow bloggers.

Setting up DHCP over VPN on a Sonicwall

If you are using a Sonicwall Firewall, you may be interested in learning how to setup Virtual Private Network access to utilize network resources away from the workplace, assuming, of course, you've paid for the VPN licenses...

This post sprouts from an issue with Windows 7 64-bit and Sonicwall Global VPN Client 64-bit v4.2.6.0305 (the latest version as of the date of this post.) A client of mine had a strange issue where occasionally, the VPN connection would not work quite right. When connecting, he would see the following dialog box pop up:

(Please note: IP addresses and connection names have been hidden in the images.)

When researching the problem on the Internet, I noticed that this dialog box may sporadically appear when one of the following conditions are met: 1) The user is not connected to the Internet. 2) Internet Explorer has been uninstalled.

I was using GoToAssist when I saw this message, so he was obviously connected to the Internet. Additionally, IE was installed, and I even uninstalled and reinstalled it again just to make sure there weren't any changes to IE that would have caused the incident. To no avail, I continued onward in quest of solving this curious predicament.

First, I changed the connection settings to use LAN only to get rid of the dialog box.

After this, the connection was successfully established, but no data could pass through. I could not ping any host or access any service that resided on the remote network. I tried removing and reestablishing the connection, uninstalling and reinstalling the Global VPN Client, and even jumping up and down in frustration. None of these fixed the issue.

At first, I did not think there was any misconfiguration on the Sonicwall Firewall because four other people, one of which used Windows 7 32-bit, could successfully establish a connection and use network resources.

After contacting and working with the horrible Sonicwall technical support, I did finally come to a resolution. The virtual adapter settings for the VPN connection in the firewall were set to not lease any IP addresses via DHCP. Here is what we needed to have set up in order for the resolution to arise:

While it is not necessary for the Sonicwall Firewall to host the DHCP server, a DHCP server is probably required for this fix to work. To set up DHCP in a Sonicwall Firewall, navigate to Network -> DHCP Server. Select both Enable DHCP Server and Enable Conflict Detection. After that, create a DHCP Lease Scope under the appropriate heading. Apply the settings.

Next, under VPN -> Settings there should already be a GroupVPN policy. I believe this should be here by default. If it is not, you can use the VPN Policy Wizard to create a new one. Edit the GroupVPN policy by selecting the pencil+paper icon.

On the Client tab, under Client Connections, there is a drop down list for Virtual Adapter settings. Make sure DHCP Lease is selected. I had None selected at first, which Windows 7 64-bit doesn't cooperate with very well.

Next, go to VPN -> DHCP over VPN. You can view current leases from here. Go ahead and just select the Configure button.

A new window opens. If you are using the internal Sonicwall DHCP server, ensure both Use Internal DHCP Server and For Global VPN Client are selected. If you are using a different DHCP server, instead check Send DHCP requests to the server addresses listed below. Add the appropriate DHCP server IP address. Hit OK.

That's it. This solved my problem. The Sonicwall technical support representative has no idea why the "None" option for the virtual network adapter did not work correctly, but the only operating system that had issues was Windows 7 64-bit.

Post any questions or comments.

Stay classy, fellow bloggers.

Strange Time Zones Around the World

On my job, I work with people around the world. Many of these people live in India. India time, or IST, differs from much of the rest of the world in that it is off by thirty minutes, instead of an hour.

In 1884, the Greenwich Meridian was internationally recognized as zero degrees longitude at the International Meridian Conference, based on solar observations in Greenwich, England by Nevil Maskelyne. Over the next forty years, the world would supplant their local mean times with approximate differences rounded to hours or half hours "ahead of" or "behind" Greenwich Mean Time.

Greenwich Mean Time was considered deprecated as an accurate source of time variations globally in 1972 due to the inconsistency of the Earth's rotation. GMT was replaced with UTC, or Coordinated Universal Time, which is based on atomic clocks.

It is believed that India had two time zones and for the sake of unity, split the two down the middle to have one uniform time zone.

India is not the only country with a strange time zone, though. Afghanistan, Iran, Nepal, Sri Lanka, and Kabul also have strange time zones, differing by 15-30 minutes. Some states/provinces, like Newfoundland in Canada and South Australia have time zones different from the rest of their country. Saudi Arabia is even stranger yet. Apparently, the time is set on a daily basis, based on the sunset.

Read the Wikipedia article for more information on Greenwich Mean Time.

Stay classy, fellow bloggers.