Workspace ONE: Migrating to the Cloud

Having traditionally worked with large Enterprise and Global accounts, it’s often that I begin an engagement designing and deploying an on-premises Workspace ONE environment, but end with a SaaS migration. Three key reasons why you might find yourself with the same desire:

  1. Few organizations have successfully organized people and process around a tool such as Workspace ONE. It integrates with several unrelated, complex enterprise services, and carries its own demand for maintenance that comes with a high cost for proficiency.
  2. Deployed with best-practices in mind, Workspace ONE is a critical slice of infrastructure powering your presentation layer on all end-user devices. Downtime is more than noticeable in your ticket queues, and if extended, can quickly become a barrier to workforce productivity for an otherwise ordinary day.
  3. Many of the more recent Workspace ONE micro-services, such as Hub Services, are “SaaS first”; meaning, some of the new toys are only available for SaaS tenants.

Bonus: I’ve seen an overwhelming surge in customers now interested in migrating to the VMware SaaS platform in response to COVID-19. The business reason driving such an exercise is two-fold:

  1. Customers need a vehicle to serve up their digital workspace on a silver platter for remote employees. Never has the demand for mobile, flexible work product capability been as important to the employee as today.
  2. Business continuity. Managing an on-premises Workspace ONE platform is a full-time job and quickly becomes the focal point of end-user impact should an unplanned outage occur.

What we’ll cover in this post is the logistics of migrating to VMware’s Workspace ONE SaaS environments, what you can expect for both your administrators and end-users during the move, and how you can use this exercise to accelerate your adoption of the new services that will be available in your new environment. That’s right, we’re accelerating the delivery of new functionality during the move, not slowing down. Migration isn’t as daunting of a task as it seems, and as such, shouldn’t necessitate the need for focusing solely on the migration itself rather than cleaning house and unwrapping the new toys.

Where We’re Coming From

Let’s construct a hypothetical architecture that I believe represents most enterprise, on-premises Workspace ONE deployments today. It consists of four major components:

  1. Primary IdP – The autonomous system where your federation to external Service Providers is maintained. This could be ADFS, PingFederate, Okta, Azure AD, etc
  2. Three-Node WS1 Access Cluster – This is the existing Workspace ONE Access on-premises environment that is the end-user presentation layer and, at a minimum, mobile device authentication broker (Mobile SSO + UEM Device Compliance)
  3. Two-by-Four WS1 UEM Environment – Each component of UEM is deployed in pairs for HA, namely Console and Device Services. This can largely vary based on your environmental sizing guidance
  4. Active Directory – The backbone of what is integrated with both your primary IdP and Workspace ONE

Looking at the above from a graphical perspective:

*Note – DR isn’t included in the above, but will definitely be present in production architectures.

Now, looking at it from an end user perspective:

This architecture enables what we affectionately refer to as a “two-app experience” (or a “two-app flow”), which defines Intelligent Hub as the anchor app enabling the MDM channel, and the Workspace ONE App serving as the unified app catalog for the end user. There are several different permutations of where the catalog is presented, all of which leading to a fragmented user experience. So, how do we eliminate this fragmentation and on-premises footprint? We migrate to SaaS and terminate the on-premises environment!

Planning

This post will primarily focus on the migration of Workspace ONE Access from on-premises to SaaS in a maximum of two phases. Workspace ONE UEM is largely out of scope because of the simple mechanism to migrate which is covered in further detail below. Take note that most of the migration steps can, and should, be performed well ahead of the migration.

Let’s define the phases of migration. There are at most two, with the second phase optional depending on your current Workspace ONE architecture. The example architecture above, meant to be indicative of what I see most in the enterprise, would not require a second phase.

Phase 0

This isn’t really a “phase” of sorts, but rather a recommendation to migrate Workspace ONE UEM to SaaS before any other component. The process is entirely white-gloved by both VMware Professional Services and SaaS Operations teams, and at a macro level involves:

  1. Take an outage and backup the UEM database
  2. Provide the database backup to VMware SaaS Ops
  3. CNAME existing site URLs to new SaaS tenant URLs
  4. Provide SSL certificate for your custom domain name to VMware
  5. Bring UEM core services online in SaaS
  6. Redeploy AirWatch Cloud Connectors with new Secure Channel Certificate

Phase 1

Phase 1 begins to migrate the user experience to the SaaS environment, swiftly delivering Hub Services functionality to all devices. Users are migrated to the “one-app experience” discussed above, with the notable exception of Windows 10 which, as of this writing, does not support Hub Services in the native Win32 Intelligent Hub app (further discussed below). The sequence of execution is:

  1. Complete preparations (IdP federation, entitlement creation, Mobile SSO, directory integration, branding etc)
  2. Reconfigure Workspace ONE Access integration in UEM to link to new SaaS tenant
  3. Reconfigure Workspace ONE Access integration in VMware Horizon providing SAML authentication (if required)
  4. Switch WS1 UEM ‘Source of Authentication’ to Workspace ONE Access
  5. Remove Workspace ONE app from all devices
  6. Re-provision Workspace ONE App to Windows 10 devices (resets URL to new tenant)

If the architecture you’re coming from includes Workspace ONE Access as your primary identity provider (that is, all enterprise service providers are federated directly to Workspace ONE Access), then phase 1 completion is depicted as:

Notice that the on-premises environment remains temporarily in support of phase 2 (the migration of your primary federations to the new environment). The methods discussed below allow us to leverage the existing on-premises federation in the new SaaS tenant, yet migrate the presentation layer in a manner that is transparent to the end user (more details on this in the Phase 2 discussion).

If, however, your architecture more closely aligns to the hypothetical use case defined above, your migration is complete and depicted as the ‘Final Architecture’ below; go ahead and skip to that section of the post.

Note: Some pre-existing devices might be required to re-enroll or re-register with Workspace ONE in order to complete phase 1 cutover. Specifically, Android Enterprise Direct Enrolled with Workspace ONE App will need to re-enroll with Intelligent Hub, and all mobile devices Workspace ONE App Registered will be required to re-register with Intelligent Hub. See KB2960141 for iOS and KB2960140 for Android that discusses these topics in further detail.

Phase 2 (Optional)

Phase 2 is solely meant to be a runway for re-federating service providers from the on-premises Workspace ONE Access environment to the new SaaS tenant if your enterprise is using WS1 Access as a primary IdP. If not, then as mentioned above, this phase is unnecessary.

The convenience of migrating the presentation layer first is that the invasive activity of federation with the vast number of service providers you might have in your ecosystem is silent to the end user. The existing on-premises environment serves as an administrative life boat in the interim, and the user simply sees a new application in the catalog for each app that is migrated over a timeline that fits your IT delivery schedule. Macro level steps of execution during this phase:

  1. Service provider is re-federated to the new Workspace ONE Access SaaS tenant by metadata exchange
  2. New application is entitled in the catalog to the end users
  3. Existing ‘App source’ application link (discussed further below) is removed from the catalog

These three steps are repeated for each application in your environment and are not time-sensitive for delivery since users are able to access these applications in phase 1.

Final Cutover

The last step in the migration is decommissioning the legacy on-premises environment(s). Once you are certain that all applications have been migrated/federated to the new SaaS environment, shutdown the Workspace ONE Access SVAs and corresponding Connectors to decommission the environment. One final recommendation I usually provide:

  1. Alter the existing on-premises Workspace ONE Access FQDN to serve as a vanity URL for the SaaS tenant – e.g. “my.example.com”

Converting the virtual server for the vanity URL involves creating a rewrite rule that issues a 301 redirect to the client with URI rewrite. For example, an F5 LTM iRule might look like:

when HTTP_REQUEST { 
    HTTP::redirect "https://{tenant}.workspaceoneaccess.com[HTTP::uri]" 
}

This closes the loop for anyone who might have still been accessing the legacy catalog either by bookmark or otherwise, and serves as a nice sign-post vanity URL moving forward.

Final architecture for a one-phase migration, or in other words, a primary IdP other than Workspace ONE Access:

Final architecture for a two-phase migration, or in other words, Workspace ONE Access as the primary IdP:

Preparations

Moving on to preparations, let’s begin focusing on the planned activities we can complete from above prior to the phase 1 cutover. These tasks will slightly deviate depending on if you’re migrating in one or two phases, but largely involve:

  1. Build out configuration in WS1 Access SaaS tenant (See Pre-Reqs below)
  2. Export/Import catalog applications from on-premises WS1 Access environment into WS1 Access SaaS tenant
  3. Sync VMware Horizon/Horizon Cloud entitlements into WS1 Access SaaS tenant (if Horizon is deployed)
  4. Update Mobile SSO configuration profiles
  5. Phase 2 Only: Establish SaaS tenant as 3rd party IdP in on-premises environment

Time to build in this sequence…

Pre-Requisites

  1. Workspace ONE UEM -> Migrated to Dedicated SaaS
  2. Workspace ONE Access (SaaS Tenant)
    • Connectors deployed
    • Directory created with users and groups necessary
    • 3rd Party IdPs federated (if required)
    • Authentication methods configured and included in Access Policies (sans UEM Device Compliance)
    • Hub Services branding and tab configuration (Hub Configuration)
  3. VMware Horizon (On-Prem or Cloud)
    • Workspace ONE Access SaaS tenant added as SAML authenticator in Connection servers (or tenant appliance) for pod

It’s quite a few pre-reqs, but boiled down, it’s a greenfield build of your SaaS Access tenant minus the catalog items. This is what gives us the freedom to build in parallel without impacting users who, at this stage of migration, are still accessing the on-premises environment. It also gives us the flexibility to minimize the number of changes that need to occur at phase 1 cutover which marginalizes the risk of unexpected outcomes.

Catalog Entitlements

Catalog entitlements should mirror the presentation layer already defined in the on-premises WS1 Access environment, and should include web apps, native apps and Horizon entitlements. This way, even with a user experience migration, the look and feel of what’s available should be familiar for the end user.

We’ll focus on web apps here, as native apps will be addressed in the cutover and virtual apps follow a greenfield configuration flow. Use the Horizon entitlements documentation for instructions on how to sync your virtual infrastructure to WS1 Access.

1. In the WS1 Access SaaS tenant admin UI, navigate to Catalog -> Web Apps and choose ‘Settings’:

2. Select ‘Application Sources’, then choose an IdP from the list to begin the configuration:

Note: These IdP names are not specific to any other ancillary configuration with the exception of ‘OKTA’. If you are migrating in two phases, pick one from the list other than ‘OKTA’. If you are migrating in one phase, choose the appropriate 3rd party IdP. Then, proceed to the next step.

3. Either manually configure the SAML metadata information in the following configuration screens, or upload/provide an XML file/URL to automatically populate the metadata:

Note: If you are migrating in two phases, this metadata endpoint is https://{on_prem_fqdn}/SAAS/API/1.0/GET/metadata/sp.xml

4. Select ‘Next’ -> ‘Next’ -> ‘Save’, then select the ‘X’ in the top right to return to the Web App Catalog main menu:

5. Select ‘New’ to create a new App Source Application, then provide an application name and icon in the resulting configuration screen:

6. Select ‘Next’, then change the ‘Authentication Type’ to ‘{IdP} Application Source’, where {IdP} equals the value you chose in step 2:

7. In the target URL field, define the Launch URL of the corresponding application in the primary IdP, then select ‘Next’:

Note: If you are migrating in two phases, this URL will be structured as https://{on_prem_fqdn}:443/SAAS/API/1.0/GET/apps/launch/app/{app_guid}. You can find this link by navigating to Catalog -> Web Apps in the on-premises WS1 Access environment, then selecting the application name hyperlink which presents you with the app ‘Definition’.

8. Assign the desired access policy for the application:

9. Select ‘Next’, then ‘Save and Assign’:

Note: If you are migrating in two phases, search for group ‘ALL USERS’ in the ‘Assign’ configuration screen. This is because the entitlement (AuthZ) is controlled in the on-premises WS1 Access environment temporarily prior to phase 2 cutover. Otherwise, assign the application to the appropriate users/groups for entitlement.

10. Select ‘Save’, then confirm the application is now listed in the main Web App configuration page of the Catalog menu.

Perform steps 5-10 for each web application that should be created to mirror app availability in the existing WS1 Access on-premises environment. For those who are migrating in one phase, you can use my colleague Chris Halstead’s Fling for automating the majority of this process.

Mobile SSO Profiles

iOS and Android mobile SSO configuration profiles need to be updated to include the new WS1 Access SaaS tenant URL in the trigger condition. This will impact existing devices by re-publishing the profile, but should have minimal impact on users and is safe to run during business hours.

1. In Workspace ONE UEM, navigate to your iOS Mobile SSO Profile and update the URLs applicable for SSO:

2. While still in UEM, navigate to Device Traffic Rules for VMware Tunnel (where Android SSO is configured) and add a ‘PROXY’ rule that proxies requests for SSO available apps from the new WS1 Access SaaS tenant {URL} to certproxy.{saas_environment}.com:5262:

Tenant Federation Trust (Phase 2 Only)

As the heading suggests, this is only required if you are migrating in two phases; that is, Workspace ONE Access is your primary IdP. If this is not the case, skip this section and proceed to ‘Cutover’.

Since we intend to maintain primary federation in the on-premises WS1 Access environment temporarily for phase 1, we need to trust user authentication sourced from the new SaaS tenant. This exercise is nothing more than 3rd party IdP trust over the SAML protocol between the two WS1 Access environments.

1. In the on-premises WS1 Access admin UI, select ‘Identity & Access Management’ -> ‘Identity Providers’, then select ‘Add Identity Provider’ -> ‘Create Third Party IDP’:

2. Provide an IdP name (free text), then copy the SaaS tenant IdP metadata URL into the text box and select ‘Process IdP Metadata’:

Note: You can find this link by navigating to Catalog -> Web Apps -> Settings in the SaaS WS1 Access environment, then selecting ‘SAML Metadata’ -> ‘Copy URL’ for the IdP Metadata. The metadata endpoint is https://{saas_tenant_fqdn}/SAAS/API/1.0/GET/metadata/idp.xml

3. Define ‘Name ID policy in SAML Request’ as ‘urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified’, then select the appropriate directory and network ranges relevant for this 3rd party IdP:

4. Define the ‘Authentication Method’ name as ‘saas-authn’, and the ‘SAML Context’ as ‘urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport’:

5. Select ‘Enable’ for Single Sign-Out Configuration, and define the ‘IdP Sign-out URL’ as ‘https://{saas_tenant_fqdn}/SAAS/auth/logout’:

6. Lastly, select ‘Add’ and confirm the newly created IdP is listed in the ‘Identity Providers’ main configuration screen:

Cutover

With preparations complete, it’s time to perform the cutover. The following steps for phase 1 cutover will be end user facing, so perform these with caution during an approved change window.

Checkpoint

As we’ve all heard at least once in our lives, ‘measure twice and cut once’. Let’s take a peek at the experience shift our users will see when consuming Hub Services from the newly minted WS1 Access tenant:

This is an effective validation exercise that can be performed prior to executing the actual cutover. From what we can see on the right, the new Catalog UI and other Hub Services tabs appear to be in order and ready for migration.

Phase 1

Per the plan, we’re executing two maneuvers in this phase: one is migrating the user to the WS1 Access SaaS environment, and the second is activating Hub Services.

1. In Workspace ONE UEM, navigate to ‘Groups & Settings’ -> ‘Configurations’, then search for ‘Hub Services’ and select ‘Intelligent Hub’:

2. Select ‘Reconfigure’ for ‘Hub Services URL’, which currently shows the URL of the on-premises WS1 Access environment:

3. Select ‘Continue’ on the ‘Configuration Overwrite’ warning screen:

4. Provide the WS1 Access SaaS tenant URL and administrative credentials on the ‘Reconfigure Hub Services’ configuration screen, then select ‘Test Connection’:

Note: The administrative credential should be a temporary System Domain credential (i.e. local account) in the WS1 Access tenant.

5. Select ‘Save’ after a successful connection test:

6. Confirm that the WS1 Access SaaS tenant URL is defined next to ‘Hub Services URL’, then select ‘Configure’ for the ‘Source of Authentication’ card:

7. Select ‘Workspace ONE Access’ for the ‘Source of Authentication for Intelligent Hub’ configuration item, then select ‘Save’:

8. Back in the Hub Services configuration menu from step 1, select ‘Configure’ for the ‘Management Mode’ card:

9. If Workspace ONE ‘Registered’ mode (i.e. ‘MAM’) is a use case for your environment, select ‘Enabled’ for iOS and/or Android platforms and choose a Smart Group allowed to register, or optionally, allow all devices in the OG to register:

Lastly, delete the Workspace ONE App from all devices since the unified app catalog is now distributed via Intelligent Hub by default. For Windows 10 devices, re-publish the Workspace ONE App so that the updated WS1 Access URL is used to populate catalog items. It is expected that in time, Windows 10 will support full Hub Services using the Intelligent Hub app.

As final steps, we need to make small configuration changes in the WS1 Access access policies, as well as the authentication settings in VMware Horizon (if applicable). I won’t call these out specifically as they are well documented, but will provide links for general documentation as a reference:

  • Workspace ONE Access SaaS Tenant
    • Access policies should be updated to include ‘Device Compliance (with Workspace ONE UEM)’ now that UEM integration has been completed. This authentication method should be coupled with any policy rule where Mobile SSO for iOS or Android have been defined
  • VMware Horizon Environment
    • If Workspace ONE Mode is enforced for the Pod, update the ‘Workspace ONE server hostname’ to reflect the new WS1 Access SaaS tenant URL. (e.g. https://{customer}.workspaceonaccess.com)

If you are migrating to SaaS in one phase, skip ‘Phase 2 (If Required)’ and proceed directly to ‘Final Cutover’. If migrating in two phases, we must also update all access policies in the Workspace ONE Access on-premises environment to only include the ‘saas-authn’ authentication method we created above in step 4 of ‘Tenant Federation Trust’. This is because authentication is now controlled by our SaaS tenant:

10. In the on-premises WS1 Access environment, navigate to ‘Identity & Access Management’ -> ‘Policies’, then select each policy to edit that is required:

Phase 2 (If Required)

Phase 2 is all about converting your ‘App Source’ targets created in step 5-10 of ‘Catalog Entitlements’ into SAML apps that represent a re-federation of the service provider from the on-premises WS1 Access environment to the SaaS tenant. Remember, this is only required if WS1 Access is your primary IdP. As you re-federate applications and add them as SAML apps to the SaaS tenant, delete the corresponding ‘App Source’ target that references the legacy federation in the on-premises environment. The Application Source created in step 2 of ‘Catalog Entitlements’ can be deleted entirely once all SAML app federations have been migrated to SaaS.

Final Cutover

Two final steps remain now that our migration to SaaS WS1 Access is complete. First, as recommended in the plan, you can use your legacy on-premises FQDN as a vanity URL for the SaaS tenant. Simply create an iRule, similar to the one defined above, that issues a 301 with URI rewrite. Any users who attempt to connect to the legacy on-prem environment will be redirected to the new tenant catalog.

Lastly, for the fun part, you can nuke the on-premises WS1 Access environment!

Outcome

Simple administrative management, rock-solid resiliency, and the latest and greatest Workspace ONE functionality are all things you can now say you’ve delivered to your end user. In times of crisis such as where we find ourselves with COVID-19, delivering a consumer-simple approach to remotely consuming all things enterprise is paramount for productivity, continuity, and far more importantly, employee experience.

Here’s a quick look at the end user’s view of the new Hub Services experience you’ve migrated to:

Tags: , , , , ,