POSReady 2009 Deployment Planning Guide

7/14/2010

Microsoft Corporation

June 2009

Summary

This technical article contains information about requirements and procedures to build, deploy, and manage Windows Embedded POSReady 2009 point of service devices in a production environment.

Introduction

Target Audience

Deployment Terminology

POSReady Platform Considerations

• Deployment Differences Between POSReady 2009 and Windows XP Professional
• Target Device Considerations
• OEM Product ID Considerations

POSReady Customization Process

• Defining Customization
• Selecting a Customization Method

Customizing the POSReady 2009 Image

• Group Policy
• Security Templates
• Multilingual Options
• Adding Components to Your POSReady Installation

Cloning the POSReady 2009 Customized Image

• Using FBReseal

Capturing the POSReady 2009 Cloned Image

• Capturing the POSReady Gold Image

Distributing POSReady 2009 Images

• Command-Line Deployment
• Windows Deployment Services Deployment
• ConfigMgr Deployment

Post-Deployment Considerations

• Generating the Computer Name for a POSReady Device
• Joining a Domain
• Configuring Automatic Logon
• Installing Applications and Utilities
• Automatically Starting an Application at Startup
• Compiling the Previous Steps into a Single Automated Script

Managing POSReady by Using ConfigMgr

• Patch Management

Conclusion

Introduction

This technical article provides architecture recommendations for building, deploying, and managing POSReady 2009 images in a retail environment. The Microsoft retail solution utilizes the concept of a store server architecture. In a store server architecture, many store workloads run on a single, multipurpose Windows Server. That server is either virtualized or is on a physical computer running locally. This architecture is designed for use in locations that in most cases do not have dedicated IT resources. All key infrastructure capabilities such as directory services, print services, name resolution, and file sharing that are required by the store are provided in a store server architecture.

The goal of this document is to outline best practices that enable you to integrate POSReady devices into an existing enterprise desktop management ecosystem. Traditionally, point of service (POS) devices are managed separately from the rest of the enterprise. This approach has drawbacks, because it requires a dedicated staff and is at times inconsistent with enterprise management practices. You can achieve significant cost savings by implementing the Microsoft store server model as opposed to the traditional stand-alone model. In the store server model, you can enforce key enterprise best practices and customize them to meet retail business requirements. To help you achieve this goal, this guide provides design steps and recommendations that are specific to retail businesses. These steps and recommendations build upon the existing deployment guidance from Microsoft in the Microsoft Windows Desktop Deployment Resource Kit (see this Microsoft Learning Web site) and the documentation for the Microsoft Deployment Toolkit (MDT) 2008.

Windows Embedded POSReady 2009 is built on the foundation of the Windows XP Professional operating system. As a result, many of the deployment concepts and practices for POSReady are identical to concepts and practices for Windows XP. This guide will direct you to existing Windows XP documentation where no differences exist between POSReady and Windows XP deployment practices.

Target Audience

This guide is intended primarily for IT professionals who plan, design, and implement retail branch IT infrastructures. The audience for this guide may also include people in the following positions:

• Technical decision-makers who determine the appropriate technology solutions for their business.
• IT infrastructure architects who design systems to provide appropriate service levels to meet the business needs of their organizations.
• IT application architects who specify the software and hardware used in a branch store environment.
• IT operations managers who manage the services that are provided to the branches.
• Consultants and partners who recommend or implement privacy and security best practices to achieve Payment Card Industry Data Security Standard compliance for their customers.

In addition, Original Equipment Manufacturers (OEMs) may find this guide useful in helping to deliver packaged hardware/software solutions to retail customers.

Deployment Terminology

The terms listed below are used throughout this document. Understanding this terminology will help you better understand the guidance provided in this guide.

Term	Description
Answer File	A file that contains the settings and configurations to apply to a Windows image during installation. This file is typically named Unattend.xml, Unattend.txt, or Sysprep.inf.
Component	A part of the Windows operating system (OS) that specifies the files, resources, and settings for a Windows feature or a part of a Windows feature. Some components include Windows unattended installation settings that can be used by OEMs and corporations for customization.
Configuration Pass	A phase of Windows installation. Different parts of the Windows OS are installed in different configuration passes. You can specify Windows unattended installation settings to be applied in one or more configuration passes.
Deployment Point	A folder that contains the files required to deploy images to target computers.
Distribution Share	A folder that contains the source files for Windows products. It may also contain additional device drivers and application files.
End User	The ultimate owner of the Windows POSReady client license, which is typically a retail or hospitality company. In an enterprise environment, this is the IT group that manages the environment.
Image-Based Setup	The mechanism used to install, deploy, and test the installation image.
Operating System Packages	A group of files that Microsoft provides to OEM customers to modify Windows features. Package types include service packs, security updates, language packs, and other software updates. Examples of packages include Product, Windows Foundation, and Feature Pack packages.
Original Equipment Manufacturer (OEM)	The reseller of the Windows POSReady license. Typically the client license is installed on the hardware platform that the OEM manufactures. The OEM sells and supports the license to the end user.
Reference Device	The computer that will be installed into a running production environment. Building this device with a repeatable method is the goal of this document.
Reference Image	A configured Windows image that contains a single reference installation that can be deployed onto many target computers.
Reference Installation	A configured Windows computer that includes additional software and updated drivers.
Target Device	The computer on which you pre-install Windows to be distributed to the production environment. You can either run Windows Setup or install a pre-configured reference image to the target computer.
Task Sequence	A series of steps that perform a deployment. During Lite Touch Installation (LTI) deployments, the task sequence is associated with a Unattend.xml (or Unattend.txt and Sysprep.inf) file.
Task Sequencer	Software that is used to perform a task sequence on the target computer.
Technician Computer	The computer on which the image management tools are installed. Typically, this includes the Microsoft Deployment Toolkit and/or the Windows Automated Installation Kit.
Unattend.xml	The generic name for the Windows Vista Setup answer file. Unattend.xml replaces all the answer files in earlier versions of Windows. This includes Unattend.txt and Winbom.ini.
Windows Imaging Format (.wim) File	A file format that contains one or more compressed Windows images.
Windows Feature	An optional feature of Windows that can be enabled or disabled.

POSReady Platform Considerations

In This Section:

Deployment Differences Between POSReady 2009 and Windows XP Professional

Target Device Considerations

OEM Product ID Considerations

Deployment Differences Between POSReady 2009 and Windows XP Professional

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.

Target Device Considerations

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.

OEM Product ID Considerations

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 Customization Process

In This Section:

Defining Customization

Selecting a Customization Method

Defining Customization

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.

Step 3 - Clone the image

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

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.

Selecting a Customization Method

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.

Customizing the POSReady 2009 Image

In This Section:

Group Policy

Security Templates

Multilingual Options

Adding Components to Your POSReady Installation

The second step of the customization process is to install the customization components that are global in nature. These customizations will not include site specific information. These generic settings are the foundation for the device as it will exist in the production environment. By applying these global settings, you can ensure that each device adheres to enterprise IT policies.

Group Policy

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.

Security 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.

To apply a security template

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.

Multilingual Options

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.

To install additional language collections

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.

To install a MUI pack on POSReady 2009

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.

Adding Components to Your POSReady Installation

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

To install additional components to your POSReady installation

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.

Cloning the POSReady 2009 Customized Image

The third step in the customization process is to prepare the customized image to be cloned. This cloning process resets the operating system to the state that it was when it was delivered from the OEM. This step finalizes or "seals" the customized device and shuts down the device.

Using FBReseal

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.

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.

Capturing the POSReady 2009 Cloned Image

The fourth step in the customization process is to "capture" an image of the hard disk into a format that can be distributed and reused in the production environment.

Capturing the POSReady Gold Image

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.

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"

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.

Distributing POSReady 2009 Images

The fifth step in the customization process is to deploy the cloned image to the target computer. The target computer is assumed to be the final production environment.

In This Section:

Command-Line Deployment

Windows Deployment Services Deployment

ConfigMgr Deployment

The same tools and utilities that you used in the cloning process are used for the final deployment. This section also covers deployment from a Windows System Center Configuration Manager (ConfigMgr) server environment. The deployment process for POSReady 2009 consists of three main steps:

1. Boot the target device from a Windows PE boot image.
2. Prepare the target device to accept the OS image.
   Preparation includes steps such as partitioning and formatting the storage device.
3. Load the OS image onto the target device.
   Loading can be accomplished by using one of three methods:
   1. Command-line deployment using the ImageX utility.
   2. Network deployment from a WDS server using the PXE boot feature.
   3. Network deployment from a ConfigMgr server using PXE boot feature.

The method of distribution is largely determined by the environment in which the image will be distributed. For example, a device that is not connected to a network is not able to take advantage of PXE and deployment over Ethernet through WDS. Similarly, if the target device has no optical drive, distribution through CD or DVD is not possible. Multiple methods for image distribution are discussed in this section. Although a given method may not fit perfectly into your environment, a combination of the methods outlined below may be suitable.

Command-Line Deployment

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\

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.

Windows Deployment Services Deployment

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.

ConfigMgr Deployment

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.

Post-Deployment Considerations

In This Section:

Generating the Computer Name for a POSReady Device

Joining a Domain

Configuring Automatic Logon

Installing Applications and Utilities

Automatically Starting an Application at Startup

Compiling the Previous Steps into a Single Automated Script

After the customized POSReady image is deployed to a target device in a production environment, there are typically site-specific customization steps that must be performed.

The following scenario outlines a manual post-installation customization process that works for many environments:

1. The end customer/retailer boots the device for the first time, and it completes the resealing process whereby it becomes a unique device on your network.
2. The computer name of the device is likely changed to follow the naming scheme used by the rest of the enterprise.
3. The device is joined to the corporate or local domain.
4. Site-specific software is installed on the device.
5. The POSReady device is placed in the appropriate location and is ready for normal use.

Following something similar to the process above can yield good results. However, when you move beyond adding a few devices at a time and start to consider deploying hundreds or thousands of devices at once, the manpower required to perform the steps becomes cost prohibitive. Spending time automating the post-installation process will save you both time and resources.

The most common automation tasks are outlined below with sample scripts that may help to automate the process after deployment.

Generating the Computer Name for a POSReady Device

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.

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

Joining a Domain

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)

Configuring Automatic Logon

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"

Install Applications and Utilities

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.

Automatically Starting an Application at Startup

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"
  

Compiling the Previous Steps into a Single Automated Script

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.

Managing POSReady by Using ConfigMgr

In This Section:

Patch Management

• Software Update Services
• Device Management

This section focuses on managing POSReady in a retail environment. It is intended as a reference to information that exists on the topic. Because of the flexibility of the POSReady OS to operate in various environments, we recommend that you use this information to make decisions regarding how POSReady fits into your enterprise management strategy.

Patch Management

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.

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

POSReady ships with multiple tools that help with local and remote management. In addition, many POS tools support Microsoft and other enterprise management tools. These tools assist you in troubleshooting, configuring, and controlling a POSReady device.

The following table shows the tools included with POSReady.

Tool	Description
Remote Desktop	Provides access to the desktop of a POSReady device remotely.
Remote Regedit	Provides access to the registry of a POSReady device remotely so you can view and edit it.
REG command	Command used in batch files to modify the registry of a POSReady device.
Remote MMC	Provides access to the management console of a POSReady device remotely.
Telnet	Provides access to a command prompt on a POSReady device remotely.
Scripting	Provides access to the complete Windows API for building automated management and configuration scripts.
Powershell	Provides the enhanced scripting language and the command line applications created for Powershell.

The following table shows additional tools that are supported but do not ship with POSReady.

Tool	Description
Remote Tools with SMS/ConfigMgr	Provides access to many of the tools listed in the previous table from the SMS/ConfigMgr console. The SMS/ConfigMgr agent must be deployed to the POSReady device in order to use the Remote Tools.
Monitoring with System Center Operations Manager	Provides a comprehensive monitoring solution for POSReady devices including management packs that monitor the health and status of the POSReady device.
Other tools	Other tools can be used with POSReady. Please contact your provider to determine if a tool is supported for POSReady

Conclusion

What you have learned

By using the information presented in this document, you should now have a better understanding of the requirements and procedures to build, deploy, and manage Windows Embedded POSReady 2009 point of service devices in a production environment.