Goal / Scope
This is a quick reference guide intended to provide the basics for using the add-on utility for MobileIron call Assemble.
MobileIron has been a leader in MDM (mobile device management) and has built the MobileIron suite of products from the ground up to make a stable, secure, and functional platform capable of managing many different devices and OS platforms. Due to the rapid growth of this area and the ever changing nature of technology in general, most the functionality is baked into the web GUI interface for the platform by default, but a handful of extra functionality has been held back. This is where MobileIron Assemble comes into play. It is a tool that provides the extra functionality making this MDM platform second to none.
Methodology / Process Steps
The add-on product can be aquired from the following Assemble website. You will need to use your MobileIron credentials to access that site, but it contains instructions, and a zip file containing several executables. These files allow running just about any “action” against your VSP using a single “rule” or several rules in combination. There is a slight learning curve to mastering this software, but if setup right it can be used as a scheduled task as well. Some of the functionality called out by MobileIron in the instructions for use are things like:
- time based restrictions
- setting all “company owned” devices to “company owned” by device serial number or ID and setting everything else to “employee owned”
- Quarantining devices based on distance from a location.
- Wiping a device when in a restricted country
- changing policy based on location (i.e. removing certificate based authentication when outside of corporate building)
- Day / Time based policies
- Location history reporting
just to name a few. These are all functions I have been asked about at one time or another while working with the MobileIron product.
In order to leverage MobileIron Assemble, a couple of things need to be setup for the Assemble executable.
- an “authentication” / configuration ini
- a “rules” / “actions” ini
NOTE: The names vsp.ini and rules.ini were selected randomly. These files can be named anything as long as the extension remains .ini.
The good news is there are GUI interfaces for configuration of these files. They look like the following:
- VSP Configuration GUI (vsp.exe)
- SMTP Configuration GUI (smtp.exe)
These applications will append to the ini file so it is best to use one of the configuration tools and then load the ini file from the other configuration tool. A couple of things to note. It seems to require the full path of the file so vsp.ini won’t work, but c:\Assemble\vsp.ini will work.
At any time you can open the ini file using notepad or a similar text editor and review the configuration settings. Once you are satisfied with how things look, it is time to create the second file, the rules.ini file.
This file has 3 concepts to it with 2 sections
the general configuration (called the RuleNum section)
The overall configuration of the rule(s) including the number of rules
The Rules section
The rules themselves
The actions taken if a rule is matched
Below is an example of the rules file used to actually send an APN message to iOS devices
- Example rules.ini File
The last Element1_value could be any label, but in this case it was company-owned devices. As you can see, there are 2 groups, [RuleNum] and [Rule1]. The RuleNum section has the number of rules along with settings that apply to the entire configuration. Rule1 contains the elements of the rule specifically. It calls out the number of elements (multiple elements can be combined for greater granularity). It also contains the actions that should be executed if a match is found. Here the device is set to wakeup (or check in) and then a message is pushed to the device with the content “Well, Hello there! :)”. The Element statements are what defines what the rule must match. In this example, it looks for any device that is associated with the “Company Owned” label. If you remove the “Element1” from the front of the string, it becomes a little easier to understand. There is a trigger definition, (what are we looking at), a description (helps describe what the rule is trying to match), the operator, (what do we do with the information) in this case the tag must “contain” the value, and value (the basic string we are trying to match).
Now that we have the 2 required files built, it is time to run the assemble executable with these files as inputs. To execute the configuration just setup, issue the following command in a command prompt.
assemble.exe vsp.ini rules.ini run
This will kick off a couple of activities. First a log file is generated and placed in the current working directory. The log file is very verbose and contains every step of the process as it is executed. Each time the command is issued a new log file is generated and the time stamp is added to the name of the file. See the example below.
- Example of the Assemble Log Files Behavior
The commands are actually run against the VSP. From reviewing the logs, the Assemble program checks for matches against all devices and then issues the command on all “matched” devices.
A system tray icon is created while the process is running providing some basic additional commands like pause or resume. Once the processes have all completed the system tray icon will be removed. This can be used as an indication of when the software completes and exits.
All company owned devices should be getting the message popping up on the screen.
Known Issues / Troubleshooting
This section is for the issues that have well defined and tested solutions.
Problem: | The Assemble Software is not performing the expected actions, or doesn’t seem to be performing any actions at all.
Solution: | Due to the complexity of the configuration, this could be due to a number of different issues. It is recommended that the Assemble website is used to debug and resolve these types of issues.