**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.]
In a lot of usage scenarios the standard Windows authentication mechanism “Windows Logon” is not the appropriate way to handle user authentication. This may be due to the lack of input devices such as keyboard, or the fact that the device is running a custom shell, which never is logged off.
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.
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:
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.