Chapter 3 (excerpt) from Installing Windows 2000 of Mastering Windows 2000 Server, Sybex Inc., 1999
| • | RIS Overview |
| • | RIS Limitations |
| • | Steps to Making RIS Work |
| • | Getting Ready for RIS |
| • | Authorizing RIS in Active Directory |
| • | Installing RIS |
| • | Running RISETUP |
| • | Enabling RIS for Clients |
| • | Installing Windows 2000 Professional on a Workstation from the RIS Server |
| • | Creating a System Image with RIPRep |
| • | Reconfiguring the Prototype |
| • | Delivering a RIPRep Image to a Target PC |
| • | Enabling Users to Start RIS Transfers |
| • | Creating the installers group |
| • | Restricting RIS Image Choices |
Well, by now, you've probably tried shoving the CD-ROM into some computer's drive and installed Windows 2000. You may well have had some luck at it and found that after a bit of twiddling, you could make it work quite well. "Cool," you might have thought, "Installing Windows 2000 will be a snap."
But then, you probably realized that you'd have to do it for several hundred machines. Let's see now, doing the exact same set of twiddling several hundred times would takewell, more patience and time than many of us have. It would be nice to be able to spend a fair amount of time on just one computer, getting it just right, and then to "xerox" that configuration onto dozens or hundreds of other computers.
And for years, many of us did just that. Back when I worked in training labs teaching Windows 3 running atop DOS 5, it was a simple matter to just boot up a workstation with a floppy containing the Novell client software, format the workstation's C: drive, and then XCOPY an entire drive image from a Novell shared volume onto the workstation. The whole process was completely automated once I got it started and took no more than about 20 minutes.
Later on, with the advent of bigger operating systems like Windows 95, drive copier programs like Ghost and Drive Image Pro came out. These drive copiers didn't care what files were on a computer; they'd just copy a physical hard disk or partitions from that hard disk to a network folder for you. Then you could set up a new computer to look just like the prototypic computer by booting the new computer from floppy and then pulling down the Ghost or Ghost-like (would that be "Ghostly"?) image.
That worked fine for Windows, but not for NT, as NT's secure and so each computer with NT installed on it has long and machine-specific strings of numbers embedded in it, numbers called Security IDs or SIDs. Cloning one machine's NT image onto thousands of machines would lead to thousands of machines with identical SIDs. While that might not sound terrible, it could have some very bizarre side effects.
For example, suppose you start up a new PC with a cloned copy of NT Workstation/Windows 2000 Professional on it, logging in the first time as the default administrator. The first order of business is then to create a local user account for yourself. But inside NT, that account would get an SID. As this is the first account created besides the built-in Administrator and Guest accounts, that account's SID will be the first available in the range of SIDs on this machine.
Now imagine that Janice down the hall, who has a machine containing the exact same cloned image on her system, also logs onto her new machine as its default administrator and creates herself an account. It'll have a different name than your accountbut that won't matter. NT doesn't really care what your name is; it cares what your SID is. And what value SID does Janice have? Well, as it's the first created account, you guessed ither account now has the same SID as yours.
What does that mean? Well, suppose you made your local account an Administrator account. That means that when she's logged on to her own machine with her own account, she can use Windows 2000's remote control tools to do administrator-like things to your system over the network. That's not a good thing, unless you and Janice are really good buddies.
As a result, disk cloning vendors have come up with "SID scrambler" programs. You copy the cloned image onto a new machine and then run the SID scrambler. It creates a unique set of SIDs on the newly cloned machine and all should be well. Microsoft, however, says that the SID scramblers from the two big players, Symantec's Ghost and PowerQuest's Drive Image Pro, won't do the whole job. I honestly don't know if this true or if it's just Microsoftwellbeing Microsoft. In any case, now Microsoft's got a method for rolling out a single workstation image to dozens, hundreds, or thousands of machines while simultaneously ensuring that each machine has unique SIDs. It's a service called the Remote Installation Services, or RIS. In this section, you'll learn how to set it up and how to get those images out to all of those PCs hungering for an operating system.
RIS lets you designate a server or a set of servers as RIS servers. A RIS server contains the files necessary to install Windows 2000 ProfessionalRIS only helps you distribute the workstation software, not server software, onto a computer from across the network. RIS can deliver an operating system to a waiting PC in one of three formats:
Simple I386-based installation In this simplest form, RIS is just a place to store the Windows 2000 Professional installation files. How's it different than just putting I386 onto a directory on any old file server and then sharing that directory? Not very much except in one way: you can go to the PC that you intend to put Windows 2000 Professional on and boot it with just one floppy and you'll be off and running, no messing around with the DOS Client for Networks or the like. Of course, once this installation starts up, you've got to sit at the computer and answer all of Setup's questions, baby-sitting the computer while Setup runs.
Scripted I386 install This installation is like the preceding situation, with the added benefit of unattended installation. You just go out to the target PC, boot the floppy, and away it goes. These first two options are called CD image format images.
Complete system image with minimal setup interaction This option is really the more interesting. In this situation, you build an entire prototypical machine, complete with applications, then use RIS to create an image of that machine on a RIS server. You then boot the target PC with a RIS-built floppy again, and RIS transfers the entire disk image, complete with operating system and applications, to the target PC. It's not entirely hands-off, however, as it needs a bit of machine-specific customization: you need to punch in a unique machine name, for example. This kind of image is called a RIPRep image format image.
Before getting too excited about RISit's nice, but the Ghost guys needn't worry about being put out of businesslet's look at what it can't do.
You can't use RIS to deliver Server images, NT 4, Windows 9x, Linuxonly Windows 2000 Professional images. Currently, it's only a Windows 2000 Professional deployment tool.
RIS Clients Must Have Particular PCI Network Cards, Laptops Need Not Apply
I'll cover this later, but you can only get a RIS system image onto a computer that knows how to ask for one, and the only way that a system knows how to ask is if you boot that system with a floppy generated by the Remote Boot Floppy Generator, a program supplied with RIS. The problem is that the resulting floppy just contains drivers for 25 PCI-based network cards. As it only supports PCI cards, laptopswhich in general use PC Card or Cardbus network cardscan't be helped by RIS. So you're back to Ghosting for the mobile users.
RIS Can Only Image the C: Drive
When you build a prototypic computer whose image you will then propagate all over the enterprise, you'd better build a computer with just one hard disk partition C:. RIS will merely copy the C: drive and whatever's on it.
RIS Has a Fairly Sparse Administrative UI
While RIS doesn't require a lot of administration, there are few tasks that you'll do frequently, and RIS doesn't provide a very good way to do them. For example, if you had a RIS server that contained many system images, but you didn't want every user to see every possible image (which is very likelyodds are that you'd have one image for the accounting folks, another for the programmers, and so on), then the only way to restrict the choice of images that a user sees is through NTFS permissions rather than via some simple administrative interface.
The first time you set up a RIS server, it can seem a bit complicated if you're not ready for it, as RIS is a bit different from other Windows 2000 services. What I'm referring to is that to install most Windows 2000 network services, like IIS or WINS, you just install them on a server, reboot the server, and you're done. Setting up RIS on a server, however, requires fiddling a bit with Active Directory.
Tip Before you can use RIS, you must have a Windows 2000based domain running with an Active Directory domain controller. You also need a functioning DNS server integrated with the Windows 2000 domainthat is, a DNS server that supports RFC 2052 SRV records and RFC 2136 dynamic updates, as described in Chapter 2.
To get a RIS server working, follow these steps:
1. | Set up a Windows 2000 server and make it a member of a Windows 2000 domain. The server must have a fairly large drive available, and that drive can't be the boot drive or the drive containing the operating system. |
2. | Authorize the soon-to-be-RIS server in the Active Directory as a Dynamic Host Configuration Protocol (DHCP) server, even though it's not a DHCP server. |
3. | Add the Remote Installation Services service to the server and reboot it. |
4. | Run RISETUP, the Remote Installation Setup Wizard, to prepare the large drive for receiving RIS images and to put an initial image on the driveit's just a simple copy of I386. |
5. | At that point the RIS server is ready. You can add new images to it with a wizard called RIPRep. |
We'll examine each of these steps in the following pages.
RIS's job is to let you take a PC with an empty hard disk, attach the PC to your enterprise network, put a RIS-created floppy disk into the PC's A: drive, and boot the PC. The small program on the floppy disk is just smart enough to get an IP address for the PC, then locate an Active Directory domain controller, and ask the Active Directory domain controller where to find a RIS server. Once the PC finds the RIS server, it can then start the process of pulling down a particular system image so that the PC becomes useful.
But Windows 2000 needs some infrastructure to make all of this work right. The PC gets an IP address from a DHCP serverso you'll need at least one DHCP server running in your enterprise to make RIS work. (In case you've never worked with an IP-based NT network before, DHCP's job is to automatically assign unique network addresses to each server and workstation on the network. TCP/IP requires that every machine have a unique IP address or the network software just doesn't work.) Once it has an IP address, the PC finds an Active Directory server by looking it up in DNSso you'll need a DNS server. And the PC can't query an Active Directory domain controller for the location of a RIS server unless you've got an Active Directory domain controllerso you'll need an Active Directorybased domain (as opposed to a bunch of Windows 2000 servers in a domain built out of NT 4 domain controllers). Of course, if you're running an Active Directorybased domain, then you've got to have DNS running, so the simplified list of things you'll need before RIS will work is an Active Directorybased domain and at least one DHCP server.
A Drive for SIS
Furthermore, the RIS server needs a partition to store the RIS images. For some reason, RIS will not store images on the boot partitionwhich is usually drive C:or the system partition, which is the drive that contains \WINNT and the other NT system files. I found this kind of frustrating the first time I went to set up RIS, as the server that I intended to put RIS on had only two drive letters and Windows 2000 installed on the D: drive. C: was the boot, D: the system, and so RIS wouldn't install. I reinstalled Windows 2000 on the C: drive, freeing up D:, and RIS worked fine. You can have other things on RIS's drive, like files of other types, you just can't have the system files on the drive. Remember that, while RIS will make an image of whatever file system is on the original workstation, it must be placed onto an NTFS partition on the server.
While it's not entirely clear to me why RIS is allergic to system files, there's a very good reason why it wants a drive pretty much to itself. Imagine a RIS server that contained 20 system imageshow much space would that need? Well, Windows 2000 Professional itself takes up about 450MB on a hard disk, so let's be generous and say that the applications added to the image only total 50MB, leading to a 500MB image; it's just easier to calculate this way. Ten half-gigabyte images totals five gigabytes. But now let's look more closely at those 10 images. The vast majority of the files in the images are identical: for example, each image contains a file named DRIVERS.CAB that's nearly 50MB in size, and the file is exactly the same for each of the 10 images. That's a terrible waste of space500MB to store 10 identical copies of a 50MB file!
RIS solves that problem with a service called the Single Instance Store, or SIS. SIS is a service that runs in the background and searches a particular drive letterfor some reason, it's only built to attach itself to a single drive letter rather than system-widelooking for duplicate files. It then frees up space by deleting the duplicate files, putting in their place a directory entry that makes it appear as if the duplicate is still in place. In actuality, however, the duplicate is no more than a sort of pointer to the complete copy of the file. Clearly a trick like this will require a bit of magic, and that magic comes from a combination of SIS and Windows 2000's version of NTFSthat dedicated-to-RIS drive must be an NTFS volume.
It's a shame that SIS only loads as part of RIS; I could easily imagine many cases wherein recovering space from duplicate files could be beneficial, such as in the case of a server containing hundreds of users' home directoriesthere's likely to be plenty of duplication there.
Microsoft figuredprobably rightlythat you wouldn't want just anybody putting a RIS server on the network. So before you can get the RIS service working on a server, that server must be authorized in the Active Directory. For some reason, however, you don't authorize it as a RIS server; you authorize it as a DHCP server.
To do that, find a DHCP server and log onto it with an account with administrative powers. Click Start/Programs/Administrative Tools/DHCP. Click Action on the menu bar, and you'll see the option Manage Authorized Servers, which is shown in Figure 3.15.
Choose Manage Authorized Servers and you'll see the list of currently authorized DHCP servers like the one in Figure 3.16.
Click Authorize and you'll get a dialog box like the one in Figure 3.17, letting you punch in the IP address of the server that you're going to make into a RIS server.
Click OK, and it'll confirm your choice, as Figure 3.18 shows.
Note: If you don't know the IP address of the soon-to-be RIS server, go over to that server and log in to it. Then open up a command prompt (Start/Programs/Command Prompt), type ipconfig, and press Enter. It will report the IP address; if you have several IP addresses, take the one in the section labeled Ethernet Adapter Local Area Connection rather than PPP Adapter.
Now that Active Directory's ready for RIS, let's get RIS ready.
Next, you'll put the RIS service on the server:
1. | Log on to the server that you want to add RIS to using an Administrator account and open up the Control Panel (Start/Settings/Control Panel). |
2. | Start the Add/Remove Programs applet. |
3. | Choose the Add/Remove Windows Components icon. |
4. | A wizard screen labeled Welcome to the Windows Components Wizard will appear; click Next and it will show you the optional server components, as you see in Figure 3.19. |
5. | Scroll down and check the box labeled Remote Installation Services. Then click Next and Finish. |
6. | You'll be prompted to reboot, so reboot the server. |
When installing most Windows 2000 services, you just choose the option in Windows Components, wait for the Control Panel to pull the new service off I386, reboot the computer, and it's up and running. RIS is a bit more work than that, however, as RIS must claim its drive and set up SIS. For good measure, RIS also creates a first image. That first image is the simplest one possibleit's just a copy of the I386 directory from the Windows 2000 Professional CD-ROM.
Log on to the would-be RIS server with an administrative account and run RISETUP (either from a command prompt or click Start/Run, fill in risetup, and press Enter) and the Remote Installation Services Setup Wizard starts. The initial screen is shown in Figure 3.20.
Click Next and the wizard will quickly scan your drives looking for a likely place to keep RIS's files. In my case, it found drive F:. It wants to create a directory named RemoteInstall, as you can see in Figure 3.21.
After you click Next, RISetup will ask you if you want the server to respond to requests from PCs for operating systems, as shown in Figure 3.22. Inasmuch as you don't have any useful images on the RIS server at the moment, tell the server not to respond to those requests.
Click Next and, as you can see in Figure 3.23, RIS will ask where to find a Windows 2000 Professional CD-ROM.
Now's a good time to pop the Windows 2000 Professional disc into your CD-ROM drivemore than likely you've currently got the Windows 2000 Server disc in there from when you installed RIS. RISetup usually isn't bright enough to know that the files are in I386, so it'll typically just suggest the drive letter of your CD-ROM. For example, if your CD-ROM drive is G:, it'll suggest that the Windows 2000 Professional files are at G: rather than G:\I386, so you'll probably have to help it out and tell it where to find the files. Alternatively, if you have Windows 2000 Professional's I386 directory on one of your hard disks, you can point RISetup there. Click Next and you'll get the screen you see in Figure 3.24.
Recall that a RIS server can have many images on it. Each image gets a folder within the \RemoteInstall folder. This first, simple I386 image needs a name too, and RISetup suggests just win2000.pro, which is probably fine for our needs. Click Next to continue and you'll see a screen in which you can describe the image, as shown in Figure 3.25.
When someone plugs a new machine into the network and boots from the RIS-prepared boot floppy, she may be offered a number of choices of OS images to download. (After all, one of the things that RIS is supposed to offer is the ability to keep a bunch of images around for different uses.) This screen lets you add some descriptive text. Click Next and you'll get a summary "this-is-your-last-chance" screen like the one in Figure 3.26.
Click Finish and go away for a while. A screen like Figure 3.27 will appear.
As you see from the screen, RISetup's got a lot to do. It copies the I386 files over to its local folder, starts SIS, and does other housekeeping. Expect it to take 10 minutes or so at least.
Amazingly, after RISetup does its work, the RIS server does not reboot! But it's time to put the RIS server to work, or at least to respond to requests for I386 installs. Make sure you are logged in as a domain administrator at the RIS server, then click Start/Run, fill in DSA.MSC, and press Enter. If the RIS server happens to be a domain controller, then it's even easierjust click Start/Programs/Administrative Tools/Active Directory Users And Computers. (Notice that you've got to start the DSA from Start/Run because for some reason Setup installs the Active Directory tools on all servers, but only puts entries for those tools on the Start/Programs menus of domain controllers.)
In the left-hand pane of the window, you'll see an icon depicting a number of computers, intended to represent your domain. Open it (double-click or click the plus sign) and it'll open to a number of folders, including one named Computers. It's likely that your RIS server is there. Right-click the RIS computer's icon and choose Properties. You'll then see a property page.
My RIS server is named D (it came after A, B, and Cand yes, some days I'm just not as creative as I would like to be), and there are several property tabs, one labeled Remote Install. Click on that and you'll see a page like the one in Figure 3.28.
There's not much in the way of an administrative and management interface for RIS, just this page and a few tabs on the Advanced screen, which you'll see a bit later.
On this screen, there's not all that much to do except to turn it on. Check Respond to Client Computers Requesting Service, and it's ready to go!
It's working; let's give it a try. The RIS server is up on the network and the Active Directory knows about it. Suppose I have a computer that I want to put Windows 2000 Professional on (call it the target computer); these are the steps.
The target computer gets the attention of the RIS server through something called the Preboot eXEcution, or PXE, protocol, pronounced "pixie." (Is that acronym a reach, or what?) Some computer vendors sell PCs with PXE in the BIOS. To connect a PXE-equipped PC to a RIS server, you don't even need a floppy disk; you just plug it into the network, turn it on, and you'll eventually get a prompt like "boot from the network y/n?" If you let it boot from the network, it'll first seek out a DHCP server, then find an Active Directory server with DNS, and kick off RISall the code for doing that is in the PC's BIOS ROM.
Those of us less fortunate, however, are not let out of the fun. Microsoft includes a utility with RIS that will generate bootable floppy disks that replace the PXE BIOS for the PXE-deaf among us. It's called RBFG.EXE, and you'll find it on any RIS server in the \RemoteInstall\Admin\I386 directory. Run it and you'll see a screen like Figure 3.29.
Running it is pretty simplejust put a floppy into A: and press the Create Disk button. A great improvement over its older cousin, the Network Client Administrator, the Remote Boot Disk Generator doesn't require that you provide it with blank floppies. That's the good news.
The bad news is that this will only work if your computer has PCI expansion slots and one of the 25 supported PCI network cards. Fifteen years' experience with network software has made me conservative enough that almost all of my NICs are made by 3Comnot because I think 3Com makes a better card, but because I don't want to have to search after driversand so RBFG supports all of my machines. But that might not be the case for all of your systems.
Actually, let me take that back. Not all of my systems will work with an RBFG floppymy laptops won't. Laptops don't have PCI slots in them (unless they're in some kind of docking station), so if your laptop connects to a network with a PC Card or CardBus slot (as 99.9 percent of them do), then you won't be able to use RIS to get Professional on your system, sadly.
But what about the fact that new network cards appear all of the time? It's not unreasonable at all to suggest that a year after Windows 2000's release you might find yourself trying to install Professional on a system with a brand-spanking-new network card that RBFG simply doesn't know how to handle. How do you introduce RBFG to a new set of drivers? I've heard that regular updates of RBFG.EXE are to be distributed over the Web by Microsoft.
In any case, if you generate a PXE boot disk, stick it into the target machine and boot the machine. You'll see a screen with something like the following text:
Windows 2000 Remote Installation Boot Floppy
Copyright 1999 Lanworks Technologies Co. a subsidiary of 3Com Corporation
All rights reserved.
3Com 3C90XB / 3C90XC EtherLink PC
Node: 00105AE2859F
DHCP...
TFTP..
Press F12 for network service boot
Press F12, and a text screen appears that says:
Welcome to the Client Installation wizard. This wizard helps you quickly
and easily set up a new operating system on your computer. You
can also use this wizard to keep your computer up-to-date and to
troubleshoot computer hardware problems.
In the wizard, you are asked to use a valid user name, password, and
domain name to log on to the network. If you do not have this
information, contact your network administrator before continuing.
Press Enter to continue
You are looking here at some client software downloaded from the RIS server called the Client Install Wizard. Look back to the first screen and notice the TFTP with all the periods after itthat was the Trivial File Transfer Protocol transferring a very simple text-based operating system to your computer.
What's kind of interesting about this is that the introductory screen, and all of the other text screens that you'll see from the Client Install Wizard, are built on a slightly modified version of HTML. You can see the "source code" for that first screen by looking on the RIS server in \RemoteInstall\OSChooser\English directory and examining the file named welcome.osc. It looks like the following:
<OSCML>
<META KEY=ENTER HREF="LOGIN">
<META KEY=F3 ACTION="REBOOT">
<META KEY=ESC HREF="LOGIN">
<META KEY=F1 HREF="LOGIN">
<TITLE> Client Installation Wizard Welcome</TITLE>
<FOOTER> [ENTER] continue </FOOTER>
<BODY left=5 right=75>
<BR>
<BR>
<BR>
Welcome to the Client Installation wizard. This wizard
helps you quickly and easily set up a new operating system
on your computer. You can also use this wizard to keep your
computer up-to-date and to troubleshoot computer hardware
problems.
<BR>
<BR>
In the wizard, you are asked to use a valid user name,
password, and domain name to log on to the network. If you
do not have this information, contact your network
administrator before continuing.
</BODY>
</OSCML>
If you've got any familiarity with HTML, then understanding this is simplethings surrounded by angle brackets <> are tags, commands to the computer. They're often in pairs like right and left parentheses<oscml> starts the "program," </oscml> ends it. That forward slash ( / ) indicates that it's the end of a commandfor example, <TITLE>Client Installation Wizard</TITLE> indicates that there's a command, <TITLE> (which, as you can guess, puts a title in the screen), then there's the text that's supposed to go into the title, and then </TITLE>, which says, "That's the end of the title text." Again, they're like left and right parentheses. The <META KEY> commands tell the wizard what to do when you press particular keys. <META KEY=ENTER HREF="LOGIN"> means, "When the user presses the Enter key, run the program login.osc." <META KEY=F3 ACTION="REBOOT"> means that if the user presses the F3 key, then just reboot the system.
My intent here isn't to document the entire programming languageMicrosoft hasn't completely documented it yet, to my knowledgebut to point out that you could easily change the generic welcome text to something customized to your particular company.
Anyway, once you press Enter, you're prompted for a username, password, and domain. The account that you log in with must have the ability to create new computer accounts. You'll next be advised that the process will delete any data on the existing hard disk:
The following settings will be applied to this computer installation.
Verify these settings before continuing.
Computer account: ADMINMARK1
Global Unique ID: 0000000000000000000000105AE2859F
Server supporting this computer: D
To begin Setup, press Enter. If you are using the Remote
Installation Services boot floppy, remove the floppy diskette from the drive and press Enter to continue.
Here, the RIS client software has chosen a name for the computer, ADMINMARK1, that it constructed by taking my login nameADMINMARK was the account I used at the timeand adding a number to it. The Global Unique ID, or GUID (pronounced "gwid") is just an ID number that RIS assigned to that computer. PXE-capable machines all have a GUID built right into them, but machines using RIS boot floppies get a GUID constructed for them consisting of 20 hex zeros followed by their NIC's MAC address. Finally, the Client Install Wizard tells you the name of the RIS server that it's getting its image from. Once you press Enter to confirm, pop the floppy out of the A: drive and walk away for a half hour or so. When you return, Windows 2000 Professional will be installed completely hands-off on the machine.
RIS sets the system up like so:
| • | The new machine joins the RIS server's domain. |
| • | RIS repartitions the machine's hard disk into just one large partition and formats that partition as NTFS, no matter how the drive was previously partitioned. |
| • | The new Windows 2000 Professional system has all of the settings you'd find in a typical install. |
Want to change any of that? Then you'll need to create some system images.
Even doing a no-frills installation on a new system with RIS is pretty nice. But it would be nicer to provide not only a vanilla operating system but perhaps a few settings and certainly an application or two. You can do such a thing, creating what's called a RIPRep image format image. Here's how you do it:
1. | Set up a prototypical Windows 2000 Professional system as you'd like it. Make sure that all of the code and data are on drive C:no other drives will be copied by RIS. |
2. | Run the RIS preparation wizard, RIPRep, which strips the SIDs off the prototypical machine. |
3. | Once the image is on the RIS server, it's available to new systems for installation. |
For my example, I've installed Office 2000 onto a Windows 2000 Professional workstation. To create the RIPRep image, I log onto that prototypical machine with a domain administrator account. I then open up My Network Places and navigate over to my RIS server, the machine named D. RIS creates a share called REMINST on every RIS server. I open REMINST, then I open up the folder inside labeled Admin, and then I open the folder inside that labeled I386. Inside is a file named riprep.exe. I double-click on it and see the opening screen, as shown in Figure 3.30.
Click Next to see the screen shown in Figure 3.31.
You can send the resulting image to any RIS server; I'll choose the one I've been working with, the server named D, and click Next, which leads to the screen in Figure 3.32.
As with the CD image that RISetup insisted upon, this new image will need a folder name. Once I name the folder and click Next, a screen in which I add a description appears, as shown in Figure 3.33.
Finally, in the next two screens (Figures 3.34 and 3.35), I confirm that I want RIPRep to actually do the work.
After transferring the system image to the RIS server, you're directed to reboot the prototype. You'll then see something oddit looks as if the prototype is running Windows 2000 Setup all over again! In order to make the prototype's image usable to RIS, RIPRep scrubs all of the user-specific settings and SIDs off the machine. Once you reboot, your system runs a kind of "mini-setup" to restore that information. Once the system reboots, you'll be prompted to do the following:
| • | Agree to the license agreement. |
| • | Choose a keyboard and localization. |
| • | Fill in a username and organization. |
| • | Specify a computer name and password for the default Administrator account. |
| • | Pick a time zone. |
| • | Decide whether to do typical or custom network settings. |
| • | Join either a workgroup or domain. |
The mini-setup doesn't take nearly as long as Setup did, however, as it's not necessary to run Plug and Play.
Now how do you deliver that operating-system-with-applications image to a target PC? In exactly the same way that you got the first one onto a target PC. Either press F12 when the PXE ROM tells you to or boot from an RBFG-generated floppy.
Note: You do not need to build a separate RBFG-generated floppy for each system. You can build just one and carry it with you, using it to start as many different RIS image transfers as you'd like.
Now that you've got more than one image on your server, the Client Installation Wizard will offer you one more screen. After you log in, it'll list the available images and their descriptions, allowing you to choose one. Then, as before, it'll remind you that it's about to destroy any data on the hard disk and, from there, all you need do is to pop that RBFG floppy out of the floppy drive, walk away, and come back in a half hourthe entire install is hands-off.
Warning: I find with beta 3 that the Setup Wizard runs hands-off for a while, but then it requires me to click Next at the Localization screen.
Warning: Once again, don't take the "this will zap the hard disk" warning lightly. If (for example) your RIPRep image is based on a system with a 1500MB C: drive formatted as FAT32, then RIS will repartition and reformat the C: drive of the target PC to 1500MB and FAT32 no matter how the drive was partitioned on the target PC before. RIS will leave any remaining space unpartitioned.
The idea, then, with RIS is this: Joe comes into your office and tells you that his computer's hosed and would you reinstall his operating systems and applications when you get a chance? You reply that you've got an even better idea and hand him an RBFG floppy. You tell him to boot it, press F12 when prompted, then log into the Client Installation Wizard and choose the Standard Productivity Desktop option, an image that you've built with all of the company's standard desktop softwareOffice, the PalmPilot HotSync software, and Lotus Organizer.
Now, if Joe goes back and tries this, he'll see an error message like this:
The user Joe currently logged on to this computer does not have the permissions needed to create a computer account or modify the computer account NEWPC (NEWPC$) within the domain apex.com.
This error may also indicate that the server D supporting this client cannot contact the directory service to perform the operation.
Restart this computer and try again. If the problem persists, contact your network administrator for assistance.
What's going on here is that, in the process of installing the RIS image on Joe's machine, RIS must also create a machine accountremember, in Windows 2000 domains, machines have accounts just as people doand not just any old user can create machine accounts. By the way, he's also got to be able to delete machine accounts, as there's probably already a machine account floating around that has the same name as the one he's about to create, as well as a few other machine permissions.
You could make him a member of the Account Operators group for just a day so that he could do the install, but that's an awful lot of power to give a user just so he can kick off a RIS image transfer. So instead, let's create an altogether new group called Installers, which will have the power to create and delete machine accounts but nothing else. Now, creating the Installers group will be a bit of a lengthy procedure, but you'll only have to do it once. Once you've got the Installers group defined, you can then just simply add any user to that group before giving him an RBFG floppy to reinstall his system. (And for safety's sake, you can remove him the next day, after he's got his system back up and running.)
You'll find creating the Installers group easiest while sitting at a domain controller:
1. | Log in using an account with domain administrator rights and then start the Directory Service Administrator DSA.MSC by clicking Start/Programs/Administrative Tools/Active Directory Users and Computers. In the left-hand pane, you'll see an icon representing your domain with a plus sign next to it; click the plus sign to expand the domain. |
2. | Next, create the Installers group. Right-click on the Users folder and choose New/Group. |
3. | That raises a dialog box called Create New Object-(Group). In the field Name of New Group, fill in Installers. This will create a global group named Installers, which is what we want, so click OK and the dialog will close. |
4. | Back in the DSA's menu, click View/Advanced Features. That will show the Security tab on the property page, which will be essential to give Installers the permissions that it needs. |
5. | Next, we're going to give some domain-wide permissions to the Installers group, so right-click the domain's icon and choose Properties. You'll get a dialog box named Domain Name Properties. |
6. | Click the Security tab in the property page. Installers doesn't currently have any permissions, so we'll need to add a record for them. Click the Add button and you'll now see a dialog named Select Users, Computers or Groups. |
7. | Click the Installers group, click Add, and then click OK to dismiss the dialog box. |
8. | Back in the Domain Name property page, find Installers in the Name list box and click it, then click the Advanced button. |
9. | You'll see a dialog box labeled Access Control Settings for Domain Name. Again, locate Installersthis part of the operating system isn't intended for regular old users, so the UI's a bit convoluted hereto indicate the Installers record that you created. It'll currently have some very basic permission like Read or the like. Click the View/Edit button. |
10. | Now you'll see a dialog named Permission Entry for Domain Name. Scroll down in the list box labeled Permissions to find the Create Computer Objects permission. You'll see two columns of check boxes, one labeled Allow and the other Deny. Check the Allow box and do the same for the next permission, Delete Computer Objects. In the list box labeled Apply To, choose This Object and All Child Objects. What you're doing here is giving Installers the right to create and destroy new objects in the directory, but only computer objectsmachine accounts. Click OK to clear the Permission Entry for Domain Name dialog box. |
11. | That permission made the folders accept the new machine objects. But once created, Installers have no control over the machine accounts themselves, so we'll add another permission record to give Installers complete control over machine accounts. From the Access Control Settings for Domain Name dialog box, click Add, choose Installers, and click OK. The Permission Entry for Domain Name dialog box then appears. |
12. | Click the Apply Onto drop-down list box and choose Computer Objects. Check the Allow box next to the Full Control permission. Click OK and Windows 2000 will return you to the Access Control Settings for Domain Name dialog box. |
13. | Scroll down in the Permission Entries list box and you'll see that there is now a new entry for Installers, a "create/delete" permissionthat's what you just createdas well as a "full control" record for "machine objects." |
14. | Click OK to dismiss the Access Control Settings For dialog box. |
15. | Click OK to dismiss the Domain Name property page. |
Now that that's done, you can put Joe into the Installers group:
1. | Open the Users folder and locate the Installers group. |
2. | Right-click Installers and choose Properties. |
3. | Click the Members tab. |
4. | Click the Add button. |
5. | Find Joe's account, click Joe, click OK, and then click OK again. |
Once you turn Joe loose with that floppy, you just might not want him accidentally loading the wrong image. He might just decide that he'd love to download the Programmer's Workstation image, complete with the C++ and Java compilers, interactive debuggers, and the likenone of which he has any use for. You can, as it turns out, keep him from seeing all of the images on the RIS server. But you'd never guess how you do it.
The RIS server has a set of directories that exist in \RemoteInstall\Setup\English\ Images\. If you've got a simple I386 installation called win2000.pro, then its image is in \RemoteInstall\Setup\English\Images\Win2000.Pro. Each RIS image, then, has a directory inside \RemoteInstall\Setup\English\Images\; remember that.
Each image contains a folder named I386, which contains yet another folder named Templates. That folder contains a file named with the extension .SIF. It's an answer file that RIS uses to be able to do the installation without any user intervention. So, for example, if you have an image called Programmers, there's an SIF file in \RemoteInstall\ Setup\English\Images\I386\Templates.
The way that you keep Joe out of the Programmers image is to set the NTFS permissions on the SIF file so that he's denied Read access. Once RIS sees that he's not supposed to see the file, the Programmers image won't even be offered to him.
About the Author
Mark Minasi, MCSE, is recognized as one of the world's best explainers of Windows NT. He teaches Windows NT classes in fifteen countries and is a much sought-after speaker at Windows NT conferences, regularly keynoting and speaking at the NT Wizards and NT Professionals conferences. He also writes three popular columns in Windows NT Magazine, as well as "Eye on the Enterprise" in Japan's Nikkei NT magazine. His firm, MR&D, has taught tens of thousands of people to design and run Windows NT networks. Among his eight other Sybex books are Mastering TCP/IP for NT Serverhttp://www1.fatbrain.com/asp/bookinfo/bookinfo.asp?theisbn=0782121233&p=technet&s=29736"http://www1.fatbrain.com/asp/bookinfo/bookinfo.asp?theisbn=0782126065&p=technet&s=29736">http://www1.fatbrain.com/asp/bookinfo/bookinfo.asp?theisbn=0782126065 which has sold a million copies and been translated into twelve languages.
1999 Sybex Inc. All Rights Reserved.
We at Microsoft Corporation hope that the information in this work is valuable to you. Your use of the information contained in this work, however, is at your sole risk. All information in this work is provided "as -is", without any warranty, whether express or implied, of its accuracy, completeness, fitness for a particular purpose, title or non-infringement, and none of the third-party products or information mentioned in the work are authored, recommended, supported or guaranteed by Microsoft Corporation. Microsoft Corporation shall not be liable for any damages you may sustain by using this information, whether direct, indirect, special, incidental or consequential, even if it has been advised of the possibility of such damages. All prices for products mentioned in this document are subject to change without notice.