Novell is now a part of Micro Focus

Taking the Pain Out of Windows NT Profiles and System Policies with Novell's ZENworks

Articles and Tips: article

Managing Consultant
Brightman Consulting Ltd., UK

01 Dec 1999

Profiles and System Policies are supposed to make it easier to roll out Windows NT Workstations. By adding ZENworks to the equation, standardizing your NT desktops is easier than ever.


Organisations that have adopted Microsoft Windows NT as a desktop operating system face a number of issues in maintaining those desktop systems, such as cost, accessibility, and user perception. To reduce the costs and ease the support burden, many have implemented a standard desktop configuration that all users must adhere to. This also facilitates user access to the information and tools they need to do their jobs, and provides a favorable perception of the Information Technology (IT) efforts within the organisation.

To help in implementing desktop standards, Windows NT 4.0 Workstation has several built-in features: Profiles and System Policies. These, along with Microsoft's Zero Administration for Windows (ZAW) initiative, are designed to assist in the installation, configuration, and administration of Windows environments.

With ZENworks, Novell has utilised and enhanced the functionality of these mechanisms by incorporating their management and storage into Novell Directory Services (NDS), making them pervasive and inherently more resilient. This AppNote discusses the features and functionality of Windows NT Profiles and System Policies, and shows how ZENworks builds upon the foundation and extends it into NDS.

Since this AppNote was written in the U.K., it retains the British spelling used by the author.

For more information about ZENworks, visit the product Web site at:

The Standard Desktop Environment

There are several issues relating to the management and use of PCs within the modern organisation. The first is cost. Organisations are becoming increasingly aware of the costs involved in maintaining PCs. By their very nature, PCs tend to be personalised, with different hardware and software configurations, user "customised" (or messed up) interfaces, user installed software (you know the ones"those freeware utilities that replace vital system DLLs), and so on. Maintaining these personalised machines becomes exponentially more difficult and costly as the use of the PC is extended throughout the organisation. The direct impacts on support staff are confusion and wasted time as time is spent establishing what software is installed on workstations and how it is configured.

A second issue comes down to accessibility. The whole purpose of IT is to facilitate access to and use of information. Workers within an organisation need access to the information and tools required to do their job. They need to be able to do this with the minimum of effort and without having to understand the mechanisms used to provide the information. With a variety of differently configured PCs and user interfaces, it becomes very difficult for users to simply get to the information they need.

Another, less tangible issue is the perception of the user. Networked PCs are often the users' interface with the corporate IT infrastructure, and this is where their opinion of the organisation's use of IT is formed. Regardless of the architecture, complexity, and "superior" management of the servers, UNIX hosts, and mainframes behind the scenes, the PC is the front line where judgements are made. If users are faced with multiple interfaces and different ways of doing the same task on different PCs, their perception of IT may be negative. In these times of increased use of outsourcing, it is essential that IT departments provide high quality, accessible, and resilient systems for their internal customers.

To address issues such as these, many organisations decide to adopt a standard desktop environment. This often comprises a standard desktop operating system and network client, usually consistent hardware, and most importantly a managed user interface.

One of the most common desktop operating system is currently Microsoft's Windows NT 4.0 Workstation, which provides a more secure and resilient desktop environment than the other Windows products. Microsoft's Zero Administration for Windows initiative is aimed at assisting organisations in the installation, configuration, and administration of Windows environments. ZAW revolves around the built-in features of Profiles and System Policies and, with the Zero Administration Kit (ZAK), provides related techniques and tools.

With ZENworks, Novell has utilised and enhanced the functionality of these mechanisms by incorporating their management and storage into Novell Directory Services (NDS), making them pervasive and inherently more resilient.

NT Desktop Interface Basics

Prior to discussing Profiles and System Policies, we need to understand the basics of the Windows NT desktop shell (Explorer). The desktop interface is essentially formed of menus, icons, and configuration parameters.

Menus and Icons

The menus and icons are simply a file and folder structure containing links to programs and functions. These are stored in the standard file system, be it FAT or NTFS. This structure is stored on a per-user basis in a folder named %systemroot%\profiles\%username%. For example, for user David the folder name might be C:\Winnt\Profiles\David.

The most obvious folders stored here are the "Start Menu" which contains the Programs folder, along with its contents of subfolders and link files (for example, the Accessories folder containing the file Notepad.lnk, which is simply a shortcut to %systemroot%\system32\notepad.exe). The contents of the %username%folder will be discussed in the following section.

Common Start Menu items and Desktop icons come from the folder structure under %systemroot%\profiles\All Users. As the folder name suggests, these items appear for all users. Common Start Menu Program items appear under the "engraved" line that separates them from the user's personal program links.

Tip: Additional desktop icons that appear for all users on a machine (for example, Inbox, Recycle Bin, and The Internet) may stem from below the HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Desktop\NameSpacesubkey.

Configuration Parameters

The configuration parameters detailing what, how, and where you see elements within Explorer are stored within the HKEY_CURRENT_USERkey of the Registry. This data is stored in the hive file %systemroot%\profiles\%username%\ntuser.dat.

The Registry is a database of configuration information for all hardware, software and applications. It is structured into keys, subkeys, values, and data and is formed from persistent data, which is stored in "hives" (individual files within the file system) as well as dynamic data (such as hardware detected during the boot sequence).

The NT Registry is logically structured into six root keys, two of which are HKEY_LOCAL_MACHINE (HKLM) and HKEY_CURRENT_USER (HKCU). HKLM relates to the configuration data for a particular machine (the local computer). This is actually formed as several subkeys each with their own hive. HKCU relates to the configuration data for the currently logged in user. It is actually a link to a subkey of another root key, HKEY_USERS (HKU), but is used to facilitate access to the currently logged in user's configuration data. The hive file for this data is NTUSER.DAT, which is stored in the %systemroot%\ profiles\%username% folder.

NT Profiles

An NT Profile contains the settings for a specific user, including the user's environment and preferences. The settings comprise a folder structure and NTUSER.DAT file. As discussed above, these are stored locally under the %systemroot%\profiles\%username%folder.

The NTUSER.DAT file is a registry hive that contains the registry data for the user. The Registry settings stored in this hive include:

  • NT Explorer preferences ("look and feel" of the Explorer interface, such as view options and window positions)

  • Persistent network connections

  • Application configuration data

  • Control Panel settings

The folder structure includes the following folders:

  • Application Data—specific application data, such as custom dictionaries

  • Desktop—desktop icons in the form of .LNK files

  • Favorites—shortcuts to favourite locations (used extensively by Internet Explorer and MS Office)

  • History—Web browsing history of URLs visited

  • NetHood—shortcuts for Network Neighbourhood

  • Personal—should be default —Save As...— location for applications (akin to —My Documents—)

  • PrintHood—shortcuts for printer links

  • Recent—shortcuts to recently accessed documents and files

  • SendTo—shortcuts for Explorer's context menu

  • Start Menu—personal Start Menu Program items (includes StartUp)

  • Templates—shortcuts to templates

  • Temporary Internet Files—locally cached data from Web browsing

Tip: Temporary Internet Files can cause significant delays during login if using Roaming Profiles. Consider altering the location in Internet Explorer Properties | General | Temporary Internet Files | Settings.

Profile Types

Windows NT provides three different types of profile: Normal, Mandatory, and Roaming.

  • Normal Profiles (sometimes called cached profiles) exist only on the local machine. Users can modify their environment and changes will be maintained on the local machine only.

  • Mandatory Profiles do not allow users to save the modifications they make to their environment. Users can adjust the settings for their current session, but these will not be maintained for subsequent logins.

Note: This important concept is often a point of confusion between Profiles and System Policies. If you want to stop users from performing certain actions (such as changing the wallpaper), you need to apply System Policies. Mandatory Profiles prevent the saving of modifications; they do not restrict the ability to modify.

  • Mandatory Profiles are pre-configured and the Registry hive has a .MAN extension as opposed to .DAT.

  • Roaming Profiles follow users from machine to machine. They are stored on network drives (in NetWare NDS environments this is under the user's %HOME_DIRECTORY) and are downloaded during the login process. It is therefore possible for a user to modify their environment on one machine and receive the same environment on a different machine.

Note: Problems can arise if users roam to differently configured machines. Specifically, shortcuts and menu items may become invalid. For example, if you move from a machine with IE4 Active Desktop installed to a machine with IE3, you may be unable to launch Windows Explorer from Start | Programs | Windows NT Explorer.

It is possible to combine Mandatory and Roaming Profiles to create a centrally controlled desktop environment that will be reset upon each subsequent login. For example, you could create a LOCKEDNT.MAN profile in a Read and File Scan only directory such as SYS:PUBLIC and specify the full pathname in the "Find Mandatory Profile in a NetWare File System" field.

Default Profile

When a user first logs in to an NT workstation and no Normal (Cached), Roaming, or Mandatory Profile exists, the user receives a copy of the Default Profile. The Default Profile consists of the same folder structure and NTUSER.DAT file as any other profile. It exists in the %systemroot%\profiles\Default Userfolder.

With this knowledge, it is possible to prepare a standard profile that will be granted to new users as they first log in. Since the Default Profile comes from the local computer, a user with a Roaming Profile enabled will receive that profile from the Default Profile of the first workstation the user logs in to. The Default Profile can be copied to from an existing Profile using Control Panel | System | User Profiles | Copy To... whilst logged in as a local Administrator.

Tip: There is a Registry key HKEY_USERS\.DEFAULT that contains the Profile settings (such as wallpaper) to be used when no user is logged in. Don't confuse this with the %systemroot%\profiles\Default User\Ntuser.dathive file, which contains the Registry settings for new users.

ZENworks WinNT Roaming Profiles

ZENworks supports Roaming Profiles through the use of the WinNT User Package, which is one of the Policy Package NDS objects made available when ZENworks is installed. WinNT User Package objects can be associated with NDS user, group, or container objects. The Search Order can be managed through the use of a Container Package object.

One of the policies available within the WinNT User Package is "NT Desktop Preferences". Within this policy object are two property pages: Control Panel and Roaming Profile (see Figure 1).

Figure 1: The NT Desktop Preferences policy object has two property pages.

Both User (Normal) and Mandatory Roaming Profiles are supported. Both are considered Roaming, as the Profile is stored on a network drive and should be available from any computer logged in. Normal Roaming Profiles (User Profiles) have to be stored under the user's home directory.

Note: It is important that the NDS Home Directory property be set for the NDS User object and that long file name support be enabled on the volume containing the home directory. The Profile is stored in folder named "Windows NT 4.0 Workstation Profile" directly beneath the user's home directory (for example, VOL1:HOME\DAVID\Windows NT 4.0 Workstation Profile).

The contents of the folder are identical to those held on the local machine. The contents are copied to the local profile folder by NWGINA.DLL (NetWare Graphical Identification aNd Authentication Dynamic Link Library) during the login process. The user then uses the local profile for the duration of the session, after which the Profile is copied back the Roaming Profile directory during the logout process.

A Mandatory Roaming Profile can be located anywhere on a network drive. This is enabled by selecting "Find Mandatory Profile in a NetWare File System" and specifying the full path to the Profile folder. As with the Default Profile on the local machine, the contents of a suitable Profile can be copied to this location. It is recommended that only Read and File Scan file system rights be granted to this folder to prevent tampering (such as renaming NTUSER.MAN to NTUSER.DAT).

System Policies

System Policies are Registry settings that define what actions can be performed and which resources are available. They can be either machine-specific (HKEY_ LOCAL_MACHINE) or user-specific (HKEY_CURRENT_USER). Machine Policies are known as NT Computer System Policies, and User Policies as NT User System Policies. It is important to differentiate between the two and understand that NT Computer System Policies apply to a machine regardless of who is logged in.

With ZENworks, there are now two methods available for applying system policies. The first is inherent within the Windows NT operating system and is independent of ZENworks. This I refer to as "traditional system policies". The second is ZENworks-specific and utilises the Novell NT Workstation Manager service. As there is the potential for these to clash, the order of precedence is detailed following a discussion of each of the mechanisms.

Traditional System Policies

Traditional System Policies are applied via the use of policy files (with a .POL extension) which are created using the System Policy Editor (POLEDIT.EXE) and policy template files (with an .ADM extension). Before creating a policy file, it is necessary to open a policy template file. Templates are ASCII files that contain details of the Registry keys that the policy file can modify, along with default values or selections for those keys.

There are different policy template files for different applications or aspects of the OS (Windows 9x also uses system policies). The System Policy Editor provided with NT Server allows you to open multiple templates concurrently. The standard template files for Windows NT are COMMON.ADM and WINNT.ADM.

The Zero Administration Kit introduced a new policy template named ZAKWINNT.ADM, which provides User Profiles through System Policies, Internet Explorer security, and the ability to control the visibility of drive letters (hide drives). Other templates are also available; for example, OFF97NT4.ADM for standard MS Office 97 applications under Windows NT 4, ACCESSS97.ADM for MS Access 97, and various template files for Internet Explorer versions 4 and 5, which can be found in the appropriate Internet Explorer Administration Kit (IEAK). It is also possible to write your own policy templates, provided you use the correct syntax. See the Microsoft document ZAKADMIN.DOC, which is included in the ZAK.EXE downloadable.

Once the required template(s) are opened in the System Policy Editor, it is possible to create the policy file. The System Policy Editor provides the Default User object for specifying NT User System Policies and the Default Computer for NT Computer System Policies. It is also possible to create user-specific policies, based on the login name, and computer-specific policies, based on the NetBIOS computer name (see Figure 2).

Figure 2: With the System Policy Editor, you can create policies for individual users and computers.

A word on priorities: if a specific user or computer policy exists, only the policies set within that entry will be applied. If there is no match, the policies set within the default entry will be used.

Automatic Application. Traditional System Policies can be applied either automatically (default) or manually. For automatic application in a NetWare environment, the policy file should be named NTCONFIG.POL and located in the SYS:PUBLIC\WINNT directory.

In a multi-server environment, the actual SYS:PUBLIC\WINNT\ NTCONFIG.POL file used is based on the following order of precedence:

  1. Use the Preferred Server, as specified on the workstation.

  2. If no Preferred Server is specified, use the Default Server in the user's NDS environment.

  3. If neither of the above is specified, use the first server the workstation attached to.

When using the Novell Client for Windows NT, there are two Registry settings that affect the use of traditional policies. The first is DWORD HKLM\ SOFTWARE\Novell\NWGINA\Policy Support\Check Default. This can either be 1 (default) which is On, or 0 to signify that the default path is not to be checked. This value can be set via the Novell Client Properties | Advanced Login | Default Policy Support check box, as well as by editing the registry. Note that since the default is 1 (on), this key may not actually appear in REGEDIT because the default is assumed unless another value is present.

The second key is DWORD HKLM\SYSTEM\CurrentControlSet\Control\ Update\UpdateMode. This can either be 0 which means traditional policies are disabled and not read, 1 (default) which specifies Automatic mode, or 2 which specifies Manual mode. This value can only be set by editing the Registry or by using the System Policy: Default Computer | Network | System Policies Update | Remote Update, which is provided by the COMMON.ADM policy template. For traditional policies to work automatically with the Novell Client for Windows NT, both these values must be set to 1, which is the default for both.

Manual Application. Manual application requires that the path to the policy file be specified. This can be either a local drive (perhaps for use on a notebook) or a network drive. This file does not have to be called NTCONFIG.POL, because the full path and filename are specified. If using a network drive, it is recommended that UNC path names be used, as drive letters may not always be available or mapped with the NetWare MAP command. The path can be specified in either the Novell Client Properties | Advanced Login | Policy Path and Filename entry (STRING HKLM\SOFTWARE\Novell\ NWGINA\Policy Support\Policy Path) or in the STRING HKLM\SYSTEM\ CurrentControlSet\Control\Update\NetworkPath, which is again settable via the System Policy: Default Computer | Network | System Policies Update | Remote Update.

The method of applying traditional System Policies has several weaknesses. Primarily this is because it is based around a physical policy file. Should this file become unavailable, the method is broken. Additionally, the use of the NTCONFIG.POL file can become complex in a multi-server environment. First, you have to try to manage which server the policy file will be read from, which is dependent on a mixture of workstation client, NDS user, and LAN traffic/Get Nearest Server results. If you try to use multiple NTCONFIG.POL files on all possible servers, you have to manage the replication and synchronisation of those files. Finally, as the application of policies is dependent on Registry settings, it is possible for an educated user with access to the Registry to counteract and disable them from future application.

System Polices with ZENworks

ZENworks uses the Novell NT Workstation Manager Service, in conjunction with NDS Policy Packages, to implement NT System Policies. This requires that the service be installed (default with the client installation and easily configured with the ACU process) and that the Enable Workstation Manager check box be ticked, with the correct NDS Tree name specified as the Trusted Tree in the properties.

Workstation Manager was introduced as a separate service with the Novell Client for Windows NT version 4.3. The existence and status of the service can be checked by looking in Control Panel | Services for "Novell Workstation Manager". It should be configured for Automatic startup and have a status of Started. Alternatively, you can check for the existence of the WM.EXE process in Task Manager ("Ctrl"+"Shift"+"Esc").

NT User System Policies can be applied via the WinNT User Package, which can be associated with either NDS user, group, or container objects. NT Computer System Policies are specified within a WinNT Workstation Package, which can be associated with either NDS workstation, workstation group, or container objects.

ZENworks System Policies give the added advantage of application by group membership, which though native in a Microsoft Networking/NT environment, is not available with Traditional System Policies for NT workstations in a NetWare environment. As with any ZENworks policy package, the Search Order is controlled through the Container Policy Package.

NT User System Policies are "singular" policies; that is, only one policy package can apply to a user, regardless of possible multiple associations via Container, Group, or individual User. NT Computer System Policies are "cumulative", whereby multiple Policy Packages can be in effect. The effective Policy Package (or individual policy in the case of conflicting, cumulative policies) is dependent upon any settings in a Container Policy Package, which is associated with the container in which the User object resides. In the absence of a Search Policy, the following default order is used:

  1. User

  2. Group

  3. Container

Note: Problems can arise if there are multiple associations via groups, as there is currently no way of specifying priorities between groups as is possible in an NT environment. The actual precedence is based upon which group the user was made a member of first. This situation is currently under review as an enhancement request (see TID #2938179 at

Workstation Manager uses two "helper" DLLs to apply System Policies. WMUSPOL.DLL is run during the login process and is used to apply NT User System Policies. WMDTPOL.DLL is run as a scheduled action by the Workstation Manager scheduler and is used to apply NT Computer System Policies.

Note: A workstation object must exist before Computer System Policies can be associated and applied (that is, successful registration, import, and synchronisation).

The easiest way to check that a workstation is correctly synchronised is to use the "Display NDS Information" option after right-clicking the Scheduler icon in system tray. This will produce a "Novell Workstation Management" status box in which the Workstation Object and Workstation Tree fields should display the fully distinguished name of the Workstation object and the NDS tree name, respectively. If these fields read "N/A", the workstation is not properly synchronised with the Workstation object in NDS.

NT User System Policies are applied during the login process. However, the NDS timestamp of the User Policy Package object in NDS is stored locally in the Registry following a successful application (HKCU\SOFTWARE\Novell\ Workstation Manger\User Policy\<Policy Package<\Last Updated Time). During subsequent logins, the locally-stored timestamp is compared with the actual timestamp of the NDS object and only applied if the NDS object timestamp is newer. To force the application of NT User System Policies during each login, there is a check box supplied on the NT Desktop Preferences property page of the WinNT User Package: <Always update workstation during NDS Authentication<. Note that this setting only applies to NT User System Policies.

NT Computer System Policies are applied via Workstation Manager (WM.EXE), according to the schedule specified. By default, this schedule is the Default Schedule which, for Workstation Policy Packages, starts at "MTuWThF between 5pm and 11:59pm". It is probably wise to set the schedule for the NT Computer System Policies to Event: User Login. However, bear in mind that the same policy package date stamp comparison between the local registry and the NDS object occurs. In ZENworks 1.1, there is no way to force the application of Computer System policies, though this feature is available in ZENworks 2 as part of the Computer Extensible Policy package.

There are several benefits that ZENworks System Policies provide over Traditional System Policies. Foremost is resilience. Since the policies are stored in NDS, there is no longer a dependency on a single file, or the problems of synchronising multiple copies of the same file. NDS-based policies also provide greater security than those based in the file system. Additionally, ZENworks System Policies offer administrative granularity as well as a tool within the NetWare Administrator utility to determine which Policy Packages are effective.

Custom/Extensible Policies

As mentioned in the section on Traditional System Policies, virtually any user or computer specific registry setting can be controlled through System Policies, provided there is a template (.ADM file) that details the setting. Many Microsoft products (including MS Office, Access, and Internet Explorer) have policy templates available so that application-specific settings can be controlled. Additionally, it is possible to write custom templates for specific settings, provided you use the correct syntax.

ZENworks provides support for these additional policies. The mechanism was enhanced between ZENworks 1.1 and ZENworks 2.

ZENworks 1.1 provides a link to a file system-based policy file, through the User Policy File property page within the NT User System Policies policy. This referenced file is a standard policy file, created using the Policy Editor (POLEDIT.EXE) and whichever templates are required (see Figure 3).

Figure 3: The User Policy File is created using the Policy Editor.

Note: Policy Settings made using this method will override Policies applied via the ZENworks policy package. The best way to avoid conflicts is not to use the COMMON.ADM, WINNT.ADM and ZAKWINNT.ADM templates when creating the file.

ZENworks 2 provides "Extensible Policies" for both User and Computer policy packages. This feature enables the actual custom policies to be stored within NDS (providing resilience, security, and so on) but references the policy templates from the file system. The User/Computer Extensible Policies appear within the appropriate policy package as a specific policy. Upon opening the Extensible Policies property page and selecting User or Computer as appropriate, it is possible to specify the location of the template file and then edit the settings the template provides (see Figure 4).

Figure 4: Editing template settings on the Extensible Policies property page.

Both User and Computer Extensible policies are implemented via the Workstation Manager scheduler (as per NT Computer System Policies), so schedules need to be set and other setting need to be made for proper implementation.

Traditional System Policies vs. ZENworks System Policies

Traditional System Policies and ZENworks System Policies can co-exist and perhaps conflict. It is therefore important to understand that, if there are conflicts, the last applied policy will be in effect. Additionally, the ZENworks 1.1 User Policy File feature (discussed above) can also be in effect. In this case, the order of precedence is as follows:

  1. ZENworks policy packages

  2. The ZENworks policy package specified User Policy File

  3. Traditional System Policies (NTCONFIG.POL)

System Policy Settings

The basic policies made available through ZENworks policy packages are those provided by the standard template files for Windows NT (COMMON.ADM, WINNT.ADM and ZAKWINNT.ADM). The following tables detail the policies available for both users and computers.

NT User System Policies

Default User Settings


- Control Panel



- Display




Restrict display





Deny access to Display icon

Prevents access to the Display option in Control Panel




Hide Background tab

Hides the Background properties of the Display option in Control Panel




Hide Screen Saver tab

Hides the Screen Saver properties of the Display option in Control Panel




Hide Appearance tab

Hides the Appearance properties of the Display option in Control Panel




Hide Settings tab

Hides the Settings properties of the Display option in Control Panel

- Desktop







Wallpaper Name

When checked, the specified bitmap will be used as the wallpaper



Tile Wallpaper

When checked, the wallpaper file will be tiled in the background of the desktop


Color Scheme

When checked, the user will automatically see the specified colour scheme

- Shell




- Restrictions




Remove Run command from Start menu

Prevents access to the Run command on the Start menu



Remove folders from settings on Start menu

Prevents access to any item listed under Settings on the Start menu



Remove Taskbar from settings on Start menu

Prevents access to the Taskbar item listed under Settings on the Start menu



Remove Find command from Start menu

Prevents access to any of the items listed under Find on the Start menu



Hide drives in My Computer

Prevents access to My Computer



Hide Network Neighborhood

Prevents access to Network Neighborhood



No Entire Network in Network Neighborhood

Prevents access to the Entire Network icon in Network Neighborhood



No workgroup contents in Network Neighborhood

Prevents workgroup contents from being displayed in Network Neighborhood



Hide all items on desktop

Prevents access to all items on the desktop



Disable Shut Down command

Prevents access to the Shut Down command on the Start menu; displays explanation in a dialog box



Don't save settings at Exit

Prevents settings from being written to the file system

- System




- Restrictions





Disable Registry editing tools

Prevents access to the Registry Editor; does not prevent access to the Registry mode in System Policy Editor




Run only allowed Windows applications

Prevents users from running any Windows-based applications except those that are listed; click Show to define the allowed applications

- Windows NT Shell




- Custom user interface






Custom shell

Specifies an alternate shell to Explorer (such as NAL)



- Custom Folders






Custom Program folders

Customises the contents of the Program directory (you must also type a path for the directory containing complete files or .LNK files that define the Programs directory items)





Custom desktop icons

Customises desktop icons (you must also type a path for the directory containing complete files or .LNK files that define the desktop shortcuts)





Hide Start menu subfolders

Check this when you use a custom Programs folder; otherwise, two Programs entries will appear on the user's Start menu





Custom Startup folder

Customises the contents of the Startup directory (you must also type a path for the directory containing complete files or .LNK files that define the Startup directory items)





Custom Network Neighborhood

Customises the contents of Network Neighborhood (you must also type a path for the directory containing complete files or .LNK files that define the Network Neighborhood items)





Custom Start menu

Customises what is listed on the Start menu (you must also type a path for the directory containing complete files or .LNK files that define the Start menu items)



- Restrictions






Only use approved shell extensions

Prevents use of unauthorised application modules that extend the functionality of the Explorer shell





Remove File menu from Explorer

Removes the File option from Explorer's toolbar





Remove common program groups from Start menu

Disables the display of common groups when the user selects Programs from the Start menu





Disable context menus for the Taskbar

Removes the context menus for the tray, including the Start button, Tab control, and Clock





Disable Explorer's default context menu

Removes the context menu that would normally appear when the user right-clicks on the desktop or in the Explorer right results pane





Remove the Map Network Drive and Disconnect Network Drive option

Prevents users from making additional network connections by removing the Map Network Drive and Disconnect Network Drive buttons from the toolbar in Explorer and also removing the menu items from the Context menu of My Computer and the Tools menu or Explorer





Disable link file tracking

Prevents the system from using UNC names to resolve shortcuts, causing use of drive letters instead. This option disables link file tracking which, when enabled, uses the configured path shown in properties for the shortcut to an application instead of the absolute path.

- Windows NT System




Parse Autoexec.bat

When this value is 1, the environment variables declared in the Autoexec.bat file are included in the user's environment



Run logon scripts synchronously

Determines whether or not the shell waits for the logon script to complete. If the value is 0, the logon script is run during the startup of the shell and allows items in the Startup group to start. If the value is 1, the logon script completes before the shell or any items in the Startup group are started. If this value is also set in the Computer section, the Computer section value takes precedence.



Disable Task Manager

Enables or disables the user's ability to start Task Manager to view processes, applications running, and make changes to the priority or state of the individual processes



Show welcome tips at logon

Enables or disables the display of the Welcome screen when the user logs on for the first and second time

- ZAK Policies




- Windows NT






- User Profiles through System Policies








AppData Folder

Specifies path to Application Data folder, which contains user-specific application files such as custom dictionaries







Favorites Folder

Specifies path to Favorites folder, which contains shortcuts to favourite locations (used extensively by Internet Explorer and MS Office)







NetHood Folder

Specifies path to NetHood folder, which contains shortcuts for Network Neighbourhood







PrintHood Folder

Specifies path to PrintHood folder, which contains shortcuts for printer links







Recent Folder

Specifies path to Recent folder, which contains shortcuts to recently accessed documents and files







SentTo Folder

Specifies path to SentTo folder, which contains shortcuts for Explorer's context menu





- Internet Explorer Security








Active Content









Allow downloading of ActiveX content

Allows ActiveX content to be downloaded








Enable ActiveX Controls and Plug-ins

Enables ActiveX controls and plug-ins








Run ActiveX Scripts

Specifies whether or not to run ActiveX scripts








Enable Java programs

Enables Java programs







Active Content Security Level






- Drives








- Restrictions









Show only selected drives

Specifies which drives are available via Explorer, My Computer, and application Open dialogue boxes; however, does not prevent users from viewing "hidden" drives using other programs (such as WINFILE.EXE)

Note: This conflicts with the Shell\Restrictions\Hide Drives policy.



- Windows








Can specify programs to be run on system startup; multiple programs can be specified, separated by spaces

NT Computer System Policies

Default Computer Settings


- Network



- System Policies update





Remote update



Controls how policies are applied to a Windows NT 4.0-based machine. With UpdateMode set to 1 (Automatic), Windows NT checks for the existence of the policy file, SYS:PUBLIC\WINNT\NTconfig.pol in NetWare. With UpdateMode set to 2 (Manual), Windows NT reads the string specified in the NetworkPath value, and checks that path for the existence of the policy file (in this case, the policy file name should be included in the NetworkPath value). With UpdateMode set to 0 (Off), a policy file is not downloaded from any system, and therefore is not applied.

- System











Specifies valid SNMP communities from which the SNMP service on the workstation will accept requests





Permitted managers

Specifies names of hosts permitted to send requests to the SNMP agent





Trap for public community

Specifies host names, IP addresses, or IPX addresses to which SNMP traps should be sent



- Run







Allows one or more applications to be run when the user logs on interactively

- Windows NT Network Sharing




- Sharing






Disable peer to peer server

Disables the Server and Browser services. If this value is selected and the Create hidden drive shares (workstation and server) are selected, this value takes precedence.





Create hidden drive shares (workstation)

When enabled, creates administrative shares for physical drives. These shares were created automatically under Windows NT 3.51. This policy setting gives administrators the ability to control this feature. This setting is specific to Windows NT Workstation.





Create hidden drive shares (server)

As above, though this setting is specific to Windows NT Server.

- Windows NT Printers





- Sharing






Disable browse thread on this computer

When this option is enabled, the print spooler does not send shared printer information to other print servers.





Scheduler priority

Above normal = 1; Normal = 0; Less than normal = FFFFFFFF





Beep for error enabled

Enables beeping (every 10 seconds) when a remote job error occurs on a print server

- Windows NT Remote Access




Max number of unsuccessful authentication retries

Specifies the number of times authentication will be attempted for a user (default 2)



Max time limit for authentication

Defines the maximum time limit in seconds for authentication to occur (default 120 seconds)



Wait interval for callback

Specifies the time in seconds that Windows NT will wait before initiating the callback from a RAS dial-in user (default 2 seconds)



Auto disconnect

Specifies the amount of idle time in minutes to wait before disconnecting the RAS client (default 20 minutes)

- Windows NT Shell




- Custom shared folders






Custom shared Programs folder

Specifies the UNC path for the folder to use when displaying folders, files, and shortcuts below the division line (common groups) when the user selects Programs from the Start menu (default = %SystemRoot%\Profils\ALl Users\Start Menu\Programs)





Custom shared desktop icons

Specifies the UNC path the folder is to use when displaying the folders, files, and shortcuts the user receives as part of the desktop (default = %SystemRoot%\Profiles\All Users\Desktop)





Custom shared Start menu

Specifies the UNC path the folder is to use when displaying the folders, files, and shortcuts the user receives as part of the Start menu (default = %SystemRoot%\Profiles\All Users\Start Menu)





Custom shared Startup folder

Specifies the UNC path the folder is to use to find folders, files, and shortcuts that should be started when the user logs on (default = %SystemRoot%\Profiles\All Users\Start Menu\Programs\Startup)

- Windows NT System




- Logon






Logon banner

Before the user logs on, displays a custom dialog box with text





Enable shutdown from Authentication dialog box

Enables or disables the Shut Down button on the logon dialog window





Do not display last logged on user name

Enables or disables display of the last logged on user name when the user presses Ctrl+Alt+Del and the logon dialog is displayed





Run logon scripts synchronously

Determines whether the shell waits for the logon script to complete or not. If the value is 0, the logon script is run during the startup of the shell and allows items in the Startup group to start. If the value is 1, the logon script completes before the shell or any items in the Startup group are started. If this value is also set in the User section, this value takes precedence.



- File system






Do not create 8.3 file names for long file names

Specifies whether NTFS should create 8.3 names for files with long names or characters from extended character set. It can improve file system performance, but may hinder applications that cannot process long filenames.





Allow extended characters in 8.3 file names

Short file names with extended characters may not be viewable on computers that do not have the same character code page.





Do not update last access time

For files that are only to be read, specifies do not update the last access time. (This increases the file system's performance.)

- Windows NT User Profiles




Deleted cached copies of roaming profiles



After a user logs off from an interactive session, if this value is enabled, the locally cached version of the roaming User Profile is deleted.



Automatically detect slow network connections



Enables or disables detection of a slow network.



Slow network connection timeout



Specifies the amount of time in milliseconds that Windows NT waits before a slow network is determine (default = 2000)



Timeout for dialog boxes



When the user is presented with a dialog box requesting User Profile information, this specifies the amount of time in seconds before the dialog box is closed and the default is accepted (default = 30)


The understanding and use of Profiles and NT System Policies can help an organisation develop a standard desktop environment that is consistent, portable, and resilient. By enabling the management of these features through NDS and NWAdmin, ZENworks enhances the ability of an organisation to effectively manage and, where necessary, control the desktop environment.

* Originally published in Novell AppNotes


The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.

© Copyright Micro Focus or one of its affiliates