The full functionality of IntelliMirror requires Active Directory and Group Policy. However, in an environment without Active Directory and Group Policy, some of the capabilities are available. You can still implement the following IntelliMirror features to manage Windows 2000 clients:
Roaming User Profiles and Logon Scripts
Folder Redirection
Internet Explorer Maintenance
Administrative Templates (registry-based policy)
Roaming User Profiles and Logon Scripts
When using either a Windows NT 4.0 domain or Active Directory, both roaming user profiles and logon scripts are configured on the user object.
Folder Redirection
You can redirect special folders to alternate locations, either to a local or network location. You do this by modifying the values under the following registry key:
HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders
Each value is of type REG_SZ, and the data is the redirected path (either local or UNC). The table below lists the folders that may be redirected and their associated value name.
Folder
|
Name
|
My Documents
|
Personal
|
My Pictures
|
My Pictures
|
Application Data
|
AppData
|
Desktop
|
Desktop
|
Start Menu
|
Start Menu
| Internet Explorer Maintenance
Instead of using Group Policy to control Internet Explorer settings, administrators can use the Internet Explorer Administration Kit (IEAK) to apply settings to Internet Explorer clients using auto-configuration packages. The IEAK can be downloaded from http://www.microsoft.com/windows/ieak.
Applying Administrative Templates (Registry-Based Policy)
Domain-based Group Policy processing requires that the User and/or Computer objects be located in a Windows 2000 Active Directory. If the User or Computer objects are located in a Windows NT 4.0 domain, then Windows NT 4.0 System Policy will be processed for whichever of these objects is located in that domain—this could be the Computer or User object, or both. System Policy is defined as the policy mechanism used natively in Windows NT 4.0; it is a set of registry settings that together define the computer resources available to a group of users or an individual. (Also be aware that the local GPO is always processed prior to any System policy.)
This section explains how to use System Policy to deliver the registry-based (Administrative Templates) policy settings that are available in Windows 2000. This may be needed for Windows 2000 clients that have either or both of the User or Computer objects located in Windows NT 4.0 domains. These procedures will also work for providing System policy from any Server Message Block (SMB)-enabled share or even from a local share.
Setting Registry-based Policy in a Windows NT 4.0 Domain
A Windows 2000 client will process System Policy if either the user and/or computer account are in a Windows NT 4.0 domain. (For exact details on processing behavior, see the section later in this document called Migrating Policy-Enabled clients from Windows NT 4.0 to Windows 2000). The client looks for the Ntconfig.pol file used by Windows NT 4.0-style System Policy. By default, it looks for this file in the NETLOGON share of the authenticating Windows NT 4.0 domain controller.
Setting Registry-based Policy in a Workgroup Environment
In the absence of a Windows NT 4.0 domain, the client can be configured to look for the NTconfig.pol file on the local computer or on any SMB share location, as explained in the section below, Specifying a Manual Path to Retrieve the Policy File from a Specific Location.
Creating NTconfig.pol Files Based on Windows 2000 .Adm Files
Using the procedure below, you can create NTconfig.pol files based on the new Windows 2000 .Adm files, and apply these settings to Windows 2000 Server or Professional clients.
You will need the Windows NT 4.0 System Policy Editor tool, Poledit.exe. This tool is installed with Windows 2000 Server and Windows 2000 Advanced Server. You can install Poledit.exe on Windows 2000 Professional computers by installing the Windows 2000 Administration Tools that are included on the Windows 2000 Server and Windows 2000 Advanced Server CD-ROMs. To install Windows 2000 Administration Tools on a Windows 2000 Professional computer, open the i386 folder on the applicable Windows 2000 Server disc and then double-click the Adminpak.msi file. Follow the instructions that appear in the Windows 2000 Administration Tools Setup wizard.
Note: The System Policy Editor (Poledit.exe) from any previous operating system version cannot read the Unicode-formatted .adm files shipped in Windows 2000. You will need to use the version of System Policy Editor that ships in Windows 2000, which has been updated to support Unicode. Alternatively, you can use an older version of Poledit.exe, if you resave the .adm files as .txt files without Unicode encoding.
Remove all #if version and #endif statements from the following .adm files: system.adm, inetres.adm, conf.adm, and then save the files. Do this to byprevent inadvertent loading of these files by poledit. (You can use Notepad or other text editor tool to edit these .adm files).
For example, in the Inetres.adm file, remove these lines:
#if version <= 2
#endif
To open Poledit.exe from Windows 2000, click Start, click Run, and type poledit.exe.
In the System Policy Editor window, click Policy Template on the Options menu.
In the Policy Template Options dialog box, click Add, and then select one of the modified template files (the .adm files that you modified in step 1 above), and click OK.
Specify the appropriate policy settings based on groups (or not), as documented in the System Policy Editor online Help and below.
Save the file as NTconfig.pol to the Netlogon share of the Windows NT 4.0 domain controller. Alternatively, you can manually set a path for the policy file to use, as described in the Specifying a Manual Path to Retrieve the Policy File from a Specific Location section later in this document.
Note: The System Policy Editor is not included in Windows 2000 Professional, but is installed when you install the Windows 2000 Administrative Tools package on Windows 2000 Professional. The Windows 2000 Administration Tools can be installed from Adminpak.msi, located in the I386 folder of the Windows 2000 Server CD.
When you install the AdminPack, Poledit.exe and its supporting .adm files (Winnt.adm, Windows.adm, and Common.adm) are installed into the \System directory and the \Inf directory, as they were in Windows NT 4.0. Note that Poledit.exe is not added to the Start menu, but it is accessible from the command line.
System Policy Files
Policies can define a specific user’s settings or the settings for a group of users. The resulting policy file contains the registry settings for all users, groups, and computers that will be using the policy file. Separate policy files for each user, group, or computer are not necessary.
To create a policy that will be automatically downloaded from validating domain controllers, create a .pol file.
For Windows NT 4.0 and Windows 2000, your .pol file should be named NTconfig.pol and must be created using the System Policy Editor running on either of these platforms.
For Windows 95, Windows 98, and Windows Millennium Edition, your .pol file should be named Config.pol and must be created using the System Policy Editor running on any of these platforms.
As system administrator, you have the option of choosing an alternate name for the .pol file and directing the computer to update the policy from a path other than the NETLOGON share. You can do this either by manually changing the registry or by using System Policy, as described in the next section. This path can even be a local path such that each computer has its own policy file. However, if a change is necessary to all computers, this change must be made individually to each workstation.
When a user of a Windows 2000 client logs on to a Windows NT 4.0 domain, if the client is working in Automatic mode (which is the default), it checks the NETLOGON share on the validating domain controller for the NTconfig.pol file. If the client finds the file, it downloads it, parses it for the user, group, and computer policy data, and applies it if appropriate. If the client does not locate the policy file on its validating domain controller, it will not check any others. It is therefore critically important that replication of the NTconfig.pol file take place among the domain controllers performing authentication. The NETLOGON share for Windows NT 4.0 is in %SystemRoot%\repl\\import\scripts. The NETLOGON share for Windows 2000 is in %SystemRoot%\Sysvol\Sysvol\\Scripts.
For more information on System Policy, refer to the “Implementing Profiles and Policies for Windows NT 4.0” white paper at http://www.microsoft.com/ntserver/management/deployment/planguide/prof_policies.asp.
Specifying a Manual Path to Retrieve the Policy File from a Specific Location
You can change the default behavior so that a Windows 2000 client looks in a different location than the NETLOGON share. The UpdateMode registry setting forces the computer to retrieve the policy file from a specific location (expressed as a UNC path), regardless of which user logs in. You can set the UpdateMode setting using either the System Policy Editor in conjunction with the Common.adm file, or you can do this manually by editing the registry as described next.
In the following registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Update:
Change the value of the UpdateMode to a hexadecimal value of 2 (Type = REG_DWORD).
Create a string value called NetworkPath, and set the value to be the fully qualified file name of the .pol file to be loaded. (Type = REG_SZ).
To retrieve the policy file from a specific location
Open System Policy Editor, by clicking Start, clicking Run, and then typing poledit.
Ensure that the System.adm file is loaded. To do this, click Options, click Policy Template, and then in the Policy Template Options dialog box, make sure that System.adm is listed in the Current Policy Template(s) list box. If it is not listed, click Add to add this file.
To open the Default Computer policy, on the File menu, click New Policy, and double-click Default Computer from the Policies for list.
Or, to open the Local Computer policy, click Open Registry on the File menu, and then double-click Local Computer.
In the Properties dialog box (for either Default Computer or Local Computer), click the Network node, and click the System policies update node to display the Remote update option.
Check the Remote update box.
In the Update mode drop-down box, select Manual (use specific path).
In the Path for manual update text box, type the UNC path and file name for the policy file to use.
Click OK to save your changes.
The first time the Windows 2000 client is modified locally using the System Policy Editor or receives a default System Policy file from the NETLOGON share of a domain controller, this location is written to the registry. Thereafter, all future policy updates use the location you specified manually. Note that this is a permanent change until the policy file resets the option to Automatic. The Windows 2000 client will not look at a domain controller again to find a policy file until you either change the instruction in the local registry, or modify the policy file in the location specified by the manual path to set the mode back to Automatic.
Migrating Policy-Enabled Clients from Windows NT 4.0 to Windows 2000
This section discusses behavior of Group Policy and System Policy in relation to migration to Windows 2000.
Windows NT 4.0 and Windows 2000 Policy Comparison
Group Policy is not System Policy from Windows NT 4.0. Although Group Policy does include the functionality from Windows NT 4.0 System Policy, it also provides policy settings for scripts, software installation, security settings, Internet Explorer maintenance, folder redirection, and Remote Installation Services.
In Windows NT 4.0 (and Windows 95 and Windows 98), the System Policies you specify with Poledit.exe:
Are applied to domains.
May be further controlled by user membership in security groups.
Are not secure.
Persist in users’ profiles (this is sometimes referred to as tattooing the registry). This means that after a registry setting is set using Windows NT 4.0 System Policies, the setting persists until the specified policy is reversed or the user edits the registry.
Are limited to desktop lockdown.
In Windows 2000, Group Policy:
Represents the primary method for enabling centralized Change and Configuration Management. You can use Group Policy to manage registry-based policy, software installation options, security settings, scripts (for computer startup and shutdown, and for user logon and logoff), Internet Explorer maintenance, folder redirection, and Remote Installation Services.
Can be associated with sites, domains, and organizational units.
Affects all users and computers in the specified Active Directory container (site, domain, or OU) by default.
May be further controlled by user or computer membership in security groups.
Settings are secure.
Default policy settings do not persist in the registry.
Can be used for tightly managed desktop configurations and to enhance the user’s computing environment.
The Windows NT 4.0 effect of persistent registry settings can be problematic when a user’s group membership is changed. An advantage of Windows 2000 Group Policy is that this does not occur. When a Group Policy object no longer applies, registry settings written to the following two secure registry locations are cleaned up:
\Software\Policies
\Software\Microsoft\Windows\CurrentVersion\Policies
Migrating to Windows 2000
Migrating Windows NT 4.0-based clients and servers to Windows 2000 in various combinations causes different behavior for Group Policy. In a pure Windows 2000 environment where both the user and computer accounts are in a Windows 2000 domain, Windows 2000 clients process only Group Policy. System Policy is not processed. However, Windows 2000 clients can process System Policy in cases where either the user account and/or the computer account is not located in a Windows 2000 domain.
In many organizations it may be impractical to upgrade all Windows NT 4.0 servers and client computers simultaneously to Windows 2000. In this case, it is important that you know how Windows 2000 Group Policy and Windows NT 4.0 System Policy are affected during and after the migration process. This section presents information on the effects of migration on Group Policy.
Client Computers
Group Policy applies only to Windows 2000-based or later computers. There is no mechanism to process Group Policy on clients running Windows NT 4.0, Windows 95, Windows 98, and Windows Millennium Edition. Although Group Policy cannot be used on these clients, you can still use Windows NT 4.0-based System Policies. For more information, see the section called Applying Administrative Templates (Registry-Based Policy) earlier in this document.
Domain Controllers
For clients that are running Windows 2000, the processing of Group Policy varies depending on whether the user and computer accounts are located in a Windows NT 4.0 domain or in a Windows 2000 Active Directory domain.
The following table summarizes the behavior of the client with respect to policy, depending on whether the computer or user accounts (or both) are located on a Windows NT 4.0 Server–based server or on a Windows 2000 Server–based server with Active Directory.
In the table below, it is assumed that client computers are running Windows 2000. Clients that receive Windows NT 4.0 System Policy obtain it either from the NETLOGON share of the users’ logon server or a redirected path.
Environment
|
Account Object Location
|
What Affects the Client
|
Pure Windows NT 4.0
|
Computer: Windows NT 4.0
|
At computer startup: Computer local Group Policy (only if changed).
Every time the user logs on: Computer System Policy.
|
“
|
Computer refresh
|
Before Control-Alt-Delete: Computer local Group Policy only.
After the user logs on: Computer local Group Policy and computer System Policy.
|
“
|
User: Windows NT 4.0
|
When the user logs on: User System Policy.
If local Group Policy changes: User local Group Policy and user System Policy.
|
“
|
User refresh
|
User local Group Policy and user System Policy.
|
|
|
(continued)
|
Environment
|
Account Object Location
|
What Affects the Client
|
Mixed (migration)
|
Computer: Windows NT 4.0
|
At computer startup: Computer local Group Policy (only if changed).
Every time the user logs on: Computer System Policy.
|
|
Computer refresh
|
Before Control-Alt-Delete: Computer local Group Policy only.
After the user logs on: Computer local Group Policy and computer System Policy.
|
|
User: Windows 2000
|
When the user logs on: Group Policy is processed after computer System Policy.
|
|
User refresh
|
User Group Policy.
|
Mixed (migration)
|
Computer: Windows 2000
|
During system startup: Group Policy.
|
|
Computer refresh
|
Computer Group Policy
|
|
User: Windows NT 4.0
|
When the user logs on: User System Policy.
If local Group Policy changes: User local Group Policy and user System Policy.
|
|
User refresh
|
User local Group Policy and user System Policy.
|
Windows 2000
|
Computer: Windows 2000
|
During computer startup and when the user logs on: Group Policy.
|
|
User: Windows 2000
|
|
Windows 2000 in a workgroup (without Active Directory)
|
Local
|
Local Group Policy only.
|
Note: When the computer account object exists in a Windows NT 4.0 domain and the user account object exists in a Windows 2000 domain, computer System Policy is processed when the user logs on. It is recommended that you move out of this mixed processing mode and into a pure Windows 2000 mode as quickly as possible.
Upgrading Computer or User Accounts from Windows NT 4.0 to Windows 2000
While the user or computer accounts were managed by a Windows NT 4.0 domain controller, the registry on the client computers may have been altered outside the approved Group Policy trees. When a domain controller holding either the user or computer accounts is upgraded to Windows 2000, these settings remain on the client computers unless the administrator undoes them by means of System Policy or by doing a clean install of Windows 2000 on the client computers.
For example, consider the following migration scenario:
Start with a Windows NT 4.0 domain with Windows NT 4.0 clients, and create and apply System Policies.
Upgrade one client to Windows 2000.
Verify that the System Policies are applied to the Windows 2000 client. The Windows 2000 client registry has now been tattooed with those System Policies. This is because System Policies have no mechanism for cleaning up registry entries that should no longer be applied. (This is referred to as tattooing the registry.)
Upgrade the Windows NT 4.0 PDC to Windows 2000 DC.
Make sure the user account and the computer are in a Windows 2000 domain.
Modify the System Policies NTconfig.pol and resave.
In this case, the System Policies changes made in step 6 will not apply to the client because Windows 2000 clients do not process System Policies when both the user and computer accounts are in a Windows 2000 domain.
Try to avoid this situation by performing a clean installation of Windows 2000. To facilitate a clean installation, you can use the User State Migration Tool to migrate the users’ data and settings to the new installation. Note that this tool can be customized to make changes in the registry, allowing you to clean up tattooed System policy settings. The User State Migration Tool will be available in the Windows 2000 Server Resource Kit, Supplement One. See http://www.reskit.com/ for details.
If a clean installation is not possible, consider using Regini.exe (available in the Resource Kit) to modify the registry settings.
For a comparison of the policy-related namespace in Windows NT 4.0, the Zero Administration Kit, and Windows 2000, see Appendix D in this document.
|
