It looks like you're not specifying an Accept header, while Jamf Pro is capable of returning both XML and JSON, therefore you may be receiving XML or JSON when expecting the other. I don't know powershell well enough to know which you're expecting, but I'm guessing JSON, in which case line 19 should look something like the following:

$data = Invoke-restmethod -Method Get -Uri $uri$i -Credential $cred -Headers @{"accept"="application/json"}

Unfortunately the same issue. I just get our "There was a problem with" error.

I would imagine you were using XML and that it's now returning JSON. Try adding:

-Headers @{"Accept"="application/xml"}

Onto the end of your $data section.

Same thing annoyingly. This used to work perfectly.

Does anyone use a similar thing that works?

I would start by adding some write-host outputs into your script to see what you're getting. Can you post the exact output you get when you run the script? You've confirmed that the API is accessible via a web browser etc?

I normally run the below to run the script and output it to a csv file.

C:ScopedScriptsAppSyncAppSync.ps1 | Select-Object -Property DisplayName,AllJSSUsers,AllMobileDevices,LimitToUsers,Exclusions | Export-csv

I only have a csv file from when it worked which looks like the attached.

The output i get now is blank as this is all i get when i run the script.

It's the path then that's probably wrong. One way you can find out is to run the script again via the ISE, and then add a line $l and start typing in the path, powershell should offer you the options and you can then find out the correct path.

Maybe TLS changes (10.6? or 10.7? can't remember). Try adding this to the top of your code.

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12

@koalatee that could be it, I glossed over that line right at the top of my script!

Thats the one. I would have never got that in a millions years. Thank you!!