Bom dia,% username%!
Em qualquer empresa grande (e não apenas em uma grande), as pessoas desejam ter acesso às informações corporativas (correspondência comercial, calendário, recursos internos) a qualquer momento e da maneira mais simples possível. Soluções separadas chamadas Gerenciamento de dispositivos móveis foram criadas para fornecer e gerenciar esses acessos.
Historicamente, usamos soluções diferentes para gerenciar dispositivos móveis em nossa empresa. No início, era uma solução personalizada para um fabricante específico, depois mudamos para outro produto que nos permitia suportar dispositivos iOS e Android. Posteriormente, decidiu-se mudar para uma solução da Microsoft.
Microsoft intune
No momento da análise da funcionalidade da solução, a versão em nuvem fornecia uma lista bastante pequena de recursos, por isso foi decidido usar o Intune Hybrid.
O que é um Intune Hybrid?
Este é o bom e velho System Center Configuration Manager, integrado ao Microsoft Intune. Esta solução tem suas próprias características:
- Todo o gerenciamento de dispositivos móveis ocorre através do SCCM.
- Todas as políticas e configurações de segurança são criadas e gerenciadas através do SCCM.
Em geral, o gerenciamento de dispositivos móveis não se diferenciou do gerenciamento de estações de trabalho. A parte da nuvem é usada apenas para comunicação entre dispositivos e o SCCM.
Juntamente com a decisão de mudar para o MS Intune, tornou-se necessário transferir todos os usuários para a nova plataforma. Infelizmente, tivemos apenas 5 meses para migrar e 28.000 usuários em todo o mundo.
Para iniciantes, foi usada a abordagem menos destrutiva da migração e os usuários foram aconselhados a reconfigurar os dispositivos para trabalhar com o novo serviço.
Essa abordagem parou de funcionar em um determinado momento e os usuários começaram a ser forçados a se desconectar do serviço anterior com um bloqueio paralelo da capacidade de configurar o dispositivo. Isso criou certas dificuldades e carga adicional no serviço de desktop. O gráfico de incidentes abertos no serviço de dispositivos móveis mostra claramente o período da migração mais ativa.
Felizmente, a transição foi bem-sucedida - no prazo e sem problemas inesperados.
Como está a vida em Marte com o Microsoft Intune?
Durante a migração, foi bastante difícil para todas as equipes de suporte se adaptarem, pois a funcionalidade para gerenciar dispositivos móveis era muito mais ampla e mais conveniente do que no SCCM. Mas, ao sacrificar uma certa quantidade de funcionalidade, obtivemos uma estabilidade significativamente maior do serviço e menos incidentes em geral. Para comparação, com a solução anterior para 28.000 usuários, tivemos cerca de 700 incidentes por mês, mas agora o nível é mantido em ± 350 incidentes.
Com os novos lançamentos do SCCM, a Microsoft está adicionando novas funcionalidades e espero que continuem investindo em uma solução híbrida.
O que há de novo?A migração para o novo produto também forneceu novos recursos de controle de acesso, pois o Intune é apenas parte do serviço Enterprise Mobility + Security. Os recursos mais importantes e interessantes para nós são o
Acesso Condicional e o
Gerenciamento de Aplicativos Móveis .
O acesso condicional é uma política de controle de acesso ao serviço. Digamos que um usuário queira se conectar de um telefone pessoal ao Exchange Online. A política de acesso exige que seu dispositivo esteja executando o Microsoft Intune para acessar o EXO. Se esse usuário tentar configurar a caixa de correio por meio do aplicativo Mail padrão no iOS, ele verá apenas uma mensagem: "O administrador exige que o dispositivo seja controlado pelo Microsoft Intune". Da mesma forma, você pode controlar o acesso a qualquer aplicativo registrado no Azure AD.
Mobile Application Management é o gerenciamento de dados corporativos dentro do aplicativo. É essa configuração que determina se é possível salvar documentos de trabalho na memória do telefone, copiá-los para aplicativos de terceiros e assim por diante.
Ambas as funções permitem a configuração flexível e indolor do usuário das configurações de segurança.
Migração para o Intune autônomo
Depois de nos interessarmos por novas soluções da Microsoft, em particular o co-gerenciamento e o piloto automático, percebemos que era necessário mudar para uma solução totalmente baseada em nuvem (o chamado Intune Standalone).
No momento da decisão, a Microsoft já havia publicado instruções passo a passo sobre a migração de usuários do SCCM para o Intune Standalone:
- Exporte configurações do SCCM e importe-as para o Intune.
- Migração de usuários de teste.
- Migração de todos os usuários.
- Alterne a Autoridade MDM de SCCM para Intune.
No estágio de exportação / importação,
foi usada uma
solução da própria Microsoft . Infelizmente, a importação não foi muito bem e não apenas aplicativos específicos foram migrados do SCCM, mas todos os tipos de implantação, criando aplicativos separados no Intune.
Parecia algo assim:
Além disso, por algum motivo, a versão do aplicativo também não foi importada corretamente e, por isso, foi necessário publicar todos os aplicativos manualmente. Com essa configuração e as políticas foram migradas sem problemas.
Migração de grupo de testeInicialmente, o grupo de teste consistia em meus colegas e eu. Estávamos com medo de que os usuários percebessem que estavam migrando. Isso pode provocar uma onda de chamadas para o serviço de desktop. Mas os testes mostraram que, na ausência de uma diferença nas configurações e aplicativos publicados, os usuários não percebem nada.
Qual foi o mecanismo de migração? O usuário necessário foi removido da coleção do SCCM, que foi usada nas configurações de assinatura do Intune. Isso foi feito por meio de uma coleção exclusiva, que, por sua vez, estava vinculada a um grupo no Active Directory. Dessa forma, para migrar o usuário, você só precisa adicioná-lo ao grupo AD necessário.
Porém, inesperadamente, houve problemas ao fornecer acesso ao Service Desk para gerenciar dispositivos migrados. Criei um papel especial, que tinha apenas os direitos necessários para suas tarefas. A função foi atribuída ao grupo necessário, mas o acesso para algumas pessoas não apareceu. As licenças dos analistas e suas contas foram verificadas, mas todas em vão. A verificação das funções efetivas por meio da API do Graph mostrou que há uma função, mas a pessoa ainda não tinha acesso. Após uma longa investigação, juntamente com o suporte da Microsoft, descobriu-se a necessidade de uma licença (Intune no EMS E3 ou EMS E5) para analistas. Além disso, os analistas, por sua vez, precisam ser migrados para o Intune Standalone. A necessidade não foi documentada e levou algumas semanas para ser resolvida.
Ao mesmo tempo, atraí um grupo de representantes de vendas de um país europeu para a migração, que usam ativamente o serviço VPN em seu trabalho diário e executam a migração em si e o
servidor configurado separadamente para o Intune Standalone
NDES . Foi nessa etapa que a migração foi quase cancelada com o retorno de todos os usuários de volta.
Para que o usuário possa usar o serviço VPN, eles são entregues com um perfil que configura o cliente VPN usando o certificado SCEP especificado, que se refere à CA raiz. Consequentemente, um par de certificados deve estar presente para operação.
Tínhamos apenas um certificado (CA raiz).
A coisa mais simples é supor que o problema esteja no servidor NDES. Mas funcionou perfeitamente e nem sequer recebeu pedidos de certificados. Ao examinar os logs dos próprios dispositivos, descobri que o dispositivo nem sequer recebia as configurações necessárias para solicitar um certificado SCEP. A Microsoft escalou esse problema para desenvolvedores do Intune que descobriram a importância de não apenas ter todos os certificados, mas também a necessidade de todos os certificados e configurações serem entregues aos mesmos grupos e dispositivos de usuários. No nosso caso, a CA raiz foi entregue a todos os dispositivos e o SCEP apenas para determinados dispositivos.
Iniciamos a migração de 1000 para 4000 usuários em uma onda. O processo levou 4 semanas. Estávamos prontos para qualquer coisa (todos sabemos que muito raramente tudo corre conforme o planejado). Mas tudo correu bem, sem um aumento nas chamadas para o serviço de desktop.
Dispositivos desatualizados
De acordo com nossos padrões, buscamos as versões mínimas do SO móvel:
· T-1 para iOS.
· T-2 para Android.
* T é a versão mais recente no momento.
Em menor grau, isso se aplica ao iOS, pois A Apple há muito tempo suporta seus dispositivos. Isso é mais verdade para dispositivos Android. Por exemplo, as pessoas ainda usam o Android 4.4.2 em dispositivos com mais de 4 anos de idade.
Nesse caso, estamos mantendo um diálogo com a equipe de TI local para determinar o momento da substituição de dispositivos, pois é necessário encontrar um equilíbrio entre segurança e dinheiro gasto na atualização.
O que vem a seguir?
A mudança de decisão levou a mudanças internas. Por exemplo, havia scripts para limpar o SCCM de dispositivos obsoletos gravados no PowerShell, que agora não são mais possíveis de usar. Em todas as suas novas soluções, a Microsoft está promovendo a API Graph, que deve ser dominada.
Até recentemente, os relatórios foram criados com base no SSRS; agora, usaremos o Power BI + oData Feed com dados do Intune Data Warehouse.
Mencionei anteriormente o acesso condicional e o gerenciamento de aplicativos móveis. A primeira solução já foi implementada, agora estamos trabalhando na segunda. Também estamos testando o Azure Application Proxy como um substituto para a VPN em dispositivos móveis. Se for interessante, contarei com prazer em novos artigos.