Microsoft Windows XP Professional Resource Kit 2003
ISBN: N/A
EAN: N/A
EAN: N/A
Year: 2005
Pages: 338
Pages: 338
On a network not running the Active Directory directory service, you can implement the following IntelliMirror and Group Policy features to manage Windows XP Professional and Windows 2000 desktops:
Roaming User Profiles and logon scripts (Microsoft Windows NT version 4.0 domains).
Folder Redirection.
Internet Explorer Maintenance.
System Policy.
Local Group Policy object.
In a Windows NT 4.0 domain, both roaming user profiles and logon scripts are configured on the user object.
On a Windows NT 4.0 Server network you can redirect My Documents and its subfolders, Application Data, Desktop, and the Start menu to a local or network location by using the following methods:
You can use System Policy to redirect these folders. This will provide only limited functionality compared with true Folder Redirection, because you cannot actually move folder contents or set ACLs.
Users can manually redirect the My Documents folder by changing the target folder location in the My Documents Properties page.
Manipulation of registry settings.
Note that you cannot configure Folder Redirection by using an LGPO.
Instead of using Group Policy to control Internet Explorer settings, you can use the Internet Explorer Administration Kit (IEAK) to apply settings to Internet Explorer clients by using auto-configuration packages. To download the IEAK, see the Microsoft Internet Explorer Administration Kit (IEAK) link on the Web Resources page at http://www.microsoft.com/windows/reskits/webresources
Like Active Directory-based Group Policy objects, System Policy can define a specific user s settings or the settings for a group of users. The resulting policy file contains the registry information for all users, groups, and computers that will use the policy file. Separate policy files for each user, group, or computer are not necessary.
Group Policy includes the functionality from Windows NT 4.0 System Policy. It also provides additional policy settings for scripts, Software Installation and Maintenance, security settings, Internet Explorer maintenance, and folder redirection. Table 5-6 provides an overall comparison of Group Policy and Windows NT 4.0 System Policy.
| Comparison | Group Policy | Windows NT 4.0 System Policy |
|---|---|---|
| Tool used: | Microsoft Management Console (MMC) Group Policy snap-in. | System Policy Editor (Poledit.exe). |
| Number of settings: | More than 150 security-related settings and more than 620 registry-based settings. | 72 settings. |
| Applied to: | Users or computers in a specified Active Directory container (site, domain, or OU) or local computers and users. | Domains or local computers and users. |
| Security: | Secure. | Not secure. |
| Extensible by: | Using Microsoft Management Console (MMC) or .adm files. | Using .adm files. |
| Persistence: | Does not leave settings in the users profiles when the effective policy is changed. | Persistent in users profiles until the specified policy is reversed or until you edit the registry. |
| Defined by: | User or computer membership in security groups. | User membership in security groups. |
| Primary uses: | Implementing registry-based settings to control the desktop and user. Configuring many types of security settings. Applying logon, logoff, startup, and shutdown scripts. Implementing IntelliMirror Software Installation and Maintenance. Implementing IntelliMirror data and settings management. Optimizing and maintaining Internet Explorer. | Implementing registry-based settings that govern the behavior of applications and operating system components such as the Start Menu. |
| Warning | System Policy settings applied to computers that have been upgraded to Windows XP Professional are persistent in ( tattoo ) the registry. Applying Group Policy to a computer with persistent registry-based System Policy settings might have unpredictable results. It is recommended that you remove these settings from computers before applying GPOs. |
Windows XP Professional based clients in an Active Directory domain can process Group Policy but cannot process Windows NT 4.0 System Policy. Windows NT 4.0 policies are persistent in user profiles. This means that after a registry-based setting is applied using Windows NT 4.0 System Policy, the setting persists until the specified policy is reversed or you edit the registry to remove the corresponding entry. The effect of persistent registry-based settings can cause conflicts when a user s group membership changes. If the Windows XP Professional computer account object or user account object that you manage exists in a Windows NT 4.0 domain, you can still use certain System Policy tools to manage them.
| Note | You can use System Policy to deliver any of the registry-based policy settings (Administrative Templates) that are available in Windows XP Professional. The procedures described in the following subsections also work for providing System Policy from any Server Message Block (SMB) enabled share or even from a local share. |
To create a policy that is automatically downloaded from validating domain controllers, you must create a .pol file by using the System Policy Editor:
For Windows NT 4.0 and later, the .pol file is named Ntconfig.pol and is created using the System Policy Editor for the specific operating system.
For Windows 95, Windows 98, and Microsoft Windows Millennium Edition (Windows Me), the .pol file is named Config.pol and must be created by using the System Policy Editor for that operating system.
As system administrator, you can choose an alternate name for the .pol file and can direct the computer to update the policy from a path other than the Netlogon share. You can do this by using System Policy. The update path can even be a local path, so that each computer has its own policy file. However, you must make this change manually on each desktop. For more information about specifying a path to the policy file, see Specifying a Path to the Policy File later in this chapter.
The System Policy Editor tool uses files called administrative templates (.adm files) to determine which registry settings you can modify and which settings display in the System Policy Editor.
In Windows XP Professional and Windows 2000, the Administrative Templates item in the Group Policy snap-in uses administrative templates (.adm files) to specify the registry settings that can be modified through the Group Policy snap-in. This includes Group Policy for the Windows XP Professional operating system and its components as well as for applications.
Policy settings are written to the following locations in the registry:
HKEY_CURRENT_USER\Software\Policies (preferred location)
HKEY_LOCAL_MACHINE\Software\Policies (preferred location)
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies
| Caution | Do not edit the registry unless you have no alternative. The registry editor bypasses standard safeguards, allowing settings that can damage your system, or even require you to reinstall Windows. If you must edit the registry, back it up first and see the Registry Reference in the Microsoft Windows 2000 Server Resource Kit at http://www.microsoft.com/reskit To configure or customize Group Policy, use the Group Policy snap-in whenever possible. |
A client running Windows XP Professional or Windows 2000 processes System Policy if the user or computer account, or both, are in a Windows NT 4.0 domain. 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.
| Warning | It is possible for a computer account object to exist in a Windows NT 4.0 domain and a user account object for a user of that computer to exist in an Active Directory domain, or vice versa. However, operating in such a mixed environment makes the users and computers difficult to manage and might cause unpredictable behavior. For optimal central management, it is recommended that you move from a mixed environment to a pure Active Directory environment. |
A Windows XP Professional based client processes System Policy if either the user or computer account exists in a Windows NT 4.0 domain. When a user logs on to a Windows XP Professional based client in a Windows NT 4.0 domain and the client is running in the default Automatic mode, 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 user, group, and computer policy data, and then applies the appropriate settings. If the client does not locate the policy file on its validating domain controller, it does not check elsewhere. It is therefore critically important that the Ntconfig.pol file is replicated among the domain controllers performing authentication.
In the absence of a Windows NT 4.0 domain, you can configure the client to look for the Ntconfig.pol file in a specific location on the local computer or on any SMB share location. For more information about specifying a path to the policy file, see Specifying a Path to the Policy File later in this chapter.
You can create Ntconfig.pol files based on the Windows XP Professional .adm files and apply these settings to Windows XP Professional based clients. To do this, you need the Windows NT 4.0 System Policy Editor tool, Poledit.exe, which is installed with Windows 2000 Server and Advanced Server. You can install Poledit.exe on Windows XP Professional based computers by installing the Administrative Tools package that is included on the Windows 2000 Server and Microsoft Windows 2000 Advanced Server operating system CDs.
To install Administrative Tools on a Windows XP Professional based 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 Administrative Tools setup wizard.
When you install the Administrative Tools package, Poledit.exe and its supporting .adm files (Winnt.adm, Windows.adm, and Common.adm) are installed into the root \System directory and the \Inf directory, as in Windows NT 4.0. Poledit.exe is not added to the Start menu, but it is accessible from the command line.
Use the following procedure to create an Ntconfig.pol file.
| Note | The System Policy Editor from Windows NT 4.0 or earlier cannot read the Unicode-formatted .adm files shipped in Windows 2000 or later. You must use the version of System Policy Editor that ships in Windows 2000 or later, which supports Unicode. Alternatively, if you resave the .adm files as .txt files without Unicode encoding, you can use an older version of Poledit.exe. |
To create an Ntconfig.pol file
Using a text editor such as Notepad, remove all #if version and #endif statements from the following .adm files: System.adm, Inetres.adm, and Conf.adm, and then save the files. This prevents inadvertent loading of these files by Poledit.exe.
For example, in the Inetres.adm file, remove these lines:
#if version <= 2
#endif
Open Poledit.exe.
In the System Policy Editor window, on the Options menu, click Policy Template.
In the Policy Template Options dialog box, click Add, select one of the .adm files that you modified in step 1 above, and then click OK.
Specify the appropriate policy settings, as documented in System Policy Editor Help.
Save the file as Ntconfig.pol to the NETLOGON share of the Windows NT 4.0 domain controller.
You can change the default behavior so that a Windows XP Professional based client looks for the policy file in a different location than the Netlogon share. The UpdateMode registry entry forces the computer to retrieve the policy file from a specific location (expressed as a UNC path), regardless of which user logs on.
You can set UpdateMode by using the System Policy Editor and the System.adm file.
To retrieve the policy file from a specific location
Open Poledit.exe.
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 then double-click Default Computer from the Policies for list.
or
To open the Local Computer policy, on the File menu, click Open Registry, and then double-click Local Computer.
In the Properties dialog box, expand Network, and then expand System policies update to display the Remote update option.
Select the Remote update box.
In the Update mode drop-down menu, select Manual (use specific path).
In the Path for manual update text box, type the UNC path and file name for the policy file, then click OK to save your changes.
The first time the Windows XP Professional based client is modified locally by 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, the Windows XP Professional based client does not look at a domain controller again to find a policy file, and all policy updates use the location you specified manually. Note that this change is permanent until you edit the policy file to reset the option to Automatic.
In addition to setting System Policy, you can set settings in the local Group Policy object (LGPO) for any computer, whether or not it participates in an Active Directory domain. Although System Policy scales more easily to a large number of clients, the LGPO can be useful if you only need to apply certain settings to a small number of Windows XP Professional based clients in a Windows NT 4.0 or other domain.
The LGPO is located at \systemroot\System32\GroupPolicy. Not all Group Policy extensions are available for the local GPO. Each Group Policy extension snap-in queries the Group Policy engine to get the GPO type, and then determines whether the GPO is to be displayed. To set the LGPO, use the Group Policy snap-in focused on the local computer.
Table 5-7 shows which Group Policy snap-in extensions open when the Group Policy snap-in is focused on an LGPO.
| Group Policy Snap-in Extension | Available in LGPO |
|---|---|
| Software Installation | No |
| Scripts | Yes |
| Security Settings | Yes |
| Administrative Templates | Yes |
| Folder Redirection | No |
| Internet Explorer Maintenance | Yes |
| RIS | No |
You can access the Group Policy snap-in by using the following procedure.
To start the Group Policy snap-in on a Windows XP Professional based client
In the MMC window, on the File menu, click Add/Remove Snap-in.
On the Standalone tab, click Add.
In the Add Standalone Snap-in dialog box, click Group Policy, and then click Add. The Group Policy Wizard appears.
Select Local Computer to edit the local GPO, or click Browse to select another computer.
Click Finish.
In the Add Standalone Snap-in dialog box, click Close.
In the Add/Remove Snap-in dialog box, click OK.
The Group Policy snap-in opens with focus on the specified GPO. If you select Local Computer, you see Local Computer Policy. Expand the tree to see Computer Configuration and User Configuration.
To quickly access the local Group Policy object, type gpedit.msc in the Run dialog box.
| Note | The Security Settings extension of the Group Policy snap-in does not support remote management for the local Group Policy object in Windows XP Professional. |
You can use LGPOs and System Policy to manage Windows XP Professional Desktops in Novell and UNIX environments. For example, NTConfig.pol can exist on any network server. You can perform typical desktop-management tasks that are based on industry-standard protocols, such as Telnet and Simple Network Management Protocol (SNMP), a standards-based TCP/IP network management protocol that is implemented in many environments. For more information about using LGPOs and System Policy, see Managing Desktops Without Active Directory, earlier in this chapter.
Windows XP Professional provides full support for SNMP, allowing you to easily manage systems that run Windows XP Professional by using a UNIX-based SNMP management suite available from independent software vendors.
You can use Telnet to remotely log on to and execute commands on a Windows XP Professional based or UNIX-based system. The Telnet client included with Windows XP Professional is character-and console-based and is enhanced for advanced remote management capabilities.
The Windows XP Professional based Telnet client also provides NTLM authentication support. With this feature, a Windows XP Professional Telnet client can log on to a Windows XP Professional Telnet server that uses NTLM authentication.
Internetwork Packet Exchange (IPX) is the native NetWare protocol used on many earlier Novell networks. You can integrate Network Connections clients into a NetWare IPX network, with the exception of clients running Microsoft Windows XP 64-Bit Edition.
The client must run a NetWare redirector to see a Novell NetWare network. This redirector is called Client Service for NetWare (CSNW).
A remote access server is also an IPX router and Service Advertising Protocol (SAP) agent. Once configured, remote access servers enable file and print services and the use of Windows Sockets programs over IPX on the NetWare network for Network Connections clients. Remote access servers and their Network Connections clients use the Point-to-Point (PPP) IPX Control Protocol (IPXCP), as defined in RFC 1552, The PPP Internetwork Packet Exchange Control Protocol (IPXCP), to configure the remote access line for IPX.
Network Connections clients are always provided an IPX address by the remote access server. The IPX network number is either generated automatically by the remote access server, or a static pool of network numbers is given to the remote access server for assignment to Network Connections.
For automatically generated IPX network numbers, the remote access server uses the NetWare Router Information Protocol (RIP) to determine an IPX network number that is not in use in the IPX network. The remote access server assigns that number to the connection.
Configure a connection by selecting NWLink IPX/SPX/NetBIOS Compatible Transport Protocol on the General tab of Local Area Connection Properties.
To use Novell ZENworks, you must register Windows XP Professional with ZENworks. A workstation record can then be imported into the Novell Directory Services (NDS) database of a Novell NetWare network. The workstation is registered by running Wsreg32.exe either from the command line or from a logon script. The following is an example of the logon script code that detects Windows XP Professional and runs the correct registry program:
IF " %PLATFORM" =" WINDOWS_NT" THEN BEGIN
#F:\PUBLIC\WSREG32.EXE
END
After the workstation is registered, you can import it into NDS by using Nnwadmn32.exe.
You can administer Windows XP Professional based clients by using the standard ZENworks tools.