Gestión declarativa de la configuración de Windows con DSC — empezar IaC con dsc.exe

El manual de instalación de un PC nuevo, la hoja de Excel con los pasos de construcción del servidor, el archivo BAT secreto que dejó alguien que ya no está en la empresa: en muchos talleres, la gestión de la configuración de Windows sigue funcionando con «un documento que describe los pasos» y «un script que ejecuta los pasos». La debilidad de este enfoque es clara: los pasos empiezan a desviarse de la realidad en el momento en que se ejecutan, y el script se rompe en la segunda ejecución.

En Linux y en la nube, el IaC declarativo (Infrastructure as Code) como Terraform y Ansible se ha convertido en la norma. Entonces, ¿qué hay que usar para gestionar los propios clientes y servidores Windows con la misma mentalidad? La respuesta de Microsoft es DSC (Desired State Configuration), y con Microsoft DSC v3 (dsc.exe), reescrito en 2025 como herramienta de línea de comandos independiente de PowerShell, por fin ha llegado a una forma con la que se puede «empezar a usarlo sin más».¹

Los lectores previstos son desarrolladores y personal de TI que gestionan la configuración de clientes y servidores Windows con manuales de procedimientos y scripts, y quieren pasar a una gestión declarativa. Los requisitos previos son Windows 10/11 y DSC 3.0 o posterior, con el manejo básico de PowerShell como conocimiento de fondo. La dificultad es intermedia.

1. Primero la conclusión

Con DSC se escribe el «estado deseado» en YAML, no los «pasos que hay que ejecutar». Los recursos asumen detectar la diferencia respecto al estado actual (test) y aplicarla (set), de modo que el mismo archivo es seguro (idempotente) por muchas veces que se ejecute, y la configuración se convierte en datos que se pueden revisar en Git. Si empieza ahora, Microsoft DSC v3 (dsc.exe) es la única opción.

La diferencia entre un script de procedimientos y una configuración declarativa se ve en cómo se rompen. Un script que codifica pasos se detiene con una aplicación duplicada o con errores cuando lo vuelve a ejecutar contra una máquina que falló a mitad de camino o que ya está configurada. Una configuración declarativa describe solo el estado deseado, de modo que por muchas veces que la ejecute, y desde cualquier estado intermedio, converge en el mismo resultado.²

flowchart TB
    accTitle: Script de procedimientos imperativo frente a configuración declarativa
    accDescr: Un script imperativo ejecuta los pasos desde arriba, de modo que volver a ejecutarlo provoca una aplicación duplicada o una parada, mientras que DSC declarativo declara el estado deseado y aplica solo la diferencia, de modo que converge en el mismo estado por muchas veces que se ejecute
    imp["Imperativo: escribir los pasos (BAT, manual)"] --> i1["Ejecutar de arriba abajo"]
    i1 --> i2["Reejecución: aplicación duplicada, errores"]
    dec["Declarativo: escribir el estado (DSC)"] --> d1["Detectar la diferencia respecto al estado actual"]
    d1 --> d2["Aplicar solo la diferencia, seguro cada vez"]

Figura 1: Un script imperativo es sensible a «cuántas veces ha corrido»; una configuración declarativa converge en el mismo estado por muchas veces que se ejecute.

En el diagrama, una línea continua marca una relación que siempre se cumple y una línea discontinua una relación condicional (las condiciones están en la explicación de cada relación en la página de detalle). La lista completa de relaciones (17 en total, con evidencia y grado de certeza) y las definiciones de los conceptos principales están reunidas en la página de detalle del mapa de conocimiento (en japonés). Datos: JSON-LD / Turtle

2. Desenredar la confusión en torno al nombre «DSC» — cuatro líneas

Lo primero que hace tropezar al aprender DSC no es la tecnología en sí, sino la confusión en los resultados de búsqueda. Cuatro líneas de mecanismos llevan el nombre «DSC», y difieren en cómo se escriben, cómo se ejecutan y con qué son compatibles.³

Microsoft DSC v3 no es simplemente una actualización del PowerShell DSC (PSDSC) anterior; es un producto distinto, reescrito cortando la dependencia de PowerShell. Las configuraciones pasan a ser datos JSON/YAML en lugar de scripts de PowerShell, los recursos se pueden implementar en cualquier lenguaje, y se ejecuta igual en Linux, macOS y Windows.¹

flowchart TB
    accTitle: Linaje de las cuatro generaciones de DSC
    accDescr: De PSDSC v1.1 integrado en Windows PowerShell 5.1 derivan PSDSC v2 para PowerShell 7 y la versión preliminar de PSDSC v3 para Machine Configuration, mientras que Microsoft DSC v3, reescrito por separado sin dependencia de PowerShell, es la línea principal actual
    v11["PSDSC v1.1 (integrado en WinPS 5.1)"] --> v2["PSDSC v2 (PowerShell 7)"]
    v2 --> v3ps["PSDSC v3 versión preliminar"]
    v11 -.->|"reescritura"| dsc3["Microsoft DSC v3 (dsc.exe)"]
    v3ps --> mc["Azure Machine Configuration"]
    dsc3 --> now["El tema de este artículo"]

Figura 2: Buscar «DSC» devuelve información de las cuatro líneas mezclada. Distinguir de qué línea trata un artículo o un documento es lo primero que hay que hacer.

A partir de aquí, «DSC» en este artículo significa Microsoft DSC v3. Que los activos de las generaciones anteriores no se desperdicien se trata más adelante (sección 6).

3. Qué significa «declarativo» — get, test, set e idempotencia

El concepto central de DSC es el recurso. Un recurso proporciona las operaciones de recuperar el estado (Get), evaluarlo (Test) y aplicarlo (Set) para un tipo de destino de configuración, como «valor del Registro», «característica de Windows» o «variable de entorno». Todo recurso implementa Get. En los recursos que no implementan Test, DSC interviene con una prueba sintética que compara el resultado recuperado con la declaración. Set lo implementan solo los recursos que pueden imponer un estado; los recursos de solo lectura, como la información del SO, no lo tienen.⁴ El usuario deja el «cómo configurarlo» al recurso y escribe solo «qué debe estar en qué estado» como datos.

Esta división del trabajo es lo que produce la idempotencia. Cuando se aplica un documento de configuración (dsc config set), DSC prueba primero cada instancia y llama a set solo en las que no están en el estado deseado. Por eso aplicar la misma configuración cualquier número de veces es seguro. Hay una diferencia: cuando se ejecuta dsc resource set sobre un solo recurso, set se llama siempre, y si se ejecuta una prueba de antemano depende de la implementación del recurso (implementsPretest).⁵

flowchart TB
    accTitle: El bucle de convergencia de get, test y set
    accDescr: test compara el estado deseado escrito en el documento de configuración con el estado actual, no ocurre nada si no hay diferencia, y si la hay, set aplica solo la diferencia y get confirma el resultado, un flujo de convergencia idempotente
    doc["Documento de configuración (estado deseado)"] --> test["test: comparar con el estado actual"]
    test -->|"sin diferencia"| ok["No hacer nada (idempotente)"]
    test -->|"diferencia"| set["set: aplicar solo la diferencia"]
    set --> get["get: confirmar el estado resultante"]

Figura 3: Aplicar DSC es un bucle de «comparar primero y luego cambiar solo lo necesario», que libera de la noción de número de ejecuciones.

Veamos la diferencia respecto a un script imperativo en código. Tomemos «poner este valor en el Registro»: en un script usted escribe la comprobación de existencia, la creación y la actualización, cada una como su propia rama.

# Imperativo: escribir los "pasos". Usted gestiona cada rama y cada orden
$path = 'HKCU:\Software\MyCompany\App'
if (-not (Test-Path $path)) {
    New-Item -Path $path -Force | Out-Null
}
Set-ItemProperty -Path $path -Name 'Mode' -Value 'standard'

En DSC se escribe lo mismo como declaración del «estado deseado». No hay comprobación de existencia ni ramificación.

# Declarativo: escribir el "estado". Crear y corregir son trabajo del recurso
- name: Modo de funcionamiento de la aplicación
  type: Microsoft.Windows/Registry
  properties:
    keyPath: HKCU\Software\MyCompany\App
    valueName: Mode
    valueData:
      String: standard

4. Instalar dsc.exe y llamar a los recursos de uno en uno

Hay dos formas de instalar DSC. Extraer el archivo de la versión de GitHub y añadirlo al PATH, o, en Windows, instalarlo con winget desde el origen de Microsoft Store.¹

# Buscar e instalar la versión estable desde el origen de Microsoft Store
winget search DesiredStateConfiguration --source msstore
winget install --id 9NVTPZWRC6KQ --source msstore

Una vez instalado, primero enumere los recursos disponibles en la máquina local.

dsc resource list

Antes de escribir un documento de configuración, también puede llamar a los recursos de uno en uno por sí solos. Poder «probar en pequeño» es lo que hace fácil de aprender la v3.⁶

# Recuperar el estado actual (get)
dsc resource get --resource Microsoft.Windows/Registry `
  --input '{"keyPath":"HKCU\\Software\\MyCompany\\App","valueName":"Mode"}'

# Evaluar si está en el estado deseado (test) — no hace ningún cambio
dsc resource test --resource Microsoft.Windows/Registry `
  --input '{"keyPath":"HKCU\\Software\\MyCompany\\App","valueName":"Mode","valueData":{"String":"standard"}}'

flowchart TB
    accTitle: Las cuatro operaciones del comando dsc resource
    accDescr: Bajo el comando dsc resource cuelgan cuatro operaciones, list para enumerar recursos, get para recuperar el estado actual, test para evaluar el estado deseado sin cambios, y set para aplicar el estado (solo en recursos que implementan Set)
    cli["comando dsc resource"] --> l["list: enumerar recursos"]
    cli --> g["get: recuperar el estado actual"]
    cli --> t["test: evaluar solo, sin cambios"]
    cli --> s["set: aplicar (recursos que admiten Set)"]

Figura 4: Los recursos se pueden llamar por sí solos sin escribir un documento de configuración. Empezar por la observación, usando solo get y test, es la vía de entrada segura.

Las operaciones que hacen cambios mediante set, y los recursos que tratan HKLM o la configuración del sistema, requieren privilegios de administrador. Lo más seguro es empezar a experimentar con ejemplos cuyo destino de escritura está en el ámbito del usuario (como HKCU).

5. El documento de configuración — escribir el «estado deseado» en YAML

Un documento de configuración declara varios recursos juntos. Se escribe en YAML o JSON y define, como mínimo, las dos propiedades $schema y resources. Cada instancia de recurso tiene un name (un nombre para mostrar único en el documento), un type (el nombre completo del recurso) y properties (el estado deseado).²

# standard-pc.dsc.config.yaml — el estado deseado de un PC cliente estándar
$schema: https://aka.ms/dsc/schemas/v3/bundled/config/document.json
parameters:
  appMode:
    type: string
    defaultValue: standard
resources:
  - name: Modo de funcionamiento de la aplicación
    type: Microsoft.Windows/Registry
    properties:
      keyPath: HKCU\Software\MyCompany\App
      valueName: Mode
      valueData:
        String: "[parameters('appMode')]"

Con parameters y variables, las diferencias entre entornos (valores de configuración por departamento, por ejemplo) se pueden expresar en un solo documento. La sintaxis de expresiones es un subconjunto de las funciones de plantillas ARM.²

flowchart TB
    accTitle: Estructura de un documento de configuración
    accDescr: Un documento de configuración consta de un esquema que identifica el esquema del documento, parameters y variables que absorben las diferencias de entorno, y una matriz resources de instancias de recursos, cada una de las cuales tiene name, type y properties
    docroot["Documento de configuración (YAML / JSON)"] --> sch["$schema: URI del esquema del documento"]
    docroot --> par["parameters / variables"]
    docroot --> res["resources: matriz de instancias"]
    res --> inst["name, type, properties"]
    par -.-> inst

Figura 5: Un documento de configuración es datos sencillos, nada más que «esquema + parámetros + declaraciones de recursos»; no es un programa.

Ponga siempre la «observación» antes de aplicar. dsc config test informa de si hay diferencias sin hacer cambios, y dsc config set --what-if muestra una predicción de «qué cambiaría si se ejecutara».⁷

# 1. Comprobar si hay diferencias (sin cambios)
dsc config test --file .\standard-pc.dsc.config.yaml

# 2. Mostrar una predicción de lo que cambiaría al aplicar (sin cambios)
dsc config set --file .\standard-pc.dsc.config.yaml --what-if

# 3. Aplicar una vez convencido
dsc config set --file .\standard-pc.dsc.config.yaml

# 4. Confirmar el estado después de aplicar
dsc config get --file .\standard-pc.dsc.config.yaml

También hay un punto de entrada en la dirección inversa. Para los recursos enumerados en el documento de entrada pasado con --file (solo los que admiten export), dsc config export genera un documento de configuración que contiene cada instancia del sistema y lo escribe en la salida estándar. Puede servir como punto de partida para consignar el estado actual de un entorno existente.⁸

# Pasar un documento de entrada que enumera los recursos de destino y guardar el documento de configuración actual
dsc config export --file .\export-targets.dsc.config.yaml > .\current-state.dsc.config.yaml

flowchart TB
    accTitle: Los cuatro pasos de una aplicación segura
    accDescr: Comprobar las diferencias con dsc config test, que no hace cambios, previsualizar los cambios con la opción what-if de dsc config set, aplicar con set una vez convencido, y confirmar el resultado con get, en ese orden seguro
    t["dsc config test (comprobar diferencias)"] --> w["set --what-if (predecir los cambios)"]
    w --> s["dsc config set (aplicar)"]
    s --> g["dsc config get (confirmar el resultado)"]

Figura 6: Mientras se conserve el orden «observar, predecir, aplicar, confirmar», aplicar una configuración declarativa no tiene nada del miedo a jugársela a una sola carta.

Que un documento de configuración sea datos, y no un programa, es su mayor ventaja operativa. «Qué debe estar configurado en esta máquina» se puede revisar como un diff YAML, y el historial de cambios es, tal cual, el historial de cambios de la configuración.

6. Reutilizar activos existentes — adaptadores para recursos PSDSC y WinGet Configuration

Oír que «la v3 es un producto distinto» hace temer por los activos del pasado, pero DSC v3 puede llamar a los recursos PSDSC de generaciones anteriores mediante un mecanismo llamado recursos adaptadores. Con los nombres actuales en DSC 3.2 y posteriores, Microsoft.Adapter/PowerShell sirve a los recursos basados en clases para PowerShell 7 y Microsoft.Adapter/WindowsPowerShell sirve a los recursos basados en MOF y en scripts para Windows PowerShell 5.1 (antes se llamaban Microsoft.DSC/PowerShell y Microsoft.Windows/WindowsPowerShell).⁹ El ecosistema de recursos PSDSC acumulado durante muchos años es alcanzable directamente desde un documento de configuración v3.

El otro punto de conexión es WinGet Configuration. Los archivos .winget presentados en el artículo de kitting de PC usan DSC v3 directamente como procesador a partir del esquema v3 (WinGet 1.11 y posteriores). Cuando se especifica dscv3 como procesador en los metadata del archivo de configuración, el cuerpo del documento es en sí un documento de configuración DSC v3.¹⁰

# WinGet Configuration v3 — el cuerpo es un documento de configuración DSC v3
$schema: https://raw.githubusercontent.com/PowerShell/DSC/main/schemas/2023/08/config/document.json
metadata:
  winget:
    processor:
      identifier: dscv3
resources:
  - name: Modo de funcionamiento de la aplicación
    type: Microsoft.Windows/Registry
    properties:
      keyPath: HKCU\Software\MyCompany\App
      valueName: Mode
      valueData:
        String: standard

Hay una salvedad. Un archivo existente en formato v2 (el formato con properties.configurationVersion: 0.2.0 y los recursos colocados bajo properties) no se ejecuta tal cual en el procesador dscv3. Los archivos v2 siguen funcionando con el procesador anterior, pero para ponerlos en DSC v3 se migra el formato siguiendo la guía oficial de conversión («Convert to v3» en el repositorio de ejemplos).¹⁰

flowchart TB
    accTitle: La estructura en capas centrada en DSC v3
    accDescr: Capas de orquestación como winget configure y Azure Machine Configuration llaman a DSC v3, y DSC v3 llama a recursos nativos directamente y a recursos PSDSC existentes mediante recursos adaptadores
    orch["winget configure, Machine Configuration"] --> dsc["dsc.exe (DSC v3)"]
    dsc --> native["Recursos nativos (Registry etc.)"]
    dsc --> adapter["Recursos adaptadores"]
    adapter --> psdsc["Recursos PSDSC existentes (activos de PowerShell)"]

Figura 7: DSC v3 es una herramienta independiente y, al mismo tiempo, el fundamento común bajo herramientas de nivel superior como winget y Azure. Los activos PSDSC existentes cuelgan bajo el adaptador.

En otras palabras, el conocimiento y las configuraciones que se escriben para la v3 funcionan con dsc.exe en la propia máquina, con winget configure en el kitting, y con Machine Configuration en la gestión en la nube. Esto no es reaprender; los caminos confluyen.¹

7. Ponerlo en operación — gestionar en Git y detectar la deriva

El lugar donde guardar los documentos de configuración es un repositorio Git. Los cambios de configuración siguen entonces el mismo flujo que el desarrollo de software: revisar en una pull request, fusionar, aplicar. La noción misma de un manual de procedimientos que nadie actualizó desaparece.

El reto después de aplicar es la deriva de configuración (alguien cambia un ajuste a mano y la máquina se aleja del estado deseado). En DSC, la detección de deriva es simplemente ejecutar dsc config test de forma programada. Como test no hace cambios, la detección y la corrección se pueden separar, lo cual es una propiedad importante. El patrón de operación seguro es automatizar primero la detección, y corregir (set) solo después de comprobar cuáles son las diferencias.

# Para ejecuciones programadas: distinguir un fallo de test en sí, errores por recurso y deriva, y salir distinto de cero en todos los casos
$json = dsc config test --file C:\config\standard-pc.dsc.config.yaml
if ($LASTEXITCODE -ne 0 -or -not $json) {
    Write-Error "dsc config test en sí no pudo ejecutarse (código de salida: $LASTEXITCODE)"
    exit 2
}
$result = $json | ConvertFrom-Json
if ($result.hadErrors) {
    # Falló la validación del documento o algún recurso salió distinto de cero. La comprobación no terminó, así que no informar como sano
    Write-Error "La comprobación de algunos recursos terminó en errores. Inspeccionar messages"
    exit 2
}
if ($result.results.result.inDesiredState -contains $false) {
    Write-Error "Deriva de configuración detectada"
    exit 1
}

Para la infraestructura de programación, el Programador de tareas sirve en los clientes (el diseño de la ejecución desatendida se trata en un artículo aparte) y los runners de CI sirven para flotas de servidores. En las organizaciones que han consolidado la gestión en Azure, Machine Configuration es el servicio de orquestación administrado que audita y aplica la configuración a las máquinas virtuales de Azure y, mediante Azure Arc, a servidores locales.¹¹

flowchart TB
    accTitle: El ciclo operativo de la gestión de configuración partiendo de Git
    accDescr: Los documentos de configuración guardados en un repositorio Git se revisan en una pull request antes de aplicarse, ejecuciones periódicas de test desde el Programador de tareas o la CI detectan la deriva, y tras inspeccionar la diferencia el ciclo vuelve a la corrección o a actualizar la configuración
    git["Repositorio Git (documentos de configuración)"] --> pr["Cambios revisados en pull requests"]
    pr --> apply["Aplicar con dsc config set"]
    apply --> sched["Ejecución programada: dsc config test"]
    sched -->|"deriva detectada"| judge["Inspeccionar la diferencia y decidir"]
    judge -.->|"la configuración es correcta"| fix["Corregir con set"]
    judge -.->|"la realidad es correcta"| git

Figura 8: Tratar la deriva no es solo «corregir». Si el cambio hecho en el terreno es el adecuado, corregir el documento de configuración y fusionarlo es la práctica propia de la gestión declarativa.

La rama de la parte inferior derecha de la figura 8 es fácil de pasar por alto. La deriva no siempre es «mala»; a veces solo significa que un cambio que hacía falta en el terreno aún no se ha reflejado en la configuración. En ese caso, en lugar de revertir la máquina, actualice el documento de configuración para que coincida con la realidad. Mientras se mantenga la disciplina de que la fuente de verdad es siempre la declaración en Git, la gestión no se rompe hacia el lado que se incline.

8. Restricciones y trampas

Aquí, con franqueza, las restricciones que conviene conocer antes de adoptarlo.

No hay LCM. El LCM (Local Configuration Manager) de la v1.1 era un agente residente que conservaba la configuración y realizaba la aplicación periódica y la corrección automática. La v3 es «un comando que solo se ejecuta cuando se llama» y no permanece residente como servicio.¹ Si necesita imposición continua, tiene que elegir usted mismo la infraestructura de ejecución (Programador de tareas, CI, Machine Configuration), como en la sección anterior. Esto no es una regresión, sino un cambio de diseño que abre «cómo se ejecuta» a las herramientas modernas; aun así desorienta si se llega con la mentalidad de la operación pull server de la v1.1.

Trato de los privilegios de administrador. set en recursos que afectan a toda la máquina (HKLM, características de Windows, etc.) requiere elevación, y usar recursos PSDSC de Windows PowerShell a través del adaptador también asume ejecutarse como administrador.⁶ Separar los ajustes por usuario de los ajustes por máquina ya en la etapa del documento de configuración facilita diseñar el contexto de ejecución.

No escriba secretos en la configuración. Los documentos de configuración son datos que van a Git. No escriba en ellos contraseñas ni claves de API de forma directa; parametrícelos y páselos en tiempo de ejecución.

Lea los archivos de configuración de otros antes de ejecutarlos. Un documento de configuración tiene el poder de cambiar el sistema a través de recursos. Antes de aplicar un archivo .winget o un documento de configuración obtenido de un repositorio público, compruebe su contenido y la fiabilidad de los recursos que referencia. Es una obligación operativa sobre la que también avisa de forma explícita la documentación oficial.¹²

flowchart TB
    accTitle: El LCM residente de la v1.1 frente al modelo de comando de la v3
    accDescr: En PSDSC v1.1 un LCM residente conservaba la configuración y se ocupaba del pull periódico y de la corrección automática, mientras que DSC v3 solo se inicia como comando, de modo que usted elige y prepara la infraestructura de programación entre el Programador de tareas, la CI y Machine Configuration
    v1["PSDSC v1.1: LCM residente"] --> pull["Conserva la configuración, pull periódico, corrección automática"]
    v3["DSC v3: solo invocación de comando"] --> push["Usted aporta la infraestructura de ejecución"]
    push -.-> ex["Programador de tareas, CI, Machine Configuration"]

Figura 9: En la v3 no hay «alguien que recuerda la configuración y la corrige por su cuenta». Tomarlo como una molestia o como recuperar el control sobre la ejecución es donde está la decisión de diseño.

9. Resumen — sustituir el manual de procedimientos por un repositorio

• Si empieza ahora el IaC declarativo para Windows, use Microsoft DSC v3 (dsc.exe). De las cuatro líneas llamadas «DSC», tenga siempre presente de cuál tratan las informaciones que lee.³
• DSC escribe el «estado deseado», no los «pasos», en YAML/JSON, y test (comparar) y set (aplicar la diferencia) garantizan una convergencia idempotente. El flujo seguro es empezar por la observación con dsc resource get/test, comprobar el impacto con --what-if y luego aplicar.⁷
• Los recursos PSDSC existentes se incorporan al mundo v3 mediante adaptadores, y los activos .winget de kitting mediante el esquema v3 de WinGet Configuration (los archivos en formato v2 necesitan una migración de formato siguiendo la guía de conversión).⁹¹⁰
• La v3 no tiene LCM. El eje de la operación es mantener la fuente de verdad en Git, detectar la deriva con ejecuciones programadas de dsc config test, y seguir la disciplina «si la configuración es correcta, corregir; si la realidad es correcta, actualizar la configuración».

El destino de un manual de procedimientos era desviarse de la realidad desde el momento en que se escribía. La gestión declarativa de la configuración convierte esa desviación en una «diferencia detectable». Empiece por escribir un puñado de ajustes de su propia máquina en un documento de configuración y ejecutar dsc config test. Debería notar cómo el manual de procedimientos se convierte en un repositorio.

Artículos relacionados

• Automatizar el kitting de PC con winget + PowerShell ── Convertir el manual de procedimientos en algo ejecutable
• ¿Esa bat debería migrarse a PowerShell? — Inventario y criterio de migración de los activos cmd/bat
• Las tareas del Programador de tareas no se ejecutan o terminan con 0x1 — cómo aislar la causa y diseñar una operación segura
• De la directiva de grupo a Intune — Guía de migración de gestión de dispositivos para pymes
• Gestión de Windows Update tras el fin de soporte de WSUS

Áreas de consultoría relacionadas

KomuraSoft LLC ayuda a migrar la configuración de clientes y servidores Windows a una gestión declarativa, a automatizar el kitting y los entornos internos estándar, y a convertir en ejecutables los manuales de procedimientos que dependen de una persona.

• Consultoría técnica y revisión de diseño
• Modificación y mantenimiento de software existente para Windows
• Reutilización y migración de activos existentes
• Contacto

Referencias

Artículos relacionados

Artículos recientes con las mismas etiquetas para profundizar en temas cercanos.

Temas relacionados

Estas páginas sitúan el tema en un contexto más amplio de servicios y decisiones.

Servicios relacionados con este tema

El artículo está directamente relacionado con los siguientes servicios.

Preguntas frecuentes

Preguntas habituales en las consultas sobre el tema del artículo.

Parece que hay varias versiones de DSC. ¿Cuál debo usar?

Si empieza ahora la gestión declarativa de la configuración, use Microsoft DSC v3 (dsc.exe). Hay cuatro líneas de DSC: PSDSC v1.1 integrado en Windows PowerShell 5.1, PSDSC v2 como módulo para PowerShell 7, PSDSC v3 (versión preliminar) usado para la compatibilidad con Linux de Azure Machine Configuration, y Microsoft DSC v3, reescrito como comando independiente que no depende de PowerShell. La v3 es multiplataforma, escribe la configuración como datos YAML/JSON en lugar de scripts de PowerShell, y puede reutilizar recursos PSDSC existentes mediante adaptadores. Al buscar, añadir "DSC v3" o "dsc.exe" facilita separar los resultados del material de generaciones anteriores.

¿En qué se diferencia DSC v3 de un script de procedimientos (BAT o PowerShell)?

Un script de procedimientos describe "los pasos que hay que ejecutar", así que tiene que construir usted mismo la idempotencia para evitar una aplicación duplicada o errores en la segunda ejecución. DSC escribe el "estado deseado" como datos, y los recursos asumen la comparación con el estado actual (test) y la aplicación de la diferencia (set). Por muchas veces que ejecute el mismo documento de configuración, no hace nada con los elementos que ya están en el estado deseado, de modo que puede distribuirlo y volver a ejecutarlo sin preocuparse del número de ejecuciones. Y como la configuración es datos YAML, las revisiones de diff y el historial de versiones en Git son mucho más fáciles que con scripts.

¿Se desperdiciarán mis recursos de PowerShell DSC y mis activos de WinGet Configuration existentes?

No. DSC v3 puede llamar a recursos PSDSC existentes basados en clases y en MOF mediante recursos adaptadores (Microsoft.Adapter/PowerShell y Microsoft.Adapter/WindowsPowerShell en DSC 3.2 y posteriores; Microsoft.DSC/PowerShell y Microsoft.Windows/WindowsPowerShell antes). WinGet Configuration, a partir de su esquema v3 (WinGet 1.11 y posteriores), usa DSC v3 como procesador. Los archivos .winget existentes en formato v2 siguen ejecutándose en el procesador anterior, pero para ponerlos en el procesador de DSC v3 hay que convertirlos al formato v3 siguiendo la guía oficial de conversión.

¿Cómo impongo una configuración "de forma continua" con DSC v3?

DSC v3 en sí es una herramienta que se inicia como comando; no tiene agente residente ni mecanismo de corrección automática como el LCM (Local Configuration Manager) de la v1.1. Si necesita aplicación y auditoría continuas, construya su propia detección de deriva ejecutando dsc config test periódicamente desde el Programador de tareas o la CI, o colóquelo en una capa de orquestación como Azure Machine Configuration (que también puede cubrir servidores locales mediante Azure Arc).

Me da recelo ejecutar dsc config set de inmediato. ¿Puedo comprobar el impacto de antemano?

Sí. Ejecutar dsc config test muestra qué instancias de recursos no están en el estado deseado, sin hacer cambios. Además, dsc config set tiene una opción --what-if que muestra una predicción de "qué cambiaría, y cómo, si se ejecutara" sin cambiar nada realmente. Compruebe primero las diferencias con test y --what-if, y ejecute set solo cuando esté convencido; esa secuencia es segura.

Perfil del autor

Página de presentación del autor del artículo.

Go Komura

Representante de KomuraSoft LLC

Especializado en desarrollo de software para Windows, consultoría técnica e investigación de fallos, sobre todo en proyectos con sistemas existentes y errores difíciles de reproducir.