Windows 7 on my Tablet

A few months ago I bought an old but nice (Pentium M, 1.5GB RAM, 30GB drive, wireless, Bluetooth) tablet to experiment and to use it as an eBook (in my opinion something far better than Kindle, the Amazon’s eReader).

One of the things I wanted to test were the new features of Windows 7, but the machine has no CD / DVD, and I have no USB-DVD.

I had read, long ago, that it was possible to create a version of XP that fit in (and boot from) a USB, so I decided to investigate whether it was possible to use a USB drive to install Windows 7.

It seems that my idea was not original, because I found a dozen blogs and articles describing how this was done.

After reading “ Install Windows 7 from a USB Flash Drive " and "Windows 7 on LE1600 - Installation from pen drive ", I decided to give it a try.

I downloaded Windows 7 Professional from Microsoft.com and I borrowed a Sony USB 5 GB from work.

I followed the instructions to the letter, but every time I tried to boot from the USB, the light blinked a couple of times and then it would just remain ON while the display only showed a blinking cursor.

Evidently, this was a boot issue. I tried doing a bootsect / nt60 , but this did not help ...

I thought that maybe the computer was slow to access the USB and it might only be a matter of patience. It was already 1 am, so I decided to call it the night and to leave the system running, but the next morning everything was unchanged.

The next day, I borrowed the USB drive, and decided to try again ...

Researching a bit more I found that " How To: Install Windows 7 Beta from a USB Key! " recommends formatting the disk as NTFS rather than FAT.

I gave it a try, this time the system started to boot, but it stopped with an error:

File:\Boot\BCD
Status: 0xc0000001
Info: An error occurred while trying to read the boot configuration data

I Google it and Bingil , but did not find a convincing solution...
I decided to try again from scratch, and sure enough, it failed again (as Einstein would say: "only a fool does the same thing over and over and expecting different results").

There I remembered that a few days ago, while updating the firmware of a system at work, a vendor insisted about not booting from a USB over 2 GB. I figured there might be a connection.
I had a 2GB USB, the issue is that the installation DVD of Windows 7 has more than 2 GB and therefore had not tried.

I decided to test, at least to help determine the problem.
Copied the whole disc except for a single file (\sources\install.wim), I knew that that file is the most important of the installation process, but I decided to continue, after all this was just a test to see if I could boot.

I placed the USB on the table, and rebooted, and lo and behold! The Windows 7 Setup began to run. Of course, as soon as I clicked install, the program complained that he could not find the file.

OK, one step forward and a new challenge...

I Connected the USB 5 GB (still had the image of my previous attempts) and clicked install, the 5 GB USB was not accessed even once and the installation failed just as before ...

I Rebooted the system to try again. This time, the 5GB USB was read, but the installation failed as before.

Looking around, I found a way to access the CMD, and I began to investigate.

My hard drive was there, in the good old C: my 2GB USB was seen as D: and the 5GB as E:, the system was running from a virtual drive X: (later determined that it was based on information from \sources\boot.wim ).

Last year we created the images for the 1200+ Windows Vista machines at work, and I became quite knowledgeable of the Windows installation process. I knew that the installation program can told from where to take install.wim information.
This option is primarily for organizations to put the file on a centralized server, or a modified version of the OS, but it should be fine for my needs.
As far as I remembered, there were two ways to specify this setting to the installer process: through an “unattended installation file” (what we had done in at work to configure the VISTA machines), or through a parameter to the executable.

I did not have an "unattended file" (nor the time or the desire to create one), so I decided to use the parameter InstallFrom for the executable.

Once again, I went to CMD, and run " setup.exe /InstallFrom:e:\sources\Install.wim ", the installer ran, but gave me the same error than before. I tried a few variations (without the file name, from different locations, adding the directory path, etc), but none worked.

I started to check the virtual disk X:, and navigated to the “Phanter” directory witch, I remembered my experience with VISTA, has the log and records of the installation process.

After a while of reading those files (very entertaining, especially when using only TYPE MORE ), I realized what my problem was: The installation and was already running.
This CMD window in which I worked had been launched from the installer and was running within the environment of the installation program, so every time I executed the setup command, the installer was restarted in memory instead of a new one being executed. That is why it was ignoring my parameters.
The program was set to find the installers in D:\Sources, and there no convincing him otherwise.

Thus, I had two choices: to create an automated installation file (unattended XML file), or tricking the system to use the USB 5GB instead of 2GB.
I needed to replace an existing disk (D:) with another disk (E:), I knew the E: drive had all the same information from the D:, so if I could replace then I should have no problem even if the system tried to look for files in the old location.

Had I have access to the disk manager I would had simply changed the drive letters, but this was not the case.

Then remembered an old DOS 3.11 command SUBST which lets you assign a drive letter to a directory.
It was a very useful command when, back in my PC-XT, we copied the games to the HD diskettes, sometimes a game would complain if it was ran from a directory, in those cases we used SUSBST to give it a drive letter and played the game from that “drive”.

I wasn’t sure if the command was still available, particularly in the reduced CMD console of the installer, but turned out to be there.

I gave it a “dry test”: SUBST R: E:\ ran smoothly, and DIR R: returned the expected result.
I knew that SUBST cannot use a drive letter that is already in use, thus I needed to eliminate the D: in order to replace it with the E:, but if I boot without the 2GB USB I would not be able to reach the installer. Catch 22

After a bit of thinking, I realized that the installer was running on Windows (a reduced version but still Windows), and I knew that the plug-and-play was working (it had detected my keyboard as soon as I plugged in).
With a little luck, if I removed 2GB USB the system would release the drive letter ... or it would hang completely:-P

I crossed my fingers and removed the USB 2GB ... the system continued to operate, good sign. :-)
I ran SUBST D: E:\ and it executed without errors, I did a DIR D: I got the expected results.
It was time for the ultimate test: I clicked on install and hold my breath until the system started to install my new OS ...

A few minutes later my tablet joined the Windows 7 family !!!! :-)

Lessons learned:
"Never retreat, never surrender"
It took me 3 days and many attempts, but finally achieved what I wanted!

"Long life to DOS!"
Most of the troubleshooting I did was using 2 very old commands TYPE and MORE , and also the solution was an old command: SUBST .

Powershell: Confirmation Level

Part of the scripts I'm making for work involve the update of several Exchange Distribution lists in an automated way.
I was on this when I run into an unexpected behavior: the Remove-DistribtionListMember Command was asking for confirmation, even when I had not specified the -Confirm parameter .

A glance to the exchange.ps1 reveled that, in effect, the Powershell environment for exchange has the confirmation Preference set to HIGH by default (thus asking for confirmation on any task that performs a important change to AD)

Changing the confirmation level it's as easy as :

$ConfirmPreference = 'High' # The allowed values seem to be High, Medium, Low, None.

But, I didn't like the idea of changing the value for the whole environment, who knows what would I like to run next ...

So decided to implement a simple temporary variable to store the value of $ConfirmPreference on the script's start and revert it to normal just before the end.

$ConfirmPreference =$OLD_ConfirmPreference

... # My Code here


$OLD_ConfirmPreference =$ConfirmPreference

My next thinking was on how cool would it be to be able to implement a confirmation switch on my own scripts, and I realize that it's easy to do:

Param(
[switch] $Confirm
)

$OLD_ConfirmPreference =$ConfirmPreference
if ($Confirm) {
$ConfirmPreference = 'High'
} else {
$ConfirmPreference = 'None'
}

...... # My Code here

$ConfirmPreference =$OLD_ConfirmPreference

Now I can have (and give to my script users) control on the Powershell confirmations.

The PATH in Powershell

One of the things I wanted to do when I had a Blog was to post a recap of the interesting things I learn periodically, specially if it took me a while to learn them or if there was some complications for me to understand them.
I will start this today with this posting.


The PATH in Powershell

Maybe because I never formally read much about powershell, maybe because I did not bother enough to find it sooner, or for whatever reason, I had never found out what to do in order to be able to execute my scripts as just another PS command, meaning be able to use

my-script

instead of

. my-script.ps1

Yesterday I decided to research on it and after some goggling I got a clue: The Script's directory MUST be in the PATH, meaning that even if you are standing right in the Script's directory, you won't be able to execute it as a command unless the directory is in the PATH. Crazy, isn't it ???

Okay,now that I knew that I need to figure out 2 things:

1. How to read the path from Powershell (I found that Path and $path did not work), and
2. How to change it (To be able to add my own directories)
   

A little more googling revealed that to get the PATH I only need to query the Environmental variables:

$env:path

Easy, right ???? ... Then, Why didn't I figure it our sooner ???

To add items to the pat, it's just as simple:

$env:path = $env:path + ";E:\My Scripts\Powershell\"

Now, that script that i was only able to execute as:

& "E:\My Scripts\Powershell\my-script.ps1"

can now be executed as:

my-script

To see if an specific directory is part of the PATH, we can use simple string functions:

($env:path -match 'My Scripts\\Powershell')

(Notice the double slash in order for the slash not to be considered as a REGEX command)

Well, not "rocket science", but it did took me a while to put all the pieces together, and I hope that I'll save some time to the next person trying to accomplish this.