Skip to main content

Hello all,

I’ve been trying to get our JAMF integration setup so that we can have the benefit of assigned devices but are having problems with “unassigning” them.

At first we thought we could remove the username within JAMF and the devices would drop from their assigned users - especially as we have ticked the option within general settings to:

Unassign owner if primary user is blank:Remove existing owner in iiQ for assets that have an empty primary user in jamf

This works for iPads but doesn’t work for MacBooks.  According to an email from support, the JAMF location:email_address field needs to be blank as well to unassign the asset.

Since it’d be easier to make all the changes in IIQ to remove the user from the device and have that push to JAMF, we starting testing on how to accomplish this.

location:email_address is hardcoded to map to User email one way from JAMF to IIQ.  If indeed we have to wipe that field in order to remove assignment, then the only way I can see to do this is to set a custom field mapping JAMF’s location:email_address field to IIQ’s owner email and have it feed both directions.

However when testing this, the push fails.

 

How are you all configured in order to remove assigned users?

@Carina Burns Randolph 
Reached out to our support team for more guidance. They are currently looking into this for you. They will be reaching out shortly. 😁

we created an unmanaged account manually within Jamf and IIQ and assign any devices to that “user” in Jamf when the device is not being directly used by someone

Thank you for the reply.  The hope was to unassign an asset in IIQ and not have to do an edit to the JAMF record also.  We’ve found that any items checked in end up reassigned to the previous owner with the overnight JAMF sync.

We managed to get a null email address successfully pushing back into JAMF.  This didn’t change anything however.   JAMF uses SAMAccountName to determine device ownership.  So unless we can push a value back into JAMF’s location:username, the ownership info will remain.

The only fields in IIQ within the integration app to determine ownership is Owner name (firstname lastname) or email address.

If you create a custom field in IIQ to bring in the SAMAccountName, it isn’t editable when updating an asset record.  Perhaps we can create a rule to null that field when an asset is checked in?

Yes that was our hope too, but unfortunately JAMF keeps the device assigned to the user it had before so that is why we are doing the extra step.  We were going to try to use the unmanaged vs managed field in JAMF that shows in the metadata, but unfortunately we couldn’t get that to work because it wasn’t an option to use.  We worked with IIQ but they never resolved it or got back to us.  So now the techs do the extra step of changing the user in JAMF as well to UnmanagedSchoolName so we can see what is in “storage” where.  It isn’t pretty but it is the fastest way we have found so far. 

We actually considered also not having JAMF update the ownership at all for any devices but decided it was worth the extra work to be able to know who is signed into what device so that in theory no check-outs need to happen.

Same experience here….IIQ never reached out so I created a ticket and finally got an answer yesterday.  Dev is looking into a possible update on this with JAMF but there isn’t a timeline.

I’m meeting with our Apple engineer today to see if we can put some logic in place for JAMF when a null email addy is updated...otherwise, we’ll likely also have to have each tech make a JAMF update at the same time as a device check in as well.

After advising my management, they feel like they were sold vaporware as the ability to make asset changes in IIQ and have it push to the MDM’s was touted in the sales pitches.  It’s quasi-true for Google devices but not for JAMF or SCCM.  The SCCM scripting looks at TopUser0 not primary user so we’re finding the assignments there aren’t always correct at user matching.



@Carina Burns Randolph  The SCCM query is editable.  You can switch TopUser0 to primary user and download a new version of the connector.  Our support team can certainly assist you with this if you would like to explore that change further.     

Apologies for any potential misunderstandings during the sales process.  Our integration with JamfSchool does support more robust write-back capabilities than Jamf Pro at this time which could have led to some confusion.  We do not support write-back to SCCM or any SQL based integrations.  Many of our asset integrations do allow write-back (Google Devices, JameSchool, FileWave, Mosyle, etc...), But we are limited by some MDMs where their API does not allow write functionality to certain fields.  Our product and engineering teams are actively investigating which fields may be supported specifically for Jamf Pro.  Since we’ll need to work with a third party to address any changes, we cannot commit to a timeline just yet. 

We do appreciate the feedback and detailed insights into the “on the ground” practices so we can continue to enhance our integrations and user experience.  

Thank you for the reply.

We’ve already been exploring the option to modify the SCCM script.  I noticed the issue with TopUser versus Primary user shortly after onboarding in April and worked with your help desk.  I opened ticket 3573 in May after various suggestions from your help desk didn’t resolve our problem.  As we are quickly approaching the start of the school year, and deploying IIQ to all of our staff, I’m reaching out to our onsite 1:1 support vender to see if they have an SCCM subject matter expert that can narrow down which Schema/Field needs to be brought in via the script.

Regarding JAMF and the other MDM integrations, perhaps a set of best practices with examples of commonly seen issues (device unable to sync, incorrect user assigned as owner, etc) within the integration documentation would be helpful.

Did this ever get solved? We are having this issue from jamf pro to iiq and trying to correct our inventory before it gets too far down the road.


@Carina Burns Randolph  The SCCM query is editable.  You can switch TopUser0 to primary user and download a new version of the connector.  Our support team can certainly assist you with this if you would like to explore that change further.     

Apologies for any potential misunderstandings during the sales process.  Our integration with JamfSchool does support more robust write-back capabilities than Jamf Pro at this time which could have led to some confusion.  We do not support write-back to SCCM or any SQL based integrations.  Many of our asset integrations do allow write-back (Google Devices, JameSchool, FileWave, Mosyle, etc...), But we are limited by some MDMs where their API does not allow write functionality to certain fields.  Our product and engineering teams are actively investigating which fields may be supported specifically for Jamf Pro.  Since we’ll need to work with a third party to address any changes, we cannot commit to a timeline just yet. 

We do appreciate the feedback and detailed insights into the “on the ground” practices so we can continue to enhance our integrations and user experience.  

This would be the answer for this question @CKnecht 297d660 sacs 😄

Here is an idea that is similar, and we are asking for your upvotes and comments: 

 

I don’t think I phrased my question correctly, sorry. Have the write-back capabilities with Jamf Pro been increased since this time?

@CKnecht 297d660 sacs  - Im not sure of all of these have be introduce since this post. But here are the capabilities of write backs. 

You are able to use the Remote Device Actions with Jamf Pro: 

  • Disable Lost Mode
  • Enable Lost Mode 
  • Remote Lock Device
  • Restart Device
  • Wipe Device

 

Additionally these fields as well: 

  • Following fields are supported to writeback from Incident IQ to Jamf Pro
    • location:email_address
    • location:realName
    • location:username
    • location:building
    • location:room number
    • Please note that the username field only accepts usernames for users already in Jamf.
    • If writing back to location:building, all your iiQ locations must be set up as buildings in Jamf. If Incident IQ try's to write back a value to the building field that doesn't exist as a building in Jamf, then Jamf won't update any properties on that asset. The asset will be skipped.

 

You can find how to configure these write back capabilities in the following KB guide. Hope this helps :) 

 

Reply


Terms & ConditionsCookie settings
Incident IQ logo

Incident IQ is a service management platform built for K-12 school districts, featuring asset management, help ticketing, facilities maintenance solutions, and more.

Corporate Headquarters:
750 Glenwood Ave SE, Suite 320
Atlanta, GA 30316