How to build your Workspace ONE Sandbox

Workspace ONE is incredibly powerful. But with so many features and functions, its no wonder people can get lost when working out where to start on configuring it to test with your scenarios in your environment.

As part of VMware Testdrive, other than getting access to a pre-configured testing environment and walkthroughs you also get a full fledged trial environment we refer to as a Sandbox.


This has all the capabilities of Workspace ONE where you can integrate it with all services to test it in your environment with real users and real devices.

So, this is where this guide comes in. Even I struggle to explain or give a place for my customers to go for all they need to get started. I'll add to the below information over time but this will be enough to get you started with Workspace ONE as part of a pilot or proof of concept.

Configuring Mobile SSO for iOS Devices in Workspace ONE

One of big differentiators we have with Workspace ONE is ability to use MobileSSO to drastically improve security and the user experience.

MobileSSO with Workspace ONE leverages certificates deployed to devices to seamlessly sign the user into the Workspace ONE Intelligent Hub and any federated SaaS services.

This solution requires both Workspace ONE UEM (to deploy and manage the lifecycle of the certificates) and Workspace ONE Access (to challenge the device for the certificate and authenticate the user). On iOS MobileSSO technically uses Kerberos by validating the certificate on the device and generating a Kerberos token the device can then present back for authentication.

In this post I'll discuss how to configure Workspace ONE Access for iOS MobileSSO and how to create a profile in Workspace ONE UEM to deploy the required certificate and approve the domains and applications that can use it.

Basics of Device Profiles in Workspace ONE UEM

Profiles are configurations that are sent to our devices in Workspace ONE UEM to configure our devices.

They're very small in size usually, and contain information that the device Operating System can understand to effect changes.

The important part to note here is that we are typically bound by what the vendor makes available via their APIs as to what we can configure. To put it more simply, the capability to make changes to settings needs to be made available by the vendor - then we can push a profile to configure it.

Seeing our environment is configured to enroll iOS devices, Android Enterprise Devices, and Windows 10 devices I'll cover some basics of profiles that are relevant to all.

Configuring Workspace ONE UEM for Windows 10 enrollment

There are a few configuration and settings changes that we need to do to make our environment able to support Windows 10 device management.

Given we've already set up our email domain for email based enrollment on iOS and Android, we now need to configure Windows Auto-Discovery Services (WADS) which allows us to use email addresses for Windows Enrollment.

Typically you will want to use the Cloud-Hosted version of WADS and this is what we'll cover in this post.

Setting up email based autodiscovery enrollment in Workspace ONE UEM

What is something that all users know? OK, what's something they should know.

Yes, it's their email address.

When we configure email based enrollment, it allows users to enter their email address during enrollment and it will autodiscover their correct environment.

It's pretty straightforward, but I wanted to make sure it was documented because its actually required for Windows enrollment.

How to configure Workspace ONE UEM to enable Android Enterprise device management

Setting up Android Enterprise device enrollment got a lot easier about a year ago. Previously you needed to create a full blown GSuite deployment, do a heap of DNS stuff and certificates.

Now its as simple as creating a Gmail account, entering it into the Workspace ONE Console and approving some applications.

 That's not to say that the Gsuite method shouldn't be used - there are definite scenarios where this is preferred - but for testing and POC purposes (any many others) using the Gmail method is perfectly fine.

Generating an Apple Push Notifications Certificate to enroll and manage Apple Devices

Most of the time it seems like magic that Apple devices 'just work'. However, there is one fundamental service that makes this happen - the Apple Push Notification Service. This is a set of services that Apple use (and that Apple devices leverage) to communicate with MDM, App Store, Email infrastructure etc.

The part that Mobility Administrators need to do to utilise this in Workspace ONE is generate their own Apple Push Notification Services certificate to secure traffic and communicate with Apple.

It essentially allows the entire mobility infrastructure to communicate freely in a "push" fashion rather than on-demand or schedule.

Now the important part here is that this certificate needs to be renewed every 12 months. I say important because if you don't renew it and let it expire, you have to reenroll every Apple device (manually) for them to function properly again.

Enough chit-chat, lets generate an APNs certificate and upload it to the Workspace ONE UEM Console.