Setting up RIS

With all checks completed, the time had come to begin setting up the Remote Installation Services (RIS) server. As a quick reminder, this has to be a system with a single network adaptor, the usual set of Windows services (Active Directory, DNS, and DHCP), a separate partition for the RIS folder tree, and at least 4GB of free hard disk space on that partition. I recall that Microsoft’s documentation also points out that your system needs to meet a minimum operating system specification, but if it doesn’t meet that you wouldn’t have been able to install the OS in the first place, so I’m not quite sure why it was mentioned at all.

As with anything in life, ‘basic minimum’ means exactly what it says, and since I prefer both belt and braces I tend to make sure that my systems are specified as far above the minimum as is affordable, practicable and sensible for the solution in mind. Most of my servers have to fulfil multiple roles anyway, so the absolute minimum specification is nearly always out of the question.

To install the Remote Installation Services onto your server, head for the Start button and select Control Panel | Add/Remove Programs | Add/Remove Windows Components. Scroll down the list that appears until you find Remote Installation Services, click on the check button and hit . Then, once the service has installed, you’ll need to restart the system.

The next thing you need to do is set up Remote Installation Services, which is done via a wizard, and you’ll find it lurking in the Administrative Tools folder. Locate the Remote Installation Services Setup applet and run it, and you’ll see that a small checklist appears reminding you of the things you need to have done before running this program – among these is the requirement for a shared folder where the client installation images are to be stored. Also, on running the wizard, you’ll be prompted initially for a folder where the installation images themselves can be stored, and you can accept the default, or create your own. Next up is a screen entitled Initial Settings that wants to know how you wish the server to respond when approached by client systems.

You can now choose whether or not the RIS server will respond to client systems as soon as the image is completed, or whether you want the server only to respond to pre-staged clients. This is a security matter that I covered here last month – make your choice (these settings can of course be changed later) and hit Next. The default is that the server won’t respond to any clients of any nature at all until setup is completed.

You’ll now be asked to specify the location of the installation files, or of a CD with the installation files, and after that you’ll be asked for a name for that files folder. You’ll then be prompted for a friendly description to enable users to see what it was they were getting. After that, the installation files will be copied to the remote installation folder and you’ll see a checklist getting ticked off as each element in the process passes successfully. You need to run this Setup wizard every time you want to add the installation files for a particular OS, as you can’t create the client images until the basic OS files have been stored in the folder tree on the server.

Once you’ve finished with the base files, you can begin the process of creating client images based on the system you’ve already set up. These can range from basic systems with just the OS, to ones that have been populated with selected applications as well. The client images can be created in a number of ways, as I described in some detail in last month’s column. In this example, I’m going to use the Remote Installation Preparation (RIPrep) wizard.
To find riprep.exe on the server system, do a quick search for a folder called REMINST, which holds the executable and other files. I found mine in the system32 folder, so I made a copy of it to a shared folder and accessed it via the Run command on the client system. Make sure you’ve already created a folder to hold the image you’re about to create before you run the wizard. Having done this, run riprep.exe from the server and the Remote Installation Preparation wizard will appear before you. Hit Next after the wizard loads and you’ll be prompted for the name of the server to which the installation image will be copied after creation – this should have been automatically filled in for you with the name of the server from which you’re running the RIPrep wizard, so just hit Next.

At this point, if you haven’t set up the server correctly the wizard will halt and display an error message. This could be to the effect that the server hasn’t been properly configured, or perhaps that you haven’t created a folder tree for the base OS installation files. If all is well, you’ll be prompted for a folder into which to install the client image file. You can choose one already created, or type in a new one and it will be created automatically for you.

The machine will then be checked for any problems, such as multiple profiles being present (this won’t stop the wizard, but you’ll get a warning about it), and you’ll be presented with a list of services that now have to be stopped. If these services can’t be stopped by the wizard itself, you’ll get another list showing you which services and/or applications you now need to stop manually. Finally, you reach the end of the wizard and you get an explanation of what’s about to follow.

In a nutshell, the workstation image will be created and the system will shut down. When it restarts, a mini-setup of Windows begins and runs, which involves a licence acceptance screen, another that shows you the system language and keyboard language (set correctly to the ones I’d installed on my system, as opposed to defaulting back to United States), and then you’re asked for your organisation name. Next, you need your licence key, a name for your computer and an administrator password. The time settings follow, and in common with the language settings, these were correctly set. Networking is next, and when I chose the custom installation option and went to TCP/IP, the original IP address and DNS server address had been retained. The domain name setting had, however, gone missing, so I typed that in, authenticated myself and all that remained was to restart the system as setup was now complete.

The system restarted and I was able to log it back onto the network as though nothing had happened. As an experiment, I’d left my anti-virus software (Sophos) in place when I created the image, and I noticed that this simply picked up where it had left off. Once setup has completed, you can then use the workstation to create other images if you wish, and to do that you simply need to run the RIPrep wizard again for each image you want to create.

How was it for me? Well I can’t really claim that the earth moved, but I did manage to achieve my objective, and that was certainly quite satisfying. Did I get it right from the beginning? I could lie and say that I did it all perfectly straight through, but in fact the reason I’m able to tell you about error messages is because they’re the ones I encountered on my way to creating the images. The first error I made was to try to create a client image before I’d run the Remote Installation Services Setup wizard on the server. That might sound stupid, but I was slightly misled by the documentation for the latter that said ‘Enter the location of the client images. This can either be the compact disc, or a shared folder that contains the installation files’. At that time I hadn’t realised that you needed to create a folder tree on the server with the base OS installation files – I’m sure it explains this thoroughly somewhere, but I’d managed to misread the statement and thought it referred to the image file I’d be creating on the client.
The second error I made was a direct relation to the first one, and once I’d run the Setup wizard on the server and installed the base OS files, RIPrep ran just fine on the client system. The ‘multiple profiles’ error then appeared because I’d logged into the client system with the network admin account as well as the local system admin account, so I wasn’t too worried about that once I realised why it was complaining. I’d hoped to screenshot the final part of the Client wizard, but was forced to shut down the Paint program I was using to store the screenshots because it was one of those running processes to which the Client Image wizard objected.

I must admit, I was initially unimpressed when a dialog popped up entitled ‘Error Log’ after all the files had copied to the server, but this turned out to be nothing more than a message saying that RIPrep had completed successfully and that client shutdown had started. I stared at this message for quite some time and it stared back at me – then, after a few minutes, I decided to be bold and click on the close button in the top-right corner of the message box (there were no other buttons) because nothing else seemed to be happening. At that point, the client system did indeed shut down, and I was done.

David Moss

Terminal services snap-in

Thanks to fellow RWC contributor Mark Newton for pointing out this next tip to me. If you locate a file called adminpak.msi in the system32 directory of your Server 2003 installation, and then run it on your XP Desktop, you’ll get a set of good administrative tools installed onto your XP machine (which is just as you’d expect, given its name). I’ve used this pack of tools endlessly, but for some reason there was one item in it that I continually overlooked, and that’s the Remote Desktops applet.

Now Remote Desktop – or Terminal Services as it used to be called – has its own client application built into Windows XP, so whenever I’ve needed to open a remote Desktop onto a server I’ve always used the client that’s already there in XP. However, while this works just fine for one server, it becomes a handful when you’re dealing with half-a-dozen or more servers – having all those windows spread across your Desktop is something of a mess. So when Mark mentioned to me on the phone one day in connection with this, ‘Jon, just click on the server name on the left and switch to the other server,’ I had to discover what he was talking about for myself, because my remote desktop had no such facility. Then he pointed me in the direction of the separate Remote Desktops applet that comes as part of the Adminpak, and sure enough it was the one tool that I’d never used.

Firing it up gave me a nice MMC (Microsoft Management Console) window and right-clicking on Remote Desktops allowed me to set up a pile of server definitions, which are then stored. Clicking back and forth on the server names then took me straight to each one’s Desktop, including logging in as appropriate if this had been configured properly. What more could I want? I’d reduced the clutter of about six open windows sprayed around my Desktop to a single manageable application that did exactly what I needed, with not a single extraneous feature or facility.

SSH

For other remote administration, I’ve been playing around with another tool that’s at the opposite extreme. Remote Desktop is fine if you need the full graphical experience, but it’s a bit mad if you’re then going to fire up a Command Prompt and do some keyboard bashing. That being the case, it felt like a good idea to consider alternative tools and strategies, rather than just trundle along with the conventional and convenient. So it was with that I found myself trying out a Secure SHell (SSH) system on my rack-mounted server in London.
SSH connects over port 23, so appropriate firewall provision needs to be made to let its traffic through. To set up SSH connections, you’ll need both a client and a server component, and I tried a number of server engines before I found one that I liked. Most of their problems centred around server-side authentication, which was either buggy, incomplete or just simply badly explained. However, I found the WAC Server (Windows Access Server) from Foxit Software suited me well, was easy to install and worked straight out of the box. I had to do almost no configuration and within seconds I’d connected to the server from a client.

There’s a huge amount of stuff you can do with SSH, from remote administration through to full port forwarding. For example, it provides a text-mode menu front-end that gives instant access to the list of services running so you can stop and start them, while forwarding lets you route connections over SSH to a remote server and then on to the outside world. It really is a most fabulously powerful set of functions to have.

What else do you get in the kit? Well it isn’t only a full Telnet server, SSH server and serial port server, but you get a free client that lets you run any text-based application on the server with a full colour display and mouse and keyboard support too. In addition, there’s support for client-side printing as well. The cost is just $99 for a server licence and there’s a free, fully featured trial version for you to have a play with. Go to www.foxitsoftware.com and give it a whirl.

Snitz Forums

I recently needed a simple, straightforward ASP-based forum software package to set up a private chat area for a group of like-minded car-nut friends of mine. It didn’t need to be flashy, and I really didn’t want to have a whole set of baubles cluttering up its user interface, so I settled on Snitz Forums, which is a freeware ASP-based forum engine. It’s neither big nor clever – in fact, by comparison with the latest gew-gaws from the competition, it looks positively basic. But it works, is reliable and takes up an insignificant amount of space on my server. So far, it’s had several thousand messages posted through it, and I guess it’s about time I got around to doing some visual customisation to get the colours better sorted.

But, like the other two packages I’ve mentioned this month, it does what I need and nothing more. I really didn’t want something with a whole heap of garbage that would need extra administration, overhead and hassle. Maybe in my old age I’m returning to the principle of simplicity, where the Command Prompt was all you really needed. And maybe I’ll soon be seen around town sporting beard, ponytail and some fine strappy sandals…

Jon Honeyball