Deployment techniques - Microsoft Windows Embedded Standard 2009 Developer Resource Kit Componentizing Windows xp...

See also:
Comparison of Servicing Solutions
Device Update Agent (DUA)
DUA is a lightweight solution for delivering scripts from a server to a client device running Standard 2009.
General information about DUA is available here:
Device Update Agent
Inside Device Update Agent (Standard 2009)
DUA scripts are compiled files that make it possible for you to copy, move, and delete files; update registry keys; and manage a device in other ways such as restarting it, copying files to it while it is in use, and running arbitrary files on it. For more information about the DUA scripting language, click on this link:
Device Update Script
Because DUA scripts can copy files and make changes to the registry, delivering a DUA script that contains file and registry changes can implement the updates automatically. Information about file and registry changes required to apply a Standard 2009 update is provided with each update that Microsoft publishes. You must obtain file and registry information for non-Microsoft updates from the appropriate company.
You can deliver DUA scripts to a device manually or automatically. If you choose to deliver the scripts automatically, you must use a server to host the script. The device can then pull the script from the server on a schedule that you set, or the server can push the script to the device when the script is ready. See this link for details:
Applying QFEs with Windows XP Embedded Device Update Agent
Aaron Stebner and Mike Hall developed a tool to make the creation of DUA Script Files simpler. A preview version of this tool is available on the web:
Support for this version of the tool is handled through the web logs (blogs).
DUAScriptGen User’s Guide
Using DUA to install Componentized Standard 2009 updates
This method is for updating images which have been deployed. It uses the Device Update Agent to apply the file and registry changes to an image which is running and which can download the update package.
1. Download from the secure OEM web site, all of the componentized updates of interest.
2. For each update from one of the embedded sites, locate the Additional Info file which is alongside the componentized update on the web site, or included in the componentized update executable. For the ones which are included, open the update executable with WinZip (do not execute it).
3. Extract the Additional Info file and the other system files and put the system files in a directory (Q835732\RESULT in this example).
4. Open the Additional Info file and look over the files and registry entries. Note if there are any files which need to be executed in the update. If there are, then the process for generating the DUA script will be modified by adding the executable in the form of EXECUTEPROCESS in the script.
5. Generate a DUA script by executing the DUAScriptGen.exe program contained with these instructions. Configure the program by entering the options as follows:
Poll Share Location: Checked
Location to poll: C:\DUA\CmdFiles (Same as the setting in your DUA component in Target Designer).
Local Dua Folder: C:\DUA\working
Next Dua Script: C:\DUA\CmdFiles\CmdFile01.DUP (set this to 02, 03, or leave it at 01)
Reboot at the end of script: Checked
6. Click on the "Convert QFE to DUA" button and complete the location of the Additional Info rtf file. The file references and registry entries will be loaded into the tool.
7. Click on "Generate Script" and complete the location of the DUS file to be generated. Name this file with the Update number (Q835732.DUS in this example).
8. Click on "Execute Compiler" and the program will generate a Q835732.DUP file in a directory 'DUA_Files".
9. Place the DUP file and all of the extracted files from the Update in a directory (Q835732\RESULT in this example). Download these files to the image to a directory referenced by the DUA component settings (C:\DUA\CmdFiles in this example). Rename the DUP file according to the configuration of DUA component on your image (CmdFile01.dup in this example).
10. When the DUA service polls the location it will see the script file and execute it. If the reboot is executed at the end it will reboot the image. When the DUA Agent finishes the script it will delete the script file so that it is not repeatedly executed on each poll.
Known issues
Some users have reported having problems setting the registry key with Device Update Agent.
Referring to the Device Update Agent documentation, the size parameter is optional, depending on the command that it applies to. The command reference should really be as follows:
11, [ErrorMode], hKey, [ExpandMode], Key, [ExpandMode], ValueName, Type, [Size,] Value
A size parameter is only needed for DAREG_NONE, DAREG_BINARY, DAREG_LINK, DAREG_RESOURCE_LIST, DAREG_MULTI_SZ. For value types that do not require a size - you should leave out the parameter entirely. DUA will look at the type and based on this information determine if the next parameter should be the size or the value. In the command you included DUA sees that the type is REGSZ and expects the next parameter to be the value. Since the next value is specified as a null string - DUA assumes this is the value you want to set and moves on (this is why the command shows as a success). It ignores anything beyond the last parameter. So you will find that this command sets an empty string:
REGSETVALUE,,HKEY_LOCAL_MACHINE,,SYSTEM\CurrentControlSet\SampleKey,,SampleValue,DAREG_SZ,,Hello World
Whereas this command actually sets the value:
REGSETVALUE,,HKEY_LOCAL_MACHINE,,SYSTEM\CurrentControlSet\SampleKey,,SampleValue,DAREG_SZ,Hello World
Using custom batch files, scripts or programs
Your solution is likely to require some degree of custom software development. At a minimum, you will likely develop custom .CMD or script files, to partially or fully automate the process.
Considerations when updating the image off-line
If the files that need to be updated are in use by the operating system that the device is running, you may need to take the device offline and then copy files to it. In this case, you can update registry keys by directly loading and modifying the files which contain the registry (the hive files) while the device image is not on-line; see the following link for more details:
Registry Hives
You can view and edit the pre-FBA registry hives in your Standard 2009 image off-line, using your development computer. The registry hive files are located in the \WINDOWS\system32\config folder in your Standard 2009 image.
Files with the .SAV extension are pre-FBA. Once FBA completes, the files are saved without the .SAV extension. Therefore any hiv changes you wish to make pre-FBA must be made using the corresponding *.SAV file hives:
DEFAULT.SAV
SOFTWARE.SAV
SYSTEM.SAV
After FBA completes, any hive changes you wish to make must be made using the file hives that do not have a .SAV extension:
DEFAULT
SAM
SECURITY
SYSTEM
Example, pre-FBA editing:
Build your image but do not run FBA yet. Perform an off-line registry hive edit (in windows\system32\config\system.sav) using regedit. The following steps show how to edit the system.sav branch of the registry (which corresponds to HKEY_LOCAL_MACHINE/SYSTEM).
Run Regedit
Click on HKEY_LOCAL_MACHINE
Choose File->Load Hive
Select this file found in your Standard 2009 image: windows\system32\config\system.sav
Choose an arbitrary name for the temporary hive path. For our example we will use FOO.
Make any desired changes to the hive branches, using RegEdit
Click on the FOO key, then use File->Unload Hive in order to unload the registry hive from Regedit
Let your modified Standard 2009 image boot, in order to run through FBA on the modified image.
Considerations when updating the image on-line
You can develop a command or batch file to deploy updates to an on-line image.
1. The REG.EXE tool, found in the Misc. Command Line Tools component, is a command-line interface to the operating system registry, which allows the user to read from and write to the system registry on remote systems as well as on the target system.
2. Use the INUSE.exe tool when you wish to update binaries that are currently in use by the operating system. INUSE works by setting parameters in the registry that get launched at an early time in the subsequent boot, before the operating system has a chance to use the binary. Click on the following link for details.
How to replace currently locked files with Inuse.exe
3. This tool may be useful when installing runtime updates:
How to install multiple hotfixes to allow a single reboot (Q296861)
Systems Management Server (SMS)
Please use SCCM instead, the successor to SMS; click here:
System Center Configuration Manager (SCCM)
Please use the following information for historical reference only.
SMS can be used for all kind of updates deployment, security updates, updates for applications and drivers, and deploying software.
Features:
Microsoft Systems Management Server (SMS). SMS is a complete network management solution for enterprises. A component of Standard 2009 makes it possible for SMS to manage devices. For more information about SMS Server:
SMS 2003 Product Information: Overview
Microsoft Systems Management Server 2003
SMS Scripting. SMS provides a method of packaging custom updates for the devices that are managed by SMS.
System Center Configuration Manager (SCCM)
SCCM 2007 is the successor to Systems Management Server (SMS). SCCM 2007 supports the OS Deployment (OSD) feature for Standard 2009, so that images can now be deployed as well as managed by SCCM.
Include the SCCM 2007 Client Prerequisites component in your design, in order to satisfy the component requirements (dependencies) of SCCM. Then install SCCM after your image has built and after FBA has completed. SCCM 2007 SP1 has been tested for use with Standard 2009 but has not been tested for previous embedded OS versions.
Embedded OS Deployment with System Center Configuration Manager (SCCM)
SCCM introduces the Sysprep component into your design. Using Sysprep for purposes other than for use with SCCM is not supported.
Sysprep Now in Windows Embedded Standard
Using Sysprep in Windows Embedded Standard
Do not use the System Cloning Tool if using SCCM because the reseal process should be performed by Sysprep. In any case, do not reseal the same image more than once.
A comparison:
Comparison of Servicing Solutions
The following links contain older information, but may be helpful in understanding SCCM's relationship with Standard 2009:
SCCM 2007 Prereq Macro is Fully Tested with CTP!
Macro Pre-Requisite Component for SCCM Client is Now Available
System Center Operations Manager 2007 SP1 (SCOM)
SCOM is an Enterprise Software Solution that can do end to end monitoring in the enterprise IT environment:
Windows Embedded Standard 2009 Supports System Center Operations Manager 2007 SP1!
Windows System Update Server Version 2.0 (WSUS)
WSUS is the successor to SUS.
WSUS can be used to push all the security updates that Microsoft publishes via Microsoft Updates which include security updates for Windows, Office, SQL and other Microsoft products.
These are the components needed in your Standard 2009 image to consume updates from a WSUS (SUS 2.0) server:
Windows Update Agent
Windows Update for Device Drivers
See this link for information about SUS:
Using SUS with Windows XP Embedded Service Pack 2
An online training video that includes a SUS tutorial is available at the following online web site:
Windows XP Embedded Tutorials
Within the above page, locate this section, and play the corresponding video:
Windows XP Embedded with SP2 Security Feature Enhancements
SUS uses Windows Update technology, which works well for security updates.
NOTE: The WSUS client components in the XPe SP2 or later database can connect to either a SUS 1.0 server or a WSUS 2.0 server.
The Windows Update Agent for SUS 1.0 Servers component can be used if the Enterprise is still using SUS 1.0 servers and have not upgraded to WSUS 2.0.
Remote Procedure Calls (RPC)
If you have applications that utilize Remote Procedure Calls (RPC), you might need to include multiple RPC components in your configuration. If an RPC function is called, but the RPC component exposing that function is not installed, the function call fails.
The following table shows the available RPC components.
Component
|
Description
|
RPC Local Support
|
Facilitates local RPC using the ncalrpc and ncacn_np protocol sequences, and provides support for dynamic endpoint resolution.
RPCs using the ncalrp protocol can enhance security for remote procedure calls without the need for additional RPC components.
|
RPC Remote
|
Facilitates local and remote RPC calls using the ncacn_ip_tcp, ncacn_http, and ncadg_ip_udp protocol sequences. This component provides the following client and server RPC functionality:
ncacn_ip_tcp
ncadg_ip_udp
ncacn_http, which requires an RPC proxy computer
Secure RPCs are not facilitated by the RPC Remote component. At least one RPC Secure component is required to make secure RPCs, such as Secure RPC over Kerberos, Secure RPC over Negotiate, Secure RPC over NTLM, or Secure RPC over SSL.
The RPC Remote component includes the functionality provided in the RPC Local Support component. Therefore, if you include RPC Remote in a configuration you do not need to include the RPC Local Support component.
|
RPC Authorization Support
|
Exposes the RpcGetAuthorizationContextForClient and RpcFreeAuthorizationContext functions. The RPC Authorization Support component provides no other RPC functionality, and is necessary only to obtain the RPC capabilities exposed by the specified functions.
|
RPC HTTP CIS Server
|
Provides the RPC proxy necessary to make RPC HTTP calls, and is also required by CIS. To successfully complete an RPC over HTTP RPC, the following components must be installed: the RPC Remote component must be installed on the client, the RPC HTTP CIS Server component must be installed on the proxy machine, and the RPC Remote component must be installed on the server.
|
RPC Named Service
|
Provides RPC named service functionality, such as the RPC Locator. The RPC Named Service component exposes all RpcNsxxx RPC functions.
The RPC Named Service component includes RPC Locator service functionality, which runs on the local machine and on the domain controller. The RPC Named Service component is typically used by applications using the auto_handle attribute.
|
RPC Remote over Named Pipes
|
Facilitates remote procedure calls using the ncacn_np protocol sequence. RPC over Named Pipes to a server on the same computer requires the RPC Local Support component.
|
RPC Remote over SPX
|
Facilitates RPCs over SPX to servers residing on the local computer or a remote computer The RPC Remote over SPX component includes both client and server support, and includes support for SPX name resolution.
|
Secure RPC over Kerberos
|
Facilitates RPCs using the Kerberos Security Support Provider Interface (SSPI) for authentication and privacy protection.
|
Secure RPC over Negotiate
|
Facilitates RPCs using the Negotiate Provider Interface SSPI for authentication and privacy protection. This component is not required to make non-secured RPCs. Other Secure RPC components provide different SSPI capabilities for RPC; developers generally include one or more Secure RPC components to secure RPCs.
|
Secure RPC over NTLM
|
Facilitates RPCs using the Windows NT Challenge/Response (NTLM) SSPI for authentication and privacy protection.
|
Secure RPC over SSL
|
Facilitates making remote procedure calls using the SChannel SSPI for authentication and privacy protection. This component is not required to make non-secured RPCs. Other Secure RPC components provide different SSPI capabilities for RPC; developers generally include one or more Secure RPC components to secure RPCs.
|
Remote management
In some cases, you cannot gain physical access to your device once it has been deployed. Standard 2009 provides a comprehensive set of component features to help you to connect via networking to a remote target device, and then remotely administer the device.
Component name
|
Description
|
TCP/IP Networking with File Sharing and Client for MS Networks
|
Enables network functionality. You also must configure your Administrator Account component and machine name, to enable remote administration tools to work. The machine name is found in your PC component (which is named Standard PC, ACPI Multiprocessor PC, or similar)
|
Terminal Services
|
Remote Desktop. Use your local workstation to take control of the console of a remote device (run MSTSC.EXE on your workstation)
|
Remote Registry Service
|
Allows your local workstation to locally use RegEdit to edit the registry of your remote device.
|
Telnet Server
|
Allows your local workstation to connect to the remote device using Telnet. This gives you a remote command prompt so you can deploy updates on the remote device.
|
Microsoft Management Console (MMC)
|
You can use MMC on your local workstation to manage a remote device.
|
Net.exe Utility
|
This is a command line tool that controls users, groups, services and network connections.
|
IIS FTP Server
|
File Transfer Protocol (FTP) server, you can use to copy files to or from the remote device.
|
WMI …
|
WMI Windows Management Instrumentation enables you to collect and manage information about the embedded device.
|
Simple Network Management Protocol (SNMI)
|
The SNMP agent monitors network traffic, and retrieves and updates local management information based on the requests from the SNMP manager.
|
RPC
|
Refer to the section in this document titled “Remote Procedure Calls”
|
Message Box and Balloon Pop-Up Interception
|
This is an Embedded Enabling Feature (EEF) component, named Message Box Default Reply, that addresses how you can force the system to automatically reply to each system-generated MessageBox. This can be useful when remotely managing a device. See also:
Message Box and Balloon Pop-Up Interception
|
Windows Preinstallation Environment deployment alternative
More information about Windows Preinstallation Environment is available in the Windows XP Professional OEM Preinstallation Kit (OPK). Contact your Microsoft Authorized Distributor for additional information.
Deploying images using a Windows Preinstallation Environment WinPE CD
Diskpart.exe can create NTFS bootable drives directly, which removes the need for the bootprep process. The following procedure is a simple walk-through that demonstrates how to make a 600 MB FAT partition that is suitable for image deployment. For this example, one primary partition is created on the first hard disk drive.
Set the BIOS to boot to the WinPE CD-ROM before the hard disk drive.
Boot off of the WinPE CD.
Run Diskpart.exe, and then issue the following commands:
select disk 0
create primary partition size=600
select partition 1
active
quit
Reboot the embedded device, and then boot Windows Preinstallation Environment again.
Format the drive. This example requires FAT, so the command is:
format c:/FS:FAT
Deploy your runtime.
WinPE contains network drivers so you can easily map a network share if your device has a network interface.
Creating a derivative Windows Preinstallation Environment CD
This section contains a method for creating a derivative Windows Preinstallation Environment CD.
Note The Windows XP Professional OEM Preinstall Kit (OPK) contains the OSCDIMG utility referenced below.
To make a Windows Preinstallation Environment boot CD:
Make a temporary folder, X:\Winpe, where X: is the drive you want to use for the temporary folder.
From the Windows XP Embedded CD, disk 1, copy the following files and folders to the X:\Winpe folder:
The entire I386 folder
The entire XPe folder
The Winbom.ini, Win51, and Win51ip files
If you need custom network driver files:
Copy the custom .inf file to the X:\Winpe\I386\Inf folder.
Copy the custom .sys file to the X:\Winpe\I386\System32\Drivers folder.
If you need network support, append the following section to the X:\Winpe\Winbom.ini file:
[WinPE.Net]
IPConfig = DHCP
StartNet = Yes
Delete the X:\Winpe\I386\Bootfix.bin file if you always want to boot from the CD and do not want to receive the prompt: "Hit any key to boot from CD."
Create an ISO file from the temporary X:\Winpe folder:
oscdimg -bx:\etfsboot.com x:\winpe x:\image.iso
Note Copy the Etfsboot.com file from the Winpe folder of the Windows Preinstallation Environment 1.1 OEM (OPK) CD to drive X.
Create the CD from the ISO file.
This CD should now boot and connect to the network.
Using Windows Deployment Server to deploy Standard 2009 runtime images
Refer to Brad Combs' article at XPeFiles.com:
HowTo: Using Windows Deployment Server to deploy XP Embedded runtime images
|