Partilhar via


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

[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.

image

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

  • The first one is an all time classic: Turn off USB storage support. Nobody wants the newest viruses on a kiosk system and, therefore, it is good to disable all kind of UFDs the kids in the neighborhood may be ready to plug in. There is a great article by Mitch Tulloch that shows how to do this with Group Policies.
  • Logon scripts are a great way to handle dynamic, user-specific actions. These scripts are easily configured in the GPO editor and can be distributed via the same AD infrastructure as the GP settings. There is a lot of information on this to be found at the TechNet script center. Using a logon script e.g. the configuration of different shells for different user can easily be implemented.
  • If a project requires granular control of which features of the control panel are shown, then GPs will find a way to just show the required applets.
  • Another area that can be configuration can be the desktop appearance, especially if you are running Explorer shell on the embedded device. Quite often the “embedded shell” needs to provide similar but not the same functionality as a desktop system to satisfy the needs. GPs deliver very granular means to configure the UI. Just have a look at the Computer Configuration\AdministrativeTemplates\Desktop section in the GPedit console.
  • image
  • You want to prevent users disabling the LAN connection? Not a problem, have a closer look at the settings below Computer Configuration\Network\Network Connections. This and a lot of other network related settings can be configured here.
  • Speaking about UI there is also a complete template section in GPedit for the Start Menu. This can be used toconfigure Explorer shell to conform to various project use cases.
  • Configuring IE: This is one of my favorites. IE is highly customizable and with GPs OEMs are able to tailor, brand and fine-tune this important application to their needs. The picture shows how to add your company name to the IE title bar.
  • image
  • What if one wants to have UFD support to read files, but wants to prevent installing software from these devices? That is a tough one, isn’t it? Well, have a look at Computer Configuration\Windows Components\Windows Installer\Prevent removable media source for any install. Keep in mind that this turns off CD/DVD installations as well.
  • RUN Programs at Logon. This setting is available in the User Configuration\Administrative Templates\System\Logon section. Any application that should be running when a user is logged on can be added here.
  • Last but not least- did it ever make sense for your embedded device to wake up from hibernate without entering the password? Well, in a lot of embedded scenarios this is the desired default. The User Configuration\Administrative Templates\System\Power Management\Prompt for password on resume/hibernate setting allows to manage this setting. Very useful looking at headless devices!

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

Comments

  • Anonymous
    July 07, 2009
    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?

  • Anonymous
    July 08, 2009
    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.

  • Anonymous
    July 08, 2009
    @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?

  • Anonymous
    July 09, 2009
    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.

  • Anonymous
    July 14, 2009
    The comment has been removed