MSI file won't install if path is too long

On a clean 64-bit Windows 7 machine, I was trying to load 7-Zip from a usb key.  The 64-bit version of 7-Zip is available only as an MSI file.  Every attempt to install the MSI file by clicking "Install" on its context menu gave me the error message:

"This installation package could not be opened.Verify that the package exists and that you can access it, or contact the application vendor to verify that this is a valid Windows Installer package."

I gave up on the GUI and tried installing from the command line after navigating to the directory containing the MSI.  The command was:

"msiexec /i 7z465-x64.msi"

I had put the command prompt in the directory containing the MSI just so I could avoid typing the full path to the MSI, which would have been

"G:\`Free Programs for New Installs\7Zip\64bit\7z938-x64.msi".

This got me thinking that maybe I was dealing with a path-length limitation.

As an experiment, I copied the MSI to the root directory of  the usb key and tried the install (using the GUI, not the command line) on another Windows 7 machine.  The install completed with no errors.

Seems clear there is a path-length limitation on installing MSI files.

The Poweredge T110 That Didn't Want To Be A Bench Machine

I wanted to make this a dual-boot machine: Windows 7 and Server 2012.

After completing the Windows 7 install (to a single drive), I found that bare drives plugged into the remaining three onboard SATA ports weren't recognized by Windows as being removable.

Google being my friend, I found a utility that enabled Safe Removal of all except the system drive:
My thanks to Kazuyuki Nakayama, for devising HotSwap! downloadable at
http://mt-naka.com/hotswap/index_enu.htm

However, once Safe Removal was working, I discovered that "Safe Insertion" was not. Every time I hot-plugged a bare SATA drive into one of those three onbard SATA ports and powered it up, the server crashed with the System Event log showing Event ID 41 from Kernel-Power.

I had been powering up the bare SATA drives with power drawn from the server's PSU. I found that if I powered a bare drive from an independent power source, no problems.

Surely Dell would not have put a wimpy PSU in this entry-level server?

Surely Dell did exactly that!

When I swapped in an Antec 620M, all problems disappeared.

I wasn't sure that a standard ATX PSU would fit in the T110, because the T110  had prongs that engaged slots in the Dell PSU. Indeed, I had to flatten out the prongs in the T110 case. Until I flattened the prongs, the threaded holes in the Antec PSU didn't want to line up with the matching holes in the T110 case.

Now all I have to do is get Windows 12 installed on the second partition.

Migrating User Profiles in Windows XP

Acknowledgment

This procedure is based on an outline that Harry Brelsford published in Certification Magazine, August 2004, "Migrate Profiles on Small Business Server Networks." Thanks, Harry!

I would occasionally run into permissions issues using Harry's recipe, so with time and experiment I've added a few refinements.

Executive Summary

Assume new user's account name is "NEWuser" and we wish for NEWuser to use the "OLDuser" profile.

• Log in to workstation once as NEWuser so Windows will create NEWuser profile. Log off and log back in as admin.

• Give NEWuser Full Control of OLDuser profile under Documents and Settings.

• In registry, point NEWuser profile at OLDuser's profile.
  
  
• In registry, load hives for OLDuser's ntuser.dat and UsrClass.dat. Give NEWuser Full Control of both hives. Unload hives, close registry, log out of Windows.
  
  
• Log back into Windows as NEWuser and enjoy OLDuser profile.

How Exactly to Do It

Determine SIDs for NEWuser and OLDuser accounts.

• Download and install the Resource Kit Tool "getsid" from <http://support.microsoft.com/kb/927229>
  
  
• Get newuser's SID by running from server "getsid \\servername NEWuser \\servername NEWuser"
  
  
• Get OLDuser's SID by running from server "getsid \\servername OLDuser \\servername OLDuser"

Let Windows create the NEWuser profile. Login to workstation once as NEWuser, thereby automatically creating:

• The NEWuser profile at %SystemDrive%\Documents and Settings\NEWuser

• The registry pointer at HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\SID_of_NEWuser\ProfileImagePath
  

Log off NEWuser and log back into Windows as local admin. (I don't like to log on to mystery workstations as domain admin and thereby risk handing domain admin credentials to resident malware.)

Open an explorer window using runas domain admin. Navigate to %SystemDrive%\Documents and Settings\OLDuser and change permissions:

• Add NEWuser and give NEWuser Full Control
  
  
• Click Advanced, check "Replace permission entries on all child objects with entries shown here that apply to child objects."
  
  
• Click Apply and wait for process to complete.
  
  
• OK your way out.
  

Launch regedit with domain admin credentials.

First we need to point the NEWuser to the OLDuser's profile:

• Navigate to HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\SID_of_OLDuser\ProfileImagePath
  
  
• Double-click the ProfileImagePath key and copy the path to the Windows clipboard
  
  
• Navigate to HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\SID_of_NEWuser\ProfileImagePath
  
  
• Double-click the NEWuser's ProfileImagePath key and paste the path you just copied from the OLDuser's ProfileImagePath.
  

Now we need to give the NEWuser permissions for two registry hives that are located in the OLDuser's profile.

To change permissions on ntuser.dat:

• Highlight the HKEY_LOCAL_MACHINE key (if you don't highlight either HKLM or HKU, the next step will be greyed out).
  
  
• Click File>LoadHive, and navigate to "C:\Documents and Settings\OLDuser\ntuser.dat". Click Open
  
  
• You'll be asked for a keyname. Any arbitrary name is fine, but I'd use something like OLDuser-ntuser. Click OK
  
  
• You now have a new subkey under HKLM named OLDuser-ntuser. Right-click it and click Permissions.
  
  
• Add NEWuser and give NEWuser Full Control.
  
  
• Click Advanced, check "Replace permission entries on all child objects with entries shown here that apply to child objects."
  
  
• Click Apply and wait for the process to complete. OK your way out.

To change permissions on UsrClass.dat:

• Highlight the HKEY_LOCAL_MACHINE key again.
  
  
• Click File>LoadHive, and navigate to "C:\Documents and Settings\OLDuser\Local Settings\Application Data\Microsoft\Windows\UsrClass.dat". Click Open.
  

• You'll be asked for a keyname. I'd use something like OLDuser-UsrClass. Click OK.
  
  
• You now have a new subkey under HKLM named OLDuser-UsrClass. Right-click it and click Permissions.
  
  
• Add NEWuser and give NEWuser Full Control.
  
  
• Click Advanced, check "Replace permission entries on all child objects with entries shown here that apply to child objects."
  
  
• Click Apply and wait for the process to complete. OK your way out.
  

Now we need to Unload both of the hives on which we just added permissions. Don't want to forget this.

• Highlight HKLM\OLDuser-ntuser and click File>UnloadHive. Yes, you're sure.
  
  
• Highlight HKLM\OLDuser-UsrClass and click File>UnloadHive. Again, you're sure.

Close Regedit and log out of Windows.

Log in to Windows as NEWuser. You should have the familiar OLDuser desktop and customizations.

How to Index that Shelf Full of Bare Hard Drives

I've got maybe a dozen bare or USB HDDs that I use for storing disk images and other big chunks of data.

When I'm heading out to a customer site, I'm never sure which HDD has enough free space for the disk image I might want to make. And when I need a particular disk image, I'm never sure on which HDD it might be stored.

So I have to connect 3 or 4 HDDs to my bench machine, boot it up and look at the HDDs with Windows Explorer. Then I have to rinse and repeat with the next 3 or 4 drives, until I find a HDD with sufficient free space or with the particular disk image I'm looking for.

Today I went looking for a better way, and I found it.

WinCatalog Light is a free download at www.wincatalog.com. It builds a catalog by scanning individual HDDs. Scans are very fast; typically just a few seconds for a complete HDD.

In the screenshot below, you see a catalog of HDDs whose volume labels were ComboGB_1, Dock_1, Dock_2, Dock_3, and Dock_5.

What's special about this is that we are now looking at a fully browsable, fully searchable, Explorer-like view of HDDs that are no longer attached to this machine.

USB/eSATA external HDDs for backup

I hear lots of concern about whether 3.5" portable HDDs are really sufficiently dependable to use as a backup solution. I've had no problems, but then I don't buy mystery packages. I choose my drive and I choose my enclosure. Here's what's worked for me.

Drives:

I use server-grade drives, typically Seagate Barracuda ES or ES.2. Seagate claims a 10x improvement in unrecoverable error rate compared with their desktop drives. MTBF is 1.2 million hours. Warranty is five years.

Drive Enclosures:

I use the MacAlly PHR-100 SU enclosures. These take SATA drives and have both a USB and a SATA connector. The drive is somewhat vibration-isolated from the enclosure by silicone-rubber donuts at each mountpoint. Note that the SATA connector is not eSATA, but the enclosures come with an adapter for connecting to eSATA cables.

Once you get the hang of it, you can mount a drive in an enclosure in about six minutes.

Carrying cases:

For transporting the drives, a $15 foam-filled pistol case works great.
<http://www.midsouthshooterssupply.com/item.asp?sku=00008811>
They're way lighter than Pelican cases, and way cheaper too. Three layers of foam; just make a cutout in the center layer to fit your drive. Sooner or later the drive is gonna get dropped or tossed in somebody's trunk. The pistol case takes away the worry.

Recovering an Orphan OST File

Googling for 'convert ost pst' turned up a handful of ~$600 utilities which promised to do the job. The search also turned up a $75 utility called "Recovery Toolbox for Outlook" which turns out to be a winner.

www.recoverytoolbox.com

It has some limitations, most notably that it cannot output pst files greater than 1GB. The workaround for a multi-GB OST or PST file input is to save the output as multiple 1GB PST files.

My OST file was only 174MB, but the recovery to PST file took about 3.5 hours, during which time Task Manager showed Outlook.exe continuously at ~45% of CPU and RecoveryToolboxForOutlook.exe at ~15% CPU. I suspect that this utility relies on Outlook to do much of its work.

While the processing is going on, there's a progress bar and counter for items recovered. The bar moved quickly at the beginning but very slooooowly toward the end. The last 500 of the 5000 total items were taking about 15 seconds each to process. The machine was a 2.8GHz P4 with 1.5GB ram. If I had to recover a multi-GB OST file, I would run the process on a dedicated machine and expect it to take a couple of days.

One other anomaly: When I opened the recovered PST file in Outlook, all the email items showed the date of the recovery operation in their Received field instead of the original Received date. Configuring Outlook to show the Sent field was an adequate workaround for my non-forensic purposes - the Sent field dates were good.

Update: The developer says the slow processing I experienced was likely due to my AV scanning each recovered item. And possibly also due to my desktop search utility (X1) that was also scanning in realtime. And he confirms that you cannot save to PST unless you have Outlook installed. I received his response just six hours after emailing my questions, which is a very nice level of support.

Safely Removing SATA and USB drives with a batch file

The devcon utility from Microsoft Downloads is what does it, but it's had me baffled for years. So now I've finally figured it out.

First we have to identify our removable device. The drive we're looking for is a 120GB Seagate drive in a USB enclosure . From the command line run

devcon classes



We can make a pretty good guess that our hard drive is going to fall within the class named "DiskDrive."

Now run the command

devcon listclass diskdrive



This lists all the Device Instance IDs in the DiskDrive class. At the bottom of the list are two USB Device Instance IDs. The bottom one is clearly the USB enclosure with our Seagate drive.

So here's our command:

devcon remove @usbstor\disk^&ven_st312002*

• We need the "@" symbol at the beginning of the Device Instance ID string to let devcon know that the string is in fact a Device Instance ID.
  
  
• We need to insert the "^" symbol preceding any occurrence of the "&" symbol; otherwise the string immediately following the "&" will be interpreted as a separate command.
  
  
• We need to truncate the Device Instance ID string and add the "*" wildcard at the end of it rather than using the whole Device Instance ID string because we want the command to work with any of our USB enclosures containing Seagate 120GB drives that we're swapping in for backups.

Now let's run the command.



Did it work? Let's do the devcon listclass diskdrive command again.



The USB enclosure with our 120GB Seagate drive is gone.

What if we need to re-connect this USB drive without trucking out to the customer site? Just run devcon rescan and then run devcon listclass diskdrive to confirm.