Just recently a lot of the buzz in the end user computing world has been around moving to unified endpoint management. As with many concepts in IT, unified endpoint management, or UEM for short, is defined more by marketing departments than any rigid scientific or legal method. It is the latest step in a journey that endpoint device management has been on for a while, namely the convergence of client management tools (CMT), mobile device management (MDM) and enterprise mobility management (EMM) toolsets.
The challenge is that the definition of UEM is governed by the participants of the conversation. The definition from Wikipedia (derived from Gartner) is probably the best that I have seen:
“Unified Endpoint Management is a class of software tools that provide a single management interface for mobile, PC and other devices. It is an evolution of, and replacement for, mobile device management (MDM) and enterprise mobility management (EMM) and client management tools.”
The Gartner paper is behind their paywall but VMware has made the entire Magic Quadrant paper available for download for free.
VMware Workspace ONE | Source Gartner, June 2018
The Unified Endpoint Management definition above shows the convergence of the toolsets used for mobile devices (typically MacOS, iOS and Android) with those used for Windows. This is a reflection both of the growing importance of the first category of devices within the workplace and the move by Microsoft to include the Open Mobile Alliance – Device Management protocol within Windows 10.
Furthermore, the UEM toolsets are typically cloud-hosted, although some have on-premises variants for those more cloud-averse organisations. This cloud hosting delivers two key benefits:
- There is no infrastructure to design and maintain. The software vendor provides you with a tenant and keeps adding patches and new features to it.
- These days, devices work outside of the corporate network more often than inside. A cloud-hosted solution means that devices can be managed wherever they are operated without relying on the users connecting to the mothership via VPN.
Organisations have typically been running multiple tools to address these device communities, but this adds complexity to what is already a complex environment. The goal of UEM is to create one tool to rule all the device communities.
The question that needs to be answered is:
Has Unified Endpoint Management reached its Digital Photography moment yet?
This may seem like an obscure question, but reading this blog by Steven Sinofsky caused me to take stock of my mindset regarding UEM. He used the example of the transition from silver halide film to digital photography. In the blog he described the technical buzz saw that devotees of the incumbent technology use to dismantle the challenger technology based on very specific and clearly defined limitations. He argued that over time, the challenger technology closed that gap. In addition, whole new workflows were invented that changed the face of photography.
I have been guilty of wielding that technical buzz saw regarding the mainstream UEM toolsets, targeting what I perceive are their shortcomings:
- Inability to deliver a bare-metal build
- Deployment of Win32 applications
- Transfer of work from deployment engineers to non-IT staff
However, having read Steven’s post I revisited my thinking, looking at things from the other side of the argument.
Inability to Deliver a Bare-metal Build
UEM tools recognise that every device is shipped from its vendor with a perfectly good operating system including drivers for the subcomponents. We do not need to deploy one before we use the device, we simply need to configure the current one to meet our needs. This is the thinking behind Microsoft’s Autopilot process.
You may be thinking that Windows devices are often shipped with trial versions of software as part of the factory installed image and that you do not want that adding to the support complexity. Therefore, Dell Configuration Services recommends our “Generic Image” option, without any trial software, in conjunction with Microsoft Autopilot registration. This provides control over the version of Windows 10 installed and ensures a known clean base to begin UEM control from.
Those with one hand still on the buzz saw will point out that most vendor support processes will replace a failed hard drive with a new “clean” drive without an Operating System. However, as Sinofsky says, “Most problems are solved by not doing it the old way”.
Three mitigations come to mind:
- The move to thinner, lighter devices has driven the proliferation of solid state storage solutions which are less likely to fail.
- Organisations can change their internal support processes to include a pool of devices to swap with any failed devices, thereby maintaining user productivity. The failed device is repaired and returned to the swap pool.
- Once critical mass is achieved, vendor-support processes may move from a repair to a swap out policy.
Addressing this inability to deliver a bare-metal build is unlikely to be resolved by the software and is therefore one area where a mindset change may be the best route.
Deployment of Win32 Applications
This highlights how the march of technical development erodes the arguments presented by the devotees of the incumbent technology. The mainstream tools at the heart of UEM are typically mobile device management tools which were designed to deliver applications to mobile operating systems (Android and iOS).
The design specification would therefore have provided for delivering relatively small applications (a few hundred megabytes) which are simple in nature and without the need for dependency checking. Delivering Win32 applications to Windows 10 devices requires a more sophisticated capability. This capability is evolving, with the two vendors that Gartner sees as the leaders (Microsoft and VMware) in a race to bring this capability to market.
VMware was first to market with the ability to deliver Win32 apps. Their capability can deploy msi, exe and zip files and differentiates between applications and their dependencies. Additionally, VMware has released their AirLift connector which connects Configuration Manager (ConfigMgr) to your Workspace ONE tenant and enables you to export the applications from ConfigMgr and import them into Workspace ONE without the need for repackaging.
This approach makes it easy to transfer the content and assignment metadata into Workspace ONE and will help customers who wish to move away from ConfigMgr in the long term. Based on my customer experience, ConfigMgr is the most widely deployed toolset, however, we are increasingly seeing customers with Ivanti LANDesk and IBM BigFix who would like to have a similar capability to help them move. It is to be hoped that the Workspace ONE engineering team can create a similar capability to assist them.
There is an additional benefit to following the Airlift enabled route. Once the applications have been moved into Workspace ONE, Dell Configuration Services offers Factory Provisioning services. I have described this in more detail in a previous post entitled, Windows 10 Migration: Best Practices for Making a User’s First Impression Great. In summary, this enables our customers to provide us with bundles of applications, including Win32 apps, for loading in our factory, thereby streamlining the deployment of their new devices using Workspace ONE.
Microsoft announced at Ignite (September) 2018 that their capability would shortly be made available as part of a public preview. At the time of writing, this facility is still in public preview and being rolled out to Intune tenants. Applications need to be converted from their current format to the new .intunewin format. This process is enabled using an upload prep tool but seems to involve significant manual data entry.
Microsoft may well feel that they have this area covered by ConfigMgr which has been the mainstay of application deployment for many customers for years. Indeed, part of their strategy is to use Intune to automatically deploy the ConfigMgr client. This gets around the limitation that a user with standard permissions would not be able to deploy the ConfigMgr client themselves.
This approach then means that the device is now in a state of dual or co-management where control is achieved using two tools. The working premise is that these tools work in concert and provide a low risk approach to transitioning from ConfigMgr to Intune one workload at a time.
Over time, applications are moving from locally deployed to software as a service or web-based. As this happens, we reduce the reliance on Win32 applications and this problem diminishes.
Transfer of Work from Deployment Engineers to Non-IT Staff
This is the key challenge for me when trying to adopt the change mindset. For years we have been delivering fully built systems to our users to minimise their downtime. In part, I suspect that this was because we were catering for less technically trained users that we have today. It was also to cater for the fact that to meet security guidelines, users were given low privilege accounts which meant that they were prevented from completing the activities even if they were willing to do them.
The introduction of solutions such as Microsoft Autopilot mean that they no longer need high privilege accounts to do key tasks. However, devices are delivered to them with few if any applications included. As described in the Windows 10 Migration post, the deployment of applications to the device can take a while. In the past this was done on the build bench and so was hidden from the users as it was in what I call Engineer Time.
If application deployment is done after device receipt by the user, it is now in User Time. This has two implications:
- The device is not ready for use immediately, potentially preventing a user from working
- Simply transferring the work from the IT team to the users does not make it more cost effective
Let’s break each of those items apart and examine them.
Device Not Ready for Use Immediately
Most devices deployed using an Autopilot method today will be replacement devices, where an existing user is getting a new device. Traditionally, they have been asked to handover the old device on receipt of the new one. Using the applications pre-provisioning methods described above may be sufficient to ensure that the device is fully ready at handover. If there is some further time required, briefly delaying the return of the old device, will allow them to work on it whilst their new device finalises. This effectively negates the impact of the delay, as the user can login to their new device and allow processes to complete before relinquishing the legacy device.
Dell is investing heavily in technology and processes which will enable it to move more and more of this pre-provisioning work upstream into our factories. We are engaged with both Microsoft and VMware to look at ways to improve the day one experience of your colleagues by automating as many of the task involved in deployment as possible.
Where an existing device is being upgraded to Windows 10 from an earlier operating system, there are two approaches that will be used: In-place upgrade or wipe and load. An in-place upgrade simply updates the operating system and migrates the data and applications as is. There is no impact here.
Wipe and load upgrades require a bare-metal build process and therefore require a toolset such as ConfigMgr. It is now possible to create a task sequence to perform a wipe and reload process which then sets the device to use Autopilot when the device is handed back to the user, but if the device not being ready for the user is a consideration then this would not be the route to take. If performing a bare metal build, it is more likely that the device will be handed back by an engineer fully ready for the user.
Transferring the Work from IT to the Users
New technology often results in the adoption of new or changed working practices. Before computers became standard issue, firms employed banks of typists to turn a manager’s thoughts or dictated words into formal output. No doubt somebody pointed out that asking a manager to type their own documents was less cost effective than asking a typist to do so. However, time moved on and the user empowerment that came from avoiding the need to dictate the content, saw the widespread adoption of the new way of working.
We are on the cusp of a similar change in end user device deployment. My conversations with IT departments are increasingly focused on user empowerment rather than the IT team owning the tasks. Clearly, there are employees within the organisation who earn significantly more than the deployment engineers, but do they prefer being able to get the task done rather than organising a time to meet with an engineer?
There is no definitive answer here, some will want the job done for them whilst others just want to get the job done even if it means doing it themselves. In a way that sums up where we are with unified endpoint management as well.
Dell’s viewpoint is that the best experience comes not from moving work from deployment engineers to users but by increasingly automating the tasks we remove the need for human intervention entirely. The analogy we often use is the comparison between visiting your bank to withdraw cash. You can visit the human teller who will give you the full in person service or you can visit the automated teller (ATM) which for most of us is convenient and a better experience.
For some organisations, typically those with a highly mobile workforce, the scales are going to be tipped in favour of one of the UEM approaches. For those whom the pace of workforce transformation is a little slower, they may still be happier with the traditional methods for now but over time they will still find themselves drawn to UEM in the end.
The point is that there is an opportunity to try something new and see whether it has reached the tipping point for you. Are we at the point where the opportunities offered by the new tools and processes enable you to do things of higher value than the things that they currently cannot?
The UEM tools available today are not the whole story. They need to be combined with pre-provisioning and factory services to ensure that work is not simply transferred from one team to another but replaced by automation. This is where the Dell Technologies value comes in. Working with both Microsoft and VMware we are pioneering ways to automate the provisioning processes and drive the most value out of the shift to UEM.
As the focus shifts towards user experience in the ongoing battle to retain key staff, it is likely that organisations will look to deliver more user empowerment through a better understanding of their user environment. Dell EMC has developed a series of tools and techniques described in the free eBook, 4 Tools and Techniques to Create Change and Empower the Workforce with Personalized Experiences, to help you meet the needs of an ever more demanding workforce. Key to this approach is the development of user personas and a detailed knowledge of the user profile. All of this data feeds the UEM tools to make for a better initial experience.
If you are ready to ditch the silver halide film and join the digital workforce transformation, please feel free to contact your Dell EMC Sales Representative to discuss how we can help you.
The post Unified Endpoint Management: One Tool to Rule Them All? appeared first on InFocus Blog | Dell EMC Services.