Blog: Networking

We had a new printer that needed to be installed on a PC at a customer site. The new printer was USB and after setting it up, all of my test jobs that I sent to the printer failed. I tested out many different drivers and even tried using a different USB printer at one point. None of these things worked. I then finally decided to remove PGP endpoint protection and the printer started working immediately. This didn’t make much sense because my account was not supposed to be blocking anything through PGP. I checked the PGP settings and found that the “everybody” group (a distribution group setup at the bank which did not include my account) was given access to these “other devices” that this USB printer fell under the category of. The group that was meant to be there was the “everyone” group to which includes CoNetrix accounts.  This wasn't an easy problem to solve due to the lack of a useful error message.  If you use PGP endpoint protection be aware that you will not get an error message if it's blocking your printer and that USB printers fall under "other devices".

I ran into another notable gotcha working with VMware View v4. I set up Windows 7 virtual machines in linked clone pools, but I was not able to get dual-monitors to work using PCoIP. After several hours of very frustrating troubleshooting, it turns out that VMware has changed the type of display driver that is included with the VMTools install on Windows 7. Prior to Windows 7, VMware used an SVGA II driver for all Windows guest OSes. With Windows 7, they are now “experimenting” with a new WDDM (Windows Display Driver Model) driver. The default VMTools install for Windows 7 uses the WDDM driver instead of the SVGA II driver. Here are some notable limitations of the WDDM driver:

• No support for OpenGL
• No multimonitor support
• VM may be slow to respond or resume
• Overlay video acceleration is disabled (basically this means flash acceleration and MMR is disabled) [more]

I’m thinking this thing isn’t fully cooked…The original article I found on this had me extract the SVGA II adapter from Workstation 7, but it appears as if new versions of the VMTools actually include it at install time, but its just not used. So, here are the instructions to revert to the SVGA II adapter so that stuff actually works!

1. Open Device Manager from Control Panel
2. Expand Display Adapters entry
3. Right click on VMWare SVGA 3D (WDDM) and click properties
4. Click on Uninstall Button
5. Check the “Delete the driver software for this device” option
6. Click OK
7. Your screen may flicker as the driver is removed.  
8. Close Device Manager and reboot Windows 7.
9. Windows will default to the Standard VGA device
10. Open Device Manager, expand Display Adapters
11. Right Click Standard VGA and select Properties
12. Click on Update Driver
13. Click on Browse my Computer 
14. Browse to directory C:\Program Files\Common Files\VMware\Drivers\video
15. Click Next
16. Confirm driver installation
17. Close window and reboot

Troubleshooting ActiveSync without access to a users smart phone is difficult. Using an device emulator is possible but time consuming. I recently ran across a nice site from Microsoft which is useful in checking several different items associated with Exchange remote connectivity.

https://www.testexchangeconnectivity.com    [more]

One of our customers had a problem with Platespin backing up a machine to their DR VMware server.  It turns out that ESX (starting in 3.5, but can include previous builds because of security patches) has a configuration file that can prevent virtual machines from booting if there is something in the virtual floppy or CD-ROM drive.  The fix is to edit the configuration files, using SSH to connect to the ESX console and edit the configuration files with vi. [more]

http://support.platespin.com/kb2/article.aspx?id=21110&query=ESX3TaskFailed

The Microsoft Exchange team is an interesting group. For years, it seemed like they didn’t listen to any user feedback about the product. The GUI was way too complicated and automation procedures were difficult because there was not a convenient CLI for the product. When Exchange 2007 came out, even though the GUI lacked a little functionality, the product as a whole was way better and it incorporated a lot of feature requests that Exchange admins have been asking for. Most notably, the LCR, CCR, and SCR features that allow local HA and DR for Exchange with a lot less complexity than past versions.

Now, enter Exchange 2010. Exchange 2010 takes everything that we were introduced to in Exchange 2007 on the availability side (LCR,CCR, SCR) and removes it. Yep, removes it. All the availability features have been merged into one technology called Database Availability Groups (DAGs). DAGs have a really nice feature set on paper…I say on paper because I haven’t really implemented them in practice, but the one deal killer at least for most of our customers is that DAGs REQUIRE Enterprise Edition OS licenses. [more]The reason is that DAGs still depend on pieces of Microsoft Cluster Services. This kinda stinks because in Exchange 2007 you could implement database HA with LCR and DR with SCR and never buy any Enterprise licenses. Like I said, the Exchange team is an interesting group….I wonder if they discussed this and decided...”that’s no big deal…doesn’t everyone have Enterprise volume licensing”.

When setting up a public folder don’t forget to allow contributor access for anonymous users so that users external to your company will be able to send emails to the public folder.

If you track the undelivered messages you will see this error if anonymous users do not have contributor access: 550 5.2.0 STOREDRV.Deliver. To fix this you can use the following Exchange Shell command:

Add-PublicFolderClientPermission -Identity \"public folder name" -User anonymous -AccessRights contributor

I had recently changed the administrator account at one of our IT consulting customer's sites, and I kept having the account lock out.  Usually this can happen if there are disconnected RDP sessions or services that explicitly run with the administrator’s old credentials.  It is not easy to tell where the lockouts are happening from, but I found some software that I was able to demo that displayed in real time when the account locked out and which computer caused it.  There were about three disconnected sessions that kept causing the lockouts to happen due to disconnected RDP sessions.  I would log off the disconnected session, and I  would see another lockout from a different PC soon after. [more]

This software helped me know where to look, and might be useful for some of our customers that deal with user accounts on a regular basis.  You can also unlock accounts through the console of this software.

http://www.netwrix.com/account_lockout_examiner.html

While working at a customer site a couple of users reported Word 2007 has no page number gallery when you go Insert -> Page Numbers. After investigating I found that just deleting the Building Blocks.dotx file in their profile fixed the problem.

Windows XP Location:
c:\Documents and Settings\{your username}\Application Data\Microsoft\Document Building Blocks\1033\Building Blocks.dotx

Windows Vista & 7 Location:
c:\Users\{your username}\AppData\Roaming\Microsoft\Document Building Blocks\1033\Building Blocks.dotx

I’ve been researching some slow installs on one of our terminal servers for a while now. An install, which normally takes a couple of minutes, had been taking close to an hour; giving me time to complete other installs and come back to it. It seemed like a registry issue for the longest time, but I wasn’t completely sure where to begin. I found a posting on an HP forum about an older version of the Universal Print Driver leaving a ton of garbage in the registry when it was installed. Checking the tree (HKEY_CURRENT_USER\Software\Hewlett-Packard, HKEY_USERS\.DEFAULT\Software\Hewlett-Packard) and there were quite a few keys with GUIDs (100a6cf5-1f38-4593-558c-306404c054e2) running down the list. [more]

Following recommendations from http://www.rb303.net/2010/01/terminal-server-2003-msiexec-high-cpu.html, I deleted all the HP printers, deleted all the HP drivers from the local print server properties, and then backed up and deleted the trees listed above as well as the HP Universal Print Monitor key (HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Print\Monitors\HP Universal Print Monitor). I then reinstalled the necessary HP printers, one of which installed the Universal Print driver again, and checked the registry. Much cleaner.

After running a test install, it appears that removing those entries really cleaned up the registry quite a bit and is speeding up the installs. To give you an idea of the sheer size of the exported entries, in the default .reg format, the export took nearly 40MB. In plain-text (.txt) export, the size doubled. That's a lot of HP garbage.