¶ Google Workspace e Android fully managed
Aplicação: Nomid MDM
Documento: V1.1.0
Última atualização: 30/06/2026
Responsável editorial: Documentação Nomid MDM
Última revisão editorial: 30/06/2026
Idioma editorial: pt-BR
¶ Objetivo
Este artigo explica, de forma prática e completa, quais configurações do Google Workspace afetam a integração com o Nomid MDM e quais são os efeitos de cada escolha durante e após o provisionamento de dispositivos Android em gestão completa do dispositivo.
O foco deste documento é responder às dúvidas mais comuns de clientes que:
- querem integrar o Nomid MDM ao Google Workspace;
- querem provisionar dispositivos Android corporativos com
fully managed; - usam ou pretendem usar
Zero-touch Enrollment,KMEouQR Code; - precisam entender o impacto de cada configuração sobre Android Enterprise, apps, identidade, escopo por unidade organizacional e experiência de provisionamento.
Importante: Desde 2024, novos clientes Android Enterprise são direcionados ao modelo de Managed Google Domain. O Google Workspace é uma das formas de manter esse domínio; organizações sem Workspace podem usar Cloud Identity.
¶ Relação com o artigo de primeiros passos
Este artigo é complementar ao guia já publicado na wiki da Nomid sobre os primeiros passos do ambiente:
Sempre que a dúvida for sobre como executar a integração no portal, use o artigo acima como referência principal. Este documento foca no significado de cada configuração, nos efeitos práticos e nos impactos durante e após o provisionamento, evitando repetir o passo a passo já coberto na wiki.
Para localizar os campos no portal, consulte também Integrations.
¶ Escopo deste artigo
Este conteúdo considera somente o cenário padrão adotado para clientes Nomid MDM:
- dispositivos
Android corporativos; - provisionamento com
gestão completa do dispositivo(fully managed); - uso de
provisionador automatizado, comoZero-touch EnrollmentouKME, ou então provisionamento viaQR Code.
Ficam fora do escopo deste artigo:
- BYOD;
- work profile;
- iOS e iPadOS;
- fluxos de gestão parcial do dispositivo.
¶ Visão geral rápida
No cenário Nomid, o Google Workspace participa da arquitetura principalmente como:
- Como plataforma de identidade e administração, usando o Admin Console para definir escopo, autenticação e integrações.
- Como plataforma que entrega o vínculo Android Enterprise correto para o EMM configurado por OU.
Quando o cliente decide usar o Nomid MDM como EMM/MDM para Android Enterprise, o Google Workspace continua sendo parte importante da arquitetura, mas deixa de ser o provedor principal de gestão Android para as unidades organizacionais vinculadas ao Nomid.
Em outras palavras:
Google Workspacecontrola identidade, usuários, unidades organizacionais e integrações;Nomid MDMpassa a controlar o gerenciamento Android Enterprise dos dispositivos vinculados ao provedor EMM selecionado.
¶ Conceitos importantes antes de começar
¶ 1. Google Endpoint Management nao e a mesma coisa que Android Enterprise
Esses termos costumam ser confundidos.
Android Enterpriseé a base tecnológica usada pelos provedores EMM para gerenciar Android corporativo.Google Endpoint Management (GEM)é o EMM nativo do Google.Nomid MDMtambém é um EMM que utiliza Android Enterprise.
Portanto, escolher o Nomid não significa “sair do ecossistema Google”. Significa apenas trocar o provedor de gerenciamento Android do Google pelo Nomid para o escopo definido.
¶ 2. O escopo no Google Workspace e por Unidade Organizacional
No Google Admin Console, a ativação de integrações terceiras para Android EMM é aplicada por Organizational Unit (OU).
Isso significa que:
- diferentes OUs podem ter comportamentos diferentes;
- a decisão de usar Nomid ou manter somente Google pode ser segmentada;
- é possível usar múltiplos bindings EMM no mesmo tenant Google, desde que cada OU aponte para o provedor correto.
¶ 3. Adicionar um EMM terceiro muda a responsabilidade da gestão Android
Ao ativar Enable third-party Android mobile management e atribuir o provedor à OU:
- a gestão Android dessa OU passa a ser feita pelo EMM selecionado;
- o Google Admin Console deixa de ser o local principal para gestão de apps Android dessa OU;
- o ciclo de provisionamento e conformidade passa a depender do provedor escolhido, neste caso o
Nomid MDM.
No desenho recomendado:
- o Google Workspace continua relevante para identidade e escopo;
- o
Nomid MDMé o ponto central de administração dos dispositivos Android provisionados; - o método de provisionamento deve ser
Zero-touch,KMEouQR Code, sempre comfully managed.
¶ Configurações possíveis no Google Workspace e o efeito de cada uma
¶ 1. Google Endpoint Management: Advanced mobile management
¶ O que é
É o modo avançado de gestão nativa do Google Workspace.
Segundo a documentação do Google, esse modo habilita:
- políticas mais fortes de segurança;
- mais controle de senha;
- wipe completo do dispositivo;
- gestão mais avançada pelo próprio Google.
¶ Efeito prático
- o Google passa a atuar como EMM efetivo para aquele escopo;
- há maior intervenção do ecossistema Google no ciclo de gestão.
¶ Efeito na integração com o Nomid
Esse modo é o principal ponto de conflito com EMM de terceiros.
Advanced mobile managementnão deve coexistir com o Nomid como EMM Android para a mesma OU;- se o cliente pretende usar o Nomid, a recomendação é evitar manter
Advancedno escopo que será entregue ao Nomid; - em migrações, a permanência indevida em
Advancedcostuma gerar confusão operacional, falha de expectativa sobre quem gerencia o dispositivo e limitações na troca do provedor.
¶ Durante o provisionamento
- se o dispositivo for provisionado esperando gestão avançada do Google, o fluxo tende a seguir a lógica do Google;
- se o objetivo é usar Nomid, o provisionamento deve ser desenhado para o
Nomid MDM, e não para o fluxo avançado do GEM.
¶ Após o provisionamento
- dispositivos já inscritos sob a lógica de outro EMM ou de gestão avançada do Google normalmente não devem ser considerados automaticamente migrados apenas porque a configuração do tenant foi alterada;
- na prática, mudanças de provedor costumam exigir
reinscriçãoe, em dispositivosfully managed, frequentementenovo provisionamentooureset de fábrica.
¶ 2. Third-party integrations > Android EMM
¶ O que é
É a configuração do Google Admin Console que habilita o uso de um provedor EMM terceiro para Android.
Exemplo da tela no Google Admin Console:
Se você precisa do procedimento operacional para criar a integração, validar o Android Enterprise no Nomid e concluir a configuração inicial, siga o artigo de primeiros passos da wiki:
¶ Opção: Enable third-party Android mobile management
¶ Quando desabilitada
- o Google não entrega aquela OU a um EMM terceiro;
- o gerenciamento Android segue a lógica nativa do Google ou a ausência de gestão, conforme o restante da configuração.
¶ Quando habilitada
- o Google permite que a OU use o EMM selecionado;
- a gestão Android Enterprise daquela OU passa a ser responsabilidade do provedor escolhido;
- o Admin Console deixa de ser o ponto principal de gestão de apps Android para aquele escopo.
¶ Efeito durante o provisionamento
- novos dispositivos da OU passam a seguir o vínculo com o provedor configurado;
- o provisionamento precisa estar alinhado com o binding correto do Nomid.
¶ Efeito após o provisionamento
- a operação diária, políticas, conformidade e ações de gestão passam a depender do Nomid;
- a simples habilitação dessa opção não “migra” automaticamente dispositivos já gerenciados por outro fluxo.
¶ 3. Seleção do provedor EMM
Na mesma tela, o administrador escolhe qual binding EMM será usado pela OU.
Isso é especialmente importante quando existem múltiplos bindings no tenant, por exemplo:
- produção e homologação;
- ambientes de marcas ou empresas diferentes;
- bindings distintos para projetos separados.
¶ Efeito prático
- cada OU deve apontar exatamente para o binding correto;
- selecionar o binding errado pode fazer o dispositivo cair em um ambiente incorreto, com políticas erradas ou sem continuidade operacional esperada.
¶ Boa prática
- validar o
Enterprise IDno Nomid; - validar o nome legal da empresa;
- validar qual binding foi configurado no Google antes de liberar o provisionamento em escala.
¶ 4. Manage EMM providers
Essa área lista os bindings EMM já conectados ao tenant Google.
Ali normalmente é possível:
- visualizar provedores vinculados;
- remover bindings que não serão mais usados;
- verificar disponibilidade de autenticação via Google;
- diferenciar ambientes quando existe mais de um provider registrado.
¶ Efeito prático
- não basta o provedor existir na lista;
- ele precisa estar corretamente vinculado e depois corretamente atribuído à OU certa.
Um erro comum é acreditar que “binding criado” significa “integração concluída”. Não significa. O binding apenas torna o provedor elegível para uso. O escopo real depende da OU.
Exemplo da tela Manage EMM providers, onde aparecem os providers vinculados e a opção Authenticate Using Google:
¶ 5. Authenticate Using Google
¶ O que é
É a opção que permite usar a autenticação Google durante o enrollment, desde que o provedor EMM suporte esse recurso.
¶ Quando desabilitada
- o enrollment tende a depender mais do fluxo próprio do EMM;
- a experiência de login pode ficar menos integrada ao diretório Google.
¶ Quando habilitada
- novos usuários podem se autenticar com a conta corporativa Google no processo de inscrição;
- melhora a aderência entre identidade Google e experiência de provisionamento;
- faz mais sentido quando os usuários já estão sincronizados no domínio gerenciado.
¶ Efeito durante o provisionamento
- exige autenticação da conta corporativa durante o provisionamento;
- aumenta o tempo total do enrollment, porque adiciona etapas e interação do usuário no meio da configuração;
- exige mais ações manuais durante a entrega do dispositivo, o que reduz a fluidez do processo em comparação com fluxos mais diretos;
- aumenta a chance de erro operacional por digitação incorreta, senha desconhecida, MFA, bloqueios de conta ou inconsistências de identidade;
- pode gerar falhas e até travar o provisionamento quando a autenticação não é concluída corretamente ou quando existe algum problema de acesso à conta Google no momento da inscrição.
¶ Efeito após o provisionamento
- reforça a coerência entre diretório, usuário e dispositivo;
- simplifica auditoria e suporte quando a identidade corporativa é o eixo principal do acesso.
¶ Recomendação
Quando o binding do Nomid suportar esse recurso, a habilitação só faz sentido em ambientes com identidade corporativa madura, usuários preparados para autenticação durante o enrollment e processos de suporte bem definidos. Em operações que priorizam rapidez, baixo atrito e menor risco no provisionamento, é importante avaliar com cuidado se o ganho de identidade compensa o aumento de etapas e a possibilidade de falhas.
¶ 6. Unidade Organizacional certa ou errada
Como a atribuição do EMM é feita por OU, essa é uma das configurações mais sensíveis.
¶ Se a OU estiver correta
- o usuário entra no fluxo esperado;
- o provedor certo assume o Android Enterprise;
- as políticas e o comportamento pós-inscrição ficam consistentes.
¶ Se a OU estiver errada
- o usuário pode cair sem gerenciamento;
- pode cair na gestão nativa do Google em vez do Nomid;
- pode cair em outro binding EMM;
- pode receber políticas inconsistentes com o projeto.
¶ Impacto real
Em muitos chamados, o problema não está no Nomid nem no Android Enterprise em si, mas no escopo incorreto da OU no Google Admin Console.
¶ Como o Nomid MDM entra nessa arquitetura
No Nomid MDM, a integração com Android Enterprise aparece no módulo de Integrations, com destaque para:
Android Enterprise;Enterprise ID;Legal Name;Type;Zero-Touch Enrollment;SSO / Identity Provider.
Esses elementos ajudam a confirmar que o ambiente Nomid está pronto para operar como EMM no ecossistema Google.
Exemplo da tela no portal do Nomid MDM:
¶ O que validar no Nomid antes de integrar com o Google Workspace
Em vez de repetir o fluxo operacional já documentado, use o artigo de primeiros passos como base para conferir a configuração inicial do ambiente:
Do ponto de vista deste artigo, os pontos que merecem validação conceitual antes de avançar são:
- o
Android Enterprisedo Nomid precisa estar ativo e coerente com o ambiente correto; - o
Enterprise IDexibido no Nomid deve corresponder ao binding esperado no Google; - o projeto precisa deixar claro se o tenant está em
produçãoouhomologação; - se houver
Zero-touch Enrollment, ele deve estar alinhado ao método de provisionamento planejado; - a estratégia de identidade e autenticação precisa estar consistente com o uso ou não de
Authenticate Using Google.
¶ Efeitos durante o provisionamento
Neste artigo, provisionamento significa sempre uma destas três entradas:
Zero-touch Enrollment;KME;QR Code.
Em todos os casos, o objetivo é o mesmo: colocar o dispositivo Android no fluxo de fully managed do Nomid.
¶ 1. Zero-touch Enrollment
Quando Zero-touch está configurado corretamente:
- o dispositivo já nasce apontado para o fluxo corporativo;
- a primeira inicialização já conduz ao provisionamento administrado;
- o atrito operacional diminui bastante em implantações em escala;
- erros humanos tendem a ser menores do que em fluxos manuais.
¶ 2. KME
Quando KME está configurado corretamente:
- o dispositivo também entra em um fluxo automatizado de provisionamento;
- a associação entre hardware e ambiente de gestão acontece antes da entrega ao usuário;
- o processo tende a ser previsível e repetível em lotes corporativos.
¶ 3. QR Code
Quando o provisionamento é feito por QR Code:
- o fluxo continua compatível com
fully managed; - depende mais da execução correta no momento da entrega;
- exige mais atenção operacional do que Zero-touch ou KME;
- é útil quando não há provisionador automatizado disponível para aquele lote de dispositivos.
¶ O que precisa acontecer para o provisionamento dar certo
- a OU do usuário precisa estar correta no Google Workspace;
- a OU precisa apontar para o binding EMM correto do Nomid;
- o binding do Nomid precisa estar íntegro em
Manage EMM providers; - o método escolhido de provisionamento precisa estar alinhado ao projeto;
- se
Authenticate Using Googleestiver ativo, a operação precisa considerar o impacto adicional no fluxo.
¶ Efeitos após o provisionamento
Depois que o dispositivo já está provisionado no Nomid:
- a administração do dispositivo Android passa a acontecer prioritariamente no
Nomid MDM; - políticas, apps e ações remotas devem ser conduzidos no Nomid;
- o Google Workspace continua sendo referência para identidade, organização e escopo;
- mudanças no Google podem afetar novos enrollments e regras de atribuição, mas não devem ser tratadas como migração automática de dispositivos já inscritos.
¶ Matriz de efeitos por configuração
| Configuração no Google Workspace | Durante o provisionamento | Após o provisionamento | Observação principal |
|---|---|---|---|
Advanced mobile management |
Leva o Android para a lógica avançada do Google | Conflita com EMM terceiro no mesmo escopo | Deve ser evitado para OUs entregues ao Nomid |
Enable third-party Android mobile management = Off |
O dispositivo não é entregue ao Nomid pela OU | Google continua como referência de gestão ou ausência dela | Integração não entra em operação |
Enable third-party Android mobile management = On |
O dispositivo pode ser entregue ao EMM configurado | Nomid assume a gestão Android da OU | Requer binding e OU corretos |
Authenticate Using Google = Off |
Menos etapas e menor atrito no enrollment | Menor dependência de autenticação durante a entrega | Mais aderente a operações rápidas de provisionamento |
Authenticate Using Google = On |
Mais etapas, mais tempo e maior risco de falha ou travamento | Melhor coerência entre usuário, diretório e device | Deve ser avaliado com cautela |
| OU correta com binding correto | Fluxo esperado | Operação consistente | Estado ideal |
| OU errada ou binding errado | Enrollment incorreto ou falho | Políticas erradas, suporte difícil | Uma das falhas mais comuns |
¶ O que acontece com apps Android no Google Admin Console
Esse é um ponto que costuma gerar dúvida.
Depois que um EMM terceiro é adicionado:
- o Google informa que não é mais possível gerenciar apps Android pelo Admin Console para aquele contexto como antes;
- se antes os apps estavam sob gestão do Google, eles deixam de estar sob essa gestão até que o provedor correto seja efetivamente habilitado para a OU;
- na prática, a governança de apps Android migra para o
Nomid MDMno escopo gerenciado por ele.
Por isso, a integração não deve ser tratada apenas como “ligar um conector”. Ela também altera o local operacional de gestão de apps.
¶ Cenários comuns e o que esperar
¶ Cenário A: cliente usa somente Google e quer começar com Nomid
¶ Recomendação
- usar o artigo de primeiros passos da Nomid para executar a integração base;
- revisar as OUs que entrarão no projeto;
- identificar se existe
Advanced mobile managementno escopo que será migrado; - definir se o lote usará
Zero-touch,KMEouQR Code; - planejar piloto antes da expansão para produção.
¶ Expectativa correta
- novos dispositivos entram pelo fluxo Nomid;
- dispositivos antigos podem exigir reinscrição;
- em dispositivos
fully managed, a migração frequentemente exige novo provisionamento; - gestão de apps Android deixa de ficar centralizada no Google para esse escopo.
¶ Cenário B: cliente já usa Google Advanced e quer migrar
¶ Risco principal
Tratar a troca como simples alteração de tela administrativa.
¶ Expectativa correta
- a mudança é arquitetural;
- dispositivos já provisionados não devem ser considerados automaticamente migrados;
- em muitos casos será necessário
reset de fábricae novo ciclo de enrollment.
¶ Principais dúvidas de clientes Nomid
¶ “Se eu integrar o Nomid ao Google Workspace, o Google deixa de ser importante?”
Não. O Google continua sendo fundamental para identidade, usuários, estrutura organizacional e escopo da integração. O que muda é quem gerencia o Android Enterprise da OU configurada.
¶ “Ativar o provider no Google já migra todos os dispositivos?”
Não. Isso prepara o escopo para o provedor correto, mas não substitui automaticamente o estado de dispositivos já provisionados.
¶ “Posso manter Google Advanced e Nomid para o mesmo escopo?”
Não é o desenho recomendado. O Google informa que o modo Advanced não coexistirá com EMM terceiro no mesmo contexto Android.
¶ “Qual método de provisionamento devo usar?”
Para clientes Nomid, o padrão é sempre gestão completa do dispositivo, usando Zero-touch Enrollment, KME ou QR Code. O melhor método depende da origem do lote e da automação disponível, mas o objetivo final é sempre o mesmo: Android fully managed sob o Nomid.
¶ “Quem passa a gerenciar os apps Android?”
No escopo entregue ao Nomid, a gestão operacional de apps Android deve passar para o Nomid MDM.
¶ “O problema está no Nomid ou no Google?”
Muitas falhas de integração vêm de:
- OU errada;
- binding errado;
- permanência indevida em
Advanced; - expectativa de migração automática;
- identidade ainda não sincronizada;
- autenticação corporativa não alinhada com o fluxo de enrollment.
¶ Checklist recomendado para projetos com Nomid + Google Workspace
- confirmar a estratégia: Google somente ou Google + Nomid;
- mapear OUs que entrarão no projeto;
- validar se existe
Advanced mobile managementativo no escopo; - executar o procedimento base de integração conforme o artigo de primeiros passos da Nomid:
Primeiros 3 passos - confirmar que o binding correto do Nomid aparece em
Manage EMM providers; - confirmar que a OU correta recebeu o provider correto;
- decidir se
Authenticate Using Googleserá usado, quando suportado; - validar qual método será usado no projeto:
Zero-touch,KMEouQR Code; - executar piloto com poucos usuários;
- somente depois expandir em escala.
¶ Erros de interpretação que este artigo busca evitar
- confundir Android Enterprise com Google Endpoint Management;
- achar que binding criado já significa integração aplicada;
- achar que a configuração vale para o tenant inteiro sem olhar a OU;
- achar que o Google continuará sendo o ponto principal de gestão Android após entregar a OU ao Nomid;
- achar que alterar a configuração do Google migra automaticamente dispositivos já provisionados;
- esquecer que apps Android também mudam de ponto operacional de gestão.
- esquecer que o contexto Nomid é
fully managed, e não gestão parcial do dispositivo.
¶ Recomendação final
Para clientes que desejam integrar Nomid MDM ao Google Workspace, o desenho mais seguro é:
- usar o Google como base de identidade, diretório e escopo;
- usar o Nomid como EMM principal para Android Enterprise nas OUs definidas;
- evitar
Advanced mobile managementdo Google no mesmo escopo; - adotar
Zero-touch,KMEouQR Codecomo caminho de provisionamento parafully managed; - tratar migrações como projeto de transição, e não como alteração instantânea;
- validar cuidadosamente OU, binding e método de provisionamento antes de liberar a operação.
¶ Fontes de referência
- Wiki Nomid: https://wiki.nomid.tech/pt-br/home
- Nomid MDM - First 3 Steps: https://wiki.nomid.tech/pt-br/3steps
- Google Android Enterprise Help: Sign up for Android management using managed Google domains
- Google Workspace Admin Help: About Android device management with Google endpoint management