Citrix NetScaler

How to re-run the XenMobile Wizard on your Citrix NetScaler correctly



The XenMobile wizard on your NetScaler that helps to integrate the appliance with your XenMobile deployment is actually pretty good. I’m starting to use it more and more with my deployments. I recently came across an issue where the wizard could not be re-run once an existing XenMobile config was removed. I want to discuss the wizard, the proper way to remove a XenMobile config from a NetScaler if you have run the wizard once before, and how to get the wizard back if it disappears on you.

I’ll be honest, I used to dislike NetScaler wizards. It always felt like you were cheating. You never really know what a wizard is doing behind the scenes. That can be scary on a network appliance. In my experience wizards and templates try to fit into every deployment scenario but if you’ve seen a lot of Citrix environments, the reality is every environment is unique. I’ve seen NetScaler wizards cause problems in the past though they have become much better over the years and are a huge value add now. Wizards are good for people new to NetScaler to integrate with other Citrix products but it doesn’t give the engineer a good idea of how the configuration is being built.

One feedback I have given to the NetScaler product team is to have the best of both worlds. As the NetScaler engineer goes through the wizard, on the right hand side have a pane that will display the CLI config changes and build the config in realtime. It’s all NITRO after all. Every check box or text you enter in the wizard immediately gets reflected in the CLI commands on the right hand side so you know exactly what’s going on. This allows the engineer to still use a guided wizard to get setup but also educates them in the process. This will ultimately make them a better NetScaler engineer and not view the appliance as some big wizard driven mystery box.

If you use the XenMobile Wizard on your NetScaler and decide to remove your config and rerun it you must use the “Remove” options in the wizard itself to remove the configurations it made:


Me being in a hurry and knowing what objects the wizard creates decided to remove the wizard created objects manually. This is a big mistake, you may get a XenMobile dashboard page of empty stats like this if you miss something and there won’t be an option to run the XenMobile wizard anymore:


If you try and manually step through the tasks the wizard normally displays by using the Configure links on the right it’s going to set you up with XenMobile 9 and not XenMobile 10.x where the architecture has changed significantly. So don’t do this:


If you do get the screenshot above go through your NetScaler config and delete everything that the wizard had created (easy to spot since your naming convention and the wizard’s convention are probably going to be very different). Then click on XenMobile again and see if the wizard is back. After doing this I could still not get the XenMobile Wizard back. The issue ended up being a bug with the way XenMobile looks for configurations it made and with some load balanced vservers I had on the appliance already. A big thanks to Kanak with NetScaler Support to help me pinpoint what was going on.

Open a Putty SSH session to your NetScaler and type the following to search your running config:

sh run | grep _XM

Here’s an example of what you might see:

this will look for all objects the wizard created which always start with “_XM”. Though I had already cleaned my config of any XenMobile wizard driven objects, I had some old service groups and load balanced vservers when I was experimenting with XML calls that I had long forgotten about. **REMINDER, don’t load balance your XML brokers/STAs like this and use them in a production config without checking all dependencies in older environments or you’ll have latency issues. See for more info.** These old objects were named:


See the problem? My usual naming convention included the same “_xm” the XenMobile wizard looks for. Through the process of elimination I found that the service groups weren’t the issue. It was the load balanced vservers the wizard was looking at. I renamed them to:


and the XenMobile wizard came back and was fully functional again. Remember that it’s case sensitive so if you run into this kind of issue do a:

sh run | grep _xm

as well with lower case “_xm”. The wizard looks for both uppercase and lowercase “_xm” but the grep command does not and is case sensitive. You can even force grep to not be case sensitive with the following command:

sh run | grep -i _XM

This will return config results with both “_xm” and “_XM” in the name.

About Jason Samuel

Jason Samuel lives in Houston, TX with a primary focus on strategic advisory and architecture of end-user computing, security, enterprise mobility, virtualization, and cloud technologies from Citrix, Microsoft, & VMware. He also has an extensive background in web architecture and networking over his 20+ year career in IT. He is an Author, Speaker, and Local User Group Community Leader. He is certified in several technologies and is 1 of 63 people globally that is a recipient of the prestigious Citrix Technology Professional (CTP) award. He is 1 of 42 people in the world that has been awarded as a VMware EUC Champion and VMware vExpert. He is a featured author on DABCC which provides the latest IT Community News on Cloud, Data Center, Desktop, Mobility, Security, Storage, & Virtualization. In his spare time Jason enjoys writing how-to articles and evangelizing the technologies he works with. Disclaimer: The content and opinions expressed in articles and posts are his own and are by no means associated with his employer.

Recommended for you

Leave a Reply

Your email address will not be published. Required fields are marked *