Terminal Services Gateway online

Finally after a year we have got our Terminal Services gateway online for remote access to our terminal server. I’m not saying that I spent a whole year trying to get it running, rather that it has taken that time from when we first installed the server, until I have had the opportunity to get all the pieces in place and the various configuration tasks completed. Terminal Services Gateway, now renamed Remote Desktops Gateway, is a significant leap forward in terms of being able to securely log in to a terminal server remotely (over the Internet). It encapsulates the traffic of the TS session over the HTTPS protocol through port 443. There is therefore a considerable advantage in terms of the configuration for firewall administrators. Along with the usual Remote Desktop connections, you can also deploy TS Remote Apps to your users. RemoteApp enables you to deploy applications for remote access rather than full desktops. You can also use TS Web Access, which allows users to start a TS session in their web browser (Internet Explorer only as it requires an ActiveX control). All they have to do is type in the URL of a web site that is running on the terminal server to get their session started. RemoteApp works by starting up a desktop session to run the selected application. This appears just like an ordinary window on the user’s PC even though the application is running remotely and it’s a little difficult to tell the difference sometimes. When the user quits the application, the TS session ends so it’s all pretty seamless.

LED Lights For Outdoor Use Vs Halogens, Cordless Spots Etc

As you see, my recent reviews have covered several different types of LED torch. The design of these is getting better all the time. The cheapest ones tend to use standard LED epoxy packages with no reflector or a simple flat reflector made of aluminised plastic, sometimes there will be a small lamp with a big magnifying lens over it, other times a multiple number of relatively low power LEDs are used to get a higher output. Better quality comes with a high power flat emitter with a proper reflector and all the of the best torches do this. Due to having a hobby until recently that required high brightness lights to be able to spot people and landscape in dark conditions (i.e. no streetlights) at long range, I have had an interest for sometime in very high brightness portable lights, ones that can be carried on the front of my bike in particular. The furtherest I went with this was a Narva 180 mm 55W car spotlight on the front and a 12V gel cell battery on the rear with obviously wiring in between. This was a lot of fun but I decided for various reasons to give this hobby away and sold everything except the Narva which I still have. Still it was more practical than various cordless spotlights on the market which can have a battery life of 10 or 15 minutes per charge when continuously operated or are impossibly huge and heavy etc. At the same time I was also experimenting with MR16s which can now be got in LED models, the latest I had was a 3x1 watt CREE unit from Jaycar with 270 lumens output which is still around somewhere. LEDs main advantage is much more efficiency, now about 5x but practically the same as fluorescent so there is as yet no advantage in commercial lighting, it is more beneficial in applications where fluorescent is impractical. So what would be needed to get a 55W output from an LED? It would probably have to have a 10 W output and perhaps 15W input power so having only a quarter of the power draw of the 55W halogen bulb would probably lead to 10x the battery charge life, therefore a much more useful battery life of 2-3 hours or a smaller battery. Result being a smaller unit perhaps one that can run off NiMH D cells instead, 6 volts or whatever.

The fact at the moment though is that a 10W output emitter would be fairly expensive presently, once the prices come down it will be more worthwhile. I did some research with the Jaycar online catalogue to prepare this article and found they have some torches with claimed outputs up to 176 lumens although no telling how usable that is. So there are a range of torches out there other than Energizer that are putting out good strong light outputs although how they compare in practice really remains to be seen. What I would actually like to see is some really bright lights to fit on the front of a bike, at the moment you have a choice of either a light powered off AAs that is all in one, or a much higher power one with a separate battery. Whereas it should be possible to make one that uses Cs or Ds in the body, granted it will be a bigger unit but the power increase will be extremely useful. The main uses I am now interested in for LED lighting are for cycling, and camping. The latter being served well by the Energizer FL452 4 D folding LED lantern as previously reviewed for use in a tent type of situation. On the bike I have my Cateye headlamp, however I feel with considerable justification that a much brighter headlamp could be produced under $100 and that has obvious benefits for visibility (both ways) at night time. As noted before I played with MR16 LED lights, but no one makes these as something that is all in one or can mount straight onto handlebars. The fittings I had had to be bolted onto the bike with a separate battery pack. Whilst such lights have their uses they are very expensive high end models, all I want is something like 100 lumens in a narrow beam running off perhaps 4 Cs.

Energizer PROSW2A comparison with Cateye EL-530 Cycle Headlight

A few weeks ago I reviewed the small handheld Energizer “Hard Case” 2 cell AA swivel head LED torch. Given I also own a Cateye EL-530 LED cycle headlight, it was only ever going to be a matter of time before I decided to compare them, although in fact this is the first time I have had the opportunity. As I noted the PROSW2A claims a 75 lumen light output and 5.5 hours runtime (presumably on the supplied 2 Energizer alkaline cells). Cateye chooses to measure the cycle lamp’s output as 7000 candlepower with the centre of the beam at 10 metres being 1000 candlepower. This means a direct comparison of the outputs is rather difficult to compute. Cateye also says the 4 AA batteries will last up to 90 hours. Since no definition is given by either manufacturer of what level of useful output is obtained at the different times, these figures are somewhat useless. Therefore I can only use an unscientific direct comparison of the usefulness of the two lights when placed side by side and observed illuminating the same target at various distances. All of these comparisons showed the Energizer was much brighter than the Cateye.

Since there is an inverse square law at work, the actual light output of the Energizer could well be more than double the Cateye, perhaps 3 or more times the brightness which could account for the substantial difference in battery life although the Cateye has twice the power available from its battery. And the Cateye has a much bigger reflector which, however, in my opinion is wasted by the small emitter which is basically the same size in the Energizer yet the reflector is much better tailored to its characteristics in the latter. I am guessing overall that a combination of factors in the Energizer including much more power output and substantially higher (by percentage) amp-hour current draw off the smaller battery accounts for the significant battery life difference. As we all know, the higher the discharge current, the lower the capacity. An average battery with a capacity of say 2500 mAh is usually rated to produce that at a current of say 250 mA, if the discharge current is 1 A or 2 A or 5 A the capacity is much less and drops roughly inversely proportional to the current. This effect is caused by the internal resistance of the battery, at the higher currents more power is being wasted across this resistance before it gets anywhere near a load and this also accounts for the battery heating up at high discharge currents. At a very rough guess the 3 watt emitter in the Energizer has a 5 watt input power, this would require a current of nearly 2 amps which is pretty high even for alkalines. There is a possibility of course that 5.5 hours is not continuous. Likewise the 90 hours of the Cateye is not continuous perhaps. At 6 volts for say a 1 watt emitter 2 watts input the current is something like 350 mA. But that doesn’t really account for the 90 hours, surely this must be a mistaken number. The mystery continues…

Energizer Folding LED Lantern FL452G

As I noted previously we are starting to see LEDs become more widespread in Energizer’s product range, a good trend considering the brand’s ubiquity and the advantages of high power white LEDs. For the purposes of this article I am comparing this battery powered lantern with a more traditional style, a fluorescent Energizer model as shown in the picture below.

On the left is the old model Energizer fluorescent lantern with the new design using high brightness white LEDs on the right. Both use 4 D cells but the lantern on the left also contains a torch and flashing amber warning light. On the other hand the LED lantern has two brightness settings and a “night light” provided. It currently retails for around $40 in NZ. A clear sticker attached to the front of the unit incorrectly claims that the two power settings are obtained by switching on 4 or 8 LEDs when in practice all 8 LEDs are always used at two different power outputs.

The LED lantern has 2 light tubes with 2 white LEDs at each end, a total of 8. The design provides for the light head to be swivelled through 180 degrees in the vertical plane, the rear part of the unit using a built in stand and the battery weight to prevent the unit from tipping over when the head is rotated out from the fully closed position seen above. The unit can also be hung using the handle fitted. A slide switch selects 2 brightness settings and a separate orange coloured night light. As is typical with the brightness settings there is only a small difference in perceivable brightness between the two settings, however it is to be expected that the change in power consumption would be more significant. Energizer claim an output of 50 lumens and a maximum runtime of 245 hours on the lower setting using Energizer Max cells. If used 5 hours a day this equates to about 45 days continuous operation. For comparison, nothing is known about the Energizer fluorescent lamp that is shown on the left of the above picture. It has only one brightness setting, and is presumed to use a fluorescent tube of about 6 watts. In my very unscientific comparison the two units have similar light outputs, the LED unit’s main advantage being the swivel head capability which gives more down facing output when the head is raised to the 90 degree position. Neither light could be considered really suitable for reading unless you are very close to the light; they are more useful for general low power illumination  such as of a tent when carrying out activities that don’t need too much light. The LEDs used in the LED lamp are not particularly high brightness and would not necessarily be more efficient than the fluorescent light unit, although considerably more efficient than older style lanterns using incandescent bulbs.

The main advantage therefore in the LED lantern reviewed is its ruggedness, with the fluorescent tubes in such type lamps being at risk of breakage. Finding replacement tubes can also be difficult should they break or burn out. It is also easier to seal a LED lantern against the weather since no provision for changing the LEDs is necessary due to their very long life.  However Energizer has not made any specific claims about the weathertightness of the LED lantern. The light tubes worked better than expected in giving a good even spread of light along the length of the tube although it was always going to be brighter at the ends. The swivel head works well and is a feature almost never seen on similar fluorescent units. I expect the FL452G will prove useful for years to come in camping type applications.

Explorer path length bug workarounds

Following on from this morning’s post I checked out a couple of GUI based tools from Microsoft:

• RichCopy is an internal MS tool they released to the community a while back. It works very well – when it works. When I used it, it crashed numerous times – apparently it can’t handle long paths at all. Another time it locked up the PC and it had to be rebooted. Due to these severe problems I regret I cannot recommend RichCopy (4.0.211)
• Robocopy GUI is another MS tool that is basically a front end for Robocopy. Once you work your way around the options it is very powerful just like Robocopy and frees you from typing a long command line. In testing it has proved to be as powerful and robust as it should be. Kudos for this solution.
•  

UPDATE: Robocopy GUI could only be run once. After that it simply would not run anything at all. When I tried using Robocopy from the command line with the same switches it works perfectly. As far as I can see, right now, this GUI version 3.1.2 has some severe limitation and the only thing it is useful for right now is to save me having to look up all the switches to use Robocopy from the command line (Which works!)

When is Microsoft going to fix Explorer’s biggest bug?

School sysadmins everywhere will know this problem. You go to back up or copy some folder where pupils have been storing their files. The error you get is “the path is too long” and you check and find the path is longer than 256 characters. Now it so happens that many older APIs in Windows work with this limit (actually 260 characters). However many years ago the Windows 32 bit API was updated to allow paths of 32768 characters. So the fact that the API can use these long paths is reason enough that the Windows Shell (that is, Windows Explorer and the other GUI components that make up the basic desktop functionality of Windows) should have used them by default. Our only workaround is to either use some third party tools, some of which are command line that you have to try to remember the syntax and switches for, or reconstruct paths in Explorer using the \\?\ prefix which forces a switch to the 32768 character path length API (and then you have to remember the special syntax for that). I want Windows to automatically allow the 32768 character length when browsing ordinary folders and files in Explorer, by default, and in other parts of the shell. It’s high time that it did.

Ghosting a server using Windows PE

When we first started to use Ghost, it used to run on MS-DOS or PC-DOS and it was just a 16 bit package. I never tried it in anything other than a desktop context. At that time our servers were not in my area of responsibility for set up and install. Later on I got more responsibilities, but up until now I have not tried to use Ghost much beyond desktop settings. The main issue using it on a server, compared to a desktop, is that custom drivers may be needed for things like a RAID controller. I don’t know how anyone would make Ghost work with Dos drivers for these devices; these days it is just easier to run Ghost over Windows PE, which can use the same old Windows drivers. Doing this requires that these drivers be added to the Windows PE image so that they can be loaded when PE boots. An alternative is to use Drvload to load the drivers when PE is running. I don’t know if this will work well with disk drivers. I also wanted to add network drivers for some of our newer motherboards which are not supported by PE 2.0 out of the box, and in which case therefore I could not ghost over the network, only to a local external HDD. Whether or not we continue with Ghost as we transition to Windows 7 / 2008 R2 is not very clear. But knowing how to customise PE will be of benefit either to the use of Ghost or to WDS which shares the architecture. So it is worthwhile to learn this technique for now.

First thing is to install WAIK to get PE up and running under Vista SP1. After this step, I copied my previous winpe_x86 folder from the XP computer I used before. It already has the files and folders that the Copype script copies for you when you set up the first time, including the Mount and ISO folders, as described here. The next thing to do is to get started on the steps needed to add drivers to PE. There are a lot of useful sites, including some from Microsoft of course :). We have to install the WIM system filter first as shown here. Then I start on the steps as listed here. I copied boot.wim to customboot.wim in the sources folder. I then mounted customboot.wim to my mount folder, this gives me access to the contents of the image which you can use just as if it were a set of ordinary files and folders. At this stage the next step is to get the drivers. Here is a problem. The server is only 4 years old, yet Intel has not produced any drivers for it beyond XP/2003. This is where I hate Intel. They are one of the worst of the hardware manufacturers for supporting their products when a new operating system comes out. The “Vista Ready” debate and subsequent lawsuit revolved around the fact that Intel decided their 915 chipset wouldn’t get a native Vista driver released. Not only that, they then proceeded to persuade Microsoft to change the specs of “Vista Ready” so that the substandard performance of the 915 would meet the requirement. As a result a lot of people found their nearly new 915 chipset boards wouldn’t do Aero under Vista.

Anyway back to getting the drivers. The ones I want are:

• The Intel SE7230NH1 RAID Drivers – latest OS supported is Windows Server 2003 (x86) so we will have to try that one – SataRaidwin.exe
• Intel Q35 network card drivers - Vista. These come as a file called ProVista32.exe with no options on the installer itself if you just want to extract the files for other use. On Symantec’s website I found the instructions – run this with the switches /s /e /f C:\temp to extract it to a path which is the last parameter as shown.

Having got these I copied the folders to the Drivers folder I created under my Custom folder. The next step is to use peimg to inject the drivers to the mounted image looking something like:

peimg /inf=DRIVE:\Temp\Driver\FOLDER\*.inf /image=DRIVE:\Temp\Mount

Changing the paths etc as appropriate.

The next step is usually using peimg to prep the image, a useful step that removes unused stuff out of the image to make it smaller, which I skipped.

After completing this step, commit the image. Typing something like:

imagex /unmount /commit DRIVE:\Temp\Mount

This puts everything back into your image’s WIM file. In this case customboot.wim is the name I gave it. You then copy your wim file to boot.wim in the sources directory where you got the original file from.

You then build your ISO file for burning a boot CD using something like

oscdimg -n -bc:\winpe_x86\etfsboot.com c:\winpe_x86\ISO c:\winpe_x86\winpe_x86.iso

From there, all you need to do is burn this to a CD and there you have it.

I am quietly pleased to report that the RAID driver injection was successful. The RAID based volumes on the server all showed up as normal disk drives in PE and I was able to image them successfully using the Ghostcast server. This was necessary because I had to drop out one of the RAID arrays completely and replace the disks with new ones (the existing disks were the dreadful Seagate Barracuda ES ST3500320NS drives that have had an appallingly high failure rate and bad firmware problems. We had four of these fail in another server and whilst this server hasn’t had any problems with its pair, I grabbed the chance to put in two Western Digital WD1002FYBS 1TB drives, which of course in a RAID-1 config gives me 1 TB to play with.

It looks like Symantec has given up the ghost (as the saying goes) on supporting the 16 bit version on Dos any more, they now supply Windows PE as their platform for the software. As I said, I don’t know if we will continue with Ghost in the future, but we will be using Windows PE across other technologies so learning these steps is worthwhile. But now since 7 has brought in PE 3.0 we have to learn that new platform and techniques, gaaaaaahhhhhh…