Managing "BYO" PCs in the enterprise (including WOA)

Posted April 19, 201212 yr

FPCH Admin

With more and more people providing their own hardware for work, the "bring your own" PC is becoming more commonplace and IT Pros want to have the confidence that they can support their clients who follow this trend. The presence of BYO does not change the need for IT Pros to manage, secure, and remain accountable for the network assets of an organization, and we all know that written policies can only go so far.
This post focuses on managing WOA PCs, which are designed with this "consumerization of IT" in mind. PCs of all form factors built on x86/64 architecture have the full complement of management tools available to them, especially those supported by third-party code running on the system. Since WOA PCs only support third-party code through the Windows Store and WinRT-based applications, we set out to develop industry-leading management capabilities that support BYO or company-deployed WOA PCs. This post was authored by Jeffrey Sutherland, a program manager lead in our Management Systems group.
--Steven

One of the major trends in IT in recent years has been the drive towards consumerization of IT, which is a term describing how consumer technology, from phones to PCs, is bleeding into business organizations in all forms and fashions. And increasingly, the devices that are showing up are owned by and liable to the employee rather than the organization they work for. We see this most notably in the smartphone device category, but more recently also in tablets or other portable PC form factors that are increasingly showing up in the workplace. As organizations embrace consumerization, IT must consider how much control they can exert over a users personally-owned device, and how much management is good enough. These questions were top of mind for us as we began our journey to Windows 8, and particularly, as we built Windows for the ARM processor architecture. Our focus has been on how we can continue to deliver PCs and software that users need, like applications and data-access on any device, with enough IT control to assert that the device is trustworthy, while avoiding any compromise of the users privacy on their personal device.

In Stevens earlier blog post about Line-of-Business applications and the WOA management client[/size]

Demand for access to the business apps that users rely on - from email to licensed software from an independent software vendor to home-grown apps developed by IT - is one of the most important use cases for consumer devices in the enterprise. We know that developers are going to find it easy and convenient to build elegant Metro style apps that automatically work on any Windows 8 system including WOA, and developers of line-of-business (LOB) apps wont be any different. But many organizations want to directly control and manage access to their internal LOB apps, including the distribution of the app binaries for installation. For these organizations, publishing their LOB apps to the public Windows Store doesnt make sense, since there is no reason to broadcast these applications to others or to have their application deployment managed through the Windows Store process. And access to these resources and the data that they expose requires an assurance to IT that the systems accessing them meet an established bar for security and data protection.

Organizations have been dealing with apps on x86/64 machines for a long time using a variety of tools and methods, including management products like System Center Configuration Manager and Windows Intune. Management of Metro style LOB apps on x86/64 will be able to leverage those same existing tools and methods and only requires that the client be configured to trust the apps that come from a source other than the Windows Store. For more information on the base capabilities of adding and removing Metro style apps on x86/64, see [url=http://technet.microsoft.com/en-us/library/hh852635.aspx" target="_blank">How to Add and Remove Apps. Developing WOA, however, provided us a unique opportunity to architect how LOB apps can be delivered to users in a way that meets the needs of IT while continuing to guarantee a consistent and reliable end-to-end experience over the life of the PC.

For WOA, we have integrated a new management client that can communicate with a management infrastructure in the cloud to deliver LOB apps to users. Youll hear more about this management infrastructure at a later date from our friends on the [url=http://blogs.technet.com/b/systemcenter/" target="_blank">System Center blog, so this post will focus on the benefits and capabilities of the WOA management client itself.

There are actually two parts to the WOA management client: the built-in system component, which well call the agent and a Metro-style app, which well call the self-service portal, or SSP, that the consumer uses to browse for and install LOB apps made available to them. Both parts of the WOA management client are well behaved Windows 8 apps in terms of user experience, power management/battery life, network awareness (for metered networks), and overall functionality.

The agent does most of the heavy lifting on the client. It configures the client to communicate with the organizations management infrastructure periodically synchronizes with the management infrastructure to check for any updated LOB apps and apply the latest settings policies configured by IT for the device and handles the actual download and installation of any LOB apps that the user wants to install. Finally, if the user or the administrator chooses to remove the device from the management infrastructure, it clears the configuration of the agent itself and disables any LOB apps the user installed from the SSP.

Connecting to the management infrastructure

Lets explore some of these elements in more detail, starting with connecting the client to the management infrastructure. In truth, this step begins with the IT admin who specifies the group of Active Directory (AD) domain users who are authorized to connect devices into the service. The admin also has the option to specify the maximum number of devices allowed per user. For authorized users, the actual steps to connect a device are quite simple. Using a new Control Panel applet on their WOA device, the user supplies their company email address and password, just like they do to set up an Exchange email account. The agent then performs a service lookup to locate the organizations management infrastructure based on the users email address.

[url=http://blogs.msdn.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-01-29-43-metablogapi/5633.Fig1_5F00_6F98511C.png" target="_blank">http://blogs.msdn.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-01-29-43-metablogapi/4150.Fig1_5F00_thumb_5F00_485E07E7.png

Connecting to your management infrastructure is as easy as entering your company email address and password

Once the agent has found the right address, it establishes a secure connection to the management infrastructure using [url=http://en.wikipedia.org/wiki/Secure_Socket_Layer" target="_blank">SSL Server Authentication and authenticates the user. If the user is successfully authenticated and has been authorized by the admin to connect devices, the service issues a user certificate to the user who initiated the connection. This certificate is sent back to the agent along with the organization root certificate and instructions for the agent, which it uses to configure its ongoing communications with the management infrastructure. All of this happens in a matter of seconds and typically requires no further interaction from the user. Once complete, the user is directed to install the SSP while the agent completes the connection in the background.

[url=http://blogs.msdn.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-01-29-43-metablogapi/6201.Fig2_5F00_4F11116A.png" target="_blank">http://blogs.msdn.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-01-29-43-metablogapi/8666.Fig2_5F00_thumb_5F00_27D6C835.png

[url=http://blogs.msdn.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-01-29-43-metablogapi/0250.Fig3_5F00_52AF2C47.png" target="_blank">http://blogs.msdn.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-01-29-43-metablogapi/0334.Fig3_5F00_thumb_5F00_6E53B83D.png

Completing the connection

Next, the agent automatically initiates a session with the management infrastructure, using the user certificate to authenticate. This session and any subsequent sessions are performed using SSL Mutual Authentication to ensure the security of the connection. This initial session completes the registration of the device with the service by supplying some basic device information such as the make and model, the OS version, device capabilities, and other hardware information. This allows IT admins to monitor what types of devices are connecting to the organization, so they can improve the apps and services they deliver to users over time.

Following the initial session, the agent initiates communication with the management infrastructure in two circumstances:

First, as a maintenance task that runs daily at a time that the user can configure on the client. The activities performed during these maintenance sessions focus on reporting updated hardware information to the management infrastructure, applying changes to the settings policies for the device, reporting compliance back to the management infrastructure, and applying app updates to LOB apps, or retrying any previously failed LOB app installations initiated from the SSP.
Secondly, the agent will communicate with the management infrastructure anytime the user initiates an app installation from the SSP. These user-initiated sessions are solely focused on app installation and do not perform the maintenance and management activities described in the first case.

Regardless of whether a session is initiated automatically by a scheduled maintenance task or manually by the user, the WOA management client continues to behave well relative to the state of the battery on the device and its current network conditions.

Settings policy management

As already discussed, access to LOB apps typically requires systems to comply with basic security and data protection policies. From the management infrastructure, the IT admin is able to configure a set of policies that we believe are the most critical to give IT the assurances they need without seriously affecting the users experience with their device, including:

Allow Convenience Logon
Maximum Failed Password Attempts
Maximum Inactivity Time Lock
Minimum Device Password Complex Characters
Minimum Password Length
Password Enabled
Password Expiration
Password History

Although our new WOA management client can only connect with a single management infrastructure at a time, we may decide to add other policy sources before we release Windows 8 and so weve architected the policy system to handle this. In the case where more than one policy exists for the same Windows 8 device, the policies will be merged and the most restrictive configuration will be selected for each. This resultant policy will apply to every administrative user on the Windows 8 device and every standard user with an Exchange account configured. Standard users who do not have an Exchange account will not be subject to the policy, but Windows 8 already restricts those users from accessing data in other users profiles and from privileged locations, thereby automatically protecting your corporate data.

In addition to the configurable policies described above, the agent can also be used to automatically configure a VPN profile for the user, so that WOA devices easily connect to a corporate network without requiring any user action. Finally, the agent can also monitor and report on compliance of WOA devices for the following:

Drive Encryption Status
Auto Update Status
Antivirus Status
AntiSpyWare Status

Leveraging this compliance information, IT admins can more effectively control access to corporate resources if a device is determined to be at risk. Yet once again, the users basic experience with the device is left intact and their personal privacy is maintained.

Before we move on, lets consider a couple of the policies listed above and how they practically affect a Windows 8 system. First, well look at Allow Convenience Logon. Windows 8 offers users convenience login features, like biometric login or the [url=http://blogs.msdn.com/b/b8/archive/2011/12/16/signing-in-with-a-picture-password.aspx" target="_blank">picture password feature. These options maintain a high level of security for Windows 8 devices, while solving one of the biggest headaches for users and IT alike: forgetting your password. Yet some organizations may require additional time before they are ready to embrace these alternative logon methods, so the Allow Convenience Logon option lets IT manage when to allow convenience logins in their organization.

Secondly, lets look at how drive encryption and Maximum Failed Password Attempts work together. You probably know people whove picked up their smartphone only to find that the device has wiped itself after their young child was playing with it and inadvertently entered the wrong password repeatedly. Nothing so severe will happen with your Windows 8 devices, fortunately. Windows 8 provides strong data protection already out of the box. So, when a user exceeds the password entry threshold, Windows will instead cryptographically lock all encrypted volumes and reboot the device into the Windows 8 recovery console. If your device has been lost or stolen, this effectively renders the device unreadable. But if youre simply the victim of your young son or daughter trying to get to Angry Birds while your device is locked, you can easily recover with the use of a recovery key that Windows 8 can automatically store on your behalf in your SkyDrive account. This way, you are able to get back up and running without enduring a lengthy wait to re-install all of your apps and copy down all of your data.

LOB app management

The features weve covered so far are obviously focused more on the mechanics of the management client and infrastructure along with the needs of the IT admin, but ultimately the entire solution exists to benefit the end user by enabling access to their LOB apps. Without such a benefit there's little reason a user would go through the trouble of using the enterprise management infrastructure. So lets dig deeper into LOB app delivery on the WOA platform.

In our previous blog post about WOA, we told you that consumers obtain all software... through the Windows Store and Microsoft Update or Windows Update. Now, with the addition of the WOA management client, were adding a fourth trusted source of software for the WOA platform. As mentioned, the Metro style self-service portal app, or SSP, is the day-to-day interface for the corporate user to access their management infrastructure. Here they can browse to discover LOB apps that have been made available to them by the IT admin. There are actually four different types of apps that IT can publish for users in the SSP:

Internally-developed Metro style apps that are not published in the Windows Store
Apps produced by independent software vendors that are licensed to the organization for internal distribution
Web links that launch websites and web-based apps directly in the browser
Links to app listings in the Windows Store. This is a convenient way for IT to make users aware of useful business apps that are publicly available.

Since the user specified his or her corporate credentials as part of the initial connection with the management infrastructure, the IT admin can then specify which apps are published to each user individually, based on the users AD domain user account, or as a member of AD user groups. As a result, the user only sees those apps that are applicable to them in the SSP.

[url=http://blogs.msdn.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-01-29-43-metablogapi/0827.Fig4_5F00_192C1C50.png" target="_blank">http://blogs.msdn.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-01-29-43-metablogapi/5621.Fig4_5F00_thumb_5F00_1FDF25D3.png

Browsing for LOB apps in the self-service portal (SSP) for a fictional company called Woodgrove

NOTE: This screenshot shows an early prototype of the SSP and may not reflect the final product.

Before any LOB apps can be delivered through the management infrastructure, there are two things that happen on the client. First, an activation key is issued by the management infrastructure and applied to the WOA device to allow the agent to install apps. Second, any certificates used to sign the LOB apps must be added to the certificate store on the device. In most cases, both the activation key and the root certificates are automatically applied during the first session after establishing the connection with the management infrastructure. Otherwise, they are automatically deployed during a subsequent session after the IT admin has turned on the feature in the management infrastructure.

When the user chooses to install an app from the SSP, the request is sent to the management infrastructure and a download link is provided to the agent. The agent then downloads the app, verifies the validity of the content, checks the signature, and installs the app. All of this typically occurs within seconds and is generally invisible to the user. In the event that an error occurs during any part of this process (e.g. the location of the content is unavailable), the agent queues the app for a retry during its next regularly scheduled maintenance session. In either case, the agent reports the state of the installation back to the management infrastructure.

[url=http://blogs.msdn.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-01-29-43-metablogapi/2072.Fig5_5F00_31BBB9A0.png" target="_blank">http://blogs.msdn.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-01-29-43-metablogapi/2480.Fig5_5F00_thumb_5F00_7185A025.png

The details page of an app in the SSP, where the user can initiate installation

NOTE: This screenshot shows an early prototype of the SSP, and may not reflect the final product.

As part of its regular maintenance sessions, the agent will inventory which LOB apps are currently installed and report that information back to the management infrastructure so the IT admin can effectively manage their LOB apps. Only Metro-style apps that were installed via the SSP and the management client are included in this inventory from a WOA device. Apps installed from the Windows Store are never reported as part of the inventory.

Anytime the IT admin publishes an update for an app that has been installed on a WOA device, the agent will automatically download and install the update during its next regular maintenance session.

Disconnecting from the management infrastructure

Finally, lets look at how to disconnect a device from the management infrastructure. Disconnecting may be initiated either locally by the user or remotely by the IT admin. User-initiated disconnection is performed much like the initial connection, and is initiated from the same location in the Control Panel. Users may choose to disconnect for any number of reasons, including leaving the company or getting a new device and no longer needing access to their LOB apps on the old device. When an admin initiates a disconnection, the agent performs the disconnection during its next regular maintenance session. Admins may choose to disconnect a users device after theyve left the company or because the device is regularly failing to comply with the organizations security settings policy.

During disconnection, the agent does the following:

Removes the activation key that allowed the agent to install LOB apps. Once removed, any Metro style apps that were installed via the SSP and management client are deactivated. Note, however, that the apps are not automatically removed from the device, but they can no longer be launched and the user is no longer able to install additional LOB apps.
Removes any certificates that the agent has provisioned.
Ceases enforcement of the settings policies that the management infrastructure has applied.
Reports successful deactivation to the management infrastructure if the admin initiated the process.
Removes the agent configuration, including the scheduled maintenance task. Once completed, the agent remains dormant unless the user reconnects it to the management infrastructure.

Summary

Given the trend towards consumerization of IT and our introduction of WOA with Windows 8, we wanted to rethink the way systems management is done. We worked to strike a balance between the sometimes competing needs of IT admins and the consumer who uses the device on a day-to-day basis. With the new WOA management client connecting to a management infrastructure in the cloud, we believe weve accomplished those goals, and we hope youll agree when you see it all in action.

-- Jeffrey Sutherland