Active Directory at Charlie’s Produce had nothing useful in it. No titles, no manager fields, no department information. There was a separate company directory that HR maintained by hand, and if something in AD actually needed updating, someone had to open a Help Desk ticket and wait. That was the system. It had worked that way for as long as anyone could remember.
I had searched that directory hundreds of times and never thought much about it. Then one day it was being slow, and I finally lost it. I was going to fix this, and I was going to fix it in a way where I would never have to think about it again.
What “fixing it” actually meant
The real problem wasn’t the speed. The speed was just the thing that broke me. The real problem was that three thousand people worked at Charlie’s and nobody had an org chart. If you wanted to know who someone’s manager was, you either knew already or you asked around. HR maintained their own directory separately from IT. The Help Desk was doing manual AD updates every time someone got promoted or transferred.
None of that had to be true. ADP had all of it — titles, managers, departments, employee IDs — and it had it accurately because payroll depends on it. The data existed. It just wasn’t anywhere useful.
Getting the data out of ADP
There was no existing ADP integration. Not even a failed attempt at one. I met with ADP directly to figure out what was possible. Direct API access wasn’t something I could get, but what they could do was publish a scheduled report to an SFTP server I controlled. A flat file, on a schedule, with everything I needed.
That was enough.
The script I wrote pulled the report from the SFTP server, pulled the relevant attributes for all users out of AD, compared the two, and wrote any differences back to AD. Title, manager, department, employee ID. If ADP said something changed, AD would reflect it the next time the script ran.
The hard part: finding the key
The trickiest piece of the whole thing was finding a reliable way to match ADP records to AD accounts. You need one field that exists in both systems and means the same thing in both places. After looking at what was available, employee number was it.
The problem: employee numbers weren’t in AD yet. Before the sync could work at all, every AD account needed that field populated.
I pulled the initial ADP report and used email addresses to match it against AD accounts. That covered about 80% of the workforce automatically. The remaining 20% had to be done manually, either because their email didn’t match exactly or because something was inconsistent between the two systems. It was tedious, but it only had to be done once.
Rolling it out carefully
I didn’t run a full sync until I was confident it would behave. I carved out a test OU and ran the script against ten or twenty accounts at a time, watched exactly what it wrote, and verified the results looked right before expanding the scope. If something was wrong, it was going to be wrong for a small group I could fix in minutes, not three thousand people at once.
Most of what came up during testing wasn’t a script problem. It was data quality. Some titles didn’t match between ADP and AD, and when I dug into those, they turned out to be cases where ADP had the wrong title. The script was doing exactly what it was supposed to. It was just surfacing discrepancies that had existed for years because nobody had ever put the two systems side by side before.
Once testing satisfied me, I deployed it for everyone.
What I’d do differently
The script works, but the core logic has an inefficiency I’d change if I rebuilt it. Every run pulls a full dump of all AD users, compares everything, then writes differences. That’s a lot of unnecessary work per cycle when realistically only a handful of records change between runs.
The smarter way to do it: compare the new ADP report against the previous one, isolate what changed, then touch only those records in AD. Faster sync, smaller blast radius if something goes wrong.
At the time, getting it working correctly was the priority. Optimization was a future problem. But it’s the first thing I’d revisit.
What happened after
The morning after I deployed it, the whole company had org charts. Every user profile had a title, a manager, a department. Contact information was accurate. Things that had never existed in AD were just there.
The reaction was immediate, especially from corporate. HR didn’t have to maintain a separate directory anymore. The Help Desk stopped getting tickets for routine personnel updates. People who had never had a reason to know who I was suddenly did.
That project got me more visibility than anything else I did at Charlie’s. Not because it was the most technically complex thing, but because everyone felt it. The automation was invisible, which was the point. The result was something every person in the company used every day.