Understanding Workstation Management Components and Features
Workstation Management features are designed to help you reduce the overall cost and complexity of configuring and maintaining workstation desktops in the network. Such inventory information as hard disk space, machine memory, and processes running can be pushed up to NDS® Workstation objects from the ZfD components pushed down to each network workstation.
The following sections provide information on components and features:
The workstation resident modules authenticate the user to the workstation (Windows* NT* only) and network, and transfer configuration information to and from NDS. Under Windows NT, Workstation Management runs with administrative privileges that allow it to dynamically create and delete NT user accounts, provided it can communicate with NDS.
ConsoleOne Snap-ins
The snap-ins are Java* files that are used to create, view, and configure the various Workstation Management NDS objects through ConsoleOne.
Features
Workstation Management features let you store and configure Windows 95/98 and Windows NT/2000 desktop policies in NDS and push them down to the client. You can also push printer drivers to the client. The client workstation can be thought of as an extension of the user.
Workstation Management has the following features:
Workstation Management software allows all user account and desktop information for Windows 95/98 and Windows NT/2000 to be centrally managed within NDS using a single administrative utility: ConsoleOne.
Configuration information is stored in policy package objects that are particular to a platform. For example, there are policy package objects containing policies for NetWare®, Windows 95/98, and Windows NT/2000 that can be downloaded to the workstations.
Windows NT/2000 Support
For Windows NT environments, Workstation Management also eliminates the need for NT domains or for a large number of NT user accounts to reside in the local Security Access Manager (SAM) of each workstation.
The Windows 2000 Group policy is an extension of extensible policies for Windows 2000 and Active Directory*.
Workstation Management stores user information, desktop configuration, OS configuration, and workstation information in NDS. For NT users, this means that when a user's NDS user account is associated with this configuration information, the user can access the network using any NT workstation configured with Workstation Management.
If the user does not have an account on the workstation at the time of login, Workstation Management can automatically create one according to the associated user information. Once the user is attached to the network, associated policies are downloaded to the workstation to provide a consistent desktop on each workstation used.
Novell Client Configuration
You can configure settings specific to the Novell® ClientTM, such as the name context and preferred tree in NDS, then have that configuration rolled out to multiple workstations on the network.
Workstation Profile Management
You can create and manage mandatory user profiles, and you can control user interface options, such as the command console, display control, keyboard control, mouse control, and sound control attributes. Once you have set these attributes, users cannot modify these settings unless they are given the appropriate NDS rights.
Scheduled Updates
This feature lets you schedule software upgrades to occur for workstations at a specific time, such as during the evening when the workstation is not in use. These updates can be done without requiring users to be logged in to the network from the workstation. As long as the workstation is powered on, Workstation Management can authenticate the workstation to NDS and perform the update.
Server and Client Policies
ZfD uses policies for hands-off management of server and client processes. Policies can be set for automating workstation import and removal, managing users and workstations, and providing workstation inventory information.
NDS Storage for Policies
Workstation Management lets you create policies using ConsoleOne instead of the Microsoft* POLEDIT utility. This approach to creating policies provides three specific benefits:
It eliminates the requirement that you copy the policy file to the SYS:\PUBLIC directory of each NetWare server on the network, thus reducing your initial setup workload.
Because the policy is stored in NDS, you only have to make changes once.
Any change you make to a policy is automatically replicated across the network in a multiple-partition NDS network, thus providing automatic fault tolerance.
Dynamic Printer Configurations
Using ConsoleOne, you can configure printing for users without ever leaving your office. You can associate a print queue and its associated print driver with Workstation or User objects. Then, when the user authenticates to NDS, the printer configuration is dynamically created on the user's workstation and the printer driver is automatically downloaded and installed.
ZfD Reports
ZfD provides predefined reports for effective policies and policy package associations. The scope of both reports is for a selected container and, optionally, its subcontainers.
The effective policies report provides the following information:
Version
Tree
Container
Object DN
Platform
Effective Policy DN
The policy package report provides the following information:
Tree
Container
Package DN
Association
The report results are displayed in Notepad and are automatically saved as text files in the \WINDOWS\TEMP directory of the workstation where you are running ConsoleOne.
Understanding the ZENworks Database
The ZENworks database is used for logging report information for ZfD. Therefore, to run reports on Workstation Management, you will need a configured Database object with an associated ZENworks Database policy.
If you selected to install the ZENworks database during installation of ZfD, you should configure and enable the ZENworks Database policy to identify the location of the ZENworks Database object, which knows the location of the database file (MGMTDB.DB).
If you are using a Sybase* database, the Database object will be created during installation if you selected the Inventory option. The Database object will then contain default values. If you did not select the Inventory option, you will need to create the Database object and configure the properties to populate it with default values. In either case, you will still need to edit the Database object properties to fill in the User Name and Password fields to secure the database file because this information cannot be automatically populated.
If you are using an Oracle* database, you will need to create and configure the Database object. Although the database files may have been installed, the Database object will not have been created.
Understanding ZfD Policies and Policy Packages
To fully deploy ZfD Workstation Management, you must configure, enable, and associate the necessary policies and policy packages in ConsoleOne.
Review the following sections for an understanding of ZfD policies and policy packages:
A policy package is an NDS object that contains policies, which are properties in the package object. ZfD policies are grouped into policy packages for ease of administration. You create and manage policy packages using ConsoleOne.
Each policy package contains one or more platform-specific tabs that contain one or more policies specific to that platform and package. One of the platform pages can be labeled General.
A policy package has a Policies tab that contains several pages. These pages each identify an operating platform, such as General, NetWare, or Windows (95-98 or NT-2000). Any policy that you enable on a General page applies generally to all platforms indicated by the other pages. However, any policy configurations you set on a specific platform page will override similar settings on the General page.
The ZfD policy packages are:
Container Package
Server Package
Service Location Package
User Package
Workstation Package
The Container Package and Service Location Package are identical to the policy packages used in ZENworks for Servers (ZfS). The Server Package also exists in ZfS; however, in ZfD it contains different polices. The User Package and Workstation Package are unique to ZfD.
Understanding ZfD Policies
ZfD policies provide you with automated management of server, user, and workstation configurations, processes, and behaviors. For example, policies can define the following:
Parameters for importing workstation objects to the tree
Locations to search for effective policies
Login restrictions
Desktop preferences for users
Help desk parameters for users
Dynamic printer definitions
Dial-up networking parameters
Parameters for remotely controlling a workstation
Event and action scheduling
Each policy's properties contains one or more tabs where you can specify settings or configurations related to User, Workstation, Group, or container objects, depending on the type of policy.
ZfD has one plural policy with the default name of Scheduled Action. Plural policies allow you to have multiple instances of the same policy type within the same policy package.
Because you can have several different actions that you might want to run on different schedules, when you add a Scheduled Action policy to the policy package you should name it to reflect the action being scheduled.
For ZfD, the Scheduled Action plural policy is available for all platforms in the User Package and Workstation Package.
Understanding Enabling of Policies
As your Workstation Management needs change, you can enable, disable, or modify a policy using any of the three states for policy settings:
Check Box
State
Description
Enabled
Activates the policy's settings; however, they are not enforced unless the policy package is also associated with an object.
Disabled
Clears a policy. However, disabling a policy in ConsoleOne does not immediately clear its effect at the workstation. The workstation will run the policy with the cleared settings because the settings for each policy are saved in the workstation's registry.
or
Ignored
Does not guarantee the clearing or enabling of a policy, because it will allow the workstation to continue with whichever policy setting it previously had.
When you create a policy package, its policies are disabled by default. Once you enable a policy, some default settings will be in place.
A policy can be enabled when you:
Create a policy package
Modify a policy package
A policy can also be enabled anytime from within most of the lists where the policy is displayed.
Understanding Policy Scheduling
Some policies can be scheduled to run at a certain time. During creation, all policy packages are given a default run schedule. This means that all applicable policies in this package will run according to the default schedule. However, you can change the entire policy package schedule, or you can set a policy within the package to run at a different time from the rest of the package.
If you should enable a policy but fail to schedule it, it will run according to the schedule currently defined in the Default Package Schedule.
Understanding Policy Package Associations
Once you have enabled a policy, you must then associate it to make it effective. Configuring, enabling, and scheduling a policy only sets it up. A policy is enforced through its association with an NDS object, such as a Server, User, Group, or Workstation object.
Because policy package associations flow down a tree like Inherited Rights do in NDS, you can associate a policy package directly with an object. You can also associate a policy package indirectly, such as with the object's parent container.
When you view the associated policy packages for an object, ZfD starts at the object and searches up the tree in the following order for the associated policy packages to be displayed:
The object
Any Group where the object has membership
Any container above the object up to [Root]
Similar to assigning different rights for different users in NDS, you can set a general policy for most users and unique policies for unique users.
You must have the Write right to both the policy package and the object in order to associate one with the another.
You can associate a policy package with Server, User, Group, or Workstation objects when you:
Create or modify the policy package
Create or modify the Server, User, or Workstation objects
Associate a policy package with a group or container where the User or Workstation objects have membership
Understanding the Search Policy
The Search policy is used to prevent tree-walking. Unless specified differently in a Search policy, when ZfD starts searching for an object's associated policy packages, it starts at the object and works its way up the tree. If ZfD does not have any Search policies defined, it will walk the tree until if finds an effective policy for the object. This can cause unnecessary network traffic. Therefore, plan to use Search policies wherever needed.
All enabled policies in a policy package that is associated directly with an object have precedence over contradicting policies in policy packages higher in the tree.
Effective policies for an NDS object are those that have been configured, enabled, and associated with the object. Just as the effective rights in NDS flow down the tree, policy package associations also flow down the tree.
ZfD and ZENworks 2 policies can both be associated with the same object. However, which policy is effective depends on the version of the Novell Client that is being used by the workstation and if the proper Search policies have been set up.
The following sections provide more information on effective policies:
When ZfD calculates the effective policies for an object, it starts with all policy packages assigned to that object. It then looks up the tree (assuming that the search order starts at the leaf object and goes up towards the root of the tree) for associations made to parent containers. The first enabled policy it finds is the one it uses, just as the system looks up the tree for effective rights.
How Package Associations Are Resolved to Determine Effective Policies
Because ZfD policies provide management-by-exception through policy package associations, a lower package association overrides an upper package association. In other words, a package associated to a User object overrides any similar settings in a package associated to the user's container object.
The following illustrates policy package associations:
Suppose that in this illustration, User Package 1 contains three enabled policies: Desktop Preferences, Help Desk, and Remote Control. User Package 2 contains one enabled policy: Desktop Preferences. For the User object, the Desktop Preferences policy settings in User Package 2 will override the similar policy settings in User Package 1.
The effective policies for the user are the Desktop Preferences policy in Policy Package 2 and the Help Desk and Remote Control policies in Policy Package 1. The Associations tab for this User object will list the one policy in User Package 2 that has been enabled. The two enabled policies in User Package 1 will also be listed on the User object's Associations tab. In other words, effective policies are the sum of all enabled policies in all policy packages associated directly or indirectly to an object.
How Effective Policies Work When ZfD and ZENworks 2 Policies Coexist in the Tree
If an object is associated with policies from both ZfD and ZENworks 2, the policy that is effective for the object depends on the schema extension version, the associated Search policy version, and the version of the Novell Client that is used by the workstation. The ZfD version of the client must be used to recognize ZfD policies. The following discussion is concerned with the possibilities from various combinations of the schema and Search policy versions.
ConsoleOne will display only the effective policies in an object's properties for ZfD policies. To view the effective policies for ZENworks 2 policies, you must use NetWare Administrator. However, in some instances ZfD reporting can show effective policies for an object for both versions.
The following table lists the policy version that is effective for the item listed in the first column according to the combination of the schema and Search policy versions listed in the column headings.
Item
Schema=v2, Search Policy=v2
Schema=v3, Search Policy=v2
Schema=v3, Search Policy=v3
Policies Actually Effective for ZfD Workstations
ZENworks 2
ZENworks 2
ZfD
ConsoleOne Snap-in for ZfD
N/A
ZfD
ZfD
Effective Policies Report for ZfD
ZENworks 2
ZENworks 2 and ZfD
ZENworks 2 and ZfD
Policies Actually Effective for ZENworks 2 Workstations
ZENworks 2
ZENworks 2
ZENworks 2
NetWare Administrator Snap-in for ZEnworks 2
ZENworks 2
ZENworks 2
ZENworks 2
Note the following from this table:
The two Policies Actually Effective rows mean that the workstations are running their respective versions of the client. In other words, a ZENworks 2 workstation is not running the ZfD version of the client.
The Policies Actually Effective For ZfD Workstations row indicates that until a ZfD Search policy has been associated with the object, any associated ZfD policies will not be in effect, although they could be displayed in some ConsoleOne object's properties as if they were.
The ConsoleOne Snap-ins for ZfD row indicates that for the ZfD version of the client there are no effective policies for an object when the schema and associated Search policy are both ZENworks 2.
The Effective Policies Report for ZfD row indicates that there are two instances when the effective policies report for ZfD can show the effective policies for an object for both versions. In all cases for the report, any policies that could be effective or have been associated are displayed. However, because ZfD is combing NDS and not pinging each client to build the report, it cannot indicate which policies are actually in effect.
In the NetWare Administrator Snap-in for ZENworks 2 row, ZENworks 2 in the last column assumes that it existed when ZfD was installed. Otherwise, that entry would be N/A.
Understanding Extensible Policies
For any software program, an extensible policy allows you to control any application function that is configured in the Windows registry. Extensible policies are user-defined. ZfD lets you easily customize and deploy extensible policies across your network to accommodate your specific business practices.
ZfD leverages Microsoft desktop enhancements by doing the following to provide extensible policies that are enabled in NDS:
Moving the policy editor functionality into NDS
Moving Windows registry information for applications into NDS
Enabling NDS to point to extensible policy files
How Extensible Policies Work
When you install a software application that is Windows 95/98 compatible, that application's installation program uses the Microsoft policy editor (POLEDIT.EXE) to read the application's .ADM file and create a .POL file that updates the workstation's Windows registry. However, when you install an application on a workstation under the umbrella of ZfD, the Novell ZENworks policy editor (WMPOLSNP.EXE) is used instead to read the .ADM file and make the necessary changes to the workstation's Windows registry.
The Microsoft policy editor lets you make changes to the policies .ADM files create, but only per workstation. The ZENworks policy editor, when an application is installed under ZfD, ensures that the application's DNS-enabled policies are automatically applied across the network, rather than manually to one workstation at a time.
When you create an extensible policy, you must schedule it to run before it can take effect. Note that some hard-coded policies are run explicitly at login. Such policies are not scheduled.
ADM Files
The .ADM files are static templates for creating policies in the ZfD database. When you edit a policy in ZfD, the changes are made in the database rather than the .ADM file. Even so, you should not delete an .ADM file from a directory once it has been used in ZfD because it will be needed to undo registry changes if you should remove the policy from ZfD.
When you have .ADM files that you want to use, you should place them in a location where you will be able to easily browse for them. You can save them on a workstation or on a server, because once the .ADM file has been used to create a policy, it will not be needed again until you remove the policy.
Because ZfD automatically displays any policies listed in the following location when you view an Extensible Policies tab, we recommend that you use it:
SYS:\PUBLIC\MGMT\CONSOLEONE\1.2\BIN\ZEN\ADM Files
This is the default location where .ADM files shipped with ZfD are placed.
Determining the Necessary Policies
To use the ZfD features, you must create policy packages and configure and enable the needed policies. ZfD provides policies in the following five policy packages. Review these sections and determine which policies are needed.
The Container Package has only one policy: Search. It is used to limit how far up the tree ZfD will search for the effective policies.
The Search policy provides the following benefits:
Improved security
The ability to reorder a search
Better search performance by limiting the search levels traversed in NDS and by avoiding unnecessary LAN traffic
The Search policy locates policy packages that are associated with containers. To make a Search policy effective you can associate it only with a container. The container you associated it with provides the location from where the search begins.
You can specify the number of levels above or below the location where to begin the search:
Number
Description
0
Limits the search to the selected level.
1
Limits the search to one level above the selected level.
For example, if you selected the server's parent container, this would limit the search to one level above the parent level.
-1
Limits the search to one level below the selected level.
For example, if you selected [Root], -1 would limit the search to one level below [Root].
Without a Search policy in effect, the default is to search from the parent container clear to [Root] hourly. The search checks each container up the tree towards [Root] for policy packages associated with those containers.
The default Search policy will recognize the policy package associated with the User or Workstation object before it will look in any group or container where such an object resides.
The default search order, Object > Group > Container > Root, can be reordered and can include as few as one of the locations. For instance, you can exclude Group objects by setting the search order to Object > Container > Root.
You can avoid unnecessary LAN traffic by searching to the partition instead of [Root].
When you view the associated policy packages for an object, by default ZfD starts at the object and searches up the tree to [Root] for all policy packages associated with:
The object
Any Group where the object has membership
Any of the object's parent containers
The first enabled policy package found is used.
Server Package
The Server Package has four policies that are used for ZfD server functions. These policies are duplicated on each of the platform pages of the Policies tab:
This policy sets rules that determine which images to put on workstations that are imaged by this policy. For more information, see Workstation Imaging. For more information on setting up this policy, see Setting Up the Imaging Server Policy.
This policy sets parameters to control automatic workstation importing. It must be enabled for Automatic Workstation Import to function.
You can set rules on how Workstation objects are named and where they are created. You should decide if you want to create Workstation objects in their own containers or in the container where the User objects reside.
You may find it easiest to manage Workstation objects in a common container if your User objects are scattered among various containers in the tree.
You may also find it easiest to keep User and Workstation objects in the same container. This will minimize the number of policies you must create and associate for using all of the ZfD features.
This policy sets the IP address of the relay host that processes outbound Internet e-mail. It must be enabled if the e-mail option for notifying or logging is selected in another policy. For more information on setting up this policy, see Setting Up the SMTP Host Policy.
SNMP Trap Targets
This policy sets SNMP trap targets for associated NDS objects.
Part of setting SNMP trap targets is to create trouble tickets. When users open a Help Requester trouble ticket, they select a subject from a drop-down list. You can use the Trouble Ticket Subject Lines dialog box to create a list of subject lines from which users can choose.
When users create a trouble ticket, it is sent to the help contact (as selected in the Help Desk policy) as an e-mail message. Carefully chosen subject lines can aid the help contact in organizing trouble tickets.
This policy sets the DN for locating the ZENworks Database object. This allows ZfD to log information in the database file for ZfD reporting. For more information on setting up this policy, see Setting Up the ZENworks Database Policy.
User Package
The User Package has a Policies tab that has three pages (General, WinNT-2000, and Win95-98). User policies are listed under each of the pages. The policies found on the various pages are:
For the Windows 95/98 and Windows NT/2000 platforms, this policy sets defaults for users' desktops. For more information on setting up this policy, see Setting Up the Desktop Preferences Policy.
Dynamic Local User
For Windows NT/2000, this policy lets you configure users created on a Windows NT/2000 workstation after they have authenticated to NDS.
A Dynamic Local User (DLU) is a User object that the Novell Client temporarily or permanently creates in the workstation's Security Access Manager (SAM) database.
A temporary user or account is known as a volatile user, and the duration is determined by the administrator. This type of account prevents the SAM from becoming too large.
If a user is not defined as a DLU and does not have an account on the workstation, the Novell Client cannot create the user's account. Therefore, the user cannot log in to the workstation, unless there is a previous account, or the administrator manually creates the user's account on the workstation. If the user is not defined as a DLU, the Novell Client uses the user's credentials from the Windows NT tab of the login dialog box to authenticate to the workstation.
If the user is defined as a DLU, the Novell Client uses the user's credentials from NDS or from the WinNT User Package, depending on how the administrator sets it up.
If you configure a DLU in an NT User Policy Package to administer user access to NT workstations, and if you use a credential set other than the NetWare credential set, the NT workstation user accounts created have a random, unknown password and are created as volatile user accounts. If volatile user caching is also enabled, the NT user accounts will persist on the workstation for the duration of the cache life. However, these accounts are inaccessible because they have an unknown password.
If you use volatile user caching for users with non-NetWare credential sets, those NT user accounts will not be accessible unless the users log in to NDS concurrently and have the Manage Existing Accounts option set.
You can allow or restrict DLU login access to certain workstations by using the Login Restrictions page. Workstations and containers listed in the Excluded Workstation list cannot use DLU access; workstations listed or workstations that are part of containers listed in the Included Workstations list can use DLU access.
To properly manage group priorities, do not allow users associated with DLUs to be members of multiple groups.
This policy sets the choices viewed in the Help Desk user interface. It lets you collect help requests from users in a consistent manner. It also allows you to specify whether a help request can be sent through e-mail. This policy is found on each of the platform pages.
Setting up a Help Desk policy for your users provides you with pertinent user information, such as user context or network address, with little effort required from the user. This policy can be associated with a User, Group, or container object.
When users or members of the group or container associated with that policy run the Help Requester on the workstation, they can send a request for help through e-mail. By selecting a problem category to display in the e-mail subject line and then entering a message, they will access support contact information, such as an e-mail address or phone number, and will be able to view information specific to their workstations.
For example, Kim is a network administrator who set up a Help Desk Policy for Joe and other users in Joe's group. Kim added three items to the Subject drop-down list: Server problem, Application problem, and Hardware problem. Kim also decided that she wanted the group's help requests to be e-mailed to her, so she placed her e-mail address in the Contact information.
Joe can't access a spreadsheet program, so he contacts the help desk by using the following steps:
1. Runs Help Requester on his workstation.
2. Selects "Application problem" as the subject of his help request.
3. Enters the message "My spreadsheet program won't open."
4. Clicks Send.
The next time Kim checks her e-mail she has a message from Joe with "Application problem" in the subject line. When Kim opens the e-mail, she sees all the pertinent information about the workstation, the user, and the problem.
For Windows NT/2000, this policy displays a list of the currently installed printers. It lets you add printers to the list, remove printers from the list, select a printer as the default, and assign a print driver to each printer. In addition, you can identify the settings for network printers.
This policy sets parameters for managing remote user functions, such as whether to prompt users for permission to remotely control their workstations. This policy is found on each of the platform pages.
This policy sets schedules for specific actions. This is a plural policy, meaning it can be added many times to the policy package. It is available for each of the platform pages.
This ZENworks 2 policy is now incorporated in extensible policies. If you migrate your ZENworks 2 policies, the User System policy will exist in the User Package; however, it cannot be edited---it can only be enabled or disabled. To change its settings you would need to use an extensible policy.
Only for Windows 2000, this policy is an extension of extensible policies for Windows 2000 and Active Directory.
For the following reasons, you will need to use UNC paths rather than mapped drives for importing this policy to ZfD:
Users could change their login scripts, altering drive mappings
Workstation objects are often logged in before users are; therefore, there are no drive mappings available
With UNC paths, as long as the server is available, the policy will be found.
Group policies have changed significantly since the ZfD version 3 initial release. Group policies are now additive, they check for revisions, they cache already-processed policies, and they use persistent or volatile settings. Review the following sections for more information:
Additive Group Policies: Group policies are now additive. This means that settings from multiple Group policies are cumulatively effective, rather than individually. Settings from multiple Group policies can affect users and workstations. Policies start with the local Group policy settings and are applied in reverse of the policy search order. This means that a setting in a policy applied first has lowest priority and its value is overwritten by any other policy with the same setting.
Security settings are not additive; they are set by the last effective policy.
Revision Checking: Group policies now track the revision of the policies in effect. As long as the list of effective policies and their revisions remains the same, Group policies are not processed, but use the cached Group policy.
NOTE: Each time the Edit Policies button is clicked, the revision of a Group policy changes, causing the policies to be reprocessed.
Group Policy Caching: The last-processed Group policy is cached locally. This helps reduce network traffic by processing Group policies only if necessary. If UserA logs in on a new machine, his or her effective Group policies are processed and then cached.
If UserA logs out and UserB logs in, and if UserB has the same effective Group policies as UserA, the locally-cached Group policy is restored instead of reprocessing Group policies. If the list of effective policies is different or if the revision is changed on any policy, the Group policies are reprocessed.
Persistent and Volatile SettingsThe administrator determines if Group policies are persistent or volatile. The persistent setting indicates that when the Group Polices are set, they remain set---even if a user happens to log in only to a workstation and not to the network.
The volatile setting indicates that the original local Group policy settings will be restored when:
The user logs out (user settings are restored)
The system shuts down (workstation settings are restored)
The Workstation package has a Policies tab that has three pages (General, WinNT-2000, and Win95-98). Workstation policies are listed under each of the pages. The policies found on the various pages are:
This policy sets workstation parameters for printing. It is found only on the WinNT-2000 and Win95-98 pages.
The printer feature lets you dynamically create printer access when a user logs in to the network or at any other time you determine it necessary. Once you configure and assign printer access, the printer icon is displayed on the workstation's desktop.
Only printers that are QMS-compatible can take advantage of this Workstation Management feature.
You can assign printers to users or workstations.
You make printer assignments to users from the Printer Policy Details page of the User Package associated with the User object. When assigned to users, printers follow the user. Regardless of which workstation the user accesses to log in to the network, the printer icon is displayed on the desktop of the workstation from which the user logs in.
You make printer assignments to workstations from the Printer Policy Details page of the Workstation Package associated with the Workstation object. When they are assigned to the workstation, printers remain with the workstation, and the printer icon is displayed on that workstation desktop regardless of which user logs in to the network from that workstation.
To enable this feature you must:
1. Enable the Printer Policy in the appropriate User or Workstation Package.
2. Set up and configure the printer.
3. Associate the User or Workstation Packages with User or Workstation objects.
This ZENworks 2 policy is now incorporated in extensible policies. If you migrate your ZENworks 2 policies, the migrated Computer System policy will exist in the Workstation Package; however, it cannot be edited---it can only be enabled or disabled. To change its settings you would need to use an extensible policy.
This policy sets dial-up networking parameters.It is found only on the WinNT-2000 and Win95-98 pages.
The Dial-Up Networking page lets you dial into a network and establish a connection before any action item is executed.
The number to dial or phone book entry to be applied to the workstations represented by the Workstation object are defined via ConsoleOne.
If a connection is not successful, the action will be rescheduled according to the options selected in the Options page of the Scheduled Action's properties. That is, the action will be considered as unsuccessful.
After they are downloaded to the workstation, the dial-up entries can be seen via the Dial-Up tab of the workstation Scheduler. The entries are downloaded when the workstation is used to log in to the network or when the administrator schedules a download.
The Dial-Up Networking page lets you:
Select a dial-up number
Create a new dial-up entry
Edit a dial-up entry
Delete a dial-up entry
Import dial-up entries defined at the workstation
The workstation itself may have dial-up numbers that are defined via the Windows Dial-Up Networking utility. These numbers are not administered by the Dial-Up Networking page.
For more information, use either Windows Help under the Start Menu in Windows or the What's This help on the individual pages associated with dial-up networking.
Dial-up networking and remotely controlling workstations are not the same. For more information on setting up this policy, see Setting Up the RAS Configuration Policy.
Remote Control
This policy sets parameters for managing remote user functions. For example, whether to prompt users for permission to remotely control their workstations. This policy is found on each of the platform pages.
Only for Windows 2000, this policy is an extension of extensible policies for Windows 2000 and Active Directory.
For the following reasons, you will need to use UNC paths rather than mapped drives for importing this policy to ZfD:
Users could change their login scripts, altering drive mappings
Workstation objects are often logged in before users are; therefore, there are no drive mappings available
With UNC paths, as long as the server is available, the policy will be found.
Group policies have changed significantly since the ZfD version 3 initial release. Group policies are now additive, they check for revisions, they cache already-processed policies, and they use persistent or volatile settings. Review the following sections for more information:
Additive Group Policies: Group policies are now additive. This means that settings from multiple Group policies are cumulatively effective, rather than individually. Settings from multiple Group policies can affect users and workstations. Policies start with the local Group policy settings and are applied in reverse of the policy search order. This means that a setting in a policy applied first has lowest priority and its value is overwritten by any other policy with the same setting.
Security settings are not additive; they are set by the last effective policy.
Revision Checking: Group policies now track the revision of the policies in effect. As long as the list of effective policies and their revisions remains the same, Group policies are not processed, but use the cached Group policy.
NOTE: Each time the Edit Policies button is clicked, the revision of a Group policy changes, causing the policies to be reprocessed.
Group Policy Caching: The last-processed Group policy is cached locally. This helps reduce network traffic by processing Group policies only if necessary. If UserA logs in on a new machine, his or her effective Group policies are processed and then cached.
If UserA logs out and UserB logs in, and if UserB has the same effective Group policies as UserA, the locally-cached Group policy is restored instead of reprocessing Group policies. If the list of effective policies is different or if the revision is changed on any policy, the Group policies are reprocessed.
Persistent and Volatile SettingsThe administrator determines if Group policies are persistent or volatile. The persistent setting indicates that when the Group Polices are set, they remain set---even if a user happens to log in only to a workstation and not to the network.
The volatile setting indicates that the original local Group policy settings will be restored when:
The user logs out (user settings are restored)
The system shuts down (workstation settings are restored)
This policy sets what hardware and software inventory data you want to view for each workstation. It also identifies an inventory server for each workstation in the network. This policy is found only on the WinNT-2000 and Win95-98 pages.
You should eventually migrate all ZENworks 2 policies to obtain the better performance and ease of management that ZfD offers. When you install ZfD, you are not required to migrate older policies because ZENworks 2 policy objects are not removed when extending the schema. This allows you to migrate the older policies in phases, such as by context.
If you do not migrate ZENworks 2 policies to ZfD, you must continue using NetWare Administrator for management purposes. ZfD uses ConsoleOne for management purposes. ConsoleOne will display only the effective policies in an object's properties for ZfD policies. To view the effective policies for ZENworks 2 policies, you must use NetWare Administrator. If you have a mixed environment of ZENworks 2 policies and ZfD policies, you must use both NetWare Administrator and ConsoleOne.
When you migrate the older policies, they are placed into the newer policy packages. You cannot choose their placement. Most ZENworks 2 policies are placed in either the User Package or Workstation Package.
Default Package schedules are not migrated, so you will need to redefine these schedules for the migrated policies.
The individual User System and Computer System policies in ZENworks 2 have been incorporated as extensible policies in ZfD. They are migrated as individual policies that cannot be edited in ZfD. By default, they are automatically enabled when migrated. To override them, you must disable them, make changes that correspond to the ZENworks 2 settings in a ZfD extensible policy, then enable the ZfD extensible policy. For more information, see Understanding Extensible Policies.
You can continue to use the older versions of the User/Computer System policies until you have duplicated the settings for these older policies in the newer extensible policies.
IMPORTANT: The User/Computer System policy settings cannot be viewed after they have been migrated. You will need to know how these policies were configured in ZENworks 2 to configure the similar settings in a ZfD extensible policy. Therefore, you should note the settings for the individual ZENworks 2 policies before you migrate them.
or 
