Windows Embedded Standard (NT4e, XPe and beyond)

October 2009 Security Database Updates are Available

2009-11-04T01:56:12Z

The October 2009 Security Updates are now available on the ECE for Windows® Embedded Standard 2009 and/or Microsoft® Windows® XP Embedded with Service Pack 2, Feature Pack 2007, Update Rollup 1.0 and Service Pack 3.

The security updates can be applied to the component database.This download is a cumulative update which incorporates all updates from prior months. Therefore you do not need to download and install previous monthly updates from ECE.

The October Security updates include:

970653 August 2009 cumulative time zone update for Microsoft Windows operating systems
971961 Vulnerability in JScript Scripting Engine Could Allow Remote Code Execution
958869 Vulnerabilities in GDI+ Could Allow Remote Code Execution.
969059 Vulnerability in Indexing Service Could Allow Remote Code Execution
971486 Vulnerabilities in Windows Kernel Could Allow Elevation of Privilege
973525 Cumulative Security Update of ActiveX Kill Bits
974112 Vulnerability in Windows Media Player Could Allow Remote Code Execution
974455 Cumulative Security Update for Internet Explorer
974571 Vulnerabilities in Windows CryptoAPI Could Allow Spoofing
975254 Vulnerabilities in FTP Service for Internet Information Services Could Allow Remote Code Execution
975467 Vulnerability in Local Security Authority Subsystem Service Could Allow Denial of Service
956844 Vulnerability in DHTML Editing Component ActiveX Control Could Allow Remote Code Execution
973812 Vulnerabilities in Windows Media Format Could Allow Remote Code Execution.
975682 Vulnerabilities in Windows Media Runtime Could Allow Remote Code Execution.
896358 A vulnerability in HTML Help could allow remote code execution

Additional Details:

In Odd numbered months, the Security Supplement Update CD contains the Security DQI updates for just that current month, and cumulative Component Database updates in the \Windows folder for each supported Embedded version (SP2, Feature Pack 2007 or Update Rollup 1.0) through the previous even numbered month. In Even numbered months, the Security Supplement Update CD contains the Security DQI updates for just that current month, and the cumulative Component Database updates for each supported Embedded version, which are updated to include the previous odd numbered month, and the current even numbered month updates.

If you are servicing your existing development environment:

On the Embedded Security Supplement Update CD in the \Windows folder, there is a Component Database Update available for each supported Embedded product version (SP2, FP2007, UPR1). If you install the Component Database update applicable to the product version you are using, your database will be current with security updates up to and including the most current even month’s security updates.

If you are servicing deployed images:

Assuming you had the cumulative Component Database updates applied to your development environment on your image creation date, you need only deliver the DQI updates for each month following your release date and have them applied directly to the image or you can update your development environment as described above, and deliver a new image for re-deployment. There may be other methods you employ for servicing your images, these are the two most basic approaches you can take with the updates we provide.

If you are a new developer installing XP Embedded for the first time:

Install XP Embedded up to the product version you wish to use (SP2, Feature Pack 2007 or Update Rollup 1.0). Then install the cumulative Database Component updates provided for that version from the latest Security Supplement Update CD to bring your database up to date with all security updates up to the most recent even numbered month.

Miscellaneous Optional updates:

You will also see other updates available on the ECE which are Optional Updates. These may or may not be applicable to your image and you can review the release notes for applicability to determine if you wish to implement them. These may be provided in DQI format, Component Database update format, or both.

Note:

The Security Supplement Updates were called just Supplement Updates through October 2007, when the name changed to Security Supplement Updates.

If you have questions on accessing the ECE, please email MS Mobile & Embedded Communications Feedback & Support, ECE@microsoft.com.

Thanks,

- Lynda

Technorati Tags: XPe,Standard 2009

Developing high quality test cases

2009-10-31T00:56:58Z

I think it may surprise a lot of people in the industry that Microsoft (and most high visibility software vendors) invests a lot of time and effort into their testing. Quality assurance is so key to the success of our products that every team in the company has personnel whose lives are dedicated to just insuring that quality is in the product. We can debate the success or failure of this effort, from my perspective, even though we find bugs after the fact, and people have issues with our products, with tens of billions of lines of code and trillions of permutations of interoperability’s, that effort has largely been successful.

If you are focusing on testing your product, then you have to do some basics before you can even begin test. The first is having a test plan, followed by a schedule which includes testing, then some automation and unit tests. Each of these are so well known and talked about that entire books, specifications, standards, best practices, etc… have been devoted to them. In fact, so much that I usually go into skim mode when I just run through the list. It’s just too long and it’s hard sometimes to understand the titles or relevance. That should be an indicator of how much software has both evolved and diverged over the past 50 years. I’m pretty sure I can list 20 sub specialties within software development that can be given unique attention without much effort.

So to the topic of developing high quality test cases, where do you begin? You cannot develop test cases without a feature specification, and in fact, I claim if you are testing without a specification, your testing is largely unsuccessful. However, thinking about test cases will tell you more about your tools and automated needs than anything else. Assuming solid unit tests are implemented where do you go?

Here are some questions to ask (it is clearly not an exhaustive list, but should give you ideas):

- Am I testing a kernel mode device driver? If so, do I have specific test cases setup so that Driver Verifier is turned on? Do I define the expected results (almost invariably, bug check, but think about others)? Do I have IOCTLs that are exposed to the application layer and do I test those? Does my driver control hardware, filter, or something else? Network?

- If you are shipping hardware, are you doing internal testing of interfaces via simulation? Are you developing tests to simulate corner case environments, what are the extremes?

- Do I understand and more importantly have the hardware that we are targeting? Platform such as x86 or IA64? Do we have architectural boundaries? Do I know the memory or CPU boundaries? How does it work with other devices, is PnP involved (it probably is)

- Am I user mode testing? Do I use Application Verifier in testing? (If not, I would add test cases for Application verifier).

- Does my feature have any exposed entry points? Do I use fuzz-ing? Are my entry points public or private? LDAP? RPC? DCOM? Win32? COM? Etc…

- If it is a windows application, do I test in safe mode, is safe mode defined, is it relevant? It may be if you need UI in safe mode.

- Do I have UI and do I need to validate all of the controls? Can multiple users select UI in my feature? Do they need to be exclusive? What kind of languages or locales do I support? What globalization issues are my tests going to cover?

- Do I test for accessibility? Are there any accessibility issues with my product? Have I thought about all the dimensions of accessibility?

- Am I testing web pages? Web interfaces? Advanced HTML, Scripts? Java classes? ASP pages?

- Do I validate data? Database tables? Remove Data? How is it accessed? Is it raw, can it be accessed outside my application? Is it formatted, is there a specification for the format?

- What is my security plan? Do I have a threat model and do I validate the known potential boundaries? Am I a secure oriented tester? Have I evaluated the cost of having to release a security update? Am I testing least privileges?

- What are the specific functional items from the specification that I need to validate? Do I have to cover any government standards (an area Microsoft has historically been silent on)? Do I have to meet any other well defined standards as well? This is where your organization must make the hard decisions.

- What types of input do I need to test? Hardware, software, text, keyboard, sound, physical elements? Can I enumerate them all? Can I cover most with a few generic items? That last one is a key to minimizing your test hit.

- What environments will I operate in; do I have clear specifications for these environments? Are there customer requirements to validate?

- Do you know what the product life cycle is and do you have a plan to test updating for bug fixes? Do you test installing new updates? This area is largely untested in virtually every environment I have been exposed to outside of Microsoft. Is there a plan for servicing your feature?

- Do you know how to test versioning, private, public fixes? Have you evaluated how it can go wrong in the cases? Do you have a plan for those scenarios?

- Do you have an uninstall option after install? Do you validate that uninstall works correctly, can you reinstall? Does it work then?

I could write a book on just these questions while adding more, and indeed, there are books that ask and in a general way answer these questions. Evaluating all of these will help you define quality test cases. For each of the above areas, you have some more criteria you need to define, some tests that measure the results, and then some action to make sure that during development and even after you ship, you have clearly built test cases that will bring quality to your feature.

You can “test” your test case by answering these questions:

Do I define the results of the test?

Does the test clearly define what it is testing?

Can the test be modified to produce variations?

Can the test validate both positive and negative inputs?

Will the test always be viable?

Does the test validate the functional specification?

Will the test always report success and/or failure clearly where there is no ambiguity?

In other words, a quality test case has the following properties:

- It is well defined and has unique relevance to your feature

- Is built upon either existing proven tests or itself, will lay the foundation for other tests

- Is based on clearly defined features, functions, or requirements

- Has some property that will clearly demark it from other tests, it is mutually exclusive

- Can be understood both by the engineer and is relevant to his domain knowledge and can be executed by the simplest personnel with full confidence in understanding the results

- Can be run under all predefined architectural boundaries as well as hardware boundaries

- Clearly measures as well as reports a result. There is no ambiguity about the results or the measure.

- Most importantly, on failure, it will generate an actionable result which insures that its failure is addressed – bug, design change, schedule modification, etc...

So, building test cases really comes down to the simplest of concepts. Understanding your feature well enough and with enough detail such that when you look over your test cases, you have a high degree of confidence that you mitigated customer risk and provided your staff with a well defined set of criteria by which they can assume they have done their job. Good engineering is a team effort, the role of you or the person developing test cases is engagement and building confidence in how you test. This will go far in helping bring a high quality product to market.

Test case development by far is non-trivial, requires special knowledge about software, and also about software environments. These can range from hardware to operating system, and are not unique to Windows. It is essential that test personnel be experts in both disciplines in order to be successful. You cannot hope to succeed in testing software without strong knowledge in both software development as well as the execution environment. There are ample well documented examples whereby this was not adhered to and disastrous results ensued.

Here are some books I have read on the subject, of course, each are examples and not my final word on the subject. Also, I am not paid to advertize these and I’m sure that you can find more relevant documentation that will help you if you are struggling with test case development. Note, I mix and match between MS Press and others, so as not to appear biased, however, “How We Test Software at Microsoft” if anything, should open your eyes to the systematic and sometimes frustrating process we go through bringing quality to our products.

Essential Software Testing: A Use-Case Approach by Mike Fornier

How We Test Software at Microsoft by Alan Page, Ken Johnston

Software Test Automation: Effective Use of Test Execution Tools by Mark Fewster

Testing Computer Software by Cem Kaner Jack Falk Hung Q. Nguyen

Testing Object-Oriented Systems: Models, Patterns, and Tools by Robert V Binder

-Hazel

Technorati Tags: XPe,Standard 2009

WMI Command-line Tool is not Completely Localized in Std 2009

2009-10-30T02:33:33Z

The Windows Management Instrumentation Command-line tool is not completely localized because the file CLIEGALI.MFL for the appropriate MUI language is not brought into the runtime when it is built in Target Designer. This is the file that defines the localized WMI namespace root\cli\MS_xxx, where xxx is the LCID for a language (e.g. 411 for Japanese). This file, for every language, does exist in the repositories but is not owned by any component.

To solve this problem copy the file (for the specific language you need) from the embedded repositories to the runtime, and place it under %Windows%\MUI\Fallback\<LCID>.

If wmic.exe has been run at least once it gets a little more complicated. When you run wmic for the first time, it compiles its MOF and MFL files (Cli.mof, Cliegaliases.mof, and Clialiases.mfl, etc), which get written into the WBEM repository (%WINDOWS%\system32\wbem\Repository) along with MOF/MFL files from other WMI providers. To resolve the problem in this case:

1. Copy the file over to the XPe device and then

2. Compile CLIEGALI.MFL after copying it to the runtime as follows:

Open a command window and run the following command:

mofcomp %Windows%\MUI\Fallback\<LCID>\CLIEGALI.MFL

- Lynda

Technorati Tags: XPe

Adding Custom Files And Creating an IBW Disk in Windows Embedded Standard 2011

2009-10-26T18:27:49Z

Note: The content in this blog is for users who are familiar with using Image Configuration Editor (ICE) to create a fully resolved answer file. If you would like to learn how to create a fully resolved answer file, please refer to this blog article.

ICE provides easy ways to add custom files to your Windows Embedded Standard 2011 image and generate a bootable IBW Disk. This blog article explains how these are done in ICE.

If you’ve chosen to install the Windows Embedded Standard toolkit with Typical option, you should find the DS in <Root Drive>\Program Files\Windows Embedded Standard Windows Embedded Standard 2011\DS. In the DS, there is a folder called “$OEM$ FOLDERS”. From Windows explorer, create a folder structure MyApps\$OEM$\$1\App1 as shown below.

In the App1 folder, add the files you’d like to be in the final image.

In ICE, you will be able to see the “MyApps” folder that you’ve added in the DS pane. Right click on it and select “Insert Oem Folders Path”

The focus should jump to the Settings pane. You will see that the OEM folder has been added to the answer file as a setting, as shown below. Validate and save the answer file.

Now that you have generated an answer file that contains your OEM folder information, it’s time to create a Windows Embedded Standard 2011 image with your files in it.

One convenient feature in ICE is the ability to create a bootable installation disk that contains all of the packages and files added to the answer file. You can use this bootable disk to boot from your target device, go through a few prompts and have your Windows Embedded Standard 2011 image installed on your device!

Let’s create the IBW Disk now. From the Tools menu, select Media Creation | Create IBW Disk From Answerfile as shown.

The IBW Disk dialog box is displayed.

Select the answer file you saved and specify a folder location for the IBW Disk content to be created. When it’s finished, you will see the bootable disk content created in the folder you specified. This folder contains the custom files that were added to the answer file. Copy all of the content inside this folder to a bootable USB drive and you’re ready to begin installing the image to a target device!

- Ivan

Technorati Tags: XPe,Quebec,CTP

Robert talks about Image Based Wizard (IBW)

2009-10-21T18:12:00Z

If you haven’t had a chance to read through Robert’s blogs on Image Based Wizard (Part 1, Part 2) introduced in Windows Embedded Standard 2011, here is a short cut -

I quickly interviewed Robert the other day. He talked about what IBW is designed for, what the key functionalities are and how to use it, etc. The video is about 9 minutes long, with the last few minutes where Robert demos an end-to-end IBW experience. Enjoy it.

Robert Smith Talks about IBW

Weijuan

Installing VS2005 or VS2008 redistributable files on Windows Embedded Standard 2009

2009-10-20T16:00:00Z

There have been several forum posts about including the redistributable files for Visual studio 2005 or Visual Studio 2008 in a runtime image so that applications built using these versions can run. Windows Embedded Standard 2009 database does not have componentized versions of the redistributable files for these versions of VS. The easiest way is to include the redist files as part of the application during development. If you are not the developer of the application then there are a few options.

You could create a new component with an FBA Generic Command that calls the redistributable package installer during FBA. You should set the FBA phase to between 8500 and 12,000 so that it runs later in the FBA sequence. If the redist package supports a quiet flag, and a silent install is desired, specify the appropriate switches in the Arguments property of the FBA Generic Command, such as

“%11%\cmd.exe” for FilePath and

“/c <path>\vcredist_x86.exe /q” for Arguments property.

Calling the redist executable directly will fail. You could just as easily do a RunOnce command in a new component, but an FBA Generic Command provides more control over the order that this command will run, especially if you have other components that are also doing custom actions during FBA.
You could also componentize the redist installer, which requires breaking the setup apart into the associated files and registry data and creating a component containing those resources.

- Lynda

Technorati Tags: XPe,

BitLocker in Windows Embedded Standard 2011

2009-10-19T20:13:00Z

In this blog article I will be talking about a new security feature in Windows Embedded Standard 2011 (“Quebec”). This security feature has been part of Windows Operating System since Vista timeframe. I will touch upon the usefulness of this feature. The main idea of this article is to go over the procedure of adding this package to your image and using it afterwards.

BitLocker in Windows Embedded Standard 2011 – Overview

Windows BitLocker Drive Encryption (BitLocker) is a new security feature that provides better data protection for your device by encrypting all data stored on the Windows Embedded Standard 2011 operating system volume. BitLocker allows an admin of a machine to encrypt volumes to protect data contained on them.

A Trusted Platform Module (TPM) is a microchip that is built into a device. It is used to store cryptographic information, such as encryption keys. Information stored on the TPM can be more secure from external software attacks and physical theft.

BitLocker has three possible modes; two need a TPM and a compatible BIOS, the 3rd does not require a TPM.

1. TPM only: BitLocker uses the TPM to provide a transparent user experience. The machine boots, and the user logs on as normal. The encryption key for the drive is stored in the TPM and only given to the boot loader if the boot files and BIOS have not been tampered with.

2. TPM + Token: The user needs to provide some additional authentication to the TPM/OS Loader - either a PIN entered manually at each boot or a USB key.

3. USB Key: BitLocker can also be used without a TPM. When BitLocker is used without a TPM, the required encryption keys are stored on a USB flash drive that must be presented to unlock the data stored on a volume.

Other points to note: BitLocker can be controlled via Active Directory (AD) as well. In this case, AD schema must be extended to support this. To control TPM recovery from AD, permission on computer class object in AD must be changed. To back up recovery information for TPM and BitLocker on AD, you will need to enable “Turn on BitLocker backup to Active Directory Domain services” via group policy management console.

Pre-requisites for BitLocker

BitLocker requires the user’s computer to be configured with at least two partitions. Partition A (the system partition) contains boot critical files and must remain unencrypted. All other partitions may be encrypted by Bitlocker.

System partition is a small 100MB partition that will co-exist with OS partition. To create this small unencrypted partition, the user could use diskpart (or disk preparation tool). This volume must be different than the OS volume.

If you add BitLocker package via IBW, this 100MB system partition is automatically created by IBW.

Adding BitLocker to your image

We realize that Windows Embedded customers care a lot about the amount of disk space their image requires. The small unencrypted 100MB partition is added to the Windows Embedded Standard 2011 image only to better support BitLocker. Hence, by default, your image will not create this system partition unless the BitLocker package has been selected to add to your image.

You could add BitLocker to your image when running Image Builder Wizard IBW setup or to your answer file created using Image Configuration Editor (ICE).

The screenshot below shows the packages you need to select when building an image using IBW

Screenshot below shows the packages you need to select when creating an answer file using ICE.

Enable BitLocker

BitLocker can be enabled one of the two ways – via command-line interface (CLI) or via GUI. You can use Windows Management Instrumentation WMI classes to manage either way. Also, you can write WMI scripts to manage BitLocker and TPM. This approach is especially useful in cases of headless devices (devices that don't have display output).

For more information on the WMI provider classes, please click on the following links:

· To manage BitLocker – http://msdn.microsoft.com/en-us/library/aa376483(VS.85).aspx

· To manage TPM - http://msdn.microsoft.com/en-us/library/aa376484(VS.85).aspx

Again, when enabling BitLocker, there are two main scenarios to consider. Both of those scenarios are outlined below.

1. Enabling Bitlocker on hard drive.

a. BitLocker with TPM (note that BitLocker requires TPM chip 1.2):

- Verify that all TPM drivers are loaded; Ensure that TPM is enabled in BIOS before running setup of Windows Embedded Standard 2011;

- Initialize TPM (either using WMI scripts or Microsoft Management Console MMC snap-in);

- Take ownership of the TPM;

- Save the TPM key (AD could be used to back up this TPM recovery information); and Now run manage-bde on the hard drive to turn on Bitlocker

b. BitLocker without TPM:

- Run manage-bde to turn on Bitlocker

2. Enabling Bitlocker on USB drive

This is the same as turning BitLocker on for the hard drive – when running manage-bde, you can specify the disk you want to encrypt via BitLocker. Run Manage-bde with “-status” switch to check status of various drives available and their corresponding encryption status.

BitLocker To Go (BTG)

Loss of confidential data via a removable drive costs the industry and governments billions of dollars every year, not to mention the resulting inconvenience. Windows Embedded Standard 2011 includes a new feature known as BTG that provides the ability to encrypt removable storage devices, such as USB drives, making sure the data is secure in case the device is lost or stolen. BTG encrypted drives can be unencrypted using a password, smart card or specific machine automatically. IT administrators can configure policy that mandates BTG encryption to grant write access to a removable disk.

Using BTG is really easy. Once your USB device is inserted and has been recognized by your device, go to the control panel and access BitLocker Drive Encryption.

Screenshots below are examples of enabling BTG when inserting a USB flash drive.

Once you insert the USB flash drive, go to the explorer shell and right click on the USB drive (F:\, for example) and select “Turn On Bitlocker”. You will get a screen as shown below:

At this point you could select a method to unlock this drive post encryption. I select password to unlock drive.

I get the next screen.

Here I can either save the recovery key to a file or print the recovery key. I recommend saving it to a file, which is more secure than printing it.

Browse to a location you want to save this key and then start encrypting.

- Hema

Reminder: Third Webinar on Windows Embedded Standard 2011 is on Monday

2009-10-16T15:28:00Z

This is a reminder that on Monday, Oct 19 the third technical webinar in our series on Windows Embedded Standard 2011 will be held. The details are:

Date: October 19, 2009
Event Start Time: 11:00 AM Pacific Daylight Time (UTC - 7 hours)
Duration: 1 hour

Join this one hour webinar to experience servicing in Windows Embedded Standard 2011. During this session you will learn how Windows Embedded Standard 2011 is maintained and updated and watch demonstrations of servicing features in action.

You can register for this webinar here. To get a head start download the Community Technical Preview build from here.

If you cannot watch the webinar live then still register as the session will be recorded and will be available to registered attendees a few hours after the webinar ends.

Enjoy!

- Lynda

Technorati Tags: XPe,Embedded,Standard 2009,Standard 2011,CTP

Quality Control for Windows Embedded Standard 2011 Drivers

2009-10-15T20:08:00Z

One of the nice features of Windows Embedded Standard 2011is that we have the same drivers available as Windows 7. That means that we have a wide range of drivers available (500+), and the drivers have gone through extensive testing with the Windows team. For Windows Embedded Standard 2011 we want to give our customers the flexibility to set up their runtimes with the drivers they want. To accomplish this, most of the drivers are packaged separately from the base Windows Embedded Standard 2011image (called eCore), allowing the user to add them to the image as they wish. The base image does come with some drivers, but only drivers necessary for the critical operations of the computer. For testing drivers in Windows Embedded Standard 2011,we can’t duplicate all of Windows team’s testing. We do want to run test cases in all of the main test categories, but mostly we want to focus our testing on the areas where Windows Embedded Standard 2011differs from Windows 7.

For instance, in Windows Embedded Standard 2011the customer can add or omit the features they chose, so the runtime environment can be vastly different than the original Windows 7 environment the driver was built for. An issue arises if the driver has a dependency on a service, file, registry key, etc. that wasn’t added to the runtime. In order to mitigate this problem we’ve analyzed the dependencies for each driver. If a driver has a dependency on a feature not included in the base image, then that information is added to the metadata of the driver packages. That way whenever you select a driver package you will know if any other packages are required to make the driver work. Since the base Windows Embedded Standard 2011 image is designed to be a self contained working unit, the drivers in it don’t have dependencies outside of the image. But we don’t just rely on the dependency analysis; we also do runtime checks for dependency issues. To that end, our testing is predominantly done with the minimum features added. We also leverage the testing done by the feature teams and run various customers scenarios to give us greater coverage.

Another area that differs somewhat from Windows 7 is the installation of the driver packages. While we use many of the same components as the Windows 7 desktop operation system, we build our own packages and often add them to an image in greater numbers. You can install driver packages either through setup or on the runtime. When installing with setup you can select specific drivers to install by using an unattend file, or you can use setup’s driver automapping feature to match drivers to your devices automatically. After a Windows Embedded Standard 2011install, you can add a package either online or when booted into WinPE 2.0 from another drive. Every installation method is tested, but there are also different stages to verify. We have to check the ‘package’ installation, which is basically about verifying where files are placed onto the image. Then there is the second way of installing drivers, in which Windows 7 components within Windows Embedded Standard 2011 match drivers to devices, and then install the drivers. We verify that the driver is running without any errors, and then extend that testing with our feature set testing. Also, we address the fact that customers will add multiple packages at once, so we stress the system with the maximum packages available. Lastly, we test whether the driver package can be updated.

As mentioned previously, we build our own driver packages, so we have to make sure that the payload is correct and the metadata included is correct. If the packages aren’t well formed, that could impact installation, setup’s driver automapping feature, package dependency resolution, or servicing of packages. In each package there is a deployment manifest, an update manifest, the driver installation file, and the files needed by the driver. The files with the metadata in them contain interconnected data, build data, and installation data that has to be verified. We also have build files associated with these packages that help determine things like what packages we have, or what language resources are available. Automation is used to verify all of these factors on a daily basis. Plus, we supplement the package verification with our installation testing mentioned above.

So we’ve mentioned what we look for in the differences between Windows 7 and Windows Embedded Standard 2011, but we also test the more typical test areas. Some of the other categories we test are Ad hoc, HW coverage, Performance, Stress, Application compatibility, Integration testing, and Language testing. We try to leverage the Windows team’s tests whenever possible, but we also build test cases and automation whenever we need to get the appropriate coverage for a test area.

- Brent

Suppressing Beeps on a Windows Embedded Standard 2009 Device

2009-10-13T16:18:00Z

In certain instances you may not want the embedded device system to beep when an event occurs or those associated with message boxes popped up by the system or user applications. In these cases you can add a registry key to suppress this beep, namely:

HKEY_CURRENT_USER\Control Panel\Sound\

Beep REG_SZ Value=yes

ExtendedSounds REG_SZ Value=yes

This registry key was not originally included in the Windows API - User component. It is often preferred that the system does give an indication by means of beeping that it is running smoothly. If you do want the system to beep you would also need to include the Beep Driver component in your image. This component is also a required dependency for many touch screens.

- Lynda

Creating Fully Unattended (“Hands-Free”) Setup and Deployment of Windows Embedded Standard 2011

2009-10-12T20:15:00Z

PLEASE NOTE: The settings described in this article apply to Windows Embedded Standard 2011 CTP. The required settings may change slightly for the release to manufacturing (RTM) version of Windows Embedded Standard 2011, but for the most part the approach outlined in this article should apply to the RTM release.

One very common scenario for users of Windows Embedded Standard 2011 is to develop a completely unattended, or “hands-free”, setup. In this scenario, a Windows Embedded Standard 2011 image can be created on a target device without a single human interaction once the Setup program has been properly started (and even this can be automated with the help of a well-crafted autorun volume). For this article, a fully unattended setup will result in the target device auto logging in and reaching the desktop.

In order to help you achieve this scenario, I will touch on the different components and stages of the setup process. From a very high level, an unattended setup of Windows Embedded Standard 2011 is achieved by providing answers to every question that the setup process has. If Setup has answers to all of its different questions, then there will be no need for a UI to ask a human what to do. These answers will be provided to Setup in the form of an unattend (a.k.a. “answer”) file. This unattend file is an XML file either created by the Windows Embedded Standard 2011 Image Configuration Editor (ICE) or by hand for those who prefer.

The image below illustrates the setup process from first launching Setup, to the logon screen, from left-to-right.

One important thing to consider about Windows Embedded Standard 2011, Windows 7 and Vista, is that the setup process takes place in multiple configuration passes. There are seven distinct setup passes:

WindowsPE
Offline Servicing
Generalize
Specialize
Audit System
Audit User
Windows Out of Box Experience (OOBE) System

Each of these phases has its own role, and different Settings Management Infrastructure (SMI) settings can be applied in one or more of these phases (for more information, see the following KB article: How Configuration Passes Work). From a high-level however, I like to think of these phases as falling into two categories: phases that take place with the Windows Embedded Standard 2011 image running, and phases that take place when the Windows Embedded Standard 2011 image is not running. These two phases are referred to as online and offline respectively.

The figure above shows how the setup process is broken down into the offline and online stages. When you run Setup, there are several questions that it is going to ask: what language to use, what features to install, where to install them, etc. Once the Setup process has completed, your device will restart, the image will switch to the online oobeSystem phase, and the OOBE will start. OOBE looks and feels like Setup, but the following should be considered:

OOBE is not part of IBW (Setup)
OOBE runs online, during the oobeSystem phase
OOBE will always run after Setup or when an image is deployed

So, in order to achieve a completely unattended setup of Windows Embedded Standard 2011, we need to provide all the answers that both IBW (Setup) and OOBE need. If this is achieved, then we can simply launch Setup and have the image setup progress all the way through to the OOBE, and finally to the desktop.

Below is a list of all the settings that need to be used. These settings are organized into two categories: IBW (Setup) and OOBE settings. Users familiar with the SkipMachineOOBE setting may want to use this setting to bypass the OOBE UI instead of providing all the OOBE SMI settings. This setting is deprecated and only included for testing. It is advised that an answer file that contains all the necessary OOBE SMI settings be used for unattended deployment. Also consider that using SkipMachineOOBE will lead to images that have not had their EULA accepted, and will not have any user accounts created, potentially leaving the final image in an unusable state.

Unattended Setup SMI Settings

Below is a list of all the SMI settings required to achieve unattended setup of Windows Embedded Standard 2011 CTP. Please note that these settings may change for the RTM release of Windows Embedded Standard 2011. These settings have been divided into three sections:

Image Build Wizard Unattend Settings
OOBE SMI Unattend Settings
Auto Logon Unattend Settings

Image Builder Wizard Language and Locale Settings

Setting	ConfigURATION Pass	Description	value
International-Core-WinPE \| InputLocale	P1 WindowsPE	Specifies the default language to use on the installed Windows operating system.	“en-US”
International-Core-WinPE \| SetupUILanguage \| UILanguage	P1 WindowsPE	Specifies the default language to use during Windows Setup. During installation, Windows Setup displays installation progress in the selected language.	“en-US”
International-Core-WinPE \| SetupUILanguage \| WillShowUI	P1 WindowsPE		Never
International-Core-WinPE \| UILanguage	P1 WindowsPE	Indicates the language of the user interface to use during Windows Setup or Windows Deployment Services.	“en-US”

Image Builder Wizard Dialog Boxes

Setting	Configuration Pass	Description	value
Setup\| FeaturePackageSelection \| ShowUI	P1 WindowsPE	Specifies whether to show the IBW feature package selection page or not.	False
Setup\| Target Analysis Mapping \| RunTargetAnalysisMapping	P1 WindowsPE	Specifies whether to run TAP.exe and map the .pmq file to driver packages or not.	True
Setup\| Target Analysis Mapping \| ShowImportDriverUI	P1 WindowsPE	Specifies whether to show the IBW import driver UI page or not.	False
Setup\| Target Analysis Mapping \| WillShowUI	P1 WindowsPE	Specifies whether to show the IBW Target Analysis Mapping pages or not.	Never
Setup \| UserData \| AcceptEULA	P1 WindowsPE	Specifies whether to accept Microsoft License Software Terms during IBW.	True

Image Installation

You must specify where you intend to install Windows. You can either specify the exact disk ID and partition ID, or you can install Windows to the first available partition.

Setting	Config. Pass	Description	Possible value
Setup \| ImageInstall \| OSImage \| InstallToAvailablePartition	P1 WindowsPE	Specifies installing Windows on the first available partition.	true

-or-

Setting	Configuration Pass	Description	Possible value
Setup \| ImageInstall \| OSImage \| InstallTo \| DiskID	P1 WindowsPE	Specifies the disk where you want to install Windows Embedded Standard 2011.	0
Setup \| ImageInstall \| OSImage \| InstallTo \| PartitionID	P1 WindowsPE	Specifies the partition where you want to install Windows Embedded Standard 2011.	1

OOBE SMI Settings

Providing all of the settings listed below in your answer file will result In the OOBE UI being suppressed during setup/deployment. Note that if you are trying to achieve unattended OOBE on an image that you intend to capture and deploy, you will need to provide the path to your answer file to sysprep when you generalize your image before capturing for deployment. For more information, see the article How Sysprep Works, and the section “Using Answer Files with Sysprep”.

Setting	ConfigURATION Pass	Description	Possible value
International-Core \| InputLocale	P7 OOBE System	Specifies the default input locale of the Windows installation.	“en-US”
International-Core \| SystemLocale	P7 OOBE System	Specifies the default system locale of the Windows installation.	“en-US”
International-Core \| UILanguage	P7 OOBE System	Specifies the default UI language of the Windows installation.	“en-US”
International-Core \| UserLocale	P7 OOBE System	Specifies the default user locale of the Windows installation.	“en-US”
Setup \| UserData \| AcceptEULA	P1 WindowsPE	Specifies acceptance of the EULA.	True
Shell-Setup \| ComputerName	P4 Specialize	Specifies the name of the computer to apply to the Windows installation.	“*”
Shell-Setup \| ProductKey	P4 Specialize	Specifies the product key to use for activation.	A valid product key (or test key) in the 5x5 format. Product_key is a 29-character string, for example: AAAAA-BBBBB-CCCCC-DDDDD-EEEEE For Windows Embedded Standard 2011 CTP Evaluation purposes, use of an “all-zeros” product key will be accepted: 00000-00000-00000-00000-00000
Shell-Setup \| TimeZone	P7 OOBE System	Specifies the time zone of the computer.	“Pacific Standard Time”
Shell-Setup \| OOBE \| HideEULAPage	P7 OOBE System	Hides the Microsoft Software License Terms page.	True
Shell-Setup \| OOBE \| ProtectYourPC	P7 OOBE System	Specifies the protection level of the Windows installation.	3
Shell-Setup \| OOBE \| NetworkLocation	P7 OOBE System	Specifies the location of the computer.	“Work”
Shell-Setup \| OOBE \| HideWirelessSetupInOOBE	P7 OOBE System	Hides the Wireless Network selection page.	True
Shell-Setup \| UserAccounts \| LocalAccounts	P7 OOBE System	Specifies the user accounts to create on the Windows installation.	Right-click to insert a new local account
Shell-Setup \| UserAccounts \| LocalAccounts \| LocalAccount \| Name	P7 OOBE System	The name of the account to create.	Any valid account name that is not already present in your image, for example: “User1”
Shell-Setup \| UserAccounts \| LocalAccounts \| LocalAccount \|DisplayName	P7 OOBE System	The display name for a local account.	Any valid user name that is not already in your image, for example: “User One”
Shell-Setup \| UserAccounts \| LocalAccounts \| LocalAccount \| Password \| Value	P7 OOBE System	The password of the account created.	Any valid password
Shell-Setup \| UserAccounts \| AdministratorPassword \| Value	P7 OOBE System	Configures the Administrator account password.	Any password string

Auto Logon Settings

Providing the settings below will result in your final image automatically logging on when booted. The account referenced in this section must match the account created in the Shell-Setup | UserAccounts | LocalAccounts section.

Setting	Config. Pass	Description	Possible value
Shell-Setup \| AutoLogon \| Username	P7 OOBE System		User name created for OOBE
Shell-Setup \| AutoLogon \| Enabled	P7 OOBE System		True
Shell-Setup \| AutoLogon \| LogonCount	P7 OOBE System		1 ~ UInt32 MAX
Shell-Setup \| AutoLogon \| Password \| PlainText	P7 OOBE System		true or false
Shell-Setup \| AutoLogon \| Password \| Value	P7 OOBE System		The same password used for this user account created under the Shell-Setup \| UserAccounts node

Here are some things to consider from this list:

1) Setup | UserData | AcceptEULA: Consider who you’re accepting this EULA for. If you’re the end user of the device, this is acceptable, but you wouldn’t want to accept the EULA if you’re not the end user.

2) Shell-Setup | ComputerName: By setting this to a value of “*”, Setup will assign an algorithmic machine name to your target device. The intention of this is to provide a unique machine name to your target device during setup/deployment, which can later be changed after setup/deployment.

3) Shell-Setup | ProductKey: A valid product key will be required for this setting. For the Windows Embedded Standard 2011 CTP, an “all-zeros” product key will be acceptable: 00000-00000-00000-00000-00000

4) Shell-Setup | OOBE | NetworkLocation: The OOBE has different execution paths depending on this setting. Setting this value to “Home” will bring you down a code-path that cannot be suppressed with an answer file. Be sure to set this value to “Work”.

It is clear from this list that there is a significant amount of settings required to achieve a completely unattended setup in Windows Embedded Standard 2011. Keep in mind that these settings can be configured in various ways to fit your specific goals. By using other SMI settings you can do things such as have the device automatically join a domain, use domain accounts instead of local accounts, name the device, etc. Experiment with these settings to find the combination of settings that meet your goal. Although there are a lot of settings, the flexibility is very powerful. Also, keep in mind that most of the SMI settings available for use when setting up, deploying, or servicing a Windows Embedded Standard 2011 image are identical to Windows 7 settings, so be sure to leverage the Windows 7 documentation for these settings.

- Peter

Technorati Tags: XPe,Embedded,Standard 2009,ICE,IBW

Importing Packages to the Distribution Share

2009-10-08T22:31:15Z

In Windows Embedded Standard 2011, the Distribution share (DS) is a critical element in creating customized Windows images. If you have used Image Configuration Editor (ICE), you would have noticed that packages are well organized into a tree structure that represents the DS. During development, users might need to use other packages in addition to the ones already found in the DS. Examples include new package releases from the Windows Embedded team (security updates, hot fixes, new versions of the same package, etc...) as well as 3^rd party supplied packages (e.g. 3^rd party driver packages).

Windows Embedded Standard 2011 allows you to maintain the DS (for example you can add a new driver package or an update package) by using one of the supplied utilities that come with the Stnadard 2011 tools, importpackage.exe. This tool enables you to:

Create a DS.
Add package(s) to a DS: Language, Feature, and Driver packages exist usually as .cab files. And ecore is usually packed into an install.wim file, which can also be imported using the import package utility.
Rebuild the index file of a DS, a major functionality of utility in maintaining the DS. In addition, rebuilding the DS index file can be indirectly used to remove some packages from a DS

Note that the import package utility can be called in two ways:

Using the command line importpackage.exe binary where you can perform all of the functions mentioned above.
Using the ICE user interface. However, it is important to mention here that within the ICE user interface only the .cab package addition functionality is currently supported for ImportPackage.
In this blog posting we will go through a step by step process for importing a package into a DS by using the ICE user interface.

The first step is to open ICE and then open the distribution share, in this example I chose to open the x86 DS that is supplied with Windows Embedded Standard 2011:

To import a package go to File->Import->Import Package(s), or you can do this by right clicking on the first node in the DS pane and then pressing on Import Package(s) as shown in the figure below:

Now you can select which package (.cab) files you would like to import into the DS. There are two methods for selection:

Select a single .cab package file and click on “Open” to import one package into the DS.
Select a folder and click on “Open Folder” to import all the package .cab files that are in that folder or its subfolders into the DS.
Make sure that the .cab package architecture matches the DS’s architecture. Cross architecture imports are not allowed (e.g. importing an x86 driver package into a 64-bit Distribution share)

In this case, I have chosen the “Open Folder” on the MyUpdatePackages folder to import the two update packages:

WinEmb6.1-KB600020-x86.cab, and WinEmb6.1-KB600021-x86.cab.

A status bar will be shown, and when the import process is complete ICE should display the following message:

Press on “Yes” and the DS view is refreshed to show the imported packages in the list as shown below:

Now, the imported packages can be added to an answer file to be included in an image.

More general information on Windows Embedded Standard 2011 tools can be found in this blog: Introduction to the Windows Embedded Standard 2011 Toolkit

Thanks,

-Sami

Technorati Tags: XPe,Standard,Embedded

Save Time with Snapshots

2009-10-05T19:59:41Z

As PC users & developers, we are faced with situations where we want to save the current state of the operating system along with its applications. One such situation is when developers have to reproduce a bug in the system/application that is hard to recreate or that occurs only occasionally. The Snapshot feature in Hyper-V is a developer’s dream in this regard- capable of saving the current state of the OS and its applications. Later, a dev can choose to restore to the saved state as many times as possible to work on the hard-to-create OS/Application state.

PC users & developers can now play with installing different applications, tweaking some system settings, editing the registry and easily go back to the previous state of the OS with the cool snapshot feature.

Here are a few scenarios where snapshots are quite handy for Windows Embedded Standard 2011 Developers:

Debug the failing OS Installation

This is not a tip for debugging itself, but helps save some time with debugging the failing OS installation. If the OS installation fails after the first reboot or during the OOBE phase, a significant amount of time has already been spent. Create a snapshot after the last successful reboot and try to debug the failure rather than installing the OS again and again to recreate the failure.

Play with Windows Embedded Standard 2011 Packages
- Launch Hyper-V
- Boot into WinPE image
- Install the Windows Embedded Standard 2011 Operating System with the required set of packages (IBW / Unattend Setup)
- Create a Snapshot for the current State of OS
- Install any application
- If the installation fails, use Dependency Walker, procmon, procexp or other tools to find the missing dependencies and corresponding package
- Use the DISM tool to install the package and restart the machine if needed
- Install the 3rd Party application again, and if installation succeeds, create a second snapshot to mark the new milestone
- If something strange happens recover to the previous state (with the saved snapshot)

Debug an application which fails only at first launch after installation

There are some applications which show an error only the first time the application is launched after installation. This problem can be solved by uninstalling and reinstalling the application. If the application is huge or has settings spread all across the registry, uninstall - reinstall is not the recommended approach; Rather, snapshots are the easiest way to get to the failure point. Install the OS and install the application that has a failure. Create a snapshot first, then launch the application. If you lose track while debugging, you can easily get to the same state with the saved snapshot.

Debug hard-to-create scenarios

Windows Embedded Standard 2009 developers may have faced hard-to-recreate bugs that take many hours to reproduce. . Snapshots provide a great solution for this situation. Once the reproduction happens, save the state of OS. Developers now have infinite number of chances to start debugging the problem from the same state.

Save the special state of a database

Sometimes an application requires setting up a database server with test data. The application can then execute scripts on the test data or change the test data during the development cycle. By taking a snapshot of the database server after loading the initial test data, the test cycle can easily start testing with the original data. The same technique is also useful in advanced applications with a lot of configurations settings. It is recommended that you take a snapshot after successful configuration settings. This snapshot provides a handy backup if the application configuration fails in the future.

There are many scenarios where snapshots would be a good time saver, and all it takes to use this snapshot feature is just a click of a button in the toolbar. Hopefully we can save you time with Snapshots.

- Saravanan

Technorati Tags: XPe,Quebec,Standard

Second Webinar on Windows Embedded Standard 2011 is on Monday

2009-10-02T18:22:00Z

This is a reminder that on Monday, Oct 5 the second technical webinar in our series on Windows Embedded Standard 2011 will be held. The details are:

Date: October 05, 2009
Event Start Time: 11:00 AM Pacific Daylight Time (UTC - 7 hours)
Duration: 1 hour

Build an embedded image with the Windows Embedded Standard 2011 (formerly codenamed "Quebec") toolkit. This session will teach you basics of building an embedded image and the fundamentals needed to effectively use the Standard 2011 toolkit. Windows Embedded Standard 2011 is the Windows 7-based version of the Windows Embedded Standard platform, a componentized version of Windows for embedded systems and devices.

You can register for this webinar here. To get a head start download the Community Technical Preview build from here.

If you cannot watch the webinar live then still register as the session will be recorded and will be available to registered attendees a few hours after the webinar ends.

Enjoy!

- Lynda

Technorati Tags: XPe,Embedded,Standard 2009,Standard 2011,CTP

Image Configuration Strategies

2009-10-01T20:00:00Z

[The following article is authored by one of the Windows Embedded MVPs (Most Valuable Professionals). Our MVPs have a heavy background in Embedded systems and are a great repository of information on Windows Embedded products. We’re providing this space on our team blog as a service to our readers by allowing MVPs to share some of their knowledge with the rest of the community.]

If one is building just a single device, it is certainly not necessary to think about configuration strategies. However, when the device gets rolled out in different versions or if your device is part of a device family, a well designed configuration strategy can help overcome versioning obstacles and save a lot of time.

Separate hardware and software

The simplest image configuration strategy is to separate the hardware and software related parts of the Windows Embedded Standard image. Ideally this is done with the help of macro components. In this case there would be one macro component containing components such as generated by TA/TAP and drivers. All other components, which are not related to accessing hardware, should be placed in a software macro component.

This approach is especially beneficial if you want to have the same image infrastructure configuration across different hardware boards requiring different drivers and HALs.

The dream of a global embedded image

Just a minute – one could say, why not instead create an “Über-Image” that contains all available drivers and HALs? It would be slightly larger than a standalone one, but this would be no problem from a footprint standpoint if you think of the price of storage today. The benefits of maintaining a single image would easily outweigh this footprint drawback.

HAL – the lonesome component

Well, “Über-Images” are possible, but only if all targeted devices support the same HAL. There cannot be more than a single HAL in an image configuration. In reality it is a lucky accident if all target devices support the same HAL. And even then, there is a good chance that a new round of HW evolution will break this. Therefore, having different HW macros for different systems cannot be avoided in most cases.It is also common that different boards require completely different drivers and therefore HAL and drivers can be grouped together in their own macro component.

Drivers, apart from the HAL, on the other hand, should not pose any problems if you do decide to keep all an “Uber-image” that contains them. During FBA the Plug and Play process installs only the required drivers from the offerings available in the raw image. Surplus drivers stay on the disk, but are not installed into the run-time.

Grouping software components

If you take the simple approach described above for drivers, namely creating an “Uber-Image” for software, you would be left with one monolithic software macro component. If a device family gets more sophisticated, there might be the need to take a more flexible approach, as well. The software macro component could be broken e.g. in a component containing OS facilities and one containing the application or applications.
This idea could be further developed by encapsulating certain functionality or application blocks. Quite often macro components Microsoft already has built can be reused for certain infrastructure parts such as networking, multimedia, WMI, Active Directory, Group Policies, etc.

To find an ideal approach certainly is not easy, and is also directly related to an OEM’s device requirements. The resulting custom functionality macros should also not be too granular, because maintaining them could become quite some work over time, as well.

Selector Prototype Component

A way to add more flexibility to a custom macro component is to add a membership to the Selector Prototype Component, which generates a list of the component dependencies that can be selected or de-selected during image configuration in Target Designer. This enables OS developers to choose which components of this macro to include in a configuration-specific way. When creating the macro component in Component Designer, the Selector Prototype Component can be configured in the components meta-data.

The component is located in the Software\Test & Development node of the catalog. There are more components available in the node, but only the one with the highest version number should be chosen. The reason for this is that outdated components are not deleted from the database, to enable the building of older image configurations if necessary.

If the Selector prototype has been added in a macro, continue to add the component dependency resources you need in the macro as for any other macro component Afterwards import the component into the database.
If a macro component with a membership on the Selector Prototype component is added to an image configuration in Target Designer, included components are shown in a select list similar to the one below (select list implemented by the WMI macro component):

Divide and conquer

With a meaningful segmentation of functionality, and flexible macro components, even complex device family scenarios can be handled. The skill here is to set the right level of functionality boundaries to offer proper choices when device requirements are considered, while having not too many macros to maintain.

In addition, component configuration files (SLDs) should be stored in a source code repository to enable better collaboration, handling and versioning.

- Alexander

Alexander Wechsler

Wechsler Consulting

www.wechsler-consulting.de

Technorati Tags: XPe,Standard 2009