Omnissa Access on-premises to cloud migration
On-premises to cloud migration overview
We created this guide to help you understand what it takes to move Omnissa Access from on-premises to the cloud. The steps also apply if you move from one cloud tenant to another. This guide helps you understand typical migration efforts and describes the necessary steps to plan and execute the migration. The primary goal of migrating to the cloud is to simplify and reduce the on-premises infrastructure footprint, thereby reducing the ongoing maintenance and added cost around the Omnissa Access services.
Moving Omnissa Access from on-premises to Omnissa Access Cloud environment helps you to:
- Reduce maintenance costs
- Reduce IT administration overhead
- Increase consistency and reliability of the Omnissa Access services
- Offer support for HA (High Availability) and scalability as the business grows
- Reduce OpEx/CapEx because of lower infrastructure costs
- Cloud delivery which is backed by a 99.9% uptime SLA (Service Level Agreement)
Audience
This tutorial is intended for IT professionals and Omnissa Workspace ONE administrators of existing production environments. Familiarity with Horizon, Active Directory, identity management, and directory services is assumed.
What is Omnissa Access as-a-service?
Omnissa Access as-a-service is a hosted (Cloud) environment that is a deployment option that Omnissa offers.
- Omnissa Access as-a-service addresses use cases around user and device authentication, SSO, and conditional access across several types of apps (for example applications could be either web or SAML) across the globe.
- Omnissa Access as-a-service is hosted on Amazon Web Services (AWS) in 9 locations around the world.
- US, Japan, Canada, Australia, Ireland, UK, Germany, India, and Singapore
- FedRAMP in the US
- Depending on enterprise customer deployment, usage requirements and the license purchased, an Omnissa Access Cloud tenant will be provisioned for the customer in the appropriate domain. (Note: Working with the respective account team, the customer can pre-determine the name of the Omnissa Access tenant.)
- For US, tenants are created under the workspaceair.com, workspaceoneaccess.com, or us1.wss.workspaceone.com domains.
- For GovCloud (US), tenants are created under the access.gc.workspaceone-gov.com domain.
- For EU, tenants are created under the ie.wss.workspaceone.com domain.
- For UK, tenants are created under the uk.wss.workspaceone.com domain.
- For Japan, tenants are created under the jp.wss.workspaceone.com domain.
- For Australia, tenants are created under the au.wss.workspaceone.com domain.
- For Canada, tenants are created under the ca.wss.workspaceone.com domain.
- For Germany, tenants are created under the de.wss.workspaceone.com domain.
- For India, tenants are created under the in.wss.workspaceone.com domain.
- For Singapore, tenants are created under the sg.wss.workspaceone.com domain.
- Unlike the on-premises environment, Omnissa Access as-a-service only needs outbound connectivity from the connector to communicate with the cloud services. Hence minimal network ports are open for maximum network security.
- Requests to port 80 by an Omnissa Access hosted tenant, redirects to port 443.
- 443 is not the only port used by the Cloud tenant. Kerberos authentication uses port 88 UDP. TCP and Android cert proxy use 5262.
- All user interactions in the Omnissa Access as-a-service environment are audited for compliance purposes.
- Customers have access to the audit logs which are kept for 90 days.
- Omnissa Access as-a-service offers support for user authentication using corporate account globally.
- Even though Omnissa Access is hosted, the connector for the directory server, which is the user store, is deployed on-premises. Omnissa Access from different geo locations can communicate with the same instance of the directory server and cater to the needs of the users globally if needed.
- Allows the user data to stay on-premises with only the required user attributes to be synchronized to the cloud. This allows operating in a hybrid model to maintain data security while keeping the maintenance and infrastructure costs low.
- Supports business continuity for end users to continue support for non-password-based authentication methods even if the on-premises connector(s) or the directory server is down. For example, certificate-based authentication is a non-password based option that does not depend on directory server/user store connectivity.
- Omnissa Access as-a-service offers high availability and elasticity for all tenants at all times.
- Offers Reliability, performance, and operational simplicity for Omnissa Access delivered in the cloud is backed by a 99.9% uptime SLA which is defined in the Service Level Agreement for Omnissa Access.
- Supports HA (High Availability) and scalability as the tenant user base grows and new user scenarios can be easily enabled for each tenant individually.
- Omnissa Access as-a-service provides tenants with a quick time-to-market turnaround for new features and capabilities.
Planning the migration
This section walks through the recommended migration at a high level and then lays out the steps commonly performed by customers during migrations. Some of the steps are unique to specific use cases and will be marked as optional.
Requirements for the migration
Before you can continue, you must have the following components installed and configured:
- An existing Omnissa Access environment (on-premises)
Migration outline
The general idea for the migration is to set up the new cloud-hosted Access environment in addition to the existing Access environment, configure the basic settings, connect both tenants with the help of a Security Assertion Markup Language (SAML) federation, link resources from the old environment into the new cloud tenant, and then start moving those resources to the new cloud tenant to minimize service downtime. Depending on your use cases, sections of the migration path may differ. For a Workspace ONE UEM customer, it will be necessary to migrate the Access and Hub Services integration. In the UEM environment, it might be important for a Horizon Universal Broker customer to relink Access in the Horizon cloud to Workspace ONE integration.
Migration steps
Step 1: Assessment
Migration of Omnissa Access from on-premises to the hosted (Cloud) environment involves rebuilding and reconfiguring the directory integrations, connectors, apps, and more. Hence a solid understanding of the existing on-premises environment is a good starting point.
The following table goes through an extensive but potentially not complete list of configurations to assess and document.
| Configuration | Task |
| Directories configurations Identify the structure and setup of user directories, including LDAP, Active Directory, etc. | Find the structure and setup of user directories, including LDAP, Active Directory
|
| Connector settings Understand the configuration settings for connectors connecting to AD (Active Directory), LDAP, or authentication methods | Understand the configuration settings for connectors connecting to AD (Active Directory), LDAP, or authentication methods
|
| Authentication Methods | Note the authentication methods in use Which authentication methods are enabled? Mobile SSO/Certificate authentication
|
| Network Ranges | Document network range configurations Hosted Access cannot use internal ranges anymore; you can only configure egress IP addresses to differentiate all internal from internet traffic |
| Identity Provider settings | Review identity provider configurations integrated with Omnissa Access. 3rd party IdPs (identity provider)
Built In IdPs
|
| Access Policies | Review and document the existing access policies Default access policy Collect the rules and order Resource specific policies Collect the rules and order |
| Roles | Collect the roles applied to Administrators and Users Collect any custom roles and applied settings |
| Login preferences | Document the login preferences settings Domain visibility and drop-down Unique Sign-in Identifier iFrame render settings |
| Branding | Note any branding customizations done in the current environment Logo and Color schema for sign-in screens |
| Hub Services | Review configurations related to Workspace ONE Hub services
|
| Web app resources | Document all web app resources integrated into Omnissa Access Omnissa Access Launch URLs for first step of migration Configured App Sources |
| Virtual Desktop resources | Collect the currently configured Horizon Pods, Citrix, or Thin Apps |
| OAuth 2.0 Clients | Identify any OAuth 2.0 clients and their configurations Service clients or OAuth Templates |
Step 2: Setup a new cloud environment to run in parallel
Work with your account representative to get a new cloud-hosted Omnissa Access tenant. We will provide either direct administrator login credentials or provide access through Omnissa Connect. Cloud-hosted access only allows you to customize the first part of the URL, e.g., https://customer.workspaceoneaccess.com and for any vanity URLs you can only use 302 redirects to the respective tenant URL. More information on customizing the tenant URL can be found in How Do You Change Your Omnissa Access URL? on Omnissa Docs.
Directory and connector setup
With the information collected in Step 1, you can start with the basic configuration of the tenant. Start by adding your identity source in order to add administrators and admins to the tenant. To add a directory, you first need to install a connector that allows the cloud tenant to communicate with your Active Directory or LDAP.
Check the network requirements for the connector to communicate with the hosted environment:
- Omnissa Access Connector Systems Requirements (Omnissa Docs)
- Omnissa Access and Hub Services SaaS IP address ranges used for network configuration (KB article)
Create the configuration for the connector in the Access admin console and download the connector installer from the customer connect portal. Then install the connector with all the services that would be required later besides the user sync and user authentication.
With the connector in place, follow the documentation to integrate with your on-premises directory using the information you gathered in Step 1.
You can start with a test group and later configure all the users that should be migrated.
Authentication methods
Setting up the authentication methods collected in Step 1 is similar to the way they were set up on-premises. There are new methods available now that were only introduced for cloud-hosted Access. The suggestion is to migrate the existing configurations and then use the documentation to become familiar with the additional methods, such as Omnissa Pass, FIDO2, or Risk Scoring for later implementation. Setting up methods such as Mobile SSO might require configurations in Workspace ONE UEM as well.
Network ranges
With the authentication methods required in place, a good next step is to create the network ranges to be used in IdPs (identity provider) and access policies. As mentioned in Step 1, we cannot use internal network ranges in the cloud-hosted Access environment. You need to use the egress IP address(es) from your network edges to differentiate internal traffic from normal internet traffic. Add them as documented in the following:
Identity provider settings
Check the built-in IdP (identity provider) created for the directory you configured and enable all configured authentication methods you want to use as well as all network ranges.
If you had 3rd party IdPs configured, configure them again by adding the metadata from the discovery phase or set the new tenant up as a new SP (Service Provider) in your IdP.
Access policies
With the methods and IdPs in place, you can now configure and create the access policies to control access to the Intelligent Hub app and resources. Leverage the information from Step 1 and potentially review the settings against the documentation and FAQ (Frequently Asked Questions) linked below. Using step up authentication such as Device Compliance requires the integration with UEM and will be configured in a later step.
Login preferences
Control the experience for users when logging in to the Intelligent Hub portal and manage the use of unique sign-in identifiers or domain drop downs. Set this up using the previously documented information and product documentation.
Branding
Finally, use the branding information documented before to customize the look and feel of the tenant.
For console and sign-in screens, see the following:
For the Intelligent Hub portal, check out the Hub branding guide:
Configure Resources that Support Multiple IdPs
For web applications or application sources that support multiple IdPs, you can now configure the integration by configuring based on the documentation. Consult with your application owner if you can use the same SP settings collected in Step 1 or if you need to create new SP metadata.
- Providing Access to Web Applications in Omnissa Access
- Providing Access to Third-Party Managed Applications in Omnissa Access
Entitle the test user group to the added resources.
Testing
With the general setup in place, test the login for the test end user group. Can users sign in correctly to the tenant and have access to the portal and, if configured, resources?
Step 3: Setup trust between the old and new environment
Trust through SAML (Security Assertion Markup Language) federation
To ease the migration, setup federation between the new tenant and the existing on-premises environment which allows you to start resources after authenticating to the new tenant.
3rd Party IdP (Identity Provider) - old environment
Copy the IdP metadata URL from the cloud-hosted Access tenant by going to Resources > Web Apps > Settings > SAML Metadata menu and use the URL to configure a 3rd party IdP in the existing on-premises environment. NameID format should be a unique identifier such as UPN (User Principal Name) and match against the same NameID value.
In the Users section, use the configured directory and all network ranges. Finally, the authentication method the new tenant will return is passwordprotected. More details on the configurations of the 3rd party IdP can be found here.
After saving the configuration you can download the Service Provider (SP) metadata from the bottom of the IdP configuration.
Access policies - old environment
In the old environment, you now need to add the 3rd party IdP authentication method as a viable authentication option in the access policies. Configure an Any or Web Browser rule after the existing rules allowing user access with the IdP authentication method.
Application source – new tenant
With the SP metadata, configure the old environment as an Application Source inside the new cloud-hosted tenant. Pick one of the three optional 3rd party sources that are not yet in use and configure it with the SP metadata of the old environment and the matching nameID configuration.
Add applications
With the application launch URLs from Step 1, you can now create applications from the application source with the Launch URL added as Target URL. This can include web applications and VDIs (Virtual Desktop Infrastructure). Entitle the test users for the application source app.
Test accessing resources
Again, let test users log in to the Intelligent Hub portal and access the newly configured resources.
Step 4: Migrate users
After successful testing, synchronize the rest of the users.
Step 5: Migrate settings in Workspace ONE UEM (Unified Endpoint Management)
Integration with Workspace ONE UEM
The next step will have an impact on all users with enrolled devices and Intelligent Hub. We need to reconfigure the existing Access integration in UEM from pointing to the old environment to the new cloud-hosted tenant. Follow the documentation:
Also, check the Hub Services integration in UEM since it needs to point to the same Access tenant as the service where it is co-hosted. Follow the guidance listed:
Devices enrolled will need to reauthenticate against the new tenant, setting up Mobile SSO or certificate authentication can help to make the process transparent for the user.
Step 6: Migrate web apps and VDIs (Virtual Desktop Infrastructure)
Web apps
For web applications that did not support multiple IdPs, we now need to work with the application owner and move the federation to the new tenant. For each app, create a web application on the new tenant with the SP metadata collected in Step 1. Then provide the IdP metadata of the cloud-hosted tenant to the application owner and plan a switch of the IdP in the application during a maintenance window. Test the federation, and if successful, entitle all required users on the app and remove the entitlement from the app source version of the application pointing to the on-premises tenant.
Go through all remaining applications in the same manner.
For the Access part of the web app configuration, you can potentially leverage the Omnissa Access Migration Tool Fling that allows for the bulk export and import of web app settings. You can download it on Tech Zone: Omnissa Access Migration Tool.
You will still need to configure the Service Provider side separately.
Virtual apps Horizon/Citrix
Go through the setup of VDIs (Virtual Desktop Infrastructure) collections in Access and change the configuration on the Horizon CS (Connection Server) side.
Step 7: Decommission on-premises Omnissa Access
After all use cases are moved to the new tenant, create a redirect to the new tenant in DNS (Domain Name System) and decommission the old tenant.
Summary and Additional Resources
This guide provided an overview of the typical steps involved when moving Access tenants, be it from on-premises or an old cloud-hosted tenant to a new cloud tenant. The steps required may vary and it is a good idea to involve Omnissa or partners to guide you through the process.
Changelog
The following updates were made to this guide:
| Date | Description of Changes |
| 2026/08/20 |
|
| 2024/11/05 |
|
| 2023/12/18 |
|
About the Author
This document was written by:
- Sascha Warno, Principal Product Specialist, Identity & Security Solutions, Omnissa
With contributions by:
- Nandini Sharma, Senior Product Specialist, Omnissa Access & Identity Solutions, Omnissa
Feedback
Your feedback is valuable. To comment on this paper, either use the feedback button or contact us at tech_content_feedback@omnissa.com.