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.

I have seen issues before on Windows XP machines where I couldn't open or run compiled HTML .chm from a network share (.chm files would fail to display any content in the same fashion as this problem was.) The only differences in this case being the file was local, it was on my desktop on my Vista computer!

After eventually right clicking the .chm file and checking properties I noticed an option at the bottom of the 'General' tab:

The option explained that "This file came from another computer and might be blocked to help protect this computer."

Since I had downloaded this help file from Microsoft's website I knew it could be trusted and clicked on the 'unblock' button. After which I could open the file as per normal and it displayed both the table of contents and all of the information/content.

Note - files with a .chm extension could potentially execute commands on your computer leaving you subject to malicious attack. If the .chm file is untrusted you shouldn't click the unblock button and open the file.

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.

There is a known problem with Vista clients that causes IE7 to crash when using OWA. I have found this is usually when users have gone through the effort of composing an email and hit the 'Send' button. IE7 then crashes with the standard issue 'Program not responding' response at any attempts to recover from it.

I have only ever noticed this problem on Exchange 2003 SP2 and cannot confirm if it happens pre SP2 but it does only seems to affect Vista clients running IE7 and not XP running IE7.

The cure to this problem is a Hotfix released from Microsoft. Although the Hotfix has been out for a while, unless you have tried it by chance there is likelihood that you wouldn't as the description is somewhat vague. The knowledge base article can be found here:

KB911829

And you can download the Hotfix from here:

Download Hotfix for KB911829

Install the Hotfix on your Exchange OWA facing server. You will have to reboot your Exchange server and key services like 'Microsoft Exchange Information Store' are stopped during the installation. This will obviously cause all outlook clients to disconnect from the Exchange server. You may also then need to instruct Vista users to log into OWA and navigate through:

Options -> E-mail Security -> Install S/MIME

to reinstall S/MIME.

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.

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.

The most noticeable was a problem with all Vista clients. After patching the servers it seemed all Vista clients were incredibly slow at authenticating and generally transferring any form of data between client and server. A quick test with a Windows XP client revealed that browsing a file server was not unbearable like the Vista client, but there was a noticeable difference in waiting for directory listings etc.

Another problem that immediately came to light was the dramatic degradation of performance on terminal servers. Although I could still log onto the terminal server (albeit very slowly), the client was very slow to respond to any changes I made on the server such as typing into a text document and the sudden movement of minimizing different windows etc.

So it seemed I had a very big problem on my hands, luckily I didn't install the Service Pack during the working day. I was stumped as to what was causing the problem, but a quick Google returned some interesting results. The first was this:

Wally McClure's Blog

Apparently Vista automatically tunes its network settings to make the most of the available bandwidth. In some scenarios though Windows Vista can fail to connect to the network. To view the current TCP optimisation settings issue the following command in a command prompt:

netsh interface tcp show global

The procedure for fixing the problem with Vista clients seemed easy enough, log onto the Vista clients as an administrator and issue the following commands in a command prompt to disable autotuning:

netsh interface tcp set global rss=disabled
netsh interface tcp set global autotuninglevel=disabled

I have to confess that I never tried the above method to cure the problem of Vista clients experiencing slow data transfer. The reason for this was that I was more concerned with the problem that terminal services users were going to experience and any other problems that Windows XP clients faced (since it was only a colleague and myself that were using Windows Vista). On Wally McClure's Blog was a link to an interesting article on Google Groups:

Google Groups - microsoft.public.windows.server.general

A post made in the Google Groups article suggested "The fix is to start the Windows Firewall service on the Windows 2K3 SP2 server". After a discussion with a friend and fellow admin it was decided to start the 'Windows Firewall/Internet Connection Sharing (ICS)' service on all Windows 2003 servers. I actually implemented this through group policy on all Windows 2003 file and terminal servers. I also changed the policy setting for 'Windows Firewall: Protect all network connections' to Disabled. So effectively the firewall service is running but not protecting.

After running a gpupdate on the servers everything was fine. Vista clients were able to authenticate and browse for files at speeds prior to those of the SP2 installation and terminal services was responding as it should. I didn't have to disable autotuning on the Vista clients.