Managing embedded devices with System Center

Microsoft

bloggers

discussions

Managing embedded devices with System Center

  • Comments 0

Posted By Jeff Wettlaufer
Sr. Technical Product Marketing Manager

In this post, I would like to talk about the advancements we have made with our relationship with Microsoft System Center to manage Windows Embedded devices. As organizations today are looking to integrate intelligent connected devices into their existing distributed infrastructure (AD, Server, System Center), it has become more important than ever to ensure those devices are secure and well managed. 

There are some classic challenges with managing embedded devices. I’ll highlight some of those general issues for you first, and then discuss how System Center has addressed these through Service Pack and R2.

Customization

Embedded devices are unique in a number of ways when compared to desktops, laptops and servers. The OS is typically customized, and enabled with restrictions and filters. It also runs on unique hardware that uses different drivers, modules and connectivity.

Identification

Embedded devices are not only unique in their configuration, they are also sometimes challenging to identify. Not just at face value – for example, they rarely look like a PC (more like an X-ray machine, POS device, or MRI) – but also under-the-hood infrastructure like Active Directory, Group Policy and System Center components may not recognize or understand that Windows Embedded devices are in fact just Windows devices. So targeting and getting a client installed may not always be successful.

The OEM

Another unique situation often encountered with embedded devices is the management of the device from the OEM. The OEM provides the OS image with the device, and typically provides updates to that device through their own processes. As a result, a parallel workflow for some of an organization’s devices is in play.

Write filters

With Windows Embedded devices, a unique feature that can be enabled (which has been improved with Windows 8.1) is Write Filters. Enhanced security, reduced hardware tax (flash storage disks, etc.) and optimized performance are key benefits. This includes an ability to configure a device with an “overlay” that permits some write activity, but redirects it to the overlay layer instead of to the traditional destination. This allows an app or service to behave as expected, but the state of the device is protected. On reboot, state restores, and it’s like it never happened. This is a significant capability for devices that are deployed – they essentially perform like the first day out of the box (we all know that).  The beauty of the Unified Write Filter is that it is not just on or off; it can be customized with exceptions for patch, AV etc. 

Having the ability to manage these filters is important. As good as the Unified Write Filter in Windows Embedded 8.1 Industry is, it can also be an administrator’s worst enemy: all their patch management, software distribution and Group Policy efforts don’t stick to the device through reboots.  So, the need to understand filters--and manage exceptions through them--is key. Enter System Center. While some of these challenges are out of scope for what System Center can do today, below we summarize for you some elements that are addressed in the Service Pack 1 and R2 releases.

Device management with System Center

At Microsoft, we really started talking about management of Embedded when I was the Senior TPM for Configuration Manager a few years ago. At the time, the Windows Embedded team built something called the Windows Embedded Device Manager (WEDM), an add-on to ConfigMgr 2007, which enabled the software distribution, OS deployment and configuration of Windows Embedded devices. This was a great step, and with SP1, integration of this functionality was achieved.

With the recent advancements in System Center 2012 Configuration Manager SP1, these capabilities are increased. Based on direct feedback from the Windows Embedded team, customers and partners, some key features were brought into support.

First, the supported platforms were extended. Now, thin clients, POS, digital signs, kiosks and thin PCs are included without additional software of add-ons--something admins really asked for.  The key scenarios the ConfigMgr team worked towards for SP1 included:

  • Write Filter orchestration (UWF is an R2 focus)
  • Maintenance Window support
  • Opportunistic and forced persistence of state change
  • System Center End Point client installation
  • System Center End Point update support
  • No additional software/license required

Persistence pays off

It’s important to understand how change can and should be allowed to impact a device, and the System Center team did a great job of understanding what types of change should be “forced” and what kids of change to a device should be “opportunistic.”

Apps, packages and programs (the traditional SMS/ConfigMgr app package), software updates and task sequences are defined as a forced persistence; meaning, the admin will explicitly target and schedule these intended changes to devices. Other settings are a little more fluid, and can be effected by usage, environment, logged-on user etc. These include client agent settings, settings management (previously referred to as DCM or Desired Configuration Management) and power management.

Not only are these settings now possible, the team has made it easier for the admin to orchestrate the configurations. One of the toughest elements to change in a product is the UI. In the case of Endpoint Protection support with the SP1 release, the ability to check a box to enable an exception through a Write Filter is possible, so admins can simply deploy a patch and target embedded devices that may have filters enabled. This allows the filters to remain enabled, but updates to perform properly. This includes the ability to simply let a targeted package write to the overlay, but be flagged so when the next deployment of something comes along, it batches up the changes and goes through filter management to commit the changes (This can require a reboot cycle to allow filters to come off and then be re-enabled.).

In conclusion, it’s important to understand that embedded devices, just like PCs and servers, need to be managed. The Unified Write Filter concept is a significant capability for Windows Embedded devices, and with the relationship to System Center now understanding many of these Filters, the ability to create exceptions in deployment is vastly improved.  

For more information, visit our Windows Embedded 8.1 Industry page or read the following additional technical references:

How to Manage Windows Embedded Write Filters Using System Center 2012 Configuration Manager

Managing Embedded Devices with Write Filters in Configuration Manager Service Pack 1

How to Manage Windows Embedded Write Filters Using Configuration Manager 2007

Example Scenario for Deploying and Managing Configuration Manager Clients on Windows Embedded Devices

My next blog in this series will be about deployment; visit my previous blog—an overview of new technical elements in Windows Embedded 8.1—here.

blog comments powered by Disqus