SOTI Pulse Logo

Finding all devices with a Custom Attribute directly set (i.e. not Inherited from a group)

MS
Matt S
Union Pacific Railroad Company

For context: we're setting up a workflow wherein we install a package using a custom attribute's value set to a version number.

After testing on a few devices, we'll set a "default" version at the root Group level, so all devices will get the newest version.

Once that's done, we'll want to clear out the custom attribute on the test devices, so they inherit from the "default" version once again. That would give us a clean testbed for future upgrades.

I'm looking for a way to find all devices that have the custom attribute set directly, not inherited from a group. But I don't see a way to query this from the console, or from the API, or even in the database directly.

Any advice?

6 months ago
SOTI MobiControl
ANSWERS
RC
Raymond Chan Diamond Contributor
6 months ago

Matt,

As far as I know, there is currently no way within MobiControl to find all devices that have the custom attribute set (i.e. overridden) directly, not inherited from a group.  Having this support actually does not make much sense or become very confusing when handling a device group tree of 3 or more levels (maximum 20 levels supported in MobiControl) deep, as there can be  one or more intermediate level(s) overriding or inheriting from their corresponding parent in the whole hierarchy down to the device end.  

In addition, if custom value is used in the way you are thinking for handing different version of the same app, there have to be two or more app policies for a single app, deploying different version based on the custom attribute value specified in the assignment filter expression.  Using this approach does NOT guarantee stable "in-place" upgrade of an app, which means that an existing app and its data may all be uninstalled/deleted before a new binary version of the app is installed, resulting in potential loss of apps data (e.g preferences, history, shortcuts, etc.) of the device end-user.  Hence, I would not recommend using this work-flow involving custom value of apps version in multiple app policies for handling app upgrade. 

MS
Matt S
6 months ago

@Raymond - thanks for the feedback. We're interested in a pretty narrow case (either directly set or inherited via any means), but if this isn't available directly in the API we'll explore other options.

I appreciate the concern for side effects of generally installing packages this way. Our use case is pretty specialized here as well and we won't be adding/removing SOTI Packages, so we can bypass the package removal risk.

A bit more context: we're using this for MobiControl agent upgrades. We tie the custom attribute to a File Sync rule which downloads the APK, and a post-sync script to directly install the APK. We've been using a similar process for years, as the devices aren't Internet connected and can't download the Agent via the standard SOTI/S3 route. If there are alternate approaches that will work within our environment's constraints, I'm open to ideas.

RC
Raymond Chan Diamond Contributor
6 months ago

Hi Matt,

Thanks for the clarification of your particular use case.

Since the custom-attribute filter is for file-sync policy rather than app-policy, and post-sync script is used to initiate the app (the device agent in your case) installation, any upgrade done with your approach should  always be in-place without any risk of lost app data in the process.  .

To avoid your problem of finding which devices have their custom attribute overridden or not, a simple workflow is to add a second file-sync policy which has the new version of the agent device file in the source directory and same destination directory as your original file-sync policy., and are only assigned at device level (i.e. no node of the device group tree is selected) for all the targeted test devices within the deice group tree,    The software can then be precisely deployed to the selected devices for test..  When  no problem is found in all the tests, the new version of the device agent file can then be put in the source directory of your original file-sync policy and targeted to the whole tree.  There wlil be no extra bandwidth or re-installation related to the already tested devices if your file-sync policy advanced options are  properly chosen.

TB
Torsten Bethke
6 months ago

We've been doing this for packages and enterprise apps for some time now, and it works quite well.

After the update, I simply filter for the attribute using the search or search directly in the SQL:

First, I search for the attribute ID:
/****** View All Cust. Attr. ******/
SELECT * FROM [MobiControlDB].[dbo].[LabelType]

Then I identify the devices:
/****** find devices ******/
SELECT [LabelDevice].[LabelTypeId]
,[LabelDevice].[DeviceId]
,[DevInfo].[DevName]
,[LabelDevice].[Value]
,[LabelDevice].[Version]
FROM [MobiControlDB].[dbo].[LabelDevice], [MobiControlDB].[dbo].[DevInfo]
where [LabelDevice].[DeviceId] = [DevInfo].[DeviceId] and
[LabelTypeId] = 56

Finally, I delete the attribute using the console's "View All" --> Import custom attributes

MS
Matt S
6 months ago

Appreciate the query, but it doesn't seem to do quite what I want. I'm seeing devices returned that have the attribute set via an "inherited" group; in addition to those with an attribute set directly.

I'll take a look at the Import Custom Attributes option, that's new to me!

ZC
Zafer Cigdem
6 months ago

Hi Matt,

I don't get one point well. So let me continue with an example.

Let's say Custom Attribute is "user phone number", as default from inheritance it would be a standard value or you can set it from group level or such, for example No Phone Number Available. 

And this way, from MC APIs page /MobiControl/api/device you can see all devices whose user phone number custom attribute is equal to default value or not. and if it's the case you can collect these devices deviceID information to csv/excel and then deploy package/profile if required as an action.

for this kind of use-cases, I prefer to get all devices related path information by using 1 API call first and then data manipulation if required and then trigger action, below is an example section from my device's API's side on related to Custom Attribute.

if you need any help related to Custom Attribute APIs, you can let me know. I hope this helps

Zafer

T
TLMOD@SOTI
5 months ago

Hi Matt,

Thanks for posting on SOTI pulse. Thanks Zafer and Raymond for responding to the post, your expertise and willingness to help are greatly appreciated!

Has your query been resolved? If not, or if you have any additional concerns, please don't hesitate to reach out. We are dedicated to providing assistance and support.

Also, if this post has helped you in solving your query, I would request you to mark the particular comment as "is solution", so that others may benefit from this information.

Similar Discussions