The new group template feature is awesome and will be very useful! I would love for it to expand and allow us to assign the template to clients. This way, we can create standardized groups across our customer base that we will use for other things. Similar to how we can assign Intune policies, we could assign the group template and have the group deploy regardless of whether it is used in an Intune policy direct assignment. It would also be helpful if we could use inherited variables in the template name. Inherited variables would allow us to adapt to our existing naming conventions.
Group Templates - Add Functionality (Completed)
4
Hi Chris Brannon. I'm glad to hear that you love the new Group Templates! And yes, we do have plans to expand the use cases for them. When you refer to 'other things', can you please elaborate on potential use cases? I understand that group-based licensing is something many companies use, but what's else?
Inherited Variables support is definitely something we'd like to bring to this feature. A related question I have on this topic, what's the general naming convention that you like to use when creating groups?
I know when I worked for MSPs, we created our own (arbitrary) naming scheme for User and Device Groups and it seemed to work well for us.
<CompanyCode>|<GroupType>-<GroupPurpose>
Examples:
NERDIO|Device-DellLaptops
ABC|User-LicensedUsers
XYZ|Device-TestingWindows11Updates
Chris makes a great point though.
Being able to utilize an inherited variable as part of the Group Template Name would make it really flexible.
Examples:
$inheritedVars.CompanyCode|$GroupType-$inheritedVars.QBVersionNum
$inheritedVars.CompanyCode|$GroupType-$inheritedVars.Region
Agree with the ask, we've had a few other partners ask for this as well.
Gido Veekens, similar to Dave's reply regarding inherited variables. We do a lot with customer abbreviations; in most cases, they could be generated by the client's name if additional templating functions were available. For example, John Doe's Plumbing == JDP, which is probably more complicated than it is worth when we could leverage inherited variables. I also see us using inherited variables for other group names.
For the "other things," a great example is billing. We do a lot of group member syncing to automatically increment user counts within our PSA—for instance, Keeper Password Manager. If we could create a security group, "{$inheritedVars.CustAbbr}-KEEPER-USER," we could then use that group in our PSA to update the Keeper Password Manager user count on their agreement. Doing this at the MSP level would allow us to standardize things more. We could even do this for a basic Nerdio AVD deployment where only one host pool is leveraged. At the MSP level, have a group template like {$inheritedVars.CustAbbr}-AVD-USER. I could even see us using this for UAM app deployment.
I know that group templates are only for security groups today, but expanding this to distribution groups would also be helpful. We typically create generic distribution lists for each client for Backup Reports and Ticket Updates. A template like Name == "{$customername} Backup Reports" and the distribution email address == "backupreports@{$defaultdomain}." - {$defaultdomain} hopefully being a system variable of the default domain within the M365 tenant.
Please sign in to leave a comment.
Comments (5 comments)