Appendix

This appendix provides sample scripts and two scenarios of deploying application compatibility mitigation scripts. Scripts provide a way of making configuration changes on more than one computer, to ensure that the configuration is identical.

The two scenarios provide sample scripts for deploying Windows® XP Service Pack 2 (SP2) and application compatibility configuration scripts. The scripts are provided as samples and may require modifications to work in your environment. Each scenario includes a Readme.txt outlining the scripts that need to be edited. Each script provides details of where changes are required. This may include changes in server name, share name, and user credentials.

You need to obtain a copy of Windows XP SP2 before running any of the scenarios or the accompanying scripts. Windows XP SP2 may be downloaded from:

https://www.microsoft.com/downloads/details.aspx?FamilyID=049c9dbe-3b8e-4f30-8245-9e368d3cdb5a&DisplayLang=en

The accompanying scripts alter settings in the Windows XP registry. The scripts should be thoroughly tested in a test lab environment to ensure that they achieve the desired results.

Before modifying the registry, ensure that you back up the registry and that you understand how to restore the registry if a problem occurs. For information on how to back up, restore, and edit the registry, see article 256986, “Description of the Microsoft Windows registry,” in the Microsoft Knowledge Base at:

For a description of the Microsoft Windows Registry, see:

https://support.microsoft.com/default.aspx?scid=kb;EN-US;256986 

For additional information on scripting, visit the Scripting Solutions Center at

https://www.microsoft.com/technet/scriptcenter/solutions/default.mspx

On This Page

How to Create a .REG File for Use with the Accompanying Scripts
Extracting the Scripts
The Application Compatibility Mitigation Scripts
Scenario Examples

How to Create a .REG File for Use with the Accompanying Scripts

Several of the scripts accompanying this guide make use of a .reg file for configuration where application compatibility is an issue. The script merges the .reg file into the Windows XP registry.

Syntax of .Reg Files

A .reg file has the following syntax:

RegistryEditorVersion
                  <Blank line>
[RegistryPath1] 
"DataItemName1"="DataType1:DataValue1"
DataItemName2"="DataType2:DataValue2"
                  <Blank line>
[RegistryPath2] 
"DataItemName3"="DataType3:DataValue3"

Where:

RegistryEditorVersion is either "Windows Registry Editor Version 5.00" for Windows® 2000, Windows XP, and Windows Server™ 2003, or "REGEDIT4" for Windows® 98, and Windows NT® 4.0. The "REGEDIT4" header also works on Windows 2000-based, Windows XP-based, and Windows Server 2003-based computers.

Blank line is a line with no characters on it except a carriage return/line feed. Blank lines make a registry file much easier to read. The standard practice is to use a blank line before every new registry path. Each key or subkey is a new registry path.

RegistryPathx is the path of the subkey that holds the first value you are importing. Enclose the path in square brackets, and separate each level of the hierarchy by a backslash. For example:

[HKEY_LOCAL_ MACHINE\SOFTWARE\Policies
\Microsoft\Windows\System]

A .reg file can contain several registry paths. If the bottom of the hierarchy in the path statement does not exist in the registry, a new subkey is created. The contents of the registry files are sent to the registry in the order you enter them. Therefore, if you want to create a new subkey with another subkey below it, you must enter the lines in the correct order.

DataItemNamex is the name of the data item that you want to import. If a data item in your file does not exist in the registry, the .reg file adds it (with the value of the data item). If a data item does exist, the value in your .reg file overwrites the existing value. Quotation marks enclose the name of the data item. An equal sign (=) immediately follows the name of the data item.

DataTypex is the data type for the registry value and immediately follows the equal sign. For all the data types other than REG_SZ (a string value), a colon immediately follows the data type. If the data type is REG_SZ, do not include the data type value or colon. In this case, Regedit.exe assumes REG_SZ for the data type. Typical data types in .reg include:

REG_BINARY hexadecimal 
REG_DWORD dword 
REG_EXPAND_SZ hexadecimal(2) 
REG_MULTI_SZ hexadecimal(7) 

Creating the .REG File

From the Application Compatibility Testing and Mitigation Guide for Windows XP Service Pack 2, the location of the Zones registry key is:

HKEY_CURRENT_USER\Software\Microsoft\Windows
\CurrentVersion\Internet Settings\Zones\

The following explains how the .reg file is created for the Zones management script, located in the \scripts\IE folder.

To generate a .reg file,

1. Configure the appropriate zone through the Internet Explorer UI (Tools menu > Internet Options > Security tab). The script uses the example of the Local intranet zone (zone 1 in the registry).

2. Open the Windows XP Registry Editor, Regedit.exe.

3. Navigate to the following key in the registry

   HKEY_CURRENT_USER\Software\Microsoft\Windows
   

\CurrentVersion\Internet Settings\Zones</pre>

4. Right-click the subkey for the appropriate zone (1 in this example), and click Export.

5. Save the .reg file. (Note that the name must match that in the script, in this case, Zones.reg.)

The process used for creating the other .reg files is similar. In some cases, the Class Identifier (CLSID) is required before the correct part of the registry can be exported. You need to search through the registry for the friendly name to find the CLSID. This needs to be cross checked in conjunction with the registry path provided in the sample scripts.

For more information regarding general scripting practices, see

https://www.microsoft.com/technet/scriptcenter/default.mspx

Extracting the Scripts

The following table lists the folders that are created on extracting the executable.

Table A.1

Folder Name	Contents
DCOM	Sample script to exempt a DCOM application from DCOM security restrictions.
IE	Sample scripts for setting Internet Explorer features.
Outlook	Sample script to alter attachment management within Outlook Express.
RPC	Sample script to alter call back restrictions in RPC Security.
Scenario1	Sample scripts and command files to install Windows XP SP2 and mitigation scripts with no user interaction.
Scenario2	Sample scripts and command files to install Windows XP SP2 and mitigation scripts with minimal user interaction.
WF	Sample scripts configure Windows Firewall behavior.

The Application Compatibility Mitigation Scripts

The following section outlines the functions of the Application Compatibility Scripts.

DCOM Exception

The DCOM folder contains a script to modify the default security behavior. The following table lists the contents in the DCOM folder.

Table A.2

Folder Name	File Name
DCOM	DCOMSec.vbs

DCOMSec.vbs

The script to exempt a DCOM application from the security applied by Windows XP SP2 uses the RegWrite method of WshShell from the Windows Script Host (WSH) object model. RegWrite writes the CLSID of the application to the ActivationSecurityCheckExemptionList value.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole
\AppCompat\ActivationSecurityCheckExemptionList

This script uses an input box to allow the user to specify the application ID from the DCOM Config section of the Component Services MMC.

Locating the Application ID

The sample DCOM script prompts you to enter the Application ID/CLSID of the application you are going to exempt. To find the Application ID, perform the following steps:

1. Open the Component Services MMC.

2. Navigate to Console Root\Component Services\Computers\My Computer\DCOM Config.

3. Click View, and then click Detail.

4. Document the Application ID (CLSID).

The following figure shows the Application ID for the application in the DCOM Config section in the Component Services MMC.

Figure A.1  Locating the Application ID (CLSID) from the Component Services MMC

Internet Explorer

There are several scripts for manipulating Internet Explorer in the IE folder. The following table provides a list of these scripts.

Table A.3

Folder Name	File Name
IE	Addon.reg
	AddOn.vbs
	AllowPop.reg
	AllowPop.vbs
	LocalMachineLockdown.vbs
	ZoneElevation.vbs
	Zones.reg
	Zones.vbs

The following sections cover these scripts in detail.

AddOn.vbs

This script merges the Addon.reg file, which contains a list of blocked Internet Explorer add-ons, into the local registry. The Addon.reg file is generated by exporting the list from a test computer. This script can be used to configure several computers using deployment methods discussed in chapter 4.

This script applies a .reg file that edits the registry to disable a specific Internet Explorer add-on.

The .reg file edits the following registry keys:

HKEY_CURRENT_USER\Software\Microsoft\Windows
\CurrentVersion\Ext\Settings
HKEY_CURRENT_USER\Software\Microsoft\Windows
\CurrentVersion\Ext\Stats

Before this script is used, the .reg file must be edited to contain the CLSID of the add-on component to be disabled. To identify the CLSID of an add-on component, search the registry for the add-on name located in the Manage Add-ons interface:

1. Open Regedit.

2. Highlight HKEY_CLASSES_ROOT.

3. On the Edit menu, click Find.

4. In the Find What text box, type the name of the Internet Explorer add-on.

5. Click Find Next.

6. If a match is found, expand the key HKEY_CLASSES_ROOT\Add-on_Name.

7. Click the HKEY_CLASSES_ROOT\*Add-on_Name\*CLSID subkey.

8. In the right hand pane, double-click the default value.

9. Highlight and copy the value data including the “{}”.

10. Paste the CLSID into the .reg file in the following three lines overwriting the existing CLSID only:

    [HKEY_CURRENT_USER\Software\Microsoft\Windows
    

\CurrentVersion\Ext\Settings {06849E9F-C8D7-4D59-B87D-784B7D6BE0B3}] [HKEY_CURRENT_USER\Software\Microsoft\Windows \CurrentVersion\Ext\Stats {06849E9F-C8D7-4D59-B87D-784B7D6BE0B3}] [HKEY_CURRENT_USER\Software\Microsoft\Windows \CurrentVersion\Ext\Stats {06849E9F-C8D7-4D59-B87D-784B7D6BE0B3}\iexplore]

Multiple edits can be made at the same time using a .reg file though each entry can be edited by writing a script to change a specific value if required.

To disable multiple Internet Explorer add-ons:

1. Manually disable the required add-ons on a test machine.

   Export the “HKEY_CURRENT_USER\Software\Microsoft
   

\Windows\CurrentVersion\Ext” key.

2. Apply the exported .reg file to the required systems using Add-on.vbs.

.reg files can be imported by directly executing the file if required.

AllowPop.vbs

This script allows pop-ups from selected Web sites. The script merges the allowpop.reg file into the local registry key:

HKEY_CURRENT_USER\Software\Microsoft
\Internet Explorer\New Windows\Allow

The accompanying .reg file can be edited to allow additional Web sites by adding additional lines using the format:

“www.website.com”=hex:

ZoneElevation.vbs

The script to allow zone elevation uses the RegWrite method of WshShell from the WSH object model. RegWrite writes to the FEATURE_ZONE_ELEVATION key in the registry to turn off the security feature for the iexplore.exe process.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft
\Internet Explorer\Main\FeatureControl
\FEATURE_ZONE_ELEVATION\iexplore.exe

This script edits the registry to turn off the zone elevation restriction for the iexplore.exe process. The script can also be used to turn on the feature.

1 - Enables the feature

0 - Disables the feature

Zones.vbs

This script configures the Internet Explorer Zones feature. This script should only be used where a Web application requires this feature. It merges the accompanying Zones.reg file into the local computer registry. The Zones.reg file is generated from a test computer with this feature disabled.

The script to change the security zone configuration applies a .reg file exported from the

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
\CurrentVersion\Internet Settings\Zones\0

key. Edit the zone configuration in Internet Explorer and then export the registry key. Apply the .reg file using the script to other computers.

The different zones are indicated by numerical values, as follows:

0 - Local

1 - Internet

2 - Trusted Sites

3 - Internet

4 - Restricted Sites

LocalMachineLockdown.vbs

This script configures further restrictions for Local Machine zone.  A script or executable downloaded from the Internet zone is saved to the local file system and therefore, prior to Windows XP SP2, could execute without prompting the user. Windows XP SP2 turns on local machine lockdown by default to prevent this potential security breach.  This feature requires that the local file system be NTFS.

LocalMachineLockdown.vbs writes to the following subkey in the registry to turn on or off the lockdown feature for the iexplore.exe process:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft
\Internet Explorer\Main\FeatureControl
\FEATURE_LOCALMACHINE_LOCKDOWN\iexplore.exe

1 - Enables the feature

0 - Disables the feature

Outlook Express Scripts

The Outlook folder contains one script for manipulating AES. The following table shows the folder and the script.

Table A.4

Folder Name	File Name
Outlook	Attachment.vbs

Attachments.vbs

The script to configure allowed attachments for Outlook Express uses the RegWrite method of WshShell from the WSH object model. RegWrite writes to the Safe Attachments value to turn off the security feature. The path to this registry value is dynamic and varies from computer to computer.

HKEY_CURRENT_USER\Identities\" & IDName 
& "\Software\Microsoft\Outlook Express
\5.0\Mail\Safe Attachments

This script edits the registry to turn off attachment restrictions for Outlook Express. This script can also be used to turn on the feature.

1 - Enables this feature

0 - Disables this feature

Remote Procedure Calls

The following table shows the contents of the RPC folder.

Table A.5

Table A.5 Folder Name	File Name
RPC	RpcSec.vbs

RpcSec.vbs

This script edits the registry to configure RPC security to bypass new restrictions and allow anonymous call back. The script to configure RPC security uses the RegWrite method of WshShell from the WSH object model. RegWrite writes to the RestrictRemoteClients value.

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft
\Windows NT\RPC\RestrictRemoteClients

The script can have three values:

0 - Bypasses new restrictions

1 - Restricts access to all RPC interfaces but allows anonymous callbacks

2 - Restricts access to all RPC interfaces and does not allow anonymous callbacks

Scenario Examples

Both of the scenarios provide examples of installing Windows XP SP2 and additional configuration with minimum user intervention.

Scenario 1 expects a network share with scripts folder and the service pack source. You need to edit the server names and share names to match your environment.

Scenario 2 expects the service pack source and scripts to be copied locally to the client.

To make editing of the scripts easier, variables have been used for paths and computer names. To use a script in a specific environment, edit the values of the variables.

Each scenario has an associated Readme.txt file. It is important to read these before implementing the scenarios.

Scenario 1

Contoso Ltd. is a medium-sized international pharmaceutical company with a dedicated IT department. Contoso wants to deploy Windows XP SP2 and configure the Windows Firewall for remote management. Contoso intends to use Windows Management Instrumentation (WMI) coupled with WSH using VBscripts, and command (CMD) files to achieve this goal.

Script Summary

The following table lists the scripts used as a part of this solution and their function.

Table A.6

Script	Summary/Function
StartRemoteIns.vbs	Executed on administrative workstation by user with administrative rights on each client and source server. Obtains the client name listed in Computers.txt. Copies the scripts folder from the source server to the client. Uses WMI to execute Install.cmd on the client. Loops to next client name in Computers.txt.
To use StartRemoteIns.vbs	Copy the WindowsXP-KB835935-SP2-ENU.exe upgrade file into the scripts directory before running script. Copy scenario1 scripts into the scripts folder. Edit the path to Computers.txt if required. Edit the scripts source server name if required.
Computers.txt	Located on the administrative workstation. Lists all client names.
To use Computers.txt	Edit Computers.txt to list client names. List one client name on each line. Do not include double back slashes "\\" before the client name. Note: Text file needs linefeed/carriage return after last client name to parse correctly.
Install.cmd	Executes WindowsXP-KB835935-SP2-ENU.exe from the local client. WindowsXP-KB835935-SP2-ENU.exe runs in quiet mode, without restarting and overwrites OEM files. Calls AutoAdmin.vbs. Calls Reboot.vbs.
To use Install.cmd	Edit the path to WindowsXP-KB835935-SP2-ENU.exe if required. Edit the switches used on WindowsXP-KB835935-SP2-ENU.exe if required. Edit the path to AutoAdmin.vbs if required. Edit the path to Reboot.vbs if required.
AutoAdmin.vbs	Writes DefaultUserName to the registry. Writes DefaultPassword to the registry. Writes DefaultDomainName to the registry. Sets AutoAdminLogon. Writes RunOnce.cmd to RunOnce registry key.
To use AutoAdmin.vbs	Edit DefaultUserName value if required. Edit DefaultPassword value if required. Edit DefaultDomainName value if required. Edit the path to RunOnce.cmd if required.
Reboot.vbs	Uses WMI to reboot the client.
RunOnce.cmd	Runs from the RunOnce key in the registry when client reboots using AutoAdminLogon. Calls WinFire.vbs. Calls Cleanup.vbs. Calls Reboot.vbs.
To use RunOnce.cmd	Edit to include relevant configuration scripts if required (See example scripts provided with this guide). Edit the path to WinFire.vbs if required. Edit the path to Cleanup.vbs if required. Edit the path to Reboot.vbs if required.
WinFire.vbs	Executes Netsh command to open file and print and RDP ports in Windows Firewall.
To use WinFire.vbs	Add Netsh command to add relevant ports to the exception list if required. Add Netsh command to add relevant programs to the exception list if required.
Cleanup.vbs	Removes DefaultUserName from the registry. Removes DefaultPassword from the registry. Removes DefaultDomainName from the registry. Removes AutoAdminLogon configuration.

Figure A.2 shows the automated deployment process flow diagram.

Figure A.2 Scenario 1: WMI deployment process flowchart

The explanation for the automated deployment process is as follows:

1. An administrator copies the required scripts, along with the WindowsXP-KB835935-SP2-ENU.exe upgrade file, to a folder on a network share.

2. The administrator creates a text file of computer names, computers.txt, to be parsed by the StartRemoteIns.vbs script, and then uses this script to launch the installation.

   Note: The administrator can be logged on at any workstation to initiate the installation. The user at the client does not require administrative privileges because the script runs in the security context of the remote administrator.

3. The script copies the folder containing the scripts and the WindowsXP-KB835935-SP2-ENU.exe upgrade executable from the server to the local computer, and then calls Install.cmd.

4. Install.cmd runs the service pack setup program, (WindowsXP-KB835935-SP2-ENU.exe), locally with switches so that no user intervention is required. The command file then calls the AutoAdmin.vbs script and once completed, it calls the Reboot.vbs script. This happens as follows:

   Note: This process can take a long time (between one and two hours).

   1. AutoAdmin.vbs sets the local client to use the AutoAdminLogon sections of the registry with an account that has local administrator privileges and configures the RunOnce part of the registry with the configuration command file, RunOnce.cmd. On completion of this script, control is returned to Install.cmd.

   2. The installation command file, Install.cmd, calls Reboot.vbs, and the client workstation is shut down and restarted.

5. On restart, the user specified in the AutoAdmin.vbs script is logged on and the command file specified in the RunOnce section of the registry (RunOnce.cmd in our example) is executed. RunOnce.cmd in turn calls scripts that perform the following tasks:

   1. In our example, RunOnce.cmd first calls the configuration script, WinFire.vbs, which performs the required configuration of the Windows Firewall, opening the necessary ports for remote management. On completion, control is returned to RunOnce.cmd.

   2. Next, RunOnce.cmd calls the cleanup script, Cleanup.vbs, which removes the AutoAdminLogon settings including DefaultUserName, DefaultPassword and RunOnce. On completion, control is returned to RunOnce.cmd.

   3. Finally, RunOnce.cmd calls Reboot.vbs, which shuts down and restarts the client workstation.

6. When the client system restarts, the logon prompt and user name is blank. The client workstation has a local scripts folder that can be deleted using a logon script or using a script placed in the startup folder.

Scenario 2

Contoso has a small remote subsidiary with several mobile users. They have been instructed to report to the office for one day within a two-week period to have Windows XP SP2 installed and configured. The user is instructed to run a script from the local server that uses the runas command to complete the installation. The user is prompted to enter a specific password, with local Administrator rights only. The following scripts are used in this scenario.

Script Summary

The following table lists the scripts used as a part of this solution and their functions.

Table A.7

Script	Summary/Function
RunSP.cmd	Executed on each client by user with knowledge of the administrative password. Executes the runas command. Requires knowledge of the administrative password. Executes Install.cmd on the client.
To use RunSP.cmd	Edit the Administrative name if required. Edit the path to Install.cmd if required.
Install.cmd	Executes WindowsXP-KB835935-SP2-ENU.exe from the scripts folder. WindowsXP-KB835935-SP2-ENU.exe.runs in quiet mode, without restarting and overwrites OEM files. Calls AutoAdmin.vbs. Calls Reboot.vbs.
To use Install.cmd	Edit the path to WindowsXP-KB835935-SP2-ENU.exe if required. Edit the switches used on WindowsXP-KB835935-SP2-ENU.exe if required. Edit the path to AutoAdmin.vbs if required. Edit the path to Reboot.vbs if required.
AutoAdmin.vbs	Writes DefaultUserName to the registry. Writes DefaultPassword to the registry. Writes DefaultDomainName to the registry. Sets AutoAdminLogon. Writes RunOnce.cmd to RunOnce registry key.
To use AutoAdmin.vbs	Edit DefaultUserName value if required. Edit DefaultPassword value if required. Edit DefaultDomainName value if required. Edit the path to RunOnce.cmd if required.
Reboot.vbs	Uses WMI to reboot the client.
RunOnce.cmd	Runs from the RunOnce key in the registry when client reboots using AutoAdminLogon. Calls WinFire.vbs. Calls LogInstall.vbs. Calls Cleanup.vbs. Calls Reboot.vbs.
To use RunOnce.cmd	Edit to include relevant configuration scripts if required (See example scripts provided with this guide). Edit the path to WinFire.vbs if required. Edit the path to LogInstall.vbs if required. Edit the path to Cleanup.vbs if required. Edit the path to Reboot.vbs if required.
WinFire.vbs	Executes Netsh commands to open file and print and RDP ports in Windows Firewall.
To use WinFire.vbs	Add Netsh command to add relevant ports to the exception list if required. Add Netsh command to add relevant programs to the exception list if required.
LogInstall.vbs	Writes the computername of the client to a logfile to track Windows XP SP2 installed clients.
To use LogInstall.vbs	Edit the servername where the logfile is located if required. Edit the sharename where the logfile is located if required. Edit the name of the logfile if required.
Cleanup.vbs	Removes DefaultUserName from the registry. Removes DefaultPassword from the registry. Removes DefaultDomainName from the registry. Removes AutoAdminLogon configuration.

Figure A.3 Scenario 2: Runas deployment process flowchart

1. An administrator copies the scripts and WindowsXP-KB835935-SP2-ENU.exe to a folder on the client computers.

2. An administrator deploys RunSP.cmd as a logon script. This launches the Install.cmd using the runas command to initiate the installation.

3. The user is prompted to enter a password, provided by the administrator.

4. Install.cmd runs the Windows XP SP2 setup program with switches so that no user intervention is required. This process can take a long time.

5. The command file then calls the AutoAdmin.vbs script and once completed, it calls the Reboot.vbs script.

   1. AutoAdmin.vbs sets the local client to use the AutoAdminLogon sections of the registry with an account that has local Administrator privileges and configures the RunOnce part of the registry with the configuration command file, RunOnce.cmd. On completion of this script, the control is returned to Install.cmd.

   2. The installation command file, Install.cmd, calls Reboot.vbs, and the client workstation is shutdown and restarted.

6. On restart, the user specified in the AutoAdmin.vbs script is logged on and the command file specified in the RunOnce section of the registry (RunOnce.cmd in our example) is executed. The RunOnce.cmd command file performs the following tasks:

   1. In our example, RunOnce.cmd first calls the configuration script, WinFire.vbs, which performs the required configuration of the Windows Firewall, opening the necessary ports for remote management. On completion, control is returned to RunOnce.cmd.

   2. Next, RunOnce.cmd calls the cleanup script, Cleanup.vbs. Cleanup.vbs removes the AutoAdminLogon settings, including the DefaultUserName and DefaultPassword settings. On completion, control is returned to RunOnce.cmd.

   3. Then, RunOnce.cmd calls LogInstall.vbs, which writes the name of the local computer to a log file located on a remote server.  This indicates to the administrator that this client workstation has been configured.

   4. Finally, RunOnce.cmd calls Reboot.vbs, which shuts down and restarts the client workstation. On restart, the user is presented with a logon screen with a blank user name and blank password.

Windows Firewall

The Windows Firewall folder (WF) contains five scripts for altering the Windows Firewall default behavior, listed in the following table:

Table A.8

Folder Name	File Name
WF	ClosePort.vbs
	CloseProgram.vbs
	FirewallLog.vbs
	OpenPort.vbs
	OpenProgram.vbs

OpenPort.vbs

This script uses the Netsh command-line utility to open a specific port in the Windows Firewall.

The Netsh command-line utility also allows the limiting of access through the port to specific computers or local subnet. In the supplied example, the Remote Desktop Connection Port (3389) is opened.

The script to open a port in the firewall uses the WshShell from the WSH object model to run an instance of the Netsh command-line tool. The Netsh tool has additional functionality with Windows XP SP2 for configuring the Windows Firewall.

ClosePort.vbs

This script uses the Netsh command-line utility to close a specific port in the Windows Firewall. The script to close a port in the firewall uses the WshShell from the WSH object model to run an instance of the Netsh command-line tool. The Netsh tool has additional functionality with Windows XP SP2 for configuring the Windows Firewall.

In the supplied example, the local FTP server port (21) is closed.

OpenProgram.vbs

This script uses the Netsh command-line utility to include a program in the Windows Firewall exception list. The Netsh command-line utility also allows limiting a program's access to specific computers or local subnet.

In the supplied example, Windows Messenger is the allowed application.

CloseProgram.vbs

This script uses the Netsh command-line utility to exclude a program in the Windows Firewall exception list. The Netsh command-line utility also allows the limiting of access with the program to specific computers or local subnet.

In the supplied example, Windows Messenger is the excluded application.

FirewallLog.vbs

The script to turn on firewall logging for the firewall uses the WshShell from the WSH object model to run an instance of the Netsh command-line tool. The Netsh tool has additional functionality with Windows XP SP2 for configuring the Windows Firewall.

This script uses the Netsh command-line utility to configure logging for the Windows Firewall.

The Netsh command-line utility also allows the limiting access through the port to specific computers or local subnet.