1) Open iTunes and navigate through the menu to: Edit --> Preferences --> Advanced (tab)

2) Click the change button and change the folder location to something like D:\My Music (you will need to create this folder.) Click OK to close the screen.

3) Close iTunes altogether.

4) Copy your iTunes folder from C:\Documents and Settings\(username)\My Documents\My Music to D:\My Music.

5) Hold down the SHIFT key and click the iTunes shortcut.

6) Click on Choose Library (to point iTunes to the new library) and browse to D:\My Music\iTunes\iTunes Library.itl. Once you have selected the file iTunes Library.itl click Open.

7) Once you have opened iTunes using the library in the new location of D:\My Music\iTunes you can remove the old copy located in C:\Documents and Settings\(username)\My Documents\My Music.

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.

Subsequently I cannot logon to the server and the Remote Desktop Connection window closes. On one occasion I contacted the data centre where the server is hosted and they logged onto the console of the server and logged the unused RDP sessions off (other administrators were not logging off the server when working, only closing the Remote Desktop Connection window). I could then logon myself remotely. As a result I had a quick think about how I could do this remotely and I now use one of the PSTools (developed by Mark Russinovich of Sysinternals – now Microsoft) to execute a couple of command line tools on the server remotely to disconnect the unused session(s) myself.

To do this I use psexec.exe to execute programs on the remote server. You should note that psexec.exe uses ports 139 and 445 (Netbios and File Sharing ports) and that in order for this to work the target computer/server should have these ports accessible by your own client computer. However, I would not recommend under any circumstances that these ports be opened to the internet because of the misuse of others and or virus’s that may be in circulation. Fortunately for me I have a direct connection to the data centre where the server is located and whilst these ports appear open for me the server remains disguised from the internet via a firewall from everyone else.

Open up a command prompt and navigate to the PSTools directory where psexec.exe resides. Now we need to get the Session IDs for all of the logged on users by running an application called query.exe on the remote server itself using psexec.exe:

psexec.exe \\(servername or ip) -u (adminusername) -p (adminpassword) query.exe session

That should return a list of enumerated users logged onto the server and the Session ID that they have been assigned.

Now we know the Session ID of the session we wish to close we can use an application called logoff.exe on the remote server again by running it using psexec.exe:

psexec.exe \\(servername or ip) -u (adminusername) -p (adminpassword) logoff.exe (session ID)

When this command executes the session that corresponds to the Session ID you obtained by running query.exe is logged off, thus freeing up a connection for you to log onto the server with.

Other options for connecting include running the Remote Desktop Client (mstsc.exe) with the /console switch which has been changed to /admin in newer versions of the client. I have used this method and sometimes still encountered problems logging on. You can also use the Terminal Services Manager as it has the ability to remotely connect to other Terminal Servers. If you want to use this method you can copy tsadmin.exe from:

C:\WINDOWS\system32

on Windows Server 2003 and run it on a Windows XP workstation to connect to Terminal Servers remotely and administer sessions.

Compiled HTML Help is a proprietary format for online help files, developed by Microsoft and first released in 1997 as a successor to the Microsoft WinHelp format. It was first introduced with the release of Windows 98, and is still supported and distributed through Windows XP and Vista platforms. As mentioned a compiled HTML help file has a .chm extension and is essentially a set of web pages written in HTML with a hyperlinked table of contents.

One of the unique features of compiled HTML Help is its ability to execute programs, a privilege not bestowed on regular uncompiled web pages. This is achieved by the use of the shortcut command, which is made available through the HTML Help ActiveX Control. As an example of using the shortcut command, a Help topic that contains an instruction to open the Printer Settings dialog can also provide a shortcut button that enables users to open that dialog with just a single click.

The problem identified by Microsoft was that in theory, an attacker could use an email to deliver a .chm file that contained a shortcut, and then exploit certain flaws to open it and allow the shortcut to execute.

As a result Microsoft released an update that closes the loopholes for all versions of Windows from 98 through to XP. When you download and install the update, you are actually updating the HTML Help ActiveX Control on your system to the latest version: 1.4a (5.2.3669.0). This version restricts the use of the shortcut command, and also fixes another important security issue that was discovered (a buffer overflow vulnerability).

Info on the security bulletin and update is available here:

MS05-026

After the update is installed a compiled HTML Help file can only use shortcuts if the Help file is located in a folder that's known to contain trusted content. For example, on Windows 2000 and XP systems, shortcuts will only operate if the file is in the Windows Help folder, the Program Files folder, the Help and Support Center folder, or in any of their subfolders. Herein lies the problem.

Many System Administrators like myself prefer to run some applications from a central shared location on a network. This because it is easier/quicker to setup an application once then on 500 computers. If the application is configured correctly then as soon as all users have the shortcut pointing to the shared network location the application should function as expected. But as you guessed if you are using a computer where the Microsoft update for the compiled HTML vulnerability has been applied then when you try to view the help file(s) you will likely be presented with a window like this:

Microsoft released the following knowledge base article with advice and workarounds for this problem:

KB896358

I won't go into detail explaining every workaround that Microsoft has provided in the article but I will explain how I tackled the problem. The way I viewed the situation was that I was willing to accept additional risk in order to get .chm files working from a shared location on the network. I believe the likelihood of sustaining a malicious attack that exploits a vulnerability of compiled HTML help is extremely low. I do however recommended that you protect against this risk, however small, by installing the update provided by Microsoft. I trust all the computers on the network so I decided to lower the restrictions on the Local Intranet zone to allow .chm files to run from the shared location. This is how I did it:

1. Click Start, click Run, type regedit, and then click OK.
2. Navigate to the following subkey:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\HTMLHelp\1.x\ItssRestrictions

(If this registry subkey does not exist, create it.)

3. Right-click the ItssRestrictions subkey, point to New, and then click DWORD Value.
4. Type MaxAllowedZone, and then press Enter.
5. Right-click the MaxAllowedZone value, and then click Modify.
6. In the Value data box, type 1, and then click OK.
7. Exit regedit.

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

1. Open the registry editor on the client (regedit)

2. Find the following registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\INTEL\LANDesk\VirusProtect6\CurrentVersion\AdministratorOnly\Security

3. Change the data stored within the UseVPUninstallPassword value from 1 to 0

4. Clost regedit and try uninstalling Symantec Antivirus from the client. It should now uninstall without prompting for the password.

You can alternatively make the Registry key change (I.e. perform all of the above steps) by saving the following file to your computer, double clicking the file and merging the contents with your registry:

Download Here (you may need to right click this link and use "save as" to save it)

In a situation where you are running a Symantec Antivirus Server managing clients you will probably want to script the registry key change through a start-up script.

I can't find any information relating to VCP from Microsoft directly but it seems that VCP has been out for a while. Its available for direct download from here:

winxpvirtualcdcontrolpanel_21

Inside the self extracting archive are 3 files:

readme.txt
VCdControlTool.exe
VCdRom.sys

The readme for the application is pretty straight forward, within a few steps you should be mounting and unmounting ISO image files from your virtual cd drive. The instructions say to copy VCdRom.sys to your %systemroot%system32drivers folder, but I found that when you browse for VCdRom.sys using VCdControlTool.exe it actually doesn't matter where it is. Here are the instructions from the readme anyway:

Installation instructions
=========================
1. Copy VCdRom.sys to your %systemroot%\system32\drivers folder.
2. Execute VCdControlTool.exe
3. Click "Driver control"
4. If the "Install Driver" button is available, click it. Navigate to the %systemroot%\system32\drivers folder, select VCdRom.sys, and click Open.
5. Click "Start"
6. Click OK
7. Click "Add Drive" to add a drive to the drive list. Ensure that the drive added is not a local drive. If it is, continue to click "Add Drive" until an unused drive letter is available.
8. Select an unused drive letter from the drive list and click "Mount".
9. Navigate to the image file, select it, and click "OK". UNC naming conventions should not be used, however mapped network drives should be OK.

Here is how I used it:

To remove/uninstall the CD-Rom driver do the following:

VCP worked well for me, it allowed me to install my program from ISO, I could even 'eject' or unmount the ISO that I had mounted in order to mount another halfway through the program I was installing (it was a 2 CD/ISO program). I've tested VCP on both Windows XP and Vista. It worked flawlessly on both operating systems and served it's purpose of letting me install from an ISO without having to restart my workstation after installing the driver. The best point of all though- its free.

Download the MySQL installer from HERE

The installer comes in a .zip file so you will need to extract it. Now run the installer (setup.exe) and select the 'Typical' setup type. Click 'Install' to begin the installation process. Once the installer copies files onto your computer you are presented with the option to 'Configure the MySQL Server now'. Make sure this option is checked and click 'Finish' to end the installation and begin configuring MySQL.

You will be presented with an option to choose a 'configuration type' for customizing your MySQL installation. Choose 'Detailed Configuration'.

You will now be asked to choose a 'server type'. Here you are presented with three options. Since I will not be using MySQL a great deal as it will only be used to serve a single website I will choose the 'Developer Machine' option. If you plan on hosting a few websites that require a MySQL database and you expect fairly heavy traffic then I would recommend the 'Server Machine' option. Since my computer's priority is not to serve multiple websites the 'Developer Machine' option is fine for me and this will use less of the computer's memory.

Next you will be asked to pick the 'database usage'. Select 'Non-Transactional Database Only'.

Next you will be asked to gauge the 'number of concurrent connections to the server'. Since I do not expect a high number of users using the database at anyone one time I will select the 'Decision Support (DSS)/OLAP' option. This allows for 20 concurrent connections to the MySQL database.

Now you will be asked to specify networking options for the MySQL database. The defaults are fine.

The following screen requires you to choose a 'default character set'. I chose the default 'Standard Character Set' since this is fine for English Languages.

You are now asked to set any windows options. I used the default option of installing MySQL as a 'Windows Service' and made sure it was set to run MySQL automatically.

The final part of this installation involves setting the security options for MySQL. I cannot stress how important it is to set a complex password on your MySQL database, especially if you computer is not protected by a firewall and is directly connected to the internet. So, make sure the 'Modify Security Settings' check box is enabled and enter a password for the default database admin user called 'root'. Make this password as complex as you can.

Next click 'Execute' to begin configuration of your database.

The wizard will configure the database for you and show blue ticks next to each part of the configuration after a successful setup.

Clicking the 'Finish' button closes the configuration wizard and completes the installation of MySQL. Should any of your requirements change and you need to reconfigure MySQL, there are two ways of modifying your configuration. The first is to manually edit the config file that contains all of the MySQL settings. It can be located at 'C:\Program Files\MySQL\MySQL Server 5.0\my.ini', the second is to browse the start menu on your computer until you find the MySQL sub menu. You can run the configuration wizard by clicking 'MySQL Server Instance Config Wizard' shortcut from within the MySQL sub menu.

I would like to say that I would have preferred to have installed apache on my server. I opted for IIS simply because I use OWA. Whilst both web servers have their pros and cons, I would have preferred apache for its mod_rewrite module. I know there are commercial ISAPI modules available (and a couple of freebies with limitations) but when weighing up the cost of losing webmail IIS was the route I decided upon.

Download the PHP installer from HERE

Now run the installer and install to the recommended directory of C:\Program Files\PHP\

When prompted for the type of Web Server you wish to setup select IIS ISAPI module

On the next screen, from the list of extensions available, select the following to be installed on the local hard drive: GD2, MCrypt, Multi-Byte String, MySQL, and MySQLi. I chose these extensions because I use a MySQL database and phpMyAdmin to manage the database.

N.B. If you find you need additional extensions later on, you can run the installer again and select the extensions to be installed from the list available.

After the setup has finished restart IIS by opening the IIS snap-in, selecting the computer icon (with the name of the computer you have IIS installed on), right clicking, selecting all tasks and choosing restart IIS

When prompted with 'What do you want IIS to do?' select the option to 'Restart Internet Services on computername' and click ok

Now, still within the IIS snap-in, browse the 'Web Sites' folder and right click the 'Default Web Site' to select properties. Select the tab named 'Documents' and add index.php to the list of default content pages. You may want to change the order in which IIS displays index pages, I moved index.php to the top of the list.

Now select the tab named 'Home Directory' and click on the 'configuration' button. Scroll down to .php in the Application Extensions window, click it to select the .php extension and click the 'edit' button. Now change the Executable path from "C:\PROGRA~1\PHP\PHP5IS~1.DLL" to "C:\Program Files\PHP\php5isapi.dll" (with quotes).

N.B. If you create any virtual websites (other than using 'Default Web Site') you will have to perform this step on them as well.

Now I made a couple of changes to the 'php.ini' file. Edit C:\Program Files\PHP\php.ini and change display_errors = Off and log_errors = On to display_errors = On and log_errors = Off. Also change both upload_tmp_dir and session.save_path paths to "C:\WINDOWS\Temp". The default paths for both of these settings is a directory that doesn't exist, hence the need to change it.

Now restart IIS again like you did earlier.

Now in the document root folder for IIS, (for me this was 'C:\Inetpub\wwwroot') create a new file called index.php using notepad or your favourite text editor. In it save the following text:

Now open your browser and browse the local computer by typing http://localhost or http://127.0.0.1 into the web address bar of your browser. you should be presented with a screen similar to the following, displaying the configuration of your PHP setup.

(click to enlarge)

If you see that page then your PHP installation for IIS has been a success!