Hi Nicolas,

I have replicated your situation myside and confirm the behaviour that for some reason the lockdown gets the first Custom Attribute and doesnt update even after lockdown refresh once device is moved group.

I have however found a work around to this, though I am not entirely sure why the lockdown menu item approach does not work

Instead of your menu item being Launch %CustomAttr:Test%

Swap this for Custom script:///sdcard/StartApp.cmd

Then create StartApp.cmd file in a text editor, its contents would be:

start %CustomAttr:Appname%

Deploy this file to the devices and locate at /sdcard/

Thanks
Adam

When value of a custom attribute has been made with the web-console at the MobiControl side, it is common that there is some time delay  before the new values get sent to the related device(s).   Such time delay can vary quite widely depending on many factors in a particular implementation, for examples, the number of devices affected, server CPU/network loading & scheduling, connection quality, heart-beat schedule, device model/firmware, device agent version, etc. 

Also, after the new value has reached a particular device, the lockdown menu already shown on the device screen may not be IMMEDIATELY redrawn using the new value unless manually enforced properly by extra script(s) based on particular implementation/device-model. 

Hi Nicholas,

Could you share what examples of AppSES could be and outline (ven roughlyl) the difference in the application packages?

Just so I can understand a little more the use case.

Thanks
Adam

Nicolas,

If you have rebooted the device, the lockdown menu must have already been redrawn.  So, if the lockdown menu screen is still drawn based on old custom attribute value, it is likely that your new custom attribute value has not actually reached the device yet.  Have you done any test to confirm this?

Is the value of AppSES just the bundle ID of an app?

Are you using the MobiControl "standard" (i.e. without any of your own customization) static or "standard dynamic" html template for your current lockdown menu?

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

Frankly speaking, I have previously used custom attributes successfully for many many different objects/elements in the html template or kiosk item parameters such as  file-path, URL, intent parameters, etc.  but never for bundle-ID, which indirectly affects some kind of application-run-control whitelist for relevant kiosk items.     I have to do some tests to see if there are any tricks when using it to replace the whole or part of an app bundle-ID.

Please clarify if you are using the html template with filename "DynamicAndroidLockdownTemplate.html"?

Or the one wth filename "MCTemplateAndroidDesktop.html"?   

If you use static template " MCTemplateAndroidDesktop.html" and cannot get %DEVICENAME%" change to work in your test, the problem can likely be related to how you use the macro (syntax, configuration, s/w compatibility, etc.) or how you do your test. Let's focus on the simpler device-name macro first before handling the App package macro.

Instead of putting the %DEVICENAME% macro in the nth "DISPLAY NAME" field, open your customized html file and replace the string <MCDISPn> with  "%DEVICENAME%".  Redo your test to see if it works or not.  After making any change to the device name, and confirm that the new value has been sent to the device (e.g. with your "showmessagebox script test), you have to force the lockdown to be redrawn by either one of the following:

1. reboot the device;

2. revoke the profile consisting of the lockdown menu payload and re-deploy;

3. run a single three-line legacy script to turn off the kiosk, wait a few seconds and turn on the kiosk again.

Usage of Custom Attributes in the lockdown to dynamically resolve a different bundle ID depending on what is present on the device is a creative, but arguably complex solution to this particular problem. If I were designing for this scenario I would probably use different Lockdown profiles and then assign them based on the criteria of the given bundle ID being installed on the device. The respective Lockdown would be installed based on the presence of the installed app. 

I totally agreed with Matt's comments in his last post.   Those are some of the reasons why my company haven't used custom-attribute for dynamic configuration of app bundle-ID in the last ten years or so.   The unpredictable time delay for custom attribute value to reach the device due to various uncontrollable factors, and the need for reliable timely mechanism to enforce lockdown menu re-rendering are also concerns in terms of users' UI experience.

Hi Nicolas,

Thanks for posting on SOTI Pulse, Thanks Matt, Ramond, and John for responding to the post, your expertise and willingness to help are greatly appreciated.

I'm glad that you've found the solution to your query.

If you have any additional questions or concerns, please don't hesitate to reach out. We're dedicated to providing assistance and support.

Kindly let us know.

Kind regards,

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