Windows Embedded Standard (NT4e, XPe and beyond)

Overcoming an Error When Using IPSECCMD SHOW GPO on Standard 2009

Embedded — Tue, 09 Feb 2010 18:45:00 GMT

The IPSecurity Services component in XP Embedded and Windows Embedded Standard 2009 is normally only configured dynamically in certain scenarios involving Domain Participation and Active Directory. In some instances it has been reported that when IPSECCMD SHOW GPO is used, the following error results:

“error 2 The system cannot find the file specified.”

The problem is due to the following registry key being present in the XPE IP Security Services component:

"SOFTWARE\\Policies\\Microsoft\\Windows\\IPSEC\\GPTIPSECPolicy", but with no values associated with it.

An example of how this key’s values are normally populated (with sample values) is:

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\IPSec\GPTIPSECPolicy]

"DSIPSECPolicyPath"="LDAP://CN=ipsecPolicy{1252bb1d-3253-476d-a468-c1ee6b3043cc},

CN=IP Security,CN=System,DC=mydomain,DC=corp,DC=mycompany,DC=com"

"DSIPSECPolicyFlags"=dword:00000001

"DSIPSECPolicyName"="SecNet Simple Default Policy (1.05.070444)"

"DSIPSECPolicyDescription"="SecNet Simple Default Policy (1.05.070444)"

This key is not automatically present on an XP Pro desktop system so it can be inferred that it is not necessary to have this key be present on an XPe or Std09 system. Therefore, in the case of this error the issue can be fixed by either:

Populating it with the appropriate value keys for the environment the runtime is deployed in
Deleting the GPTIPSECPolicy key.

Obviously the usual degree of testing should be applied after using either solution, in order to verify that there are no unforeseen consequences later.

- Lynda

Technorati Tags: XPe,Embedded Standard

Creating a Template

Embedded — Sat, 06 Feb 2010 00:05:20 GMT

A while back JT talked about Application Templates for Image Configuration Editor and the resources and community that we’re building around them. I wanted to explain how to create a template for ICE and clarify any questions you might have.

Templates are functionally just like answer files, but are meant to represent some functionality or subset that you would like to have available or share to build upon. ICE can take these templates and merge them into the answer file you are currently working with, as well as export them to share with other people, like on our new Application Templates web page. This allows you to work with images at a higher level of abstraction, grouping things such as drivers needed for your various models of devices, flagship 3^rd party apps that have had their dependencies fully analyzed and tested, audio and visual packages needed for kiosk or gaming machine bases, etc.

To create a template, create an answer file as you normally would, then save it in the Templates folder (or any subfolder under it) of the distribution share in which you created it. The distribution share pane will then refresh and show your template in the pane.

Let’s start this walkthrough by downloading the various Windows Live templates from the Application Templates web site (x86):

Windows Live Toolbar
Windows Live Mail
Windows Live Photo Gallery
Windows Live Messenger

Extract all of these files, and then in ICE, choose File -> Import -> Import Template… from the menu and choose the one of the files, and repeat for each (sorry we didn’t make this multi-selectable!). Another option for importing simple standalone answer files is to simply extract them to the Templates folder in your DS. However, this doesn’t work with templates that have additional files associated with them, like OEM Folders, as we’ll see soon. You can also organize templates into subfolders as you choose, even after importing. I moved my templates into a subfolder called Windows Live.

After importing the templates, create a new answer file, and double-click each template file to add it to the answer file.

It would be nice to include the Windows Live installer in our template, so let’s do that by creating an $OEM$ Folder to go along with it. Right-click $OEM$ Folders, then choose Explore from Here, and create a subfolder structure of Windows Live\$OEM$\$1, like this:

Download the installer from download.live.com and save it in the $1 folder.

In ICE, you will now see Windows Live under $OEM$ Folders in the distribution share pane. Right click on it and choose Insert OEM Folders Path from the menu.

Now let’s save this answer file in our Templates folder in the DS as Windows Live Installer. ICE will complain to you about validation errors – this is normal and expected, as we are creating a template, and not a final image. We don’t want to resolve dependencies, as we want to represent just the modular piece of Windows Live Installer and its required packages. Some of the dependencies, for example, include choosing a language pack. By not choosing a language pack, we allow this template to be used in images with different languages.

Now Windows Live Installer.xml appears in the pane, we can right-click it and choose Export Template… to save it to an empty folder of your choice. After it succeeds, click Yes to open the folder in explorer, and notice as you drill down under the Windows Live Installer_Files folder, you find the installer executable. As another user imports this template, this installer will be copied into their distribution share. Now you can use this process to build your own library of templates!

- Nathan

Technorati Tags: XPe,Embedded Standard,CTP

ECE Site Maintenance Delayed until Feb 5

Embedded — Thu, 04 Feb 2010 22:13:02 GMT

Previously the ECE team announced upcoming maintenance to the ECE site.

This date has now changed- it will now occur on Friday, February 5, 2010 at 5:00p.m. Pacific Standard Time (PST) and will last until Monday, February 8, 2010 at 8:00 a.m (PST).

The ECE site will not be accessible during this timeframe and the ECE team apologize for any inconvenience this may cause.

- Lynda

Technorati Tags: XPe,Standard 2009

Introduction Video on Using Templates in IBW and ICE

Embedded — Tue, 02 Feb 2010 22:53:37 GMT

Last time, in this video, Ben Tucker gave us an overview of the Image Configuration Editor (ICE) tool in Windows Embedded Standard 2011. This time Ben talks about application templates and how they can be used in IBW (Image Builder Wizard) and ICE to make the imaging building process easier. The difference between the templates used in the two tools is also explained.

The video is intended for people who are new to the product. Check it out here.

Weijuan

A Bag Full of Updates are now Available on ECE

Embedded — Tue, 02 Feb 2010 01:27:59 GMT

A bunch of new 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.

These include:

An Internet Explorer Out-of-band Security Update -can be applied directly to runtime images. The componentized version of this update will e included in Feb’s security updates

978207 Cumulative Security Update for Internet Explorer

January 2010 Optional Updates – can be applied to the component database

GB18030 is a Chinese character encoding standard. Products sold in China must conform to this standard. The GB18030 Support package contains a font, system libraries, and an applet for installation on XP based systems, with the optional East Asian Language support installed, to meet these conformance requirements.
A File Based Write Filter update that addresses the following issues:
- Resolves issues caused by the FbwfProcessWriteThroughList path buffer not being cleared. This issue may present symptoms including the following:
- In the current session, FBWFMGR /display may not return accurate write through lists reflecting the fbwfmgr /addexclusion configuration. A correct write through list may not be returned until the following session.
- A newly created file, even though listed in the exclusion list, may not persist after reboot, in particular files named tmp.
- You may be able to rename a file to the same file name as a file listed in the exclusion list, in particular files named tmp. Expected behavior would return an error that the file cannot be renamed and the request is not supported.
- Resolves a potential memory leak caused by the FBWF's failure to call the FreeCallback function, required to allow memory filters above FBWF to free their per-stream context.
- Resolves a potential file deadlock, resulting from a FBWF incompatibility with a WMI API.
Microsoft YaHei Regular and Bold Version 5.00 for Windows XP to improve rendering of Simplified Chinese text in Windows Presentation Foundation.

Redistribution of Visual C++ Service Pack 1

This supplemental update for VC++ is being provided to ensure that the necessary version of the VC++ runtime library is available for runtime images

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

Custom Dialog Filters, Part 1

Embedded — Wed, 27 Jan 2010 22:31:00 GMT

A new feature in Windows Embedded Standard 7 called Windows Embedded Dialog Filter allows devices, such as Kiosks and Digital Signs, to reroute system dialogs away from the public. Using search criteria including the window’s title, class name, process name, and buttons, the window can be moved off screen or onto another screen. Also, actions can be performed such as clicking a button or closing the window.

For information on how to use the Dialog Filter, see this blog article.

There is one catch: it cannot do .NET WinForms and WPF Windows. The reason is that one of the filter criteria, the Window Class, contains instance information which changes frequently. This isn’t important for Window’s dialogs because they use consistent names, but it can be important if a 3^rd party application written in .NET shows an unwanted dialog box.

Custom Filters, a feature in the Dialog Filter component, can be created to handle this.

Basic Design

Custom Dialog Filters are in-process COM DLLs that implement a published interface provided by the Dialog Filter. The default filter which uses XML to define filters is itself a Custom Filter which means it can be overridden or replaced fairly easy. Being COM driven, Custom Dialog Filters can be written in Native and Managed code. The example below is in C#.

Step 1: .NET and COM

For more detailed information on .NET and COM, see the MSDN documentation at:

http://msdn.microsoft.com/en-us/library/zsfww439.aspx.

To get started, a TLB file is provided on the Windows Embedded Standard 2011 installed to C:\Program Files\Windows Embedded Standard 2011\EmbeddedSDK\lib\DialogFilterXmlFilter.tlb. If you don’t have this file, it can be installed from the Windows Embedded Standard 2011 DVD. This file is not registered so you’ll have to do this yourself using the command:

TLBIMP <path to DialogFilterXmlFilter.tlb> /out:<path to DialogFilterXmlFilter.import.dll>

MSDN has more information about this and other commands at http://msdn.microsoft.com/en-us/library/xwzy44e4(VS.71).aspx.

Create a new C# Class Library Project. I used the name DialogFilterDotNet but you should name it whatever is appropriate for your project. Rename the class to something more appropriate. In the example below, I used MainFilter.

With the new project’s properties, change the following settings:

Under the Application tab, click Assembly Information and check “Make assembly COM-Visible”.
Under the Signing tab, check “Sign the Assembly”. Under “Strong Name Key File”, select <New> and uncheck “Protect my key file with a password. If your organization has software digital certificates, use this instead.

Add the References. This includes the import DLL created from the TLB which can be done using the Browse option. UIAutomationClient and UIAutomationTypes are also needed.

Visual Studio 2008 and 2010 make it really easy to implement the interface from DialogFilterXmlFilter library. To do this, add the interface IObjectFilter. Visual Studio will provide an option to implement the interface by highlighting a small underscore below this name. If you do this, Visual Studio will provide the functions you’ll need to implement automatically.

Step 2: The Functions

The IObjectFilter interface has only 4 functions, 2 of which are filters, 1 for logging, and a factory.

CreateObjectInfo

This factory function is used to create an object to store information about a window which is then passed around within the Dialog Filter service. In this example, we can create the default ObjectInfoClass, a COM object implemented by the Dialog Filter’s built-in filter. You may also create your own by implementing IObjectInfo, but example will use the default.

The implementation of CreateObjectInfo is as follows:

string ModifiedClassName = WindowClass;

Match RegexMatch = _FormRegex.Match(WindowClass);

if (RegexMatch.Success)

{

ModifiedClassName = RegexMatch.Result("${type}");

}

ObjectInfo r = new ObjectInfoClass();

r.SetWindowInfo(ProcessId, ProcessName, Handle, ModifiedClassName, WindowTitle, XPos, YPos);

return r;

When a WinForm or WPF class name (WindowClass) is read, it’s going to be something like:

WinForm: WindowsForms10.Window.8.app.0.33c0d9d

WPF: HwndWrapper[WpfApplicationClassCheck.exe;;69c35e29-70fe-4bb4-af05-70880670403c]

This example looks at the class name (WindowClass) and if it follows the format of a WinForm or WPF class, a new class name replaces it with one from a Regular Expression. This Regular Expression is formatted as:

^((?<type>HwndWrapper)\[[\w.]+;;([\da-f]{8}-[\da-f]{4}-[\da-f]{4}-[\da-f]{4}-[\da-f]{12})\])|(^(?<type>WindowsForms).(\d).Window.(\d).app.(\d).([a-f\d]{6,}))$

Regular Expressions never readable, but if there’s a match format wise, ${type} will equal HwndWrapper or WindowsForms.

CheckWindow

This function is a kind of a pre-filter. Its job is to look at the basics of the window, such as the process name, title, and class name, and return to the service whether we want further processing and if we want it visible. For our example, we’re only interested in the class name and will obscure any WinForm or WPF window until we know for sure what it is.

If the window is neither a WinForm or WPF window, default processing is handled. Default processing is done by using the existing XML configured filter that ships with Dialog Filter. Doing this is easy. A single line object is added to the class:

private IObjectFilter _defaultFilter = new ObjectFilterClass();

This allows us to continue to use the XML file to list windows and actions which greatly simplifies what we need to do. The implementation to CheckWindow is as follows:

switch (pObjectInfo.WindowClass)

{

case "HwndWrapper": // HwndWrapper will stay as-is

case "WindowsForms": //WindowsForms will change to the actual class name

return CheckWindowResult.cwHideGetDetails;

default:

return _defaultFilter.CheckWindow(pObjectInfo);

}

One note about CheckWindow is that it is multithreaded and will block the window from showing itself until it returns. This is to improve system performance and eliminate flicker on the screen. Implementations should be aware that they should not spend much time doing filtering since this will negatively affect how long an application loads and performs. It also cannot call UIAutomation, however CheckWindowContents can.

CheckWindowContents

This function gives us a chance to dive into the content of a window. Unlike CheckWindow, calls to CheckWindowContents are queued and managed from a single thread. This gives us the ability to look for specific information within a window, and in our case, an AutomationId that WinForms provides.

This example looks for WindowsForms as the class name. If this is the case, the class name is reset to the AutomationId which is really the class name as written in C#. After this, the default filter is used.

if (pObjectInfo.WindowClass == "WindowsForms")

{

AutomationElement winForm = AutomationElement.FromHandle(pObjectInfo.Handle);

if (winForm != null)

{

pObjectInfo.SetWindowInfo(pObjectInfo.ProcessId,

pObjectInfo.ProcessName,

pObjectInfo.Handle,

winForm.GetCurrentPropertyValue(

AutomationElement.AutomationIdProperty) as string,

pObjectInfo.WindowTitle,

pObjectInfo.XPos,

pObjectInfo.YPos);

}

_defaultFilter.CheckWindowContents(pObjectInfo);

Again, the window is forwarded to the default XML filter. From there, XML configuration will dictate whether we show the dialog or not and whether we want to perform an action on it.

LogMessage

How we log is completely up to the implementation however it’s easiest just to forward it on to the default. The default will create log entries in the Event Viewer under Applications and Services, Microsoft, Windows, Dialog Filter. On top of that, it will provide suggestions on XML that can be added to block a window that pops up.

Implementation is a single line:

_defaultFilter.LogMessage(type, pObjectInfo, szData);

XML

The ConfigurationList.xml (usually located in c:\ProgramData\Microsoft\DialogFilter but is customizable) will vary from system to system. For my example, I created two simple programs, one WinForm and one WPF, both with a couple buttons placed in the window. Once created and run, the DialogFilterEditor is able to create filters that can be saved in the XML. The only change is that the class name must be updated to match what we’ve changed them to.

For the WinForms filter, the class name becomes “Form1”. For the WPF filter, the class name becomes “HwndWrapper”. The Close action is applied to both and is saved.

Step 3: More COM: Registering

Like in C++, .NET libraries must be registered by the administrator, however the process is completely different. This is how to do this:

Open a Visual Studio command prompt as administrator on the test system. Note that the default command prompt won’t work.
Change to the directory where the binary is built.
Run “RegAsm /tlb:<path to EmbeddedSDK\lib\DialogFilterXmlFilter.tlb> <path to custom filter.dll>”. This only needs to be done once.
Cache the custom filter dll by running “GacUtil /I <path the custom filter.dll>”. This must be done every time there’s a new build.
Run Regedit, browse to HKEY_CLASSES_ROOT\<your namespace>.<your filter name>\CLSID. For my example, it will be DialogFitlerDotNet.MainFilter.
Copy to the Clipboard the GUID value of CLSID.
Browse again to HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DialogFilter\Parameters.

Create a string (REG_SZ) called “FilterDll” and set it to the value of the GUID in step 6.

Start/Restart the service. If all goes well, the DialogFilter.exe process should appear in the Task Manager and there should be no errors or warnings in the Event Log.

Step 4: Debugging

You’re going to find out that debugging isn’t as easy as it usually is, but the easiest way is to install the Visual Studio Remote debugger on the Test system and use remote debugging. This is because breakpoints in code may block other windows from running, Visual Studio included. This often causes race conditions where Visual Studio and Dialog Filter wait for each other. There’s no nice way of getting out of this other when this happens, so avoid debugging the Dialog Filter locally.

For more information on remote debugging see

http://msdn.microsoft.com/en-us/library/bt727f1t(VS.71).aspx (using Visual Studio)

http://msdn.microsoft.com/en-us/library/cc266321.aspx (WinDbg)

- Brendan

Technorati Tags: XPe,Embedded Standard,CTP

Managing and Servicing your Distribution Share

Embedded — Mon, 25 Jan 2010 17:13:14 GMT

Since you’d be using the distribution share (DS) provided with Windows Embedded Standard 2011 from RTM until the next service pack is out, it helps to consider how you are going to manage your DS. Well, firstly, here’s a hypothetical timeline on the changes that could happen to your DS. We’ll look at 4 different scenarios from the date of Standard 2011’s release to 5 years from now.

A. Time: Standard 2011 release (in H1 2010)

Your DS is in the initial state (the golden state). It contains all the Windows-Embedded feature packages plus all the embedded specific security updates that correspond to the Windows 7 security updates since Win7’s release.

B. Time: About a month later

New security updates are released by Embedded.

You can run PkgScn on these updates and decide if your runtimes need these security updates. If needed, you can import them into your DS. If not, then you need not import them.

What’s recommended: It is recommended to import all the security updates. Even if some updates are not applicable to your device, it doesn’t hurt to import them into the DS. That way, your DS will always be in a consistent, up-to-date state. The other advantage is that you don’t have to keep track of the updates that you didn’t choose to import. (I.e. you won’t face this scenario... “I think I ignored KB300000 since it was a Bluetooth security update and my device doesn’t contain Bluetooth. But am I sure that it was a Bluetooth update? Let me look up this Excel file to check. Wait a minute... is this Excel file up to date?”)

C. Time: About 3 months later; a new Out Of Band (OOB) package is released by Embedded, say .NET 4.0 or GoldDark (it’s hard to come up with cool OOB names! So something sounding like Silverlight should suffice for now)

The package is usually available on one of the usual websites (Out of Band updates, as well as Security updates can be downloaded from Microsoft OEM Online or the Mobile and Communications Extranet.). You import this package into your DS. You can now create embedded devices using this new OOB package. You again need not import this package if your device doesn’t have anything to do with .NET 4.0 or GoldDark

What’s recommended: To import the package for reasons similar to importing updates.

D. Time: About 5 months later; a bug fix is done in a package, say .NET 2.0. The updated feature package is released by the embedded team.

Why do we release an updated feature package instead of an update package?

Along with binary changes, a feature package also contains Windows-Embedded specific information which an update package doesn’t. For example, a feature package contains dependency information so that when you select a package in ICE, it tells you that it depends on package X, Y and Z. An update package doesn’t contain any Windows-Embedded specific information. It only contains logic and rules that allow the operating system’s CBS layer to install the update (more on CBS in another blog).

Since we have about 600+ feature packages, there is a remote possibility that one or more of these packages may have incorrect package dependency information. To rectify this, we need to service the Windows-Embedded specific information and this is done only through an updated feature package.

What’s recommended: Importing this package into the DS. Again, even though it is a package that your device isn’t currently using, it’s a good practice to import it into your DS.

Based on this timeline, here are some basic findings:

1. It is better to import all packages and updates that are released by the Embedded team

2. It is important to not remove or delete any package from the DS.

ICE and ImportPackage access the DS by using a binary index file. Whenever you import a package into the DS, this index file is updated by ImportPackage. So, if you manually delete a package from the DS, the index file goes out of sync, hence causing problems.

Why would somebody delete a package?

“Hey, I am developing a device that only needs a minimal runtime and the basic networking package. Why do I need all other packages? They take up too much disk space. That’s why I deleted them…”

Suggestion - Don’t bother about disk space. The DS doesn’t reside on the embedded device. It exists on developer machines or on a server. On these boxes, space shouldn’t be a big issue considering the problems you can avoid.

3. Since there are constant updates to the DS, it makes sense to have regular backups of the DS. Probably each time you decide to import update packages. You could consider a configuration management system to store your DS. A simpler and more efficient way would be to use a server share.

4. Since you may have to manage over a long duration, you could probably have a folder structure as follows

\\server\WES_DistributionShares

Gold

SP1

Backups

Gold

Sep-01-2010

Jan-01-2011

Feb-01-2011

SP1

Sep-01-20xx

Oct-01-20xx

Hope you find this useful... feel free to post your questions... till then, ciao.

-Anup

Technorati Tags: XPe,Embedded Standard

January 2010 Runtime Security Updates are Now Available on the ECE Site

Embedded — Thu, 21 Jan 2010 19:41:34 GMT

The January 2010 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.

This month’s security updates can be applied directly to runtime images.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 January Security updates include:

972270 Vulnerability in the Embedded OpenType Font Engine 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.

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

Introducing Improvements to the Windows XP Embedded and Windows Embedded Standard 2009 Security Update process for OEMs and Distributors using Microsoft OEM Online (MOO) and the Embedded and Mobile Communications Extranet (ECE)

Embedded — Thu, 21 Jan 2010 02:16:00 GMT

ASK: The Embedded product group has been asked by customers to reduce the size of the monthly Windows XP Embedded and Windows Embedded Standard 2009 Security Update supplemental releases on MOO and ECE.

HISTORY: The monthly supplement has accumulated every security DQI (runtime update package) that is applicable for each of our embedded platforms. The supplement also includes a cumulative component database update for each platform development environment, which contains all applicable Security updates since the platform released. By accumulating the applicable DQIs for every platform on the download, over time the size of the monthly security supplement has grown quite large. For example, the December 2008 IMG (ISO) download was approximately 507MB. This has grown to approximately 800MB for the December 2009 IMG (ISO) download.

ACTION: Beginning with the January 2010 supplement, we have implemented a new process. The January 2010 supplement provides the DQIs for December 2009 and January 2010 as well as the cumulative component database updates for each platform, which still contain all Security updates since the platform release through December 2009 (the database updates are bi-monthly and current in the even numbered months). DQIs will accumulate for each supported platform throughout the year. At the beginning of 2011, we will do a similar refresh of the supplement.

RESULT: The January 2010 IMG file is significantly reduced in size, to approximately 256MB. The size will increase throughout the year, and be reduced again with the January 2011 update. With this plan in place, we don’t expect that the size of the supplement will grow to the size of the December 2009 supplement again.

Customers can still bring their development environment completely up to date with all Security updates applicable to their platform by installing just the component database update for their platform from the latest Windows XP Embedded and Windows Embedded Standard 2009 Security Updates – Product Download.
For runtime servicing, our customers only need to apply the DQI runtime updates released after the servicing date of the development environment used to build the runtime. For example, consider servicing a runtime built with Windows Embedded 2009, which had the development environment updated with the September 2009 security update for the component database (servicing date = September 2009).

The December 2009 Windows XP Embedded and Windows Embedded Standard 2009 Security Updates – Product Download which contains all DQI runtime updates for each platform through December 2009, and the current 2010 Windows XP Embedded and Windows Embedded Standard 2009 Security Update – Product Download which contains all of the 2010 DQI runtime updates are the only two resources you need.

All DQI updates from September 2009 through December 2009 would be applied from the December 2009 Windows XP Embedded and Windows Embedded Standard 2009 Security Updates – Product Download release.
Then all of the DQI updates from January 2010 forward would be applied from the latest 2010 Windows XP Embedded and Windows Embedded Standard 2009 Security Update – Product Download.

Consider servicing the same runtime in 2012. You would install the following DQIs:

September 2009 through December 2009 would be applied from the December 2009 Windows XP Embedded and Windows Embedded Standard 2009 Security Updates – Product Download
All DQIs from the December 2010 Windows XP Embedded and Windows Embedded Standard 2009 Security Update – Product Download
All DQIs from the December 2011 Windows XP Embedded and Windows Embedded Standard 2009 Security Update – Product Download
All DQIs from the current 2012 Windows XP Embedded and Windows Embedded Standard 2009 Security Update – Product Download.

For more information on servicing the development component database and Embedded runtimes, please see the Readme at the root of the monthly security update supplement, and also this previously posted blog article:

What’s New in Security Update Servicing - http://blogs.msdn.com/embedded/archive/2008/12/02/what-s-new-in-security-update-servicing.aspx

- Gina

Technorati Tags: XPe,Embedded Standard

Round 1 Winners for embeddedSPARK Competition Announced

Embedded — Mon, 18 Jan 2010 18:07:29 GMT

Round 1 of the embeddedSPARK competition ended last week and the 75 contestants moving to Round 2 were announced on Friday. In Round 1, each contestant had to submit a paper detailing their idea for a project related to the “Fun and Games” theme. In Round 2, they will have to develop their ideas into a working prototype. The top 3 entries from Round 2 will go on to compete live on stage at ESC Silicon Valley during Kevin Dallas’ keynote.

See more details see the post here.

- Lynda

Technorati Tags: XPe,Standard,CE,Embedded

Some Thoughts about Application Templates in Windows Embedded Standard 2011

Embedded — Wed, 13 Jan 2010 18:00:00 GMT

Now that Windows Embedded Standard 2011’s CTP2 has been publicly available for several weeks I hope you’ve had the chance to take a look at our new Application Templates web page. Finding the dependencies for an application to ensure it runs correctly on your embedded image has always been one of the biggest challenges in using Windows Embedded and we hope to make life easier for you by providing answer files for specific applications, saving you time and effort.

Currently, the Application Templates web page displays templates we have created for some Microsoft applications and allows you to download and utilize the templates. It functions well as a little repository and currently suits what we are doing. However, we want the Application Templates site to be a place that a community can be built around, benefitting all OEMs, ISVs, developers, and other potential customers that use Standard 2011. At a high level, here are some of the things you should be seeing in the future as we improve the Application Templates website.

Website

While I can’t promise exactly what features we will be adding or how the website will be improved, we are very much looking to make the site customer-oriented and community-driven while also attempting to integrate the experience with our tools as much as possible. Here are some possible ideas for the website:

Add sorting and searching to the website
Give each template its own page with comments and ratings
Allow the templates to be downloadable from the website while in ICE
Allow for anyone’s template to be uploaded to the site

Templates

In the coming months, we hope to add three different kinds of templates to the site:

More Microsoft application templates, such as:

Silverlight 4
XNA
SQL Express
System Center Configuration Manager
And several others

Templates, created by Microsoft, for third-party applications. Possible examples include:

Adobe Flash
eTrust Antivirus
Symantec Altiris
Citrix Receiver

Templates for third-party applications, created by the companies that own those applications. We’re very excited about these, since these templates are created by the developers of the applications. This will ensure that they are being created by the individuals who know that application better than anyone else in the world and allow for better testing and smaller footprint sizes. We are working with several companies on this at the moment, and you should be seeing these templates show up over the coming months

Eventually, we hope to allow for user-created templates to be uploaded to the site as well, allowing for a fourth kind of template.

Documentation and Tools

More and more documentation will be posted to explain the new features and how to get started with using the template site or making your own application templates. Blog articles, video tutorials, live meetings, and whitepapers will all be available in a new “Documentation & Help” section on the application template website.

In addition to this documentation, we are working on some small downloadable utilities that will make dependency analysis and template creation easier for everyone.

All in all, there’s a lot of work to be done in this area, but we’re very excited about where we are and how we’ve started out, and we hope continually improve the application template experience so it can be useful for everyone.

What do you think of the ideas? Is there something you’d like to see added? We’re very interested in your thoughts and feedback, so post a comment on the blog site.

- JT

Technorati Tags: XPe,Embedded Standard

Quick Introduction Video on Image Configuration Editor (ICE)

Embedded — Mon, 11 Jan 2010 21:22:33 GMT

Recently I sat down with Ben Tucker and talked about Image Configuration Editor(ICE), one of the key tools in Windows Embedded Standard 2011. Ben is one of the Program Managers who have been working on the tools for a while. He gave us a high level introduction and then walked us through an end-to-end demo on how to use the tool to create an answer file for an embedded device image.

This video is for people who are new to the product. In the future we’ll have follow-up videos to deep dive some specific areas/features.

Check out the video here -

Ben Tucker talks about Image Configuration Editor

Weijuan

Upcoming Maintenance to ECE Site

Embedded — Mon, 04 Jan 2010 19:00:00 GMT

Just wanted to let folks who access XPe and Standard 2009 updates and information from the Mobile and Embedded Communications Extranet, better known as the ECE, that we have a scheduled maintenance coming up and the site may be temporarily unavailable during the timeframe.

Currently we are on track for the maintenance to begin Friday, January 8, 2010 at 5:00 p.m. Pacific Standard Time (PST) and it supposed to last until Monday, January 11, 2010 at 8:00 a.m PST. If there are any changes to this date they will be featured on the ECE homepage.

We apologize for any inconvenience this may cause.

Thanks,

- Patrick

Technorati Tags: XPe,Embedded Standard

Reduce Exposure Time and User Downtime when Servicing a Write-Filter Enabled Image

Embedded — Wed, 30 Dec 2009 00:30:00 GMT

Those who service images with write filters are aware that the combination of applying updates and having write filters is one with several concerns and complexities. Amongst those concerns are exposure time and user downtime. What do I mean? I will explain in the following paragraphs.

Servicing a write-filter enabled image goes roughly as follows:

Disable write filter
Reboot (so that disabling the write filter goes into effect)
Download the update
Install the update
Re-enable the write filter
Reboot (so that the re-enabling of the write filter goes into effect)

What we care about here is that the write filter is disabled throughout Steps 3 and 4, which has two negative implications:

Exposure Time: The system is in a state where any write will be persisted, or in other words, the system is exposed.
User Downtime: Users are expected to not do anything during this duration to prevent persisting of an undesirable state. Often IT Pros will ensure that the user is locked out through this duration.

Although you may fail to completely eliminate the above two problems, you can at least take measures to mitigate them. Like what? Just move Step 3 (Download the update) to the beginning of the 6-step process. To be more explicit, the new 6-step process will be as follows:

Download the update
Disable write filter
Reboot (so that disabling the write filter goes into effect)
Install the update
Re-enable the write filter
Reboot (so that the re-enabling of the write filter goes into effect)

Now, the update will be downloaded while the write filter is still enabled leaving only the installation step (Step 4) to take place while the write filter is disabled. Subsequently, the exposure time and the user downtime will be limited to just the installation step.

But wait… the update downloaded at Step 1 will no longer be there by the time we reach Step 4 to start the installation. That is correct-----unless the update is downloaded into an unprotected location in the filesystem. In the case of FBWF, you can easily add a particular folder to the exclusion list and have the update files downloaded there. As for EWF, you will need an unprotected partition to download the updates into. Subsequently, this approach may not work well for everyone who’s using EWF.

In closing, I should note the obvious: The implementation specifics have not been spelled out in this article as they vary depending on customer needs and the specific technologies used for servicing. Lastly, I will attempt a quick one-sentence recap: To reduce exposure time and user downtime, download the update files into an unprotected location, so that the write filter only needs to be fully disabled during the installation.

- Norris

Technorati Tags: XPe,Embedded Standard

Happy Holiday From the Embedded Team!

Embedded — Thu, 24 Dec 2009 02:56:00 GMT

I'd like to send good wishes from the whole team to all Embedded Windows customers, partners and MVPs for a wonderful holiday season, and a successful 2010! We thank you for your support in 2009. Your willingness to give feedback, as well as your continued participation in community forums and newsgroups, chat sessions, face-to-face or virtual meetings are greatly appreciated by our team. We hope we can continue to partner with you to bring you prosperity in the new year.

FYI-The Redmond offices of Microsoft will be closed tomorrow and Friday (PST) for the Christmas weekend, so responses to mail and forum posts may be delayed.

- Lynda

Technorati Tags: XPe,Standard