Good day,% username%!
In any large company (and not only in large), people want to have access to corporate information (work mail, calendar, internal resources) at any time and as simply as possible. To provide and manage these accesses, separate solutions have been created, called Mobile Device Management.
Historically, in our company, we used different solutions for managing mobile devices. At first it was a solution, tailored for a specific manufacturer, then we switched to another product, which allowed us to support both iOS and Android devices. Subsequently, it was decided to move to a solution from Microsoft.
Microsoft Intune
At the time of the analysis of the solution functional, the cloud version provided a rather small list of possibilities, so it was decided to use the Intune Hybrid.
What is the Intune Hybrid?
This is the good old System Center Configuration Manager integrated with Microsoft Intune. This solution has its own features:
- All mobile device management is done via SCCM.
- All security policies and configurations are created and managed through SCCM.
By and large, mobile device management has become no different from the management of workstations. The cloud portion is used only for communication between devices and SCCM.
Together with the decision to switch to MS Intune, it became necessary to transfer all users to the new platform. Unfortunately, we had only 5 months to migrate and 28,000 users around the world.
For a start, the least destructive approach to migration was used and users were recommended to reconfigure devices to work with the new service.
This approach stopped working at a certain point, and users began to forcibly disconnect from the previous service with parallel blocking of the ability to configure the device. This created certain difficulties and additional load on the service desk. The graph of open incidents on the service of mobile devices clearly shows the period of the most active migration.
Fortunately, the transition was completed successfully - on time and without unexpected problems.
How is life on Mars with Microsoft Intune?
During the migration, it was quite difficult to adapt to all support teams, as the functionality for managing mobile devices was much broader and more convenient than in SCCM. But by sacrificing some amount of functionality, we received a much greater stability of the service and fewer incidents in general. For comparison, with the previous solution for 28,000 users, we had about 700 incidents per month, now the level is kept at ± 350 incidents.
With the new releases of SCCM, Microsoft is adding new features, and I hope that they will continue to invest their efforts in a hybrid solution.
What is new?Migrating to a new product also provided new access control capabilities, since Intune is only part of the Enterprise Mobility + Security service. The most important and interesting features for us are
Conditional Access and
Mobile Application Management .
Conditional access is a policy for regulating access to a service. Suppose one user wants to connect from a personal phone to Exchange Online. Access policy requires that its device must be running Microsoft Intune to access EXO. If this user tries to set up the mailbox through the standard Mail application on iOS, he will see only one message: “The administrator requires that the device be managed through Microsoft Intune.” Similarly, you can control access to any application registered in Azure AD.
Mobile Application Management is the management of corporate data within the application. It is this setting that determines whether working documents can be saved in the phone’s memory, copied to third-party applications, and so on.
Both of these functions allow users to customize security settings in a flexible and painless manner.
Migration to Intune Standalone
Interested in new solutions from Microsoft, in particular co-management and autopilot, we realized that it was necessary to switch to a completely cloud-based solution (the so-called Intune Standalone).
At the time of the decision, Microsoft had already published a step-by-step instruction on the migration of users from SCCM to Intune Standalone:
- Export configurations from SCCM and import them into Intune.
- Migration test users.
- Migrate all users.
- Switch MDM Authority from SCCM to Intune.
At the export / import stage, a
solution from Microsoft itself was used . Unfortunately, the import did not go very well and not only specific applications were migrated from SCCM, but also all deployment types by creating separate applications in Intune.
It looked like this:
Moreover, for some reason, the version of the application was also not imported correctly and because of this it was necessary to publish all applications manually. At the same time, configurations and policies were migrated without any problems.
Test group migrationInitially, the test group consisted of my colleagues and me. We were afraid that users might notice that they are migrating. This could provoke a wave of calls to the service desk. But testing has shown that in the absence of a difference in configurations and published applications, users do not notice anything.
What was the mechanism of migration? The required user was removed from the SCCM collection, which was used in the Intune subscription settings. This was done through the exclusive collection, which, in turn, was tied to a group in Active Directory. Accordingly, in order to migrate the user, you just had to add him to the necessary AD group.
But unexpectedly, there were problems with providing access to the Service Desk for managing migrated devices. I created a special role that had only the rights necessary for its tasks. The role was assigned to the necessary group, but access did not appear for some people. Analyst licenses and their accounts were checked, but all was in vain. Verifying effective roles through the Graph API showed that there was a role, but the person still did not have access. After a lengthy investigation with the support of Microsoft, a need was found to have a license (Intune in the EMS E3 or EMS E5 package) for analysts. And also, analysts, in turn, need to be migrated to Intune Standalone. The need was not documented and it took a couple of weeks to resolve.
In parallel, I brought to the migration a group of sales representatives from one European country who actively use the VPN service in their daily work and run in both the migration itself and the
server separately configured for the Intune Standalone
NDES . It was at this step that the migration was almost undone with the return of all users back.
In order for the user to use the VPN service, a profile is delivered to him that configures the VPN client using the specified SCEP certificate that refers to the Root CA. Accordingly, for the operation must be a couple of certificates.
We only had one certificate (Root CA).
The simplest thing is to assume that the problem is in the NDES server. But it worked perfectly and didn’t even receive any requests for certificates. While researching the logs from the devices themselves, I discovered that the device did not even receive the necessary settings for requesting a SCEP certificate. Microsoft escalated this problem to Intune developers, who discovered the importance of having not only all certificates, but also the need for all certificates and settings to be delivered to the same groups of users and devices. In our case, Root CA was delivered to all devices, and SCEP only to specific ones.
And so, we began to migrate incrementally from 1,000 to 4,000 users in a single wave. The process took 4 weeks. We were ready for everything (we all know that extremely rarely everything goes according to plan). But everything went smoothly without a surge of calls to the service desk.
Outdated devices
In accordance with our standards, we strive for minimal versions of mobile OS:
· T-1 for iOS.
· T-2 for Android.
* T - the newest version at the moment.
To a lesser extent, this applies to iOS, because Apple has maintained its devices for quite a while. To a greater extent this applies to Android devices. For example, people still use Android 4.4.2 on devices that are over 4 years old.
In this case, we are conducting a dialogue with the local IT team to determine the timing of the replacement of devices, since it is necessary to find a balance between security and the cash costs of updating them.
What's next?
Change of decision led to internal changes. For example, there were scripts for cleaning SCCM from irrelevant devices, written in PowerShell, which are currently not possible to use. In all of its new solutions, Microsoft is promoting the Graph API, which needs to be mastered.
Until recently, reporting was based on SSRS, but now we will use Power BI + oData Feed with data from Intune Data Warehouse.
I previously mentioned Conditonal Access and Mobile Application Management. The first solution has already been implemented, we are working on the second one. We also test the Azure Application Proxy as a replacement for VPN on mobile devices. If it is interesting, I’ll be happy to tell you about it in new articles.