Monday, January 14, 2013

WIN 7 INSTALL NOTES

 System Preparation (Sysprep) tool prepares an installation of Windows for duplication, auditing, and customer delivery. Duplication, also called imaging, enables you to capture a customized Windows image that you can reuse throughout an organization. Audit mode enables you to add additional device drivers or applications to a Windows installation. After you install the additional drivers and applications, you can test the integrity of the Windows installation. Sysprep also enables you to prepare an image to be delivered to a customer. When the customer boots Windows, Windows Welcome starts.Sysprep must be used only to configure new installations of Windows. You can run Sysprep as many times as required to build and to configure your installation of Windows. However, you can reset Windows activation only up to three times. You must not use Sysprep to reconfigure an existing installation of Windows that has already been deployed. Use Sysprep only to configure new installations of Windows.If you intend to transfer a Windows image to a different computer, you must run sysprep /generalize, even if the computer has the same hardware configuration. The sysprep /generalize command removes unique information from your Windows installation, which enables you to reuse that image on different computers. The next time you boot the Windows image, the specialize configuration pass runs. During this configuration pass, many components have actions that must be processed when you boot a Windows image on a new computer. Any method of moving a Windows image to a new computer, either through imaging, hard disk duplication, or other method, must be prepared with the sysprep /generalize command. Moving or copying a Windows image to a different computer without running sysprep /generalize is not
supported.


 System Preparation (Sysprep) tool prepares an installation of Windows for duplication, auditing, and customer delivery. Duplication, also called imaging, enables you to capture a customized Windows image that you can reuse throughout an organization. Audit mode enables you to add additional device drivers or applications to a Windows installation. After you install the additional drivers and applications, you can test the integrity of the Windows installation. Sysprep also enables you to prepare an image to be delivered to a customer. When the customer boots Windows, Windows Welcome starts.Sysprep must be used only to configure new installations of Windows. You can run Sysprep as many times as required to build and to configure your installation of Windows. However, you can reset Windows activation only up to three times. You must not use Sysprep to reconfigure an existing installation of Windows that has already been deployed. Use Sysprep only to configure new installations of Windows.If you intend to transfer a Windows image to a different computer, you must run sysprep /generalize, even if the computer has the same hardware configuration. The sysprep /generalize command removes unique information from your Windows installation, which enables you to reuse that image on different computers. The next time you boot the Windows image, the specialize configuration pass runs. During this configuration pass, many components have actions that must be processed when you boot a Windows image on a new computer. Any method of moving a Windows image to a new computer, either through imaging, hard disk duplication, or other method, must be prepared with the sysprep /generalize command. Moving or copying a Windows image to a different computer without running sysprep /generalize is not supported.

If you have Active Directory Domain Services (AD DS) role installedIf you have Active Directory Domain Services (AD DS) role installed, you must manualy remove it with dcpromo.exe before running sysprep on domain controller with sysprep /generalize

Sysprep Executable

Sysprep.exe is the main program that calls other executable files that prepare the Windows installation. Sysprep.exe is located in the %WINDIR%\system32\sysprep directory on all installations. Sysprep must always be run from the %WINDIR%\system32\sysprep directory and must run on the version of Windows with which it was installed.

Sysprep Process

When Sysprep runs, it goes through the following process:Verifies that Sysprep can run. Only an administrator can run Sysprep, and only one instance of Sysprep can run at a given time. Also, Sysprep must run on the version of Windows with which it was installed.Initializes logging.Parses command-line arguments.If no command-line arguments were provided, the Sysprep window appears that enables users to specify Sysprep actions.Processes Sysprep actions, calls appropriate .dll files and executable files, and adds actions to the log file.Verifies that all .dll files have processed all their tasks, and then either shuts down the system, restarts the system, or exits Sysprep.

Using Answer Files with Sysprep

You can use an answer file with Sysprep to configure unattended Setup settings. The following sections describe some of the considerations and processes for using answer files with Sysprep.

Applying Settings in the generalize, auditSystem and auditUser passes

Not all configuration passes run during Windows Setup. Some configuration passes are only available when you run Sysprep. The generalize, auditSystem and auditUser passes are available only by running Sysprep. If you add settings to your answer file in these configuration passes, you must run Sysprep to apply these settings:To apply the settings in auditSystem and auditUser, you must boot to Audit mode by using the sysprep/audit command.To apply the settings in the generalize pass, you must generalize the Windows image by using the sysprep/generalize command.For more information, see How Configuration Passes Work. For more information about Sysprep command-line options, see Sysprep Command-Line Syntax.

Caching Answer Files to the Computer

If you install Windows by using an answer file, that answer file is cached to the system so when subsequent configuration passes run, settings in the answer file are applied to the system.Because this answer file is cached, when you run Sysprep, settings in the cached answer file are applied. If you use the settings in a different answer file, you can specify a separate Unattend.xml file by using the sysprep /unattend:filename option. For more information, see Sysprep Command-Line Syntax.For more information about using implicit answer file search, see How Windows Setup Works.

Persisting Plug and Play Device Drivers during generalize

You can persist device drivers when you run the sysprep /generalizecommand by specifying the PersistentAllDeviceInstalls setting in the Microsoft-Windows-PnPSysprep component. During the specialize pass, Plug and Play scans the computer for devices and installs device drivers for the detected devices. By default, these device drivers are removed from the system when you generalize the system. If you set PersistAllDeviceInstalls to True in an answer file, Sysprep will not remove the detected device drivers. For more information, see the Unattended Windows Setup Reference.

Displaying RunSynchronous Actions in an Answer File

In Audit mode, you can view the status for RunSynchronous commands that run during auditUser. The AuditUI window displays the status for commands and provides:Visual progress to indicate that an installation is continuing and not suspended.Visual indication of when and where failures occur. This provides quick diagnosis if log files are not created by the command.If there are RunSynchronous commands in the answer file in the auditUser configuration pass, a list of the commands are displayed in the AudiUI window in the order specified by RunSynchronous/RunSynchronousCommand/Order. Each list item in the UI is either the string from:RunSynchronous/RunSynchronousCommand/Description (if present)-OR-RunSynchronous/RunSynchronousCommand/PathAll RunSynchronous commands are processed in order. If the command succeeds, then its related list item is annotated with a green checkmark. If the command fails, then its related list item is annotated with a red X. If a reboot is requested, the AuditUI is redisplayed after the boot but only unprocessed list items are displayed. Previously processed items no longer appear in the AuditUI. If the list of items in the AuditUI exceeds the height of the display, then the list is clipped to the display and does not scroll. As a result, some items might not be visible.Windows Setup interprets the zero and nonzero return codes as status values in the AuditUI. A zero value indicates a success, while a nonzero value indicates a failure. The return value of the command might affect the behavior of the Setup, depending on the value of the RunSynchronous/RunSynchronousCommand/WillReboot command.If RunSynchronous/RunSynchronousCommand/WillReboot is set to Always, then:If the command returns 0, its related list item is annotated with a green checkmark. A reboot immediately occurs.If the command returns nonzero, its related list item is annotated with a red X. A reboot immediately occurs.If RunSynchronous/RunSynchronousCommand/WillReboot is set to Never, then:If the command returns 0, its related list item is annotated with a green checkmark. If the command returns nonzero, its related list item is annotated with a red X. A nonzero return value is not treated as a fatal error when WillReboot is set either to Always or Never.If RunSynchronous/RunSynchronousCommand/WillReboot is set to OnRequest, then:If the command returns 0, its related list item is annotated with a green check mark.If the command returns 1, its related list item is annotated with a green check mark. A reboot immediately occurs.If the command returns 2, its related list item is temporarily annotated with a green checkmark. A reboot immediately occurs. Following the reboot, the related list item is displayed again in the AuditUI without annotation because the command is still in process.If the command returns other values, then a fatal error occurs and a blocking dialog is displayed. If the Errorhandler.cmd file is present, no dialog is displayed. For more information about Errorhandler.cmd, see Add a Custom Script to Windows Setup.

Resetting Windows Activation

When you install Windows with a single license product key, you have 30 days during which you must activate that installation of Windows. If you do not activate Windows within the 30 day period and do not reset the activation clock, Windows will enter RFM (Reduced Functionality Mode). This mode prevents users from logging on to the computer until Windows is activated.There is no limit to the number of times Sysprep can run on a computer. However, the clock for Windows Product Activation begins its countdown the first time Windows starts. You can use the sysprep /generalize command to reset Windows Product Activation a maximum of three times. After the third time you run the sysprep /generalizecommand, the clock can no longer be reset.When you run the sysprep /generalize command, the activation clock will automatically reset. You can bypass resetting the activation clock by using the SkipRearm setting in the Microsoft-Windows-Security-Licensing-SLC component. This enables you to run Sysprep multiple times without resetting the activation clock. For more information about this setting, see the Unattended Windows Setup Reference.ImportantIf you anticipate running Sysprep multiple times on a single computer, you must use the SkipRearm setting in the Microsoft-Windows-Security-Licensing-SLC component to postpone resetting the activation clock. Because you can reset the activation clock only three times, if you run Sysprep multiple times on a computer, you might run out of activation clock resets. Microsoft recommends that you use the SkipRearm setting if you plan on running Sysprep multiple times on a computer.

Volume License and OEM Activation Requirements

For volume licenses, activation clock reset behavior is different, depending on the type of license.Activation can be reset an unlimited number of times for an activated Key Management Service (KMS) clients. For non-activated KMS clients, the activation clock can be reset only up to three times, the same as a single license.Microsoft recommends that KMS clients use the sysprep /generalizecommand where the value of the SkipRearm setting is equal to 1. After capturing this image, use the sysprep /generalize command where the value of the SkipRearm setting is equal to 0.For Multiple Activation Keys (MAK) clients, the recommendation is to install the MAK immediately before running Sysprep the last time before delivering the computer to a customer.For OEM Activation licenses, activation is not required. OEM Activation is available only to royalty OEMs.

Activating Windows before Shipping to a Customer

Most customers can easily manage activation after receiving their computers. But if you prefer, you can activate the software on behalf of your customers, making it easier for them to start using their new computers. After activation is completed, most users will not need to activate their installation again.To activate Windows for your customer, use the unique Product Key from the certificate of authenticity (COA) label that is affixed to the specific computer, and activate the computer on behalf of the end user. Run the sysprep /oobe command to prepare the computer for delivery to the customer.NoteYou cannot make an image of an activated Windows installation and duplicate that image to another computer. If you do, Windows fails to recognize the activation and forces the end user to reactivate the installation manually.

Booting to Audit Mode or Windows Welcome

When Windows Vista boots, there are two modes in which the computer will start:Windows Welcome Windows Welcome, also called Machine OOBE (out-of-box experience), is the first user experience and enables end users to customize their Windows installation. End users can create user accounts, read and accept the Microsoft Software License Terms, and choose their language and time zones.By default, all Windows installations boot to Windows Welcome first.The oobeSystem configuration pass runs immediately before Windows Welcome starts. For more information about this configuration pass, see oobeSystem.Audit Mode. Audit mode enables OEMs and corporations to add customizations to their Windows images. Audit mode does not require settings in Windows Welcome to be applied. By bypassing Windows Welcome, you can access the desktop quicker and perform your customizations. You can add additional device drivers, install applications, and test the validity of the installation.In Audit mode, settings in an unattended answer file in the auditSystem and auditUser configuration passes are processed. For more information about these configuration passes, see auditSystem and auditUser.If you are running in Audit mode, to configure the installation to boot to Windows Welcome, run the sysprep /oobe command. OEMs are required to run sysprep /oobe before shipping a computer to an end user. In a default Windows Vista installation, after installation completes, Windows Welcome starts. However, you can skip Windows Welcome and boot directly to Audit mode by pressing Ctrl+Shift+F3 at the first Windows Welcome screen.For unattended installation, you can configure Windows to boot to Audit mode by using the Microsoft-Windows-Deployment | Reseal setting in an answer file. For more information, see the Unattended Windows Setup Reference.For more information about Audit mode, see Customize Windows in Audit Mode.

Detecting the State of a Windows Image

You can identify the state of a Windows image, whether it will boot to Audit mode, Windows Welcome, or if the image is still in the process of installation. For more information, see Windows Setup Installation Process.

Sysprep Log Files

Sysprep logs Windows setup actions in different directories, depending on the configuration pass. Because the generalize pass deletes certain Windows Setup log files, Sysprep logs generalize actions outside the standard Windows Setup log files. The following table shows the different log file locations that are used by Sysprep.

 

ItemLog Pathgeneralize%WINDIR%\System32\Sysprep\Pantherspecialize%WINDIR%\Panther\Unattended Windows setup actions%WINDIR%\Panther\Unattendgc

--------


Add a Custom Script to Windows Setup

5 out of 6 rated this helpful - Rate this topicYou can add custom scripts to Windows Setup that can be configured to run in different circumstances. You can run a custom script:Immediately after Windows Setup completes.If Windows Setup encounters a fatal error.

Run a Custom Script after Windows Setup Completes

You can make further customizations after Windows Setup completes by adding commands to the %WINDIR%\Setup\Scripts\SetupComplete.cmd file. This file enables you to install additional applications, run custom Windows scripts (cscript/wscript), or make other modifications to the system before a user logs on.NoteCommands in the Setupcomplete.cmd file are executed with local system privilege.After Windows is installed, but before the logon screen appears, Windows Setup searches for the SetupComplete.cmd file in the %WINDIR%\Setup\Scripts\ directory.If a SetupComplete.cmd file is found, the file is executed. Otherwise, installation continues normally. Windows Setup logs the action in the Setupact.log file.NoteYou cannot reboot the system and resume running SetupComplete.cmd.Setup does not verify any exit codes or error levels in the script after executing SetupComplete.cmd.The functionality of Setupcomplete.cmd differs from the RunSynchronous and RunAsynchronous commands in that Setupcomplete.cmd runs after Windows Setup completes while the RunSynchronous and RunAsynchronous commands run during Windows Setup.

Run a Custom Script if Windows Setup Encounters a Fatal Error

If Windows Setup encounters a fatal error, you can configure Setup to automatically launch a script that contains custom commands or actions. A fatal error is an error in which Windows Setup is prevented from completing the installation.This functionality is useful when you automate the installation of many systems at the same time. By enabling this functionality, you can immediately detect when an error occurs during Windows Setup and run custom actions.If Setup encounters a fatal error and is prevented from completing the installation, Setup searches for a command script in the following directory: %WINDIR%\Setup\Scripts\ErrorHandler.cmd. One of two actions will occur, depending on whether the script is found.If the script is not found, a dialog box is displayed with the error text. A user must dismiss the dialog box before Setup exits.If the script is found, the script executes synchronously. No dialog box or error text is displayed. After the ErrorHandler.cmd script completes, Windows Setup exits.Depending on the phase of Windows Setup, the computer will return to the environment from which Setup was executed (for example, a downlevel operating system or Windows PE).There are several ways that you can add the ErrorHandler.cmd file by using the $OEM$ directory structure.Create a Sources\$OEM$\$$\Setup\Scripts folder in the Windows distribution. Copy the ErrorHandler.cmd file to this directory. For more information about using $OEM$ files, see Add Content to $OEM$ Folders.Create a temporary folder that contains a $$\Setup\Scripts folder structure. Copy the ErrorHandler.cmd file to this directory, and then run Windows Setup with the /m:temp_folder parameter. For example, if you create C:\Temp\SetupFiles\$$\Setup\Scripts\ErrorHandler.cmd, use the following command:setup.exe /m:C:\temp\SetupFiles For more information about the setup.exe /m parameter, see Windows Setup Command-Line Options.There may be instances when Windows Setup encounters more than one error and runs the ErrorHandler.cmd script more than once. When developing the code for ErrorHandler.cmd, ensure that you can run this script multiple times.




9 comments:

  1. Microsoft-Windows-Shell-Setup | UserAccounts | AdministratorPassword can be used in oobeSystem pass to prevent having to enter a password for the built-in Administrator account after you complete the out-of-box experience.The following XML output shows how to set the appropriate values.                                                yourBApasswordhere                     true                            

    Disabling the Built-in Administrator Account

    Original equipment manufacturers (OEMs) and system builders are required to disable the built-in Administrator account before delivering the computers to customers.Run the sysprep /generalize command When you run the sysprep /generalize command, the next time the computer starts, the built-in Administrator account will be disabled. -or-Use the net user command Run the following command to disable the Administrator account.net user administrator /active:no You can run this command after configuring the computer, before delivering the computer to a customer

    ReplyDelete
  2. Use the Local Users and Groups MMC consoleChange the properties of the Administrator account by using the Local Users and Groups Microsoft Management Console (MMC).Open the MMC console and select Local Users and Groups.Right-click the Administrator account and select Properties. The Administrator Properties window appears.On the General tab, clear the Account is Disabled check box.Close the MMC console.Administrator access is now enabled.

    Enable the Built-in Administrator Account for Windows Server 2008

    For Windows Server® 2008, the built-in Administrator password must be changed at first logon. This prevents the built-in Administrator account from having a blank password by default.Both Microsoft-Windows-Shell-Setup | Autologon and Microsoft-Windows-Shell-Setup | UserAccounts | AdministratorPassword sections are now needed for autologon in audit mode to work. Both of these settings should be added to the auditSystem pass.The following XML output shows how to set the appropriate values.                                               yourBApasswordhere                     true                                                  true             Administrator                            yourBApasswordhere               true                      

    ReplyDelete
  3. In Windows Vista, the built-in administrator account is disabled by default. In previous versions of Windows, an Administrator account was automatically created during Out-of-Box-Experience (OOBE) with a blank password.An Administrator account with a blank password is a security risk. To better protect the system, the built-in Administrator account is disabled by default in all clean installations and upgrades of Windows Vista.NoteFor upgrade installations, the built-in Administrator account is kept enabled when there is no other active local Administrator on the computer. However, the built-in Administrator account is disabled by default for new installations and upgrades on domain-joined computers, regardless of whether there are other active local Administrators on the domain-joined computers.In audit mode, Windows Setup will implicitly enable the built-in Administrator account as the last action in the auditSystem configuration pass if the built-in Administrator is not already enabled. The first action in the auditUser configuration pass is to disable the built-in Administrator account. This enables you to run programs and applications as an Administrator. When you complete your customizations in audit mode and log out, the built-in Administrator account will be disabled. Unless you want to explicitly leave the built-in Administrator account enabled, there’s no need to re-enable the built-in Administrator account in audit mode.

    Enable the Built-in Administrator Account for Windows Vista

    There are two ways to enable the built-in Administrator account.Use the AutoLogon unattended Setup setting You can enable the built-in Administrator account during unattended installations by setting the AutoLogon setting to Administrator in the Microsoft-Windows-Shell-Setup component. This will enable the built-in Administrator account, even if a password is not specified in the AdministratorPassword setting.You can create an answer file by using Windows System Image Manager (Windows SIM).The following sample answer file shows how to enable the Administrator account, specify an Administrator password, and automatically log onto the system. SecurePasswd123 true Administrator true 5 SecurePasswd123 true

    ReplyDelete
  4. http://technet.microsoft.com/en-us/library/cc766343(v=ws.10).aspx

    ReplyDelete
  5. Server ModeExplanationLegacy modeThe Legacy mode is equivalent RIS; it is Windows Deployment Services binaries with RIS functionality. To run in this mode, install and configure RIS and then install (but do not configure) Windows Deployment Services. In general, if you do not have Windows Vista in your environment, you should use Legacy mode. Windows Deployment Services was designed to deploy these new operating systems and while it is compatible with older operating systems, you need the Windows Vista installation media in order to deploy images.Boot environment: OSChooserImage Types: RISETUP and RIPREPAdministration experience: RIS toolsetMixed modeIn this mode, you can deploy RISETUP and RIPREP image types using OSChooser, and you can deploy Windows image (.wim) files using the Windows Deployment Services management tools. From the client computer, you can choose to boot into RIS or into one of the boot images that contain Windows PE. To run in Mixed mode, configure Windows Deployment Services on a RIS server that has existing RIS images. For instructions, see Steps for configuring Windows Deployment Services.Boot environment: OSChooser and Windows PEImage Types: .wim, RISETUP, and RIPREPAdministration experience: RIS toolset to manage RISETUP and RIPREP images and Windows Deployment Services management tools to manage .wim images.Native modeWith Native mode, you use Windows Deployment Services to deploy only .wim images. To configure your server in Native mode, install and configure Windows Deployment Services on a server that has RIS installed but not configured (that is, there are no RIS images on the server). For instructions, see Steps for configuring Windows Deployment Services. If you already configured RIS, then you will need to uninstall RIS and reinstall it before installing Windows Deployment Services.Boot environment: Windows PEImage Types: .wimAdministration experience: Windows Deployment Services management tools

    ReplyDelete
  6. Configuring the boot menu

    Optionally, you create and modify boot images. Boot images are the images containing Windows PE that the client boots into in order to select the image to install. When you have multiple boot images available to client computers, they will be presented with a boot menu that displays the boot images. Users will have to select a boot image, then the computer will boot into Windows PE, and the install images will be displayed. The boot menu allows you to have boot images for different tasks, and architecture types—for example, you could have boot images that do the following:Launch Setup to install Windows.Reformat the hard disks to support BitLocker Drive Encryption (using unattend) and then install Windows. Contain the Windows Recovery Environment (Windows RE) that you want to use when a computer fails to start. Contain the Windows Deployment Services Image Capture Wizard, which creates an install image from the client computer's operating system.Includes a Windows PE image for administrators who want perform other operations from within Windows PE.In addition, x64-based computers can run x86-based or x64-based boot images. Therefore, for each of these tasks, you could have two boot images—one for x86 and one for x64. The boot menu on x86-based computers will only display x86 boot images (because x86-based computers cannot run x64 boot images).

    Known issues with configuring the boot menu

    You might encounter the following issues when you configure the boot menu.Only 10 boot images are visible at a time. If you have more than 10, you will have to scroll down to view the rest.Double-byte character sets used as image names might not display properly in the boot menu. This issue pertains to localized strings. Limitations within the BIOS character sets do not allow the characters to display properly. 

    ReplyDelete
  7. Creating discover images

    If you have a computer that is not PXE enabled, you can create a discover image and use it to install an operating system on that computer. Otherwise, you can skip this section. When you create a discover image and save it to media (CD, DVD, USB drive, and so on), you can then boot a computer to the media. The discover image on the media locates a Windows Deployment Services server, and the server deploys the install image to the computer. You can configure discover images to target a specific Windows Deployment Services server. This means that if you have multiple servers in your environment, you can create a discover image for each, and then name them based on the name of the server.

    Prerequisites for creating discover images

    Have CD or DVD or flash drive to store the image.Have a disk-burning utility if you are burning the image to CD or DVD.

    Steps for creating discover images

    You can create discover images using the Windows Deployment Services MMC snap-in or WDSUTIL. After you create the discover image, create media that contains the image. You must create discover images using the Boot.wim file from the media (located in the \Sources folder). You cannot use the WinPE.wim file from the Windows AIK to create a discover image.To create a discover imageIn the Windows Deployment Services MMC snap-in, expand the Boot images node.Right-click the image you want to use as a discover image. This must be the Boot.wim from the Windows Vista media.Click Create Discover Boot Image.Follow the instructions in the wizard, and when it is complete, click Finish.Use the following procedure to create media that contains the image.To create media that contains the discover imageDownload and install the Windows AIK.Click Start, click All Programs, click Microsoft Windows AIK, and then click Windows PE Tools Command Prompt.To create a WinPE build environment, type:CopyPE C:\WinpeTo copy the discover image created in the previous procedure, type:Copy /y c:\.wim c:\Winpe\ISO\SourcesTo change back to the PETools folder, type:Cd C:\Program Files\Windows AIK\Tools\PEToolsTo create the bootable ISO image, type:Oscdimg -n -bc:\winpe\ISO\boot\etfsboot.com c:\winpe\ISO c:\.isoUse a utility that can create a CD or DVD to transfer the ISO image to the appropriate media.

    ReplyDelete
  8. http://technet.microsoft.com/en-us/library/cc749366(v=ws.10).aspx

    Specifying locations

    Specifying encoded locations. The encoded location used in all the helper functions is an unambiguous string representation for the name of an object. It is composed of the node part, optionally followed by the leaf enclosed in square brackets. This way, there is a clear distinction between nodes and leaves.For example, you should specify the file C:\Windows\Notepad.exe like this: c:\Windows[Notepad.exe]. Similarly, you should specify the directory C:\Windows\System32 like this: c:\Windows\System32(notice the absence of the [] construct). Representing the registry is very similar. The default value of a registry key is represented as an empty [] construct. For example, the default value for the HKLM\SOFTWARE\MyKey registry key will be HKLM\SOFTWARE\MyKey[].Specifying location patterns. You specify a location pattern in a similar way to how you specify an actual location. The exception is that both the node and leaf part accept patterns. However, a pattern from the node does not extend to the leaf.For example, the pattern c:\Windows\* will match the Windows directory and all subdirectories. But it will not match any of the files in those directories. In order to match the files as well, you need to specifyc:\Windows\*[*].

    ReplyDelete
  9. http://technet.microsoft.com/en-us/library/cc749366(v=ws.10).aspx#locations

    ReplyDelete