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 https://support.citrix.com/article/CTX118670 for more info.** These old objects were named:

lbvsrv_xml_XenApp
lbvsrv_xml_XenDesktop
svcgrp_xml_XenApp
svcgrp_xml_XenDesktop

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:

lbvsrv_x-ml_XenApp
lbvsrv_x-ml_XenDesktop


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.

Jason Samuel

Jason Samuel is a visionary product leader and trusted advisor with a proven track record of shaping strategy and driving technology innovation. With extensive expertise in enterprise end-user computing, security, cloud, automation, and virtualization technologies, Jason has become a globally recognized authority in the IT industry. His career spans consulting for hundreds of Fortune 500 enterprises across diverse business sectors worldwide, delivering cutting-edge digital solutions from Citrix, Microsoft, VMware, Amazon, Google, and NVIDIA that seamlessly balance security with exceptional user experiences.

Jason’s leadership is amplified by his dedication to knowledge-sharing as an author, speaker, podcaster, and mentor within the global IT and technology community. Recognized with numerous prestigious awards, Jason’s contributions underscore his commitment to advancing technology and empowering organizations to achieve transformative results.  Follow him on LinkedIn.