Does the Performance Matter?

Back around 2015 or so, I wrote a simple Powershell script which basically re-populates Active Directory (AD) group membership based on data procured from our central systems. Two primary AD groups in particular are synchronized to our print management system, PaperCut, which pre-provisions accounts and access so folks handling monetary transactions don't have to create accounts, etc. Side fact: in our institution AD is not the system of record (SOR) for folks' account records; there are a series of jobs I don't understand which essentially side-load AD from our SORs.

I essentially have two primary groups of users:

• Employees (current/active appointments per our HR system)
• Students (actively enrolled per our SIS system)

There are also several, smaller groups of users used for different access rights (being granted rights to handle transactions, run some data, and so forth). These smaller groups rarely have changes and so, currently, are managed on an as-needed basis (i.e. an Access Request Form).

At any rate, as the two primary groups naturally change (sometimes in major ways near the beginning of an academic term), and because I don't do it better than a machine, I wanted a way to automatically handle the account provisioning in PaperCut. It turns out that PaperCut supports synchronization with AD groups, so if the vendor supports it, why not!?

Since our AD environment isn't directly coupled to our HR and SIS systems in ways to automatically/meaningfully do this for me, I needed to come up with a way to basically batch-load an AD group. It's a simple script, and it works super well...

Import-Module ActiveDirectory  
Get-ADGroupMember -Identity OUR-ADGroupName | ForEach-Object {
    Remove-ADGroupMember -Identity OUR-ADGroupName -Members $_ -Confirm:$false
}
Import-CSV "\\path\to\our\input\list.csv" | ForEach-Object {  
    Add-ADGroupMember -Identity OUR-ADGroupName -Member $_.'USER_ID'
}

Except it takes nearly ten minutes to run (a job for each group to reload the group membership; two jobs total). Something about this felt inherently like bad practice, wrong, and dirty.

At my first MMS in 2016, an experience which has forever changed my life, I met the venerable Don Jones®. I sat in on several of his sessions that year and learned a boatload of stuff. At the opening reception after the pre-conference session, while mingling, Don and I crossed paths and exchanged a bit of small talk. Not wanting to be That Guy asking an expert to fix his problem, but trying to capitalize on the situation, I mentioned my little situation and how it bugged me, and asked for any high-level pointers I'd not considered...to improve the performance.

His initial answer was simple:

Does it matter?

You mention that the job runs overnight, once a week...so who cares if it takes ten minutes?

I was flabbergasted! You mean the process I'd conjured up wasn't totally out of line with what someone with an abundance of experience would generally agree with the process? Dude!

Don and I spent the rest of our drinks talking about some of the nuances of what I was doing and how it could be improved, but the reality of the situation was it was functionally the same. The majority of my process time overhead really related to iterating through thousands of lines of a flat input file, and the requirement for each row to be processed independently. My major takeaway from the chat was a better understanding of some limitations internal to AD itself (short version: there are some transaction "limits" of which to be aware that could cause problems). This made me feel infinitely better about the solution, while providing some insight in how I might have to change things up a bit if/as the input file grew to a certain size.

My respect for Don grew exponentially as a result of that single chat. I'm positive he has no recollection of it, which is to be expected. But here was a gentleman who took his time to explain some deep underpinnings of a technology to a relative n00b and who mentioned if he were in a similar situation he'd do the exact same thing I'd done.

Whenever I automate other jobs, especially the larger ones that run with less frequency and perhaps non-optimal performance, I always ask myself, "does the performance matter?" Especially before I try to improve beyond a certain point. As Don also shared at that MMS:

The perfect is the enemy of the good.

So jump in! Make an attempt. See how it works. Measure some performance. Make some tweaks.

Just don't try to overthink or overbuild it.

Headline image via giphy