Licensing failover to a different SKU if there are not available licenses in the first SKU?

[Ian Crew]

Hi all:

As at least some of you are aware, Google splits the licensing for Education Plus users of Workspace into two separate SKUs, 1010310008 and 1010310009.

This is pretty inconvenient, because it means that we have to split up the users into two different groups, of approximately the right size, before applying licenses to those accounts by running the following 3 commands each night:

gam group_users google_eduplus_li...@example.edu recursive end sync license 1010310008 productid 101031

gam group_users google_eduplus_li...@example.edu recursive end sync license 1010310009 productid 101031 

gam group_users google_eduplus_li...@example.edu recursive end sync license 1010310008 productid 101031

(We’re using a different tool to keep those two Groups updated from our central groups management system based on people’s affiliations at the university.)

It’s necessary to run all 3 of those commands to handle the case in which someone moves from license 1010310009 to 1010310008, as the first command will throw an error if someone already has a 1010310009 license.

Both the “008” and “009” licenses are the same in terms of functionality, so it doesn’t really matter which one one of our users get. There’s a split because of the way Google sells licenses into education—for every X “Education Plus" (008) licenses you buy, you get Y "Education Plus (Staff)" (009) licenses. 

But this split winds up getting to be pretty inconvenient because we have to maintain a significant buffer in each of the two groups, and segmenting our population in that way is pretty inconvenient.

So I was wondering if there might be some way to tell GAM (or put a wrapper around GAM) to get something to the effect of:

gam group_users all_google_eduplus_licenses@example.edu recursive end sync license 1010310008 OR 1010310009 productid 101031

In other words, meaning that we could just treat all of our licenses as a single big pool rather than having to manage the size of the two separate sub-groups, which is rather cumbersome, and also means we need to keep around a far larger buffer of unused licenses.

I’m thinking that this must be doable somehow, as the API gives an error if you try to add an “008” license to someone who already has an “009” license, so presumably that could be leveraged? Maybe something like:

1. gam config csv_output_header_filter "userId" print licenses sku "1010310008,1010310009"  to see who already has a license
2. gam group_users all_google_ed...@example.edu recursive end print to see who *should* have a license.
3. Compare the lists via comm (or similar) to get who should have a license added and who should have a license removed
4. Remove the licenses from those that should no longer have a license, regardless of whether it’s a 008 or 009 license.
5. Attempt to add a 008 license to those that should have a license, but don’t. If that fails, try adding a 009 license before giving up. 

I know how to do steps 1 through 3, but I’m less sure about how to accomplish steps 4 and 5. 

Any thoughts? 

Thanks,

Ian

 

Ian Crew Solutions Architect Productivity & Collaboration Services Berkeley IT

[Ian Crew]

Thinking more about this overnight, maybe these steps:

1. gam config csv_output_header_filter "userId" print licenses sku "1010310008,1010310009"  to see who already has a license
2. gam group_users all_google_ed...@example.edu recursive end print to see who *should* have a license.
3. Compare the lists via comm (or similar) to get who should have a license added and who should have a license removed
4. Remove the licenses from those that should no longer have a license, regardless of whether it’s a 008 or 009 license.
5. Attempt to add a 008 license to those that should have a license, but don’t. If that fails, try adding a 009 license before giving up. 

could actually look more like (based on https://github.com/taers232c/GAMADV-XTD3/wiki/Licenses#synchronize-licenses) :

1. gam group_users all_google_ed...@example.edu recursive end sync license 1010310008 productid 101031 removeonly —remove any 008 licenses that shouldn’t be allocated anymore.
2. gam group_users all_google_ed...@example.edu recursive end sync license 1010310009 productid 101031 removeonly —remove any 009 licenses that shouldn’t be allocated anymore.
3. gam group_users all_google_ed...@example.edu recursive end sync license 1010310008 productid 101031 addonly —attempt to add 008 licenses to members of the group that don’t have them. Ignore all errors that occur.
4. gam group_users all_google_ed...@example.edu recursive end sync license 1010310009 productid 101031 addonly —attempt to add 008 licenses to members of the group that don’t have them. Ignore any errors about the user already having a license (because that’ll be someone with a 008 license), pay attention to errors about not being able to add a license (because that likely means you’re out of licenses).

I haven’t tried this yet, but what do you all think? Does this sound plausible/someplace close to accurate?

Thanks much,

Ian

[Ian Crew]

Hi all:

With many, many thanks to Ross, I’m pleased to be able to share that as of version 6.30.01 (released today), it’s now possible to use GAM Advanced to manage your EduPlus licenses as if they are one combined pool, rather than the separate-but-equivalent EduPlus and EduPlus (Staff) pools. Check out the “onesku” option at https://github.com/taers232c/GAMADV-XTD3/wiki/Licenses#synchronize-licenses for all the details of how to do it.

The origin of this improvement was the thread below. It turns out that the 4-step process (2 removeonly steps followed by 2 addonly steps) does work, but it’s slow because it’s ultimately a very mechanistic way of doing things, just trying to add both licenses to every user in the group, not paying attention to things like errors returned by the API.

Ross stepped in and added the new “onesku” option to accomplish the same goal, but in a far speedier and intelligent manner, where it first determines who needs to have which license removed; then moves on to adding licenses using one SKU until that one is filled up. It then moves on to the next, and so on.

I have tested this with a number of different scenarios, and as far as I can tell, it works quite well, but there is a “preview” option to allow you to see what it’s going to attempt to do. I’m Obviously, it can’t tell when it’s going to have to “fail over” from the first SKU to the next, but at least you can see which licenses will be added and removed.

Cheers,

Ian