This chapter discusses the use and creation of user policies. User policies are associated with users and affect their working environment.
You can create User Policy Packages in ZENworks for Desktops 4 for any of the Windows 32 environments, namely Windows 98/NT/2000/XP. The support for Windows 95 is available only with the ZENworks 3.x version; Windows 3.1 support is available only with the ZENworks 2 version.
Users are associated with user policies through associations with policies in any of three ways: 1) policies can be associated with the user object directly; 2) policies can be associated with a parent container of the user object; and 3) policies can be associated with a group to which the user is a member.
When a user logs into the tree, a ZENworks for Desktops 4 agent (Workstation Manager Service) walks up the tree looking for the first User Policy Package it can find that is associated with the user. Like all agents associated with ZENworks for Desktops 4, the order that the tree is searched is dependent on standard Novell Directory Services behavior and any search policies in the tree.
When a policy is being searched from the tree, the Workstation Manager agent walks the tree until it finds the root of the tree or a search policy that limits the searching. All of the applicable user policies are merged and then the culmination is applied to the workstation. If any policy conflicts exist (such as two user policies affecting the same parameter), the parameter setting in the first policy is applied.
The remote control policy can be created for both the user and the workstation. In the instances when a remote control policy exists for both the user and the workstation, the remote control subsystem takes the most restrictive combination of the policies. For example, if one policy says to prompt the user for permission and the other does not, the system prompts the user.
ZENworks 4 gives you easier administration by selecting policies in one place (the general page) and applying to all types of workstations that your users access. At the same time, you do not lose the ability to have unique policies for each platform, because the general policies can be overridden by a platform-specific policy (alternate platform page).
Regardless of the users who are logged into the system, each workstation finds the policies associated with it for that user, whether the policies come from the general policies or from the platform specific set, and executes the administrative configurations for that workstation.
On some occasions, you might want to associate a particular, unique policy to a set of users who are housed in containers along with other users of the same type. You can then create a group of users and associate specific policies to those users by associating the policy package to the user group. Consequently, these users receive the policies from this group rather than from the container.
In order to create a policy that affects users who are logging into the tree through workstations, you need to create a User Policy Package. To create a User Policy Package, do the following:
-
Start ConsoleOne.
-
Browse to the container where you want to have the policy package. Make sure you have the container where you want the policy package selected in ConsoleOne. Remember that you do not have to create the policy package in the container where you are doing the associations. You can associate the same policy package to many containers in your tree.
-
Create the policy package by right-clicking and choosing New, Policy Package or by selecting the Policy Package icon on the toolbar.
-
Select the User Package object in the wizard panel and press Next.
-
Enter the desired name of the package in the Policy Package Name field and select the container where you want the package to be located. The container field is already filled in with the selected container so you should not have to browse to complete this field. If you do need to browse, press the Browser button next to the field and find the container where you want the policy object stored. Press Next.
-
Select the Define Additional Attributes field in order to go into the properties of your new object and activate some policies. Press Finish.
-
Check and set any policies you desire for this User Policy Package and press OK.
The following subsections describe each of the fields and property pages that are available in the User Policy Package.
All of the user policies are activated within the policies property page. Initially, the page is on the general policies. As other platforms are selected, additional policies are displayed. You can select which platform to display by clicking the word Policies in the tab. This activates a drop-down menu that allows you to select which platform-specific page you want to display, (see Figure 8.1).
The following sections discuss briefly each of the policy pages; subsequent sections cover the specifics of each policy.
When you first go into the properties of the User Policy Package, you are presented with the Policy Property page. The policy page first displays the general category. All of the policies that are activated in the general category are active for all platforms supported by ZENworks for Desktops and associated with the logged in user.
Figure 8.2 shows a snapshot of the initial property page of the User Policy Package.
As you can see from Figure 8.2, only the Remote Control Policy and the iPrint Policy are available to all of the platforms supported by ZENworks for Desktops 4. The Remote Control Policy and iPrint Policy are discussed later in this chapter.
In order to activate a policy, you simply need to check it. You can then go into the details of the policy and set additional configuration parameters on that specific policy.
Within the policies tab, you can select the Windows 95-98 policy page. This page displays the policies that are available for your Windows 98 users. These policies include the Windows Desktop Preferences policy, Remote Control policy, iPrint Policy, and the User Extensible policies. See Figure 8.3 for a sample of the Win95-98 policies page.
As you can see, the Remote Control policy is under the general and the Win95-98 policies page. When you select a policy in the Win95-98 page it supercedes any selections made on the General tab. The policies are not merged; only the platform-specific policy is used instead of the policy set in the general category. Also, only the policies selected in the platform-specific tab are used in place of the general policies. For example, if the remote control policy is selected in the General tab and is not selected in the Win95-98 tab, when an associated user logs into a Windows 98 system, the general remote control policy is activated for that user.
Within the policies tab you can select the Windows NT policy page. This page displays the policies for Windows NT users. These policies include the Novell iPrint policy, Dynamic Local User policy, Windows Desktop Preferences policy, Remote Control policy, and the User Extensible policies. See Figure 8.4 for a sample of the WinNT policies page.
As with the Win95-98 properties page, you can see the Remote Control policy is under the general and the WinNT policies page. When you select a policy in the WinNT page, it supercedes any selections made on the General tab for that platform. The policies are not merged; only the platform-specific policy is used instead of the policy set in the general category. Also, only the policies selected in the platform-specific tab are used in place of the general policies. For example, if the remote control policy is selected in the general tab and is not selected in the WinNT tab, when an associated user logs into a Windows NT system, the general remote control policy is activated for that user.
Within the policies tab you can select the Windows 2000 policy page. This page displays the policies for your Windows 2000 users. These policies include the Dynamic Local User policy, Windows Desktop Preferences policy, Novell iPrint policy, Remote Control policy, User Extensible policies, and the Windows Group Policy. See Figure 8.5 for a sample of the Win2000 policies page.
Note that the Remote Control policy is under the general and the Win2000 policies page. When you select a policy in the Win2000 page, it supercedes any selections made on the general tab for that platform.
Within the policies tab you can select the Windows XP policy page. This page displays the policies that are available for your Windows XP users. These policies include the Dynamic Local User policy, Novell iPrint policy, Windows Desktop Preferences policy, Remote Control policy, and the Windows Group Policy. See Figure 8.6 for a sample of the WinXP policies page.
You can see the Remote Control policy is under the general and the WinXP policies page. When you select a policy in the WinXP page it supercedes any selections made on the General tab for that platform.
Within the policies tab, you can select the Windows 2000 Terminal Server policy page. This page displays the policies that are available for your Windows 2000 Terminal Server users. These policies include the Dynamic Local User policy, Novell iPrint policy, Windows Desktop Preferences policy, Remote Control policy, User Extensible policies, and the Windows Terminal Server Policy. See Figure 8.7 for a sample of the Win2000 Terminal Server policies page.
You can see the Remote Control policy is under the general and the Win2000 Terminal Server policies page. When you select a policy in the Win2000 Terminal Server page, it supercedes any selections made on the general tab for that platform, as described in earlier sections.
Within the policies tab, you can select the Windows XP Terminal Server policy page. This page displays the policies for your Windows XP Terminal Server users. These policies include the Dynamic Local User policy, Novell iPrint policy, Windows Desktop Preferences policy, Remote Control policy, User Extensible policies, and the Windows Terminal Server Policy. See Figure 8.8 for a sample of the WinXP Terminal Server policies page.
You can see the Remote Control policy is under the general and the WinNT Terminal Server policies page. When you select a policy in the WinXP Terminal Server page it supercedes any selections made on the general tab for that platform, as described in previous sections.
The Associations Page of the Windows User Policy Package displays all of the locations in the tree (containers) where the policy package has been associated. These associations do not necessarily reflect where the policy package is located in the directory. The Windows users who are in or below those containers have this policy package enforced. Choosing the Add or Remove buttons allows you to add or remove containers in the list that are associated with this policy.
The NDS Rights property page is made up of three sections. You can get to each of the pages by clicking on the small triangle to the right of the page name, and then selecting the desired page to be displayed.
These pages allow you to specify the rights that users have to this object. The following subsections discuss briefly each of these pages. These NDS Rights pages are displayed for every object in the tree.
On this page you can grant objects rights as trustees of the User Policy Package. These trustees have rights to this object or to attributes within this object.
When you assign a container as a trustee of an object, everyone in that container or subcontainer has some rights to this object. To view the details of any trustee assignment (in order to modify the assignment), you need to choose the Assigned Rights button.
When you choose the Assigned Rights button, you are presented with a dialog box that allows you to select either [All Attribute Rights] (meaning all of the attributes of the object) or [Entry Rights] (meaning the object, not implying rights to the attributes).
From within the assigned rights dialog box, you can set the rights for the object on this package. You can set those rights on the object as well as any individual property in the object. The rights that are possible are the following:
• Browse—Although not in the list, this right shows up from time to time (especially in the effective rights screens). This represents the capability to view this information through public browse capabilities.
• Supervisor—This right identifies that the trustee has all rights, including delete, for this object or attribute.
• Compare—This right provides the trustee with the capability to compare values of attributes.
• Read—This right allows the trustee to read the values of the attribute or attributes in the object.
• Write—This right provides the trustee with the capability to modify the contents of an attribute.
• Add Self—This right allows the trustee to add himself as a member the list of objects of the attribute. For example, if this right were given to an attribute that contains a list of linked objects, the trustee could add himself (a reference to their object) into the list.
If you want to add the object as a trustee to an attribute, choose the Add Property button to bring up a list of properties or attributes that are available for this object.
From this list, you can select a single attribute. This attribute is then displayed in the Assigned Rights dialog box. From there you can select the attribute and then set the rights you want the trustee to have for that property. A user does not require object rights in order to have rights on a single attribute in the object.
Remember that rights flow down in the tree. If you give user rights at a container level, those rights continue down into that container and any sub-containers until that branch is exhausted or until another explicit assignment is given for that user in a sub-container or on an object. An explicit assignment changes the rights for the user at that point in the tree. You can also use inherited rights filters to restrict the flow of rights down into the tree.
This page allows you to set the IRF (Inherited Rights Filter) for this object. This filter restricts the rights of any user who accesses this object, unless that user has an explicit trustee assignment for this object.
You can think of the IRF as a filter that lets only items checked pass through unaltered. Rights that bump up against an IRF filter are blocked and discarded if the item is not checked. For example, consider a user who has write privileges inherited at some point above the current container (they were explicitly granted that right at some container at or above the one we're in). This user runs into an IRF for an object or attribute that has the write privilege revoked (that is, unchecked). When the user got to that object, their write privilege would be gone for that object. If the object were a container, the user would lose write privileges for all objects in that container or sub-container.
You can effectively remove supervisor privileges to a portion of the tree by setting an IRF with the supervisor privilege turned off. You must be careful not to do this without someone being assigned as the supervisor of that branch of the tree (given an explicit supervisor trustee assignment at the container where the IRF is done) or you'll make that part of the tree permanent (that is, you can't ever delete any objects in that branch of the tree).
ConsoleOne helps prevent you from performing this action. It shows an error dialog box that keeps you from doing this without having first given an explicit supervisor assignment on the same container.
The Effective Rights property page allows you to query the system to discover the rights that selected objects have on the object you are administering.
Within this page, you are presented with the Distinguished Name (DN) of the object whose rights you want to observe. Initially, this is your currently logged in user running ConsoleOne. You can use the Browse button to the right of the trustee field and browse throughout the tree to select any object.
When the trustee object is selected, you can then move to the properties table on the lower half of the screen. As you select the property, the box to the right changes to reflect the rights that the trustee has on that property. These rights may be via an explicit assignment or through inheritance.
This page might not be displayed for you, depending on your rights to the plug-in that now comes with ConsoleOne.
Warning
This page is particularly powerful. People who do not have an intimate knowledge of the schema of the object in question and its relationships with other objects in the directory should avoid using this page.
The intention of this property page is to give you generic access to properties that you cannot modify or view via the other plugged-in pages. The attributes and their values are displayed in a tree structure, allowing for those attributes that have multiple types (are compound types that consist of, say, an integer and a distinguished name, or postal code that has three separate address fields).
Every attribute in eDirectory is defined by one of a specified set of syntaxes. These syntaxes identify how the data is stored in eDirectory. For this page, ConsoleOne has developed an editor for each of the syntaxes currently available in eDirectory. When an attribute is displayed on this page, the editor displays the data and modifies when the user clicks the specific attribute.
For example, if the syntax for an attribute were a string or an integer, an in-line editor is launched, thus allowing the administrator to modify the string or the integer value on the screen. More abstract syntaxes such as octet-string require that an octet editor be launched, thus giving the administrator access to each of the bytes in the string, without interpretation of the data.
The danger with this screen is that some applications require that there be a coordination of attribute values between two attributes within the same object or across multiple objects. Additionally, many applications assume that the data in the attribute is valid, because the normal user interface checks for invalid entries and does not allow them to be stored in the attribute. If you should change a data value in the other page, no knowledge of related attributes, objects, or valid data values are checked because the generic editors know nothing about the intention of the field. Should you change a value without making all the other appropriate changes, some programs, and the system, could be affected.
Rights are still in effect in the Other property page. You cannot change any attribute values that are read-only, or change any values that you do not have rights to modify.
This page in the property book is present in all objects in the directory. This property page allows you to view and set rights for this object for specific files and folders on that volume.
You must first select the volume that contains the files and folders in which you are interested. You can do this by pressing the Show button on the right and then browsing the directory to the volume object. Selecting the volume object places it in the volumes view. When that volume is selected you can use the Add button to add a file or folder of interest. This brings up a dialog box allowing you to browse to the volume object. Clicking on the volume object moves you into the file system. You can continue browsing that volume until you select the file or directory you are interested in granting rights.
Selecting the file or folder in the lower pane displays the rights that the object has been granted on that file or folder. To modify the rights, simply choose them to turn them on or off.
You can also see the effective rights that the object has on the files by pressing the Effective Rights button. This displays a dialog box, allowing you to browse to any file in the volume. The object's effective rights are displayed (in bold). These effective rights include any explicit and inherited rights from folders higher in the file system tree. Remember that anyone with supervisor rights to the server or volume automatically has supervisor rights in the file system.
The iPrint Policy option is available across all platforms and on the general policy page. It allows you to configure an iPrint client that can be placed on the workstation, allowing it to use Internet printing capabilities.
This page allows you to specify the path on a server where the iPrint client is. Setting this option on the iPrint policy will cause the iPrint client to automatically be installed on the workstation. You can also specify the language and the version number of the software.
The Remote Control Policy option is available across all platforms and on the general policy page.
A Remote Management Policy is activated for this policy package by selecting the check box on the Remote Management Policy. The Remote Management Policy is then activated for all users associated with the User Policy Package.
The Remote Management Policy controls the features of the Remote Management subsystem that ships with the ZENworks for Desktops 4. The Remote Management system is comprised of two parts:
• Remote Management Session Manager, which makes the connection and is used by the administrator
• Remote Management Agents, which are installed on the user's workstation
The remote control agent is part of the full ZENworks management agent and is installed as part of the agent installation process. You can run SETUP.EXE in the publiczenworks folder or get the MSI version of this from the Novell Cool Solutions and update sites.
The Remote Management system makes a peer-to-peer connection between the administrator's workstation and the remote workstation. You can do this using either the IPX or the TCP/IP protocol. In this policy, you can specify the preferred protocol for the connection. This protocol is attempted first, but if the connection cannot be made, the alternative protocol is used.
Remote controlling a workstation via ZENworks for Desktops 4 also requires rights within the Workstation Object that represent the workstation wanting to be controlled. Without these rights, the administrator is denied access to the remote control subsystem. Both the session manager and the agents validate that the user has rights to remote control the workstation. You assign the remote control rights through the Remote Management Rights wizard, or in the Workstation object in the Remote Operators page.
ZENworks for Desktops 4 added the capability to remote control via a password, without any workstation object in the tree. When launching remote control from the Tools menu of ConsoleOne, the dialog box that appears requires the IP address of the workstation and a password. This password must match the password entered by the user through the Security menu of the remote control agent (on the tray) of the workstation. The password use of remote control must be configured in the policy.
The Remote Management page identifies the features that you want to be activated with the Remote Management system. The following sections describe configuration options available under each of the tabs of the Remote Management policy window.
The first tab of the remote management panel allows you to set the following general system functions:
• Enable Diagnostics—This allows the agent on the workstations to perform a diagnostics report. Select the workstation and then right-click and select Actions, Diagnostics of the menu. The Diagnostics utility performs some basic queries on the system and returns the information about the workstation. This information includes memory, environment, and processes running. Additionally, it would include NDS and Netware connection information, client information, network drives, and open file list, as well as printers, Network protocols, and network services active. You can also view the various event and error logs that have been recorded on that workstation.
• Enable Password-based Remote Management—This field allows the operator to establish password-based remote management with the workstation.
• Terminate Session When Workstation User Logs In and Requires to Be Prompted for Permission—Terminates any ongoing remote management session with the workstation when a new user, whose permission for starting a remote management session is required, logs in.
The Control tab enables you to set the following remote control functions:
• Enable Remote Control—When this option is enabled, the remote control subsystem can be activated. Without this setting, no one can remote control the workstations.
• Prompt User for Permission to Remote Control—This option displays a dialog box on the user's machine when a remote control session is started. The user can accept or deny the remote control request. The dialog box tells the user who wants to remote control their machine and asks if this is approved. If the user denies the remote control session, the session is terminated and the administrator cannot remote control the workstation.
• Give User Audible Signal When Remote Controlled—This option provides the user with a tone periodically while the remote control session is active. You can also set the number of seconds between each beep.
• Give User Visible Signal When Remote Controlled—This option displays a dialog box on the user's desktop while the remote control session is active. The dialog box indicates that the workstation is being remote controlled and who is controlling the workstation. You can set the number of seconds that you want to have between flashing the name of the user who is initiating the remote control session.
• Allow Blanking User's Screen—This option causes the screen on the remote desktop to be blank, preventing the user from seeing what the administrator is doing. When you enable the blanking of the screen, the keyboard and mouse are automatically locked.
• Allow Locking User's Keyboard and Mouse—When the administrator remote controls the workstation the keyboard and the mouse on the remote workstation are deactivated. The user can move the mouse or keyboard, but they will not function and any input from them will be ignored.
The View tab enables the remote view functions. Remote view is the capability of the administrator to view the remote Windows screen of the target machine but not control the mouse or keyboard of the machine.
• Enable Remote View—When this option is enabled, the remote view subsystem can be activated. Without this setting, no one can remote view the workstations.
• Prompt User for Permission to Remote View—This option displays a dialog box on the user's machine when a remote view session is started. The user can accept or deny the remote view request. The dialog box notifies the user who it is that wants to remote view their machine and asks if this is approved. If the user denies the remote view session, the session is terminated and the administrator cannot remote view the workstation.
• Give User Audible Signal When Remote Viewed—This option provides the user with a tone periodically while the remote view session is active. You can also set the number of seconds between each beep.
• Give User Visible Signal When Remote Viewed—This option displays a dialog box on the user's desktop while the remote view session is active. The dialog box displays that the workstation is being remote viewed and who is viewing the workstation. You can set the number of seconds that you want to have between flashing the name of the user who is initiating the remote view session.
The File Transfer tab enables the file transfer system. This allows you to send files to the remote workstation.
• Enable File Transfer—When this option is enabled, the file transfer subsystem can be activated. Without this setting, no one can send files to the workstations in question.
• Prompt User for Permission to Transfer Files—This option displays a dialog box on the user's machine when a file transfer session is started. The user can accept or deny the file transfer request. Within this dialog box, the user is told who wants to perform the file transfer from his machine and asks if this is approved. If the user denies the file transfer session, the session is terminated and the administrator cannot send the files to the workstation.
The Remote Execute tab describes the feature enabling of the remote execute system. This allows you to remotely execute a program on the remote workstation. The output of the program is not displayed on the administrative console.
• Enable Remote Execute—Enables the administrator to execute applications or files on the remotely managed workstation.
• Prompt User for Permission to Remote Execute—This option displays a dialog box on the user's machine when a remote execute session is started. The user can accept or deny the remote execute request. If the user denies the remote execution session, the session is terminated and the administrator cannot execute the program on the workstation.
The NAT tab allows you to enable remote management operations across a NAT network boundary. The following options are configurable for remote management operations across NAT:
• Accept Connections Across NAT—This option enables the administrator to connect across NAT to perform remote management operations.
• Prompt User for Permission to Remote Execute—This option displays a dialog box to be displayed on the user's machine identifying the remote connection across NAT request. The user can accept or deny the remote connection request. If the user denies the remote connection request, the connection is terminated.
This policy is an option across all platforms. It allows you access to the ZAW/ZAK features that are exposed by the Microsoft Windows system. Within the ZENworks for Desktops 4 system, these ZAW/ZAK policies are divided into their logical parts: Desktop Preferences, User System Policies, and Workstation Policies. This policy allows the administrator to set the desktop preferences for any Windows system to which the user is currently connected. This policy follows the users as they move from workstation to workstation.
Microsoft provides tools called poledit for version prior to Windows 2000 and gpedit with Windows 2000 on. These tools allow an administrator to construct some Registry settings (ZAW/ZAK features) and have those settings saved in a file. These files can then be applied to any workstation by having the system look for these files on the server. The problem here is that these policy files must be located on every server that any user might use as an initial connection. With ZENworks for Desktops 4, this information is stored in these policies and into Novell Directory Services, thus making it always accessible to every user who connects to the system without having to place these policy files on every server.
Editing policies is discussed in more detail later in the chapter when group policies are discussed.
The Desktop Preferences policies allow the administrator to set Control Panel features as well as roaming profile configurations.
The settings for any particular desktop such as the desktop icons, screen colors, taskbar selections, and so on, are stored in profiles. These profiles can, with this Roaming Profile feature, be placed into the file system on the network. By doing this, when users who have profiles saved on the network log into any workstation, their profiles are retrieved from the network and brought to that workstation. This allows a consistent look and feel for the workstation to be presented to the users regardless of which actual workstation they are using. Any changes to the desktop, or preferences, are stored on the network and therefore reflected the next time that the user logs into any workstation. Figure 8.9 shows the Roaming Profile page.
Figure 8.9. Roaming Profile page of a Windows Desktop Preferences policy of the User Policy Package.
In the Roaming Profile page, the administrator can set whether roaming profiles are available. If they are available, you want to also check the Enable Storage of Roaming Profiles check box. This option allows the profiles to be stored on a network server for access from any workstation.
The Override Terminal Server Profile option means that this user profile will override any profiles that they receive via the Terminal Server system available for NT servers.
Once the enabling of storage has occurred, you have the choice of either allowing the profiles to be stored in the user's home directory or in a specified file system directory. When you specify that the profiles be stored in the user's home directory, a subdirectory called Windows 95 Workstation Profile is created in the home directory. Within that directory, the profile information is stored and maintained.
If you identify a specific directory, all users who log into the workstation with that policy store the desktop information directly into that directory, and have the profiles shared with all users who log into that workstation. This is why storage into a specific directory is recommended for mandatory profiles only.
The NDS Rights, Other, and Rights to Files and Folders pages are described in the “Creating a User Policy Package” section earlier in this chapter.
By clicking each of the icons presented in the Settings page of the Windows Desktop Preferences policy, the administrator can configure the properties of each of these Control Panel items.
The standard scenario is that the agent searches the tree for this policy and applies it during the user login process. You can change this schedule in the policy package to be another scheduled time or event. To ensure that these preferences are always applied when the user logs into the tree, regardless of the schedule in the policy, you need to check the Always Update Workstation During NDS Authentication check box.
By clicking this icon, you are presented with a tabbed dialog with the capability to set the following properties:
• Keyboard page allows you to set the standard Windows 95/98 Accessibility Options for StickyKeys, FilterKeys, and ToggleKeys.
• Sound page allows you to set the SoundSentry and ShowSounds.
• Mouse page allows you to configure the mouse keys.
• General page allows you to configure Automatic reset, Notification, and SerialKey devices.
This icon brings up the property page that allows you to configure the properties of the console window (such as a DOS box) for the Windows 95/98 system. The Console Windows properties allow you to set the following:
• From the Options tab, you can set the console options such as Cursor Size, Display Options, Command History sizes and buffers, QuickEdit Mode, and Insert Mode.
• From the Layout tab, you can configure the Screen Buffer Size, Window Size, and the Window Position.
• From the Colors tab, you can set the console colors for the text and backgrounds.
From this policy, you cannot set the font properties of the Console window.
Clicking this icon brings up the property page that allows you to make the following configurations:
• The Background tab enables setting of the wallpaper. You can specify that no wallpaper be presented or specify a filename of the .BMP file to be displayed for the wallpaper.
• The Screen Saver page enables you to determine whether a screen saver should be available. You can specify a particular .SCR or .EXE file to be executed for the screen saver. In addition to the screen saver program, you can specify if the screen should be password protected. Also on this page you can specify the capability to use the energy saving features of your monitor.
• The Appearance tab enables you to specify the color scheme that you want applied for this user. You can set the color scheme to any of the following choices: Windows Standard, Brick, Desert, Eggplant, High Contrast Black, High Contrast White, Lilac, Maple, Marine (high color), Plum (high color), Rainy Day, Red White and Blue (VGA), Rose, Slate, Spruce, Storm (VGA), Teal (VGA), or Wheat.
• The Plus page enables you to set some basic features of the Plus! Package. You can use large icons, show window contents while dragging, show smooth edges of screen fonts, show icons using all possible colors, and stretch the desktop wallpaper to fit the screen.
This icon allows you to specify character repeat rates and the cursor blink rate on the user's machine.
This icon brings up the property page of the mouse system for the user. From this property page, you can set the following features:
• The Buttons tab provides you with the following features: button configuration for left- or right-handed mouse and double-click speed.
• The Pointers tab allows you to configure the mouse cursor to be used: 3D Bronze, 3D-White, Conductor, Dinosaur, Hands 1, Hands 2, Magnified, Old Fashioned, Variations, Windows Animated, or Windows Default.
• The Motion property tab gives you the capability to set the pointer speed, snap to default, and the pointer trail speed.
This policy option is available across all platforms.
Microsoft has required that software packages that bear the Windows approved logo provide capabilities to be configured through .POL files. The poledit program allows you to edit these “extensible policies” and include them in the system .POL file. ZENworks also allows the policies that are stored in NDS to accept these additional extensible polices and provide them to all of the users who are associated with these policies.
The User Extensible policy allows you to import these special .ADM files into the NDS tree and have them administered and dispersed to the users associated with the policy package. Once these .ADM files have been imported into the tree, they can be administrated and associated to users in the NDS tree. These settings are applied like the User System Policies.
When you first bring up the User Extensible Policies dialog box, you are presented with the User Extensible Policies page. An example of this page is displayed in Figure 8.10.
This page is split into three areas: ADM files, Policies, and the policy-specific window in the bottom-right corner.
The files in the ADM file list are the policies that are applied to the users associated with this policy. To add a policy file to the list, use the Add button. You are presented with a file dialog box where you can browse and select the file. Remember that this file should reside on the server, as it is stored there for retrieval by the policy managers. When you browse and select a file, make sure it is on the server, and that the drive that you use is mapped correctly for all users who are associated with the policy. You can enter a UNC path in the filename field of the dialog box and thereby get a UNC path for the ADM file; however if you browse and then select, the program puts a drive letter into the path, thus necessitating that each user has the same drive mapping.
When this policy is initialized, four .ADM files are automatically pulled in by the plug-in into ConsoleOne. These include ADMIN.ADM, COMMON.ADM, WINNT.ADM, and ZAKWINNT.ADM. Each of these files is stored in the ConsoleOneinzenadmfiles directory and is considered the default package.
Note
The .ADM file must be stored on a server that users can access. The policy references the .ADM file and needs to retrieve it to apply it to the users and to allow the administrators to modify the settings. It's recommended, therefore, to use a UNC path in specifying the location of the file.
You delete the .ADM file from the applied set by selecting the file and pressing the Remove button.
Note
Other .ADM files are available depending on which version of Windows you are running on your workstation. For example, Windows 2000 clients also include SYSTEM.ADM; there is an INETRES.ADM file for restricting Internet Explorer.
You can also modify the settings of the .ADM files by selecting the file in the ADM files windows. When you select the file, its Registry content is displayed in the Policies window. The user interface for this window mimics the poledit program available from Microsoft. The small window underneath the Policies box displays information about the selected Registry setting along with any categories that are available for the specific key. Selecting the key in the policies window populates the details fields.
You can browse through the ADM files and turn on, turn off, or leave as set in the Registry (unchecked and grey) for each of the keys as you would in the poledit program. Once you have made your changes, choose Apply or OK to update the ADM files on the server.
The NDS Rights, Other, and Rights to Files and Folders pages are described in the “Creating a User Policy Package” section earlier in this chapter.
The Policy Schedule page enables you to customize (outside of the package default schedule) when you want the ADM files applied to the workstation/desktop of the user.
This page enables you to select when the package should be applied: Event, Daily, Weekly, Monthly, or Yearly.
Once you have selected when you want the package applied, you have additional fields to select in the lower portion of the screen. The following sections discuss these options.
When you choose to have the ADM files applied when a certain event occurs in the workstation, you also need to select which event affects the changes.
The events that you can select include the following:
• User Login—This causes the policies to be applied when the user logs into the system. This happens after the user enters a username and password, but before the desktop appears and the user login scripts have started.
• User Desktop Is Active—This runs the policies after the user has logged into the system and all login scripts have been completed, but before the desktop is displayed. This is available with Windows NT/2000 only.
• Workstation Is Locked—This causes the policies to be applied when the workstation is locked (such as when the screen saver is activated and is locked awaiting a password). This is available with Windows NT/2000 only.
• Workstation Is UnLocked—This runs the policies when the workstation becomes unlocked, after the user has supplied the password to unlock the system. This is available with Windows NT/2000 only.
• Screen Saver Is Activated—This runs the policies when the screen saver is activated on an idle system.
• User Logout—This applies the policies when the user logs out of the system.
• System Shutdown—This applies the policies when a system shutdown is requested.
When you choose to have the ADM files applied daily on the workstation, you have to select when the changes are made.
This schedule requires that you select the days when you want the policy applied. You select the days by clicking on the days you desire. The selected days appear as pressed buttons.
In addition to the days, you can select the times the policies are applied. These times, the start and stop times, provide a range of time when the policies are applied.
To keep all workstations from simultaneously accessing the servers, you can select the Randomly Dispatch Policy During Time Period option. This causes each workstation to choose a random time within the time period when they retrieve and apply the policy.
You can alternatively choose that the policies be applied only weekly.
In the weekly screen, you choose on which day of the week you want the policy to be applied. When you select a day, any other selected day is unselected. Once you have selected the day, you can also select the time range when the policy may be applied.
To keep all workstations from simultaneously accessing the servers, you can select the Randomly Dispatch Policy During Time Period option. This causes each workstation to choose a random time within the time period when they retrieve and apply the policy.
Under the monthly schedule, you can select on which day of the month the policy should be applied, or you can select the last day of the month to handle the last day because all months obviously do not end on the same calendar date.
Once you have selected the day, you can also select the time range when the policy is applied.
To keep all workstations from simultaneously accessing the servers, you can select the Randomly Dispatch Policy During Time Period option. This causes each workstation to choose a random time within the time period when it will retrieve and apply the policy.
Select a yearly schedule when you want to apply the policies only once a year.
On the yearly page, you must choose the day that you want the policies to be applied. You do this by selecting the Calendar button to the right of the Date field. The monthly dialog box appears. Browse through the calendar to select the date you want to choose for your policies to be applied. This calendar does not correspond to any particular year and might not take into account leap years in its display. This is because you are choosing a date for each year that comes along in the present and future years.
Once you have selected the date, you can also select the time range when the policy is applied.
To keep all workstations from simultaneously accessing the servers, you can select the Randomly Dispatch Policy During Time Period option. This causes each workstation to choose a random time within the time period when they will retrieve and apply the policy.
On each of the scheduling pages you have the option of selecting the Advanced Settings button, which allows you some additional control on the scheduled action that is placed on each user's workstation. Pressing the Advanced Setting button gives you a dialog box with several tabs to set the specific details of the schedule.
When first displayed, the Completion tab is activated. The following sections describe each field on the tabs and how it relates to the action.
The Completion tab allows you to specify what should happen on the workstation once the scheduled action has completed. You can choose any of the following:
• Disable the Action after Completion—This prevents the action from being rescheduled after completion. If you decide that the policy should be applied every hour, choosing this turns off that action. The policy will not be reapplied. This rescheduling only occurs and is reset when the user logs off and back onto the system.
• Reboot After Completion—This causes the workstation to reboot after applying the policies.
• Prompt the User Before Rebooting—This allows the user to be prompted before rebooting. The user can cancel the reboot.
This tab allows you to specify what should occur if the scheduled action fails in its completion.
The following choices are available to failed actions:
• Disable the Action—This results in the action being disabled and not rescheduled or rerun.
• Retry Every Minute—This attempts to rerun the action every minute despite any schedule specified in the policy.
• Ignore the Error and Reschedule Normally—This assumes that the action ran normally, and reschedules the action according to the policy.
These settings allow you to specify the account that should be used when running the action.
The following choices are available for the user type that is used to run the scheduled item:
• Interactive User—This option runs the action with the rights of the currently logged in user. This should be used if it is acceptable to run this action and not have access to the secure portions of the Registry, because most local users do not have access to the secured portions of the Registry or file system.
• System—This option runs the action in the background with administrative privileges. This impersonation level should be used only if the action has no user interface and requires no interaction with the user.
• Unsecure System—This option runs the action as a system described above, but allows user interaction. This is available only on Windows NT and 2000 and should be used carefully because NT does not normally allow a cross-over between user and system space.
This tab allows you to specify at which level you want the action to run on the workstation.
The following choices are available within the priority schedule:
• Below Normal—This schedules the actions at a priority that is below the normal user activity. This level does not interfere with the behavior of the system and gives the user a normal experience.
• Normal—This schedules the action at the same level as any user activity. This can cause the workstation to perform at a slower level because the service is competing with the user for resources.
• Above Normal—This level schedules the action at a higher priority than the user requests and results in being completed before user activity, such as mouse and keyboard input, is serviced by the system. Using this level allows the action to be completed faster; however, it can impact the user by resulting in slow performance on the client.
This tab of the scheduled advanced settings allows you to specify how long the service should be allowed to run before it is terminated. You can use this option to protect yourself from having the action run for long periods of time on the workstation. This terminates the action, which might cause the action to not complete properly. This tab is not normally used because you usually want the action to complete.
Often, several users within a company have access to shared Windows NT workstations, and it would be an administrative nightmare to have to keep up accounts for all users of these shared systems. Consequently, ZENworks for Desktops 4 can dynamically create accounts on the local NT workstation while the user is logging into the system. The local account is literally created at login time.
By having the system automatically create the account at the time that the user is authenticated to the Novell Directory Services tree, any of these users can log into any Windows NT workstation and have a local account automatically created on that workstation. To prevent the system from allowing any user to log into a specific workstation, you can administer the Restrict Login Policy in the Windows NT specific Workstation Policy Package. The Restrict Login Policy allows you to specify which users can log into the specific workstation. Figure 8.11 displays the dynamic local user policy page.
The NDS Rights, Other, and Rights to Files and Folders pages are described in the “Creating a User Policy Package” section earlier in this chapter.
Checking the Enable Dynamic Local User option allows the system to start creating accounts on the local system. The following options can be set in this policy:
• Manage Existing NT Accounts (If Any)—This option allows the ZENworks for Desktops 4 agents to manage a previously existing account for this user through the Dynamic Local User system. Any previously generated accounts are subject to the properties that you administer in this policy.
• Use NetWare Credentials—The system uses the Novell Directory Services password as the password for the local account.
• Volatile User (Remove NT User After Logout)—This check box is accessible only if you have previously checked the Use NetWare credentials box. This check box enables the system to remove the local account that was used for the dynamic user when the user logs out of the system. This feature in conjunction with the Manage Existing NT Account (If Any) option causes a previously created local account to become volatile and to be removed when that person logs out of the workstation.
• NT Username—This field is accessible only if the Use NetWare Credentials option is disabled. The system uses the specified name for the local account when any Novell Directory Services user logs into the system.
• Full Name—This field is accessible only if the Use NetWare Credentials option is disabled. The system uses the specified full name for the local account when any Novell Directory Services user logs into the system.
• Description—This field is accessible only if the Use NetWare Credentials option is disabled. The system uses the given description for the local account when any Novell Directory Services user logs into the system.
• Member of/Not Member of—These lists allow you to specify which local accounts, created or used for these users, are members of which local NT groups.
• Custom—This button allows you to create new custom groups in order to make the dynamic local users members of these groups.
If the NetWare credentials are not used for the Dynamic Local User policy—causing the NT username, full name, and description to be used—this account will always be volatile and will be created and then removed each time a user logs into and out of the workstation.
Additionally, if any password restrictions (including minimum password age or length or uniqueness) have been placed in the local workstation policy, the Dynamic Local User system is not activated for that workstation. A dialog box notifying the user that Dynamic Local User features have been disabled is displayed whenever anyone attempts to log into the workstation.
The Windows Group Policy option is available on the Win2000 and WinXP platforms.
With Windows 2000 and Active Directory, Microsoft introduced the Group Policy to their servers. You can apply this policy to a set of users who are part of a container or a sub-container in Active Directory. Novell ZENworks for Desktops 4 incorporates this group policy into ZENworks by applying this policy to any group, user, or container in the tree.
The Microsoft Group Policy is nothing more than another .ADM file that is applied to all the users in the container—in Novell's case, users associated with this policy via direct association, group association, or container association.
Figure 8.12 displays a sample screen of this policy.
This allows you to specify or browse to the location of the group policy you want to edit or create.
• Edit Policies—If you are running on a Windows 2000 or XP workstation, the Microsoft Management Console editor appears. You can then edit the user and computer configuration settings.
• Import Active Directory Folder—If you want to create or access a group policy from Active Directory, this option allows you to browse to the folder where the Active Directory Group policy is and copy it to the directory specified in the Network Location field.
Check this box to indicate that the selected group policies remain in effect on the local desktop after the user has logged out.
In earlier releases of ZENworks, it wasn't possible to apply computer configuration settings to a user. ZENworks for Desktops 4 allows you to apply Windows user, computer, and security settings to be selected with a user policy.
• User—This option enables the settings under User Configuration with the group policy.
• Computer—This option enables the settings under Computer Configuration (except security settings) with the group policy.
• Security—This option applies all security settings in the group policy.
The NDS Rights, Other, and Rights to Files and Folders pages are described in the “Creating a User Policy Package” section earlier in this chapter. The Policy Schedule page is described in the “User Extensible Policy,” which also appears earlier in this chapter.
The Windows Terminal Server policy option is available on the WinNT Terminal Server, Win2000 Terminal Server, and the WinXP Terminal Server platforms.
For a greater compatibility between ZENworks for Desktops 4 and other systems, ZENworks has included a new policy that allows you to administer your user's interaction and the behavior of terminal server available on Microsoft servers.
The NDS Rights, Other, and Rights to Files and Folders pages are described in the “Creating a User Policy Package” section, earlier in this chapter.
Figure 8.13 displays a sample page of this policy.
In this policy, you can administer the various aspects of the terminal server, as follows:
• Allow Login to Terminal Server—This allows associated users the capability to log into the terminal server system.
• Broken or Timed-Out Connections—You can cause the system to disconnect these broken connections or choose to reset the connection.
• Reconnect From—This allows you to choose whether the reconnection should be done from any available client on the terminal server or from the previous client (the one that timed out).
• Timeout Settings—Here, you can set the time in minutes for each of the connection times, disconnect timeout, and idle timeout times.
• Shadowing—These fields allow you to enable or disable shadowing on the terminal server along with the options to allow input and to notify the client when shadowing is enabled.
• Modem Callback—This allows you to enable modem callback and administer the phone numbers to use.