In previous Daily Drill Downs, we’ve shown you how to install and configure ZENworks for Desktops on your network. Now it’s time to get down to work. One of the most powerful and useful features of ZENworks is its ability to allow you to control your users’ desktops. In this Daily Drill Down, we’ll take a look at the various Policy Packages you can distribute using ZENworks.
What are Policy Packages?
If you use or plan to use ZENworks, then you will use Policy Packages to some extent. Policy Packages are about managing and restricting user desktops. Dealing with user desktops can sometimes be a very time-consuming chore.
A Policy Package is a set of rules that dictates how a user is granted access to workstations and how the workstation desktop is presented to the user. There’s a Policy Package for restricting and managing users and a similar package for workstations. This Daily Drill Down explains the functionality of User and Workstation Policy Packages.
Policy Packages are special NDS objects that contain policies for implementing a number of useful functions. The User Policy Packages are for policies specifically targeted at users and the Workstation Policy Packages are associated with Workstation objects. There’s also a Container Policy Package for improving NDS login performance. These Policy Packages are available only for Windows platforms. If you’re running a non-Microsoft desktop operating system such as a Mac, OS/2, or Linux, then you’re out of luck. The following packages are available:
- Windows NT/2000 User Policy Package
- Windows 95/98 User Policy Package
- Windows 3.x User Policy Package
- Windows NT/2000 Workstation Policy Package
- Windows 95/98 Workstation Policy Package
- Windows 3.x Workstation Policy Package
- Container Policy Package
In the next section, I’ll go into each package, unpack it, and explain what the policy is for and where the pitfalls are (if any). It’s up to you to decide how it fits into your organization and how it should be implemented.
Creating a Policy Package
Policy Packages (and most objects) are created using the NWAdmin program. Run the program, and select the container where the object will reside. Right-click the container, and select Create. Then, scroll down through the list until you find Policy Package and click OK.
You’ll be presented with a list of possible Policy Packages. After selecting the package you need, you’ll see a list of available policies. At this stage, you can configure the policies if you like, but I usually just give the package a name. Then, I create it and configure the policies later by reopening the Policy Package object.
Caring for your NDS
The User Policy Packages include a Windows NT User Policy Package, a Windows 95/98 User Policy Package, and a Windows 3.x User Policy Package. These policies are associated with User objects and should be placed as close as possible to them. The Windows NT Workstation Policy Package, Windows 95/98 Workstation Policy Package, and Windows 3.x Workstation Policy Packages are associated with Workstation objects and should be placed as close as possible to them.
A Container Policy Package is also included that can be used to ensure that policy search times are reduced. This policy should be placed with the Policy Packages and used to reference the users and workstations to keep the policy search from navigating the whole NDS tree.
User Policy Packages
The contents of a User Policy Package differ according to the platform. Some of the policies are the same or similar across platforms, and some policies are present in one platform package and not in another. These policies are listed below, and the supported platform is indicated.
Dynamic Local User Policy (Windows NT/2000 only)
If you have or plan to have Windows NT or 2000 Workstations, then you must use this policy. Windows NT and 2000 require that you log in before you can use the workstation. This means that you need to have an account on each workstation the user plans to use so that the user can log in to the workstation as well as the NDS. The Dynamic Local User Policy eliminates this need by dynamically creating an account on the workstation when the user has successfully authenticated to the NDS. The account can either remain afterwards or be removed when the user logs out.
Select the check box next to the policy, click the Details button, and then enable the policy. This is the stage where you need to decide whether you want the user account to remain or be removed. When the Policy Package is associated with a user, a group of users, or a container of users, those users will be able to log in to Windows NT/2000 workstations under the following conditions:
- The Novell client is installed on the workstation and configured to use your NDS tree.
- Workstation Manager is installed on the workstation, with your NDS tree configured as the trusted tree.
If you plan to remove the account during logout, watch out for file ownership when the user next logs in. When the user account is created, the account is granted a unique number called a Security Identifier (SID). This SID is used by the NTFS to identify the owner of any of the user’s files. When the account is deleted, the SID is set aside by the system and never used again. When the user logs in again, he’s given a new NT Workstation account and SID. Because he’ll have a new SID, he’ll no longer own the files from the last session.
If you have users who tend to use the same workstation, it may be better to keep the account on the workstation rather than delete it. If your users roam about, then this may become a problem. The obvious solution is for the user to keep all personal files on the NetWare file server, where they will be backed up, and the SID issue will disappear. This is probably good practice for any distributed network, anyway.
Helpdesk Policy (all platforms)
This policy contains the configuration for the Help Requester application. This application can be made available to users so that they can forward problems to your help desk. To enable the policy, select the check box and click the Details button. The Information page defines contact details, such as e-mail addresses and phone numbers.
Through the Configuration page, you can define the mechanism for sending help requests or trouble tickets via e-mail. If your help desk software accepts help desk requests via e-mail and then forwards them to IT support specialists via the subject line, you can enter the available subject lines here. Doing so will enable users to provide a short description of the problem.
Desktop Preferences Policy (Windows NT/2000 and Windows 95/98)
If you need to force certain desktop preferences, such as the wallpaper or screen saver, then you can perform this task through this policy. If you wish to disable Control Panel functionality, however, then you should look at the User System Policies detailed later.
The Desktop Preferences Policy also allows you to enable roaming or mandatory policies. To enable the policy, select the check box and click Details, then select the Profiles tab. This will open a page that allows you to define the location of the profile. If you choose the user’s home directory (roaming profile), the profile will be stored in the root of the user’s home directory for Windows 95/98, the Windows NT 4 Workstation profile directory for NT 4, or the Windows NT 5 Workstation profile directory for Windows 2000. You can also define another location on the NetWare server to store a mandatory profile.
You’ll need to set up some sort of profile for your workstation service to work. The roaming profile is very useful if you wish to allow your users some freedom to have personal settings or if your users tend to use different workstations. If you wish to really restrict your users, then a mandatory profile may be the best solution. The profile consists of not only the user’s HKEY_CURRENT_USERcontained in the file Ntuser.dat (for Windows NT/2000) or User.dat (for Windows 95/98), but also other settings, such as the contents of his or her personal desktop and favorites list.
NT User Printer Policy (Windows NT/2000 only)
This policy allows you to install printers on remote NT Workstations and to set a default printer for the user. If you require that only certain users can use certain printers, then this policy will work for you. Workstation Manager installs the driver on the user’s behalf because the user may not have rights on the workstation to perform this work.
You may wish to consider assigning printers to a workstation instead so that a user who is normally in the Tokyo office and is visiting the London office will print in London and not Tokyo. This policy for Windows NT and Windows 95/98 Workstations is discussed later in this Daily Drill Down.
User System Policies (Windows NT/2000 and Windows 95/98)
The Zero Administration Kit (ZAK) from Microsoft allows the system administrator to keep the power and stability of the Windows operating system but remove unnecessary flexibility. ZAK does its work through mandatory profiles and extended policy settings. These restrictions can be used to simplify the system or to protect the system (or both).
When you view the tree of system settings, you’ll notice that all the check boxes are gray, and when you click a check box it can either be white or ticked. These settings seem to confuse many people, but they are very simple once you understand them. All of the System Policies have three possible values:
- Enable(box is selected): This will enable the policy by setting a registry key to a certain value. If you have more than one Policy Package governing more than one group, and you enable a policy for one group, you may need to disable it for the other, depending upon the reason for the Policy Package.
- Disable(box is white): This will disable the policy by setting a registry key to a different value than the Enable option. If you have more than one Policy Package governing more than one group, and you disable a policy for one group, then you may need to enable it for the other.
- Ignore(box is gray): This is the default setting for all polices. When the policy settings are inspected for action during the login process, the registry key for that policy will be ignored. If you have two groups of users—one administrators and the other users—you will probably use two different Policy Packages to govern their access. The Ignore setting may not be the best setting when one group needs more rights than the other. If one Policy Package has a policy setting enabled, then the other will need to have it disabled. A good example of this is when you want to disallow users from running the registry editing tools (a good idea). To do this, enable the Registry Editing Tools Policy in the User System Policies for users and disable it for administrators. Leaving it in the Ignore state will probably disable it for everyone. Ignore settings are much quicker to parse than the enabled and disabled states, so it’s probably best to leave all policies in this state unless you specifically need them set one way or the other.
One of the distinctions between Windows NT/2000 and Windows 95/98 is security. Windows NT/2000 insists that some authentication occur before allowing anyone to use the system. Windows 95/98 has none of these distinctions. User System Policies help you increase the security of certain areas of the Windows 95/98 system to prevent users from fiddling in those areas.
Remote Management Policy (Windows NT/2000 and Windows 95/98)
If you plan to use the Remote Management feature of ZENworks, this policy contains all the configuration you need for indicating how the agents running on the workstations should behave for certain users. The policy in this case dictates how the agent should behave for a particular set of users associated with the Policy Package.
Extensible Policies (Windows NT/2000 and Windows 95/98)
This is really an extension to the System Policies shown above. System Policies are defined by ADM files. These files dictate what the policy is, which registry keys they affect, and what the keys should be set to. The Microsoft Poledit program reads the ADM file, and the tree of policies is displayed. There is no reason why you couldn’t write your own ADM file to force a certain registry state when users log in. There are certainly lots of these files available in the Zero Administration Kit that may be useful to you. The Extensible Policies are designed to allow you to include extra registry key settings from these ADM files so that they can be forced on the user during the login process.
Workstation Import Policy
If you wish to make use of Workstation objects, then you’ll need to set up this policy so that they can be imported. Enable the policy and click the Details button. You can then define what the workstation should be called and where the Workstation object should be placed when imported.
Workstation Policy Packages
The contents of the Workstation Policy Packages also differ according to the platform. There are very few options in the Windows 3.1 Policy Package compared to the Windows NT Policy Package. The affected platforms are indicated below.
Computer System Policies (Windows NT/2000 and Windows 95/98)
The Computer System Policies are very similar to the User System Policies as far as function is concerned. The emphasis is on the workstation in this case. Remember that although the workstation is what is being affected, it is the user who will experience the policies. The issues involved in setting the Enable, Disable, and Ignore values are the same as those discussed earlier in the User System Policies.
3.x Computer System Policy (Windows 3.x)
This policy is not as sophisticated as the Windows NT and Windows 95 Computer System Policies, but it does give you the ability to manage certain files on the workstation, which is worth doing if you have many Windows 3.x systems. The Windows 3.x workstation must have Workstation Manager running or the file management will not work.
Select the check box next to the 3.x Computer System Policy and click the Details button. This will open a window where you can list a set of files to be managed. If a file is binary, you can copy it down to the client from a networked drive. If the file is ASCII, you can view its contents to ensure that the lines in the file are set correctly.
Client Configuration Policy (Windows NT/2000 and Windows 95/98)
If you wish to ensure that the NetWare client is configured correctly, you can enforce the correct settings from the Client Configuration Policy. If the workstations are running Windows NT or 2000, the user will not have the rights to modify them, so this policy is of most use for Windows 95/98 workstations that may suffer from user interference. Select the check box next to the policy and click the Details button to reveal a set of tabbed pages similar to the Client Configuration pages in the client itself.
Computer Printer Policy (Windows NT/2000 and Windows 95/98)
The Computer Printer Policy allows you to install printers on the local workstation and define the default printer as well. This policy makes a lot more sense to me than the User Printer Policy described earlier. Printers and workstations usually stay put, so the available printers should be tied to the workstation rather than the user, who is much more mobile. Click the Details button, then indicate the queue from which the print jobs are to be spooled and the driver to be associated with the printer.
RAS Configuration Policy (Windows NT/2000)
The Remote Access Service (RAS) Configuration Policy allows you enforce standard settings for the RAS Control Panel on Windows NT and Windows 95/98 Workstations. If you need the users to dial up, then this policy is useful for ensuring that Control Panel is set up correctly.
Remote Management Policy (Windows NT/2000 and Windows 95/98)
Similar to the User Remote Management Policy, this policy affects the workstation rather than the user. ZENworks Remote Management can be implemented in several ways. It may be that you wish to be able to remotely manage all your workstations or users. If you wish to manage only certain workstations, then this policy is best. If you wish to manage only certain users regardless of which workstation is in use, then use the User Remote Management Policy.
Restrict Login Policy (Windows NT/2000 and Windows 95/98)
If you need to define which users can use certain workstations, then this is the place to make that definition. Enable the policy by selecting the check box, then click the Details button. This will reveal a window with two columns: Allow Access From and Deny Access From. If you enable this policy and have nothing listed in either column, no one will be able to use the workstation! You must have at least one user in the Allow column so that the workstations associated with the policy can be used by that user.
Extensible Policy (Windows NT/2000 and Windows 95/98)
This policy is functionally exactly the same as the User Extensible Policy except that it affects computer system policies rather than the user-oriented policies.
Workstation Inventory Policy (Windows NT/2000 and Windows 95/98)
If you intend to use the workstation hardware and software inventory, you’ll need to define how it is to function via this policy. The ZENworks Inventory System collects the inventory data and stores it in a Sybase database on the server. Click the Details button to reveal pages that dictate how the inventory is to function.
The hardware inventory is performed by a scanner program. You will have to indicate where this program is located for the scan to occur. The hardware-scanning program will find and identify components of hardware from most parts of the system, including the memory, video, network card, etc., and will also collect DMI data.
If you wish to use the software inventory function, you’ll need to tell the software scanner what to look for and how to recognize it. There is a long list of software that can be recognized. This software is held in a file called ldappl.ini. It’s probably not a good idea to have all the software in the list set to be scanned and identified because the scan may take a long while to run. Go through the list and select which pieces of software you want to look for.
Container Policy Package Search Policy
The Search Policy’s purpose in life is to speed up login time by helping a User or Workstation object find its associated policies. A search through the entire NDS tree could result in an unacceptable login time.
In this Daily Drill Down, I showed you that Policy Packages are very useful objects. They are the cornerstone for desktop management within ZENworks and should be used whenever required. Because of an obvious maintenance overhead of having too many of these objects, you should exercise a little caution when using them.
The authors and editors have taken care in preparation of the content contained herein but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.