As a follow-up to my post addressing migrating from Novell, I wanted to share the results of a few simple network packet captures. Before doing so, let me quickly revisit the issues leading to the tests:
- Our Windows Vista x64 clients were experiencing 15-20 second delays, intermittently, when trying to access Novell shares
- Our Windows XP x86 clients (regardless of Outlook versions) were experiencing 15-20 second delays, intermittently, when trying to interact with email or access a Microsoft file share
As a corollary, we introduced a new Exchange server (2007 SP1) and a new archival tool from C2C Systems.
As the calls to HelpDesk began to add up, I attempted to record as much information about the user, though my efforts were almost pointless as no one else thought to do this — even after my explicit instruction. At any rate, given the data I collected, I could not find any correlation between cached/non-cached mode or version and the intermittent slowdowns. My next logical leap was to blame our new archival process for slowing everyone down. I then disovered that the archival procedure — removing literally thousands of emails from Exchange databases — left holes in the database, prompting me to take each database offline and defragment. This improved performance overall, but the intermittent slowdowns continued and the support calls rapidly increased.
Practically at my wits end, I received an interesting demand from an employee — an upgrade to Vista. They claimed that every XP user in their department experienced slowdowns in Outlook AND in accessing our newly-created Microsoft file share (the first share completely migrated from Novell). I quickly put out that fire by asserting that it couldn’t possibly be an operating system-specific issue. I was only halfway right, as you’ll see.
I had little to no experience using packet capturing software, I’m sad to say, so this was really my first chance to dig in deep. I installed Microsoft Network Monitor on the Vista lover’s PC (a normal machine by our standards, running Office 2003 and XP SP2 x86) and proceeded to capture traffic. I kept the user logged in and checked traffic over a period of time to see if I could glean anything useful. It wasn’t until the user could predictably create the 15-20 second delay that I learned anything useful — the client was attempting to connect to a share on the Exchange server during the slowdown.
I quickly set up a number of test PCs to try and reproduce the slowdown in both Outlook and accessing the Microsoft share. The machines had the following in common with the user’s PC:
- Outlook 2003 in cached mode
- C2C client installed
- Novell Client 4.91 SP4
- Tested under an account not licensed for C2C
- Tested under an account that was a power user on the PC
As it turns out, I was able to reproduce the issue described by the user at start-up. In other words, when I booted the machine and attempted to access the Microsoft share, there was an excruiciating 15 second delay before the entire contents of the share were displayed. Feeling quite good at my ability to reproduce the issue (hah!), I installed WireShark and took the following steps to capture whatever network traffic was generated during the slowdown:
- Logged in as a power user that wasn’t licensed for C2C
- Opened Outlook
- Opened WireShark
- Started a WireShark capture
- Attempted to open an unread email that was not displayed in the preview pane
- Stopped WireShark once the message opened (I double-clicked the message to open it)
The results: 
Look at all of those attempts to connect to the Exchange share! To the developer in me, this SCREAMS bad coding. Why would a non-licensed C2C user need to access the C2C share? Beats me. Shame on you, C2C developers, for your inefficient coding. To work around this problem, I decided to un-install the C2C client, reboot, and repeat the test. Here are the results:
Wow — what a reduction in SMB chatter — not to mention there was absolutely no delay in viewing any message. I reproduced the same results, both with the C2C client and without, when attempting to access the Microsoft share. Removing the C2C client seemed like a good idea, but ultimately this wasn’t the solution I was looking for. All of our licensed users need the client to search through their old mail.
Elated at finding the source of the problem (SMB chatter), I went to the oracle (aka Google) and started a search for SMB performance problems and found a few notable recommendations. An awesome TechRepublic post detailed how to modify a few settings to allow for quicker SMB performance. I tested this out with a few users and the first thing they noticed was a huge performance hit when accessing Novell shares. While Outlook performance was stellar, these users would have rather had slow Outlook performance and speedy Novell access.
My next promsing lead was a Novell TID written in an extremely vague fashion. It discusses creating a registry entry and listing out the servernames and IP addresses hosting SMB shares. It was immediately obvious where to put this new registry entry, so I had to search deeper and found a much better explanation on the Novell Forums. Here is a screenshot of the registry fix:
I tested this registry hack on select machines throughout the company with a 100% success rate. Using Configuration Manager 2007, I pushed out a VB script to make the appropriate changes on every Windows XP machine in the company.
Another step away from Novell and another step closer to Microsoft. /sigh…
