MDT: cómo usar CustomSettings.ini para automatizar la implementación

El artículo anterior de nuestra serie Microsoft Deployment Toolkit (MDT) explicó cómo usar Bootstrap.ini, el archivo que controla el acceso a la unidad compartida donde se almacena el repositorio de implementación. Analizamos cómo funciona Bootstrap.ini y cómo se puede modificar aún más para proporcionar un proceso de implementación automatizado mediante la interfaz lite-touch (LTI).

Este artículo tiene como objetivo llevar este trabajo más allá al ampliar las capacidades de MDT para proporcionar escenarios de implementación automatizados mediante el archivo CustomSettings.ini. Este archivo maneja el orden en que el proceso de implementación ejecuta las secuencias de comandos, pero también proporciona una forma de brindar respuestas a los eventos de las secuencias de comandos para una verdadera implementación de manos libres.

Echemos un vistazo rápido a los requisitos primero:

• Servidor que ejecuta Windows Server 2008 (o posterior)
• Instalar y configurar los Servicios de implementación de Windows en el servidor
• Instalar y configurar Microsoft Deployment Toolkit en el servidor
• Acceso administrativo al servidor
• Editor de texto para editar archivos de configuración
• Diagrama de red (Esto es opcional, pero muy útil cuando se utilizan varios sitios o se equilibra la carga entre varios servidores).

Similar a Bootstrap.ini, este archivo se puede dividir en tres secciones: Configuración, Personalizado y Predeterminado.

Consulte: Cómo configurar Microsoft Deployment Toolkit: paso a paso

configurar

En la sección Configuración, el encabezado Prioridad afectará el orden en que se procesan las secciones posteriores y las líneas contenidas en ellas cuando 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. Podemos aprovechar esto para aumentar la productividad sin tener que actualizar a Systems Center Configuration Manager (SCCM) para realizar muchas de las mismas tareas.


[Settings]
Priority=Init,DefaultGateway,ClientType,Model,Default
Properties=MyCustomProperty;BIOSVersion;SMBIOSBIOSVersion;ProductVersion,ComputerSerialNumber

Al igual que el archivo Bootstrap.ini, CustomSettings.ini (CS) se puede editar para incluir información que desee tener en cuenta antes de iniciar el proceso de implementación, como datos que existirán como variables a las que se puede llamar según sea necesario. Esto es útil cuando se trabaja con varios sitios o se desea aplicar ciertas configuraciones al escritorio, mientras que el dispositivo móvil recibe un conjunto diferente de configuraciones.

Si observa el fragmento de código anterior, verá que hay un encabezado adicional debajo de Prioridad titulado Propiedades. La prioridad incluirá las secciones presentes en el archivo CS y el orden en que deben ser leídas por MDT. Los atributos hacen referencia a las variables utilizadas en los archivos CS, por lo que MDT reconocerá estas variables a medida que se utilicen durante el proceso de implementación.

Cuando utilice variables y modifique los encabezados de prioridad, debe realizar las debidas diligencias y probar cada componente del archivo CS antes de pasar a producción. Lo último que debe tener en cuenta es que la información en el archivo CS se procesa por orden de llegada. Si dos o más entradas chocan, se escribirá la primera entrada detectada y las demás se descartarán.

VER: Windows 10 Spotlight: preparar, reparar y recuperar (Tech Pro Research)

disfraz

Las entradas personalizadas en los archivos CS no necesitan ejecutarse en el nivel de automatización. Sin embargo, según las necesidades de su entorno, podría ser una buena idea implementar algunas entradas personalizadas para simplificar la administración de la configuración de MDT.

Una de las secciones comunes enumeradas es [Init], abreviatura de inicialización o inicialización. Las entradas en esta sección generalmente se colocan como primera prioridad y contienen datos que deben existir al comienzo del proceso de implementación, incluso antes de que se ejecute el primer script de implementación.


[Init]
ComputerSerialNumber=#Right("%SerialNumber%",7)#
MDTOU=OU=New,OU=Computers
OUPath=OU=Sites,DC=THEMACJESUS,DC=COM

Los motivos de tales secciones varían, pero un uso común es determinar el número de serie de una computadora. Por ejemplo, considere el esquema de nomenclatura de la computadora que se usa en los archivos CS. Requiere que la variable LocationName (que coincida con DefaultGateway) se ingrese como los primeros tres caracteres del nombre, seguidos de «-» y el número de serie de la computadora. En computadoras con números de serie de menos de 11 caracteres, esto no es un problema. Sin embargo, para las computadoras con números de serie de más de 11 caracteres, el nombre de la computadora generado en MDT se truncará y es posible que no coincida con el nombre reservado en Active Directory (AD). Esto puede ser y será problemático cuando la secuencia de comandos ejecuta el comando de unión al dominio y falla porque no puede encontrar una coincidencia en AD, lo que hace que el proceso de implementación falle por completo.


[DefaultGateway]
192.168.1.1=NYC
192.168.2.1=LAX

[NYC]
Nombre de la ubicación = Nueva York
MachineObjectOU=OU=%MDTOU%,OU=%LocationName%,OU=%OUPath%

[LA]
Nombre de la ubicación = Los Ángeles
MachineObjectOU=OU=%MDTOU%,OU=%LocationName%,OU=%OUPath%

En la puerta de enlace predeterminada anterior, 192.168.2.1 pertenece a LAX, que es una abreviatura que lo vincula a la parte del mismo nombre que contiene la variable adicional LocationName=Los Ángeles y proporciona la ruta a la unidad organizativa para crear una nueva en AD Computer. Objetos Sucursal Los Ángeles.

Puede incluir otras entradas principales, como especificar KeyboardLocalePE=, que establece el idioma para el diseño de teclado predeterminado, ideal si administra ubicaciones en otros países que requieren un diseño de idioma diferente al de otros sitios.

El siguiente es [ClientType] Algunos, esto es opcional, pero descubrí que cuando se administran varios tipos de dispositivos, como computadoras de escritorio, portátiles y servidores, la implementación es bastante fluida.


[ClientType]
SubSection=Server-%IsServer%

[Server-True]
Secuencia de tareas ID=WIN2012_X64

[Server-False]
Secciones=Escritorio-%IsDesktop%

[Desktop-True]
Secuencia de tareas ID=WIN10_X64

[Desktop-False]
Secciones=Laptop-%IsLaptop%

[Surface Pro 3]
DriverGroup001=Windows 10\x64\%modelo%
DriverSelectionProfile=Ninguno
Tipo de implementación = NUEVA COMPUTADORA

Al vincular estas entradas, el archivo CS le dice a la secuencia de comandos WMI que primero verifique el tipo de hardware del dispositivo del que se está creando la imagen. Si devuelve el valor de IsDesktop, escribirá la variable TaskSequenceID=WIN10_X64 en el script porque la computadora de escritorio está correctamente identificada e instalará Windows 10 de 64 bits como sistema operativo en ese dispositivo. Si se detecta otro valor, como IsServer, durante la verificación del hardware, la variable asignada cambiará dinámicamente para asignar TaskSequenceID=WIN2012_X64, lo que a su vez indicará al script que instale Windows Server 2012, edición de 64 bits, como el sistema operativo especificado para el hardware del servidor.

El título también se puede modificar al nombre del producto del dispositivo asociado. Esto le dará a la secuencia de comandos una coincidencia más precisa para asignar una o más variables según el nombre del producto interno, en lugar de soñar con qué tipo de ID de hardware tiene.

notas: Una de las formas más fáciles de determinar el nombre del producto en su computadora es iniciar una línea de comando, escribir el siguiente comando y presionar Enter:

wmic get product name

defecto

La tercera y última sección, posiblemente la más importante, es la sección predeterminada. Por lo general, se considera el más importante porque, de forma predeterminada, todas las entradas maestras se colocan aquí y se aplican a todas las sesiones de implementación en todos los dispositivos. Este concepto parece funcionar perfectamente si todos sus sitios tienen la misma marca/modelo de dispositivos que ejecutan la misma versión de Windows y la misma configuración, pero este rara vez es el caso en el mundo real.

Esta es la razón por la que la sección predeterminada a menudo se considera «todo incluido», ya que aplicará la configuración y las variables que permanecen estáticas para todos los dispositivos y servirá como fuente principal de configuración para guiar los scripts de MDT durante todo el proceso de implementación.


[Default]
_SMSTSORGNAME=MAC|JESUS: %OSDComputername%
OSInstall=Y
DoNotCreateExtraPartition=YES
TimeZoneName=Eastern Standard Time
AdminPassword=password
OSDComputername=%DefaultGateway%-%SerialNumber%

Algunas entradas (por ejemplo, TimeZoneName=) se pueden colocar aquí si todos los dispositivos están en la misma zona horaria. Esta configuración, junto con otras como OSInstall=Y y _SMSTORGNAME=, permite que MDT instale el sistema operativo (una función central del proceso de implementación) y proporcione encabezados como el nombre de la empresa durante el proceso de implementación. También puede usar una variable como %OSDComputerName%, que llenará dinámicamente el campo con el nombre de la computadora de la que se está creando una imagen para que pueda determinar de un vistazo qué computadora es.


;JoinWorkgroup=WORKGROUP
JoinDomain=THEMACJESUS.COM
DomainAdmin=administrator
DomainAdminDomain=THEMACJESUS.COM
DomainAdminPassword=password
MachineObjectOU=OU=Unknown Computers,OU=%OUPath%
DomainErrorRecovery=AUTO
Administrators001=THEMACJESUS\user

En la imagen de arriba, las entradas aquí todavía forman parte de la sección predeterminada, como un ejemplo más de la configuración que se puede modificar para realizar una función como un grupo de trabajo o unirse a un dominio usando la entrada JoinWorkgroup= o JoinDomain= y especificando el nombre El grupo de trabajo o dominio al que desea unirse. Para automatizar aún más el proceso, se deben agregar las entradas DomainAdmin=, DomainAdminDomain= y DomainAdminPassword= para incluir el nombre de la cuenta con privilegios de dominio, la contraseña de la cuenta y el nombre de dominio al que pertenece la cuenta.

notas: Recuerde que todas las entradas contenidas en el archivo CS se enumeran en texto sin formato.La mejor práctica es dejar esta configuración en blanco (esto obligará a MDT a solicitar credenciales antes de iniciar el proceso de implementación) o crear una Unir una computadora a un dominio delegando solo los permisos necesarios Realice esta única tarea administrativa. De esta forma, es bastante fácil restablecer la contraseña y mitigar la amenaza si la cuenta se ve comprometida.

también es una buena idea Restablecer las cuotas de equipo predeterminadas impuestas por Microsoft (MS) Una el objeto de la computadora al dominio usando una cuenta estándar con privilegios elevados porque MS lo ha configurado para 10 dispositivos. Después de eso, se bloqueará la cuenta para que no pueda unir más dispositivos al dominio. Si tiene una red grande, puede ampliar fácilmente esta limitación o eliminarla por completo con algunas modificaciones en las interfaces de servicio de Active Directory (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

Arriba se muestran las claves para la configuración que suprimirán la aparición de los paneles del asistente y responderán las preguntas que hacen al mismo tiempo para automatizar realmente la mayor parte del proceso de creación de scripts de MDT.


DeploymentType=NEWCOMPUTER
SkipCapture=YES

FinishAction=Reiniciar

servicio de eventos=http://192.168.1.1:9800
SLShareDynamicLogging=\\1192.168.1.1\DeploymentShare$\Logs\%COMPUTERNAME%
cáscara oculta = sí

Permítanme comenzar diciendo que las últimas configuraciones son opcionales, pero realmente se recomienda incluirlas en su archivo CS. Manejan configuraciones de seguridad como FinishAction=Reboot y HideShell=Yes al afirmar que al final de la implementación, se debe ejecutar el comando de reinicio para realizar el primer arranque en la máquina recién instalada. Además, el shell de Explorer debe ocultarse durante el primer arranque porque el sistema inicia sesión automáticamente como administrador local; de lo contrario, estará expuesto a cualquier persona cuando se complete el proceso posterior a la implementación.

La configuración EventService= habilitará el registro del sistema para el servidor y compartirá las rutas que ingrese aquí, lo que puede ayudar a resolver algunas fallas o problemas que impiden que MDT funcione correctamente.

Finalmente, casi cientos de configuraciones están disponibles en MDT a través de todo el archivo CustomSettings.ini. Algunos tienen bifurcaciones que permiten múltiples respuestas, mientras que otros son simples entradas de sí o no. Por desgracia, hay demasiado para cubrir aquí. Sin embargo, Microsoft ha proporcionado documentación a través de TechNet ¿Le gustaría obtener más información sobre algunas configuraciones y cómo conectarlas con otras para servir mejor a su entorno?

Ver también…

su opinión

¿Ha utilizado el archivo CustomSettings.ini para automatizar el proceso de implementación? Comparta sus consejos y experiencias con otros miembros de Tecnopedia.