Extension Attribute scripts retaining variables?

[dewinej]

I made a pretty simple extension attribute script that lists the OU path of a computer bound to our AD:

#!/bin/sh

ad_computer_name="$(dsconfigad -show | grep "Computer Account" | awk '{print $4}' | rev | cut -c 2- | rev)"

ad_ou="$(ldapsearch -LLL -h *domain* -x -D *AD_Admin_Account@domain* -w '*password*' -b "DC=domain1,DC=domain2,DC=domain3,DC=domain4" "name=${ad_computer_name}" | grep -A1 "distinguishedName:" | tr -d '
')"

echo "<result>${ad_ou}</result>"

exit 0

I had previously used a similar script in a policy, which used the API to put the value into an extension attribute, and it worked pretty well. But I wanted to try out using a scripted Extension Attribute instead.

My problem is that the resulting EA for a computer will show up on multiple computers, instead of each having their own correct value. usually ones that check in right after each other will share the value of the first computer to check in. does the variable defined in the EA script carry over to the next computer that checks in?

[mm2270]

In short, no. What you're describing makes no sense. I'm not saying you aren't seeing what you're seeing, but that isn't how Extension Attributes work. Each machine supplies back to the server it's own EA values, that have nothing to do with any other Mac on the server. I can't imagine a situation where Mac # 2 would be grabbing the value from Mac # 1 that inventoried just before it. They are independent records, so that really shouldn't happen.

Is it possible that your script is somehow grabbing the same ad_computer_name value, and therefore when it does the ldapsearch it pulls the same information? That's the only thing I can think of in the short term in looking at your script. I assume each Mac has a unique computer name in how it was joined to AD, since usually you can't have duplicate names without causing even bigger problems.

[dewinej]

It is doing that. I appended the EA script to add the $ad_computer_name to the echoed result. The multiples show the same computer name for each computer, which is obviously wrong (but that means the $ad_ou part of the script is correct) So I guess the question then is why does this command:

dsconfigad -show | grep "Computer Account" | awk '{print $4}' | rev | cut -c 2- | rev

return the value of a different computer? and why does it only happen in groups of 3-4 that check in at about the same time?

edit: I'll add that when I ssh into these computers and run that command, the proper name returns. It also returned the proper name when that command was used in my OU policy script.

[mm2270]

I have no idea. The dsconfigad -show command should be pulling a local value from the Mac, not from anywhere on the network, not from another Mac, etc.
Honestly I'm more or less at a loss to explain how multiple machines could be pulling the same AD computer name value from that.

I'll roll this around in my head a bit to see if anything comes to mind, but, really that is a strange situation. Sorry, wish I could be of more help.

Edit: I just saw your edit above. If that's the case, then this sounds like a Jamf issue. I might open a support case with Jamf if you can and explain what you're seeing. It almost sounds like the Jamf Pro server is hanging on to a previously populated variable in that EA script and just re-using it for a machine that runs that EA shortly after. But that makes zero sense. It's never worked that way as far as I'm aware, so if it IS doing that now, then I'd consider that a defect.

[dewinej]

Now that the script has been running a while, I have some more weird results. It ran on about 500 computers. of those 500, about 80 returned the correct value. another 20 or so were little groups of 3-4 multiples. then the other 400 all returned the exact same value (and there isn't anything particularly special about the name they returned, it is just a generic lab computer) And they didn't all check in after each other, there would be 10-12 that returned the lab machine value, then 1-2 correct values, then another 15 lab machine value, etc.

[mm2270]

Yeah, as I said, something strange is happening there. That being said, I wouldn't rule out an AD issue in your environment. Although I don't see a way that dsconfigad would pull the wrong value, it's not impossible it's being sidetracked by something like a DNS issue or something like that. Unfortunately AD bound Macs and DNS/DHCP is sometimes weird in how they all work together.

Out of curiosity, if you feel confident that the local computer name and the name the Mac was joined to AD with match in most cases, can you try swapping out the ad_computer_name variable with something like this instead and see what the results are?

ad_computer_name=$(scutil --get ComputerName)

[dewinej]

That does make a difference. It is only returning a result on about 10% of the computers now, but of them all the values are correct. It's entirely possible that there is a discrepancy between Computernames and AD names. I'll have to make a policy script to check on that.

Thanks for your help narrowing this down.

edit: spoke too soon. after a couple correct values, all the checking in computers reverted back to a lab computer name (interestingly a different generic lab computer)

At this point, I'm going to have to check with my AD admins and see if perhaps its something on their end that doesn't like all these queries

[mm2270]

Sure thing.
I just remembered that most times, AD computer record names contain a trailing $ character in them, at least when a machine is joined under normal circumstances.
If you make a slight adjustment to the variable above, like this - ad_computer_name="$(scutil --get ComputerName)$" you may get more results than just 10% of them reporting back.

But even if not, I'm glad that helped narrow things down on where to look to solve this. Post back once you find out what's going on.

Edit: Arg! Sorry that didn't seem to actually be helping. Good luck on working with your AD people to track down the issue.

[dewinej]

Just as a test, I stripped out the OU part. so now the EA script simply gets the Computername and returns it as the result. The outcome was that dozens of computers still all returned the name of a random lab computer. I'm baffled.

#!/bin/sh

ad_computer_name="$(scutil --get ComputerName)$"

echo "<result>${ad_computer_name}</result>"

exit 0

[mm2270]

This just gets weirder and weirder. I can almost understand the dsconfigad -show command somehow returning the same result on multiple machines, but genuinely confused how it could happen with the scutil command. Makes no sense at all!

I'd open that support case with Jamf to see if they can provide any insight. I feel like there's some underlying issue in the server there.
What version of Jamf Pro are you using with this? Also, how are you running the test to grab these updated values again? Are you using Jamf Remote and just selected all machines and telling them to update inventory?

[dewinej]

I think I'm going to give up on EA scripting for the time being and go back to Policy scripts + API. Not sure what I'm doing wrong, but I know the other way works. I was just trying to be more efficient.

Jamf version: 10.18.0-t1576686828

I'm just waiting for the computers to check in and self-inventory.

One last weird note:

When I change something in the EA script, I delete the whole EA and start over with a new one. What seems to happen is the EA script only seems to run (or at least have a non-null result) on about 10% of the computers that are checking in. And on those first 10% or so, everything works correctly. Then, all of a sudden the lab machine name shows up populated to hundreds of computers (even computers that haven't checked in for a month). /shrug

[nstrauss]

@dewinej You're not going crazy, and it's not an issue with your script. I reported the same issue when working with EAs recently. At one point I had over 100 Macs reporting the same value for an EA which should all have been machine specific.

Turns out this is already filed as PI-007549 and as of 10.18 it's still not fixed. Quoting Jamf support...

"If multiple successive inventories for the same device are submitted, the device lookup may only contain a partial set of extension attribute values that, when persisted, result in data loss."

I wouldn't be surprised if there's a resolution in a release soon. I'd recommend opening a case with Jamf support linking to this post to explain your situation. You might want to also sign up for the beta program to get full release notes for the upcoming version. I'm in a similar situation over here waiting for it to be fixed.

[tlarkin]

This is a known issue and we have opened a ticket with jamf and jamf has created PI-007857 where EA data is mismatched and replicated to device records. In our testing, it seems a recon fixes it eventually.

[mm2270]

Thanks to both @nstrauss and @tlarkin for mentioning this known issue. I wasn't aware of this PI myself. I guess I just never ran across it because I don't have a lot of systems in our NFR Jamf Pro console, so the numbers just weren't there to have seen it.
This is a weird one, and I hope Jamf solves it sooner rather than later. Given that device inventory information is the bedrock of how Jamf Pro operates, in terms of Smart Groups and such, an issue like this has to be causing a lot of problems in larger Mac environments. Ugh.

[sdagley]

+1 on seeing this issue. And yeah, it's a Very Bad Thing™ if you can't trust your EA results.

[ddelisser]

We're also seeing this on multiple machines which has caused us to delay pushing out a script in fear of the wrong information being reported & altered. Version: 10.18.0-t1576686828

[tlarkin]

@mm2270 If you are only using EAs for reporting and not taking action on things or using them for unique data you might not catch that. We are capturing unique agent IDs and shipping them to our product, and well, we caught duplicate data. This bug seems to happen more often on non active devices, and when devices finally check in and recon they sometimes seem to fix themselves. However, any data integrity issue can be hard to fully understand the impact and it may be affecting other things that we aren't fully aware of yet

[valkyrie]

I think I'm going to give up on EA scripting for the time being and go back to Policy scripts + API. Not sure what I'm doing wrong, but I know the other way works. I was just trying to be more efficient.

I've been seeing the same issue, and also didn't have a clue what was causing it. It's a bit of a relief relief that I'm not the only one with this issue.
@dewinej I spent all day yesterday trying to get an EA to give me the correct output, but gave up on it in the end. You're talking about policy scripts + API. I thought policy results and API don't go together? My network team needs to be able to read an IP-address (which is given as the policy result) through the API. Is this possible after all?

[spalmer]

I just discovered we are seeing the same thing this morning. I was just about to start enabling Self Service policies for Microsoft Office for all 5,700 or our Macs that were scoped to an EA we created based on Paul Bowden's script to return the Office License type. Thankfully I caught this before making these policies available.

I think our issue is probably related more to the PI-007857 that @tlarkin mentioned. I looked at seven recently created extension attributes and in each case I found that Macs that had not run inventory since before that extension attribute was created have values in those fields. These are EAs that I created a few months ago and Macs that haven't run inventory in over a year or were unmanaged before those were created are reporting values when they can't possibly have any value in that EA field.

[valkyrie]

Turns out this is already filed as PI-007549 and as of 10.18 it's still not fixed.

@nstrauss PI-007549 is supposed to be fixed in Jamf 10.19. Are you still seeing this issue? I'm still on 10.18, but that would be a valid reason to upgrade to 10.19 sooner.

I think our issue is probably related more to the PI-007857 that @tlarkin mentioned.

@spalmer Where did you find info on PI-007857? A search on the known product issues page turned up nothing for me.

[spalmer]

@valkyrie it was mention by @tlarkin earlier in this discussion.

https://www.jamf.com/jamf-nation/discussions/34767/extension-attribute-scripts-retaining-variables#r...

This is a known issue and we have opened a ticket with jamf and jamf has created PI-007857 where EA data is mismatched and replicated to device records. In our testing, it seems a recon fixes it eventually.

Jamf support confirmed we are likely hitting PI-007857. They have stated the fix has been identified and will be in the 10.20 release.

[beeboo]

any alternatives for writing the ea? no idea where else to place the data.

suggestion would be to write it to a tmp file and just have the EA write the result of that vs running the actual script itself.

[tlarkin]

In our initial testing in the 10.20 beta, this does seem to be fixed, FYI Please test on your own and give feedback