Component Tales: 10 Cool Uses for Group Policies on Windows Embedded Standard

re: Component Tales: 10 Cool Uses for Group Policies on Windows Embedded Standard

David — Wed, 08 Jul 2009 09:35:39 GMT

Yes, Group Policies are cool, but the problem I see is that an administrator could apply policies that break the embedded device or simply alter its configuration in ways that were never tested. This is a very problematic scenario for e.g. medical devices.

Is there a way that I can configure an Embedded image so that only the policies that I can test can be applied? For example, I don't want to run any other code than my own, so no scripts are allowed, and no published applications. In essence, I want a local policy that overrides everything else, and only leaves a few cruical settings overrideable. This is not what you want on a general purpose desktop OS, but it is very desireable on embedded device. Is it possible?

re: Component Tales: 10 Cool Uses for Group Policies on Windows Embedded Standard

Alexander Wechsler — Wed, 08 Jul 2009 19:28:23 GMT

There are some precautions that help to make make this possible. First, put all Windows Embedded Standard devices in their own organizational unit in Active Directory. You or the admin are then able to specify and test which policies are applied. This can be considered a best practice for Standard devices, anyway, because it shield against desktop GP changes.

Additionally you could use EWF or FBWF to protect the image against unwanted configurations and apply GPs selectively leveraging Secedit(see http://support.microsoft.com/kb/227448).

In this scenario EWF or FBWF need to be turned off before the update and turned on afterwards.

re: Component Tales: 10 Cool Uses for Group Policies on Windows Embedded Standard

David — Wed, 08 Jul 2009 23:43:04 GMT

@Alexander: Thanks for the reply, but I think Secedit is too coarse. Also, EWF and FBWF won't prevent policies for being applied at boot time (although changes don't persist after a restart).

If all the users of my device really put it in an OU of its own, with only "safe and approved" policies, there would be no problem, but what realistically is going to happen is that admins mistakenly apply policies that break the device, like installing an intrusive antivirus suite on it. If this is a medical device, with strict regulatory requirements, this is unacceptable.

Right now I don't see how I could join a medical device to a domain and have Group Policies enabled without these kind of risks. So, would it be possible to join a domain for the sake of authentication, but completely opt out of Group Policy? Finally, any news on improvements to this scenaro in Windows 7?

re: Component Tales: 10 Cool Uses for Group Policies on Windows Embedded Standard

Alexander Wechsler — Fri, 10 Jul 2009 09:02:52 GMT

If You just need authentication functionality, this can be achieved with the help of AD Federation Services (http://technet.microsoft.com/en-us/library/cc772593(WS.10).aspx)on application level without joining the domain. Another option would be the use of LDAP to do authentication aginst the directory service.

Btw., if you do not trust admins you should educate them to handle your devices.

Otherwise there will be a lot of problems, e.g. with the handlicng of application and OS updates. What if they apply all desktop patches to your device? In this case the problem is not being in a domain or not.

re: Component Tales: 10 Cool Uses for Group Policies on Windows Embedded Standard

David — Tue, 14 Jul 2009 19:08:45 GMT

@Alexander: Thanks, those were great tips that I will look into.

About not trusting admins - think of the device as a locked-down appliance where users and admins don't have access to the standard Windows shell or command prompt, and applications can't be run from external media. Updates will come through the device maker, not Microsoft Update. It is really an embedded device in the more traditional sense and not intended to be used as a general purpose Windows PC. The motivation for using Windows at all is ease of development and access to many enabling technologies (save for the full Windows shell and Control Panel). I think that it is important that Windows Embedded works well in this scenario, and not just Windows CE. This includes giving the platform builder a lot of control over the end product, from how the boot process works, Plug-and-Play driver installation, Control Panel dialogs, and selective Group Policy application. The point is to leave more control over which parts of Windows that a user (or admin) can access to the device maker, without having to reinvent the wheel (i.e. rewrite a lot of Control Panel dialogs that open "Pandoras Box" or build something akin to Group Policies to help with management of many devices).