Device Relocation based on device model

Device Relocation based on device model

   First off my ultimate intentions is to have one barcode that loads all Zebra devices.  Doesn't matter if it is a ET50, TC70X, or a TC50.  With that in mind I have setup the add rule to drop all devices into a Stage folder.  

   My goal is to setup a device relocation based on the device model.  Unfortunately IP and Custom Data are the only option to trigger relocation rules (Soti PLEASE make this more flexible in future!).  I could use the Custom Data, but the only way to fill a custom data feild is through an INI or XML file off of the device (again FLEXIBILITY please...).  So at this point i'm thinking a file sync rule with a custom script post file sync that will take the %MODEL% and write it to an ini file on the android device.  Then I can tie the custom attribute to that file and pull back what was written into that ini.  FYI - I have this working on WinMobile devices since there are ini files built in that include the device model.

   I am very weak at writing soti scripts and am wondering if i'm on the right track before I spend a bunch of time writing the script.  Is there an easier way?  Will this work at all?

8 Answers

Order By:   Standard | Newest | Votes
Raymond Chan | posted this 19 December 2018

What are the version and build numbers of your MobiControl server?

Are all devices of the same model to be moved to one single device group?  Is this a one-time task or do you need to repeat it at different scheduled time?  Approximately how many devices are there?

 

 

  • 0
  • 0
Travis Epperson | posted this 19 December 2018
Version: 14.1.4.1693

There will be at least three different models for this add rule.  Each will be moved into their own folder based on their model number.
  • 0
  • 0
Travis Epperson | posted this 19 December 2018

Total count will be 2000+ in the end.  Trying to automate a lot of things so that it is a clear process and doesn't take manual work in Soti.

  • 0
  • 0
Matt Dermody | posted this 19 December 2018

You're frustrations around the limited options within Device Relocation rules are certainly valid and the workaround you've developed is basically the same process that we leverage, outside of creating a unique Staging folder for each device model. I don't believe you can actually write to an INI file via a SOTI script in Android (hopefully I'm wrong) so you may have to create a unique INI for each of your device models that has a "hardcoded" model name value and then use a Profile with Filter Criteria of Model for each device. It is certainly frustrating that Model, Manufacturer, and OEM Version are all options Filter Criteria but not options for Device Relocation rules. This approach would be a little less dynamic than ideally writing the macro %MODEL% value to the file automatically through a File Sync rule but it would work. 

 

One other approach that I've leveraged is utilizing the OEM Version and/or LG Version extracted from GetPatchVer as the CustomData for inferring the device model. Its a little trickier keeping track of and maintaining than a straightforward device model but the OEMVersions across those device models should hopefully be unique. That probably won't be the case with all of the next generation SD660 devices that will share common OEM Versions and LifeGuard updates like the Atlas (TC51, TC70x, MC3300, VC80x) devices do today. 

  • 0
  • 0
Raymond Chan | posted this 19 December 2018

Unless I've misinterpreted your descriptions,  I believe you probably don't need to use custom data or whatever complicated task you mentioned.  One possible trick is like this:

For each model,  add a virtual device group with automatic filter based on the model name.  Then add a device-relocation rule using full IP address range 0.0.0.0-255.255.255.255 to target all devices already automatically selected in the virtual device group.

 

  • 0
  • 0
Matt Dermody | posted this 19 December 2018

Great point, you could use the Virtual Groups to accomplish this as well! This is one of the best AND worst things about SOTI. There are so many different ways of accomplishing the same goal. 

  • 1
  • 0
Travis Epperson | posted this 19 December 2018

I hadn't messed with virtual groups yet!  This works great, and is less messy then what I had planned.  I think for the options available this is the best.  (Soti if you are reading I still vote for more flexibility in your migration rules though).

 

Thanks a ton!

  • 0
  • 0
Support Staff | posted this 19 December 2018

Hi Travis,

 

Great post and yes your vote has been noted! ;)

 

Cheers!

 

Technical Support | SOTI Inc. |1.905.624.9828 | support@soti.net | www.soti.net |

  • 0
  • 0

Give us your feedback
Give us your feedback
Feedback