Policy Application via Remote Access or Slow Links

You will certainly have situations in which clients use Windows 2000 and Windows XP to make inbound remote access connections to your Active Directory. Both client systems, by default, will detect the speed of the connection and make a snap judgment about whether to process Group Policy. If the machine uses TCP/IP to connect to RAS (Remote Access Service), it is considered "fast enough" to process Group Policy if the connection is 500 kilobits or greater. If the connection is deemed fast enough, portions of Group Policy are applied.

Surprisingly, even if the connection is not deemed fast enough, several sections of Group Policy are still applied. Security settings, Software Restriction Policy settings (Windows XP only), and Administrative Templates are guaranteed to be downloaded during logon over an RAS connection-regardless of the speed. And there's nothing you can do about it. Additionally, included in security settings are EFS (Encrypting File System) Recovery Policy and IPSec policy. They are also always downloaded over slow links.

Warning 

The Group Policy interface suggests that downloading of EFS Recovery Policy and IPSec policy can be switched on or off over slow links. This is not true. (See the note in the "Using Group Policy to Affect Group Policy" section later in this chapter.)

If the user connects using RAS before logging on to the workstation (using the "Logon Using Dial-Up Connection" check box as seen in Figure 3.2), the security and Administrative Templates policy settings of the Computer node of the GPO are downloaded and applied to the computer once the user is authenticated. Then, the security and Administrative Templates policy settings of the User node of the GPO are applied to the user .

Figure 3.2: If you select "Log on using dial-up connection," you first process GPOs in the foreground (when Fast Boot is disabled).

If the user connects using RAS after logging on to the workstation (using the "Network and Dial-up Connections" icons), the security policy settings and the Administrative Templates policy settings for the user and computer are not applied right away; rather they are applied during the next normal background refresh cycle (every 90 minutes by default).

Other sections of Group Policy are handled as follows during a slow connection:

• Internet Explorer Maintenance Settings These are not downloaded by default over slow links. (You can change this condition using the information in the "Using Group Policy to Affect Group Policy" section later in this chapter.)

• Folder Redirection Settings These are not downloaded by default over slow links. (You can change this condition using the information in the "Using Group Policy to Affect Group Policy" section later in this chapter.)

• Scripts (Logon, Logoff, Startup, and Shutdown) These are not downloaded by default over slow links. (You can change this condition using the information in the "Using Group Policy to Affect Group Policy" section later in this chapter.) Also see the sidebar "Processing and Running Scripts over Slow Links" later in this chapter.

• Disk Quota Settings These are not downloaded by default over slow links. (You can change this condition using the information in the "Using Group Policy to Affect Group Policy" section later in this chapter.) The currently cached disk quota settings are still enforced.

• Software Installation and Maintenance These are not downloaded by default over slow links. More specifically , the offers of newly available software are not shown to users. Users do have the ability to choose whether to pull down the latest versions of applications at their whim, as detailed in Chapter 10. You can torture your dial-in users by changing the behavior of how offers are handled and permit the icons of new software to be displayed. They will hate you after you do this, but that is for you and them to work out. See the corresponding setting described later in this chapter in the "Using Group Policy to Affect Group Policy" section.

• Software Restriction Policy (Windows XP and Windows 2003 Only) These are guaranteed to download over slow links. You cannot turn off this ability.

• 802.11 Wireless Policy (Windows XP and Windows 2003 Only) These are not downloaded by default over slow links. (You can change this condition using the information in the "Using Group Policy to Affect Group Policy" section later in this chapter.) The currently cached 802.11 policy settings are still enforced.

• Administrative Templates These are guaranteed to download over slow links. You cannot turn off this ability.

• EFS Recovery Policy These are guaranteed to download over slow links. You cannot turn off this ability. The interface has an option that makes it appear as if you could turn off this ability, but you can't.

• IPSec Policy These are guaranteed to download over slow links. You cannot turn off this ability. The interface has an option that makes it appear as if you could turn off this ability, but you can't.

What is considered fast enough for all these policy categories can be changed from 500Kb to whatever speed you desire (independently for the computer half and the user half), as detailed in the "Using Group Policy to Affect Group Policy" section later in this chapter.

Processing and Running Scripts Over Slow Links

If your users try to run scripts while using slow links, they (and you) might notice some interesting behavior. First, computer startup scripts will not run over slow links. This just isn't supported by the Group Policy engine.

However, one enterprising customer of mine had a service written to explicitly do this after the user was logged on. That said, logon scripts are currently still fair game. However, many factors play into whether the scripts will run.

When a user is dialed in over a slow link, the scripts policy itself will not process. That is, it will not receive information about new or updated scripts. The actual running of the scripts is a different matter altogether and is irrespective of whether the use has a slow connection. There fore, if you applied the script policy while on a high-speed connection (for example, a home office LAN) and then a user should log on over a dial-up connection, scripts will indeed run; the script policy has already been download and set for takeoff. Indeed, your script policy might tell the client to execute the script from the server, which may or may not be available.

But until your users come back to the headquarters, they won't get updates to that script policy if any has occurred. For instance, if the script policy states to run the script from an alternate server location, this information won't be downloaded until they come back into headquarters.

Windows 2000 and Windows XP have slightly different behavior for the actual running of the scripts. Windows 2000 requires that the SYSVOL (NETLOGON share) be accessible for the scripts to even attempt to run. If the machine cannot see SYSVOL, no scripts will run.

Windows XP and Windows 2003 have addressed this problem, but it's thorny. If the machine is 100% offline (and, hence, SYSVOL isn't available), the scripts will indeed run. But if the system determines it's on a fast connection and SYSVOL is unavailable, scripts won't run.