Automatización total: Despliegues sin esfuerzo con CustomSettings.ini de MDT

El artículo anterior en nuestra serie sobre Microsoft Deployment Toolkit (MDT) explicaba cómo utilizar el archivo Bootstrap.ini, el cual controla el acceso a la unidad compartida que almacena el repositorio de implementación. Vimos cómo funciona Bootstrap.ini y cómo se puede modificar para permitir un proceso de implementación automatizado utilizando la interfaz de "lite-touch" (LTI).

Este artículo tiene como objetivo ampliar esa funcionalidad extendiendo las capacidades de MDT para ofrecer un escenario de implementación automatizada utilizando el archivo CustomSettings.ini. Este archivo maneja el orden en el que se ejecutarán los scripts durante el proceso de implementación, pero también proporciona una forma de proporcionar respuestas a eventos de script para lograr una implementación verdaderamente sin intervención.

Requisitos:

• Servidor con Windows Server 2008 (o posterior)
• Windows Deployment Services instalado y configurado en el servidor
• Microsoft Deployment Toolkit instalado y configurado en el servidor
• Acceso administrativo al servidor
• Editor de texto para editar archivos de configuración
• Diagrama(s) de red (esto es opcional, pero ayuda mucho cuando se trabaja con múltiples sitios o se equilibra la carga entre varios servidores)

Similar a Bootstrap.ini, el archivo CustomSettings.ini puede descomponerse en tres secciones: Settings, Custom y Default.

Settings

Bajo la sección de Settings, el encabezado de Priority afecta el orden en el que se procesan las secciones y las líneas que contiene a medida que se ejecutan los scripts durante la fase de implementación. Al reorganizar estas entradas, podemos controlar la ejecución de la fase de implementación y aprovechar al máximo la productividad sin necesidad de actualizar a Systems Center Configuration Manager (SCCM) para lograr muchas de las mismas tareas.


[Settings]
Priority=Init,DefaultGateway,ClientType,Model,Default
Properties=MiPropiedadPersonalizada;VersionBIOS;VersionSMBIOSBIOS;NumeroDeSerieComputadora


Los beneficios de usar un monitor ultrawide en Windows 10

Al igual que el archivo Bootstrap.ini, CustomSettings.ini (CS) se puede editar para incluir información que se desea tener en cuenta antes de iniciar el proceso de implementación, como datos que existirán como variables que se pueden llamar según sea necesario. Esto es extremadamente útil cuando se trabaja con múltiples sitios o cuando se desea que se apliquen ciertas configuraciones a equipos de escritorio, mientras que los dispositivos móviles reciben un conjunto de configuraciones diferente.

Si observa el fragmento de código anterior, verá que hay un encabezado adicional bajo Priority, titulado Properties. Priority incluirá las secciones que están presentes en el archivo CS y el orden en el que deben ser leídas por MDT. Properties se refiere a las variables que se utilizan en el archivo CS y, como tal, MDT reconocerá estas variables cuando se utilicen durante todo el proceso de implementación.

Cuando se trabaja con variables y se modifican los encabezados de prioridad, es imperativo ser minucioso y probar cada componente del archivo CS antes de ponerlo en producción. Un último punto a tener en cuenta es que la información en el archivo CS se procesa en orden de llegada. Si dos o más entradas entran en conflicto, se escribirá la primera detectada y las demás se descartarán.

Custom

Las entradas personalizadas en el archivo CS no son obligatorias para que funcione a nivel automatizado. Sin embargo, dependiendo de las necesidades de su entorno, puede ser una buena idea implementar algunas entradas personalizadas para simplificar la administración de las configuraciones de MDT.

Una de las secciones comunes listadas es [Init], que significa inicialización. Las entradas en esta sección se suelen colocar como primera prioridad y contienen datos que deben estar presentes al inicio del proceso de implementación, antes de que se ejecute el primer script de implementación.


[Init]
NumeroDeSerieComputadora=#Right("%NumeroDeSerie%",7)#
MDTOU=OU=Nueva,OU=Computadoras
OUPath=OU=Sitios,DC=THEMACJESUS,DC=COM


Cómo crear un instalador USB con VMware ESXi desde tu equipo Windows

Las razones para este tipo de sección varían, pero un uso común es determinar el número de serie de la computadora. Por ejemplo, considere el esquema de nomenclatura de la computadora utilizado en el archivo CS. Requiere que la variable LocationName (que se corresponde con DefaultGateway) se ingrese como los tres primeros caracteres del nombre, seguidos de un guion y el número de serie de la computadora. En una computadora con menos de 11 caracteres para un número de serie, esto no es un problema. Pero para una que tenga un número de serie con más de 11 caracteres, el nombre de la computadora generado en MDT se truncará y probablemente no coincidirá con lo que se ha preestablecido en Active Directory (AD). Esto puede causar problemas más adelante cuando el script ejecute el comando de unión al dominio y falle porque no puede encontrar una coincidencia en AD, lo que resultará en un fallo total del proceso de implementación.


[DefaultGateway]
192.168.1.1=Nueva York
192.168.2.1=LAX


[Nueva York]
LocationName=New York
MachineObjectOU=OU=%MDTOU%,OU=%LocationName%,OU=%OUPath%

[LAX]
LocationName=Los Angeles
MachineObjectOU=OU=%MDTOU%,OU=%LocationName%,OU=%OUPath%

En la sección de la puerta de enlace predeterminada de arriba, 192.168.2.1 se refiere a LAX, una abreviatura que lo vincula a la sección del mismo nombre que contiene la variable adicional de LocationName=Los Angeles y proporciona la ruta a la OU para crear nuevos objetos de computadora en AD para la sucursal de Los Angeles.

También se pueden incluir otras entradas, como especificar el KeyboardLocalePE=, que establece el idioma del diseño de teclado predeterminado, ideal si se administran ubicaciones en otros países que requieren un diseño de idioma diferente a otros sitios.

Cómo instalar VMware ESXi en hardware bare-metal para alojar máquinas virtuales

A continuación está la sección [ClientType], que es opcional, pero que, en mi opinión, hace que las implementaciones funcionen de manera más eficiente al administrar diferentes tipos de equipos, como escritorios, portátiles y servidores.


[ClientType]
SubSection=Servidor-%EsServidor%


[Servidor-True]
TaskSequenceID=WIN2012_X64

[Servidor-Falso]
SubSección=Escritorio-%EsEscritorio%

[Escritorio-Verdadero]
TaskSequenceID=WIN10_X64

[Escritorio-Falso]
SubSección=Portátil-%EsPortátil%

Cómo la colaboración en investigación de IA está impulsando el avance del mercado empresarial

[Surface Pro 3]
DriverGroup001=Windows 10\x64\%Modelo%
DriverSelectionProfile=nada
DeploymentType=NUEVACOMPUTADORA

Al encadenar estas entradas, el archivo CS le está indicando al script de WMI que primero verifique el tipo de hardware del dispositivo que se va a imaginar. Si devuelve un valor de EsEscritorio, escribirá la variable TaskSequenceID=WIN10_X64 en el script, ya que el equipo de escritorio se ha identificado correctamente, e instalará Windows 10 - 64 bits como el sistema operativo en ese dispositivo. Si se detecta otro valor durante la verificación de hardware, por ejemplo, EsServidor, la variable asignada cambiará dinámicamente para asignar TaskSequenceID=WIN2012_X64, lo que a su vez instruirá al script a instalar Windows Server 2012 - edición de 64 bits como el sistema operativo designado para hardware de servidor.

El encabezado también se puede modificar para el nombre del producto del dispositivo en cuestión. Esto proporcionará una coincidencia más precisa para que el script asigne una o más variables basadas en el nombre interno del producto en lugar de suponer qué tipo de ID de hardware tiene.

Nota: Una de las formas más sencillas de determinar el nombre del producto en una computadora es abrir la línea de comandos, escribir el siguiente comando y luego presionar Enter:

wmic get product name

Default

La tercera y última sección, y posiblemente la más importante, es la sección Default. A menudo se considera la más importante porque, de forma predeterminada, todas las entradas se colocan aquí y se aplican a todas las sesiones de implementación para todos los dispositivos. Si bien este concepto funcionaría perfectamente si los sitios tuvieran el mismo fabricante/modelo de equipos que ejecutan la misma versión de Windows y configuraciones idénticas, esto rara vez ocurre en el mundo real.

Cómo bloquear y asegurar los ajustes individuales en Windows 10

Es por eso que la sección predeterminada se considera a menudo el "comodín", ya que aplicará las configuraciones y variables que permanecerán estáticas para todos los dispositivos, así como servirá como la fuente principal de configuraciones que dirigirán los scripts de MDT durante todo el proceso de implementación.


[Default]
_SMSTSORGNAME=MAC|JESUS: %OSDComputername%
OSInstall=Y
DoNotCreateExtraPartition=YES
TimeZoneName=Hora estándar del Este
AdminPassword=contraseña
OSDComputername=%DefaultGateway%-%SerialNumber%


Ciertas entradas, como TimeZoneName=, se pueden colocar aquí si los dispositivos residen todos dentro del mismo huso horario. Esta configuración, entre otras, como OSInstall=Y y _SMSTSORGNAME=, permite a MDT instalar sistemas operativos (una función principal del proceso de implementación) y proporcionar un título durante el proceso de implementación, como el nombre de una empresa. También se puede utilizar una variable, como %OSDComputerName%, que completará dinámicamente ese campo con el nombre de la computadora a medida que se está imagenando, para poder determinar de un vistazo qué computadora es.


;JoinWorkgroup=GRUPODETRABAJO
JoinDomain=THEMACJESUS.COM
DomainAdmin=administrator
DomainAdminDomain=THEMACJESUS.COM
DomainAdminPassword=contraseña
MachineObjectOU=OU=ComputadorasDesconocidas,OU=%OUPath%
DomainErrorRecovery=AUTO
Administradores001=THEMACJESUS\usuario


En el fragmento de código anterior, las entradas todavía pertenecen a la sección predeterminada y también se muestran ejemplos adicionales de configuraciones que se pueden modificar para realizar funciones como la incorporación a un grupo de trabajo o dominio mediante la entrada JoinWorkgroup= o JoinDomain= y especificando el nombre del grupo de trabajo o dominio al que desea unirse. Para automatizar aún más el proceso, deben agregarse las entradas DomainAdmin=, DomainAdminDomain= y DomainAdminPassword= para incluir el nombre de la cuenta con derechos de dominio, la contraseña de esta cuenta y el nombre del dominio al que pertenece la cuenta.

Nota: Es importante tener en cuenta que todas las entradas incluidas en el archivo CS se muestran en texto sin formato. Las mejores prácticas serían dejar estas configuraciones en blanco (lo que obligaría a MDT a solicitar las credenciales antes de comenzar el proceso de implementación) o crear una cuenta en AD que solo sirva para unir computadoras al dominio, delegando solo los derechos necesarios para realizar esta tarea administrativa. De esta manera, si la cuenta se ve comprometida, es bastante fácil restablecer la contraseña y mitigar la amenaza.

Microsoft aumenta el número mínimo de versiones de documentos en OneDrive y SharePoint

También es una buena idea restablecer la cuota de máquina predeterminada impuesta por Microsoft (MS) para unir objetos de computadora al dominio utilizando cuentas estándar con privilegios elevados, ya que MS lo ha establecido en 10 dispositivos. Después de eso, la cuenta ya no puede unir más dispositivos al dominio. Extender este límite o eliminarlo por completo si se tiene una red grande es fácil de hacer mediante una edición mínima de las Interfaces de servicios de directorio activo (ADSI).


SkipAdminPassword=YES
SkipApplications=YES
SkipBDDWelcome=YES
SkipBitLocker=YES
SkipComputerBackup=YES
SkipComputerName=YES
SkipDeploymentType=YES
SkipDomainMembership=YES
SkipUserData=YES
SkipFinalSummary=YES
SkipLocaleSelection=YES
SkipPackageDisplay=YES
SkipProductKey=YES
SkipRoles=YES
SkipSummary=YES
SkipTaskSequence=YES
SkipTimeZone=YES


Lo mostrado arriba es la esencia de las configuraciones que deshabilitarán los paneles del asistente para hacer preguntas y responderlas al mismo tiempo para automatizar verdaderamente la mayor parte del proceso de secuencias de comandos de MDT.


DeploymentType=NUEVACOMPUTADORA
SkipCapture=YES


FinishAction=REBOOT

EventService=http://192.168.1.1:9800
SLShareDynamicLogging=\\1192.168.1.1\DeploymentShare$\Logs\%COMPUTERNAME%
HideShell=YES

Cómo habilitar y descargar la aplicación Whiteboard de Microsoft Store en Windows 10

Permítanme empezar diciendo que estas últimas configuraciones son opcionales, pero son muy recomendables para incluir en su archivo CS. Manejan configuraciones de seguridad, como FinishAction=Reboot y HideShell=Yes, asegurando que al final de la implementación, se ejecute el comando de reinicio para realizar el primer arranque en la máquina recién instalada. Además, ocultan el shell de explorador durante este primer arranque, ya que el sistema se inicia automáticamente como administrador local y, de lo contrario, quedaría expuesto para que cualquier persona lo use mientras completa los procesos posteriores a la implementación.

La configuración EventService= permitirá el registro del sistema en el servidor y la ruta compartida que se ingrese aquí, lo que puede ser útil para solucionar problemas de fallos o problemas que hacen que MDT no se ejecute correctamente.

Por último, hay casi cientos de configuraciones que se pueden utilizar en MDT a través de todo el archivo CustomSettings.ini. Algunas tienen bifurcaciones que permiten varias respuestas, mientras que otras son simples entradas de sí o no. Sin embargo, Microsoft ha proporcionado la documentación a través de TechNet si desea obtener más información sobre ciertas configuraciones y cómo se pueden vincular a otras para mejorar su entorno.

También te puede interesar...

• Cómo configurar Microsoft Deployment Toolkit (Newsmatic)
• Cómo automatizar la preparación previa de cuentas en WDS con PowerShell (Newsmatic)
• Cómo integrar DaRT en Microsoft Deployment Toolkit y Windows Deployment Services (Newsmatic)
• Cómo implementar Windows utilizando MDT y WDS (Newsmatic)
• Cómo implementar aplicaciones con Microsoft Deployment Toolkit (Newsmatic)

Tus pensamientos

¿Has utilizado el archivo CustomSettings.ini para automatizar el proceso de implementación? Comparte tus consejos y experiencias con otros miembros de Newsmatic.

Cómo bloquear aplicaciones de Microsoft Store en Windows 10

En Newsmatic nos especializamos en tecnología de vanguardia, contamos con los artículos mas novedosos sobre Microsoft, allí encontraras muchos artículos similares a Automatización total: Despliegues sin esfuerzo con CustomSettings.ini de MDT , tenemos lo ultimo en tecnología 2023.