Previous Table of Contents Next Policies To avoid this type of situation, Microsoft has introduced a special administrative tool called a policy file. A policy file, when in the SYS:PUBLIC directory of a Novell server or the NETLOGON directory of an NT server, will enforce certain Registry settings for either default users or specific ones. This makes it sort of tough for users to shoot themselves in the foot, and it keeps you from wanting to shoot them elsewhere. A policy file can be as restrictive or as permissive as you like. You can lock down the Control Panel in part or in full, restrict application installation, and so on, as shown in Figure 16.3. In short, you can make yourself really, really unpopular with the users. It's a tough call-how much restriction is fair protection versus how much restriction makes a network a fascist police state? This pretty much depends on your corporate culture. [16-03t.jpg] Figure 16.3 The Windows NT System Policy Editor can restrict your users from doing just about anything. Windows policies make it possible for you to ensure that certain Windows attributes stay the same between PCs on your network. Although policies are pretty neat, they've long been considered hard to use. (Try the POLEDIT executable included on your Windows CD-ROM and see if you agree.) However, they are becoming usable-certainly more so since Microsoft introduced its Zero Administration Kit (ZAK). ______________________________________________________________ Check out Microsoft's take on low-cost deployment at http://www.microsoft.com/NTworkstation/Deployment/deployment /default.asp. ______________________________________________________________ Novell has recently released Z.E.N. (Zero Effort Networking) Works. Among other things, it allows you to administer Windows policies using NDS users, groups, and organizational units. (Z.E.N. also features application deployment tools and remote control.) Take a gander at http://www.novell.com/products/nds/zenworks for more information. App in a Snap It used to be that all you needed to do to deploy a network application was give a user a menu option or a shortcut. Windows applications are a lot more complex; some install lots of workstation files, make changes to the user's Registry, and can, frankly, drive network administrators nuts. ______________________________________________________________ Some (but not most) Windows applications are easy to standardize. All you need to do is to install the application into a shared network directory that many people can access. This way, you can configure the application from this central location. For example, NetTerm, a Telnet application, allows many users to use the same network directory to run the application without running the setup program on each workstation. Here's how to do this: 1. Run NetTerm's setup program. 2. Specify a network location for the program (for example, G:\NetTerm). 3. Create an icon for NetTerm on each user's desktop that points to G:\netterm\netterm.exe, either by visiting the user or by modifying the user's network profile. You'll have to check your manufacturer's documentation or experiment to determine whether you've got an application that will support this. ______________________________________________________________ For complex applications, application deployment tools are almost as cool as disk duplication. They basically take a snapshot of a PC before a given application is installed and then take one again after the application is installed. The differences-whether in the Registry, in the files on the C:\ drive, or wherever-are calculated and stored on the network. These differences can be applied to any PC. You have an instant application with minimum user interaction, and all from the network. This is a great method for standardizing user workstations in conjunction with disk duplication. The only thing to bear in mind when using one of the application deployment tools-for example, Microsoft's SYSDIFF, Novell's SnAPPshot, or Ghostsoft's Picture Taker-is that you need to make sure you're using a perfectly clean workstation when taking the "before" snapshot. That is, the workstation should never have had the application installed on it (ditto for shared components that the application wants). My preference is to keep a freshly installed copy of Windows (along with my file and print client of choice) around as a disk duplication file; I reload a hard drive with this right before taking a snapshot. This ensures that each app has a chance to perform a totally fresh install. Are there problems with this? There can be-applications are just as capable of conflicting due to automated installation as they are due to regular installation. The key, again, is to test, test, and test some more before you deploy. This up-front work-for any of the standardization techniques we've discussed in this hour-will pay off as you experience easy troubleshooting operations for hours, days, and weeks in the future. Summary Using network components that are similar means that you don't have to undertake deep troubleshooting in order to solve many local (not systemic) problems. Besides, heterogeneous components tend to behave the same-which, if they have a "known good" configuration, is a wonderful thing. Apart from using common-sense work habits while creating users and workstations, you'll also want to check out the built-in cookie-cutter functions of your network operating system, such as user templates and "Joe User" user copies. Although a little bit of scripting knowledge can be a dangerous thing, it can also be a huge help in streamlining user login setups. User profiles and disk duplication are simple and easy ways to ensure uniformity among your users, as well as to guide workstation setups or user setups back in line when they stray. What's more, policy management packages, such as ZAK and Z.E.N. Works, can really help as well. Add application deployment to the recipe, and you've got a mix of strong tools that will help your network stay as consistent as possible. Previous Table of Contents Next