This chapter discusses the use and creation of workstation policies. Workstation policies are associated with workstations and workstation groups, and affect their working environment.
Workstations are associated with Workstation Policies through associations with policies in any of three ways: 1) policies can be associated with the workstation object directly; 2) policies can be associated with a parent container of the workstation object; and 3) policies can be associated with a workstation group to which the workstation is a member.
The ZENworks for Desktops 4 Workstation Manager agent is activated on a workstation at user login time for Windows 98 systems, and on Windows NT/2000/XP systems, it is activated when the service is started. Once the ZENworks for Desktops 4 Workstation Manager agent is activated, it logs into the tree as the workstation and walks up the tree looking for the first Workstation Policy Package it can find that is associated with the workstation. Like all ZENworks for Desktops 4 agents, the order that the tree is searched is dependent on standard Novell Directory Services behavior and any search policies in the tree. All of the applicable workstation policies are merged and then the culmination is applied to the workstation. If any conflicts occur with the policies (such as two workstation 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 for Desktops 4 enables the administration of specific policies for each platform that is supported in the system. By having a policy that is categorized for each type of platform, the administrator can make unique policies for each system. Regardless of the users who are logged into the system, each workstation finds the policies associated with it and executes the administrative configurations for that platform.
Occasions exist when you might want to associate a particular, unique policy to a set of workstations that are held in containers along with other workstations of the same type. You can then create a group of workstations and associate specific policies to those workstations. Consequently, these workstations receive the policies from this group rather than from the container.
In order to have a Workstation Policy Package, you must first create the policy package. To create a Workstation Policy Package, do the following:
-
Start ConsoleOne.
-
Browse to the container where you want to have the policy package. 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 Workstation Policy 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 it is not filled in, press the browser button next to the field to 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 Workstation Policy Package and press OK.
The following subsections describe each of the fields and property pages that are available in the Workstation Policy Package.
All of the 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 small triangle to the right of the word Policies in the tab. This activates a drop-down menu that enables you to select which platform-specific page you want to display.
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 Workstation Policy Package, you are presented with the Policy Property page. The policy page first displays the general category. All policies activated in the general category are active for all workstation platforms supported by ZENworks for Desktops 4 and associated to the workstation.
Figure 9.1 shows a snapshot of the initial property page of the Workstation Policy Package.
As you can see in Figure 9.1, four policies are available to all of the platforms supported by ZENworks for Desktops 4. They include the Novell iPrint Policy, the Remote Control Policy, the Workstation Imaging Policy, and the ZENworks for Desktops Agent Policy. These, as well as all of the other policies, are discussed later in this chapter.
In order to activate a policy, you simply need to select 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 NT policy page. This page displays the policies that are available for Windows NT workstations, including the Computer Extensible Policies, the Novell iPrint Policy, the Remote Control Policy, the Workstation Imaging Policy, the Workstation Inventory, and the ZENworks for Desktops Agent Policy. See Figure 9.2 for a sample of the Windows NT policies page.
As you can see, the same policies appear on the General and on the Windows NT policies page. When you select a policy in the Windows NT page, it overrides any selections made on the General tab for that platform. The policies are not merged, and only the platform-specific policy is used. For example, if the Workstation Import policy is selected in the General tab and in the Windows NT tab, agents on a Windows 2000 system use the Windows NT Workstation Import policy rather than the policy in the General tab.
Within the policies tab you can select the Windows NT policy page. This page displays the policies that are available for Windows 2000 workstations, including the Computer Extensible Policies, the Novell iPrint Policy, the Remote Control Policy, the Windows Group Policy, the Workstation Imaging Policy, the Workstation Inventory, and the ZENworks for Desktops Agent Policy. See Figure 9.3 for a sample of the Windows 2000 policies page.
As you can see, the same policies are on the General and the Windows 2000 policies page. When you select a policy in the Windows 2000 page, it supercedes any selections made on the General tab. The policies are not merged, and only the platform-specific policy is used. For example, if the Workstation Import policy is selected in the General tab and in the Windows 2000 tab, agents on a Windows 2000 system use the Windows 2000 Workstation Import policy rather than the policy in the General tab.
Within the policies tab, you can select the Windows XP policy page. This page displays the policies that are available for Windows XP workstations. These policies include the Computer Extensible Policies, the Novell iPrint Policy, the Remote Control Policy, the Windows Group Policy, the Workstation Imaging Policy, the Workstation Inventory, and the ZENworks for Desktops Agent Policy. See Figure 9.4 for a sample of the Windows XP policies page.
As you can see, the same policies are on the General and the Windows XP policies page. When you select a policy in the Windows XP page, it supercedes any selections made on the General tab. The policies are not merged, and only the platform-specific policy is used. For example, if the Workstation Import policy is selected in the general tab and in the Windows XP tab, agents on a Windows 2000 system use the Windows XP Workstation Import policy rather than the policy in the General tab.
The WindowsNT-2000-XP tab provides backward-compatibility for workstations using previous versions of ZENworks. If you need to set policies for workstations that are using versions of ZENworks previous to ZENworks for Desktop 4, you need to set these policies using the WindowsNT-2000-XP tab.
The Associations page of the Workstation 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 agents that are associated with users or workstations that are in or below those containers have this policy package enforced. Choosing the Add or Remove buttons enables 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 enable you to specify the rights that users have to this object in the directory. 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 assign objects rights as trustees of the Workstation Policy Package. These trustees have rights to this object or to attributes within this object.
If user admin.novell has been added to the trustee list, this user has some rights to this object. To get into the details of any trustee assignment (in order to modify the assignment), you need to choose the Assigned Rights button.
When you press the Assign Rights button, you are presented with a dialog box that enables you to select [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 the object can have 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 right 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 enables 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 enables the trustee to add him or herself as a member to the list of objects of the attribute. For example, if this right were given on an attribute that contains a list of linked objects, the trustee could add him or herself (a reference to their object) to the list.
If you want to add the object as a trustee to an attribute, you need to press the Add Property button to access 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, and if you give a user or an object 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 this flow of rights down into the tree.
This page enables you to set the IRF (Inheritance 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 to 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 they'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 gets to that object, his write privilege is gone for that object. If the object is a container, the user loses write privileges for all objects in that container or sub-container.
You can effectively remove supervisor privileges from a portion of the tree by setting an IRF with the supervisor privilege turned off. You must be careful to not do this without someone being assigned as the supervisor of that branch of the tree. Otherwise, you won't be able to delete any objects in that branch of the tree. ConsoleOne helps prevent you from performing this action by giving you an error dialog box. You cannot put an IRF on the [Entry Rights] of the object without having first given an explicit supervisor assignment on the same container.
The Effective Rights property page enables 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 to browse throughout the tree and 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 rights box 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. 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, enabling 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 that are currently available in eDirectory. When an attribute is displayed on this page, the editor displays the data and then modifies it should the user click the specific attribute.
For example, if the syntax for an attribute were a string or an integer, an in-line editor is launched, enabling 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 and you are not enabled to change any attribute values that are read-only or 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 enables you to view and set rights for this object on the volumes and 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 enabling you to browse to the volume object; then clicking on the volume object moves you into the file system. You can continue browsing that volume until you select the file or directory to which 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 select the rights that you want to have explicitly granted for the object.
You can also view the effective rights that the object has on the files by pressing the Effective Rights button. This displays a dialog box, enabling 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 who has supervisor rights to the server or volume objects automatically gets supervisor rights in the file system.
Microsoft requires that software packages that bear the Windows approved logo be capable of being configured through .POL files. The poledit program enables you to edit these extensible policies and include them in the system .POL file. ZENworks also enables the policies that are stored in eDirectory to accept these additional extensible polices and provide them to all of the users who are associated with these policies.
The User Extensible policy enables you to import these special .ADM files into the eDirectory tree and administer and disperse them 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 eDirectory tree. These settings are applied like the User System Policies.
The NDS Rights, Other, and Rights to Files and Folders pages are described in the “Setting Up a Workstation Policy Package” section.
When you first bring up the Computer Extensible Policies page, you are presented with the Computer Extensible Policies page. An example of this page is displayed in Figure 9.5.
This page is split into three areas: ADM files, Policies, 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, simply press 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 have 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 ConsoleOne1.2inzenadmfiles directory and they are considered the default packages.
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.
Note
The .ADM file must be stored on a server on which users have access. The policy references the .ADM file and needs to retrieve it to apply it to the users and to enable the administrators to modify the settings. It's recommended, therefore, that you use a UNC path to specify the location of the file.
You delete the .ADM file from the applied set by selecting the file and pressing the Remove button.
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 subsetting categories. Double-click the key in the policies window to populate this details field.
You can browse through the ADM files and turn them on, turn them off, or leave them as set in the Registry as you can in the poledit program. Once you have made your changes, press Apply or OK to update the ADM files on the server.
The Policy Schedule page enables you to customize (outside of the package default schedule) when you want the ADM files applied to the user's workstation/desktop.
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 the various options.
When you choose to have the ADM files applied on an event that occurs in the workstation, you have the additional need to select which event affects the changes.
You can select from one of the following events:
• User Login—This causes the policies to be applied when the user logs into the system. This happens after the users enter their username and password, but before their desktop is shown 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 servers 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 servers only.
• Workstation Is Unlocked—This runs the policies when the workstation becomes unlocked, after the user has supplied a password to unlock the system. This is available with Windows servers 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 need to indicate 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 start and stop times provide a range of time where 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 will retrieve and apply the policy.
You can have the policy also reapplied to each workstation within the timeframe every specified hour/minute/second by clicking the Repeat the Action Every Field and then specifying the time delay. This results in a scheduled action being run on every associated user's workstation for the selected repeat time.
You can alternatively choose that the policies be applied only weekly.
In this screen, you choose which day of the week you want the policy to be applied. You can select only one day at a time. Once you have selected the day, you can also select a time range.
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 which day of the month the policy should be applied or you can select 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.
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.
Select a yearly schedule when you want to apply the policies only once a year.
On this screen 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. This brings up a monthly dialog box where you can browse through the calendar to select the date you want. 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 will come along in the present and future years.
Once you have selected the date, you can also select the time range for the policy.
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 in which they will retrieve and apply the policy.
On each of the scheduling pages you have the option of selecting the Advanced Settings button. It affords you some additional control on the scheduled action that is placed on each user's workstation.
When first displayed, the Completion tab is activated. The following sections describe each field on the tabs and how they relate to the action.
The Completion tab enables you to specify what should happen on the workstation once the scheduled action has completed. You can choose any of the following by selecting the check box next to the appropriate items:
• Disable the Action After Completion—This stops the action from being rescheduled after completion. If you chose to apply the policy every hour, choosing this turns off that action. The policy is not 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 enables the user to be prompted before rebooting. The user can cancel the reboot.
This tab enables 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 the schedule that might have been 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 enable 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 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, as most local users do not have access to the secured portions of the Registry or file system.
• System—This 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 runs the action as a system described above but enables user interaction. This is only available on Windows servers and should be used with care because normally Windows NT does not allow a cross-over between user and system space.
This tab enables 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 it 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 is serviced.
This tab of the scheduled advanced settings enables you to specify how long the service should be allowed to run before it is terminated. This can be used to protect yourself from having the action run for long periods of time on the workstation. Terminating the action, though, might prevent the action from completing properly. Therefore, because you usually want the action to fully complete, this tab is not normally used.
The Novell iPrint Policy is new with ZENworks for Desktops 4 and replaces all previous ZENworks print policies with a single effective, easy-to-use policy. You can control printer access using the iPrint Policy by taking the time to design a set of Workstation Policy Packages specifically organized to provide the correct workstations with access to the correct printers.
The iPrint policy, shown in Figure 9.6, allows you to specify the following options that will define how workstations associated to the workstation package print on your network:
• Client Install Location—Allows you to specify the network location of the iPrint client install you want users associated with this workstation object to use.
• Language—Allows you to specify the language to use when installing the iPrint client.
• Force Install—Forces workstations to install the iPrint client.
• Reboot Option—Forces the workstation to reboot immediately after applying the client install. This allows you to ensure the installation is complete.
• Printer List—Clicking the Add button allows you to add a list of iPrint printers installed on the workstation.
• Force Default—Allows you to force the workstations to use a specific printer as the default. This can be an extremely useful administrative tool when you need to push printing to a specific printer.
A Remote Management Policy is activated for this policy package by selecting the check box on the Remote Management Policy. Once this is selected, this Remote Management Policy is activated for all workstations associated with the Workstation Policy Package.
The Remote Management Policy controls the features of the Remote Management subsystem that is shipped with the ZENworks for Desktops 4 package and is not shipped with the ZENworks Starter Pack. The Remote Management system is comprised of two parts: Remote Management Session Manager, which makes the connection and is used by the administrator, and the Remote Management Agents, which are installed on the user's workstation. The remote control agents can be installed on the workstation when the client that is shipped with ZENworks for Desktops 4 is installed. The agents can be installed on the workstation through the remote control application objects that were added to your tree when you installed ZENworks for Desktops 4. You simply need to associate these application objects to the users or workstations and then have the ZENworks for Desktops 4 Application launcher install these agents automatically on the workstation. For more information, see Chapter 6, “Creating and Using Application Objects.”
The Remote Management system makes a peer-to-peer connection between the administrator's workstation and the remote workstation. This is done using either the IPX or the TCP/IP protocol. In this policy, you 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. The way that you assign the remote control rights is through the Remote Management Rights wizard or in the Workstation object on the Remote Operators page.
The NDS Rights, Other, and Rights to Files and Folders pages are described in the “Setting Up a Workstation Policy Package” section.
The Remote Management page identifies the features that you want to be activated with the Remote Management system. Figure 9.7 shows the Remote Management page.
The following sections describe each of the options available from each tab of the Remote Management policy.
This tab includes general system functions.
• Enable Diagnostics—This allows the agent on the workstations to perform a diagnostics report. This can be done by selecting the workstation and then right-clicking and selecting Actions, Diagnostics from 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 eDirectory 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.
• Display Remote Management Agent Icon to Users—Allows you to specify whether to display an icon in the system tray for users to access remote management, such as viewing remote management operations that are being performed on their workstation or terminating sessions.
This tab describes the feature enabling of 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 in question.
• Prompt User for Permission to Remote Control—This option causes a dialog box to be displayed on the user's machine when a remote control session is started. The user can accept or deny the remote control request. This 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 a periodic tone 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 displays that the workstation is being remote controlled and also displays the eDirectory name of the user who is remote 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, thus 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.
• Enable 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 is ignored.
This tab describes the feature enabling 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 in which the currently logged in user has this policy associated with their user object.
• Prompt User for Permission to Remote View—This option causes a dialog box to be displayed on the user's machine when a remote view session is started. The user can accept or deny the remote view request. Within this dialog box the user is told who wants to remote view their machine. 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 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 also displays the eDirectory name of the user who is remote 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.
This tab describes the feature enabling of the file transfer system. This enables you to send files to the remote workstation.
• Enable File Transfer—When this option is enabled, the file transfer subsystem can be activated.
• Prompt user for permission to transfer files—This option causes a dialog box to be displayed on the user's machine when a remote view session is started. The user can accept or deny the remote view request. Within this dialog box the user is told who wants to remote view their machine. If the user denies the remote view session, the session is terminated and the administrator cannot remote view the workstation.
This tab describes the feature enabling of the remote execute system. This enables you to remotely execute a program on the remote workstation. The output of the program is not displayed on the administrative console.
• Prompt User for Permission to Remote Execute—This option causes a dialog box to be displayed on the user's machine when a remote view session is started. The user can accept or deny the remote view request. Within this dialog box the user is told who wants to remote view their machine. If the user denies the remote view session, the session is terminated and the administrator cannot remote view 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 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.
The Windows 2000 and Windows XP policy pages include the Windows Group Policy. This policy can be applied to a set of workstations that are part of a container of a sub-container in Active Directory.
The Windows 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.
The NDS Rights, Other, and Rights to Files and Folders pages are described in the “Setting Up a Workstation Policy Package” section.
Figure 9.8 displays a sample screen of this policy.
This policy enables you to browse to the group policy ADM file (the default policy file for the Windows 2000 group policy is the default). You can then press the Edit button to launch the poledit program on the local administrator workstation in order to edit this group policy.
ZENworks for Desktops 4 has the capability to image a workstation and then to apply that image back to the original or other workstations. See Chapter 14, “Imaging a Workstation,” for more detailed information on the functionality of the ZENworks for Desktops 4 imaging system.
The placement of an image associated with an Image object in the directory onto a workstation can occur three ways in ZENworks for Desktops 4.
• Booting the workstation with a floppy disk that communicates with the imaging agent on the server.
• Placing a special boot partition on an unregistered workstation that communicates with the imaging agent on the server.
• Placing a special boot partition on a registered workstation and setting the Put an Image On this Workstation on the Next Boot field in the workstation object.
Each of these ways results in the workstation being imaged with the image associated with the workstation or determined by the imaging agent that resides on the server. The way that the workstation finds the imaging server is when the imaging boot diskettes are created, the administrator can specify either an IP or a DNS name for the server. This information is saved on the diskettes or in the special boot partition.
The Workstation Imaging Policy comes into effect if the workstation is to be imaged and there is no image associated with the workstation object and the policy is activated.
This policy enables the administrator to create a set of rules that can govern when a particular image should be used, based on some basic information from the workstation. The imaging server follows the list of rules in the policy until one of the rules is satisfied. The rule that is satisfied results in an associated image that is then applied to the workstation.
This page enables the administrator to input the rules and associated images that the system uses to determine the image to place on a specific type of workstation. Figure 9.9 shows a sample of this page.
You must first press the Add button to add rules to the list. Once you have added several rules, you can then select a specific rule and change its order in the list, look at its properties, or remove the rule. When you choose the Add button, a dialog box appears, in which you add the rule to the policy.
Use the browse button next to the Use this Image field to browse to an image object in the tree that is associated with an image file on the image server. Once the image object is selected, you can identify the rule that is associated with this image. You can currently have six key/value pairs about the workstation to compare in order to determine which image to use.
In the middle of this dialog box, you can see the six potential equations that you can generate to determine whether the image should be used. The equation is made up of a series of True/False statements that are combined with AND and OR logic. You construct the statement by filling in the drop-down statements. (The resulting statement is displayed in a more English-like view to help you understand the equation.)
The logic for the AND and OR operators is strictly left to right in the equation. In the Rule Description box, parentheses are added to the equation to help the administrator understand how the rule is evaluated. You cannot insert the parentheses; they are automatically inserted and are not under user control.
Select the key you want to examine via a drop-down dialog box. The keys that you can choose from are the following:
• Chipset—This displays the reported processor. An example is GenuineIntel Mobile Pentium MMX 233 MHZ.
• Video—This option captures the type of video adapter that is in the workstation. An example of this is Trident Cyber9397 (rev 243).
• Network—This is the network adapter for the workstation. An example is “3Com.”
• Sound Card—This is the sound card that has been reported. Often this field results in no sound card detected. This is because the system sends out a PCI request and, if no sound cards respond, you get this even if a sound card is present.
• Hard Drive Controller—This is the type of hard drive in the system. If the hard drive is an IDE device, the value for this field is IDE. If the hard drive is a SCSI device, you get the reported name of the device, such as FUJITSU MHJ2181AT.
• MAC Address—This is the MAC address of the network card. An example of this value is 00 60 80 03 C2 E7.
• IP Address—This is the assigned IP address of the workstation. This is reported as the traditional 137.65.237.5.
• Hard Drive Size—This reports the disk size in megabytes. Therefore an 8GB hard drive is reported as 8192MB in this field. The imaging system might not always report the full disk capacity. It's best to use a wide boundary when generating your rules. For instance, if you want to look for an 8GB drive, use the statement Hard drive size > 8000MB.
• RAM—This is the reported amount of RAM in megabytes. This field also might not always report the exact amount of RAM space that you would expect on your workstation. It is advisable that you use a wide boundary when generating your rules, as in the previous field.
When the workstation is booting the imaging system, it is in reality booting up the Linux operating system and running the tools that are included in the imaging system. The values for the keys described previously are values that the Linux system can report to the software. In order to discover what a system reports to Linux, you need to boot a sample workstation with the Imaging system boot disk and run the Img information command. This displays the information that is sent to the image server about the workstation. This information includes the data values that you put into the key comparison equations for your rules. You can also get this information from an image by opening the image in the ZENworks image editor and choosing properties on the image root. See Chapter 14, for more detailed information on the functionality of the ZENworks for Desktops 4 imaging system.
The next step of the equation involves specifying the operator. Two types of operators exist: String and Integer operators. The Hard drive size and RAM fields are treated as integers, whereas all of the other fields are treated as strings. A case-insensitive string compare is performed to determine operator results. The string operators are contains, doesn't contain, begins with, and equals. The integer operators are =, <>, >, >=, <, and <=.
These operators perform expected comparisons between the key value supplied by the workstation to the imaging server and the value that you place into the value field of the equation. The following meanings are placed with each operator:
• contains—The specified value is a substring anywhere in the reported value.
• doesn't contain—The specified value is not equal to or contained in the reported value.
• begins with—The specified values are represented in the initial character of the reported value.
• equals—The specified value is the same as the reported value.
• = (equals)—The specified value is numerically equivalent to the reported value.
• <> (not equal)—The specified value is not equal to the reported value.
• > (greater than)—The specified value is greater than the reported value.
• >= (greater than or equal to)—The specified value is numerically equal or greater than the reported value.
• < (less than)—The specified value is less than the reported value.
• <= (less than or equal to)—The specified value is numerically less than or equal to the reported value.
The next field in the operation is where you enter the value that you want to compare. The far right field enables you to extend the operation to additional key/value comparisons. Your choices currently are AND and OR.
The Boolean operators are evaluated strictly from left to right. For example if the following rules were entered into the policy:
-
Hard drive size >= 600MB AND -
RAM < 16MB OR -
RAM > 31MB
The resultant evaluation would be (Hard drive < 60MB AND RAM < 16 MB) OR (RAM > 31MB). This would result in giving the image to any system that has a disk smaller than 200MB with less than 16MB of RAM. This would also give the image to any system that has more than 31MB of RAM regardless of the size of the hard drive.
You can view the precedence of the equation; complete with parentheses, on the bottom half of the screen as you introduce new key/value pairs into your rule.
Once your set of key/value pairs have been entered and you have reviewed your equation at the bottom of the screen, you press the OK button to include the rule into the imaging system. You are returned to the original Rules page with the rule that you had entered placed on the screen.
Once again, from this page, after you have entered some rules you can then specify the order in which the rules are evaluated. After selecting a rule you can move that rule in the order by pressing either the Move Up or the Move Down buttons. As the imaging server is evaluating the rules, the first rule that results in a TRUE evaluation results in that imaging being supplied to the workstation.
The ZENworks for Desktops 4 Workstation Inventory Policy page allows you to configure how workstations associated with this Workstation Policy Package are inventoried.
See Chapter 13, “Using ZENworks Workstation Inventory,” for more detailed information about the inventory system with ZENworks for Desktops 4.
With the Workstation Inventory policy you identify where the collector of the inventory information is located, whether hardware or software scanning is done, and the capability to customize the scan list to identify programs without an identifying header. The NDS Rights, Other, and Rights to Files and Folders pages are described in the “Setting Up a Workstation Policy Package” section earlier in this chapter.
Figure 9.10 displays the Workstation Inventory page of the Workstation Inventory Policy.
Within the inventory policy, the administrator can administer the following parameters:
• Inventory Service—This field represents the service object in the tree that represents the service module running on a server in the network. This server agent is responsible for receiving the information from the workstations and processing it, either by placing it in a local Sybase database, or forwarding it on to the next level of the inventory database hierarchy (see Chapter 12, “Creating a Server Policy Package”). All workstations that have this policy associated with them send their scanned information to the specified server agent.
• Hardware Scanning—This field allows you to enable DMI, WMI, and custom scanning as well as configure the custom attributes to scan for.
• Software Scanning: Enable software scan—This field turns on ZENworks for Desktops 4 agents to perform a software scan in addition to the standard hardware scan.
• Software Scanning: Custom Scan Editor button—Pressing this button brings up a dialog box that enables you to configure information about files found on a workstation. You can store the Vendor Name, Product Name, Product Version, File name, and File size in this list. When a file does not have header information, it is found in this table (by filename and size) and reported as the specified program. You can export and import these file lists into the eDirectory policy object.
• Configuration Editor—Allows you to import, export, and modify custom scanning configuration settings, such as ZIP file extensions to scan for, vendor and product rules, and asset information.
This schedule determines when the hardware and software inventories for associated workstations are run. See the “Computer Extensible Policy” section for a description of this page.
The ZENworks for Desktops Agent is one of the most dynamic features of ZENworks for Desktops 4 because it enables you to maintain workstations that do not have the Novell Client installed on them. The ZENworks for Desktops Agent policy, shown in Figure 9.11, enables you to configure the following settings, which the agent running on workstations associated with the Workstation Policy Package will use:
• Webserver IP Address or DNS Name—Specifies the IP address or DNS name for the Web server that is running on the middle tiered server that the ZENworks for Desktops agent will use to connect the workstation to the network.
• eDirectory Refresh Rate—Specifies the amount of time in minutes that the ZENworks for Desktops agent will wait before checking eDirectory for changes in objects of policies. The default is 540 minutes. Each time the agent refreshes eDirectory information, traffic is generated on your network, so if you have a large number of workstations connecting through the agent you might need to make this a larger number.
• Enable Login—Allows you to specify whether the Novell Login windows is displayed when workstations running the ZENworks for Desktops agent are started.
• Enable Volatile Cache—When checked, this option allows volatile user information that has been cached on a workstation to stay cached on the workstation for the specified period of time. The default time is five days. Because volatile users are not created or removed at every login or logout, this makes login times much faster and makes it possible for a user to continue using the workstation even when the workstation is disconnected from the network and the user is not a registered user on the workstation.
• Resident Workstation Welcome Bitmap—Specifies the name of a bitmap file, located in the WINNT directory of the workstation, that appears on the welcome screen when you start Windows NT/2000/XP. The default is blank (no bitmap).
• Welcome Caption—This field allows you to specify the caption that is displayed in the header of the welcome screen when you start Windows NT/2000/XP.
The Scheduled Action policy is a plural policy that enables you to specify one or more actions to perform on workstations associated with the Workstation Policy Package based on the policies schedule. Because it is a plural policy, you can create as many Scheduled Action policies for each platform in the Workstation Policy Package as you need.
For example, if you needed all of your DNS/DHCP clients to refresh their IP configuration every day at 8:00 a.m., you could create a Scheduled Action policy that runs the IPCONFIG utility twice, once with the /release parameter and once with the /renew parameter. Then, you would set the policy schedule to run daily at 8:00 a.m.
You create a Scheduled Action policy by going to the package you desire and pressing the Add button on the policies tab. This will bring up a dialog box that lists the available plural policies. Schedule Action policy will be one of them. Enter a policy name and press OK to add the policy to the package.
From the Scheduled Action Policy window Actions tab, shown in Figure 9.12, you can configure the following for each action by clicking the Add or Properties button:
• Name—Full pathname to the application that will be executed on the workstation.
• Working Directory—The working directory the policy will use when applying the action.
• Parameters—Command-line parameters that are added to the command line when the action is executed.
• Priority—Specifies the priority assigned to this action when compared to the priority of the user's access to the workstation. You can specify a priority of Action Default, Above Normal, Normal, and Below Normal. Setting the priority to Above Normal helps ensure that the action is performed quickly on the workstation no matter what the user is doing. Setting the priority to Below Normal will impact the user on the workstation less. For example, you should take into account this priority balance when scheduling actions. You might want to create one Scheduled Action policy for high priority actions and one for low priority ones.
• Termination Time—Specifies the amount of time in minutes that the application can run on the workstation before the policy will force its termination. The default is 1 minute. This can be extremely useful in protecting users from experiencing too big of a performance hit by the scheduled action. It can also be useful when ensuring that all of the actions in the policy can run.
You can also disable an individual action by selecting it and clicking the Disable button, as shown in Figure 9.12. This allows you to keep the action and its setting available for future use but not execute it the next time the policy schedule is reached.
The final setting you have on the Actions tab of the Scheduled actions policy is the Run Items in Order Listed option, shown in Figure 9.12. This option forces the actions to run one at a time in the order that they are listed in the Actions list. This can be extremely useful when you need to run a set of actions in a specific order. The Move Up and Move Down buttons allow you to change the order of the actions, if necessary.
