Real World Computing

RiPrep images are created using a wizard and are made whenever you want an image of a fully setup workstation with all its installed applications, which will be placed on the RIS server as a single file system image. I'll be using this type of image to roll out installations to networked workstations, which I want to all have the same initial setup. RiPrep images are quite large, but they tend to install much faster than RiSetup images.

RiSetup images have their uses too, however. They don't exist as a single file image, but rather a tree structure, much the same as you'd find on an OS installation CD. The advantage of this type of setup is that you can add applications, drivers and so on manually to the installation folder tree on the RIS server and then create answer files to sort out what applications and drivers are to be installed on client systems that come a'calling. There's clearly a need for both these installation types and a test setup is the best environment in which to try this out, not least because of the security considerations required with RIS installations.

For example, PXE systems are inherently unable to prevent a server from performing an installation on them once connection has been established. This isn't quite the case in the other direction, as you can only get an RIS server to run an installation to clients that are already authenticated via NTLM. One way round the former issue is to pre-stage the client computers in Active Directory and then set the RIS server to respond only to installation requests from known clients. I think this makes the most sense, as otherwise any PXE-enabled system could theoretically demand an installation if it had bypassed logon security checks in some way.

A firewall would be another useful item to have in place, because PXE has no way of detecting spoofing, and so there'd be nothing to prevent rogue packets from being sent to the client as it receives the installation files from the RIS server. Certainly, as far as my RiPrep installations are concerned, I intend setting the Client Installation Wizard (CIW) to run under automatic setup; that way, I can just point the wizard to my pre-defined computer names in Active Directory. The idea of custom setups sounds great in some circumstances, but it seems to require you to leave the RIS server set to accept requests from non-pre-staged clients. I could get away with that in most of my environments, as I know there's no danger of rogue clients appearing, but I should imagine there'll be a number of system admins who will shudder at the prospect. Even though automatic setup can be designed to be exactly that, it's also possible to give it a slightly customisable setup edge by allowing advanced users to pick something other than the default settings when the CIW runs. An example might be to let the user choose the language for their installation.

The CIW, of course, starts with the good old logon screen, so username and password, along with domain name, will be required. Since all of this can be tightly linked to Group Policy, you can set the CIW so that it provides different setup types and options to different users. You might, for example, want to give help desk users the ability to pick the OS that's going to be installed from a list of those available, whereas you might equally want other users to have no choice whatsoever in this particular matter. More next month.

DAVID MOSS