Microsoft syncs#

Overview#

This topic provides an approach to syncs with “auto filtering” for Microsoft.

Using filters in syncs#

It is recommended that you define a filtering strategy employing filtering criteria that can drive filtering on the Microsoft Graph API side.

Applying the filter on the Microsoft side in this way returns matching users only, thus minimizing the number of records that need to be processed, and reducing sync time and load on the system. For example, let’s say there are three hundred thousand users in your tenant and you only need fifty thousand users in the system to be managed. In this case, it is recommended that you apply API filtering to retrieve only the relevant fifty thousand users, while preventing import of the additional two hundred and fifty thousand records that you don’t need.

Supported fields

The following fields are supported for Microsoft Graph API filtering:

  • UPN

  • city

  • country

  • IsLicensed

  • Licenses

  • UserType

  • CompanyName

  • employeetype

  • department

  • office

  • ExtensionAttributes(1-15)

Note

  • These fields only support the equals criteria. Currently, any other criteria can’t be applied via the API call.

  • For IsLicensed, the parameter for equals must be true, and must be lower case to match. Any other value for equals is treated as false.

  • For UserType, the parameter for equals is Member by default so that external/Guest accounts are excluded.

Building your MsolUser model instance filter (MIF) with these fields and using the required criteria ensures that you’re using the API filtering in Microsoft Graph where possible.

Note

Filtering on the Microsoft Graph API is case-insensitive, which helps to prevent errors where, for example, User Principle Names (UPNs) are not uniform.

If filtering on a field or using criteria that is unsupported on the Microsoft Graph API, then this is applied within Automate after retrieving all records from Microsoft.

Filtering methods

There are two approaches to filtering:

Auto filter - filter CsOnlineUser based on MsolUser#

The Auto-filter feature for Teams/CsOnlineUser sync filters CsOnlineUser based on MsolUser. Auto filter is the recommended default if filtering is used. Auto filter simplifies setup and operations and should be reviewed as a path to move to for existing customers/systems that might have implemented other filtering approaches prior to Automate 25.1.

Auto filter provides the ability to focus filtering around the Microsoft Entra User (MsolUser) resources, which means that the system only pulls users from Teams (CsOnlineUser) if the user exists in Automate (filtering based on UPNs). As a result, you won’t sync in any Teams users that haven’t first been synced from Microsoft Entra.

Sync setup and performance is streamlined, making it easier for admins to set up and manage filters on the syncs. Admins can build effective filters for various needs, based on the rich set of fields available on Microsoft Entra User. The Teams sync utilizes this data set rather than another filter, and excludes any non-essential data. Syncing with auto filter impacts only the device/mstteamsonline/CsOnlineUser model. No other Teams models are affected.

Model instance filters and related filtering capabilities are supported for all other Microsoft Teams models, but not CsOnlineUser.

To use the auto filter, you apply filters to the O365/MSOL user sync, which has more fields to filter on, and use the Auto-filter feature for Teams/CsOnlineUser sync. This will not support additional filters on the CsOnlineUser.

The table describes the advantages and disadvantages of the Auto-filter feature for Teams/CsOnlineUser sync:

Advantages

Disadvantages

  • Focuses filter activity on the user model that has the most fields to filter on -

  • Easy to create a plan to “stamp” users if the base populated fields are inappropriate. For example, end customers can “stamp” users for managed services to their MSP.

  • Provides significant control for managing the dataset size for various reasons, such as performance or security (to only see relevant data, for instance)

  • Provides a more effective method for limiting the Teams sync and improving sync performance (not limited to filtering based on CsOnlineUser fields)

  • It is not possible to apply additional CsOnlineUser filters to the sync if you’re using the auto filter. This is due to how filtering happens on the PowerShell side, and the risk of unpredictable results.

Traditional syncs - independent filters#

Traditional syncs (using independent filters) refer to the way that syncs have typically been set up and managed in Automate. In this method, the sync is set up with separate model instance filters for the Microsoft Entra and Teams side, and you would try to align these model instance filters where possible. This sync works when a field you want to filter on is the same on each model (for example, City or Country), but are often not the ideal fields to filter on.

Advantages

Disadvantages

Can offer more control in scenarios where there is a need to have different sets of users from Microsoft Entra compared to Teams.

  • Difficult for admins to set up, to ensure accuracy, and to maintain

  • Inefficient performance

    Many filters need to be applied on Automate, which means all users are pulled then filtered.

  • Often requires trade-offs (pulling in too much data due to lack of effective fields to filter on)

Filtering and user types#

The following user types should be considered when defining filters, regardless of the approach you take:

  • Real users

  • Service accounts

The table describes filtering considerations for the user types:

User type

Considerations

Real users

Real users need to be in MS Entra to have Teams, so should not be an issue to have the user come in via Entra and identify an appropriate filter.

The goal is to minimize the users being pulled in for performance/security reasons, so identifying a filter based on your data to best achieve this.

This may be considered the base filter.

Service accounts

The potential challenge with this user type is how these users fit into the MsolUser filter.

  • Resource accounts - these often won’t have the same field(s) populated as real users (for example, City), as they are auto-created and not effectively managed. Criteria therefore needs to be added to the filter to incorporate these if they don’t fit into the “real user” filter. At the highest level, these can be filtered on the Department field to be synced in. This means all resource accounts are pulled in instead of a potential relevant sub set. However, if the Entra users for these accounts are tagged correctly then the filter can be refined.

    If all resource accounts are pulled in, this is typically a far smaller set of data and less sensitive than real users so the lack of potential filtering is probably acceptable considering the admin effort of tagging those Entra users correctly.

  • Meeting Room and Common Area Phone users - These instances will also have Entra users for each instance.

    Typically, these are more like “real users” as they need to be explicitly added, they usually have a site (location), and other business context that can be added in Entra. Thus, if they align with the “real users” filter, nothing further is required. However if they don’t align with “real users”, your base filter may need to be extended to ensure these users are encapsulated.

Important

The CsOnlineUser record for service accounts are pulled in from Teams to enable accurate inventory and management of the user accounts.

MsolUser filter logic in the model instance filter

Your MsolUser filter logic in the model instance filter (MIF) should consider the following:

  • Criteria required for “real users” based on the fields supported on MsolUser.

    This can include fields populated naturally in the directory (such as City or Country), or by using a specific tagging approach (such as ExtensionAttribute1 = Managed)

  • Criteria for service accounts (resource accounts, meeting rooms, and common area phones)

    Where these can align to the “real user” filter, this is preferred. However, if alignment is not possible, additional criteria may need to be added to the filter (for example, Department = Microsoft Communication Application Instance).

Scheduling syncs#

Consider the following with regards to scheduling syncs:

  • MS365 user sync

    • Run and complete the MS365 user sync before running the Teams user sync. This ensures that any new or removed users in Entra are in the system and can drive the auto-filter behavior during the Teams user sync.

    • Run the MS365 user sync more frequently than the Teams sync to minimize delays for user onboarding.

      The MS365 sync brings users into Automate and can then be run through the onboarding process (whether admin initiated or via flow through provisioning).

      Typically, the Teams user is not required in the system to make onboarding possible. The onboarding workflow target syncs the Teams user in during the workflow.

  • Teams user sync

    • May not need to be run as frequently as the MS365 sync.

    • If you’re performing many user transactions outside the system (such as assigning numbers), the sync may need to be more frequent, for example, to ensure the accuracy of the number inventory.

Typically, updates won’t need to be scheduled as the system updates data when records are opened. However, update syncs can be set up and scheduled as needed.