Working in the field while migrating from XenMobile 9.0 to XenMobile 10.x, we learned more than a few lessons and checks that need attention. Here’s some of our observations.

Observation 1:

In XDM 9.0, if the SQL Server’s Name is configured only with the hostname (ex: sql1) and NOT with the SQL Server’s FQDN (ex: sql1.mydomain.com), you will encounter an issue with migration.

Resolution:

Update C:\Program Files (x86)\Citrix\XenMobile Device Manager\tomcat\webapps\zdm\WEB-INF\classes\ew-config.properties file with the FQDN of SQL Server (4 locations in the same file need to be updated), save the changes before initiating the migration.

Properties that need to be updated/changed are:

pooled.datasource.url=jdbc:jtds:sqlserver://sql1.domain.com:1433/xxxxxxxxx

pooled.datasource.hostname=sql1.domain.com

audit.datasource.url=jdbc:jtds:sqlserver://sql1.domain.com:1433/xxxxxxxxx

audit.datasource.hostname=sql1.domain.com

———————————————————————————————————————————————————————

Observation 2:

While performing the migration you will need to use exactly the same username as displayed while performing ZIPIT!! step.

zipit blog

———————————————————————————————————————————————————————

Observation 3:

Make sure you add enrollment FQDN in NetScaler Gateway -> Global Settings -> Configured Domains for Clientless Access to Allowed Domains

———————————————————————————————————————————————————————

Observation 4:

Checks:

  • Verify Custom Store Name in AppController under Setting, Becons.
  • Verify if AppController FQDN is in upper case (fixed in V4+)
  • Verify the domain alias under LDAP config
  • Perform a comparison check if with the 9.0 environment if you have more than one LDAP managed.
  • Custom Store name works in 9.0 and 10.3, doesn’t in 10.1
  • Store name with spaces work in 9.0
  • Store name with spaces doesn’t work in 10.1 and 10.3
  • If there are any spaces in store, plan to change it before migration on 9.0

——————————————————————————————————————————————————————–

Observation 5:

Checks:

  • Make a note of Time Zone settings in 9.0, update the same in 10.3
  • Verify if there are any windows 8.1 devices and the WorxHome version
  • Check if there are any “.” (dots) in group names in XM 9.0

——————————————————————————————————————————————————————–

Observation 6:

  • Before and/or, At the time of Migration
  • Delete browser cache, Chrome browser is preferred
  • Double check if customer has V6 license server installed
  • Double check if customer has new DMZ IP’s for MAM Load balance virtual server and for Migration Load Balancer
  • Disable Load Balance 443 Virtual Server
  • Disable Load Balance 8443 Virtual Server
  • Disable NetScaler Gateway Virtual Server

OR

  • Block 443 and 8443 ports on firewall to Load Balance Virtual Server
  • Block 443 port on firewall to NetScaler Gateway Virtual Server

Note: No user should have access to XenMobile 9.0 environment

——————————————————————————————————————————————————————–

Observation 7:

  • Post Migration – XenMobile 10.1
  • Verify time and time zone, set it to be same as xenmobile 9.0
  • Verify Certificates
  • Verify Licenses
  • Verify Worx Branding (Store Name)
  • Verify Cluster settings, enable SSL Offload, if cluster
  • Verify firewall settings, enable port 80
  • Verify LDAP, edit and save
  • Verify AppS
  • Verify devices and the status of devices
  • Verify delivery groups
  • Verify ew-config.properties updates from 9.0
  • Perform XenMobile Health Checks
  • Perform NetScaler Gateway health checks

——————————————————————————————————————————————————————–

Observation 8:

  • Post Migration – Verify NetScaler
  • 1 load balance virtual server for fresh install, 2 load balance virtual servers for migration, We call them as
    • XMS Load Balancer, 8443
    • AppController Load Balancer, 443
  • Create DNS A Record for AppController FQDN pointing to AppController Load Balancer
    • Service will be new XMS Server
  • Create DNS A Record for XMS (enrollment) FQDN pointing to XMS Load Balancer
    • Service will be new XMS Server
  • AppController Certificate should be bound to AppController Load Balancer
  • Add / Verify XMS STA to NetScaler Gateway VIP
  • Add / Verify Storefront STA to NetScaler Gateway VIP
  • Add / Verify XMS FQDN is added in client less access domain

——————————————————————————————————————————————————————–

Observation 9:

Post Migration:  NetScaler configuration is not visible in XMS

Issue:

  • Data migration to the XMS 10.1 was successful, however, NetScaler configuration do not show up under Settings.
  • We found that the data has been migrated to the new XMS as the data was found in the DB.
  • What and where was the problem?
  • The Web address under storefront had a :0 (example is in the screenshot below)

blog 2

——————————————————————————————————————————————————————–

Observation 10:

Post Migration : WorxStore takes more than 5 min to open

Issue:

  • Data migration is successful.
  • User from Android and iOS are able to authenticate
  • When tapping on WorxStore there is a latency of about 5 min observed.
  • All policies on NSG were revisited, no issues observed.
  • No errors found in device logs
  • What and where was the problem?

Reason:

  • StoreFront server was configured when no StoreFront existed in the first place
  • WorxStore will perform about 3 attempts to ping and wait for a response from the StoreFront server after which it timed out.
  • You would also see behaviors like, enrollment fails @ MAM..etc

Solution:

  • Removed the XenApp/Desktop storefront config from the XMS.

——————————————————————————————————————————————————————–

Observation 11:

Post Migration – Users belonging to a particular domain could not login.

Users belonging to one of the four domain managed could not login reason being this domain managed on MDM 9, LDAP setting had the OU information filled under “Users organizational unit” field.

blog 4

Reason:

Post migration on checking the LDAP settings for this particular domain, observation was that the MDM 9.0  LDAP “Users organizational unit” config was being carried over onto XMS 10.X as “User base DN” as part of the migration which caused the issue.

blog5

Solution:

Modified the details in the XMS from OU to the complete base  DN (root context) “DC=xxxxxx,DC=xxx,DC=xx”, which fixed this issue.

blog6

Note: The issue has been captured and is fixed in next version 6 (V6) of the migration tool.

——————————————————————————————————————————————————————–

Observation 12:

Post Migration Published apps do not launch

Reason:

  • XenApp and XenDesktop STA’s were not added under NSG VIP.
  • In this case the customer was using a New NetScaler for the migrated environment.

——————————————————————————————————————————————————————–

Observation 13:

Post Migration Unable to connect to V6 license server

  • Port 7279 was not open though port 27000 was open.
  • In this case the customer setup a new V6 license server.

——————————————————————————————————————————————————————–

Observation 14:

Post Upgrade –  Number of licenses displayed wrongly

blog3

The reason that the customer sees fewer licenses in 10.3.5 than the previous release (10.3.0 displays correctly) is because of the SA (Subscription Advantage) Date on the licenses.  Any licenses with a subscription advantage date before 2016.0301 [March 1, 2016], will not be displayed on the console for 10.3.5. Similarly, any licenses with subscription advantage date before 2015.1019 [Oct 19, 2015] will not be displayed on the console for 10.3. From the license files we got from customer, we had seen that all licenses will be valid for Poseidon, however, only 500 licenses will be valid for Theseus.

Solution:

Get in touch with License server team, to get you one consolidated license file by reallocting the license.

FYR: Case # 71064244

——————————————————————————————————————————————————————–

Observation 15:

Issue: Post migration the XMS server goes for a continuous reboot.

Do you have proxy enabled on the AppController, does either the username or password hold a special character in it.  If YES, the following steps are recommended.

  • Undo/Remove the proxy setting from AppController using the CLI.
  • Once again export the support bundle in encrypted form.
  • Run through the migration process.
  • Once you have successfully performed the migration, you can enable the proxy by configuring it once again using the new XMS CLI.
——————————————————————————————————————————————————————–
Observation 16:
Migration fails with the following error displayed in the logs.
| migration | com.citrix.titan.migration.common.FatalErrorException: java.io.IOException: Keystore was tampered with, or password was incorrect

Caused by: java.io.IOException: Keystore was tampered with, or password was incorrect

We need to replace the tampered keystore with a valid keystore. For instructions please refer to this document.

XenMobile-Migration-SAML KeyStore Tampered

 —————————————————————————————————————————————————————–
 More: Stay Tuned, observations will be updated as on when we learn new items from field.