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.]
One of the new features in Windows Embedded Standard 2009 is the support of SCCM operating system deployment. This means, any Standard image can be deployed the same way images for desktop or server machines are deployed within an SCCM infrastructure. Previously, it was not possible to deploy XP embedded images, because XPe did not support the Sysprep utility.
Change management scenarios of embedded devices are sometimes much harder to handle than those of corporate desktops. This is especially true when you consider the way users interact with devices. System Center offers a control panel applet users and administrators can use for local interaction with the Configuration Manager infrastructure. This works fine for Windows Embedded Standard Devices as long as they run explorer shell the same way corporate desktops do. If embedded devices run their own shell these options are gone, because no access to the applets can be provided.
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:
An embedded device has to look like an embedded device! This means that the system and its user interface needs to be optimized according to the device purpose and should not behave like a PC. In some cases, the systems should not even give a hint about the platform they are running on. This does not only lead to a better usability experience, but also can be the first security barrier if systems are designed to operate in places where neither network nor physical access can be controlled very well. Gaming consoles, for example, are very often a target for fraud and designers try to set up many intrusion barriers to guard against this.
To be very clear, creating a custom software update or servicing solution is not something that should be taken lightly. It may look relatively easy at first glance and this makes it tempting to try, but many device projects have been derailed by custom solutions.