I don’t dream of Grouper, but if I did …

A couple of weeks ago I said we had nothing to lose by trying out a new Grouper to Active Directory group membership provisioning mechanism. Well, it turns out we actually had a lot to gain. The new solution has worked better than I could’ve dreamt. (For the record, I don’t dream of Grouper; I have been asked!)

Despite another huge number of corporate data changes at the start of September, we have not had any membership changes waiting more than a day to be provisioned and now, on day 11, we actually have no backlog at all so PSP is back to “real time” provisioning.

Chart showing monthly updates to Grouper groups, by stem, from March 2016 to September 2018

Chart showing monthly updates to Grouper groups, by stem, from March 2016 to September 2018

The fact that we have got through the entire backlog at least a week sooner than last year has surprised me, but I have a theory as to why this might be.

The obvious conclusion, which you could jump to by looking at the chart, is simply that there have not been as many changes for PSP to process this year.

There might be something in that but I also think the monthly view could be slightly misleading. When broken down by week, you can see that last year’s peak is not that much taller than this year’s – it’s just that we’re only part way through September at the moment.

Chart showing weekly updates to Grouper groups, by stem, from September 2017 to September 2018

Chart showing weekly updates to Grouper groups, by stem, from September 2017 to September 2018

My theory is that the highly effective new method of updating AD group memberships with changes in Grouper, that we’ve been using since the end of August, has allowed PSP to run through its backlog far quicker, as it’s actually had less work to do.

The PSP provisioning technology works in a three step process: ‘calc’, ‘diff’, ‘sync’.

  1. ‘Calc’: It firstly, calculates how the AD group should look, after the change from the change log has been applied.
  2. ‘Diff’: It then works out the difference between how the AD group should look and how it does look, and what needs to be done so that there is no difference.
  3. ‘Sync’. Finally, it synchronises the groups by applying the output from the the ‘diff’ step.

This is all relatively time-consuming. By using the new solution to synchronise group memberships before PSP gets around to trying, PSP has less to do as it only has to complete the ‘calc’ and ‘diff’ steps for each change and can therefore race through the change log at a much faster pace.

Nothing to lose

As a wise sage so profoundly opined, “when you ain’t got nothing, you got nothing to lose”. Thankfully, unlike Dylan’s unfortunate protagonist, we don’t have nothing but, like Miss Lonely, we do have nothing to lose.*

In case you haven’t yet realised (and I appreciate it might not be too obvious), I’m alluding to plans for lessening the impact of the corporate data changes in Grouper at the nominal changeover of the academic years.

Like a rolling stone gathering no moss, so PSP will carry on regardless. And thus we do not have nothing. But we know from experience that what we do have will be very slow for a while. And so we have nothing to lose by implementing a new, complementary method of synchronising group memberships between Grouper and Active Directory. After extensive testing and a few improvements, we believe we are now in the favourable position of being able to put this new solution into production.

This means that membership changes to existing Grouper groups will be reflected in AD much sooner than we would have otherwise expected. We know that this new method is going to be a lot quicker. What we do not know is exactly how long it will all take. We have not been able to test the sheer volume of group membership changes that will be required. We will endeavour to maintain lines of communication to keep anyone who is interested informed with progress.

We’re not selling any alibis and we’ve got no secrets to conceal, so I think it’s also worth mentioning what this new solution will not do: it will not create any new groups in Active Directory and it will not process changes to group names or descriptions. These will have to wait for PSP to catch up.

Also, as a spin-off from this new solution, I’ve developed a nice little means of synchronising the membership for a specific group. This should prove to be much quicker and more reliable than the existing mechanism for doing this.


*(Sorry, I really shouldn’t write these things late at night.)

A New Hope

With the new academic year fast approaching, we were hoping to be able to avoid a return of the delays in Grouper to Active Directory provisioning we’ve suffered for the last two years. Salvation seemingly lay in the hands of Grouper’s next generation provisioning technology but, following a saga longer than a pod race and more twisted than Darth Vader’s mind, we’ve concluded that PSP-NG is still not quite production-ready.

But was that our last hope? No, there is another.

I’ve recently begun working on something I’d been thinking about for a while. It’s not a replacement for the PSP technology but I believe it can complement it and significantly alleviate the impact of the inevitable provisioning backlog at the start of September.

Using Talend, the force behind much of the Institutional Data Feed Service, I plan to interrogate the Grouper change log to find out which groups that are provisioned to AD have had membership changes. Then, for each of those groups, I can query the Grouper database to find the complete current membership list for those groups. After a bit of jiggery-pokery, I can then push the full list of members into the corresponding group in AD.

More testing is required but I’m confident that this will be a good addition to our resistance to the problem; perhaps the most powerful weapon in our arsenal of workarounds.

This is just a prequel; you can expect the next episode before the end of the month, where we will let you know whether or not we are in a position to make this new weapon fully operational.