Blog: Networking

After installing the 2482017 and/or 2467023 Microsoft patches you will be unable to connect from the VMware View Connection Server if your View Client  has a build number lower than 353760.  Connection attempts to the VMware View Connection Server will fail.  To fix this problem you can either uninstall the Microsoft patches or upgrade your View Client to a newer version. [more]

Click here to download the VMware View Client patch.

Click here to read the VMware knowledge base article concerning this issue.


 

One of our Lubbock IT support clients uses both the PS and PCL6 versions of the Xerox Global Print Driver (GPD) in a Windows 2008-x86 clustered print server environment.

To fix an issue that we were having with v5.173 of the GPD, Xerox suggested we upgraded to the current 5.185 version of the driver.

I successfully upgraded the PS language of the v5.185 driver on both print servers without any problems.

The problem appeared after I upgraded the PCL6 driver. I downloaded and installed the PCL6 driver to both print servers. Both servers showed that the update was installed successfully; however, the version of the driver within print management still showed to be v5.173. When I pulled up the printer that was using the driver, the version showed to be the updated version (5.185). When print jobs were sent to printers using the updated PCL6 version of this driver, the print spooler would crash and fail over. This occurred on both print servers. [more]

I was unable to uninstall the driver at this time, because over 40 printers were pointed to this driver. I then modified each printer to use the PS version of the driver. After doing so, I then removed the driver package from the print server through print management. I successfully removed the driver and the package from one print server. On the second print server, I received the following error upon removal: “Failed to remove driver package x2univx.inf. Driver package in use.” The driver itself was no longer listed in the print management window.

I then reinstalled v5.185 of the global print driver on both servers. Printing was successful on the print server on which the driver was removed successfully. However, the print spooler continued to crash on the server which had the error on driver removal. I attempted to remove the driver again, but received the same error. Restarting the print spooler as well as the server after an install but before the removal did not alleviate the issue. At this point, I called Xerox. Unfamiliar with the issue, they suggested I remove some files manually from the print virtual quorum. I completed this process, but the error still occurred upon driver removal.

Finally, I reinstalled v5.173 of the global print driver. After a successful installation, I then attempted to remove the driver.  The driver package was removed successfully and installed the new version of the driver (v5.185). I modified some of the printers to use this new driver and printing was successful.


 

We had an ongoing issue with a customer’s HP server where the internal fans continually ran at full RPM. We had to move the server to a new location because the noise was too much for the employees. The HP monitoring software would shut down the server occasionally because it senses it over heating, but there was never any real sign or indication that there was an overheating issue. The problem typically occurred when backups were running so we thought it was possibly the tape drive was causing a faulty temperature reading.

We went as far as to purchase a USB temperature logger which I placed on the server to monitor the environment for a week.  All readings came back normal. I opened a case with HP Support and their recommendation was to update the firmware and the drivers and everything else they could think of. But nothing they suggested made a difference. [more]

I decided to take the server down and look at the internal parts for possible obstructions in air flow that would cause it to think it was overheating. I was checking the second processors heat sink I noticed it was not seated exactly right but was clamped down. I removed the heat sink and found dust under it. That’s right... dust between the CPU and the silver paste. As you can tell from the picture below the silver paste had never contacted the CPU, except on one corner. I grabbed some canned air, blew the dust off, and reseated the heat sink.  Closed up the server and started it up. Since that time the server has run super quite with no thermal issues to this day. However, HP did have to replace an internal fan that failed from running so long at high RPM.


 

A coworker and I have been doing a lot of work on the CommVault email archiving and compliance products here lately. CommVault email compliance solutions provide two ways to access data collected via email compliance archiving agents. The end-user compliance portal allows a user to log in and search only their email whereas the compliance portal allows search of all email that has been collected via journaling. The issue we were able to reproduce was the following:

A user with a specific employment date (lets say 10.1.2010 for instance) could log in and see email that was sent prior to his/her employment date. They couldn’t see ALL email, just certain email. [more]

Long story short, as part of a troubleshooting task with CommVault support, our customer had created  a “special” configuration that enabled the compliance agents to basically harvest all mail in the Exchange environment from all mailboxes. Part of the work that the CommVault indexing engine does is to look at the email message and “mark” the message in such a way that it can be found by associated parties via the end-user search portal. It does this by looking up all parties on the email in active directory, then it associates the message with all the user GUIDs that should have access to the message via end-user search. In our case specifically, when all the emails were “harvested” from all exchange mailboxes, a specific set of emails that were sent to a distribution group were pulled in. The indexing engine expands those distribution groups and links the GUIDs accordingly. Emails to that distribution group go back farther back in time than the employment of the user in question, but the user is CURRENTLY a member of the distribution group. So, when the indexing server expanded the group, that user was associated….and viola, access to an email prior to employment via end-user search.


 

If you forward a meeting invitation, Exchange will notify the meeting Organizer that the meeting notice has been forwarded, and to who it was forwarded.  So, if you don’t want the Organizer to know that their meeting was forwarded, you can forward the meeting as an attachment.

Notes:

  • When you forward a meeting request, it will not include the organizers name in the “To” or “CC”  fields; however, there is a small note above the “To” section that says “When you forward this meeting, a meeting forward notification will be sent to the organizer.”
  • If you look at the forwarded message (from your sent items), it does not show it was sent to the organizer; however, it does state in the From: Your Name on behalf of Person You Forwarded To.

 
 

Windows 2008 terminal servers handle user profiles slightly differently than Windows 2003. 

  1. Windows 2008 (and Windows 7) profiles use a different format from previous versions.  You will notice in the roaming profile folder that you get a new folder with a .v2 extension; this is to prevent the new format from being applied to older OS’s.  Essentially, the user has two different roaming profiles; one for older OS’s and one for Windows 2008 (and Windows 7).  (\\servername\profile_share\username\tsprofile for older machines, \\servername\profile_share\username\tsprofile.v2 for Windows 2008 terminal servers)
  2. They finally manage to delete the user profile when the user logs off.  I’ve noticed two issues related to this.
    • The Users folder (formerly Documents and Settings) starts having multiple folders with the users name.  wcbtest, wcbtest.datacenter, wcb.datacenter.001, wcb.datacenter.002, etc.  The event log shows an error when trying to delete the profile folder, saying that it is not empty.  I have not looked in-depth yet; there may be a solution to this.
    • If you want to run the group policy results wizard, you have to do it while the user is logged in.
  3. If the roaming profile location is unavailable, the user gets a temporary profile every time.  On Windows 2003, you would get an error saying the roaming profile location could not be contacted (if I remember correctly), but the local profile would be normal.

 

The Level Platforms Service Center website is probably not very standards-compliant.  We've know for some time that Firefox and Chrome browsers don’t render it properly, but I’ve recently seen more critical problems, such as the Site Management page showing a blank site-list in Chrome.  Some of the monitoring procedures require these pages, so using IE (or Firefox add-on like IE Tab) may be the only way to see everything properly.


 

On any VMware virtual machine running Windows 2008 or 2008 R2 that was created using v4.1, the advanced configuration parameter disk.enableUUID is set to TRUE. Basically, this enables application-level quiescence in the VM. If the VM was created on ESX prior to v4.1, the advanced configuration setting does not exist. So, if you want to get application consistency on a VADP (vStorage API style) initiated backup, it won’t happen if that setting isn’t set to TRUE. This is a problem because a number of vendors (CommVault included) don’t support this feature yet. Since it is a default for new VMs, they won’t back up correctly.

The bottom line is... make sure you are absolutely sure you are getting application consistent backups by checking the app logs on the VM when doing the backup. You may not be getting as consistent of a backup as you think.


 

A while back I tried to use nbtstat on my 64bit Windows 7 machine and it seemed to not be installed.  Well, I did some more research into this.  After a while I figured out that if I launched a command prompt using the usual shortcut I had been using, nbtstat would not be found.  But if I launched cmd.exe from the start menu, it could be found.  When listing the contents of the system32 directory the files were different when depending how I launched the command line.

Here is a single screen shot of two command prompts.  The directory commands were executed within seconds of each other.  The top command prompt can see nbtstat.exe, but it cannot see audiodev.dll.  The bottom command prompt cannot see nbtstat.exe, but can see audiodev.dll. [more]

Looking at these closely, did you notice that the times on the files displayed on both command prompts were different?

The gotcha here is how Windows handles launching 32 bit programs on a 64 bit system.  Many of us have probably noticed the “Program Files” directory is for 64 bit programs and the “Program Files (x86)” directory is for the 32 bit programs.  The system32 directory is for 64 bit programs and DLLs and there is a sysWOW64 directory for the 32 bit system32 files.  But instead of the operating system just activating the correct DLL when a program needs it, it does some sneaky root kit like work.  Here is what is really going on: 

When running a 32 bit program, the sysWOW64 directory looks like the system32 directory so no matter what the program does, it cannot try to load a 64 bit DLL.  Or it cannot even load a 64 bit executable.  I was launching the command prompt by using a shortcut.  But I was launching it from a 32 bit program launcher.  A 32 bit program can launch a 64 bit program if it can find it.  But when my 32 bit program launcher went looking for cmd.exe in the system32 directory, it actually found the 32 bit cmd.exe in the sysWOW64 directory and just didn’t know it.  So Windows 7 does not come with a 32 bit nbtstat, only the 64 bit version.  So that is why I could not find nbtstat.