MI Core currently has no mechanism to communicate changes to objects to other systems. Therefore MIDA has to use Sync services to request changes from MI Core again and again.
The synchronization services of MIDA are described below:
- Label Import: Label synchronization
- Devices Import: device synchronization
- App import: App synchronization
- Policy Sync: Policy synchronization
Note: The intervals and delays are stored in the /etc/sysconfig/mida file on each individual MIDA server.
For the Device Sync the Event Notification Service can be used.
Label Workers (Import&Sync)
The Label Import imports and synchronizes all labels from the MI Core into the local MIDA database.
Since the multi-client capability of MIDA is based on the label, this service is mandatory.
This means: If this service is deactivated, all other services (Device, App, Policy) are also deactivated. If one of the other services is subsequently activated, the label service is automatically activated as well.
Label Import consists of two separate services: Label Import and Label Sync:
Label Import Service
The Label Import has two functions.
- When switched on for the first time, all labels are imported from the MI Core into the MIDA database. If a label found on the MI Core cannot be found in MIDA, it will be created in MIDA. After the first complete import the “initial_labels_import_done” flag in the database table dbo.core_config is set to true(1). From this point on MIDA uses the labels in the database.
- Subsequently, the same service imports labels created on the MI Core after the initial import.
The following configuration parameters are used:
Interval for the label import of 200 labels in milliseconds:
mida.coredata.label.import.interval
Delay for task start after MIDA server start in milliseconds:
mida.coredata.label.import.delay
Label Sync Service
The Label Sync service synchronizes the already known labels with the MI Core. Changes (e.g. description/type/LDAP filter/number of devices) and deletions are synchronized with this. The MI Core always has the higher priority. MIDA never overwrites the labels in the MI Core.
The following configuration parameters are used:
Interval for the synchronization of a label in milliseconds:
mida.coredata.label.sync.interval
Example: The default value is 1000 = 1 second. Every second a label is checked for changes.
Delay for starting this service after MIDA server startup in milliseconds.
mida.coredata.label.sync.delay
The Label Sync is also started briefly in the following cases when editing or creating objects, since MIDA data is required by the MI Core:
- Assign label to a device = Create device.
- Create / delete / edit label (not in use at FI).
Example Create device
MIDA creates the device on the MI Core, but requires further data, such as the Device UUID assigned by the MI Core and the assigned labels. This data must be requested from the MI Core for the creation of the device in MIDA.
Diagram for label import and sync:
Device Workers (Import&Sync)
The tasks of this service import and synchronize devices, device details and device labels from MI Core to the local MIDA database. If Device Import is disabled in the settings, the devices, device details and device label import and synchronization services will be disabled:
Device Import Service
The Label Import has two functions.
- When Device Import is switched on for the first time, all devices are imported from the MI Core into the MIDA database. If a device found on the MI Core cannot be found in MIDA, it will be created in MIDA. After the first complete import the initial_devices_import_done flag in the database table dbo.core_config is set to true =1. From this point on MIDA will use the devices in the database.
- Subsequently, the same service imports devices that were created on the MI Core after the initial import. For this purpose it loads page by page (200) devices from the MI Core and checks if they already exist in MIDA. The existing devices are ignored, the unknown ones are imported including the device details.
The following configuration parameters are used:
Interval for executing the import of 200 devices at a time in milliseconds:
mida.coredata.device.import.interval
Delay for start of device import after MIDA Server startup in milliseconds:
mida.coredata.device.import.delay
Flow Chart
regscan – import of devices created on the MI Core
A new service has been developed for importing devices created directly via MI Core (this includes DEP devices).
The name: regscan
Reason: The Device Import Task must have gone through all devices in MIDA to find new devices on the MI Core. This can take days due to the amount of devices.
During this time, the devices are not visible to the customer administrators and thus cannot be administered.
The process:
- Query the MI Core for the devices that were registered in the last 6 minutes.
Note: These are the devices that show a registration date, not pending devices!
- If the device (the device UUID) is already known to MIDA, it will be ignored.
- If the device is not known to MIDA, it will be taken over with the assigned labels into the
MIDA database so that it can be assigned directly to a client. This is only possible with an API v1 Call, because API V2 does not offer a similar function. Also imported are the device details known until then (API V2 Call)
This process is repeated every 5 minutes. To avoid importing duplicate devices, a lock system is also applied here.
Thus only one MIDA Server executes this task at a time. The configuration parameters for Regscan:
Param | Default value | Description |
mida.coredata.device.regscan.interval *) | 3000000 | How often should the import run |
mida.coredata.device.regscan.delay | 20000 | How long to wait after starting MIDA until the service is executed |
mida.coredata.device.regscan.query | common.registration_date>=now-6m | What is the query to the MMI Core to find the devices |
mida.coredata.device.regscan.sortBy | common.registration_date | According to which field should be sorted |
mida.coredata.device.regscan.sortOrder | DESC | What sort |
*): To implement the 5 minute check, the following parameter must be set in /etc/sysconfig/mida: -Dmida.coredata.device.regscan.interval=300000 \
The device import should continue to run with a higher value after the initial import and despite the re-scan, in order to ensure a slow but permanent synchronization of the device inventory; e.g., in the event of an MI Core failure, in which the re-scan cannot be active.
Slow Device Import (API V1) and Regscan (API V2) minimize the API V1 queries that put so much load on the MI Core.
Device Sync Service
The Device Sync Task matches the following data in the MIDA database with the MI Core:
- Device data and details (like MI Core Compliance)
- Removing devices from the MIDA database that were deregistered in MI Core directly, i.e. not with MIDA
- Each device action briefly starts the Device Sync Task to keep the data up to date
Any change to the devices label
The following configuration parameters are used:
Interval for querying the device data:
mida.coredata.device.sync.interval
Delay for the start of the device sync after the start of the MIDA server in milliseconds:
mida.coredata.device.sync.delay
Procedure:
- The device sync task runs periodically, configurable by mida.coredata.device.sync.interval
- Reading 200 devices from the MIDA database
- For each device (device UUID) the MI Core is queried for changes.
- When a change is detected, the data is transferred to the MIDA database.
Flow diagram using the example of a deregistered device:
Devices Label Sync Service
This service synchronizes the labels associated with a device to the local MIDA database.
The following configuration parameters are used:
Interval for execution in milliseconds:
mida.coredata.device.label.sync.interval
Delay for the start of this service after the start of the MIDA server in milliseconds:
mida.coredata.device.label.sync.delay
Procedure:
- The device label sync task runs periodically, configurable by mida.coredata.device. label. sync.interval
- Reading 200 devices from the MIDA database
- For each device (device UUID) the MI Core is queried for changes
- Alignment of the devices labels
- In case of a detected change, transfer the label to the MIDA database
Flowchart: A label has been assigned to a device on the MI Core:
App Workers (Import&Sync)
The tasks of this service import and synchronize apps, app details, app label, VPP and iBooks from MI Core to the local MIDA database.
If the Apps Import service is disabled in the settings, the following functions are disabled:
Apps import
The Label Import has two functions.
- When App Import is switched on for the first time, all apps from the MI Core are imported into the MIDA database. If an app found on the MI Core cannot be found in MIDA, it will be created in MIDA. After the first complete import, the initial_apps_import_done flag in the database table dbo.core_config is set to true =1. From this point on MIDA will use the apps in the database.
- Subsequently, the same service imports apps that were created on the MI Core after the initial import. To do this, it loads pages (200) of apps from the MI Core and checks whether they already exist in MIDA. The existing apps are ignored, the unknown ones are imported.
The following configuration parameters are used:
Interval for the execution of the import of the apps of 200 apps in milliseconds each.
mida.coredata.app.import.interval
Delay for the start of the import after the start of the MIDA server in milliseconds:
mida.coredata.app.import.delay
App Sync Service
This service is used to transfer app information or possible changes in the MI Core to MIDA. This task is only responsible for the apps already imported into MIDA.
The Apps Sync service splits into three tasks:
- App Data Change Detection: Detection of data changes
- App Labels Change Detection: Detection of a label change on an app
- App VPP Summaries Change Detection: detection of changes in VPP licenses
App Sync service (App Data Change Detection)
Checks the MI Core for basic app data changes (app name, description).
If a change is found, it is transferred to the MIDA database.
If the service receives a 404 error (Not found) for a request, the app is removed from MIDA.
The following configuration parameters are used:
Interval for app data synchronization for an app in milliseconds:
mida.coredata.app.sync.interval
Delay for the start of this service after the start of the MIDA server in milliseconds:
mida.coredata.app.sync.delay
App Label Sync service (App Label Change Detection)
This service synchronizes the labels associated with apps into the local MIDA database to make this information available in MIDA as well. So, it is about adding and removing labels.
The following configuration parameters are used:
Interval for the synchronization of the labels of an app in milliseconds:
mida.coredata.app.label.sync.interval
Delay for the start of this service after the start of the MIDA server in milliseconds:
mida.coredata.app.label.sync.delay
App VPP Sync service (App VPP Summaries Change Detection)
This service synchronizes the VPP Apps compilations (content VPP licenses) after an Apple App.
If a change is detected, the VPP license usage is transferred to MIDA via VPP Label.
This task is also responsible for the synchronization of the VPP labels.
The following configuration parameters are used for VPP app synchronization in milliseconds:
mida.coredata.app.vpp.sync.intervalInterval
Delay for starting this service after MIDA server startup in milliseconds:
mida.coredata.app.vpp.sync.delay
Listed here are two examples of how MIDA proceeds with actions in MIDA:
- Add an app that does not yet exist in the MI Core app catalog.
- Another client adds an app to their app catalog that already exists in the app catalog on MI Core.
1. Details when adding for apps if the app is not yet present in MIDA or MI Core.
In MIDA > Apps > Add App, select App Store and search for App, Add Label and Save.
The further course looks as follows:
- MIDA searches for the app on the MI Core.
If not yet available: - MIDA adds the app to the MI Core App Catalog with Label
- MIDA receives from MI Core the App Catalog ID of the App
- MIDA writes the app with the ID into the MIDA database
- MIDA starts the Apps Sync, App Label Task and App VPP Sync to write the app data(description, images) to the MIDA database
2. App is already available in the MI Core:
In MIDA > Apps > Add App, select App Store and search for App, Add Label and Save.
- MIDA searches for the app on the MI Core. If available, the new label is added to the app.
- MIDA starts the Apps Label service to write the label change of the app into the MIDA database.
An overview of the App Sync Tasks:
More Details
If an action is executed in MDA for an app, the corresponding sync services for this action are also executed.
- App import
- Delete apps
- Assign label (Normal and VPP)
- Remove label (Normal and VPP)
- Add and delete VPP license (not in use at FI)
iBooks Sync
Note: The following services are required for iBooks.
When creating an iBook in MIDA, first the iBook data is sent to the MI Core and the iBook is created. The MI Core answers with an ID, which MIDA needs for further management of this iBook. With this ID the iBook is created in MIDA, the iBook Sync service is started for this iBook, transferred to MIDA and can be displayed in MIDA.
The configuration parameters:
Parameter | Default value | Description |
mida.coredata.ibooks.sync.interval | 15000 | Interval for sync from an iBook in milliseconds |
mida.coredata.ibooks.sync.delay | 15000 | Delay for the iBook Sync when starting the MIDA server in milliseconds |
mida.coredata.ibooks.import.interval | 15000 | Interval for iBooks import in milliseconds |
mida.coredata.ibooks.import.delay | 15000 | Delay for iBooks Label import in milliseconds |
mida.coredata.ibooks.label.sync.interval | 15000 | interval for iBook labels sync in milliseconds |
mida.coredata.ibooks.label.sync.delay | 15000 | Delay for iBook Label Sync in milliseconds |
Policy Worker (Sync)
This service synchronizes the content of the data in the Policy Sync Configs from MI Core automatically with the local MIDA database.
Procedure:
- The MIDA Admin changes the iOS version.
- The iOS version is stored directly in the Security Policy on the MI Core and is active.
- MIDA will show the new iOS Version right away.
- This service synchronizes the content of the changes on the MI Core to the MIDA database for the admin to view.
- If there are not a lot of changes performed on the Core, this service does not needs to be enabled. Instead the refresh button on the pages can be used to pull the fresh data from MI Core to MIDA when required.
The following configuration parameters are used:
Interval for execution in milliseconds:
mida.coredata.policy.sync.interval
Delay for the start of this service after the start of the MIDA server in milliseconds:
mida.coredata.policy.sync.delay
Performance Changes
Standard socket timeout of MIDA for the services in the background
If MIDA starts an automatic query via Worker to the MI Core, MIDA waits 30 seconds before MIDA reports a timeout. The MI Core uses a timeout of 120 seconds.
MIDA now also uses this timeout value (120) before a query is reported as unsuccessful. With this, MIDA adapts to MI Core and are thus identical.
Queue for requests from MIDA administrators
With 2.5.5-Fix5, requests from tasks such as compliance checks or report creation are collected in a list and processed one after the other. This prevents too many time-consuming queries from being performed on the MI Core in the future. The number of simultaneous tasks is 4 (one for every server).