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. 

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.

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?

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

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?

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.

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,

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.