This is a continuation of a series of articles on Azure services from an operational engineering perspective with the most recent introduction of Microsoft Graph with the link here. The previous articles discussed the Microsoft Graph, its connectors and Data Connect. This article discusses introduces Intune. The Microsoft Graph API for Intune enables programmatic access to Intune information for our tenant. The API performs the same Intune operations as those available via the portal.  It just behaves like another service that provides data into the Graph API.

Microsoft Intune is a cloud-based service that manages devices and their applications. These devices can include mobile phones, tablets and notebooks. It can help configure specific policies to control applications. It allows people in the organization to use their devices for school or work. The data stays protected, and the organizational data can be isolated away from the personal data on the same device. It is part of the Microsoft’s Enterprise Mobility and Security EMS suite. It integrates with the Azure Active Directory to control who has access and what they can access. It integrates with Azure Information Protection for data protection.

Since it is a cloud service, it can work directly with clients over the internet, or be comanaged with Configuration Manager and Intune. The rules and configuration settings can be set on personal, and organization owned devices to access data and networks. Authenticated applications can be deployed on devices. The company information can be protected by controlling the way users' access and share information. The devices and applications can be made compliant with the security requirements. The users must opt into the management with Intune using their devices. Users can opt in for partial or full control by organization administrators. These administrators can add and assign mobile apps to user groups and devices, configure apps to start or run with specific settings enabled and update existing apps already on the device, see reports on which apps are used and track their usage and do a selective wipe by removing only organization data from apps. App protection policies include using Azure AD identity to isolate organization data from personal data, helping secure access on personal devices, and enrolling devices.

Intune makes use of app protection policies and device compliance policies to protect data. It uses profiles and configuration policies to protect data. It uses applications and application configuration policies to manage applications. It saves the device compliance results to Active Directory for conditional access. It uses groups from Active Directory for regulating all the activities it performs for users. The authentication and authorization helper libraries that work with Active Directory, are used by SaaS applications and Office 365 to integrate with Application stores and device experiences.  In a way, Intune works like a collection of microservices instead of a monolithic control and state reconciliation plane. The end-user devices make use of Network access control partner, Mobile Threat defense connector, and Telecom expense management routines to connect with the microservices that protect data and configure devices.

The technology behind the software updates, push notifications is not a new one. The benefits of synchronization over an always-online solution are quite clear – reduced data transfer over the network, reduced loads on the enterprise server, faster data access, increased control over data availability. But it is less understood that there are different types of synchronization depending on the type of data.  For example, the synchronization may be initiated for personal information management (PIM) such as email, calendar entries, etc. as opposed to application files. The latter can be considered artifacts that artifact-independent synchronization services can refresh. Several such products are available, and they do not require user involvement for a refresh. This means one or more files and applications can be set up for synchronization on remote devices although they are usually one-way transfers.

Data synchronization, on the other hand, performs a bidirectional exchange and sometimes transformation between two data stores. This is our focus area in this article. The server data store is usually larger because it holds data for more than one user and the local data store is usually limited by the size of the mobile device. The data transfer occurs over a synchronization middleware or layer. The middleware is set up on the server while the layer hosted on the client. This is the most common way for smart applications to access corporate data.

Synchronization might be treated as a web service with the usual three tiers comprising of the client, the middle-tier, and enterprise data. When the data is synchronized between an enterprise server and a persistent data store on the client, a modular layer on the client can provide a simple easy to use client API to control the process with little or no interaction from the client application. This layer may just need to be written or rewritten native to the host depending on whether the client is a mobile phone, laptop, or some other such device. With a simple invocation of the synchronization layer, a client application can expect the data in the local store to be refreshed.

The synchronization middleware resides on the server, and this is where the bulk of the synchronization logic is written. There can be more than one data store behind the middleware on the server-side and there can be more than one client from the client-side. Some of the typical features of this server-side implementation includes data scoping, conflict detection and resolution, data transformation data compression, and security. These features are maintained with server performance and scalability. Two common forms of synchronization middleware are a standalone server application and a servlet running in a servlet engine.  The standalone server is more tightly coupled to the operating system and provides better performance for large data. The J2EE application servers rely on an outside servlet engine and are better suited for high volume low payload data changes.

The last part of this synchronization solution is the data backend.  While it is typically internal to the synchronization server, it is called out because it might have more than one data stores, technologies, and access mechanisms such as object-relational mapping.