Here are the default devices for the Windows XP Professional VM:

Since I had built the 5 Windows XP VMs from a template I had created, I decided to find a way to convert the IDE disk to a SCSI disk and update the template incase I needed to resize the OS disk in the future. The easiest way I found to do this was as follows:-

Firstly I made the following assumptions:

• I would need to add a SCSI Controller to the VM and install the drivers before booting from the VMDK (I have seen cases before where moving a HD to new hardware caused a BSOD)
• If possible I would need to change the default Controller used for new VMDKs from IDE to SCSI
• I wanted to use the LSI Logic SCSI Controller
• I wanted to make the VMDK the first SCSI device (0:0) attached to the Controller

So, with the VM powered OFF I edited the settings for it through the VI Client and added a new SCSI Device (by default it doesn't seem possible to simply add a SCSI Controller to a VM without also attaching a SCSI Device to it):

I left the SCSI Device as being a CDROM and (optionally) changed the Virtual Device Node to SCSI (0:1) so that when I converted the existing disk and added it to the SCSI Controller it would be device SCSI (0:0). I clicked Next and Finish but I didn't click OK to commit the changes:

Before clicking OK, I selected the SCSI Controller and changed it's type as appropriate. Then I clicked OK to commit the changes to the VM:

I powered on the VM and noticed that the Windows Found New Hardware Wizard prompted me to install the driver for the SCSI controller. I knew that the controller used is a LSI20320-R so I downloaded it from here:

LSI20320-R - Driver Download (Click the Support and Downloads tab)

I downloaded the appropriate driver and extracted it (for Windows XP 32bit I used LSI20320-R_xp_50700_01034132IT_1201800_1005239.zip and within that symmpi_wXP_1201800.zip.) Then I used the Found New Hardware Wizard to browse for and install the driver. Once the hardware installation completed I shut down the VM. The VM now had the SCSI controller installed and I was confident I would be able to boot from it.

I then located the datastore where the VM resides. For example:

/vmfs/volumes/<datastore>/<vm>/

You can use the Service Console or an SSH\SCP application to open the <vm>.vmdk (not the <vm>-flat.vmdk). I edited the following line:

ddb.adapterType = "ide"

For the LSI SCSI Controller I changed it to:

ddb.adapterType = "lsilogic"

After saving the file I used the VI Client to edit the VM settings. I selected the IDE disk and removed it. I then clicked OK to commit the changes.

NOTE: Remember to only 'Remove from virtual machine' and NOT 'Remove from virtual machine and delete files from disk':

Then I used the VI Client to edit the VM settings again and add the disk back. This time, because I had edited the .vmdk file to specify that the disk uses the LSI Logic Controller, it attaches the disk to this instead of the IDE Controller used previously:

The disk is added as device SCSI (0:0):

I clicked Next and Finish to complete adding the disk. I then selected the CDROM (SCSI device 1) and removed it:

I clicked OK to commit the changes to the VM. I now had a VM using the LSI Logic SCSI Controller with the System OS disk connected to the Controller as device SCSI (0:0).

Since the VM had already booted with the LSI Logic Controller installed, when I powered on the VM Windows booted normally and was immediately accessible. Subsequently, any new virtual disks created for the VM are automatically created as SCSI disks and attached using the next available Virtual Device Node.

SSH Hyperlink

The first .bat file allows for easy installation/uninstallation of the SSH hyperlink association. It is used for a hyperlink with an associated prefix of ssh://. The bat file will invoke a 3rd party SSH client and establish a connection to the host.

To create and use a hyperlink that is prefixed by ssh:// you will first need to download the latest copy of putty.exe - HERE

Save or move putty.exe (rename to this if different) to C:\WINDOWS\System32\

Download ssh.bat - HERE

Extract and run ssh.bat to create the scp:// hyperlink association on your computer.

SCP Hyperlink

The second .bat file allows for easy installation/uninstallation of the SCP hyperlink association. It is used for a hyperlink with an associated prefix of scp://. The bat file will invoke a 3rd party SCP client and establish a connection to the host.

To create and use a hyperlink that is prefixed by scp:// you will first need to download the latest copy of WinSCP.exe - HERE (use the link for 'Portable executables')

Save or move WinSCP.exe (rename to this if different) to C:\WINDOWS\System32\

Download scp.bat - HERE

Extract and run scp.bat to create the scp:// hyperlink association on your computer.

Notes

After completing the above, any hyperlinks prefixed with ssh:// and/or scp:// will automatically be opened and a connection attempt made.

A hyperlink of:

ssh://someserver

would run putty.exe and attempt to connect to 'someserver'.

For more info about using these hyperlinks on webpages and within Zenoss check:

RDP Hyperlink

Since some protocols are identified by a prefix (ftp:// http:// https://) I decided to use rdp:// as the prefix to launch mstsc.exe. I have combined the necessary registry keys and the required JScript file into a single .bat file that allows for easy installation/uninstallation of the rdp hyperlink association. When you run rdp.bat you are presented with 3 options:

Option 1. Adds registry key HKCR\rdp which contains the parameters needed to associate the rdp:// prefix with a file created in C:\Windows called hyperlink-rdp.js. The JScript file is responsible for some string manipulation that trims the rdp:// prefix and then passes the remaining string (server name) to mstsc.exe to try and establish the rdp session.

Option 2. Removes registry key HKCR\rdp and the C:\Windows\hyperlink-rdp.js file.

Option 3. Exits the batch file.

After you use rdp.bat to create the hyperlink association you can launch an rdp session by clicking any hyperlink in the form of:

rdp://someserver

Typing rdp://someserver into your browser or windows explorer address bar will also launch the Microsoft Terminal Services Console and attempt to establish a session.

Note: When clicking an rdp:// hyperlink for the first time from a browser it is likely that you will receive a prompt that the browser is trying to launch a local application. You will need to allow this in order for the Microsoft Terminal Services Console to be opened and a session established.

After creating the rdp association on my Windows computer I added a specific link to the device in my Zenoss web console by:

1) Navigating to the device
2) Clicking the options drop down arrow
3) Selecting More --> zProperties
4) Adding a HTML hyperlink to the zLinks property

The syntax for a standard HTML hyperlink is:

<a href="rdp://someserver">rdp://someserver</a>

Although the above hyperlink works, I later discovered that Zenoss makes use of TALES expressions, one of which can be substituted for the server name (someserver) in this instance. If you use TALES you would only need to set the hyperlink once globally for all Windows servers by:

1) Navigating to Devices --> Server --> Windows
2) Clicking the zProperties tab
3) Adding the Zenoss TALES hyperlink to the zLinks property

The syntax for the Zenoss TALES hyperlink is:

<a href="rdp://${here/id}">rdp://${here/id}</a>

You will then have a clickable hyperlink on the Status tab from within the Windows device (or any new devices you add if you use the Zenoss friendly hyperlink):

Note: If you are planning to run rdp.bat on Windows Vista or Windows 7 you will need to run it with Administrator privileges. You can do this by right clicking rdp.bat and choosing 'Run as administrator':

Download rdp.bat - HERE

Note: Since this article I have also written another post on creating SSH and SCP Hyperlinks

These were as follows:

1. TCP port 135
2. TCP port 2701
3. TCP port 2702

Of course a port/service should never be exposed unless absolutely required. The best practice to reduce the level of exposure would be to also configure the scope of the users that can connect to the above ports. This should be limited to specific computers that have the SCCM ConfigMgr Console installed.

To do this using Group Policy I navigated to the following location in a GPO:

Computer Configuration --> Administrative Templates --> Network --> Network Connections --> Windows Firewall --> Domain Profile --> Windows Firewall: Define inbound port exceptions

I then defined the following exceptions:

135:TCP:(scope):enabled:SCCM
2701:TCP:(scope):enabled:SCCM
2702:TCP:(scope):enabled:SCCM

Note: (scope) is either "*" (for all networks - although this is not advised) or a comma-separated list that contains any number or combination of these:

IP addresses, such as 10.0.0.1
Subnet descriptions, such as 10.2.3.0/24
The string "localsubnet"

After adding the above exceptions to clients via an existing GPO I could successfully connect to them using the Remote Tools feature in SCCM.

The machine had recently been re-imaged but as the organisation I work for requires that all users be local administrators on their own computer I suspected spyware/malware was to blame. Before I re-imaged the computer again (to be sure the machine was cleaned) I had a quick look at rectifying the connectivity issue. It seemed that Winsock2 (a Windows API that defines how Windows network software should access network services such as TCP/IP) had been corrupted. To manually reinstall TCP/IP and fix the Winsock2 issue I performed the following:

1. Browse Control Panel and then Network Connections
2. Right-click on your network connection, and then click Properties
3. Click the Install button
4. Click Protocol and then click Add
5. Click Have Disk when asked to Select a Network Protocol
6. Browse to C:\Windows\inf (inf is hidden), then select Nettcpip.inf and click OK
7. On the list of available protocols, click Internet Protocol (TCP/IP), and then click OK
8. Restart computer

Following this process the buttons for 'Network ID' and 'Change' were no longer greyed out.

Booting from the disc revealed it was unrecognised so I burned another - same issue. Burning the same .ISO from a different computer worked so I was sure there wasn’t an issue with the image. I began to suspect a faulty DVDRW drive but even after swapping it any CDs burned remained unrecognisable, even to the drive they were burned in. I tried one of the laptops that came preinstalled with the Dell Windows XP configuration and sure enough it was bootable. I then assumed there was an issue with a driver or some software on the laptop that was preventing the laptop from burning the CD successfully. A peek in device manager revealed no issues with the DVDRW device (mine was a TSSTcorp DVD+-RW TS-U633A). I checked both Dell and Intel’s websites for newer drivers but I already had the latest.

The only application I didn’t have installed was the Intel Matrix Storage Manager, a program used to monitor disks/drives and report their status and/or RAID condition. It seemed pretty far fetched but as the DVDRW drives were SATA300 I decided to install the application. After installing it and burning yet another Knoppix CD I was astounded to see that when I put it into another computer I could successfully boot from it! After testing this on another of the laptops I was sure that it was the lack of the Intel Matrix Storage Manager that was causing the CD burn to fail each time. One thing I only noticed afterwards, when initially using MagicISO to burn the .ISO image (pre the installation of the Intel Matrix Storage Manager) the application never reported it was attempting to 'Close the Session'. Since installing the Intel Matrix Storage Manager I have not had any further issues burning audio or data to CD or DVD.

The latest Intel Matrix Storage Manager is available direct from Intel - Here

A quick dig around on Google afterwards revealed similar issues for Dell owners of Latitude E6400 and E6500 series laptops. It now seems this issue is commonly found on most laptops with the same SATA DVDRW drive as above.

I recently used the following approach to create a file 5MB in size to prove that email statistics were correctly being generated. This command produces a new file called '5mb-file.txt' on the root of the c:\ drive:

fsutil file createnew C:\5mb-file.txt 5000000

The number at the end of the command is the file size in bytes. So the result is a file just under 5mb in size.

Here is a screen shot of the error I was presented with:

Being familiar with various forms of installers I started to probe into the contents of the files on the CD. I copied all files from the CD into a folder on the desktop. A quick inspection of all editable files revealed a file called Custom.ini with what looked to be a condition for the setup.exe Installshield installer.

Its contents included the following 3 lines of text:

[PowerDVD]
CLScan=DELL,Unbranded
RunDVDLauncherMCE=1

Immediately my attention was drawn to the 'CLScan=DELL,Unbranded' line. This seemed to be the condition of the installer. I tried changing the condition of the 'CLCScan' parameter into various forms such as:

CLScan=ALL
CLScan=ANY
CLScan=(blank)

None of the above seemed to work. Every time I changed the text the error message above would change to reflect the new condition but still not let me install the application. After changing the condition a few times I finally managed to get the application to install. I set the contidion to be:
CLScan=*

The asterisk saved in the Custom.ini file allowed the install to complete without any errors. I have also tried other symbols including an apostrophe and the ‘@’ symbol. You can run the command MSINFO32 to show you the manufacturer of your system which may work if one of the above symbols doesn't. Any of these methods could allow PowerDVD to successfully install. A quick test afterwards revealed that the machine had PowerDVD installed and it was indeed fully functional.

This proved a headache and I immediately thought that I should be running the application from a network share. The problem I had was that the .net framework abides by a security policy and subsequently the default security settings allow the application to run from a network share but do not allow the user to perform basic tasks like using the application to browse for an e-portfolio folder in this case.

I started looking at ways of modifying the security policy. It turns out that .net versions 1.1 and 2.0 each have their own security policy and have to be configured separately. It appears that .net 3.0 contains some extensions but still uses the .net 2.0 compilers and executables governed by the .net 2.0 security policy. Therefore any changes made to the .net 2.0 security policy should affect .net 3.0.

To make changes to either the .net 1.1 or 2.0 security policy you can access each framework's respective configuration tool the following way:

Start -> Control Panel -> Administrative Tools

and either:
Microsoft .NET Framework 1.1 Configuration or
Microsoft .NET Framework 2.0 Configuration

You will have to install the .net 2.0 SDK before its configuration tool is available, although the 1.1 configuration tool is supplied with the framework installer.

The configuration tools are virtually identical, but to make changes to the .net 2.0 framework you have to expand 'My Computer' in the view in the left pane when the tool is run.

To allow each framework's security policy to run an application from a share you have a couple of options available. You can allow a specific application to run from a specific location or you can 'Fully Trust' your local Intranet zone which will allow all .net applications to run from any share on your local network (albeit at a greater security risk). Being a school I can see there being a need to run applications from shares quite frequently, and so I wanted to change the 'Local Intranet' policy from a level of almost full trust to full trust. The Microsoft explanations of each setting are as follows:

Nearly Full Trust (this is the default setting)
Programs might not be able to access most protected resources such as the registry or security policy settings, or access your local file system without user interaction. Programs will be able to connect back to their site of origin, resolve domain names, and use all windowing resources.

Full Trust
Security checks are not performed and programs can access and use all resources on your machine. Avoid this setting unless you are certain that no potentially harmful or error-prone programs can execute from the selected zone.

Now I can see why my application didn't like to browse for files when it was run from a share! To change the security policy for the 'Local Intranet' zone you need to click on the 'Runtime Security Policy' icon in the tree view on the left pane. Then in the pane on the right click on 'Adjust Zone Security'. When prompted click next to make changes to 'this computer'. Click on the 'Local Intranet' icon and change the level of trust to 'Full Trust'. Click next -> finish to exit. This has just changed the level of trust for the .net framework who's configuration tool you ran. I repeated this for the other version of the .net framework so that both fully trusted the local Intranet zone. I was then able to run my VB.net application from a network share without any problems.

My next issue was going to be how to achieve this on over 500 computers. Luckily, each .net configuration tool is able to create an MSI that can be deployed over a network via Group Policy. To create an MSI for this you need to open each .net frameworks configuration tool, click on the 'Runtime Security Policy' icon in the tree view on the left pane, and then click 'Create Deployment Package' on the right hand pane that appears. If you decide to make your own MSI to distribute, when you attempt to use the deployment package tool you should select 'Machine' security level when you are prompted.

I initially created two MSIs, one for each .net version that would change the local Intranet zone to fully trusted. After testing these MSIs it appears that they don't appear in Add Remove Programs, and that when they are uninstalled they do not set the policy back to its original settings. So I started looking at exactly what happens when you manually change the local Intranet zone's security level. Each .net framework saves its settings in a file called 'security.config' located:

.net 1.1
C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\CONFIG

.net 2.0
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\CONFIG

I made the changes to the local Intranet security policy for both frameworks and copied the files out. They are available here:

.net 1.1 security.config Download

.net 2.0 security.config Download

I have included a condition in my MSIs (I ended up authoring my own custom MSIs) to make sure that each framework is installed before the installation proceeds. I have also tested them to make sure that when they are removed, the settings return back to the default values, and that they appear in 'Add Remove Programs'. They can be downloaded here:

.net 1.1 MSI Download

.net 2.0 MSI Download

This procedure is intended to help you in either of the following situations:

1. When you want to move a hard disk from one computer to another where the new computer has completely different hardware to the old computer that the hard disk was in originally (and you still want to boot from it thus retaining your windows installation and all applications/programs).

2. When you want to upgrade the motherboard in your computer without having to reinstall Windows and all your applications/programs. This will only work if the motherboard is still functioning, if it is not then you will not be able to boot the original computer to make the necessary change(s) required for the disk to function with the new motherboard.

To achieve this use the following steps:

Boot the first (old) computer with the hard disk in it as normal, then go to control panel, double click the system icon, go to hardware tab, and click device manager button.

Within device manager find the 'IDE ATA/ATAPI CONTROLLERS' and expand the tab. Right click the controller that bears the name of the chipset present on your mainboard (do not touch the 'Primary IDE Controller' or 'Secondary IDE Controller') and select 'Update Driver'. Select 'No not this time' when it asks if you would like windows update to search for a new driver and click next. Then choose the option to 'Install from a list or specific location (Advanced)' and click next again. Now choose the 'don't search I will choose the driver to install' option and click next. Highlight/select the Standard Dual Channel PCI IDE Controller and again click next. The Standard controller driver will now install, click 'Finish' to continue. Now reboot (click yes when prompted with 'Do you want to restart your computer now?') and logon to your computer as normal. The standard IDE controller driver is now completely installed.

After installing the hard disk in the new computer or installing your new mainboard and booting from the hard drive for the first time you will have to wait a couple of minutes before you can use the computer. This is because Windows is automatically detecting the new hardware and installing all of the relevant drivers it can. Most of the drivers are installed for you automatically. When Windows has finished updating your drivers it will ask you to restart the computer again. Once restarted launch device manager to see which items of hardware still require drivers. You will have to go to the relevant manufacturer’s website to download and install any that are missing.