No, unfortunately, current ADM syntax doesn’t support populating HKEY_USERS. However, you can use a round-about approach if you really need to populate these keys using Group Policy. Specifically, you can modify the security options policy area found under Computer Configuration|Windows Settings|Security Settings|Local Options|Security Options. This is described in more detail in the following KB article http://support.microsoft.com/default.aspx?scid=kb;en-us;214752

If your custom ADM populates registry entries that are considered “preferences” rather than policies (see my explanation of Tattooing for more information of the difference) then, by default, the GP Editor will not show the policy items. In order to see them, you have to un-filter them by selecting View, Filtering, and un-checking the box that says, “Only show policy settings that can be fully managed”. Note that there is no way to save this filter setting in between GP editor sessions. You have to re-select it each time you enter the GP Editor tool.

The following site maintains a pretty good list:

http://social.technet.microsoft.com/wiki/contents/articles/4976.aspx.

The two profiles govern the behavior of the Windows Firewall that ships with SP2 when the machine is in different network settings. While it may seem obvious, based on the name, when one profile is in effect over the other, the mechanism that Windows uses can sometimes be a little less than intuitive. Specifically, the domain profile is determined to be in effect when the following conditions are true:

The computer in question is a member of a domain (otherwise standard profile is always used)
During the last Group Policy update, if the DNS suffix of the connection over which the GP update came is the same as the DNS suffix of the current non-PPP (i.e. VPN or Dial-up) connection. For example. Let’s say that during the last GP update, my computer received policy from the “Local Area Network” Connection, which has a DNS suffix of myaddomain.com. That value is then recorded in the registry and compared to the current DNS suffix of the currently active non-PPP connection. If the suffixes are the same, its assumed that I’m still on the “managed” domain network. If not, then its assumed that I’m not on the “managed” network so the standard profile is applied.

In fact, there is. You can launch the GP Editor directly against a domain-based GPO from the command line using the following format:

gpedit.msc /gpobject:”LDAP://CN={GUID of the GPO},CN=Policies,CN=System,DC=<domain>

For example, if my domain name is test.com and the GPO I wish to edit is the Default Domain Policy, I can use the following command:

gpedit.msc /gpobject:”LDAP://CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Policies,CN=System,DC=test,DC=com

A WMI filter takes the form of a WMI Query, using the WMI Query Language (WQL). However, you must preface your query with the name of the WMI namespace you will be accessing. For example, if I wanted to query for all machines running XP, SP2, my WMI Filter would look like this:

root\cimv2;Select * FROM Win32_OperatingSystem WHERE Build= 2600 AND CSDVersion = "Service Pack 2"

In this filter, I’m starting off by telling Windows that I want to perform a query against a WMI class that resides in the root\cimv2 namespace. After following that with a semicolon, I enter my WQL query. In the example above, I’m selecting all instances of the Win32_OperatingSystem class (there is only one on a given Windows system) whose properties Build and CSDVersion equal 2600 (the build # for XP) and “Service Pack 2″. The best tool I’ve found for checking out the name of various WMI classes and their properties is the WMI browser, which is part of the WMI Tools download available at http://www.microsoft.com/downloads/details.aspx?FamilyID=6430f853-1120-48db-8cc5-f2abdc3ed314&DisplayLang=en.

Note that my WMI Filter Validation Tool on the Tools page lets you view, print and validate WMI filters against systems in your environment.

Wireless Network Policy was first added in Server 2003 and requires the Server 2003 AD schema to be installed in order to create GPOs that leverage this policy. That being said, systems running XP, SP1 and greater added the ability to process Wireless network policy but not edit it. However, you can easily remedy this situation with the following steps. Copy the following three files from a Server 2003 installation’s c:\windows\system32 folder to c:\windows\system32 on the XP machine where you plan to edit your GPOs:

wlsnp.dll
wlstore.dll
ws03res.dll

From a command prompt on the XP machine, change to the system32 directory and issue the following command:

regsvr32 wlsnp.dll

This command will register the Wireless Network Policy editor MMC snap-in extension and you should be able to edit Wireless policy from XP at that point.

There are several reasons that I’ve seen that cause this error. In cases where computer policy processing is failing with this error but user policy processing is occurring just fine, it could be a network stack timing issue. In that case, check out http://support.microsoft.com/default.aspx?scid=kb;en-us;840669

In cases where its just failing outright for all policy there are at least two other possible reasons for this. The first is that one or more SYSVOL replicas on your DCs are not replicating correctly and the gpt.ini file is actually missing from a given DC that the client is hitting. In this case, Windows is not smart enough to failover to another DFS replica (SYSVOL is just a system-maintained DFS replica) and GP processing will simply fail. In that case, the quickest solution is to copy the contents of the failing GPO from a known-good copy of it on another DC. The last reason I’ve seen for this failing is when you’ve implemented a restrictive security policy on the client that is processing GPO. For example, if you implement one of the “High Security” templates from the Server 2003 security guide, which may require, for example, SMB signing of all network traffic between server and client. In that case, if the server does not support that requirement, basic file communications between the client processing GP and server will fail. Usually the solution there is to apply a less restrictive security template to the client processing GP (or to the DC serving up GP if the change was made on the DC side)

When you remove the machine from the domain, the GP settings remain and, since its no longer in the domain, only the local GPO will process. That means that unless the local GPO overrides those domain-based settings, they will remain “tattooed” on your system indefinitely. The best way to handle that is to either move the machine outside of the scope of GP settings before removing it from the domain and let it process the removal of policies, or use the local GPO editor to override the settings on the machine as it exists right now.

The following KB article, http://support.microsoft.com/default.aspx?scid=kb;en-us;831201, describes a hotfix that you can use to modify your DCs to make the logon server always be at the top of the DFS referral list. This guarantees that the DC that your workstations use for authentication and AD access is the same as the one they use for SYSVOL, since SYSVOL is just another DFS replica set.

When you remove the machine from the domain, the GP settings remain and, since its no longer in the domain, only the local GPO will process. That means that unless the local GPO overrides those domain-based settings, they will remain “tattooed” on your system indefinitely. The best way to handle that is to either move the machine outside of the scope of GP settings before removing it from the domain and let it process the removal of policies, or use the local GPO editor to override the settings on the machine as it exists right now.

Loopback policy is a special mode of policy processing that allows you to control what user policy a user receives based on the machine they are logging onto rather than their user account. It is used most often in Terminal Server or “Kiosk” environments, since in both of these situations you want to tightly control the user lockdown of any users logging onto these special-use machines. Loopback is configured on the designated computers that your users will be logging onto. You can enable Loopback by setting the computer-based policy found at Computer Configuration\Administrative Templates\System\Group Policy\User Group Policy loopback processing mode. Loopback comes in two flavors–merge mode and replace mode. These different modes are described in the next question.

There is no detailed auditing supported in Windows today, for Group Policy changes, that will tell you which GPO setting was changed. However, you can tell when something on a GPO was changed and who made the change by using native Active Directory auditing. Specifically, if you enable auditing for Directory Service Access events on you domain controllers, then each time a GPO is changed, you will see an audit event in the security log on the PDC emulator DC (by default, this is where GP changes are originated unless the administrator changes it in the GP Editor). The event you see will show up as event ID #566 and will show a change to a groupPolicyContainer type of object. And while the friendly name for the GPO will not appear in the event description, the GUID of the GPO will be listed in the Object Name field, allowing you to determine which GPO it is by simply going into GPMC and looking for that GUID.

The duplicate GPO processing is a function of using Loopback policy in merge mode only (replace mode doesn’t cause this). What is going on is, with replace mode, Windows basically says, don’t do any user-specific policy processing for the user logging into a loopback machine. So basically any GPOs that would normally be processed by the user, including local, site, domain and OU- linked ones, are just not processed in replace mode. Instead, all user settings come from any GPOs that apply to the loopback computer, including those linked at the local, site, domain and OU level. By contrast, merge mode says, first process all user GPOs that the user account would normally get. Then, process all user GPOs that the loopback computer would normally get. So, what that means is that policies that are higher in the hierarchy, like site and domain-linked GPOs that are processed both by the computer and the user, get processed twice. Since the computer-based loopback user settings process last, the result would normally be that any conflicting user-specific settings (like Admin. Template registry settings) would be overridden by the loopback computer settings. And that happens, however, certain policy extensions, like scripts or software installation, don’t exhibit override behavior. If two scripts are in the path to be processed, they will process cumulatively rather than one overriding the other. Hence the reason you see logon scripts running twice.

These terms refer to whether or not Group Policy processing occurs while other things are happening in Windows. For example, if computer-specific foreground processing is set to run asynchronously (as is the case by default in XP but not Windows 2000) then as Windows initially boots up, it will not wait for GP processing to finish before presenting a user logon dialog. Similarly, if user-specific foreground processing is set to run asynchronously, Windows will not wait for GP processing to finish before presenting the user’s desktop. Asynchronous can speed up the startup and logon process but can also result in certain policy extensions (e.g. Folder Redirection, Software Installation) require two or more foreground processing events to take effect. A foreground processing event is a computer startup or user logon. When foreground processing is set to synchronous, then Windows waits for computer or user GP processing to complete before presenting the user a logon dialog or a desktop, respectively.

Group Policy processing requires the following protocols and ports to be open between client and Domain Controller:

–

You can configure RPC/DCOM to use a restricted set of high-level (>1024) by making changes to a client’s registry. See http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndcom/html/msdn_dcomfirewall.asp for more details.

Yes! In fact, when GPMC is installed, it registers new MMC property sheets for Group Policy tab within AD Users and Computers. However you can simply remove those new property sheet references from the registry and point it back to the old GPO property sheet. This won’t affect GPMC functionality but will return the old GPO dialogs that you had before GPMC was installed. To make this change, you’ll need to change the values under multiple keys, as follows (remember to back up your registry first in case you need to undo these changes):

In the first key,

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MMC\NodeTypes\{bf967aa5-0de6-11d0-a285-00aa003049e2}\Extensions\PropertySheet

delete the value that is there that refers to Group Policy Management and add a value with the following name, type and data:

{D70A2BEA-A63E-11D1-A7D4-0000F87571E3} REG_SZ = "Group Policy"

In the second key,

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MMC\NodeTypes\{bf967ab3-0de6-11d0-a285-00aa003049e2}\Extensions\PropertySheet

delete the value that is there that refers to Group Policy Management and add a value with the following name, type and data:

{D70A2BEA-A63E-11D1-A7D4-0000F87571E3} REG_SZ = "Group Policy"

The following additions to this item courtesy of Mika Seitsonen:

The following reg file can also be used to re-add the Group Policy tab to the domain, OU and site objects:

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MMC\NodeTypes\{19195a5b-6da0-11d0-afd3-00c04fd930c9}\Extensions\PropertySheet]
"{D70A2BEA-A63E-11D1-A7D4-0000F87571E3}"="Group Policy"
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MMC\NodeTypes\{bf967aa5-0de6-11d0-a285-00aa003049e2}\Extensions\PropertySheet]
"{D70A2BEA-A63E-11D1-A7D4-0000F87571E3}"="Group Policy"
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MMC\NodeTypes\{bf967ab3-0de6-11d0-a285-00aa003049e2}\Extensions\PropertySheet]
"{D70A2BEA-A63E-11D1-A7D4-0000F87571E3}"="Group Policy"

Also, Mika notes, “And if you want to have both options and consequently two Group Policy tabs, just leave both values ” meaning that you can have both the GPMC and old Group Policy tabs appear in AD U&C by simply not deleting the property sheet references to the GPMC.

Absolutely, by default, the file brndlog.txt is created in the logged on user’s profile, under Application Data\Microsoft\Internet Explorer. This file stores information about IE Maintenance processing. This folder also stores the cached IE maintenance policy settings that are downloaded from SYSVOL at GP processing time.

This is a known issue in IE Maintenance policy where it sometimes does not correctly read that the policy has changed, and therefore, does not properly apply the policy. The workaround for this is to enable the following administrative template policy for all computers that you wish to enforce IE maintenance policy against: Computer Configuration\Administrative Templates\System\Group Policy\IE Maintenance Policy Processing\Process even if the Group Policy Objects have not changed.

Put simply, when you set IE Maintenance Policy in preference mode, you aren’t really enforcing the policy, but rather, setting it once, and then leaving it up to the user whether or not they wish to change that policy. For example, if you set a proxy server address within IE using preference mode, you are setting the proxy address the first time the user processes that policy but then letting them change it without the policy being reinforced at the next processing interval. Its like saying, “I’d like to you have this policy setting, but you’re free to change it if you’d like.”

Strangely, when you edit certain sections within IE Maintenance policy, the GP editor calls the live dialogs on your local machine. This typically occurs in areas within IE Maintenance where you can import settings, such as the Security zones section and Connection Settings section. If you edit these areas, you are actually editing the configuration of IE on the machine where you’re doing the editing. This can be somewhat disconcerting! After importing the settings into the policy, you’ll need to go back–outside of the GP editor, and change them back to the settings you need.

There is a known issue in XP, SP1 and Win2K earlier than SP4 where using this feature in Restricted Group Policy won’t work. Check out http://support.microsoft.com/default.aspx?scid=kb;en-us;Q810076 for information on a hotfix for XP. Note that there are two modes of operation for Restricted Groups policy. There’s the “Members” policy in the top box, which mandates that, for a given group, only those users/groups listed in this dialog may be members. Use this policy with caution because any members of the target group that aren’t in the list get removed the next time the GPO is processed. And administrative groups are excluded from this, meaning that you can very easily lock yourself out of a bunch of machine if you’re not careful. The second part of Restricted Groups is the “Members of”. This is where you can optionally ensure that the selected group is made of a member of a list of other groups. This membership in the local Administrators group is what was fixed by the hotfix noted above. Note also that if you use Restricted Groups policy on a GPO that is targeted by a Domain Controller, then the groups whose membership you are effecting reside in AD and thus this policy has an impact on AD replication and group membership (esp. in pre-Win2K3 environments where group membership is replicated as a single attribute).

Yes, in fact security policy is one of those anomalies with respect to the “Don’t process if the GPO hasn’t changed” rules. By default, security policy (which is defined as policy found in Computer Configuration|Windows Settings|Security Settings) will process every 16 hours in the background, even if the GPO hasn’t changed. This ensures that, for a critical area like security configuration, if the user has made a change on the local system that contravenes policy, that change will be undone on a periodic basis. You can actually modify this background refresh interval by editing the following registry value:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions\{827D319E-6EAC-11D2-A4EA-00C04F79F83A}\MaxNoGPOListChangesInterval

This value is stored as a hexadecimal number that represents the number of minutes between background refreshes.

When security policy is processed, Windows uses the secedit security configuration engine to process Group Policy-based security policy. Part of this processing relies on using a local security database, found on each Windows system, called secedit.sdb. This file is found, by default, in c:\windows\security\database. Occasionally this database can get corrupted and prevent security policy from applying on that machine. You can check for this by running the following command:

esentutl /g c:\windows\security\database\secedit.sdb

If the command finds errors you can use the esentutl utility’s /p option to attempt to repair the file.

There’s two ways to find out what software restriction policy is up to. First, software restriction policy rules should show events in the Application event log when they are fired. Those events have event IDs between 865 and 868 and show details of what process kicked of which SRP rule. If you need even more detail, you can enable verbose trace logging of SRP by modifying the registry on the system receiving the policy. This is done by creating the following registry key, if it doesn’t already exist:

KEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers

and adding a registry value to that CodeIdentifiers key, of type REG_SZ, called LogFileName. In the LogFileName value, enter a path to a log file name (any path and filename you want). For example, you could enter: c:\logs\srplog.txt in this value and the SRP trace log would be stored in that file.

Yes, but there are some limitations involved. There is a way to deploy legacy .exe setups for use in GPO-based software deployment using something called a ZAP (Zero Application Packaging) file. A ZAP file is simply an INI style file with a .zap extension. However, ZAP files have two significant limitations:
They can only be published per-user–they can not be assigned to computer or user.
They do not benefit from the privilege escalation feature that MSI-based packages do, when deployed via Group Policy. This means that the user who initiates the ZAP-based installation from Add/Remove Programs must have sufficient privilege to install the application
Beyond these two limitations. ZAP-based deployment can be a quick and dirty way to get an application distributed without having to take the time to re-package it into .MSI format. A little known fact is that when this feature was introduced in Windows 2000, Microsoft product team members referred to it as “Crappy ZAW”, where ZAW stood for Zero Admin. Windows–an old term from NT 4 days! In any case, here is a sample .zap file created to deploy Winzip 9.0:

[Application]
FriendlyName = "Winzip 9.0"
SetupCommand = "\\server\packages\winzip90.exe"
DisplayVersion = 9.0
[Ext]
ZIP=

This ZAP file is pretty self explanatory. The FriendlyName key represents what you see in Add/Remove Programs when you go to select the package. The SetupCommand key lists the UNC path to the setup .exe file (Note that this must be a UNC–a drive letter path won’t work). The DisplayVersion key is optional and shows the version of the application as it appears in the GPO. Finally, the extension section lists the extensions associated with this application. By using this EXT section, you guarantee that the application setup will automatically be started if the user clicks on a file with that extension (in this example, .zip), even if they don’t explicitly run the setup from Add/Remove Programs. This is sort of a poor man’s “install on first use” in the absence of a .MSI advertisement. Note that the command you provide should also include any appropriate switches if you want the installation to run silently. Otherwise, it will just run interactively, requiring the user to answer prompts along the way.

The answer is, there is no supported way to change a package path without impacting clients who have already received the package. This is because the path to the package is stored in a number of places, including in AD, in the .aas file found in the GPT portion of the GPO, and most notably, on the client. If you need to move a package to a new server, the best solution is to try and keep the server name the same (or alias the old server name) or better yet, use DFS for all of your packages so that you can move the package around without changing the path.

For any client machines that have installed the application that was deployed via GPO, when that application is redeployed, the client will essentially reinstall the application during its next foreground processing cycle. For example, if you redeploy an application that was machine assigned, at the next reboot of any client who had installed the application via that GPO, that client will perform a reinstallation of the application. Specifically what happens is the client is instructed to do a Windows Installer repair with the options omusv. Those options essentially reinstall most (but not all) major pieces of a package (for more details on what those options actually do, check out http://support.microsoft.com/default.aspx?scid=kb;en-us;314881). So, keep in mind that when you do a redeploy, all clients that had previously installed that application via the GPO will attempt to reinstall that application. This can sometimes have a big impact on the network if many clients are hitting a package on a server share nearly simultaneously.

Check out this post on the GPTalk mailing list for a variety of suggestions: http://www.freelists.org/archives/gptalk/02-2007/msg00083.html

Startup scripts are machine specific and run before a user logs on. As a result they run in the context of the localSystem account on a computer. As localSystem, they have privilege to do just about anything on a Windows system. If a startup script needs to access network resources (e.g. a server share) however, localSystem will not work. Given that, Group Policy will change the security context of the script to that of the machine’s computer account, which is a valid AD user (e.g. a machine named WorkstationA will have an account in AD called WorkstationA$–this account is hidden, but is represented by the computer object when you are viewing an AD domain). The machine account, just like any other user account in AD, is a member of the Authenticated Users and can thus access any network resources that a member of this group can. So, if you have a startup script that needs to access server resources, make sure that the computer’s machine account has permissions to access those resources.

Its a good question. The answer is no, you don’t have to go through a machine restart for the new shutdown script to be picked up. Even though scripts are only run during foreground processing, script policy is in fact processed in the background. In fact, Windows caches script information in the registry during policy processing, so if you add a new shutdown script policy while a machine is running, it will pick up that new script during background processing and will run it during the next shutdown. You can confirm that your workstations have picked up the new shutdown (or startup) script policy by looking under the following registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\System\Scripts

Or by looking in the following location for User Logon or Logoff scripts:

HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\System\Scripts

Yes, essentially you need to do three things to activate a script within a local GPO:
Copy script file into appropriate directory on local system.
Create or modify scripts.ini file to refer to script
Modify gpt.ini file to ensure local GPO is processed
For example, if you need to deploy a startup script to a number of systems, you will need to first copy your script file (e.g. .bat, .vbs or other) to %windir%\system32\GroupPolicy\Machine\Scripts\Startup. Next, you’ll need to create or edit the scripts.ini file within the %windir%\system32\GroupPolicy\Machine\Scripts folder. The scripts.ini file holds the name of the scripts that get called, and any command-line parameters that get passed. For example, the following scripts.ini file calls a script called startup.vbs with no parameters.

[Startup]
0CmdLine=startup.vbs
0Parameters=

If you have more than one script to call within the local GPO, then it will follow the first one as follows:

[Startup]
0CmdLine=startup.vbs
0Parameters=
1CmdLine=startup2.vbs
1Parameters= /%computername%

Once you’ve copied the script and edited the scripts.ini file, you need to ensure that the version of the local GPO is non-zero, and is incremented to account for the new script. This is a bit trickier because the file that holds the version information–called gpt.ini– will exist already within the local GPO under %windir%\system32\GroupPolicy. You’ll need to edit this file, parse the version= line and increment it. If you want to stick with the official incrementing scheme for Group Policy, then you need to increment the version number 1 for each machine-specific change you make (e.g. adding a startup script) and 65536 for each user-specific change (e.g. adding a logon script) you make. For example, if I have a workstation with a GPT.INI file that has a version number of 0, as shown below:

[General]
gPCFunctionalityVersion=2
gPCUserExtensionNames=[{35378EAC-683F-11D2-A89A-00C04FBBCFA2}{0F6B957E-509E-11D1-A7CC-0000F87571E3}][{A2E30F80-D7DE-11D2-BBDE-00C04F86AE3B}{FC715823-C5FB-11D1-9EEF-00A0C90347FF}]
Version=0
gPCMachineExtensionNames=[{35378EAC-683F-11D2-A89A-00C04FBBCFA2}{0F6B957D-509E-11D1-A7CC-0000F87571E3}{53D6AB1D-2488-11D1-A28C-00C04FB94F17}][{B1BE8D72-6EAC-11D2-A4EA-00C04F79F83A}{53D6AB1D-2488-11D1-A28C-00C04FB94F17}]

Then I’ll need to change the value to 1 if I add a startup script, or 65536 if I add a logon script. Once these three changes are made, the script will be enabled on the local GPO for that machine.

First off, you can tell which profile is currently applied to a given machine by viewing the Windows Firewall properties dialog, shown here:

[Image not found]

The box in red shows that this machine is receiving the standard profile. In order to determine whether to apply the standard or domain profile, Windows attempts to detect whether you are on the network where your AD domain exists or on another network. It does this in a fairly non-obvious way. When Group Policy is processed, the DNS suffix of the network connection that you are receiving Group Policy updates on is stored in the registry with the value: HKLM\Software\Microsoft\Windows\CurrentVersion\Group Policy\History\NetworkName. The next time that the computer is restarted or whenever a network connection change is detected (e.g. you connect to a new network or get a new IP address), the DNS suffix of the new connection is evaluated against the one stored in NetworkName. If they are different, then it is assumed that you are not on the AD network and therefore the standard profile is applied to the computer. If they are the same, then the domain profile is applied.
There are a couple of limitations with this approach. First off, PPP and SLIP type connections are ignored from this equation. This means that VPN connections are essentially always treated as standard profile (at least in the testing I’ve done). The other limitation is that it is fairly easy to circumvent this system by hard-coding a DNS suffix within the TCP/IP properties of a connection. For example, lets say that you normally connect to your AD network using a Wireless connection and that your AD DNS suffix is cpandl.com. If you hard code that DNS suffix into that wireless connection’s TCP/IP properties and then go to your local Starbucks for a little WiFi action with your double, wet, non-fat caramel macchiato, your machine will look at the hard-coded DNS suffix and compare it to the suffix when you were on your AD domain, see that they are the same and assume you are still on the corporate network. This could be bad if the domain profile specifies to disable Windows Firewall. So, its important that if you’re using different profiles, that DNS suffix is supplied by DHCP rather than hard-coded.

Actually, there is no way to do this in XP or Win2003. The best way to get around this is to use a program exception instead for the application that requires the multiple port access. If you use a program exception, then all ports used by that application will be available.