[Not really] booting from USB in MS Virtual Server

Many virtualisation suites for the desktop won't let you reliably boot from physical disks, if at all. Virtualbox and Vmware spring to mind instantly. I also only use these on the laptop, rather than my desktop, so I started fiddling about 15 minutes ago to see if I can get what I want done with MSVSR2SP1.

Turns out it's actually quite easily done, although at the end of the day I wasn't strictly booting from the USB device itself, but an image of it which can also be acheived with almost all other packages.

  1. Create a Linked Disk in the MSVSR2SP1 web console. You need to make sure that you've not got the device mounted (i.e. no drive letter - remove it from under the disk management MMC in the usual way)
  2. Next Inspect the vhd you've just created, then select convert to dynamic disk.
  3. Wait a few minutes and you're done. You can then link this to any VM you want.

The reason you can't directly link the USB is that it's "unsupported", like so many other virtualisation solutions.

My goal? To test my customised bootable USB pendrive I've been carrying around. Turns out integrating DBAN and your regular bootable linux pendrive is actually quite easy, if you're using syslinux (much easier than I imagined). Now I just need to learn more about squashfs and getting what I want in it.

Automagically configuring Wyse thin clients running "blazer"

It's probably no secret to some people who read this that I do a fair bit of work with terminal servers and thin clients (dumb, low power machines that connect to a terminal or citrix server). However, most deployments I've been involved with at work at relatively small, our largest of which has recently gone up to a load balanced set of 5 Windows Terminal Servers, a few weekends ago.

In the past we've always manually configured the thin clients, as they've always been rolled out over a long period, typically in very small quanities (no more than one or two); slowly replacing aging computers. However, this project is effectively a new cluster of terminal servers (replacing some aging hardware it was decided that it would be a good opportunity to do things properly). Personally I didn't really like the prospect of going to each one in the building and manually fixing the config, or using a CNAME in the local DNS, as many probably need firmware updating and altering in other ways to bring them inline with the rest.

In the past I knew that the Wyse S10's (which is the model we've mostly got deployed with this client) were administratively configurable (by this I mean en-mass from a single point, á la group policy), but I had never really gone hunting for some decent docs until three-four weeks ago.

I stumbled across freewysemonkeys.com, an absolute gold mine of documentation for anything Wyse thin client related without having to wade through all the other "user guides" from Wyse themselves. Whilst the docs weren't always 100% accurate for our model they did give me enough of a leg up to get everything we needed working perfectly on all but the oldest S10's (unfortunately getting a firmware update from Wyse currently requires a support contract, according to their site).

A few days prior to this project I had tested it on another, much smaller client, as I was on-site virtualising part of their systems, and it worked awesomely well. Based on the configuration we will now beable to tell if a thin client has a proper network connection by simply asking what colour the background of the thin client is, setup various remote connections, wallpapers and icons, automatically reflash the firmware if there's a newer version available, etc. all of which is picked from some basic DHCP scope options and a FTP server.

There are other solutions for the various thin client's out there, so if you're still manually configuring stuff by hand before shipping out to a customer, I recommend investigating for your chosen make and model, no matter how small your deployment is. It'll make your life as an administrator, and the life of your users, much easier.

MS ISA Server 2004 to Draytek Vigor 2800 IPSec Tunnel

A few weeks ago I had to setup my first IPSec tunnel between ISA 2004 and a non-Windows device, in this case a Draytek Vigor 2800, to create a site-to-site VPN. I had a few things that I hit on the Draytek which stumped me for a little bit (although probably could've been resolved much more quickly had I been more familiar with a Draytek Vigor I fear).

First thing I did was to head into the ISA console and setup an IPSec tunnel, using almost all of the defaults (this is important as the settings for the Draytek must match the ISA/Windows defaults). If you're not familiar with ISA, then the process is roughly as follows;

  1. Under VPN and then Remote Sites, hit "Add a remote site network" under tasks.
  2. Select IPSec tunnel, bung in the external IP of the draytek for the "Remote VPN gateway IP address" and selected the external IP for the local gateway (what you'd probably refer to as the end points if you were doing this in anything else), add the authentication (either PSK or cert. - in this example I'll use a PSK, although you might want to think about using a certificate once you've tested it with a PSK), added the remote address subnet and then pretty much followed the defaults.
  3. Apply this and then head to Configuration > Networks, Network Rules. Create a new Network Rule from our internal subnet into the remote network to route, not NAT.
  4. Apply this, and then head to the Firewall Policy and created a couple of rules to allow the traffic we wanted the remote subnet and the internal to send and receive. Apply again and you're done.

The Vigor then needs to be configured, to match the ISA server;

  1. Head to VPN and Remote Access > Remote Access Control, and enabled the IPSec VPN Service (this is what had caught me out - some how I'd managed to miss this completely!).
  2. Under IPSec General Setup, untick Medium (AH), tick all the items next to High (ESP).
  3. Next go to VPN and Remote Access > LAN to LAN. Select the first free profile (probably 1) and set it up as follows:
    • Common Settings Set the Profile Name to anything you like, its just a name - I used the same name that I gave the network in ISA. Tick "Enable this profile" and select both for Call Direction.
    • Dial-Out Settings Select IPSec tunnel, set the "Server IP/Host Name for VPN" to the external IP of your ISA server (or whatever you selected in your IPSec tunnel setup in ISA). Set the IKE Pre-Shared Key to the same as in ISA, or if you used a certificate set the Digital Signature. Under IPSec Security Method set "High (ESP) 3DES with Authentication". Click advanced to open a new window and check "Main mode", set IKE phase 1 proposal to 3DES_SHA1_G2, IKE phase 2 proposal to 3DES_SHA1/DES_MD5, IKE phase 1 key lifetime to 28800, IKE phase 2 key lifetime to 3600 and enable PFS and click ok.
    • TCP/IP Network Settings Set the WAN IP and the Remote Gateway IP to 0.0.0.0. Set the Remote Network IP to your internal subnet host address, and the Remote Network Mask to your internal subnet mask (by internal I mean the subnet protected by ISA). Disable RIP (unless you want to use it), and set the NAT operation to Private IP. We didn't need to set this as the default route, this is obviously your own design decision.

You should now be good to go, and your Vigor and ISA box will negotiate and encrypt all traffic that travels between the 2 subnets, as it should. To check on the Vigor you can head to connection management and check out whether or not the tunnel is currently up, and that it's encrypted.

There are various reasons for opting for an IPSec tunnel, however the major one is that it's one of the easier tunnels that can be created, and are secure. You could of course opt for a site-to-site PPTP, or L2TP/IPSec, VPN. However these come with their own complications and security issues.

If the Vigor 2800 is anything to go by, I'd say that the Draytek routers are a nice bit of kit which work well for SOHO deployments, although there are a number of things in the GUI which really started to cheese me off after a while. There's no denying that they're not as flexible as other solutions, but they're no where near as simple as other routers which you could use. I'm still not entirely convinced that they're the perfect solution, although Chris has fallen in love with them, but at the end of the day for this sort of job you're rarely going to be touching them once they're up and working, so the cost savings over an equivilent Cisco box may pay off at the end of the day.

Group policy "Restricted Groups"

Restricted Groups is a part of the GPO Computer configuration tree that I've not ever used until today, primarily because I'd never looked into what it does exactly, and partially because it has a misleading name (in my mind) and I assumed that it did something else.

What this feature allows you to do is configure member ship of groups within Active Directory or in the local groups of domain computers. It's also available in the local security policy (naturally), so you can also use it on a standalone machine (although I'd imagine that in this situation it would be rather less useful).

Why do I now consider this setting important? Because it allows you to setup a GPO for an OU to allow users to be a member of a given local group, such as the Remote Desktop Users, for instance. This first example is useful to me as I didn't want users to be a member of the AD Remote Desktop Users group and have RDP access all over the network by default. This allows me to add a group of users to the local RDU group, and now setup a Terminal Server entirely automatically once it's been added to the correct OU.

The second example is forcing membership to the local administrators group. This is useful in stopping fiddlers (who "require" local administrator rights on laptops) from removing Domain Admins, or other groups and users, from the local admin group. Whilst I've only ever been locked out of a user's laptop once because of this, I'd rather not go through that again.

Another benefit of using the setting is that it will automatically remove any local user accounts that should not be a member of the local admins group. I'm sure you can imagine why this is useful!

MS Windows Server 2008 & multiple RDP connections per user

At work it's sometimes useful to allow multiple connections to a server, from the same user account, so that we can get more done at once, or to help out each other.

By default on Windows 2008 server you can't do this. Simple fix: Start up gpedit.msc, go to Computer Configuration\Administrative Templates\Windows Components\Terminal Services\Terminal Server\Connections\, find "Restrict each user to a single session" and disable. If you're on a domain and want to apply it to multiple machines, you obviously need to make it a domain policy.

Bullshit back story applied, just for Chris!
P.S. I win.