What is the TDX MDM Integration?

The TDX MDM Integration is a custom-built application that retrieves information about MSU Denver-managed devices from the TDX ITS Assets/CIs application, transforms it and sends it to the respective mobile device management system (MDM). This information then fuels device provisioning by organizing devices into various building, room, department and provisioning type groups. This allows us to target applications, policies and configuration profiles in a variety of ways. This application also facilitates automatic decommissioning to prepare large amounts of devices to leave the university.

Who is this information for?

While this system is used by technicians who need to prepare managed devices, reading this article is not necessary to follow the provisioning and decommissioning processes. Instead, this article aims to to inform future Desktop Systems Engineers about this application so they can maintain it. It may also be useful for other universities who wish to modernize their device management processes.

Prerequisite reading

In order to better understand this integration, readers should first review the technician guides for provisioning and decommissioning devices. Note, these articles require sign-in are only visible to members of ITS.

How do I provision a Windows computer?

How do I provision a macOS Computer?

How do I provision an Android device?

How do I decommission a Windows computer?

How do I decommission a macOS computer?

Components

Required

These components are essential to this integration. Although the core concepts could be applied to any MDM, this integration relies heavily on APIs from the following:

• Jamf Pro: to manage macOS, iOS and iPadOS devices.
• Microsoft Intune: to manage Windows and Android devices.
• Windows Autopilot: Windows device hashes are uploaded by a hardware vendor or manually by a technician which in turn joins the device to Entra and enrolls it in Intune management. Almost all the actions taken by this integration on Windows devices are performed on Autopilot records since they persist between re-provisioning.
• Microsoft Entra: this integration was built specifically to support the migration of Windows computers from co-management and hybrid-join to Entra-join and Intune-management. Autopilot has limited support for hybrid-joined machines and the device naming portion of this integration will not work for them.
• TeamDynamix Asset Management: provides a central database to store information about devices. Several custom attributes were created:
  • Operating System: allows a technician to select the OS for a device. This could in theory be stored in the product model but since full model information is not returned in webhooks from TDX, it would take an extra API call every time. This also let's us customize the provisioning types that appear beneath this field in the asset form.
    • Windows
    • macOS
    • iOS
    • Android
  • Provisioning Type: broadly categorizes a device into several buckets. This is roughly equivalent to the different "images" we used in the old system. Each provisioning type is assigned a set of standard applications and policies such as Microsoft Office and Adobe Acrobat with shared device licensing for Multi User and Classroom/Lab. For more information, see the provisioning articles above. Some special case types have been excluded for brevity.
    • Single User
    • Multi User
    • Classroom/Lab - Student
    • Classroom/Lab - Instructor
    • Kiosk
    • Digital Sign
    • Manual
  • Room number: TDX includes a built-in location field that uses a combination of building and room number. This field must be pre-populated by a TDX admin however. Since MSU Denver operates on a shared campus (Auraria), we do not have a master list of all our rooms. This custom attribute allows a technician to enter a room number if it's not found in the pre-populated list.

Not strictly required

These components are used in this integration and provide a great benefit to us but there are workarounds without them:

• TDX iPaaS (Integration platform as a service): a cloud-based service that allows us to build automated flows that can be triggered by other systems. Similar to Microsoft Power Automate but more advanced. See FAQ below.
• Apple School Manager/Apple Business Manager: Apple uploads device records at the time of purchase which in turn enrolls them into our Jamf Pro instance during provisioning. Devices could be enrolled in Jamf manually without this. We don't use any of the ASM APIs in this integration (yet).
• Google Zero Touch: Android device records are uploaded by a hardware vendor which in turn registers the device with Entra and enrolls it in Intune management during provisioning. Devices could be enrolled manually without this.
• Dell computers: the Windows decommissioning flows rely on a Dell-specific script to remove the BIOS password from the computers. This would need to be modified for other manufacturers if needed.
• Active Directory: this integration deletes existing computer records in AD during decommissioning. This is only needed during our transition to the cloud.

Credentials

These credentials are needed to run the application and come in different forms depending on the system. MSU Denver Systems Engineers should refer to the Secret Server for actual passwords and keys.

• TDX API User: used to perform all actions for TDX Assets/CIs. The built-in API user can be used or a special account with limited permissions can be created.
• Jamf Pro API Client: used to perform Jamf pro actions. Generally, it should have access to perform management commands and update inventory records for both devices and computers.
• Entra App Registration: used to perform all Entra and Intune related actions. This app registration should have the following permissions granted with admin consent in the application context:
  • Device.ReadWrite.All
  • DeviceManagementConfiguration.ReadWrite.All
  • DeviceManagementManagedDevices.PrivilegedOperations.All
  • DeviceManagementManagedDevices.ReadWrite.All
  • DeviceManagementServiceConfig.ReadWrite.All
  • Directory.ReadWrite.All
• Google Cloud Service Account: used to perform Google Zero Touch actions. A Google Cloud project must be created to contain the service account and control its access to the Android Device Provisioning Partner API. Additionally, service accounts must be granted permission by Google using a request form. See https://developers.google.com/zero-touch/guides/customer/service-accounts for more information.
• Active Directory Service Account: used to delete AD computer records.

Triggers

These serve as entry points to the application. Information is sent from a primary system to a specific flow in the iPaaS application.

Webhooks

• TDX Assets/CIs: webhooks can be configured in TDX Assets/CIs to fire whenver an asset record is changed. "Changed" could be a technician updating one or many attributes in a record or as simple as leaving a comment in the feed. This is the primary way the application is triggered to do something. The webhook should be configured to call the API endpoint of a single iPaaS flow known as Webhook Receiver - TDX Assets. This is known as the "mother flow" and directs traffic to some of the other flows based on the operating system and whether the device needs to be provisioned or decommissioned.
• Jamf Pro Devices: this webhook is produced directly by Jamf Pro whenever a device is enrolled or re-enrolled into Jamf. It calls the iPaaS flow Provisioner - iPad. Note: this webhook is not triggered for computers.
• Microsoft Graph: known as "subscriptions" in Microsoft terminology, this is triggered any time membership to the Entra security group Intune - Android - Named incorrectly is changed. The iPaaS flow Webhook Receiver - Microsoft Graph - Android - Provisioning is called by this webhook. This subscription is created once using the iPaaS flow Webhook Creator - Microsoft Graph - Android and kept alive continually by the iPaaS flow Webhook Receiver - Microsoft Graph - Android - Lifecycle. See https://learn.microsoft.com/en-us/graph/change-notifications-lifecycle-events?tabs=http for more details.

Local scripts

• macOS - Provisioning - Start: during macOS setup, a local bash script is run following enrollment. This script calls the iPaaS flow Provisioner - macOS to do the work of updating device inventory. Since Jamf is fast and because we can control the exact order that things are executed during macOS setup, this works well and allows us to run the flow on-demand only when a device is being provisioned. Unlike Windows machines where we have no control over the order that things are executed during Autopilot.
• Windows - Dell BIOS Password Remove & Decommission: this is a PowerShell script that removes the BIOS password from Dell computers. The last step of the script calls the iPaaS flow Decommissioner - Windows - Wipe to continue with the decommissioning process.

Provisioning

Windows

The Webhook Receiver - TDX Assets flow calls the Provisioner - Windows flow when asset records are changed in TDX. The flow does the following:

1. Checks the TDX record for accuracy:
   1. If "Single User" was selected for the Provisioning Type and the record is missing an Owning Acct/Dept or an Owner, then the technician is notified and the flow is stopped.
   2. If something other than "Single User" was selected for the Provisioning Type and the record is missing an Owning Acct/Dept, Location, or Room Number, then the technician is notified and the flow is stopped.
2. Checks to see if the device has a record in Autopilot using the serial number.
   1. If there are none, the flow stops and notifies the technician to upload the hash.
   2. If there are multiple, the flow stops and notifies the technician to fix the duplicates.
   3. If there is one, the flow continues.
3. Checks to see if the Autopilot display name matches the TDX asset name. If not, then it updates it.
4. If the device has an associated Intune record (if the device has already been provisioned) and the Intune device name does not match the TDX asset name, then it updates it.
5. Checks to see if the provisioning type is set to "Teams Room". If so, then it adds the group tag "MTR-" to the Autopilot record. This is a special case specific to Windows-based Teams Rooms and allows it to be detected by the Teams Rooms Pro Management System.
6. Determines the names of the Entra security groups the device should belong to based on provisioning type, owning acct/dept. and location. Teams Rooms are not given a provisioning-type group since they are managed by a dynamic group. Single user machines are not given a department or combination/room group since this would produce many groups unnecessarily and users can be targeted for apps and policies using user groups instead.
   1. Provisioning type:
      • "[System] - [OS] - [Provisioning Type]"
      • e.g. Intune - Win - Multi User
   2. Department:
      • "[System] - [OS] - [Provisioning Type] - [Department]"
      • e.g. Intune - Win - Multi User - Biology
   3. Building:
      • "[System] - [OS] - [Building]"
      • e.g. Intune - Win - SI - Science Building
   4. Combination/room:
      • "[System] - [OS] - [Provisioning Type] - [Department] - [Building abbreviation] - [Room number]"
      • e.g. Intune - Win - Multi User - Biology - SI - 1099
7. Creates any groups that do not exist. Groups are given the description: "IPAAS MANAGED GROUP: Do not alter this group, it is being managed by a TDX iPaaS flow."
8. Adds the device to any groups it wasn't already a member of and removes it from any groups it should no longer be a member of. The integration ignores any groups that do not have "IPAAS MANAGED GROUP:" in the description field.
9. Updates Extension attribute 1 on the device's Entra record with the current date and time for troubleshooting purposes.
10. Updates the TDX attribute MDM Integration Result to "✅Success".

Mac

During provisioning, directly after a macOS computer is enrolled, it will run the macOS - Provisioning - Start script and call the Provisioner - macOS flow in iPaaS. The flow does the following:

1. Looks up the device in TDX Assets using the serial number.
2. Checks the TDX record for accuracy:
   1. If "Single User" was selected for the Provisioning Type and the record is missing an Owning Acct/Dept or an Owner, then the technician is notified and the flow is stopped.
   2. If something other than "Single User" was selected for the Provisioning Type and the record is missing an Owning Acct/Dept, Location, or Room Number, then the technician is notified and the flow is stopped.
3. Using the Owning Acct/Dept attribute in TDX, searches for the department in Jamf. If it does not exist then it creates it.
4. Using the Location attribute in TDX, searches for the building in Jamf. If it does not exist then it creates it.
5. Sets the following Jamf attributes:

Note: note all fields are set for all assets. For example, only Single User machines receive user/owner information and do not require a room number.

6. Returns the Asset Name and Provisioning Type to the script running locally on the Mac.
7. Updates the TDX attribute MDM Integration Result to "✅Success".

iPad

During provisioning, directly after an iPad or other iOS device is enrolled, Jamf will send a webhook to the Provisioner - macOS flow in iPaaS. The flow does the following:

1. Looks up the device in TDX Assets using the serial number.
2. Using the Owning Acct/Dept attribute in TDX, searches for the department in Jamf.
3. Using the Location attribute in TDX, searches for the building in Jamf.
4. Sets the following Jamf attributes:

TDX Attribute	Jamf Attribute
Name	Mobile Device Name
Name	Asset Tag
Owner: PrimaryEmail	Username
Owner: PrimaryEmail	Email Address
Owner: Full Name	Full Name
Owner: Title	Position
Owner: WorkPhone	Phone
Owning Acct/Dept (Jamf lookup/creation in step 2)	Department
Location (Jamf lookup/creation in step 3)	Building
Location Room or Room Number (custom attribute) (preference is on Location Room)	Room
Status	TDX Status (extension attribute)
Provisioning Type (custom attribute)	Provisioning Type (extension attribute)

5. Updates the TDX attribute MDM Integration Result to "✅Success".

Android

Part 1: Configuration update

Technicians update the TDX Asset record and select a Provisioning Type. This causes TDX to send an "Asset Changed" webhook to the iPaaS flow Provisioner - Android. The flow then does the following:

1. Searches for the device in Google Zero Touch using the serial number or the IMEI.
2. Sets the device configuration (enrollment profile) in Google Zero Touch to match the Provisioning Type in TDX.
3. The technician begins provisioning the device.

Part 2: Rename and group

Technicians turn on the device and allow it to run through the Android set up process. When the device is enrolled in Intune, it receives a device name similar to "username_AndroidEnterprise_5/12/2025_4:42 PM". Entra dynamically adds it to the security group Intune - Android - Named incorrectly. The iPaaS flow Webhook Receiver - Microsoft Graph - Android - Provisioning is subscribed to receive webhooks whenever membership to this group changes. The flow then does the following:

1. Searches for a TDX Asset record with a matching serial number.
2. Sets the device name in Intune to match the asset name in TDX.
3. Determines the name of the Entra security group the device should belong to based on provisioning type, owning acct/dept. and location. Only one group type is created:
   1. Format: "[System] - [OS] - [Provisioning Type] - [Department]"
   2. Example: Intune - Android - Single User - Standard - Biology
4. Creates the group if it does not exist. Groups are given the description: "IPAAS MANAGED GROUP: Do not alter this group, it is being managed by a TDX iPaaS flow."
5. Adds the device to the group.
6. Updates Extension attribute 1 on the device's Entra record with the current date and time for troubleshooting purposes.
7. Updates the TDX attribute MDM Integration Result to "✅Success".

Decommissioning

​Windows

Part 1: BIOS Password Removal

Technicians select the Decommission checkbox on the TDX Asset records they wish to decommission automatically. This causes TDX to send an "Asset Changed" webhook to the iPaaS flow Decommissioner - Windows - Remove Autopilot & BIOS Password. The flow then does the following:

1. Checks to see if the device has a record in Autopilot using the serial number and deletes any records it finds.
2. Checks to see if the manufacturer is Dell. If not, then an error is reported and the flow is stopped.
3. Searches for the serial number in Intune. If there are no results then it updates the TDX attribute MDM Integration Result to "⛔Decommissioned". Otherwise, the flow continues.
4. Gets the Entra object ID of the most recently checked-in Intune device record with a matching serial number and adds it to the Entra security group Intune - App - Dell BIOS Password Remove & Decommission.
5. The BIOS-Password-Detect-Decomm.ps1 script is contained within a Win32 Intune application called Dell BIOS Password Remove & Decommission and is assigned to this security group as required.
6. When the computer checks in with Intune, the script runs and removes the BIOS password if present and then calls the iPaaS flow Decommissioner - Windows - Wipe.

Part 2: Wipe

1. The iPaaS flow Decommissioner - Windows - Wipe then does the following:
2. Searches for the asset record in TDX using the serial number.
3. Using the Entra Device ID provided by the local PowerShell script, gets the Intune device record.
4. If the machine is running Windows 10, the Intune device record is deleted, an error is reported and the flow is stopped. The technician must decommission the machine manually.
5. If the machine is not running Windows 10, then it calls Intune to send the wipe command to the machine.
6. The flow then checks the status of the command until the device record is deleted which indicates success. The time between checks is determined by an exponential backoff function. The time increases exponentially by powers of two until 9 hours have passed. In which case an error is reported and the flow is stopped. https://en.wikipedia.org/wiki/Power_of_two#First_64_powers_of_two.
7. Double checks that there are no more Intune device records that match the reported serial number and deletes any that it finds along with the associated Entra record.
8. Updates the TDX attribute MDM Integration Result to "⛔Decommissioned".

Mac

Technicians select the Decommission checkbox on the TDX Asset records they wish to decommission automatically. This causes TDX to send an "Asset Changed" webhook to the iPaaS flow Decommissioner - macOS. The flow then does the following:

1. Looks up the computer in Jamf using the serial number.
2. Checks to see if the computer exists in ASM (Apple School Manager). If it does, then it calls Jamf to send the "disown" command to release the device from ASM.
3. If the computer does not exist in ASM or Jamf, then it updates the TDX attribute MDM Integration Result to "⛔Decommissioned".
4. If the computer does exist in Jamf it will call Jamf to send the wipe command to the computer.
5. Checks every 20 seconds to see if the wipe command was successful or not. The flow will quit and report an error if the command fails three times.
6. Deletes the Jamf computer record.
7. Double checks that there are no more Jamf computer records associated with the serial number. If so, it updates the TDX attribute MDM Integration Result to "⛔Decommissioned".

iPad

Not in production yet.

Android

Technicians select the Decommission checkbox on the TDX Asset records they wish to decommission automatically. This causes TDX to send an "Asset Changed" webhook to the iPaaS flow Decommissioner - Android. The flow then does the following:

1. Searches for the device serial number in Google Zero Touch.
2. Removes the configuration (enrollment profile) from the device record. This prevents the device from automatically enrolling in Intune after a factory reset.
3. Searches for the device record in Intune using the serial number.
4. Calls Intune to wipe the device.
5. The flow then checks the status of the command until the device record is deleted which indicates success. The time between checks is determined by an exponential backoff function. The time increases exponentially by powers of two until 15 loops have been completed. In which case an error is reported and the flow is stopped. https://en.wikipedia.org/wiki/Power_of_two#First_64_powers_of_two.
6. Double checks that there are no more Intune device records that match the reported serial number and deletes any that it finds along with the associated Entra record.
7. Updates the TDX attribute MDM Integration Result to "⛔Decommissioned".

Using the groups

The primary outcome of the provisioning portion of this integration is the ability to assign applications, policies and configurations to any number of device identities. Groups of devices can be targeted in a number of ways:

• All Single User machines receive the Microsoft Office suite with named-user licensing via the Intune - Win - Single User Entra security group and Single User smart computer group in Jamf.
• All Multi User machines receive Microsoft Office with shared-device licensing via the Intune - Win - Multi User Entra security group and Multi User smart computer group in Jamf.
• Windows machines receive wallpaper and lockpaper images that match the building they are assigned to via the building groups, e.g. Intune - Win - SI - Science Building.
• Departmental computer labs receive specialized software. For example, all Engineering department classroom/lab computer receive AutoCAD through the Intune - Win - Classroom/Lab - Student - Department of Engineering and Engineering Technology group.

There are differences between Intune and Jamf in the way these groups are created and managed. In Jamf, smart device groups are created by a systems engineer and the criteria is set to include devices based on their Jamf attributes. Jamf automatically sorts the device into these groups. This works well because we have a smaller number of devices in Jamf than we do in Intune. In Intune, groups are created on-demand by the TDX MDM Integration and membership is managed by the integration as well. Whenever a Windows or Android asset record is updated in TDX, the integration is triggered and the groups are updated. This allows us to manage a large number of devices in shared spaces.

Error handling

The integration was designed to handle most (but not all) of the problems that can occur during the provisioning and decommissioning process. When an error occurs that prevents a flow from continuing, a comment is left on the TDX asset record and the technician who last modified the record is notified.

Example notifications:

FAQ

Why was this application created?

Many organizations across the globe want to migrate away from on-premise systems towards cloud-based systems (for better or for worse). MSU Denver is no exception. After the 2020 pandemic, remote work became normalized and as our managed devices moved off-campus, they lost communications with some of our management systems. This caused issues when our users needed to change their password, install applications, or receive support. From a security perspective, we also lost some important visibility like the device's last check-in time and compliance policy evaluation. To solve this, the Desktop Systems Engineering team sought to migrate from our existing on-premise Windows MDM, Microsoft Configuration Manager (SCCM, MECM, SMS) to Microsoft's cloud solution, Intune. But there was a big problem: Intune doesn't have a front-end for provisioning.

The standard for Windows device provisioning at the time was an SCCM task sequence. Using a 3rd-party product called "OSD FrontEnd", we were able to provide an interface for technicians to provide information about devices before the task sequence started. Technicians would manually type in a hostname, select an image and an AD OU (Active Directory organizational unit) for the device to be placed in. These options dictated what software, policies and scripts would be installed on a machine.

Microsoft Intune and Windows Autopilot however, have no such capabilities. There are no fields in an Intune device record that contain information like department, building and room number. Autopilot was designed to be much more hands-off than traditional provisioning methods. At many organizations like businesses for example, computers are shipped to users directly from the hardware vendor and applications are installed based on the identity of the person who signs in to the computer during Autopilot. Universities, however, are much more complicated due to the sheer amount of shared devices in our fleets. University IT departments can't scope applications and policies strictly based on user groups. Computer labs are usually purpose-driven and each lab has its own unique configuration. This creates a significant overhead for endpoint administrators because it requires them to organize devices based on location, department and purpose rather than just importing people information from HR.

In SCCM, applications can be scoped to OUs in AD which the technician assigns the device to at the time of provisioning. In Microsoft Intune however, all scoping is based on Entra security groups. Windows computers can be placed in security groups ahead of provisioning so long as they have an Autpilot record. But manually moving devices into multiple security groups is tedious. Especially when dealing with a large amount of devices like a computer lab with 30 machines for example. Intune supports setting a group tag on Autopilot records which you can then use to build dynamic Entra groups with. But this approach has two problems: the group tag field is just a text field which is prone to errors. Technicians can't see a list of all the appropriate group tags. Secondly, dynamic groups must be created by an admin manually. In a constantly changing environment with close to 1,000 Intune security groups alone, the task of creating groups becomes insurmountable.

It became very clear that some sort of automation was needed. Thus, the TDX MDM Integration was born.

Why not use the built-in TDX-Intune integration?

TeamDynamix provides a built-in Intune integration that allows you to sync information from Intune into TDX Assets/CIs. This integration is not suitable for us for several reasons:

• The sync operates in the Intune TDX direction instead of TDXIntune. This may be useful for organizations who don't already have an asset management system and practice. They could create asset records automatically based on the existing information in Intune. At MSU Denver, we were already using TDX Assets/CIs to record information about our devices. We needed a way to send all that information into Intune. Again, since Intune does not provide a way to record department, location and other custom fields on device records, we decided TDX Assets/CIs would be the source of truth.
• It does not create Entra security groups or manage membership. Again, this is an important automation for us in such a large environment.
• It does not set the Intune device name to match the TDX asset name.
• At the time of writing, it does not have any logic for handling duplicate Intune device records. This is common in organizations who are transitioning from co-management with SCCM to full Intune-management. This could lead to misinformation as the integration may sync information from old device records.
• There is no Jamf integration.

This integration may be complementary to our custom-built one and we may decide to turn it on one day if they fix the duplicate records bug.

Can I build this integration with Microsoft Power Automate?

Probably! Power Automate is also an iPaaS solution that has many of the same capabilities. We think TDX iPaaS is a much more robust solution however and is better suited for our needs. Power Automate may require a premium license for things like incoming webhooks which are crucial for this integration.

Can I build this integration without an iPaaS?

Yes! For Windows devices, this project was initially built using Python and PowerShell scripts running on a Windows server. For Macs, this was accomplished using a bash script that ran locally on devices. See the code on our GitHub page: https://github.com/MSUDenverSystemsEngineering/TDX-Intune-Integration-Public. We did not have a pre-iPaaS integration for iPads and Android devices however. That kind of integration would be more challenging without the cloud web server capabilities in TDX iPaaS.

Changelog

Version 1.0

Initial release. This version only managed Windows and macOS computers and relied on scripts running on a server and locally on client machines respectively. The code is located at https://github.com/MSUDenverSystemsEngineering/TDX-Intune-Integration-Public.

Version 1.1

Release #26578390

All changes

• 💡Change name from TDX MDM Integration to TDX Intune Integration.
• 💡Begin using GitHub to store code and track changes: https://github.com/MSUDenverSystemsEngineering/TDX-Intune-Integration.
• ➡️Migrate production automation server from VMWDSESRV on Nutanix to VMWAS30 on vSphere due to failing Nutanix hardware and eventual decommissioning.
• 🪲Move a function for writing the timestamp in Extension Attribute 1 from line 185 to line 193. It was part of the primary user function and would not write to the extension attribute if the device did not exist in Intune (has not been provisioned yet). The integration will now write the timestamp for devices that are only in Autopilot.

Changes impacting technicians

• 🪲Windows devices will now have timestamps in Azure Extension Attribute 1 when the integration accesses the device record even if the device has never been provisioned or is otherwise missing an Intune record but has an Autopilot record.

Changes impacting end users

• None

Changes in development

• Migration from a scripted server environment to TDX iPaaS.
• More features and enhancements such as enhanced logging and reactive updates rather than scheduled interval updates.

Version 2.0

Release #28227717

Change #28168173

All changes

• ➡️Migrate integration from PowerShell and Python files running on VMWAS30 to a TDX iPaaS flow.
• 💡Integration is now triggered from a webhook when an asset record is modified in TDX instead of on a scheduled basis. Flow will run and complete ~30 seconds after a TDX asset record is updated instead of every 5 minutes.
• 💡For machines in laptop carts, Active Directory computer accounts are now created by the integration, given service principal names and added to the "Wireless Connection" security group.
• ⚠️Criteria for TDX asset records to pass integration have changed:
  • Status is "In Use"
  • Operating System is "Windows"
  • Provisioning Type has a value and is not "Manual"
  • Owning Acct/Dept has a value
  • For Single User machines, Owner has a value
  • For provisioning types other than "Single User", Location and Location Room or Room Number have values (integration prefers the Location Room attribute in cases where both were filled in).
• 💡Comments on asset records notifying technician when record is missing information:
  • Provisioning Type is "Single User" and Owning Acct/Dept or Owner are missing values.
  • Provisioning Type is something other than "Single User" and Owning Acct/Dept, Location or Location Room/Room Number are missing values.
• 💡Comments on asset records notifying technician when certain errors occur during flow:
  • Failed to retrieve Autopilot device record
  • Autopilot device record does not exist
  • Duplicate Autopilot device records exist
  • Could not update Autopilot device display name
  • Could not retrieve Entra device record
  • Could not retrieve device's current group membership
• 🪲Devices with duplicate Autopilot records are no longer updated. Technician intervention is required.
• 🪲Asset name is updated on Intune device records instead of just on Autopilot device records (allows for name changes to happen post-provisioning).
• 🪲Duplicate security group creation has been mitigated with a lock step that prevents parallel processing on certain security group related flow steps.
• ⛔Primary user is no longer set for single user machines.
• 💡More accessible and verbose logging for Systems Engineering.
• 💡Security groups managed by this integration are now identified by text in the group description field: "IPAAS MANAGED GROUP: Do not alter this group, it is being managed by a TDX iPaaS flow."
• 💡New security group naming schema:

Old group name format

Intune - TDX - Building
Intune - TDX - Department (will be deleted)
Intune - TDX - Provisioning Type
Intune - TDX - Provisioning Type - Department - Building - Room

New group name format

Intune - Win - Building
Intune - Win - Provisioning Type
Intune - Win - Provisioning Type - Department (new group type)
Intune - Win - Provisioning Type - Department - Building - Room

Example

Intune - Win - SI - Science Building
Intune - Win - Classroom/Lab - Student
Intune - Win - Classroom/Lab - Student - Biology
Intune - Win - Classroom/Lab - Student - Biology - SI - 3099

Changes impacting technicians

• 💡Technicians no longer need to wait 5 minutes for the integration to run. Average time from asset record update to flow completion is 30 seconds. Longer wait times may occur during bulk updates to asset records with identical acct/dept., location and provisioning types where a security group does not yet exist.
• 💡Technicians no longer need to ask Systems Engineering to create Active Directory computer accounts for machines in laptop carts needing certificate-based WiFi connections. However, techs still need to ask Systems Engineering to assign the Intune policies for new laptop carts (existing carts completing a hardware refresh need not as long as assets are categorized the same).
• ⛔Since users on single user machines will no longer be the primary user of their machine, there will be no primary user listed on device records in Intune.
• 💡Technicians can now install software from the Company Portal when signed in with their accounts on a single user machine. Previously, this was restricted to only the primary user. Existing devices may still have a primary user set.
• ⚠️Technicians must enter the correct information in the TDX asset record in order for the flow to run. See above for details. Notably, location information is no longer needed for Single User devices.
• 💡When a record has missing information or terminating errors occur, a comment is added to the asset record and will notify the last technician that modified the record. Not every error or situation triggers a comment. See above for all possible scenarios.

• 🪲If a device has a duplicate Autopilot record, the flow will not run at all. The technician who last updated the asset record will be notified so they can take action. This is common for computers who have motherboard replacements.
• 🪲Since Intune device records are updated with the asset name from TDX, custom device names cannot be used. This may impact areas like Aviation and Aerospace who change hostnames in their labs or instrumentation machines like AURARIA3 in the Health Center. Hostname changes can be prevented by setting the provisioning type to "Manual". Additionally, co-managed machines are never touched by this integration.

Changes impacting end users

• ⛔ Since users on single user machines will no longer be the primary user of their machine, they cannot retrieve their own BitLocker keys from https://portal.manage.microsoft.com/. This will only impact new Intune records going forward.

Changes in development

• Device decommissioning workflows. i.e. devices can be deleted when marked for lease return, donation etc.
• One-time cleanup processes to dispose of old Intune/SCCM records left over after a device was converted to full-Intune management.