Windows Embedded Home
Windows Embedded 8 Family
Windows Embedded 7 Family
Other Windows Embedded Products
**Updated 3/26/09 with preface
[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.]
Devices built with Windows Embedded Standard 2009 are able to offer sophisticated security mechanisms that integrate well in Enterprise scenarios, depending on the components that are included in the image. But, as always, more functionality means higher image footprint and so it is good to treat security considerations not as an afterthought, but as an important item on the requirements list, when designing the device architecture.
What it is:
Microsoft Support Lifecycle policy is the Microsoft standard for product support availability throughout a product’s life. Quoting the Lifecycle policy page: “By understanding the product support available, customers are better able to maximize the management of their IT investments and strategically plan for a successful IT future.” This is true for OEMs supporting embedded devices as well.
Blog-worthy Embedded Windows Dates:
Over the years there have been a number of newsgroup posts about using System Cloning with IIS. Some customers have cloned the image and then found that IIS service will not restart on the cloned image when it boots up.
There are a number of issues that may have an impact here. The most common one to be aware of is that fbreseal.exe does not support cloning an image more than once. Cloning an image numerous times can lead to data loss and image corruption of user settings, IIS & database settings, domain memberships and local & group policies.
Even on image sealed just once the IIS service may not start, due to a timing issue with services restarting on the cloned image. Brad Combs explained it this way in a newsgroup post:
Have you noticed that there is a huge amount of Windows XP Embedded related content on the public internet?
Have you also discovered that it can be hard to find, collect and organize the information you need to answer XPE questions and solve XPE problems?
Did you ever wish for a "Top Level" reference document that ties together all the myriad resources? A single document that you can search to find your solutions or links to solutions?
As mentioned in the blog articles “Image Builder Wizard – Quick and Easy Embedded OS Creation – Part 1” written by Robert and “BitLocker in Windows Embedded Standard 2011” written by Hema – the BitLocker feature requires two partitions. The first partition is a system partition contains the BCD (Boot Configuration Data) store and remains unencrypted. The second partition is the partition that contains Windows, programs, etc and can be encrypted. IBW does a good job in ensuring that the user is required to partition with a separate system partition if the user has added the BitLocker feature. It is able to do that because it has an awareness of whether the feature is added by the user.
What’s the “Gotcha” you may ask? Well, during Mass Deployment scenarios, such as using WDS or IBW to deploy a custom WIM, the disk partitioning dialog has no awareness of whether the BitLocker feature is in the image. That means that it is possible under these circumstances to create a system with the BitLocker feature and only have one partition. This is not a supported setup for BitLocker and the feature will not enable or allow the Windows partition to become encrypted.