Blog

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.

While Bitlocker is encrypting your drive, the program automatically locks your entire drive except for 6GB. This is normally not a problem, but can be an issue if you are doing significant copying to the disk being encrypted. The following verbiage from a TechNet article describes this “feature” and describes how to temporarily pause the encryption in case you need to do work that requires more than 6GB on the disk. [more]

Why does it appear that most of the free space in my drive is used when BitLocker is converting the drive?

BitLocker cannot ignore free space when the drive is being encrypted because unallocated disk space commonly contains data remnants. However, it is not efficient to encrypt free space on a drive. To solve this problem, BitLocker first creates a large placeholder file that takes most of the available disk space and then writes cryptographic material to disk sectors that belong to the placeholder file. During this process, BitLocker leaves 6 GB of available space for short-term system needs. All other space, including the 6 GB of free space not occupied by the placeholder file, is encrypted. When encryption of the drive is paused or completed, the placeholder file is deleted and the amount of available free space reverts to normal. A placeholder file is used only on drives formatted by using the NTFS or exFAT file system.

If you want to reclaim this free space before encryption of the drive has completed, you can use the Manage-bde command-line tool to pause encryption. To do this, open an elevated command prompt and type the following command, replacing driveletter with the letter of the drive you want to pause encryption on:

manage-bde –pause driveletter :

When you are ready to start encrypting the drive again, type the following command:

Manage-bde –resume driveletter :

Quite frequently on information security audits we find machines where group policies have been applied incorrectly or not at all.  The IT administrator swears the policy is working, but the policies haven’t always taken on machines.  What we can do in that situation for Windows XP machines is use GPupdate.exe, Rsop.msc, and GPresult.exe to find out more information. [more]

GPupdate

After you make changes to group policies, you may want the changes to be applied immediately, without waiting for the default update interval (90 minutes on domain members and 5 minutes on domain controllers) or without restarting the computer. To make this update, at a command prompt, run the Gpupdate.exe utility.

RSoP

The Resultant Set of Policy MMC snap-in has a nice interface and is easily used. Just go to Start, Run and enter rsop.msc. This will flash up a quick screen with a summary of the environment it’s processing.

When the progress reaches 100%, it will pull up a report for the policies upon which the computer and the user are having applied. You can browse the list, which mirrors the Group Policy Management Console, and see which policies the machine is seeing, which might not quite match what you’ve set in the Active Directory server.

You can also use this to diagnose any errors. For example, if a software deployment isn’t coming through for some reason, you can verify that it has access to the policy and has received the command. You can also see any related errors to help your troubleshooting.

GPResult

Starting with Vista SP1, RSoP no longer shows all of the group policies that a computer might have being applied to it. Instead, Microsoft recommends that you use the command line tool GPResult. Just open the Command Prompt and type:  gpresult

Being a command line tool, it opens up the possibilities to include it in scripting. There are a large number of options you can use with GPResult to get exactly what you want. You can use it to create a nicely formatted HTML or XML report and you can also use it to run remotely on another system and as a different user (provided you know the password).

Just as IT departments are finally locking down the use of removable media, a new threat may make existing technical controls irrelevant.  The “Teensy” is a USB microcontroller that plugs into a PC in the same manner as a USB thumbdrive.  But, the technical controls that are able to neutralize the use of thumbdrives and other USB storage have no effect on the Teensy.  That is because the Teensy emulates a human interface device, such as a keyboard.  Since USB keyboards are restricted by very few, if any companies, the Teensy is able to connect undetected.  The tiny microcontroller can be programmed with virtually any code- including code useful in an exploit.

Teensy devices are available online for relatively low cost- under $10 US.  It looks like IT administrators have another thing to keep them awake at night.

A customer that had been printing duplex documents to a HP LaserJet 8150 had to send the printer off for repairs.  When they got it back and reconnected it to the network, they were unable to print duplex.  Printing test pages from the printer’s console came out duplexed and the settings on the display showed that duplexing was enabled. 

When I went to look at the printer properties on the printer server, I found a setting under the Device Settings tab for Duplex Unit.  It was set to Not Installed.  As soon as I changed it to Installed, users were able to print on both sides of the page.  I’m not sure what caused the printer to lose this functionality while it was being repaired, but this was the solution. [more]

I run a Windows 7 virtual machine when I need to connect to customer sites.  From this VM I frequently create an RDP session on a customer server then run the vSphere client to connect to the console of multiple VM's.  I ran into a problem where the vSphere client would "capture" my mouse/keyboard in the console session.  Normally you would press Ctrl-Alt to release the mouse, but unfortunately when running from a desktop VM, this releases for the VM and not the connected RDP session.  The only way to get out of this is to force logoff of your RDP session from different session.

My workaround was to create a new key combination through VMware Fusion to send Ctrl-Alt to the VM.  I believe this same technique will work for VMware Workstation also.

I've noticed an increasing use of Micro USB connectors in things such as bluetooth headsets, external hard drives, Kindle and BlackBerry devices, etc.

Since so many devices use the Mini USB connector, I have more than enough of the Mini USB cables.  I looked and found some nice little Micro to Mini adapters that just plug onto the end of the Mini cable.  If you can keep from losing such a small item, it saves room and cables.

I had a problem with my iPhone. It was getting hot to the touch. I then discovered that it was chewing up download data... about 5MB every 15 minutes. This was discovered when AT&T sent me a message that my consumption of my monthly allotment was at 90%.

After many hours of work, I discovered that it was the Exchange server “push”   that was causing it to chew through data. Specifically, it was “push” on the Contacts folder. I ended up extracting my contacts folder to a PST file, and re-importing the file and this seemed to fix the issue of chewing through the Cellular Network Data. [more]

At this point, I realized that I had a problem syncing all my contacts. The contacts would just not all load onto my phone. This was not related to the issue above with Cellular Network Data, but the contacts download would just stop before synchronizing all the contacts. I had noticed this problem forever, but had not researched. It turns out that there were two contacts in my address book that were causing the problem. These contacts have been in my list for years.  After removing these two contacts ( I discovered which ones they were by dividing my list in halves  - binary search- until I isolated the culprits) everything works fine. I have not yet discovered the cause as to why these particular contacts will not sync. I sent one of the contacts to a coworker, and it will not sync with his phone (not an iPhone) either …

A network support customer was having an issue on one PC that every time he opened Excel documents with graphs generated by data from worksheets, no graph would appear. However the same Excel document opened on any other PC would work fine. If other users logged into the affected system the graphs worked. I found that defect print drivers could cause this problem, so I changed his default printer and the graphs work. Changed it back and the graphs wouldn’t work. I then uninstalled and reinstalled the drivers for the default printer he was using and the problem was gone. So do not run out corrupt print drivers when troubleshooting Office 20XX problems.