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, KME o QR 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:

• Primeros 3 pasos

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, como Zero-touch Enrollment o KME, o aprovisionamiento mediante QR 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:

1. Plataforma de identidad y administracion, usando la Admin Console para definir alcance, autenticacion e integraciones.
2. 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 Workspace controla identidad, usuarios, unidades organizativas e integraciones;
• Nomid MDM controla 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 Enterprise es la base tecnologica utilizada por los proveedores EMM para gestionar Android corporativo.
• Google Endpoint Management (GEM) es el EMM nativo de Google.
• Nomid MDM tambien 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 MDM se convierte en el punto central de administracion de los dispositivos Android aprovisionados;
• el metodo de aprovisionamiento debe ser Zero-touch, KME o QR Code, siempre en modo fully 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 management no debe coexistir con Nomid como EMM Android para la misma OU;
• si el cliente planea usar Nomid, la recomendacion es evitar mantener Advanced en el alcance que se entregara a Nomid;
• en migraciones, dejar Advanced habilitado 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 reinscripcion y, para dispositivos fully managed, a menudo un nuevo aprovisionamiento o restablecimiento 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:

• Primeros 3 pasos

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 ID en 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:

• Primeros 3 pasos

Desde la perspectiva de este articulo, los puntos conceptuales que deben validarse antes de avanzar son:

• el Android Enterprise de Nomid debe estar activo y alineado con el entorno correcto;
• el Enterprise ID mostrado en Nomid debe coincidir con el binding esperado en Google;
• el proyecto debe dejar claro si la empresa es de produccion o homologacion;
• 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 Google esta 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

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 MDM para 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 management en el alcance que se migrara;
• definir si el lote usara Zero-touch, KME o QR 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 fabrica y 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;
• Advanced dejado 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 management esta 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, KME o QR 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 management en el mismo alcance;
• adoptar Zero-touch, KME o QR Code como camino de aprovisionamiento para fully 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

Véase también

• Google Cloud Identity
• Integraciones
• Aprovisionamiento por Zero-touch
• Aprovisionamiento por KME
• Políticas