Servicing checklist
The following tips can help you to successfully complete servicing tasks, and can help make these tasks less time consuming and costly.
Planning Ahead
Think about servicing when you design your devices. Servicing should not be an afterthought. Will your devices be able to connect to the Internet and communicate with a server? Will your devices use modem access? How many servers do you need to handle the load of servicing?
Servicing Experience
Invest the time required to design a clear and consistent user experience for servicing. For example, a set top box periodically downloads a program guide. It can also download updates, which simplifies its design and makes the user experience clear and consistent.
Testing Your Servicing Solution
Test your servicing solution thoroughly so that you are sure that it works correctly. By the time you have deployed your devices in the field, it is too late to fix major bugs. If you thoroughly plan your testing and then test against your plan, you can potentially save time and money. Include scalability testing (tests that ensure that servicing scenarios work the same way, regardless of the number of devices) and corner cases (tests that introduce small deviations in sets of devices).
Have a Back-Up Plan
Make sure that you create a back-up plan in case your primary servicing solution fails. If you typically service devices by using a broadband connection, you might want to be able to dial up by using a modem, also. You might want to be able to service devices through a CD-ROM or a USB storage device, and plan to replace media and devices in case of failures.
Include components that facilitate Servicing
Consider including Device Update Agent (DUA) in your configuration, and edit its parameters. Even if you plan to update the entire image in bulk, you may find requirements in the future to make small changes.
Include useful maintenance tools in your image such as Registry Editor, Administration Support Tools, Misc. Command Line Tools, Net.exe Utility, etc. (See Addenda 1. Table of built-in Windows XP utilities for a complete list)
Perform a Security audit
Review the Security section in this document.
Using Image Difference Engine (ImageDiff)
Microsoft Windows XP Embedded Image Difference Engine (ImageDiff) is available on the OEM Secure web site (Where to get updates).
ImageDiff can be useful for comparing two Standard 2009 images in order to identify the effects of specific targeted changes to an image.
For example it can be useful to observe the changes made to an image when an application, driver, or set of service packs are added.
However, using ImageDiff to perform large scale updates to deployed devices, such as upgrading from SP1 to SP2 is not formally supported. This is mainly because once a Standard 2009 device is deployed, its contents and settings change over time, ultimately becoming significantly different than the original master image from which it derived.
Attempts to apply ImageDiff to perform a whole image update to an image that no longer matches the original master image is likely to render the image non-bootable or cause other functionality problems.
Here is a sampling of scenarios that can cause problems.
Many system components use dynamically generated GUIDs (a GUID is a representation of a large random number) to represent system resources. Examples are the NIC and wireless LAN interfaces; GUIDs are generated when a new network connection is made. Those GUIDS will be different on even identically cloned images. This may break any preset TCP/IP and other settings for the NICs.
Every image has a unique computer Security ID (SID). This is a requirement if the devices are to be networked; which applies to the majority of today's devices. Even two identical cloned images will have different computer SIDs. Even if you don’t run fbreseal, the act of running through FBA generates a random SID. All local users accounts internally are represented by SIDs that derive directly from the computer SID. If you compare two identical cloned images that were installed using the same pre-FBA image, both will have different sets of local users. Although you will see a “George” user on both images, internally those are two different user accounts. This will definitely cause issues with system components and customer’s apps that are tied to specific user account (for example, some of those store a hash of the user SID and password and uses it to authenticate access). Examples: Task scheduler, EFS, IIS, etc.
Registry branches CurrentControlSet (holds critical system-wide config info needed to boot the system) and \Hardware Profiles\Current (system config variations of the base settings) are aliases to ControlSet001 (or 002, etc.) and \Hardware Profiles\001 (or 002, etc). Those may be different even on two identically cloned machines. Copying these branches from one machine to another will likely cause hardware problems, confuse the status of services and drivers, and more seriously cause boot issues and bluescreens.
Commonly there are hundreds of customizations (desktop look and feel, fonts, service/hardware configuration, …a very long list) that an OEM or end user tweaks on a deployed image. Applying a whole image diff derived from another image will likely cause loss or corruption of many of these customizations.
ImageDiff is a simple image differencing tool. ImageDiff has no knowledge of interdependencies between registry entries, i.e. knowing which registry setting combinations are valid. Therefore it is possible to inadvertently apply a set of registry settings that are not valid and/or have never been formally tested. Note that direct modification to system OS registry entries (bypassing APIs intended for that purpose) is commonly not supported.
Common servicing questions When replacing critical system binaries do I need to disable Windows File Protection (WFP) first?
If SCCM (and hence Sysprep) is not used, the answer is no, because WFP is permanently disabled in Standard 2009. Your servicing mechanism does not need to take any special steps. However if a binary that you need to replace is currently in use, you will need to either (1) rename the old in-use binary and then copy in the new one, or (2) use the inuse.exe utility to cause the binary to be replaced on the next boot:
How to replace currently locked files with Inuse.exe
However, if using SCCM (which uses Sysprep), Windows File Protection may be partially or fully enabled, because Sysprep requires the full, standard XP Pro binaries that enable WFP.
How can I identify Operating System version, Service Pack level, and specific XP Embedded platform? Method 1. Using the GetVersionEx() Function
To find out whether the OS is fundamentally one of the XP Embedded platform versions use the GetVersionEx() function.
The OSVERSIONINFOEX structure reports XPe devices with a value of VER_SUITE_EMBEDDEDNT.
If finer granularity is required, here are additional options.
Method 2. Using the IsOS() API
This API approach is the preferred method because registry structures may change in future versions.
Refer to the API info found at MSDN on-line:
IsOS Function
Use the IsOS() Function to distinguish between the various OS versions:
// WEPOS is based on Embedded and therefore needs to be detected before Embedded
if (IsOS(OS_WEPOS))
{
// WEPOS
}
// Windows Fundamentals for Legacy PCs (WinFLP / EIGER) can be based on Embedded and therefore needs to be detected before Embedded
else if (IsOS(OS_FUNDAMENTALS))
{
// WinFLP
}
else if (IsOS(OS_EMBEDDED))
{
// Generic Embedded XP;
}
else if (IsOS(OS_WES))
{
// Windows Embedded Standard
}
// need to come before OS_PERSONAL since Windows XP Starter Edition is based on personal
else if (IsOS(OS_STARTER))
{
// XP Starter
}
else if (IsOS(OS_PERSONAL))
{
// XP Home
}
else if (IsOS(OS_MEDIACENTER))
{
// XP Media Center Edition
}
else if (IsOS(OS_TABLETPC))
{
// XP Tablet Edition
}
else
{
// XP Professional;
}
Here are the definitions:
#define OS_EMBEDDED 13 // Embedded Windows Edition
#define OS_PERSONAL 19 // Home Edition
#define OS_TABLETPC 33 // TabletPC
#define OS_MEDIACENTER 35 // XP Media Center Edition
#define OS_STARTER 38 // Windows XP Starter Edition
#define OS_WEPOS 43 // Windows Embedded for Point of Service
#define OS_FUNDAMENTALS 44 // Windows Fundamentals for Legacy PCs (WinFLP / Eiger)
#define OS_WES 45 // Windows Embedded Standard
Method 3. Using the GetSystemMetrics Function.
Using the GetSystemMetrics function the following information can be retrieved.
GetSystemMetrics Function
SM_WEPOS (0x2003) indicates WePOS.
SM_Fundamentals (0x2004) indicates Windows Fundamentals for Legacy PCs (WinFlp)
See also the following KB article to determine if Windows Fundamentals is installed:
How to identify a Windows Fundamentals for Legacy PCs-based computer
Method 4. Registry inspection
Here are the registry settings for the various OS types and versions.
|
Registry References (see legend for associated registry key)
|
OS
|
ProductSuite
|
MajorVersion
|
XpeVersionInfo
|
WeposVersionInfo
|
XPe SP1
|
EmbeddedNT
|
0x100 (Note 1)
|
n/a
|
n/a
|
XPe SP2
|
EmbeddedNT
|
0x200
|
n/a
|
n/a
|
XPe FP2007
|
EmbeddedNT
|
0x200
|
FP2007
|
n/a
|
XPe UR1.0
|
EmbeddedNT
|
0x200
|
Update Rollup 1.0
|
n/a
|
XPe SP3
|
EmbeddedNT
|
0x300
|
SP3
|
n/a
|
Windows Embedded Standard 2009
|
EmbeddedNT
|
0x300
|
Windows Embedded Standard 2009
|
n/a
|
WEPOS 1.0
|
EmbeddedNT
|
0x200
|
n/a
|
1.0.0
|
WEPOS 1.1
|
EmbeddedNT
|
0x200
|
n/a
|
1.1.0
|
XP Pro SP1
|
(empty string)
|
0x100
|
n/a
|
n/a
|
XP Pro SP2
|
(empty string)
|
0x200
|
n/a
|
n/a
|
XP Pro SP3
|
(empty string)
|
0x300
|
n/a
|
n/a
|
Note 1: This field may be blank owing to a bug in the original release of XPe SP1. The OEM can add the value 0x100 in order to enable XPe SP1 Runtime Desktop QFE (DQI) Installer updates to work correctly.
n/a = Not Applicable
Registry References legend:
Label
|
Registry key and value path
|
ProductSuite
|
HKLM\SYSTEM\CurrentControlSet\Control\ProductOptions\ProductSuite
|
MajorVersion
|
HKLM\SYSTEM\CurrentControlSet\Control\Windows\CSDVersion
|
XpeVersionInfo
|
HKLM\SYSTEM\CurrentControlSet\Control\WindowsEmbedded\ProductVersion
|
WeposVersionInfo
|
HKLM\Software\Microsoft\WEPOS\Version
|
Note that WINVER or MSINFO32 report the Service Pack version based on the CSDVersion section of the registry above.
A Script for reporting OS information
Use the following VB script to report OS versioning information, including:
Identifies the OS as Windows Embedded Standard 2009, WEPOS, POSReady or Windows
OS Version
If Embedded, then what version of XP including Service Pack it is based on
Hardware Manufacturer and Model
Registration: Owner and Company
License: Evaluation vs Unlimited
If Evaluation it reports days to expiration
Copy the following script into a file and rename the file so it has a .VBS extension.
'
' Windows Embedded POSReady 2009
' Last Rev: August 26, 2008
'
const HKEY_LOCAL_MACHINE = &H80000002
strComputer = "."
strWPAKeyPath = "SYSTEM\WPA\"
strWPAValueName = "Installed"
dwWPAValue = 0
strAppKeyPath = "SOFTWARE\Microsoft\"
strAppVersion = "Version"
strAppBuild = "Build"
strAppVersionValue = ""
strAppBuildValue = ""
Set objWMIRegistry = GetObject("winmgmts:" & "{impersonationLevel=impersonate}!\\" & strComputer & "\root\default:StdRegProv")
Set objWMIService = GetObject("winmgmts:" & "{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2")
Set colWPA = objWMIService.ExecQuery ("Select * from Win32_WindowsProductActivation")
Set colOperatingSystems = objWMIService.ExecQuery ("Select * from Win32_OperatingSystem")
Set colComputerSystem = objWMIService.ExecQuery ("Select * from Win32_ComputerSystem")
'----------------------------------------------------
' Operating System
'----------------------------------------------------
objWMIRegistry.GetDWORDValue HKEY_LOCAL_MACHINE, "SYSTEM\WPA\WES", strWPAValueName, dwWPAValue
If dwWPAValue = 1 Then
strApp = "WES"
Else
objWMIRegistry.GetDWORDValue HKEY_LOCAL_MACHINE, "SYSTEM\WPA\POSReady", strWPAValueName, dwWPAValue
If dwWPAValue = 1 Then
strApp = "POSReady"
Else
objWMIRegistry.GetDWORDValue HKEY_LOCAL_MACHINE, "SYSTEM\WPA\WEPOS", strWPAValueName, dwWPAValue
If dwWPAValue = 1 Then
strAPP = "WEPOS"
Else
strApp = "Windows"
End If
End If
End If
If strApp = "Windows" Then
For Each objOperatingSystem in colOperatingSystems
strInfo = strInfo & "PRODUCT:" & vbTab & objOperatingSystem.Caption & vbCrLf
strInfo = strInfo & vbTab & vbTab & objOperatingSystem.Version & " (" & objOperatingSystem.CSDVersion & ")" & vbCrLf & vbCrLf
strOSMajorVer = Left(objOperatingSystem.Version,1)
Next
Else
If strApp = "WES" Then
strInfo = strInfo & "PRODUCT:" & vbTAB & "Windows Embedded Standard" & vbCrLf & vbCrLf
For Each objOperatingSystem in colOperatingSystems
strInfo = strInfo & "BASED ON:" & vbTab & objOperatingSystem.Caption & vbCrLf
strInfo = strInfo & vbTab & vbTab & objOperatingSystem.Version & " (" & objOperatingSystem.CSDVersion & ")" & vbCrLf & vbCrLf
strOSMajorVer = Left(objOperatingSystem.Version,1)
Next
Else
If strApp = "POSReady" Then
strInfo = strInfo & "PRODUCT:" & vbTab & "Windows Embedded POSReady 2009" & vbCrLf
Else
strInfo = strInfo & "PRODUCT:" & vbTab & "Windows Embedded for Point of Service" & vbCrLf
End If
For Each objOperatingSystem in colOperatingSystems
If objOperatingSystem.SuiteMask And 64 Then
objWMIRegistry.GetStringValue HKEY_LOCAL_MACHINE, strAppKeyPath & strApp, strAppVersion, strAppVersionValue
objWMIRegistry.GetStringValue HKEY_LOCAL_MACHINE, strAppKeyPath & strApp, strAppBuild, strAppBuildValue
strInfo = strInfo & vbTab & vbTab & "Version: "
If strAppVersionValue Then
strInfo = strInfo & strAppVersionValue
Else
strInfo = strInfo & "1.0"
End If
If strAppBuildValue <> "" Then
strInfo = strInfo & " (" & strAppBuildValue & ")"
End If
strInfo = strInfo & vbCrLf & vbCrLf
End if
strInfo = strInfo & "BASED ON:" & vbTab & objOperatingSystem.Caption & vbCrLf
strInfo = strInfo & vbTab & vbTab & objOperatingSystem.Version & " (" & objOperatingSystem.CSDVersion & ")" & vbCrLf & vbCrLf
strOSMajorVer = Left(objOperatingSystem.Version,1)
Next
End If
End If
'----------------------------------------------------
' Computer System
'----------------------------------------------------
strInfo = strInfo & "COMPUTER:"
For Each objComputerSystem in colComputerSystem
strInfo = strinfo & vbTab & objComputerSystem.Manufacturer & vbCrLf
strInfo = strinfo & vbTab & vbTab & objComputerSystem.Model & vbCrLf & vbCrLf
Next
'----------------------------------------------------
' Registration
'----------------------------------------------------
For Each objOperatingSystem in colOperatingSystems
strInfo = strInfo & "REGISTRATION:"
strInfo = strInfo & vbTab & objOperatingSystem.RegisteredUser & vbCrLf
strInfo = strInfo & vbTab & vbTab & objOperatingSystem.Organization & vbCrLf & vbCrLf
Next
'----------------------------------------------------
' Evaluation Period
'----------------------------------------------------
If strApp = "POSReady" Then
For Each objWPA in colWPA
strInfo = strInfo & "LICENSE:"
If (objWPA.RemainingEvaluationPeriod > 2000000000) Then
strInfo = strInfo & vbTab & "Unlimited" & VBCR & VBLF
Else
strInfo = strInfo & vbTab & "Evaluation" & vbCrLf
strInfo = strInfo & vbTab & vbTab & objWPA.RemainingEvaluationPeriod & " Days Remaining" & VBCR & VBLF
End If
Next
End If
'----------------------------------------------------
' Display results
'----------------------------------------------------
Wscript.Echo strInfo
'----------------------------------------------------
' End of script
'----------------------------------------------------
Can I run a single Standard 2009 target image on multiple hardware devices?
Yes, this is possible and is a common question by OEMs when they want to support multiple HW configs for their customers yet have the same features and functionality across all the devices they market.
The caveat to this is that all the devices must use the same HAL. If the devices require different HALs then all bets are off. Otherwise, you can import multiple PMQs into the same config within TD when creating the runtime.
Also, since there is no driver.cab in Standard 2009, all devices you expect to be attached to the device need to be added to the configuration before deploying the runtime, unless they want the ability to "Add New Hardware" from the desktop. If you want the driver.cab functionality, include the Generic Device Driver Support component, then pick and choose which device classes you need within this component.
Finally please note that you need to run First Boot Agent exactly once on each unique hardware platform, and then you will likely need to maintain one post-FBA master image for each supported hardware platform.
What is the relationship between XP Pro Security Update releases and Standard 2009 Security Update releases?
All applicable XP Pro security bulletins are made available for Standard 2009 in the Security Update packages, available on the OEM Secure web site at the Downloads link. There are two types of update:
an update to the Standard 2009 SQL component database used by Target Designer; found in the \Windows folder
a Desktop Update Installer runtime version; found in the \DQI folder, that you use to update a finished, properly prepared and deployed runtime.
Note that there is a time delay between the release of the XP Pro update and the Standard 2009 version – this is due to the extra engineering we have to do to get the Standard 2009 version ready for release. This delay is usually one business week.
One thing to keep in mind when comparing XP Pro to Standard 2009 is that there are cases where a security update available for Standard 2009 is not applicable to a given device. For example, devices that do not include Internet Explorer would not be affected by the IE update (or the vulnerability it fixed) that was released earlier this week. In this case, the Standard 2009 device is more secure than a similar XP Pro device, simply because the reduced footprint means less surface area for attack.
Can I use Windows XP desktop Updates (hot fixes) in a deployed Standard 2009 runtime?
For testing purposes only, you may be able to apply hot fix packages intended for Windows XP Professional, executing them directly in a running Standard 2009 system. In other words, installing them the same way as you would a DQI runtime update. If you wish to apply those hotfix updates for redistribution, contact Microsoft to obtain an OEM redistribution license for the applicable hotfix.
For general info regarding updating deployed images:
Updating Standard 2009 runtime images after they have been deployed
For production deployment, use the corresponding Standard 2009 Update fixes which update your component database. Then rebuild and deploy your updated runtime using the updated database.
Warning: When deploying hot fixes in this way, you must ensure that the intended target component(s) of each hot fix are also completely included in the runtime image. Since a Standard 2009 image contains a subset of the components that constitute the Windows XP desktop operating system, it is possible that a Windows XP Desktop Update may contain file updates for files that are not already present in your Standard 2009 runtime image. In this case, you might not get the updated version because some updates will only copy files that pre-exist on the target.
1. Use Target Designer to create your runtime image.
2. Deploy your image on your embedded system target. Let FBA complete.
3. On your embedded system target, run the tool services.msc in order to confirm that the Cryptographic Services is installed and is started. Cryptographics Services is required in order to deploy some XP Professional hot fixes.
4. Finally, install and run each of the desired XP Professional hot fixes on the embedded runtime.
5. After installing the hot fixes in this way, a good validation is to compare between a Standard 2009 computer and a desktop XP Pro computer using the same update package to make sure you are getting everything.
Caveats
The installer may fail when it attempts to update a binary that it expects to exist on the image but is not there.
The copied binaries may not correctly implement the update because of dependencies they have on components that may be missing in the image.
Regarding the overwriting of system files, when you configure a DUA script you can specify the need to copy the file after the subsequent reboot. This is something you need to set up yourself.
You can also write a batch file, using the inuse.exe tool available on MSDN, or programmatically via movefileex(). These mechanisms perform the copy on the subsequent reboot.
How do I identify the hot fixes installed in my runtime?
If you run any recent desktop update with the -l switch (that's a lower-case "L"), you will list all the hot fixes (updates) installed.
See also the following registry key where sub keys identify each hot fix in your runtime image: HKLM\Software\Microsoft\Windows NT\CurrentVersion\Hotfix
How do I obtain and configure Licensing Runtime PIDs?
You obtain your runtime PIDs from a licensed distributor, one per deployed Standard 2009 device.
Note that these PIDs are not the same as the PID associated with the Windows Embedded Standard 2009 Tools Suite installation PID.
Also please note that:
The Standard 2009 runtime PIDS will only work with Standard 2009 images
The XP Embedded runtime PIDS up to and including Update Rollup 1.0, will only work with XP Embedded versions prior to Standard 2009.
One runtime PID should be used for all the target devices no matter how many of these devices they’re deploying as long as (1) enough licenses (i.e. Certificate of Authenticity (COA) stickers) are obtained and (2) all these devices belong to the same category (e.g. POS, Thin client, etc). An OEM can pick a PID number on any of the COA stickers and use it as the runtime PID for his Standard 2009 image. If the OEM does not have any stickers yet, then the OEM needs to contact the Microsoft Authorized Embedded Distributors.
More info at:
Licensing a Run-time Image
| 