[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 some of my recent posts I have already shed some light on enterprise infrastructure components such as ADSI, WMI or COM+ Services. Another member of this family is Group Policies. As part of the Windows security system it provides a granular means to configure user-, system- and domain-wide functionality, which can also be synchronized via Active Directory if needed.
In contrast with other Windows subsystems there is no macro component that holds the complete Group Policy support, instead each of the relevant feature components, e.g. Internet Explorer, pull-in Group Policy support as needed into an embedded image. Although GPs are configuration infrastructure features similar to WMI, there are some subtle differences. WMI is not as tightly woven into the Windows security system and user management cannot be as easily applied to a larger number of computers.
Embedded perspective
Adding Group Policies requires image sizes above 100 MB at least and, therefore, might not be an optimal fit if a project needs to have a minimal footprint. If images can around 200 to 400 MB or larger, there is great value to be derived from this infrastructure. There are no settings in Target Designer to configure these components during build time- all configuration is handled during runtime.
One of the great things about Group Policies is that any setting you create with the Group Policy Object Editor (GPedit.msc) can be synched across a domain easily or, in the case of embedded, cloned from a master image to all target systems. This does not only apply to local or network configuration settings. The power of Group Policies becomes apparent when the configuration has to follow specific policy requirements, that may be a mix of device, user and security settings. Here some interesting sample scenarios.
10 embedded scenarios for Group Policies
These ten samples are just the tip of the iceberg. There are tons of unexplored settings and configurations left to discover that are able to help in a Windows Embedded Standard Project.
- Alexander
Alexander Wechsler
Wechsler Consulting
www.wechsler-consulting.de
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?
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.
@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?
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.
@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).