La llegada de Microsoft Dev Home y Microsoft Dev Box ha cambiado por completo la forma en la que una empresa puede montar, mantener y escalar sus entornos de desarrollo en Windows. Ya no se trata solo de instalar herramientas sueltas en cada PC, sino de disponer de un auténtico centro de control para developers y de estaciones de trabajo en la nube listas para usar en cuestión de minutos.
Si estás pensando en usar Windows 11 como base para tus equipos de desarrollo, te interesa conocer bien cómo encajan Dev Home, Dev Box, Dev Drive y el Modo de desarrollador dentro de una estrategia corporativa. En este artículo vas a ver cómo debería ser la instalación inicial y la configuración de Microsoft Dev Home en una empresa, qué requisitos necesitas a nivel de licencias y Azure, y qué decisiones clave debes tomar para que todo sea seguro, eficiente y fácil de mantener.
Qué es Microsoft Dev Home y por qué importa en una empresa
Microsoft Dev Home es, en pocas palabras, un panel centralizado para desarrolladores en Windows 11. Ofrece un dashboard configurable donde puedes seguir el estado de tus proyectos, monitorizar recursos del sistema, configurar entornos de desarrollo, instalar software con WinGet y conectar de forma nativa tus cuentas de GitHub y otros servicios para desarrolladores.
A nivel corporativo, Dev Home funciona como un punto de entrada para todo el flujo de trabajo de desarrollo: desde preparar una nueva máquina (local o en la nube) hasta monitorizar compilaciones, consumo de CPU, memoria o disco. Y acceder a tareas clave de GitHub sin salir de Windows. Es especialmente útil cuando tienes equipos que usan WSL, Visual Studio, VS Code, GitHub Copilot y otros componentes del ecosistema de Microsoft.
La herramienta se apoya en WinGet para permitir una configuración declarativa del entorno. En lugar de instalar herramientas “a mano”, defines un archivo de configuración y lanzas un comando para que Dev Home y WinGet desplieguen automáticamente las aplicaciones, paquetes y ajustes necesarios para cada perfil de desarrollo.
Además del propio Dev Home, Microsoft ha introducido Dev Drive. Este es un tipo de volumen de almacenamiento optimizado para código y repositorios. También ha reforzado la integración con GitHub Copilot y servicios como Microsoft Dev Box y GitHub Codespaces. Se facilita así la mezcla de desarrollo local y en la nube dentro de la misma experiencia de Windows.
Diferencias entre Dev Home, Dev Box y Modo de desarrollador
En un despliegue empresarial es clave no mezclar conceptos, porque Dev Home, Dev Box y el Modo de desarrollador cumplen funciones muy distintas aunque se complementan entre sí.
Por un lado, Microsoft Dev Home es una aplicación para Windows 11 que se instala desde Microsoft Store (actualmente en versión Preview en muchas organizaciones) y que actúa como centro de control: panel de widgets, configuración rápida con WinGet, integración con GitHub y Copilot, acceso a Dev Drive, etc. Se ejecuta en el equipo del desarrollador, ya sea físico o virtual.
Por otro, Microsoft Dev Box es un servicio en Azure que proporciona máquinas virtuales de desarrollo en la nube, preconfiguradas con las herramientas necesarias para cada proyecto o equipo. Esas “cajas de desarrollo” se crean y gestionan desde Azure Portal y el portal para desarrolladores, no desde Dev Home, aunque Dev Home puede encajar muy bien como capa de productividad en cada una de esas máquinas.
Finalmente, está el Modo de desarrollador de Windows, una característica del sistema operativo (presente en Windows 10 y Windows 11) que habilita herramientas adicionales: depuración avanzada, instalación de aplicaciones fuera de Microsoft Store (side-loading), uso de Device Portal, servicios SSH para despliegue remoto y ajustes de diagnóstico más relajados. Este modo se configura desde la app de Configuración, en el área de opciones avanzadas para desarrolladores.
En entornos corporativos suele ser preferible usar Dev Box + Dev Home + Dev Drive y aplicar el Modo de desarrollador solo donde sea estrictamente necesario, ya que sus libertades adicionales pueden afectar a la seguridad si se activan a la ligera en equipos de usuarios que no son developers.
Requisitos previos para desplegar Microsoft Dev Home y Dev Box en empresa
Antes de ponerte a configurar nada, conviene tener muy claros los requisitos de infraestructura, licencias y permisos que necesita una organización para trabajar cómodamente con Dev Box. Y, por extensión, con entornos Windows para desarrolladores. Estos son los requisitos:
- Suscripción de Azure activa. Si la empresa aún no tiene suscripción, es necesario crear una cuenta en Azure y asociar un método de pago o usar una suscripción de evaluación mientras se define la arquitectura definitiva.
- Rol de Propietario u otro rol con permisos equivalentes sobre la suscripción. O, como mínimo, sobre el grupo de recursos donde se desplegarán los servicios de Dev Box y Dev Center. De lo contrario, no podrán crear centros de desarrollo, proyectos ni grupos de cajas.
- Licencias adecuadas de Windows Enterprise, Intune y Microsoft Entra ID P1. Estas licencias vienen incluidas en paquetes como Microsoft 365 E3, E5, A3, A5, Empresa Premium, F3 (con ciertas limitaciones en Windows Enterprise) o el beneficio de estudiantes de Educación. La parte crítica es que el usuario cuente con Windows 11 Enterprise o Windows 10 Enterprise, Microsoft Intune para la gestión de dispositivos y Microsoft Entra ID P1 para la identidad.
- Microsoft Intune para administración de dispositivos (configuración, políticas, cumplimiento) y Microsoft Entra ID como solución de identidad y control de acceso. Dev Box se integra con estos servicios para gestionar el ciclo de vida de las máquinas de desarrollo, el acceso condicional y la protección de datos corporativos.
- Registrar el proveedor de recursos Microsoft.DevCenter. Este registro se hace desde Azure Portal: en la suscripción, apartado Proveedores de recursos, se busca “Microsoft.DevCenter” y se selecciona Registrar. Sin este paso, no se podrán crear centros de desarrollo ni proyectos de Dev Box.
Creación del centro de desarrollo (Dev Center) en Azure
El primer componente que hay que desplegar para usar Dev Box en una empresa es el centro de desarrollo, también conocido como Dev Center. Es el punto central donde se administran proyectos, tamaños de máquinas, imágenes de dev box y configuración de red que después heredarán los equipos.
La creación se realiza desde Azure Portal. En la barra de búsqueda se escribe “Centros de desarrollo” y se elige la opción correspondiente. Dentro de esa vista, se selecciona “Crear” para iniciar el asistente. En la pestaña de aspectos básicos se definen varios parámetros clave: la suscripción de Azure donde se va a crear el centro, el grupo de recursos (nuevo o existente), el nombre del centro de desarrollo y la región de Azure en la que residirán estos recursos. La región conviene elegirla lo más cercana posible a la mayoría de desarrolladores para mejorar la latencia.
Después de los aspectos básicos, el asistente permite acceder a la pestaña de configuración, donde se activan o desactivan varias opciones. Una de ellas son los catálogos de nivel de proyecto, que permiten que los administradores de proyectos adjunten sus propios catálogos además de los globales del Dev Center.
Otra opción importante es la posibilidad de usar redes hospedadas por Microsoft para las Dev Box. Estas redes simplifican mucho la puesta en marcha, ya que proporcionan aislamiento, personalización sencilla y baja carga de administración.
También se puede activar que todos los cuadros de desarrollo del centro instalen automáticamente el agente de Azure Monitor. Este agente envía métricas y logs a Azure Monitor para tener visibilidad completa del rendimiento y estado de las máquinas de desarrollo. Algo muy valioso para equipos de plataforma y seguridad.
En la pestaña de etiquetas se pueden asignar pares nombre-valor (por ejemplo, “Departamento = Desarrollo”, “Proyecto = ProductoX”) que faciliten la organización y el control de costes en Azure. Una vez revisada la configuración, se pulsa en “Crear” y se monitoriza el progreso desde el panel de notificaciones hasta que la implementación finaliza y se puede acceder al nuevo centro de desarrollo.
Definición de proyectos de Dev Box dentro del Dev Center
Cuando el Dev Center está listo, el siguiente paso es crear al menos un proyecto de Dev Box. Los proyectos agrupan la configuración de equipo (límites, catálogos, opciones de personalización) y sirven como contenedor desde el que los desarrolladores verán y crearán sus cajas de desarrollo.
Para crear un proyecto, se inicia sesión en Azure Portal y se busca “Proyectos”. Desde la página de proyectos se selecciona “Crear” y se abre el panel correspondiente. En la pestaña de aspectos básicos se elige la suscripción, el grupo de recursos que se va a usar, el centro de desarrollo con el que se va a asociar el proyecto, un nombre identificativo para el proyecto y una breve descripción del propósito del mismo (por ejemplo, “Desarrollo backend API corporativa”).
En la pestaña de configuración de la caja de desarrollo se definen varias opciones de uso. Una de ellas son las personalizaciones de usuario: si se activan, cada desarrollador podrá ajustar ciertos parámetros de su dev box al crearla (por ejemplo, tamaño dentro de un conjunto permitido), mientras que si se desactivan se fuerza una configuración totalmente estandarizada.
Otra decisión importante es si se van a establecer límites de entornos de desarrollo por usuario. Se puede dejar desmarcada la casilla para que cada developer pueda crear varias Dev Box sin límite desde los grupos asignados, o bien habilitar un máximo de cajas por usuario para controlar costes y evitar proliferación de máquinas innecesarias.
Igual que en el Dev Center, también se pueden aplicar etiquetas al proyecto para simplificar la gestión administrativa. Tras revisar los campos, se confirma la creación y, una vez desplegado, ya se puede acceder al recurso desde Azure Portal.
Creación de grupos de cajas de desarrollo (Dev Box pools)
Los grupos de cajas de desarrollo son la pieza que conecta la configuración del proyecto con las Dev Box concretas que verán los desarrolladores. Un grupo define la imagen base, la región, el tipo de proceso, el almacenamiento, la red y la política de costes (apagados automáticos, hibernación, etc.) para un conjunto de máquinas de desarrollo.
Para crear uno, se abre el proyecto deseado en Azure Portal y se accede a la sección de “Grupos de cuadros de desarrollo”. Desde ahí se selecciona “Crear” y se abre el asistente. En la pestaña de aspectos básicos se pide asignar un nombre para mostrar, que debe ser único dentro del proyecto.
El siguiente punto crítico es elegir la definición de imagen que usará el grupo. Aquí hay varias opciones:
- Definiciones de imagen basadas en archivos YAML que aplican personalizaciones sobre una imagen base.
- Imágenes personalizadas almacenadas en Azure Compute Gallery.
- Imágenes de Marketplace (como Windows 11 Enterprise con Visual Studio).
- Definiciones de Dev Box que combinan imagen y tamaño fijo de VM.
En el apartado de proceso se elige el tamaño de máquina virtual que se usará para las Dev Box de este grupo (vCPU, memoria, etc.). Luego, en almacenamiento, se define el tamaño del disco principal.
En la pestaña de administración se definen los roles y privilegios en las Dev Box. Se puede decidir si las cajas se crean con usuario estándar o con rol de administrador local.
En cuanto al control de costes, el grupo permite configurar apagado automático programado. Se establece una hora de detención diaria y una zona horaria. A esa hora, las Dev Box que soportan hibernación entrarán en ese estado. Las que no, se apagarán.
Gestión de permisos: acceso de usuarios y administradores de proyecto
Para que los desarrolladores puedan crear y gestionar sus cajas de desarrollo, no basta con crear proyectos y grupos. Hay que concederles permisos adecuados mediante roles de Azure en el nivel de proyecto.
El rol clave para los usuarios finales es “Dev Box User de DevCenter”. Asignando este rol a un usuario o grupo sobre un proyecto determinado, se les permite ver ese proyecto, acceder a todos sus grupos de Dev Box, crear cajas de desarrollo a partir de esos grupos y administrar sus propias Dev Box desde el portal para desarrolladores. Por ejemplo: reiniciar, hibernar o eliminar su máquina.
La asignación se realiza desde Azure Portal. En el proyecto correspondiente se entra en “Control de acceso (IAM)”, se elige “Agregar asignación de roles” y se selecciona el rol de usuario de Dev Box. Indicando a continuación los usuarios, grupos o entidades de servicio que deben tener ese acceso. Una vez aplicada la asignación, los desarrolladores ya verán el proyecto. Así, sus grupos y podrán empezar a desplegar sus entornos.
Para delegar la gestión en personas que no sean administradores globales de Azure, existe el rol de “DevCenter Project Admin”. Este rol permite a los administradores de proyecto crear y administrar grupos de Dev Box, definir límites de cajas de desarrollo, configurar escalado automático y gestionar otras opciones de funcionamiento del proyecto, pero sin otorgarles permiso para añadir o eliminar usuarios del proyecto.
De esta forma se consigue un modelo de gobierno equilibrado. El equipo central de plataforma define el Dev Center y las líneas maestras, los administradores de proyecto adaptan los grupos de Dev Box a sus necesidades. De este modo, los desarrolladores se autogestionan sus entornos dentro de los márgenes establecidos.
Instalación e integración de Microsoft Dev Home en los equipos
Una vez que la infraestructura en Azure está en marcha, toca aterrizar la parte visible para el desarrollador. Es decir, Microsoft Dev Home en los equipos Windows 11 de la empresa o en las propias Dev Box que se han creado en la nube.
Dev Home se encuentra disponible en la Microsoft Store como “Dev Home (Preview)”. La instalación es directa: se abre la Store, se busca la aplicación y se pulsa en instalar. En un entorno corporativo se pueden usar herramientas de distribución de software como Intune para desplegar Dev Home de forma masiva en los equipos de los developers o en las imágenes base de las Dev Box.
Cuando Dev Home está instalado, el usuario dispone de un dashboard personalizable donde puede añadir widgets de monitorización de CPU, RAM, GPU, uso de Dev Drive, y widgets específicos de GitHub que muestran repositorios, issues o estado de compilaciones. Cada equipo o área puede adaptar este panel a su forma de trabajar. Esto ayuda a tener en un solo vistazo la información relevante del día a día.
Uno de los grandes atractivos de Dev Home es la integración con WinGet, el gestor de paquetes de Windows. Además, Dev Home facilita la conexión con GitHub y la integración de GitHub Copilot. Al vincular la cuenta de GitHub desde Dev Home, el usuario tiene un widget con el estado de sus repos. Así puede acceder rápidamente a sus proyectos y se prepara el terreno para usar Copilot en herramientas como Visual Studio, VS Code o la propia terminal. Esto permite escribir código más rápido, recibir sugerencias inteligentes y detectar errores de manera temprana.
Dev Drive: almacenamiento optimizado para código y repositorios
Otro componente clave del ecosistema es Dev Drive, un tipo de volumen pensado específicamente para alojar código fuente, repositorios, dependencias, artefactos de compilación y todos los archivos asociados al trabajo diario de programación.
Dev Drive se basa en un sistema de archivos resistente y está optimizado para escenarios de E/S intensivos propios del desarrollo. Microsoft indica que, combinado con el modo de rendimiento de Microsoft Defender para Antivirus, puede ofrecer mejoras de hasta un 30 % en tiempos de compilación en algunos escenarios. Esto se traduce en builds más rápidas, pruebas que completan antes y una sensación general de mayor agilidad.
A nivel de seguridad, Dev Drive está diseñado para ser más seguro que simplemente excluir carpetas o procesos de Defender. El modo de rendimiento reduce el impacto del antivirus sobre el sistema de archivos sin renunciar a la protección, algo especialmente importante cuando se maneja código confidencial o propiedad intelectual de la empresa. La idea práctica es dedicar Dev Drive a todo lo que tenga que ver con código: repos de Git, proyectos de Visual Studio o VS Code, dependencias de paquetes, etc., facilitando además probar software sin dejar rastro en el sistema. De este modo se logra un equilibrio entre rendimiento y protección, evitando que el antivirus penalice en exceso las operaciones de lectura/escritura típicas de la programación.
Uso y configuración del Modo de desarrollador en Windows 11
En paralelo a Dev Home y Dev Box, muchas empresas necesitan activar en ciertos dispositivos el Modo de desarrollador de Windows, sobre todo cuando se desarrollan y prueban aplicaciones UWP, MSIX o escenarios que requieren despliegue remoto y depuración avanzada.
Este modo se encuentra en la aplicación de Configuración, normalmente en la sección Sistema > Opciones avanzadas (o “System > Advanced”) dentro del apartado “Para desarrolladores” (consulta ajustes de Windows 11 que usan los expertos). Al activarlo, se desbloquean herramientas especiales diseñadas para compilar, implementar y probar software en Windows. Incluyendo la posibilidad de instalar aplicaciones que no provienen de Microsoft Store y opciones de depuración adicionales.
Cuando se habilita el modo de desarrollador, Windows instala un paquete de características específicas. Entre ellas se incluyen Windows Device Portal, un entorno web de administración remota para el dispositivo. La configuración de reglas de firewall para permitir servicios SSH. La habilitación del servidor SSH cuando se activa la detección de dispositivos, lo que facilita la instalación remota de aplicaciones y su depuración desde Visual Studio.
Device Portal se puede usar, por ejemplo, para implementar aplicaciones en dispositivos de prueba como tablets o máquinas dedicadas a QA, mientras que la detección de dispositivos permite que esos equipos sean visibles en la red mediante mDNS y que se pueda realizar el emparejamiento por PIN necesario para la primera implementación desde Visual Studio.
Al habilitar la detección de dispositivos, el sistema expone un botón de “Par” que, al pulsarlo, muestra un PIN temporal en pantalla. Ese PIN se utiliza como contraseña para la cuenta DevToolsUser a través de SSH, y solo es válido mientras permanece visible. Además, se activa un subsistema SFTP que permite gestionar manualmente la carpeta DevelopmentFiles, donde se instalan las implementaciones de archivos sueltos.
Problemas habituales con el Modo de desarrollador y cómo gestionarlos
En algunos entornos corporativos, la activación del Modo de desarrollador puede dar fallos porque el paquete correspondiente no se descarga o instala correctamente. Esto suele deberse a políticas empresariales, problemas de conectividad o bloqueos en servicios como WSUS.
Un error recurrente es el código 0x80004005 indicando que el paquete no se pudo encontrar en Windows Update. Ante este mensaje, lo primero es comprobar que el equipo tiene acceso a Internet. Si está unido a un dominio, hablar con el administrador de red. En muchas organizaciones, las características bajo demanda (como el paquete del modo de desarrollador) están bloqueadas por defecto en WSUS. Hay que permitir explícitamente ciertos KB para que puedan descargarse.
En concreto, se recomienda revisar que las actualizaciones KB4016509, KB3180030 y KB3197985 estén permitidas en WSUS en versiones actuales o anteriores de Windows, ya que están relacionadas con la disponibilidad de este paquete. Tras ajustar la configuración, conviene forzar la búsqueda de actualizaciones desde Configuración → Actualización de Windows y confirmar que el componente aparece en las características opcionales.
Otro mensaje común es que el paquete no se ha podido instalar, también con código 0x80004005. Pero en este caso por incompatibilidades entre la compilación de Windows y el paquete. La solución suele pasar por instalar todas las actualizaciones pendientes y reiniciar el equipo.
En escenarios donde se siguen produciendo errores, es recomendable enviar comentarios a Microsoft a través del Centro de opiniones. Especialmente si se trata de un entorno empresarial gestionado, por si hubiera algún conflicto específico con las políticas de la compañía.
Habilitar el Modo de desarrollador mediante directivas, Registro o PowerShell
En contextos de automatización o pruebas masivas, muchas empresas prefieren no depender de que el usuario active manualmente el Modo de desarrollador. En estos casos se puede recurrir a Directivas de grupo (gpedit.msc), claves del Registro o scripts de PowerShell para configurar los dispositivos de forma centralizada.
Con el editor de directivas de grupo (no disponible en ediciones Home de Windows 10 o 11), se puede ir a Directivas de equipo → Configuración del equipo → Plantillas administrativas → Componentes de Windows → Implementación de paquetes de aplicaciones y ajustar las políticas necesarias. Para permitir la instalación de aplicaciones de confianza (side-loading) se habilita la política “Permitir que todas las aplicaciones de confianza se instalen”.
Si además se quiere activar el modo de desarrollador completo y la instalación de aplicaciones desde un entorno de desarrollo integrado (IDE) como Visual Studio, hay que habilitar la política que permite el desarrollo de aplicaciones para UWP e instalación desde el IDE. Después de ajustar estas políticas, se recomienda reiniciar los dispositivos para que los cambios surtan efecto.
Combinando correctamente Microsoft Dev Box, Dev Home, Dev Drive y el Modo de desarrollador, una empresa puede pasar de setups manuales y propensos a errores a entornos de desarrollo estandarizados, reproducibles y seguros, donde montar una nueva estación de trabajo (local o en la nube) deja de ser cuestión de días y pasa a resolverse en cuestión de horas o incluso minutos. Con todo el ecosistema de Windows, GitHub y Azure trabajando a favor del equipo de desarrollo.
