Assign Profile to Virtual Group

Assign Profile to Virtual Group

Hi,

 

Do we know why we cannot assign Profiles to Virtual Group?

I am using MOBI 13.4

 

you might ask, why do i need this?

Our structure is to have folder per company branch, and each branch have 2 Enrollment Rules per Team (each team has his own devices), so we end up having for example, branch Seattle has Folder named Seattle, and under it we have devices for team1 and devices for team2.

What we want is to push profiles based on DeviceName, ex: includes "team1"... and so force.

 

I realized that when creating Virtual Group we could do that, but profiles cannot be assigned to Virtual Group!

Also, i was thinking to add this filter in the profile Assignment, but the assignment doesn't give me the option to select by DeviceName.

 

does one of these 2 features exist in newer versions of MOBI?

 

  • 26 June 2019
  • SOTI MobiControl
  • 8 Answers
  • 0 Upvote
  • 2 Followers
  • 1.8K Views
    • 8 Answers
    • 0 Upvote
    • 2 Followers

8 Answers

Order By:   Standard | Newest | Votes
Matt Dermody | posted this 26 June 2019

I think the primary reason why you can't is to avoid conflict of Profiles with different version number or setting values. Because devices can exist in multiple Virtual Groups you could inadvertently create a situation where two different Feature Control profiles or two Profiles with different versions of the same Package get assigned to the same device, creating a conflict that would be difficult to control. It would be difficult for SOTI to determine under those circumstances which version of a Package or Profile settings would take priority over the other. 

There are some alternative solutions available however:

- As of 14.4 you can assign Profiles based on DeviceName

- You could assign a Custom Value to the devices that would act as a SiteID value or TeamID that could then be used within the Filter Criteria of a Profile. 

 

 

  • 1
  • 0
Raymond Chan | posted this 26 June 2019

Even before profiles were introduced in v12.0,  virtual groups had already been restricted to rules.  The configurations and advanced-settings were done "in-place" at each device group tree nodes, with automatic inheritance and flexible over-ridding. This in-place approach/UI  nearly completely removes possibility of creating configuration conflicts by inexperience administrators.

 

The introduction of profiles in v12.0 brought many advantages (such as possibility to clone profile to save policy tuning effort; profile read/write permission control, profile filters to add more assignment criteria, etc). One of the biggest consequence is, however, the increasing possibility of configuration conflicts that may be caused by one or more administrators. 

 

As each device can belong to virtually unlimited number of virtual device groups,  allowing profile configuration to target virtual group will just lead to more policy conflict problems, especially for inexperienced and careless administrators.  While there are no full set of well-defined rules to resolve policy conflicts (not even with the single-vendor iOS platform, let alone highly fragmented Android). Even if there are, I reckon the processing time required to handle conflicts for large implementation with thousands of devices will render the web-console very unresponsive to interact and slow to deploy profiles.  However, profile filter is actually already one step forward to allow some functionalities/benefits of virtual group to be available to profiles.

 

  • 0
  • 0
Sean I | posted this 27 June 2019

Thanks Matt,

 

I was thinking first of customs attribute, but this won't be a great solution as i have to set the value per device and that will be difficult to maintain, i want something more autonomous. if the enrollment rule could set a customs attribute value this might be a solution.

Now, i understand why Profiles cannot be assigned to Virtual Group.

I thinks what i need is the ability to select DeviceName filter in the profile assignment, and this cannot be done unless i upgrade to 14.4, correct?

 

Any alternative method?

  • 0
  • 0
Matt Dermody | posted this 27 June 2019

If you already are planning on separate Enrollment rules by team then you can create the following Group structure, have devices enroll directly to the team group, and then assign the Profiles to the specific group folders so that you don't have to mess with Device Names. 

 

Branch Group->Seattle Group->Team 1

  • 0
  • 0
Tu Pham | posted this 29 June 2019

Hi Michael,

 

I’ve met the same predicament and found that you can have device relocation rule targeted to a Virtual Group that can relocate to a Device Group. I would exercise caution though as you could add delays to profile delivery if you get over-zealous with filters. 

If I have read correctly, you already have a unique enrolment rule per team. So if the ratio of Enrolment ID to Team is 1:1, then couldn’t you set each “Add Device Rule” to each respective folder?

Seattle

|_ Team 1

|_|_ "Add Seattle Devices to Team 1” Add Device Rule 

|_ Team 2

|_|_ "Add Seattle Devices to Team 1” Add Device Rule 

 

Chicago

|_ Team 1

|_|_ "Add Chicago Devices to Team 1” Add Device Rule 

|_ Team 2

|_|_ "Add Chicago Devices to Team 1” Add Device Rule 

 

Team 1 Profile Assignments

 //Seattle/Team 1

//Chicago/Team 1

 

Team 2 Profile Assignments

 //Seattle/Team 2

//Chicago/Team 2

 

As new sites and teams get created then you would add assignment of existing profiles to the new Team1/Team2 groups.  

 

Is that feasible?

  • 0
  • 0
Tu Pham | posted this 29 June 2019

If you already are planning on separate Enrollment rules by team then you can create the following Group structure, have devices enroll directly to the team group, and then assign the Profiles to the specific group folders so that you don't have to mess with Device Names. 

 

Branch Group->Seattle Group->Team 1

 

Apologies. @Matt.. I posted my response below before seeing your last post, which essentially is the same thing.

  • 0
  • 0
RJMOD@SOTI | posted this 30 July 2019

Hello Moine,

 

Were you able to test out the solutions provided by Matt and Tu?

It seems like the easiest way to proceed would be to have a sub folder structure which can then be targeted by specific profiles.

 

Regards,

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

  • 0
  • 0
Raymond Chan | posted this 31 July 2019

Hi Moine,

If your original plan is to use custom attribute, you can consider using bulk import (using CSV file with DeviceID and custom attribute name and value per line)  in MobiControl v13.4 to operate on all devices in one go to solve your so-called maintenance problem.

 

  • 0
  • 0

Give us your feedback
Give us your feedback
Feedback