Windows Embedded POSReady 2009 is delivered to end users by Original Equipment Manufacturers (OEM) only. There are several differences in deployment practices between Windows XP Professional and Windows Embedded POSReady 2009 that you should be aware of.

The key differences that will affect the deployment process are as follows:

• Pre-installation
  A clean installation of the POSReady 2009 OS by an end user is not supported. The OEM will provide the installation media (DVD) that a user can use to add or remove OS features.
  
• Server-based image deployment
  Computer-specific configuration settings are handled after an image is fully deployed to the target device. This is usually achieved through use of an executable script. These configuration settings include domain membership, in addition to a custom computer name and location specific network settings. This differs from Windows XP Professional as Microsoft System Center Configuration Manager (ConfigMgr) can apply many of these changes as part of the image deployment process.
  

As you plan the hardware and software operating environment for your POSReady 2009 implementation, it is important to develop a validation procedure for hardware and software compatibility.

The product ID (PID) that is required to license the OS is only available to an OEM. End users receive a fully installed OS that can be customized. It is important to understand the state of the POSReady OS that you receive from your OEM. The original installation of POSReady must be prepared by the OEM by using the Sysprep utility. This will put the OS image in a state that is ready to be customized and cloned. The OEM must not use FBReseal to prepare the computer for cloning. The suggested cloning method, which uses Windows Deployment Services, will only recognize a device that has had a full Sysprep pass. The OEM will likely provide two sets of media to aid in the POSReady customization process:

• The POSReady installation media is used to add or remove Windows features. This media includes the POSReady companion setup utility that is used to install companion applications such as Microsoft Silverlight.
  
• The OEM image restore media that you can use to restore the OS to the state it was in when it was shipped from the OEM. If the OEM does not provide the restore media, a full OS image should be captured before you customize the OS image.
  

The following diagram shows the major steps involved in building a customized POSReady OS environment. The diagram indicates the portion of the build process that is performed by the OEM in addition to the portion that is performed by the end user.

POSReady 2009 is delivered through the OEM channel, which can lead to differences in the image customization process. Because retail POS devices vary widely in their function and form, the customization of the OS to match the intended environment must be handled by the retailer.

Customizations may include some or all of the following:

• POS-specific applications
  
• Systems management
  
• Virus protection
  
• Application database initial settings
  
• Network settings and credentials
  

The steps to customize a POSReady 2009 image are as follows:

1. Receive the OEM image
   
2. Customize the image
   
3. Clone the image
   
4. Capture the image
   
5. Deploy the image
   

Step 1 - Receive OEM image

Receive the OEM image installed on the reference computer. Use the installation media to add or remove Windows system components.

Step 2 - Customize the image

Perform initial startup and add retailer-specific customizations to the target device.

Note:
Additional scripting can be applied to support multiple hardware configurations.

Step 3 - Clone the image

Prepare the master OS for cloning by using the Windows Embedded cloning utility (FBReseal.exe).

Note:

The FBReseal tool does not support cloning an image more than once. As soon as the system cloning tool reseals a run-time image, the FBReseal.exe file is deleted from the image. This behavior is by design, because it prevents end users from accidentally starting the FBReseal.exe utility in a deployed run-time image. We recommend that a full backup of the image be captured prior to the image being sealed. If you have a backup, you can modify the image without having to revert to the OEM build.

Step 4 - Capture the image

Capture the master target device image onto a suitable media for deployment. Any full image backup method can be used. We recommend the Microsoft Windows Imaging Format for server-based deployment.

Step 5 - Deploy the image

Deploy the image to the target device.

The following image shows the process for customizing a POSReady image.

There are two methods that can you can to customize an OEM-delivered OS for final production:

• OEM final delivery
  In this method, the OEM OS is delivered directly to the production environment. The end user either requests that the OEM apply specific customizations before delivery or performs customizations onsite after initial startup of the OS. Making the customizations generally requires a greater level of on-site expertise. End users should follow the documentation provided by their OEM to determine which steps are necessary to configure the OS onsite.
  
• End-user customization
  The end user may modify the OEM-delivered OS and choose to redeploy a custom image. With this approach, the end user can customize the POS OS to meet the needs of the organization before it is delivered to the production environment. POSReady 2009 includes a utility that you can use to re-seal the image after customization. This results in the image performing as it did when it was received from the OEM.
  

Selection of the deployment method depends on several factors:

• Scope of the customizations
  In some cases, the on-site installation process makes it possible for the user to provide input that might not match the configuration setting policy of the store. We recommend that you perform this type of installation in a controlled environment to ensure consistent configuration of the OS. If you allow user options, we recommend that you implement a configuration audit process. This can be either a manual or automated process.
  
• Existing desktop deployment practices
  The image creation, deployment, and management procedures may already be in place for a retailer, making it possible to clone client devices in an enterprise environment. In this case, the POS image creation should follow the existing procedures.
  
• Server-based environment
  Windows Vista lets you add POS computers to the store and quickly load the latest customized image to a device. We recommend this method for environments that have multiple OS and customization combinations. Although this approach does require a manual step in the store, the consistency of the final OS is still maintained.
  

The subsequent sections of this document will focus on the end user customization method, specifically, the steps involved in building, cloning, and deploying a system in a Windows server environment. Refer to the diagram above for the steps involved in the process.

POSReady 2009 ships with Group Policy Administrative Templates. You can use these templates to configure group policy settings on your POSReady OS before you clone and redeploy it.

To apply Group Policy Administrative Templates, start the Group Policy Object Editor by clicking Start, then clicking Run, and running Gpedit.msc. Within the console that launches, you can access and apply the administrative templates.

POSReady ships with the same security templates that are found in Windows XP Professional. You can apply these templates to your POSReady installation to quickly provide a predetermined set of security settings.

1. Click Start, and then click Run.

2. Type mmc and then click OK.

3. On the File menu in the Microsoft Management Console, click Add/Remove Snap-in.

4. Click Add.

5. In the Available Stand Alone Snap-ins list, click Security Configuration and Analysis.

6. Click Add, click Close, and then click OK.

7. In the left pane, click Security Configuration and Analysis, and view the instructions in the right pane.

8. Right-click Security Configuration and Analysis, and then click Open Database.

9. In the File Name box, type the name of the database file, and then click Open.

10. Choose the security template that you want to use, and then click Open to import the entries that are contained in the template to the database.

11. Right-click Security Configuration and Analysis in the left pane, and then click Configure Computer Now.

POSReady 2009 supports all of the multilingual options that are available in Windows XP Professional including the supplemental Complex Script and East Asian language collections. Installing either of these language collections will provide the OS with additional input languages and additional standards and format locales. Additional language collections can either be installed by the OEM during the initial setup of the OS, or they can be installed manually afterwards provided that you have a copy of the POSReady setup media.

1. Click Start, and then click Control Panel.

2. Open Regional and Language Options.

3. In the Regional and Language Options window, click the Languages tab.

4. On the Languages tab, select either or both checkboxes under Supplemental Language Support, and click Apply.

The POSReady media also contains 32 additional Multilingual User Interface (MUI) Packs that you can apply to your POSReady installation to localize the OS. The MUI installer is incorporated into the POSReady Companion Setup, which is launched directly from the POSReady media. You should coordinate with your OEM to ensure that the MUI packs you want to install are included on the media that the OEM provides.

1. Insert the POSReady media. POSReady 2009 Companion Setup should start automatically.

2. Click Multilingual User Interface Languages.

3. Select the MUI packs to install on your OS. Some MUI packs may be disabled because their corresponding language collection is not installed on your OS. To use these languages, install the required language collection.

4. Click Install. After installation is complete, the OS will reboot.

With POSReady 2009 you can add components after the initial installation process has completed.

1. From the Start menu, launch the Control Panel.

2. Click Add or Remove Programs.

3. Click Add/Remove Windows Components.

4. Select or clear the components that you would like to add or remove from the installation.

5. Click Next.

FBReseal is a utility that can be used to reseal a customized installation, and you can run it from the command line. FBReseal generates a unique Security Identifier (SID) and computer name. You can run FBReseal only once on an image. Refer to the POSReady documentation at this Microsoft Web site for switches you can use with FBReseal to change its functionality.

The steps below assume you are using FBReseal without any switches.

Note:
The FBReseal tool does not support cloning an image more than once. After the tool reseals a POSReady image, the file FBReseal.exe is deleted from the image. This behavior is by design, and it prevents end users from accidentally starting the FBReseal.exe utility in the deployed POSReady image.

By default, the FBReseal utility is not included in the OS image supplied by the OEM (refer to the OEM documentation for complete details). The FBReseal utility and its companion files are stored in the \Utilities\FBReseal directory on the POSReady DVD. If your DVD does not contain the same directory structure, contact your OEM for instructions on how to obtain the files. There are three files that you should copy to the target device's \Windows\System32 folder. The files are:

• FBReseal.exe
  
• Setupcn.exe
  
• Setupcl.exe
  

  Note:
  If you are prompted to overwrite FBReseal.exe in \Windows\System32, choose Yes to overwrite the existing files with the version from the POSReady DVD.

To start FBReseal, double-click the FBReseal.exe utility in \Windows\System32, or open a Command Prompt window and at the command line, run FBReseal.exe. The device will start the reseal process and stage any commands that should be run on next boot. A message box appears indicating that the OS has been resealed. In the message box, choose Shutdown to shut down the POSReady device.

Note:
Do not restart the device. The reseal process is now staged to be completed on the next boot. This is the point where you want to capture the gold image that will be distributed to your devices.

This section assumes that the Windows Automated Installation Kit (AIK) is installed in the build environment, perhaps on the Windows Server or a technician computer. You can download the kit at this Microsoft Web site. Install the kit from the downloaded MSI using the default settings. The AIK will be used to build a Windows Preinstallation Environment (Windows PE) boot image that you can use to capture an image of the reference device hard disk.

The following sections outline the process for creating a Windows PE image. This document focuses on various media types, including Windows Deployment Server, CD or DVD, and a network share. The boot process for Windows PE is identical for all three capture locations. The capture process will be slightly different depending on where you intend to store the image.

The steps to capture an image of the reference device for cloning to target devices include the following:

1. Confirm Windows Deployment Services is active
   
2. Create a RAM boot image to boot the reference device for capturing
   
3. Add the boot image to the Windows Deployment Services server
   
4. Boot the reference device and capture the hard disk image
   
5. Add the cloned image to the Windows Deployment Services server
   

1. Confirm Windows Deployment Services is active

The first step is to confirm that the Windows Deployment Services (WDS) server is active and to allow clients to make network boot connections using the Preboot Execution Environment (PXE).

After installing Windows Server 2003 onto the target server, run Windows Update to ensure that all available OS updates have been applied to the OS.

To configure Windows Deployment Services

1. Configure the server to be a domain controller in a new or existing Active Directory domain. A WDS server must be either a member of an Active Directory domain or a domain controller for an Active Directory domain. The Active Directory domain and forest versions are irrelevant; all domain and forest configurations support Windows Deployment Services.

2. Configure the server to run as a Dynamic Host Configuration Protocol (DHCP) server.

3. Configure the server to run as a Domain Name System (DNS) server. This is installed by default when the server is configured as a domain controller.

4. Install Windows Server 2003 with Service Pack (SP) 2 if necessary.

5. Install WDS. WDS can be installed by clicking Start, then clicking Control Panel, then Add/Remove Programs, and then clicking Add/Remove Windows Components. You may be prompted for the Windows Server 2003 installation media.

6. Download and install the Automated Installation Kit (AIK) for Windows Vista SP1 and Windows Server 2008 by using the default installation options.

7. Open WDS by clicking Start, then clicking All Programs, then Administrative Tools, and then clicking Windows Deployment Services.

8. In the left pane, expand Servers. Right-click your server and choose Configure Server.

9. Choose C:\RemoteInstall for the images path.

10. Click Yes to confirm.

11. Choose Do Not Listen On Port 67 and Configure DHCP option 60 to PXEClient.

12. Choose Respond to all client computers.

    If a PXE request comes in, this setting instructs the DHCP server to give the client an IP and then direct the client to the WDS server for boot information.

13. Clear Add images now, and click Finish.

Configuring Windows Firewall to work with Windows Deployment Services

Several exceptions must be added to the Windows Internet Connection Sharing firewall on the server computer to allow requesting clients to connect to the server. Open the ports in the following list as exceptions in Windows Firewall.

Service name	UDP	TCP
DHCP and TFTP	67,69,4011	Not applicable
BINL	4011	Not applicable
NetBIOS	Not applicable	139
SMB	Not applicable	445
LDAP	Not applicable	389

2. Create a RAM boot image to boot the reference device for capturing

Creating the initial Windows PE RAM boot image for use with Windows Deployment Server

After configuring the server, the next step is to create a RAM boot to capture a full disk image of your customized POSReady reference device. This is the image that clients will boot from.

The main difference between POSReady and Windows XP is that the capture of the reference device image must be performed with the ImageX command-line tool. This difference arises because the standard WDS capture process requires a product ID, which is not available with an OEM-delivered operating system.

For step-by-step instructions on creating a boot image, refer to this Microsoft Web site.

For a network deployment to be possible, the client device must have a network adapter that is Preboot Execution Environment (PXE)-capable. You can then perform system deployment using a network connection to computers without CD-ROM drives and on computers that have non-formatted or non-partitioned hard disks.

Most network adapters are supported by the standard boot image. If your network adapter is not recognized, you will need to add a network driver to the boot image. For more information about adding the appropriate network drivers to the boot image, see Windows PE Customization How-To Topics at this Microsoft Web site. This makes it possible for the Plug-n-Play boot process to recognize the network driver.

3. Add the boot image to the Windows Deployment Services server

The next step in the process is to add the newly created RAM boot image to the WDS server so that clients can boot to it. This step assumes that your WDS server is configured so that clients can connect and firewall rules allow clients to connect to the PXE server.

You can add the Windows PE RAM boot image to the Deployment Server environment by using the Windows Deployment Services MMC snap-in.

To add a boot image

1. To open the snap-in, click Start, then click All Programs, click Administrative Tools, and then click Windows Deployment Services.

2. In the left pane of the Windows Deployment Services MMC snap-in, expand the server list, and locate the server where the boot image is located.

3. Right-click the Boot Image node and then click Add Boot Image.

4. Browse to select the boot image (for example c:\winpe_x86\winpe.wim), and then click Open.

5. On the Image File page, click Next.

6. On the Image Description page, click Next to select the default name and description.

7. On the Summary page, click Next.

8. Click Finish.

9. Optional. Remove the need to hit F12 to boot to PXE by opening the Server Properties dialog box.

10. Optional. Click the Boot tab.

11. Optional. Under x86 Architecture, click Browse, and choose pxeboot.n12.

12. Optional. Click OK.

4. Boot the reference device and capture the hard disk image

Now that you have created a method to boot your reference device for capture, the final step is to capture a full disk image of the reference computer for storage and subsequent deployment to your target device. Several options exist for storing the disk image.

The target device will need to be configured for network boot. Refer to your OEM documentation on how to change the boot device order. This step generally requires pressing a function key (F12) to initiate a network (PXE) boot.

As a best practice, you should set the network (PXE) boot as the first option in the boot order. By setting it as the first option, an on-site user can press a key to boot to the server to recover a device. In some cases, the BIOS does not allow for keyboard initiation of PXE boot. In this case, you need to change the boot order in your BIOS. The best practice production setting is to set automatic PXE boot as the second boot option. This facilitates a boot to the network in the case where the primary boot device is not functioning.

Capture the image to a network share using ImageX

The first step in capturing an image to a network share is to configure the target device to boot using PXE. After the target device has been configured, connect it to the same Ethernet network where the Windows Deployment Server is located. After you have connected it to the network, boot the device and allow the PXE process to complete.

The network boot process will begin with the Windows Boot Manager. Select the Windows PE boot image that was added to the server in step 3.

After Windows PE is loaded, you will be presented with a command prompt window.

From the Windows PE command prompt, you can capture the POSReady image from the hard drive of the reference device. You can then store the image on an additional disk that is attached to the reference device, or on a network share. This guide focuses on capturing the Windows Imaging Format (.wim) image onto a network share.

Note:
To complete the following steps, ensure that a network share is accessible from the target device and that you have access to the share.

At the Windows PE command prompt, type:

net use z: >\\<servername>\<share> /user:username password

<servername> is the name of the computer that is hosting the shared folder. <share> is the name of the folder shared on the server. The username and password values are the credentials of users who have been given access to log on to the share.

You are now ready to use ImageX to capture the gold image. Notice that the Windows PE command prompt defaults to x:\. This is the RAM drive created during the boot process. Navigate to the drive that contains the POSReady image. In most cases this will be the c:\ drive. At the Windows PE command prompt type:

ImageX /capture /compress maximum c:\ z:\POSReady.wim "POSReady"

Note:
Windows PE assigns X as the drive letter of any media that it boots from, and the assignment cannot be modified.

The POSReady image is now captured to the z:\ network share.

Note that POSReady images are hardware abstraction layer (HAL)-specific so you cannot deploy an image of one HAL type to a computer with a different HAL. All images of Windows operating systems earlier than Windows Vista are HAL-specific. If you are planning to deploy different types of hardware, you may need to create a custom image based on the HAL. You can determine the HAL that is loaded by reviewing the computer node in the device manager. For reference information, see this Microsoft Web site.

5. Add the cloned image to the Windows Deployment Services server

You can add the POSReady cloned image to the Deployment Server environment by using the Windows Deployment Services MMC snap-in.

To add a boot image

1. To open the snap-in, click Start, then click All Programs, click Administrative Tools, and then click Windows Deployment Services.

2. In the left pane of the Windows Deployment Services MMC snap-in, expand the server list, and locate the server where the boot image is located.

3. Right-click the Install Image node, and then click Add Install Image.

4. Browse to select the boot image (for example c:\winpe_x86\winpe.wim), and then click Open.

5. On the Image File page, click Next.

6. On the Image Description page, click Next to select the default name and description.

7. On the Summary page, click Next.

8. Click Finish.

9. Optional. Click the Boot tab.

10. Optional. Under x86 Architecture, click Browse, and choose pxeboot.n12.

11. Optional. Click OK.

For additional reference information, see this Microsoft Web site.

The process for manually deploying the POSReady image that was previously captured is similar to the process to capture the image itself. The first step is to boot the target device to the Windows Preinstallation environment (Windows PE). You can do this by following the same steps above by using either a CD or DVD or over the network through the Windows Deployment Services PXE boot feature.

After the device has booted into Windows PE, the process to deploy the image consists of three main steps:

1. Preparing the target device to accept the POSReady image.
   
2. Confirming the POSReady image is visible (network, DVD, USB).
   
3. Deploying the POSReady image to the target device by using ImageX.
   

Preparing the target device:

To prepare the target device, you should partition and format the hard disk. This can be done in an automated fashion by scripting the process, or manually from the Windows PE command prompt. To partition the drive, enter the following commands at the Windows PE command prompt, assuming disk 0 is the location where POSReady will be deployed:

Diskpart
Select Disk 0
Clean
Create Partition Primary
Assign Letter C
Active
Exit

Format c: /fs:NTFS /q /y /v:POSReady\

Note:
The command "list disk" will display all disks attached to the device. You can then confirm which disk you want to format.

The commands shown above will partition and format the disk with the NTFS file system. Next, copy the POSReady image to the disk using ImageX. If the POSReady .wim file is stored on a network share, you should ensure you have access to the share.

Accessing the image:

To access an image on a network, you must map a drive to the network share.

net use z: \\servername\share /user:username password

To access an image on any other media, that media must be visible.

Deploying POSReady to the target device:

Now that the device is prepared, you can use the ImageX utility with the /apply argument to deploy the POSReady image onto the target (c:\) drive:

ImageX /apply z:\POSReady.wim 1 c:

After the image has finished loading, type Exit from the Windows PE command prompt to restart the device.

The process for deploying POSReady from a Windows Deployment Services (WDS) server involves the following steps:

1. Boot the target device from the WDS server network (PXE) boot.
   
2. Connect to the WDS server with user credentials.
   
3. Select the image that you want to deploy to the target device.
   
4. Prepare the target device to accept the OS image. Preparation includes steps such as partitioning and formatting the storage device.
   

This section will cover the manual steps involved in deploying an image to a target device. Please note that steps 2 through 4 can be automated to reduce the involvement of the user in the production environment. Automation requires you to provide answers for the user to the WDS server in advance. For detailed reference information, see this Microsoft Web site.

Boot the target device:

You must configure the reference device for network boot. Refer to your OEM documentation on how to change the boot device order. This step generally requires you to press a function key (F12) to initiate a network (PXE) boot.

As a best practice, you should set the network (PXE) boot as the first option in the boot order. That allows an on-site user to press a key to boot to the server to recover a device.

Connect to the WDS server:

Before connecting to the WDS server, you will be prompted to select some basic options for information. This information includes:

• System language
  
• System keyboard type
  
• Credentials
  

The user must enter his or her credentials before connecting to the WDS server. The default setting is to require only standard "User" credentials; however, your domain policy may differ. The user's credentials must have access to the share where the images are stored, which is by default "RemoteInstall".

Select the image to deploy:

An image selection menu will be presented to the user (see below). There should be specific instructions on which image to deploy to the device.

Prepare device for install:

The user will be presented with a screen to select the location to install the image (see the figure below). The action that the user takes will depend on whether the disk has already been partitioned. You will need to develop a procedure for how to respond to this portion of the installation. We recommend that you automate this step because of the level of instruction required to perform this step. For detailed information on providing an answer file to WDS, see this Microsoft Web site.

This guide does not cover how to deploy the POSReady operating system by using the System Center Configuration Manager (ConfigMgr). ConfigMgr is typically part of an enterprise strategy to manage many different types of devices.

The differences related to the POSReady operating system relate to the preparation of the Windows Imaging Format (.wim) file. Refer to your enterprise ConfigMgr strategy to incorporate deployment of the customized POSReady .wim file in a production environment.

The POSReady image supplied by the OEM should have been prepared using Sysprep before leaving the factory. This means that when the device is booting for the first time it is already set to generate its own unique computer name. If there is no requirement within the enterprise to control the actual name assigned to the computer, then this step can be skipped. However, many enterprise environments use a naming scheme for computer names. If your enterprise requires a customized computer name, follow the process outlined below.

To automatically change the computer name for a device, you can use a script. The code below is a Visual Basic Script that changes the computer name to NewSystem001.

Note:
You will have to develop a process by which the script gets the computer name in an automated fashion due to the unique requirements of each environment. That may mean accessing a network share and parsing a text file to retrieve the name or some other process that achieves the same goal.

strComputer = "."
strComputerName = "NewSystem001"
Set objWMIService = GetObject("winmgmts:" _
    & "{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2")

Set colComputers = objWMIService.ExecQuery _
    ("Select * from Win32_ComputerSystem")

For Each objComputer in colComputers
    err = objComputer.Rename(strComputerName)
Next

With POSReady, the process for joining a Windows domain is the same process that you would follow when joining a Windows XP or Windows Vista computer to the domain. The process for joining the device to a domain is outlined at this Microsoft Web site.

It is also possible to automatically join a POSReady device to a domain by using a script. The code below is a Visual Basic Script that will join the device to a fictional domain named BigRetail.

Const JOIN_DOMAIN = 1
Const ACCT_CREATE = 2
Const ACCT_DELETE = 4
Const DOMAIN_JOIN_IF_JOINED = 32
Const JOIN_UNSECURE = 64
Const MACHINE_PASSWORD_PASSED = 128
Const DEFERRED_SPN_SET = 256
Const INSTALL_INVOCATION = 262144
 
strDomain = "BigRetail"
strPassword = "secret"
strUser = "Administrator"
 
Set objNetwork = CreateObject("WScript.Network")
strComputer = objNetwork.ComputerName
 
Set objComputer = GetObject("winmgmts:{impersonationLevel=Impersonate}!\\" & _
    strComputer & "\root\cimv2:Win32_ComputerSystem.Name='" & _
        strComputer & "'")
 
ReturnValue = objComputer.JoinDomainOrWorkGroup(strDomain, _
    strPassword, strDomain & "\" & strUser, NULL, _
        JOIN_DOMAIN + ACCT_CREATE)

In some environments it may be necessary to configure the POSReady device to automatically log on by using a specified user name and password. This is a common scenario on POS devices. The POS application itself typically tracks which cashier is using the terminal at any given time. To configure automatic logon, follow the process outlined at this Microsoft Web site.

It is also possible to enable automatic logon by using a script. The code below runs within a batch file. The commands will enable automatic logon by setting the DefaultUsername, DefaultPassword, and AutoAdminLogon entries in the system registry. An additional option, ForceAutoLogon, can be used to prevent an end user from logging out of the POSReady device. If you want to bypass the automatic logon to log on as a different user, hold down the SHIFT key after you log off or after the OS restarts.

Dim WshShell
Set WshShell = WScript.CreateObject("WScript.Shell")
strUsername = "Administrator"
strPassword = "secret"
strDomain = "BigRetail"

wshShell.RegWrite "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\AutoAdminLogon", "1", "REG_SZ"
wshShell.RegWrite "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\DefaultUserName", strUsername, "REG_SZ"
wshShell.RegWrite "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\DefaultDomainName", strDomain, "REG_SZ"
wshShell.RegWrite "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\DefaultPassword", strPassword, "REG_SZ"
wshShell.RegWrite "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\ForceAutoLogon", "1", "REG_DWORD"

Now that the OS is configured with a unique computer name and joined to the domain, you may need to apply additional customizations in the form of site-specific applications or updates to existing applications that occurred after the cloning process. These may include custom applications, Windows components, POS applications, and peripheral drivers.

Typically a POSReady OS will boot directly into the application that it was designed to run. There are several ways to accomplish booting directly into an application, each with pros and cons. The three most common scenarios are listed below, along with suggestions for when each would be appropriate.

• Starting an application at startup by using a Startup folder item
  This method is likely the easiest for starting an application automatically at startup. To add an application to the Startup folder, create a shortcut to the application that is to be started. Copy the shortcut into the C:\Documents and Settings\%user%\Start Menu\Programs\Startup folder, and restart the OS. Alternatively, you can copy the shortcut to C:\Documents and Settings\All Users\Start Menu\Programs Startup. This folder will cause the application to start when any user logs in as opposed to when a specific user logs in.
  
• Starting an application at startup by using the Run key in the system registry
  You can specify that an application be started automatically from within the system registry. This is the same process used by many of the system tray applications and utilities that open with Windows. The Run key is processed by Windows Explorer just after logon. For more information about the Run key and how it is processed, see this Microsoft Web site.
  
• Starting an application as the Windows shell
  You can start an application as the Windows Shell instead of using the standard Windows Explorer. This method is beneficial where security is of higher concern and you want to hide Windows from end users. When you run an application other than Windows Explorer as the shell, it can cause other complications within the OS and you should test the OS thoroughly to ensure that it performs as expected. To add a custom application as the Windows Shell application, modify the following registry value:
  
  [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon]
  "Shell"="yourapp.exe"

As mentioned earlier, each of the steps above can be performed manually on each device or automatically by using a script. The following information details the process of compiling each of the steps into a larger script and then staging that script to be started automatically on first boot.

Each step should be copied into a master script file. This guide assumes that the file is named Config.vbs. This file should be copied to the \Windows\System32 folder on the target device that you want to capture your image from. The script should look similar to the following example:

Dim WshShell

Const JOIN_DOMAIN = 1
Const ACCT_CREATE = 2

strComputer = "."
strComputerName = "NewSystem001"
strDomain = "BigRetail"
strPassword = "secret"
strUsername = "Administrator"

'Set the computername of the local system to strComputername
Set objWMIService = GetObject("winmgmts:" _
    & "{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2")

Set colComputers = objWMIService.ExecQuery _
    ("Select * from Win32_ComputerSystem")

For Each objComputer in colComputers
    err = objComputer.Rename(strComputerName)
Next

'Join the Active Directory Domain strDomain

Set objNetwork = CreateObject("WScript.Network")
strComputer = objNetwork.ComputerName
 
Set objComputer = GetObject("winmgmts:{impersonationLevel=Impersonate}!\\" & _
    strComputer & "\root\cimv2:Win32_ComputerSystem.Name='" & _
        strComputer & "'")
 
ReturnValue = objComputer.JoinDomainOrWorkGroup(strDomain, _
    strPassword, strDomain & "\" & strUsername, NULL, _
        JOIN_DOMAIN + ACCT_CREATE)

Set WshShell = WScript.CreateObject("WScript.Shell")
wshShell.RegWrite "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\AutoAdminLogon", "1", "REG_SZ"
wshShell.RegWrite "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\DefaultUserName", strUsername, "REG_SZ"
wshShell.RegWrite "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\DefaultDomainName", strDomain, "REG_SZ"
wshShell.RegWrite "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\DefaultPassword", strPassword, "REG_SZ"
wshShell.RegWrite "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\ForceAutoLogon", "1", "REG_DWORD"

Next, use the Windows Registry Editor to create a new string (REG_SZ) entry in the registry under HKLM\Software\Microsoft\Windows\CurrentVersion\RunOnce with a Name value of Config and a data value of "c:\Windows\System32\Config.vbs". This stages the Config.vbs file to be started one time at the next startup. This is preferred because you do not want the configuration script to run more than one time. The entry will be removed from the RunOnce key automatically after the batch file has run successfully.

Now that the OS is configured (either manually or a script has been staged to configure the OS on next reboot), you are ready to complete the process by running FBReseal and capturing a new gold image.

Note:

It is advisable to capture a pre-FBReseal image to store for future use. The pre-FBReseal image should be configured with the necessary applications and utilities so you can image a target device with the POSReady installation as it existed prior to FBReseal. Having a backup copy is valuable in a situation where you would like to add or remove utilities from the configured OS and then use FBReseal and capture a new gold image. Follow the steps in Capturing the POSReady Gold Image above to capture the pre-FBReseal image.

The patch management process for POSReady uses the same tools and techniques as Windows XP Professional. The same hotfixes, security patches, and important updates that have been issued for Windows XP Professional are used with POSReady. There are no custom versions of these updates for POSReady. However, there are patches and updates that are unique to POSReady. These patches and updates are for additional functionality that has been added beyond the base Windows XP Professional release and are provided by your OEM.

Because patch management for POSReady uses the same patches as Windows XP Professional SP3, it also uses the same tools as Windows XP Professional SP3 such as:

• Windows Update
  
• Windows Server Update Services (WSUS)
  
• SMS and System Center Configuration Manager (ConfigMgr)
  

Software Update Services

POSReady includes the Windows Update agent for use with the Windows Update service. Although POSReady supports the use of Windows Update for patch management, we do not recommend it for use in a retail environment. Not all retail devices have access to the Internet. In addition, you will likely need to verify and test patches and updates against their application stack and configuration prior to updating the devices in the field. As a result, you may want to manage the update process through the Windows Server Update Service (WSUS). By using WSUS, you can retrieve patches and updates directly from Microsoft. You can then validate the patches and schedule the update process from within a secure Intranet environment. To learn more about WSUS, see this Microsoft Web site.

By using WSUS with an Active Directory group policy, you can manage update settings and distribution. If you are deploying retail devices in an Active Directory environment, we recommend that you create a new Group Policy Object (GPO) that contains only the WSUS settings.

Note:
We recommend that you do not edit the Default Domain or Default Domain Controller GPOs.

The new GPO gives retailers the flexibility to have different groups of devices configured with their own unique WSUS settings. You can then link the new GPO to the appropriate Active Directory container for your environment. In some network configurations, this can be the domain. In a more complex configuration, the GPO may be linked to specific organizational units.

If you are deploying retail devices in an environment that does not support Active Directory, you can still configure the Windows Update Agent to receive updates from a WSUS server. You can either use the Group Policy Object Editor to edit the Local Group Policy Object or you can change the associated registry settings. For more details, see this Microsoft Web site.

For information on best practices when using WSUS, see this Microsoft Web site.

Retailers who choose to implement an update strategy that includes application updates can use Systems Management Server (SMS) or its successor System Center Configuration Manager (ConfigMgr) with Windows Embedded POSReady. SMS and ConfigMgr provide a comprehensive set of management tools that help you to install and update your applications, including internal applications and those from other sources.

For an overview of ConfigMgr, see this Microsoft web site.

For more information about ConfigMgr, see this Microsoft web site.

Device Management