¶ Google Workspace y Android fully managed
Aplicación: Nomid MDM
Documento: V1.1.0
Última actualización: 02/07/2026
Responsable editorial: Documentación de Nomid MDM
Última revisión editorial: 02/07/2026
Idioma editorial: es-ES
¶ Objetivo
Este articulo explica, de forma practica y completa, qué configuraciones de Google Workspace afectan la integracion con Nomid MDM y cuáles son los efectos de cada decision durante y despues del aprovisionamiento de dispositivos Android en modo fully managed.
Este documento busca responder las dudas mas comunes de clientes que:
- quieren integrar Nomid MDM con Google Workspace;
- quieren aprovisionar dispositivos Android corporativos como
fully managed; - usan o planean usar
Zero-touch Enrollment,KMEoQR Code; - necesitan entender el impacto de cada configuracion sobre Android Enterprise, apps, identidad, alcance por unidad organizativa y experiencia de aprovisionamiento.
Importante: Desde 2024, los nuevos clientes de Android Enterprise utilizan el modelo de dominio de Google gestionado. Google Workspace es una forma de mantener ese dominio; las organizaciones sin Workspace pueden utilizar Cloud Identity.
¶ Relacion con el articulo de primeros pasos
Este articulo complementa la guia de primeros pasos ya publicada en la wiki de Nomid:
Siempre que la duda sea como realizar la integracion en el portal, use el articulo anterior como referencia principal. Este documento se enfoca en el significado de cada configuracion, los efectos practicos y los impactos durante y despues del aprovisionamiento, sin repetir el paso a paso ya cubierto en la wiki.
Para localizar estos campos en el portal, consulta también Integraciones.
¶ Alcance de este articulo
Este contenido considera solamente el escenario estandar adoptado para clientes Nomid MDM:
- dispositivos
Android corporativos; - aprovisionamiento con
gestion completa del dispositivo(fully managed); - uso de un
metodo de aprovisionamiento automatizado, comoZero-touch EnrollmentoKME, o aprovisionamiento medianteQR Code.
Quedan fuera del alcance de este articulo:
- BYOD;
- work profile;
- iOS e iPadOS;
- flujos de gestion parcial del dispositivo.
¶ Vision general rapida
En el escenario Nomid, Google Workspace participa principalmente en la arquitectura como:
- Plataforma de identidad y administracion, usando la Admin Console para definir alcance, autenticacion e integraciones.
- Plataforma que entrega el enlace correcto de Android Enterprise al EMM configurado por OU.
Cuando el cliente decide usar Nomid MDM como EMM/MDM para Android Enterprise, Google Workspace sigue siendo una parte importante de la arquitectura, pero deja de ser el proveedor principal de gestion Android para las unidades organizativas asignadas a Nomid.
En otras palabras:
Google Workspacecontrola identidad, usuarios, unidades organizativas e integraciones;Nomid MDMcontrola la gestion Android Enterprise de los dispositivos vinculados al proveedor EMM seleccionado.
¶ Conceptos importantes antes de empezar
¶ 1. Google Endpoint Management no es lo mismo que Android Enterprise
Estos terminos suelen confundirse.
Android Enterprisees la base tecnologica utilizada por los proveedores EMM para gestionar Android corporativo.Google Endpoint Management (GEM)es el EMM nativo de Google.Nomid MDMtambien es un EMM que utiliza Android Enterprise.
Por lo tanto, elegir Nomid no significa salir del ecosistema Google. Solo significa reemplazar a Google como proveedor de gestion Android para el alcance definido.
¶ 2. El alcance en Google Workspace se define por Unidad Organizativa
En Google Admin Console, la integracion Android EMM de terceros se aplica por Organizational Unit (OU).
Eso significa que:
- diferentes OUs pueden tener comportamientos distintos;
- la decision de usar Nomid o mantener solo gestion Google puede segmentarse;
- es posible usar multiples bindings EMM en el mismo empresa de Google, siempre que cada OU apunte al proveedor correcto.
¶ 3. Agregar un EMM de terceros cambia quien gestiona Android
Cuando se habilita Enable third-party Android mobile management y el proveedor se asigna a la OU:
- la gestion Android de esa OU pasa a ser responsabilidad del EMM seleccionado;
- Google Admin Console deja de ser el punto principal para gestionar apps Android en esa OU;
- el ciclo de aprovisionamiento y cumplimiento empieza a depender del proveedor seleccionado, en este caso
Nomid MDM.
En el diseño recomendado:
- Google Workspace sigue siendo relevante para identidad y alcance;
Nomid MDMse convierte en el punto central de administracion de los dispositivos Android aprovisionados;- el metodo de aprovisionamiento debe ser
Zero-touch,KMEoQR Code, siempre en modofully managed.
¶ Configuraciones posibles en Google Workspace y el efecto de cada una
¶ 1. Google Endpoint Management: Advanced mobile management
¶ Que es
Es el modo avanzado de gestion nativa de Google Workspace.
Segun la documentacion de Google, este modo habilita:
- politicas de seguridad mas fuertes;
- mas control de contraseñas;
- borrado completo del dispositivo;
- gestion mas avanzada por parte del propio Google.
¶ Efecto practico
- Google actua como el EMM efectivo para ese alcance;
- hay mayor intervencion del ecosistema Google en el ciclo de gestion.
¶ Efecto en la integracion con Nomid
Este es el principal punto de conflicto con EMMs de terceros.
Advanced mobile managementno debe coexistir con Nomid como EMM Android para la misma OU;- si el cliente planea usar Nomid, la recomendacion es evitar mantener
Advanceden el alcance que se entregara a Nomid; - en migraciones, dejar
Advancedhabilitado suele generar confusion operativa, expectativas incorrectas sobre quién gestiona el dispositivo y limitaciones al cambiar de proveedor.
¶ Durante el aprovisionamiento
- si el dispositivo se aprovisiona esperando la gestion avanzada de Google, el flujo tiende a seguir la logica de Google;
- si el objetivo es usar Nomid, el aprovisionamiento debe diseñarse para
Nomid MDM, no para el flujo avanzado de GEM.
¶ Despues del aprovisionamiento
- los dispositivos ya inscritos bajo otro EMM o bajo la gestion avanzada de Google no deben considerarse automaticamente migrados solo porque se cambio una configuracion de la empresa;
- en la practica, los cambios de proveedor suelen requerir
reinscripciony, para dispositivosfully managed, a menudo unnuevo aprovisionamientoorestablecimiento de fabrica.
¶ 2. Third-party integrations > Android EMM
¶ Que es
Es la configuracion de Google Admin Console que habilita el uso de un proveedor EMM de terceros para Android.
Ejemplo de la pantalla en Google Admin Console:
Si necesita el procedimiento operativo para crear la integracion, validar Android Enterprise en Nomid y completar la configuracion inicial, siga el articulo de primeros pasos de la wiki:
¶ Opcion: Enable third-party Android mobile management
¶ Cuando esta deshabilitada
- Google no entrega esa OU a un EMM de terceros;
- la gestion Android sigue la logica nativa de Google o la ausencia de gestion, segun el resto de la configuracion.
¶ Cuando esta habilitada
- Google permite que esa OU use el EMM seleccionado;
- la gestion Android Enterprise de esa OU pasa a ser responsabilidad del proveedor seleccionado;
- la Admin Console deja de ser el punto principal para gestionar apps Android en ese alcance.
¶ Efecto durante el aprovisionamiento
- los dispositivos nuevos de esa OU empiezan a seguir el enlace hacia el proveedor configurado;
- el aprovisionamiento debe estar alineado con el binding correcto de Nomid.
¶ Efecto despues del aprovisionamiento
- la operacion diaria, las politicas, el cumplimiento y las acciones de gestion pasan a depender de Nomid;
- habilitar esta opcion no migra automaticamente los dispositivos que ya estaban gestionados por otro flujo.
¶ 3. Selección del proveedor EMM
En la misma pantalla, el administrador elige qué binding EMM usara la OU.
Esto es especialmente importante cuando existen multiples bindings en la empresa, por ejemplo:
- produccion y homologacion;
- diferentes entornos de empresa o marca;
- bindings separados para proyectos separados.
¶ Efecto practico
- cada OU debe apuntar exactamente al binding correcto;
- seleccionar el binding incorrecto puede enviar el dispositivo al entorno equivocado, con politicas incorrectas o sin la continuidad operativa esperada.
¶ Buena practica
- validar el
Enterprise IDen Nomid; - validar la razon social;
- validar qué binding fue seleccionado en Google antes de habilitar el aprovisionamiento a escala.
¶ 4. Manage EMM providers
Esta area lista los bindings EMM ya conectados a la empresa de Google.
Normalmente alli es posible:
- ver los proveedores vinculados;
- eliminar bindings que ya no se usaran;
- comprobar si la autenticacion con Google esta disponible;
- distinguir entornos cuando hay mas de un proveedor registrado.
¶ Efecto practico
- no basta con que el proveedor exista en la lista;
- debe estar correctamente vinculado y luego correctamente asignado a la OU correcta.
Un error comun es asumir que "binding creado" significa "integracion completada". No significa eso. El binding solo hace que el proveedor sea elegible para uso. El alcance real sigue dependiendo de la OU.
Ejemplo de la pantalla Manage EMM providers, donde aparecen los proveedores vinculados y la opcion Authenticate Using Google:
¶ 5. Authenticate Using Google
¶ Que es
Esta opcion permite usar autenticacion Google durante la inscripcion, siempre que el proveedor EMM soporte esta funcion.
¶ Cuando esta deshabilitada
- la inscripcion depende mas del flujo propio del EMM;
- la experiencia de inicio de sesion puede quedar menos integrada con el directorio de Google.
¶ Cuando esta habilitada
- los nuevos usuarios pueden autenticarse con su cuenta corporativa de Google durante la inscripcion;
- mejora la coherencia entre identidad Google y experiencia de aprovisionamiento;
- tiene mas sentido cuando los usuarios ya estan sincronizados en el dominio gestionado.
¶ Efecto durante el aprovisionamiento
- exige autenticacion con la cuenta corporativa durante el aprovisionamiento;
- aumenta el tiempo total del enrollment porque agrega pasos e interaccion del usuario en medio de la configuracion;
- exige mas acciones manuales durante la entrega del dispositivo, lo que reduce la fluidez del proceso frente a flujos mas directos;
- aumenta la probabilidad de error operativo por credenciales mal escritas, contraseñas desconocidas, MFA, bloqueos de cuenta o inconsistencias de identidad;
- puede generar fallos e incluso bloquear el aprovisionamiento cuando la autenticacion no se completa correctamente o cuando existe algun problema de acceso a la cuenta de Google en el momento de la inscripcion.
¶ Efecto despues del aprovisionamiento
- refuerza la coherencia entre directorio, usuario y dispositivo;
- simplifica auditoria y soporte cuando la identidad corporativa es el eje principal del acceso.
¶ Recomendacion
Cuando el binding de Nomid soporte esta funcion, habilitarla solo tiene sentido en entornos con identidad corporativa madura, usuarios preparados para autenticarse durante el enrollment y procesos de soporte bien definidos. En operaciones que priorizan rapidez, baja friccion y menor riesgo de aprovisionamiento, es importante evaluar cuidadosamente si el beneficio de identidad compensa los pasos adicionales y el riesgo de fallos.
¶ 6. Unidad organizativa correcta o incorrecta
Como la asignacion del EMM se hace por OU, esta es una de las configuraciones mas sensibles.
¶ Si la OU es correcta
- el usuario entra en el flujo esperado;
- el proveedor correcto toma el control de Android Enterprise;
- las politicas y el comportamiento posterior a la inscripcion se mantienen consistentes.
¶ Si la OU es incorrecta
- el usuario puede caer en un flujo sin gestion;
- el usuario puede caer en la gestion nativa de Google en lugar de Nomid;
- el usuario puede caer en otro binding EMM;
- el usuario puede recibir politicas inconsistentes con el proyecto.
¶ Impacto real
En muchos casos de soporte, el problema no esta en Nomid ni en Android Enterprise en si, sino en el alcance incorrecto de la OU en Google Admin Console.
¶ Como encaja Nomid MDM en esta arquitectura
En Nomid MDM, la integracion con Android Enterprise aparece en el modulo Integrations, con destaque en:
Android Enterprise;Enterprise ID;Legal Name;Type;Zero-Touch Enrollment;SSO / Identity Provider.
Estos elementos ayudan a confirmar que el entorno Nomid esta listo para operar como EMM dentro del ecosistema Google.
Ejemplo de la pantalla en el portal de Nomid MDM:
¶ Que validar en Nomid antes de integrar con Google Workspace
En lugar de repetir el flujo operativo ya documentado, use el articulo de primeros pasos como referencia base para revisar la configuracion inicial del entorno:
Desde la perspectiva de este articulo, los puntos conceptuales que deben validarse antes de avanzar son:
- el
Android Enterprisede Nomid debe estar activo y alineado con el entorno correcto; - el
Enterprise IDmostrado en Nomid debe coincidir con el binding esperado en Google; - el proyecto debe dejar claro si la empresa es de
produccionohomologacion; - si existe
Zero-touch Enrollment, debe estar alineado con el metodo de aprovisionamiento planificado; - la estrategia de identidad y autenticacion debe ser consistente con el uso o no de
Authenticate Using Google.
¶ Efectos durante el aprovisionamiento
En este articulo, aprovisionamiento siempre significa uno de estos tres metodos de entrada:
Zero-touch Enrollment;KME;QR Code.
En todos los casos, el objetivo es el mismo: llevar el dispositivo Android al flujo fully managed de Nomid.
¶ 1. Zero-touch Enrollment
Cuando Zero-touch esta configurado correctamente:
- el dispositivo ya nace apuntando al flujo corporativo;
- el primer encendido ya conduce al aprovisionamiento administrado;
- la friccion operativa disminuye significativamente en despliegues a gran escala;
- el error humano tiende a ser menor que en flujos manuales.
¶ 2. KME
Cuando KME esta configurado correctamente:
- el dispositivo tambien entra en un flujo automatizado de aprovisionamiento;
- la asociacion entre hardware y entorno de gestion ocurre antes de la entrega al usuario;
- el proceso tiende a ser predecible y repetible en lotes corporativos.
¶ 3. QR Code
Cuando el aprovisionamiento se realiza mediante QR Code:
- el flujo sigue siendo compatible con
fully managed; - depende mas de una ejecucion correcta en el momento de la entrega;
- exige mas atencion operativa que Zero-touch o KME;
- es util cuando no hay un metodo automatizado disponible para ese lote de dispositivos.
¶ Que debe estar correcto para que el aprovisionamiento funcione
- la OU del usuario debe ser correcta en Google Workspace;
- la OU debe apuntar al binding EMM correcto de Nomid;
- el binding de Nomid debe estar integro en
Manage EMM providers; - el metodo de aprovisionamiento elegido debe estar alineado con el proyecto;
- si
Authenticate Using Googleesta habilitado, la operacion debe considerar el impacto adicional en el flujo.
¶ Efectos despues del aprovisionamiento
Despues de que el dispositivo fue aprovisionado en Nomid:
- la administracion del dispositivo Android ocurre principalmente en
Nomid MDM; - las politicas, apps y acciones remotas deben gestionarse en Nomid;
- Google Workspace sigue siendo la referencia para identidad, organizacion y alcance;
- los cambios en Google pueden afectar nuevas inscripciones y reglas de asignacion, pero no deben tratarse como migracion automatica de dispositivos ya inscritos.
¶ Matriz de efectos por configuracion
| Configuracion en Google Workspace | Durante el aprovisionamiento | Despues del aprovisionamiento | Observacion principal |
|---|---|---|---|
Advanced mobile management |
Lleva Android a la logica avanzada de Google | Entra en conflicto con EMM de terceros en el mismo alcance | Debe evitarse en OUs asignadas a Nomid |
Enable third-party Android mobile management = Off |
El dispositivo no se entrega a Nomid por la OU | Google sigue siendo la referencia de gestion o no existe integracion efectiva de terceros | La integracion no entra en operacion |
Enable third-party Android mobile management = On |
El dispositivo puede entregarse al EMM configurado | Nomid asume la gestion Android de la OU | Requiere binding y OU correctos |
Authenticate Using Google = Off |
Menos pasos y menor friccion en el enrollment | Menor dependencia de autenticacion durante la entrega | Mas alineado con operaciones rapidas de aprovisionamiento |
Authenticate Using Google = On |
Mas pasos, mas tiempo y mayor riesgo de fallo o bloqueo | Mejor coherencia entre usuario, directorio y dispositivo | Debe evaluarse con cautela |
| OU correcta con binding correcto | Flujo esperado | Operacion consistente | Estado ideal |
| OU incorrecta o binding incorrecto | Enrollment incorrecto o fallido | Politicas incorrectas y soporte dificil | Uno de los fallos mas comunes |
¶ Que ocurre con las apps Android en Google Admin Console
Este es un punto que suele generar dudas.
Despues de agregar un EMM de terceros:
- Google indica que ya no es posible gestionar apps Android desde Admin Console para ese contexto del mismo modo que antes;
- si antes las apps estaban bajo gestion de Google, dejan de gestionarse alli hasta que el proveedor correcto se habilite efectivamente para la OU;
- en la practica, la gobernanza de apps Android pasa a
Nomid MDMpara el alcance gestionado por Nomid.
Por eso, esta integracion no debe tratarse solo como "activar un conector". Tambien cambia el punto operativo donde se gestionan las apps Android.
¶ Escenarios comunes y qué esperar
¶ Escenario A: el cliente solo usa Google y quiere comenzar con Nomid
¶ Recomendacion
- usar el articulo de primeros pasos de Nomid para realizar la integracion base;
- revisar las OUs que formaran parte del proyecto;
- identificar si existe
Advanced mobile managementen el alcance que se migrara; - definir si el lote usara
Zero-touch,KMEoQR Code; - planificar un piloto antes de expandir a produccion.
¶ Expectativa correcta
- los dispositivos nuevos entran por el flujo de Nomid;
- los dispositivos antiguos pueden requerir reinscripcion;
- para dispositivos
fully managed, la migracion suele requerir un nuevo aprovisionamiento; - la gestion de apps Android deja de estar centralizada en Google para ese alcance.
¶ Escenario B: el cliente ya usa Google Advanced y quiere migrar
¶ Riesgo principal
Tratar el cambio como si fuera solo una modificacion de pantalla administrativa.
¶ Expectativa correcta
- el cambio es arquitectonico;
- los dispositivos ya aprovisionados no deben considerarse automaticamente migrados;
- en muchos casos sera necesario un
restablecimiento de fabricay un nuevo ciclo de enrollment.
¶ Principales dudas de clientes Nomid
¶ “Si integro Nomid con Google Workspace, Google deja de ser importante?”
No. Google sigue siendo fundamental para identidad, usuarios, estructura organizativa y alcance de la integracion. Lo que cambia es quién gestiona Android Enterprise para la OU configurada.
¶ “Activar el provider en Google ya migra todos los dispositivos?”
No. Eso prepara el alcance para el proveedor correcto, pero no reemplaza automaticamente el estado de los dispositivos ya aprovisionados.
¶ “Puedo mantener Google Advanced y Nomid en el mismo alcance?”
No es el diseño recomendado. Google indica que el modo Advanced no coexiste con EMM de terceros en el mismo contexto Android.
¶ “Qué metodo de aprovisionamiento debo usar?”
Para clientes Nomid, el estandar es siempre fully managed, usando Zero-touch Enrollment, KME o QR Code. El mejor metodo depende del origen del lote y de la automatizacion disponible, pero el objetivo final es siempre el mismo: Android fully managed bajo Nomid.
¶ “Quién pasa a gestionar las apps Android?”
En el alcance entregado a Nomid, la gestion de apps Android debe pasar a Nomid MDM.
¶ “El problema esta en Nomid o en Google?”
Muchos fallos de integracion provienen de:
- OU incorrecta;
- binding incorrecto;
Advanceddejado habilitado por error;- expectativa de migracion automatica;
- identidad aun no sincronizada;
- autenticacion corporativa no alineada con el flujo de enrollment.
¶ Checklist recomendado para proyectos Nomid + Google Workspace
- confirmar la estrategia: solo Google o Google + Nomid;
- mapear las OUs que formaran parte del proyecto;
- validar si
Advanced mobile managementesta activo en el alcance; - ejecutar la integracion base segun el articulo de primeros pasos de Nomid:
Primeros 3 pasos - confirmar que el binding correcto de Nomid aparece en
Manage EMM providers; - confirmar que la OU correcta recibio el provider correcto;
- decidir si se usara
Authenticate Using Google, cuando sea compatible; - validar qué metodo de aprovisionamiento se usara en el proyecto:
Zero-touch,KMEoQR Code; - ejecutar un piloto con un grupo pequeño de usuarios;
- solo despues expandir a escala.
¶ Errores de interpretacion que este articulo busca evitar
- confundir Android Enterprise con Google Endpoint Management;
- asumir que crear el binding ya significa que la integracion esta aplicada;
- asumir que la configuracion vale para todo la empresa sin revisar la OU;
- asumir que Google seguira siendo el punto principal de gestion Android despues de asignar la OU a Nomid;
- asumir que cambiar la configuracion en Google migra automaticamente los dispositivos ya aprovisionados;
- olvidar que las apps Android tambien cambian su punto operativo de gestion;
- olvidar que el contexto de Nomid es
fully managed, no gestion parcial del dispositivo.
¶ Recomendacion final
Para clientes que quieren integrar Nomid MDM con Google Workspace, el diseño mas seguro es:
- usar Google como base de identidad, directorio y alcance;
- usar Nomid como EMM principal para Android Enterprise en las OUs definidas;
- evitar Google
Advanced mobile managementen el mismo alcance; - adoptar
Zero-touch,KMEoQR Codecomo camino de aprovisionamiento parafully managed; - tratar las migraciones como proyectos de transicion, no como cambios instantaneos;
- validar cuidadosamente la OU, el binding y el metodo de aprovisionamiento antes de liberar la operacion.
¶ Fuentes de referencia
- Wiki Nomid: https://wiki.nomid.tech/es/home
- Nomid MDM - First 3 Steps: https://wiki.nomid.tech/es/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