Austin Maliszewski's Blog

At Payton, we use Ghost to help us administer all the client PCs in the building. Each family of PCs gets its own image (with some minor variations since certain departments require specialized software that can’t be easily managed using GPOs) which is deployed every few months from a central server with multicast.

In the past, we’ve always booted the PCs with Ghost Boot CDs which allowed them to connect to the GhostCast Session. We didn’t have good luck with Ghost Console working properly, so we always did it this way. (Though I really want to start using WDS). However, recently, we acquired 100 notebook PCs that don’t have optical drives. Obviously, this was a problem. We were either going to have to use a USB CD drive or a USB floppy and neither would have been pretty for imaging 100 PCs.

There are several ways of network booting for Ghost. I’m going to go over two ways. One is with all free or shareware software and the other, is the way we ended up doing it and that’s with 3Com Boot Services since Symantec Ghost 8 Corporate includes it. Let me say that that software is a piece of work. It has a UI dating from the Windows 3.11 days. However, it actually works, when you get around its quirkiness. (I picked the 3Com route because you can configure the PXE server to run in DHCP Proxy mode which was critical since we don’t have any control over the DHCP server.)

Instead of me going over everything with the free/shareware software way, let me just provide a link. His instructions are great and got me a working setup. (Just don’t use any of the included software, it’s a few years out of date). Link from Damian Jackson at Lilydale Heights College. Point of Interest: The only drive letter that the Ghost Boot Wizard is willing to work with for creating the floppy image is A:/. You might need to disable your system’s actual floppy drive if you’re not using real disks (or don’t have physical access to the server). That took me hours to figure out.

It’s also probably not worth me going over the 3Com Boot Services way since it comes with a perfectly good manual on the CD. However, there are a few things which are covered in the manual, but not inherently obvious if you don’t read the manual. The rest is straight forward and you probably won’t have to read the manual. This is the brief version of everything.

First off, you need to create a Network Boot Image using the Ghost Boot Wizard. You can probably figure this out. Make sure to use the PXE Network Driver. I made two images. One has no command line parameters (which I called Ghost Manual) and the other has the parameters “-ja=[sessionname] -sure” where [sessionname] is equal to the name we use for our GhostCasting sessions. This I called Ghost Automatic since it automatically connects to the session.

Now you need to prep 3Com Boot Services. On your Start Menu under 3Com Boot Services is the 3Com Boot Image Editor. Open that up and select “Create a PXE menu boot file”. Create your menu file. Here’s what mine looks like.

PXE Boot Menu in 3Com Boot Image Editor

When you’re done go ahead and save it. You can name it if you like or just leave it as “mba.pxe”. The next step is to edit the BOOTPTAB file. Which you can do by opening the appropriately named BOOTPTAB Editor. This whole BOOTPTAB thing is a little clunky. The default BOOTPTAB file has a couple of entries. Go ahead and nuke those. Now, go to Edit and Add Host. This is where it gets a little weird. This is how you fill it out:

Adding a new host into BOOTPTAB

Yes, those are really question marks. You can also specify a MAC address, but putting in all question marks serves as a wildcard to allow all clients. Hit “Ok.” Now your BOOTPTAB file should look like this:

Sample Configuration

Go ahead and save that. Now, you can launch the PXE Server and the TFTP Server. (Both must be running. You can make them services if you’d like.) When you first launch the PXE Server it will check to see if the PC you’re running it on is a DHCP server. If it’s not, it will ask you if you’d like it to be a DHCP Proxy. Tell it that you would. You’re all done on the server side.

Now, go to one of your client PCs and tell it to boot from LAN. If you did everything correctly, you’ll get a menu that looks something like this (depending on your configuration).

PXE Boot Menu

Happy Ghosting!

Conveniently ESXi includes a way to increase the size of a virtual hard disk. However, like everything else in ESXi it is neither easy to find nor easy to make work. To save you the effort, here’s how to do it. First, you need to delete any and all snapshots. It won’t work if you have any snapshots. (Don’t worry, deleting them just merges them into the flat disk and deletes the deltas. You won’t lose any information.)

If you have snapshots on the virtual drive you can tell ESXi to make the change. ESXi tells you it resized the disk but it never actually does it. (It doesn’t give an error message, it just doesn’t work). I’d recommend shutting down your VM just in case, though you’re supposed to be able to do it to a live VM the thought is a bit scary for me.

Go to your VM’s Getting Started page in Infrastructure Client and click on “Edit virtual machine settings”. On the left side, there’s an option that says “Hard Disk” and a number. Click that. That brings up this menu:

VMWare ESXi Properties Menu. VHD Settings

On the right, you’ll notice that you can adjust the disk capacity. You can make the drive larger (or smaller) as needed by adjusting the New Size tab. It’s not recommended that you mess with any of the other settings as changing them can confuse your operating system and prevent it from booting. That’s it. You’re done, now you just need to resize the partition so that your OS can make use of the new space.

(While it may seem like I’ve been bashing ESXi, it really is a great product. Once you get it running and figure out its quirks it’s one of the best virtualization solutions around. And it’s free. For what more can you ask?)

This weekend, I was browsing the web and I came across an interesting MSIT Whitepaper on using Terminal Services for remote access and new components of Windows Server 2008 Terminal Services. In TS2008, Microsoft developed really neat new features which make Terminal Services a viable solution for remote access. In fact, I think these new services make TS far more attractive than an ordinary VPN; it’s significantly more secure, too.

As part of Server 2008, Microsoft built new TS components. First, I want to start with TS Gateway. TS Gateway allows you to send RDP traffic over HTTPS. A TS Gateway server relays the RDP traffic to its destination inside the network. This is really neat; you don’t have to poke a billion holes in your firewall to have remote access to your computers nor do you need to establish a full VPN connection.

However, it gets better… There’s another component, TSRemoteApp which allows you to encapsulate applications in Terminal Services. That is, you can send an app without the background environment over TS. It appears as a window on the client computer without a second explorer interface, etc. In fact, it will match the client’s theme if you install the Desktop Experience plugin on the server. That’s incredibly cool because then you can have apps that people can access from home without having to wait for them to load over a VPN connection, which is generally pretty slow, given the speed of most people’s DSL. Even better is that you save bandwidth because TS uses less bandwidth than transferring whatever application.

This has some amazing security benefits. One, it takes the security of the client PC mostly out of the picture. You don’t really have to worry about an infected client because the scope of potential damage is significantly reduced; i.e., the infected client does not become part of the network through VPN, it’s avenues of infection are significantly limited. This also has majoer confidentiality benefits. If you have confidential information that you need protected, that stays on the server this way. Employees/volunteers can access the files from home, but you’re free to lock them to the terminal server. They no longer would be copied to someone’s home PC for editing, etc.

This can also integrate with some new rights management features of Active Directory. It also is fully integrated with AD DS. Users logon to the server using their AD username and password. Permissions are managed by AD and group policy, etc. It also integrates with AD CS and Rights Management.

It also will relay RDP traffic to properly configured workstations. That is, an end user could connect securely, through TS Gateway to the PC on his or her desk and work as if he or she were sitting at his or her desk. There’s no need to make a VPN connection, nor expose the network to potential viruses on the end user’s home PC, the user can work seamlessly with RemoteApp or RDPing into his or her desk PC.

To tie this all together, there’s another component, TS Web Access which provides access to all these resources in a nice, easy to use web interface. You logon to the ASP.NET app, that is TS WebAccess, with your AD username and password and you have access to all your RemoteApp apps, your desk PC, (server manager, if you’re an admin), etc.

All in all, I need a little more time to play with this before I try implementing it, but it definitely looks promising as a way of controlling access to enterprise resources but still allowing end users to work from home. Way to go Microsoft!

I recently discovered this program by Bartels Media, a German software company, called MaxiVista. Despite the name, this has nothing at all to do with Windows Vista. It’s actually a really neat multimonitor package that allows you to use old laptops/computers as a secondary, tertiary, etc., monitor for your main PC/Laptop.

I have this configured with two monitors connected to one of my main laptops (I have two main laptops, one that leaves the house with me and one that doesn’t.). Then I have MaxiVista setup using an older laptop as a third monitor. This gives me a total of three monitors of screen space.

Quite frankly, I’m impressed with this program. There’s no latency between the monitors. I wouldn’t show video over the third monitor, but, it might actually work. I even pulled iTunes over to the third display and coverplay ran, albeit a little blocky, but it ran. Take that, Remote Desktop. Right now, I’m typing this message with Firefox in the third monitor, so that’s working nicely. I thought having two monitors was nice, but having three is really incredible. When I build my new desktop, it will probably have three or four (depending on how far over budget I run) monitors on two dual head video cards with 1GB DDR3 VRAM each. I haven’t decided which ones yet, though.

I just had to share this really neat program. I forgot exactly where I read about it, otherwise I’d give credit. Link: http://www.maxivista.com

I finally got around to installing Vista on my Gateway CX2724. I made a pledge to wait until at least SP1 and since that’s here, I did it. I pulled a copy of Vista Business from MSDN, burned it to DVD, resized my XP Tablet PC partition with GPartEd on Knoppix and installed it. The installation process was pretty painless. Put in your product key, time zone, if you want it to automatically update, it installs everything, about 30 minutes later, you put in your new username and password and it’s done. It rebooted a final time. Loaded, and well, it’s pretty and seems to run pretty nicely, etc.

First thing I notice, the pen doesn’t work. Well, I knew that would happen. Connected it to my WiFi and went and downloaded the pen drivers from Gateway.com. (Well, I downloaded Firefox first.) I installed the drivers based on the HWID of the HID. Then I installed the Tablet Buttons drivers based on its HWID. And what do you know, I point the pen at the screen and the mouse moves. Well, it’s a good deal away from where it should be. I fiddled with Calibration which failed every time. I decided I should do Windows Update, so I go do that, and in my list of updates are drivers for the pen device. Well, it does its thing and an hour later, I’m prompted to reboot. It tells me that the updates for the pen device failed, which makes sense since I already had the newest drivers. Upon reboot, everything works perfectly.

This morning, I played with it a bit more. I tried out the Input Panel. Boy, the handwriting recognition is so much greater than XP TPE. It could make everything I threw at it. I wrote in cursive, manuscript, mixed it up (that is pseudocursive), neatly, messily, it could read it all. It even got my name. I had to wait until about 4 o’clock before I could download OneNote because MSDN was being updated. Loaded up OneNote and did some sample

The way OneNote’s handwriting recognition works is based on the OS it’s running on. It makes a hook to the host OS’s handwriting recognition API if it has one. It installs TPE’s if you’re running it on any version of XP besides TPE, and on Vista it uses the native API except on Home Basic which doesn’t have one. (This is to the best of my knowledge, not sure if 2007 still works that way). So, handwriting recognition worked nicely, again recognizing everything I threw at it.

The best part is it’s supposed to learn your handwriting and improve over time kind of like the way Speech to Test works now. Well, we’ll see.

Overall, I’m pretty happy with the way Vista and Tablet PCs work. In the near future I should be getting a new Tablet (HP tx2525nr) with Vista Ultimate which should be a pleasure to work with.

Another thing: If anyone has computer questions, shoot me an email. I fix/can help with PCs (XP, Vista), Macs (OS X), *nix boxes, networking, servers, and hardware problems. Oh yeah, I also do programming and web design.