During a recent implementation of XenMobile 10 Enterprise (build 10.0.0.62300) I created a ShareFile Administrator Account within the ShareFile control plane to be used for the XenMobile integration.While I was still doing some testing and configuring a simple, non complex password was used for the ShareFile Administrator account. Soon as everything was working correctly I logged in to the ShareFile Control Plane and updated the password used for the ShareFile Administrator account for a complex one. Well so far so good. Next step in the process would naturally be to update the ShareFile Administrator account within the XenMobile Server (XMS) settings.
I logged in to the XenMobile 10 console and went to Configure > Settings > More > ShareFile and finally clicked Sharefile. Almost immediately I was confronted with an Error message “Username or Password was incorrect”.
Ok, this was to be suspected I did change the ShareFile Administrator password within the ShareFile control plane. After I clicked “Ok” an empty configuration box appeared.
This was different then in previous versions, but ok let’s go ahead and fill in all the required information (Domain / User name / Password) and click “Save”. Now I’m confronted with an error box that confused me: Error “Domain already exists”
I know the domain already exist I only want to update the ShareFile Administrator password which is being used. The domain box is however mandatory and my current configuration is not displayed so the only option left is to enter Domain, User name & Password. This feels like a deadlock situation where I’m not able to update the configuration through the web console.
This felt like a bug in XenMobile 10.0.0.62300 so I opened a support ticket with Citrix. After a short investigation of the XenMobile Engineer this was indeed classified as a Bug. The XenMobile escalation engineer reported it with development team, who are currently working on a hotfix for the issue.
Meanwhile I wasn’t able to wait for a hotfix and asked for a workaround, so we could continue the project. They suggested the following workaround:
Be aware it’s not a official Citrix Recommendation to use this workaround! It should be used with great precaution. Make sure to make a full backup of your XenMobile SQL Database before proceeding!
Determine AppID for ShareFile
Start the SQL Management Studio, select the XenMobile 10 database and create a new database query:
SELECT * FROM "RESOURCES_BAG"
This will give you an application list, including the AppID we need further on:
Chrome Extensions
Next we’ll need to add two extensions to the Google Chrome browser:
Log in
Then open the XenMobile Console (https://xms.yourdomain.example:4443) and make sure you’re logged in as administrator.
Referer Control
Open the Referer Control and add your XenMobile Console URL in the Custom section. Make sure to end the URL with a “/” backslash! Also make sure the Referer Control status is set to “Active”
Advanced REST Client
Switch over to the “Advanced REST Client” tab and fill out the following fields:
- URL, This should be your XenMobile console URL followed with /controlpoint/rest/application/<AppID>. Use the App ID we previously acquired from the SQL Database. Example URL : https://xms.yourdomain.example:4443/controlpoint/rest/application/3
- Request Type, This should be set to “Delete”
- Content-Type, This should be set to “Text/Plain”
Before you hit the “Send” button make sure you are logged in to the XMS Console so the browser has the session cookie available. The referer header will be taken from the Referer control.
And voila, the workaround deletes the existing ShareFile configuration from the XenMobile Server (XMS). Only thing left is to reconfigure the ShareFile configuration into the XenMobile Server. Until the XenMobile team releases a hotfix for this specific bug, I consider this workaround as a good alternative, as long it’s used with great precaution!
Many thanks to the XenMobile support team members, who worked with me on this issue.
This article is based on XenMobile 10.0.0.62300