Google Workspace e Android fully managed

Aplicação: Nomid MDM Documento: V1.1.0 Última atualização: 02/07/2026 Responsável editorial: Documentação Nomid MDM Última revisão editorial: 02/07/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, KME ou QR 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:

• Primeiros 3 passos

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, como Zero-touch Enrollment ou KME, ou então provisionamento via QR 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:

1. Como plataforma de identidade e administração, usando o Admin Console para definir escopo, autenticação e integrações.
2. 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 Workspace controla identidade, usuários, unidades organizacionais e integrações;
• Nomid MDM passa 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 MDM també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 empresa 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, KME ou QR Code, sempre com fully 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 management nã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 Advanced no escopo que será entregue ao Nomid;
• em migrações, a permanência indevida em Advanced costuma 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 da empresa foi alterada;
• na prática, mudanças de provedor costumam exigir reinscrição e, em dispositivos fully managed, frequentemente novo provisionamento ou reset 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:

• Primeiros 3 passos

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 na empresa, 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 ID no 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 à empresa 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:

• Primeiros 3 passos

Do ponto de vista deste artigo, os pontos que merecem validação conceitual antes de avançar são:

• o Android Enterprise do Nomid precisa estar ativo e coerente com o ambiente correto;
• o Enterprise ID exibido no Nomid deve corresponder ao binding esperado no Google;
• o projeto precisa deixar claro se a empresa está em produção ou homologaçã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 Google estiver 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

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 MDM no 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 management no escopo que será migrado;
• definir se o lote usará Zero-touch, KME ou QR 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ábrica e 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 management ativo 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 Google será usado, quando suportado;
• validar qual método será usado no projeto: Zero-touch, KME ou QR 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 a empresa 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 management do Google no mesmo escopo;
• adotar Zero-touch, KME ou QR Code como caminho de provisionamento para fully 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

Veja também

• Google Cloud Identity
• Integrations
• Provisionamento por Zero-touch
• Provisionamento por KME
• Policies