Hola a todos,
En repetidas ocasiones, hemos tenido casos en los que se nos pregunta cómo administrar aquellos atributos de una cuenta del DA que no son accesibles desde la consola Active Directory Users and Computers. Lo que veremos a continuación es cómo, a través de un script .vbs, nos ayudaremos de los menús contextuales de la consola para acceder a un atributo determinado y darle el valor que nosotros deseemos.
Lo expuesto a continuación no agregará ningún campo adicional en ninguna de las pestañas del cuadro Propiedades de la cuenta seleccionada.
A modo ilustrativo, tomaremos como ejemplo el atributo EmployeeID (ya existente en el esquema del DA).
En primer lugar, necesitaremos el siguiente script:
eid.vbs
Dim oVar
Dim oUsr
Dim tmp
Set oVar = Wscript.Arguments
Set oUsr = GetObject(oVar(0))
tmp = InputBox("The Employee ID of the user is: " & oUsr.employeeID &vbCRLF & vbCRLF & "If you would like enter a new
number or modify the existing number, enter the new number in the textbox below")
if tmp <> "" then oUsr.Put "employeeID",tmp
oUsr.SetInfo
Set oUsr = Nothing
WScript.Quit
1. Abrir la consola Active Directory Services Interfaces (ADSI) Edit (adsiedit.msc), desplegar la partición de Configuración CN=Configuration,DC=midominio,DC=local, y navegar hasta CN=C0A, CN=DisplaySpecifiers,CN=Configuration,DC=midominio,DC=local.
Este paso es dependiente del lenguaje de nuestro sistema operativo. Para el caso del Español su código correspondiente es C0A, para el Inglés es 409, etc…
Podéis encontrar una relación de los idiomas con su correspondiente código aquí.
2. En el panel de la derecha, hacer clic derecho sobre CN=user-Display y seleccionar Propiedades.
3. En la lista de atributos, hacer clic sobre adminContextMenu, pulsar el botón Editar y agregar lo siguiente (sin las comillas):
“,&Employee ID..., C:\Ruta\eid.vbs”
Nota: Debemos asegurarnos de tener el script .vbs en la ruta indicada en la máquina desde la que utilizaremos la consola Active Directory Users and Computers.
4. Al abrir la consola Active Directory Users and Computers y al pulsar botón derecho sobre las propiedades de una cuenta de usuario, tendremos disponibles una nueva opción (“Employee ID…”) en el menú contextual desde donde podremos consultar/editar el atributo:
5. Dado que inicialmente no podemos agregar estos dos atributos desde el menú Ver-> Añadir/Eliminar Columnas, para poder realizar listados de las cuentas por EmployeeID, es necesario realizar lo siguiente:
· Abrir consola ADSI Edit
· Localizar y doble clic en organizationalUnit-Display bajo CN=C0A, CN=DisplaySpecifiers,CN=Configuration,DC=midominio,DC=local.
· Modificar el atributo extraColumns y agregar lo siguiente employeeid,Employee ID,1,100,0
Nota: Nótese que lo estamos haciendo a nivel de Unidad Organizativa. Si deseamos disponer de listados a nivel de Contenedor (como por ejemplo Users o Computers), será necesario realizar los mismos pasos para el atributo container-Display.
Una vez realizados estos pasos, ya estará disponible el atributo employeeID en el menú Ver-> Añadir/Eliminar Columnas para poder obtener un listado como este:
- Javier Rama del Castillo
En un porcentaje elevado de los casos de soporte es necesaria la obtención, o el análisis, de un volcado de memoria de la máquina para llegar a conocer quien o quienes pueden ser los responsables de una caída inesperada de la máquina, un bloqueo o una degradación en su rendimiento.
Lo mas conveniente es tener el servidor configurado de forma que, en caso de caída inesperada, se genere un volcado automático y este pueda ser analizado con posterioridad.
Para configurar la máquina habremos de seguir los siguientes pasos:
Cómo seleccionar opciones de volcado de memoria
Se pueden generar tres tipos de archivos de volcado de memoria. Seleccione uno antes de desencadenar el archivo de volcado manualmente. Para ello, siga estos pasos:
1. Haga clic con el botón secundario del ratón en Mi PC y, a continuación, haga clic en Propiedades.
2. En la ficha Opciones avanzadas, haga clic en el botón Configuración de Inicio y recuperación.
3. Haga clic en Escribir información de depuración y, a continuación, seleccione Volcado de memoria completa o la opción que deseemos configurar.
También podemos configurar aquí donde quedará guardado el fichero definitivo.
Hemos de tener en cuenta que se generará un fichero temporal en la unidad de sistema, y durante el inicio de la máquina, tras el volcado, este fichero pasará a la ubicación indicada en esta opción, por lo que deberemos de tenerlo en cuenta a la hora de administrar el espacio en disco.
Por esto es muy importante tener al menos un archivo de paginación con el tamaño de la memoria física en la unidad de sistema, si se encuentra en otra unidad no podrá generar el temporal no obteniendo el volcado.
Estas mismas opciones están en el registro, en la clave HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl
Con los valores:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\CrashControl CrashDumpEnabled REG_DWORD 0x0 = None CrashDumpEnabled REG_DWORD 0x1 = Complete memory dump CrashDumpEnabled REG_DWORD 0x2 = Kernel memory dump CrashDumpEnabled REG_DWORD 0x3 = Small memory dump (64KB)
Algunos valores adicionales CrashControl:
0x0 = Disabled 0x1 = Enabled AutoReboot REG_DWORD 0x1 DumpFile REG_EXPAND_SZ %SystemRoot%\Memory.dmp LogEvent REG_DWORD 0x1 MinidumpDir REG_EXPAND_SZ %SystemRoot%\Minidump Overwrite REG_DWORD 0x1 SendAlert REG_DWORD 0x1
Se necesita un reinicio para habilitar las opciones configuradas con antelación.
Obtenido de:
307973 How to configure system failure and recovery options in Windows
http://support.microsoft.com/default.aspx?scid=kb;EN-US;307973
254649 Overview of memory dump file options for Windows Server 2003, Windows XP, and Windows 2000
http://support.microsoft.com/default.aspx?scid=kb;EN-US;254649
274598 Complete memory dumps are not available on computers that have 2 or more gigabytes of RAM
http://support.microsoft.com/default.aspx?scid=kb;EN-US;274598
En los casos en que se queda la máquina bloqueada se puede generar un volcado mediante el teclado que nos permita analizar que estaba haciendo en el momento de cuelgue y cuál puede ser el causante.
También se puede emplear para comprobar si el volcado se realiza correctamente en caso de no estar seguros que este correctamente configurado, la forma de configurarlo está reflejado en el artículo siguiente.
Habilitar el Scroll Lock dump –
Para lanzar el volcado de memoria se deberá pulsar la siguiente combinación de teclas:
CTRL+SCROLL LOCK+SCROLL LOCK
Esta opción se habilita en un equipo que utiliza un teclado PS/2, siguiendo estos pasos:
1.Inicie el Editor del Registro.
2.Busque la siguiente sub clave del Registro:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\i8042prt\Parameters
3.En el menú Edición, haga clic en Agregar valor y agregue la entrada siguiente del Registro:
Nombre: CrashOnCtrlScroll Tipo de datos: REG_DWORD Valor: 1
4.Cierre el Editor del Registro y reinicie el equipo
Para el caso de teclado USB se precisa una versión especial del driver Kbdhid.sys, el cual solo está desarrollado para sistemas servidor y disponible como hotfix.
En el momento que se pulse la combinación aparecerá nuestra querida pantalla azul con el siguiente mensaje:
*** STOP: 0x000000E2 (0x00000000,0x00000000,0x00000000,0x00000000) The end-user manually generated the crashdump.
Habrá que esperar a que el contador llegue a cien y se reinicie la maquina (en caso de estar seleccionado el reinicio en las opciones del volcado) para que se genere el volcado complete de memoria al disco.
244139 Windows feature lets you generate a memory dump file by using the keyboard
http://support.microsoft.com/default.aspx?scid=kb;EN-US;244139
Cuando no se genera el volcado a pesar de estar la máquina correctamente configurada es muy importante revisar que no tenga configurado o habilitado opciones como Automatic System Restart (ASR) de Compact o elementos similares de otros proveedores, estos se suelen administrar desde las opciones de la BIOS de la máquina.
También se tiene que cumplir la siguiente condición en cuanto a la configuración del disco y el archivo de paginación:
Si se selecciona la opción volcado de memoria completa, se debe tener en el volumen de arranque del sistema un archivo de paginación que sea suficiente para contener toda la memoria física RAM mas 1MB (megabyte). Por defecto el volcado de memoria completa se escribe en el fichero %SystemRoot%\Memory.dmp.
Esto es debido a que en la partición del sistema se aloja el fichero temporal donde se vuelca la memoria hasta el inicio de la máquina y copiado a la unidad seleccionada en las propiedades de la máquina.
Se pueden realizar las mismas opciones para las máquinas virtuales, en este articulo se especifica cómo hacerlo para Virtual Server 2005.
928839 How to use the keyboard to generate a memory dump file on a Virtual Server 2005 guest computer
http://support.microsoft.com/default.aspx?scid=kb;EN-US;928839
Toda esta información aplica a las versiones de W2000, Windows 2003 y Windows 2008 Server.
Espero que esta información facilite la obtención de datos para poder solucionar situaciones que, en algunos casos, resultan críticas para una empresa.
Raúl del Moral Guirado
Técnico de Soporte Premier
Hola de nuevo,
Hoy veremos dónde se almacena la información correspondiente a las zonas integradas en Directorio Activo.
Para ello, antes tenemos que recordar que en Windows Server 2003 se introdujeron las nuevas Particiones de Aplicación. Las dos particiones de aplicación que se crean por defecto para DNS son ForestDNSZones y DomainDNSZones. También es posible crear nuevas particiones de aplicación mediante las herramientas ntdsutil y dnscmd.
Cuando se crea/configura una zona DNS integrada en DA en Windows Server 2003 y Windows Server 2008, por defecto hay tres opciones disponibles para el ámbito de replicación:
1. To all DNS servers in the Active Directory forest midominio.local
Si seleccionamos esta opción, la información de la zona midominio.local se almacena en la partición de aplicación ForestDNSZones bajo el contenedor MicrosoftDNS:
CN=MicrosoftDNS,DC=ForestDNSZones,DC=domain,DC=local
Esta información va a ser replicada por todos los servidores DNS (que también sean DCs) del bosque.
2. To all DNS servers in the Active Directory domain midominio.local
Si optamos por esta segunda opción, la información de la zona midominio.local se almacenará en la partición de aplicación DomainDNSZones bajo el contenedor MicrosoftDNS:
CN=MicrosoftDNS,DC=DomainDNSZones,DC=domain,DC=local
Esta información va a ser replicada por todos los servidores DNS (que también sean DCs) del dominio.
3. To all domain controllers in the Active Directory domain midominio.local
La tercera opción corresponde a la forma clásica (Windows 2000) de almacenar las zonas DNS en Directorio Activo. Concretamente, la información de la zona midominio.local se almacenará en esta ocasión en la propia partición del dominio, bajo el contenedor MicrosoftDNS dentro de System:
CN=MicrosoftDNS,CN=System,DC=domain,DC=local
Esta información va a ser replicada por todos los Controladores de Dominio (DCs) del dominio así como por todos los DCs que sean Catálogos Globales (GCs) en el bosque.
Existe una cuarta opción disponible una vez se han creado nuevas particiones de aplicación: To all domain controllers specified in the scope of the following application directory partition. De esta manera, podremos seleccionar qué DCs específicos replican dicha partición y que sean ellos, por tanto, los que sirvan la zona DNS en la que se ha especificado que el ámbito de replicación corresponda a dicha partición.
Recomendaciones generales
Las recomendaciones generales (siempre habría que tener en cuenta las peculiaridades del entorno particular) en cuanto al almacenamiento de zonas en Directorio Activo son las siguientes:
· Si algún servidor DNS es Windows 2000 Server, habría que configurarlas para que replicaran a todos los DCs del dominio, por lo que la zona se almacenaría en la partición de dominio. De esta manera, los servidores DNS Windows 2000 Server podrían almacenar, cargar y servir dicha zona.
· Si todos los servidores DNS son Windows Server 2003, se recomienda que las zonas se almacenen en las nuevas particiones de aplicación que presenta Windows Server 2003:
o Las zonas que deban estar en todos los servidores DNS del dominio se almacenarán en la partición de aplicación DomainDNSZones
§ Para las nuevas zonas DNS creadas a partir de Windows Server 2003, esta es la configuración por defecto
§ Se recomienda configurar las zonas correspondientes a cada dominio con este tipo de replicación, de tal manera que todos los DNS de dicho dominio tengan la zona y no se replique a los GC del bosque, evitando así replicación y almacenamiento innecesarios.
§ Con esta configuración también se logra separar la información propia de AD (usuarios, equipos, grupos, etc.) de los datos de las zonas DNS
o Las zonas que deban estar en todos los servidores DNS del bosque se almacenarán en la partición de aplicación ForestDNSZones
§ Se recomienda configurar de este modo la zona _msdcs.midominio.local para que puedan cargarla todos los servidores DNS del bosque
Los datos de una zona almacenada en una partición de aplicación de DA no se replican a los GC del bosque, mientras que los datos almacenados en la partición del propio dominio sí se replican a los GC. Al utilizar particiones de aplicación, por tanto, se reduce el tráfico generado en la red así como la cantidad de datos replicados, ya que sólo los DCs que sean servidores DNS van a llevar a cabo la replicación de dichas particiones, dependiendo además del dominio/bosque al que pertenezcan.
Se puede encontrar más información sobre la configuración de la replicación de las zonas DNS y las recomendaciones generales en los siguientes enlaces:
· DNS zone replication in Active Directory
· Use DNS Application Directory Partitions
- Paula Tomás Galed
Soy Paula, del equipo de Directorio Activo. Recientemente tuvimos un caso en el que un usuario deshabilitado podía realizar una conexión a LDP y no recibía ningún error (aunque posteriormente no podía navegar por el árbol de la partición del dominio).
A la hora de realizar el BIND mediante la herramienta LDP.EXE, el mensaje recibido era el siguiente (indicando aparentemente que se había realizado la autenticación con las credenciales del usuario deshabilitado user1):
res = ldap_bind_s(ld, NULL, &NtAuthIdentity, 1158); // v.3
{NtAuthIdentity: User='user1'; Pwd= <unavailable>; domain = 'haledomain'.}
Authenticated as dn:'user1'.
Si obtenemos unas trazas de red de dicha conexión, se muestra un BIND exitoso:
Hora
Origen
Destino
Prot
Detalles
12:59:07.370
192.168.1.1
192.168.1.2
LDAP
LDAP:Search Request, MessageID: 32, BaseObject: NULL, SearchScope: base Object, SearchAlias: neverDerefAliases
12:59:07.380
LDAP:Search Result Entry, MessageID: 32
12:59:14.269
LDAP:Search Request, MessageID: 33, BaseObject: NULL, SearchScope: base Object, SearchAlias: neverDerefAliases
12:59:14.280
LDAP:Search Result Entry, MessageID: 33
12:59:14.770
LDAP:Bind Request, MessageID: 35, Version: 3
12:59:14.780
LDAP:Bind Response, MessageID: 35, Status: Sasl Bind In Progress
12:59:14.790
LDAP:Bind Request, MessageID: 36, Version: 3
12:59:14.981
LDAP:Bind Response, MessageID: 36, Status: Success
En condiciones normales, un usuario deshabilitado no puede realizar una conexión LDAP a Directorio Activo ya que se deniega su acceso indicando que sus credenciales son inválidas:
Error <49>: ldap_bind_s() failed: Invalid Credentials.
Server error: 8009030C: LdapErr: DSID-0C09043E, comment: AcceptSecurityContext error, data 0, vece
Este mensaje de red se puede observar también en la respuesta obtenida del DC (servidor LDAP) en las trazas de red:
13:12:04.417
LDAP:Search Request, MessageID: 73, BaseObject: NULL, SearchScope: base Object, SearchAlias: neverDerefAliases
LDAP:Search Result Entry, MessageID: 73
13:12:12.208
LDAP:Bind Request, MessageID: 76, Version: 3
LDAP:Bind Response, MessageID: 76, Status: Sasl Bind In Progress
LDAP:Bind Request, MessageID: 77, Version: 3
13:12:12.278
LDAP:Bind Response, MessageID: 77, Status: Invalid Credentials
Revisando el visor de sucesos de Seguridad del DC de nuestro entorno de pruebas tras realizar el intento de conexión con el usuario deshabilitado user1, observamos la siguiente secuencia de eventos:
Event Type: Failure Audit
Event Source: Security
Event Category: Account Logon
Event ID: 672
Date: 8/14/2008
Time: 1:09:24 PM
User: NT AUTHORITY\SYSTEM
Computer: HALEDC01
Description:
Authentication Ticket Request:
User Name: user1
Supplied Realm Name: haledomain
User ID: -
Service Name: krbtgt/haledomain
Service ID: -
Ticket Options: 0x40810010
Result Code: 0x12
Ticket Encryption Type: -
Pre-Authentication Type: -
Client Address: 127.0.0.1
Certificate Issuer Name:
Certificate Serial Number:
Certificate Thumbprint:
Event Type: Success Audit
Event Category: Logon/Logoff
Event ID: 552
User: HALEDOMAIN\administrator
Logon attempt using explicit credentials:
Logged on user:
User Name: administrator
Domain: HALEDOMAIN
Logon ID: (0x0,0x27F79)
Logon GUID: {94b7a00d-5198-8f5c-d90b-566add369611}
User whose credentials were used:
Target User Name: user1
Target Domain: haledomain
Target Logon GUID: -
Target Server Name: HALEDC01.haledomain.com
Target Server Info: HALEDC01.haledomain.com
Caller Process ID: 3256
Source Network Address: -
Source Port: -
Event ID: 680
Logon attempt by: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
Logon account: user1
Source Workstation: HALEDC01
Error Code: 0xC0000072
Event ID: 531
Logon Failure:
Reason: Account currently disabled
Domain: haledomain
Logon Type: 3
Logon Process: NtLmSsp
Authentication Package: NTLM
Workstation Name: HALEDC01
Caller User Name: -
Caller Domain: -
Caller Logon ID: -
Caller Process ID: -
Transited Services: -
Source Network Address: 192.168.1.1
Source Port: 2768
En cambio, en el visor de sucesos del DC del entorno que aparentemente autenticaba al usuario deshabilitado se podían ver los siguientes eventos:
Time: 1:06:53 PM
User: HALEDOMAIN\Guest
Logon account: Guest
Error Code: 0x0
Los tres primeros eventos son iguales en ambos casos:
· El evento 672 indica que se ha intentado realizar una autenticación por KERBEROS con el usuario user1 y se ha devuelto el error 0x12. Este código de error se traduce al siguiente mensaje que indica que el usuario ha sido “revocado”:
KDC_ERR_CLIENT_REVOKED à Clients credentials have been revoked
· El evento 552 indica que se está intentado realizar una conexión al DC utilizando el usuario user1.
· A continuación se muestra el evento 680 indicando que el intento de autenticación del usuario user1 ha resultado fallido y proporciona el código de error 0xC0000072 correspondiente al siguiente mensaje (cuenta de usuario deshabilitada):
STATUS_ACCOUNT_DISABLED à The referenced account is currently disabled and may not be logged on to.
El evento que aparece a continuación de los anteriores es distinto en ambas situaciones:
· En el primer caso (el usuario no puede realizar la conexión LDAP – comportamiento esperado), se recibe el evento 531 indicando que la cuenta de usuario está actualmente deshabilitada: Account currently disabled
· En el entorno que aparentemente permite la conexión del usuario aparece el mismo intento fallido de autenticación pero se observa que, inmediatamente después, existe un intento exitoso de autenticación del usuario Invitado o Guest (evento 680).
Por lo tanto, en realidad no es el usuario user1 el que se está autenticando en el BIND de la conexión LDAP (aunque sea esa la percepción desde el cliente LDAP), sino que su autenticación es denegada y automáticamente se realiza otra autenticación con el usuario Invitado porque dicho usuario se encontraba HABILITADO en el entorno.
La razón de que el usuario posteriormente no pudiera acceder a los datos de la partición del dominio era precisamente por haber realizado la autenticación con la cuenta Invitado, ya que por defecto esta cuenta no tiene permisos de lectura sobre AD.
Es importante resaltar que la recomendación es que la cuenta Invitado permanezca deshabilitada por motivos de seguridad.
Más información sobre la cuenta Invitado (Guest):
User and computer accounts
Threats and Countermeasures. Chapter 5: Security Options
Microsoft Security: Windows 2000 Server Baseline Security Checklist
Ante el paso de máquinas virtuales de los sistemas actuales de virtualización a Hyper-V se deben tener en cuenta una serie de factores antes de incluir directamente los vhd en un servidor el rol habilitado y arrancar las máquinas en él, con esto nos evitaremos sorpresas y algún que otro quebradero inesperado.
Aparte de las recomendaciones habituales del manual como no tener las máquinas en estado guardado, encontrarse todas en el estado apagado, … estas son algunas situaciones en las que nos podremos encontrar tras la actualización.
1. Licenciamiento ante el cambio a Hyper-V
Algo que debemos de tener en cuenta ante el cambio a Hyper-V es que el sistema operativo de la máquina cliente (child partition) deja de emplear los driver genéricos de virtualización y el hardware emulado para pasar a emplear, a través del bus de Hyper-V, los recursos físicos de la máquina W2K8.
Esto supone que se registran una serie de modificaciones en el hardware de la máquina que pueden obligar a volver a activar la licencia , es conveniente tenerlo en cuenta ya que el proceso de activación puede requerir un acceso a internet o, en caso de no disponer de este acceso, una activación por teléfono.
Por si surge el caso, para la activación por teléfono bastara con marcar esta opción de activación y aparecerá el teléfono de contacto según el país en el que nos encontremos.
2. Que ocurre con los archivos de configuración de la máquina
Con el paso a Hyper-V cambia el formato de los archivos de configuración de las máquinas virtuales siendo este .xml.
Esto supone que los archivos de configuración de la maquina (memoria, red, ...) deben ser generados de nuevo para que se apliquen a la antigua máquina virtual.
El formato del vhd sigue siendo compatible, con lo que el fichero vhd antiguo no precisa ninguna modificación para que sea aceptado por Hyper-V.
3. Como actuar cuando la antigua máquina tiene Virtual Machine Additions
En este punto hay que ser especialmente cuidadoso ya que podemos dejar la antigua maquina en un estado inestable.
Siempre se deben desinstalar la virtual machine additions antes del paso a Hyper-V.
Esto es así ya que, en caso de tener la maquina estas instaladas no se permite la instalación de las Integration Services .
Pero una vez que la maquina esta en Hyper-V las virtual machine additions no pueden ser desinstaladas, ya que, al emplear los drivers nuevos para hyper-v la maquina se considera física, no virtualizada, y da un error a la hora de proceder a su desinstalación.
4. ¿Y si mi máquina virtual es W2K3 SP1?
Las versiones soportadas con Hyper-V se pueden comprobar en el artículo siguiente:
http://support.microsoft.com/kb/954958/en-us
la pregunta es, ¿cómo es que W2K3 no aparece que este soportado como sistema cliente su versión con SP1?
Esto no supone que no funcione esta version en Hyper-V, supone que no ha sido testeado y las mejoras de cara a su administración incluidas en los Integration Services, como integrar el ratón en sesiones de administración establecidas mediante terminal server, y otras, no están disponibles para esta versión ni pueden ser instaladas.
Soporte Core Premier España
Administrando Roles, Role Services y Features desde línea de comandos
Para realizar esta operación utilizaremos la herramienta ServerManagerCmd que en todos los casos lanzaremos con privilegios elevados desde una ventana de línea de comandos.
Consultando Roles, Role Services y Features instalados
Empezaremos por mostrar los Roles, Roles services y Features instalados ejecutando servermanagercmd –query y obtenido una salida del tipo que parece más abajo, donde aparecen en color verde las distintas partes instaladas.
Como en versiones de anteriores podemos redireccionar la salida del comando a un fichero de texto, con tan solo utilizar el símbolo de redirección “>”
ServerManagerCmd –query > ServerConfig_17Agosto2008.txt
Otra posibilidad es obtener la salida en un fichero xml, para ello basta con escribir a continuación del modificador –query el nombre del fichero. Esta posibilidad facilita la manipulación de los ficheros cuando estamos automatizando tareas.
ServerManagerCmd –query Mifichero.xml
Instalando Roles, Role Services y Features
La sintaxis es sencilla, ServerManagerCMD –install “NombredelComponente” donde el nombre de componente será el nombre del componente a instalar (ver tabla más abajo). Así mismo podemos instalar componentes subordinados utilizando el parámetro –AllSubFeatures del modo siguiente:
ServerManagerCmd –install fs-dfs –allsubfeatures
Como se puede ver el comando anterior instala el Role service “Distributed File System” así como sus subordinados “DFS Namespaces” y “DFS Replication”. Si el resultado es correcto obtendremos una salida similar a esta:
Si para completar la instalación fuera preciso un reinicio, podemos utilizar el modificador –Restart.
Otra posibilidad que se ofrece es simular el resultado que se obtendría si se ejecutara el comando, esta opción se suministra mediante el parámetro -Whatif.
En caso de intentar instalar componentes ya instalados, obtendremos un mensaje similar a este:
Si por algún motivo ServerMangerCmd no fuera capaz de realizar la operación solicitada nos
mostrará un error en color rojo. Por defecto ServerManagerCmd escribe la información detallada de cada operación realizada en la ruta %SystemRoot%\logs\servermanager.log, siendo posible cambiar esta ubicación mediante el parámetro –LogPath o su versión abreviada –L.
ServerMangerCmd –install fs-dfs –allfeatures –logpath c:\logs\install.log
Otro error común es el relativo al uso de argumentos inválidos, en este caso seremos informados mediante un mensaje de salida.
Eliminando Roles, Role Services y Features
La sintaxis es similar a la de instalación ServermangerCmd –remove NombreComponente, con el parámetro –allsubfeatures para desinstalar también los componentes subordinados.
ServerManagerCmd –remove –fs-dfs –allsubfeatures
Al igual que en el proceso de instalación, si fuera necesario un reinicio para completar la eliminación se podría incluir el parámetro –Restart y simular el resultado del comando mediante el parámetro –Whatif
Paloma García Martín
Técnico de Soporte Microsoft Premier
Dado que muchos de nuestros sistemas están en otros idiomas diferentes al inglés (español fundamentalmente) este es una situación que se nos puede presentar con facilidad.
Para solventar esta situación se ha publicado el artículo referente a MDT 2008 al que se puede acceder desde http://support.microsoft.com/?id=952573
En resumen, este error se debe a que el script Ztibcdutility.vbs se queda esperando un “Successfully” tras la ejecución de BcdEdit y si el sistema no esta en US.English esto no ocurre, por lo que la fase de edición del arranque no es correctamente actualizada.
Para solucionarlo habrá que modificar el script Ztibcdutility.vbs del siguiente modo:
1. En MDT 2008 en la carpeta de distribución abrir la carpeta "scripts".
2. Editar el script Ztibcdutility.vbs
3. Localizar el código que contiene la función CreateNewRamDiskEntry
If iRetVal <> Failure Then
arrTemp = split(iRetVal, " ")
sNewGuid = arrTemp(2)
Else
CreateNewRamDiskEntry = iRetVal
Exit Function
End If
Borrar el código original y cambiarlo por el siguiente:
Dim aGuidTemp
arrTemp = split(iRetVal, "{")
aGuidTemp = split(arrTemp(1), "}")
sNewGuid = "{" & aGuidTemp(0) & "}"
4. Localizar la function RunBCDEdit
5. Utilizar el siguiente código para reemplazar la función original de RunBCDEdit
Function RunBcdEdit (sCommand, bCapture)
Dim iRetVal, oExec, sLine,oExec1, sLine1,arrTemp1
Dim re
sBcdEdit = oEnv.Item("SystemRoot") & "\system32\bcdedit.exe"
If not oFSO.FileExists(sBcdEdit) Then
SetBcdError ("Unable to locate bcdedit.exe")
RunBcdEdit = Failure
sCommand = sBcdEdit & " " & sCommand
Set oExec = oShell.Exec(sCommand)
sLine = oExec.StdOut.ReadLine
if bCapture = True Then
iRetVal = sLine
iRetVal = Success
RunBcdEdit = iRetVal
End Function
Espero que esta información ayuda a solucionar algunas situaciones comprometidas a la hora de preparar una instalación distribuida de nuestros sistemas en otros idiomas.
Tecnico de Soporte Premier España