Concluding the story

OK, it’s taken me a few months to get around to finishing the story, but it turns out that it definitely wasn’t fewer changes that helped us get through the backlog quicker last September. Looking at the number of changes for the whole month of September, we can see that there were actually more this latest time around.

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

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

This leads me to conclude that my theory about PSP having less to do is most likely correct.

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 delay, you say?

It’s been pointed out to me that the impact of the Grouper to AD provisioning delays is actually not widely understood. I’ll try to sum it up here as explicitly as I can but please feel free to ask if I haven’t explained anything as well as you would’ve liked!

The delay is in provisioning new groups, changes to groups and changes to group memberships from Grouper to AD. There is no impact to existing groups and group memberships.

So, what could be affected by this?

Anything that uses AD groups in the ‘GrouperGroups’ OU for access control could be affected. Some of the things these groups are used directly to control access to include (but are not limited to) shared filestore, mailing lists, wifi, calendars, printers, PCs, software and the new Rocket HPC system (currently in pilot, I believe).

Additionally, AD’s GrouperGroups groups show up as a Shibboleth attribute which can be used to restrict access to any resources protected by the Login Gateway to a specific group of people. Known uses for this include Microsoft Imagine (formerly Dreamspark), some internal websites and some holiday booking systems. There could, of course, be others.

And what is definitely not affected?

There is no delay internal to Grouper so group memberships within Grouper are up to date. Anything relying on Grouper groups directly or via data feeds, such as some features of the mobile app or Chubb access to some buildings, will be fine.

What does all this actually mean?

Firstly, I hope that anyone who has chosen to use (or inherited) Grouper as an access control component of their service knows and understands how Grouper fits into their particular picture; if it includes AD then access to the service could be affected for new users.

It’s something to consider if an end user reports an access issue. For example, if a new member of staff can’t connect to their team’s shared filestore or they’re not receiving emails to a mailing list they should be on then the chances are they are a victim of the delay. If, however, they find that their smartcard won’t let them into Merz Court then that will be caused by something else.

I hope this has helped to clear up the impact of the delay but if not please let us know!

Good news for staff onboarding

One of the most common queries (and, dare I say, criticisms) we get with Grouper is about why a new member of staff is not yet in Grouper*. Expectations of our IT systems and services are so high that everyone expects everything to be set up and available ready for new staff the moment they walk through the door on their first day.

Previously, due to the timing that we receive ‘current’ staff data from SAP HR**, we weren’t loading new staff into Grouper until the night after their first day.

Well, not any more!

I’ve rewritten the way we consume SAP HR data so we now identify ‘current’ staff through a different mechanism, without the need to refer to our previous source of this information. This means that we now know, from midnight each night, who is a current member of staff for the forthcoming day. This also applies to internal staff moves; we should always have the correct, current data relating to department, job title, etc. This data is now available to any new data feeds that need up to date information on current staff***.

I’ve rewritten the job to load subjects into Grouper to take advantage of this so now any new members of staff should be in Grouper before they arrive, raring to go, on their first morning. The impact of this can be quite impressive if they happen to be in a department which really takes advantage of the power of Grouper. For example, if you use corporate data to control access to team mailing lists, shared filestores and internal websites (or anything else) then any new staff member will be able to access all of that information from the moment they log in to their shiny new PC.

(And, by the way, let’s not forget that we were already pretty hot here! Getting access to all your resources on your second day is not to be sniffed at; when a certain ex-colleague turned up for his new job at a well-known multinational software company providing open-source software products to the enterprise community, he was asked to bring in a book to read for the rest of the week!)


* I’ve just realised that we’ve never actually documented this “issue”, despite having told many, many people about it many, many times. We did, however, cover it in our ‘Getting to Grips with Grouper’ session.

** Each evening we get the details of staff whose contracts are active that day.

*** I’ll get around to reimplementing the definition of ‘current’ for People Search and NU Service, in due course. They are both also using day old definitions of ‘current’ at the moment. UPDATE: Both People Search and NU Service are now taking advantage of this development.