美好的一天，％用户名％！
在任何大型公司中（不仅是大型公司），人们都希望随时随地尽可能简单地访问公司信息（工作邮件，日历，内部资源）。 已经创建了称为“移动设备管理”的单独解决方案来提供和管理这些访问。
从历史上看，我们在公司中使用不同的解决方案来管理移动设备。 最初，这是为特定制造商量身定制的解决方案，然后我们切换到另一种产品，该产品使我们能够支持iOS和Android设备。 随后，决定从Microsoft切换到解决方案。
微软风采
在分析解决方案功能时，云版本提供了相当小的功能列表，因此决定使用Intune Hybrid。
什么是Intune Hybrid？
这是与Microsoft Intune集成的旧系统中心配置管理器。 该解决方案具有自己的特点：
- 所有移动设备管理都通过SCCM进行。
- 所有安全策略和配置都是通过SCCM创建和管理的。
总的来说，移动设备的管理与工作站的管理没有什么不同。 云部分仅用于设备和SCCM之间的通信。
决定切换到MS Intune的同时，必须将所有用户转移到新平台上。 不幸的是，我们只有5个月的迁移时间，全球已有28,000名用户。
首先，使用了破坏性最小的迁移方法，建议用户重新配置设备以使用新服务。
这种方法在某一时刻停止工作，并且用户开始被迫与以前的服务断开连接，同时阻止了对设备进行配置的能力。 这给桌面服务带来了一定的困难和额外的负担。 有关移动设备服务的未解决事件的图表清楚地显示了最活跃的迁移时间。
幸运的是，过渡是成功的-按时完成，没有出现意外问题。
Microsoft Intune在火星上的生活如何？
在迁移期间，所有支持团队都很难适应，因为管理移动设备的功能比SCCM中的功能更广泛，更方便。 但是牺牲了一些功能后，我们的服务稳定性大大提高，总的来说事件也更少。 相比之下，与以前的28,000个用户的解决方案相比，我们每月大约有700个事件，但现在的水平保持在±350个事件。
随着新版SCCM的发布，Microsoft将添加新功能，我希望他们继续投资于混合解决方案。
有什么新东西？迁移到新产品还提供了新的访问控制功能，因为Intune只是Enterprise Mobility + Security服务的一部分。 对我们来说，最重要和最有趣的功能是
条件访问和
移动应用程序管理 。
条件访问是一种服务访问控制策略。 假设有一个用户想要从个人电话连接到Exchange Online。 访问策略要求您的设备必须运行Microsoft Intune才能访问EXO。 如果此用户尝试通过iOS上的标准Mail应用程序配置邮箱，则他只会看到一条消息：“管理员要求通过Microsoft Intune控制设备。”同样，您可以控制对在Azure AD中注册的任何应用程序的访问。
移动应用程序管理是对应用程序内公司数据的管理。 此设置确定是否可以将工作文档保存在手机的内存中，或将其复制到第三方应用程序等。
这两个功能都允许用户灵活，轻松地配置安全设置。
迁移到Intune Standalone
对Microsoft的新解决方案（特别是共同管理和自动驾驶）产生了兴趣之后，我们意识到有必要切换到完全基于云的解决方案（所谓的Intune Standalone）。
在做出决定时，Microsoft已经发布了有关将用户从SCCM迁移到Intune Standalone的分步说明：
- 从SCCM导出配置并将其导入Intune。
- 迁移测试用户。
- 迁移所有用户。
- 将MDM授权从SCCM切换到Intune。
在导出/导入阶段，使用了
Microsoft本身的
解决方案 。 不幸的是，导入进展不顺利，不仅从SCCM迁移了特定的应用程序，而且还迁移了所有部署类型，从而在Intune中创建了单独的应用程序。
它看起来像这样：
此外，由于某种原因，应用程序版本也未正确导入，因此，必须手动发布所有应用程序。 使用此配置和策略，迁移没有任何问题。
测试组迁移最初，测试小组由我和我的同事组成。 我们担心用户可能会注意到他们正在迁移。 这可能会激起对桌面服务的呼叫。 但是测试表明，在配置和已发布的应用程序没有差异的情况下，用户什么都不会注意到。
迁移机制是什么？ 所需的用户已从SCCM集合中删除，该集合已在Intune订阅设置中使用。 这是通过专有集合完成的，该专有集合又与Active Directory中的组绑定。 因此，为了迁移用户，您只需要将其添加到必要的AD组中即可。
但是出乎意料的是，提供服务台访问权限以管理迁移的设备存在问题。 我创建了一个特殊角色，该角色仅具有执行其任务所需的权限。 该角色已分配给必要的组，但没有出现某些人的访问权限。 分析员许可证及其帐户均经过检查，但均无济于事。 通过Graph API检查有效角色表明存在角色，但是该人仍然没有访问权限。 经过长时间的调查，再加上Microsoft的支持，发现分析人员需要许可证（EMS E3或EMS E5中的Intune）。 而且，分析人员又需要迁移到Intune Standalone。 需求没有记录在案，花了几周时间才解决。
同时，我吸引了来自一个欧洲国家的一群销售代表来迁移，他们在日常工作中积极使用VPN服务，并在迁移本身和为Intune Standalone
NDES单独配置的
服务器中运行。 正是在这一步，迁移几乎被取消，所有用户都返回了。
为了使用户能够使用VPN服务，系统会为他提供一个配置文件，该配置文件使用指定的SCEP证书（指的是根CA）来配置VPN客户端。 因此，必须提供一对证书才能进行操作。
我们只有一个证书（根CA）。
最简单的事情是假设问题出在NDES服务器中。 但是它运行良好，甚至没有收到证书请求。 在检查来自设备本身的日志时，我发现该设备甚至没有收到请求SCEP证书的必要设置。 Microsoft将这个问题升级为Intune开发人员，他们发现不仅拥有所有证书的重要性，而且还需要将所有证书和设置传递给相同的用户组和设备。 在我们的案例中，根CA已交付给所有设备，SCEP仅交付给某些设备。
因此，我们开始了一次迁移，从1000个用户增加到4000个用户。 该过程耗时4周。 我们为任何事情做好了准备（我们都知道很少有事情按计划进行）。 但是，一切进展顺利，而桌面服务的呼叫却没有激增。
过时的设备
根据我们的标准，我们努力争取移动操作系统的最低版本：
·T-1（适用于iOS）。
·T-2 for Android。
* T是目前的最新版本。
在较小程度上，这适用于iOS，因为 苹果长期以来一直支持其设备。 对于Android设备更是如此。 例如，人们仍然在超过4年的设备上使用Android 4.4.2。
在这种情况下，我们需要与当地的IT团队进行对话，以确定更换设备的时间，因为有必要在安全性和更新设备上花费的资金之间找到平衡。
接下来是什么？
决定的改变导致了内部的改变。 例如，有一些脚本用于从用PowerShell编写的过时设备中清除SCCM，现在无法使用。 在所有新解决方案中，Microsoft都在推广必须掌握的Graph API。
直到最近，报告都是基于SSRS构建的，现在我们将使用Power BI + oData Feed和Intune数据仓库中的数据。
之前我提到了条件访问和移动应用程序管理。 第一个解决方案已经实施；现在我们正在研究第二个解决方案。 我们还在测试Azure应用程序代理，以替代移动设备上的VPN。 如果有趣，我会很高兴在新文章中讲述。