Hola, soy Javier Rama, del equipo de Directorio Activo / Networking. En algunas ocasiones hemos tenido casos en los que el cliente necesita configurar el Firewall de Windows a través de GPO en su dominio.
Como sabemos, tenemos multitud de settings para configurarlo desde la consola de edición de Políticas de Grupo en:
Computer Configuration\Administrative Templates\Network\Network Connections\Windows Firewall
Sin embargo, puede haber ocasiones en que necesitemos deshabilitar todas las reglas y excepciones que aplicamos en el Firewall para un interfaz de red concreto del equipo.
Esto no podemos conseguirlo directamente con el conjunto de parámetros que podemos configurar a través de GPO.
Para conseguirlo, debemos realizar los siguientes pasos:
1. Deshabilitar la siguiente política en el perfil de Dominio, Windows Firewall: Protect all network connections
Gracias a este setting , habilitamos o deshabilitamos el Firewall de Windows. El inconveniente que nos encontramos estableciéndolo es que, además de habilitar el Firewall, también lo configuramos para que aplique todas las reglas en todos los interfaces de red disponibles en la máquina destino. Por tanto, lo deshabilitaremos estableciéndolo a Disabled y ,como veremos a continuación, activaremos el Firewall gracias a la herramienta netsh.
Gracias a este setting , habilitamos o deshabilitamos el Firewall de Windows.
El inconveniente que nos encontramos estableciéndolo es que, además de habilitar el Firewall, también lo configuramos para que aplique todas las reglas en todos los interfaces de red disponibles en la máquina destino.
Por tanto, lo deshabilitaremos estableciéndolo a Disabled y ,como veremos a continuación, activaremos el Firewall gracias a la herramienta netsh.
2. A continuación, crearemos un script de inicio para el equipo con el siguiente contenido:
netsh firewall set opmode mode=enable profile=domain (Habilitar el Firewall de Windows para el perfil de dominio) netsh firewall set opmode mode=enable interface=”Red” (Proteger este interfaz de red con el Firewall de Windows) netsh firewall set opmode mode=disable interface=”Red Externa” (No aplicar las reglas del Firewall para este intefaz)
netsh firewall set opmode mode=enable profile=domain (Habilitar el Firewall de Windows para el perfil de dominio)
netsh firewall set opmode mode=enable interface=”Red” (Proteger este interfaz de red con el Firewall de Windows)
netsh firewall set opmode mode=disable interface=”Red Externa” (No aplicar las reglas del Firewall para este intefaz)
…
(Continuar con todos los dispositivos poniéndolos a enable o disable según nos interese)
Como vemos, es necesario especificarle el nombre completo de cada interfaz de red.
Tras la aplicación de este script, conseguiremos el siguiente efecto:
3. El resto de parámetros que queramos configurar, tales como reglas específicas o excepciones, podemos hacerlo normalmente a través de GPO.
- Javier Rama del Castillo
Hola, soy Javier Rama, del equipo de Directorio Activo / Networking.
Hace algunos días, un cliente nos preguntaba cómo ocultar las carpetas y ficheros de un share a los usuarios que no tienen permisos para acceder a ellos.
Para acometer dicha tarea, tenemos disponible la tecnología ABE (Access Based Enumeration) gracias a la cual, el servidor de ficheros ocultará las carpetas y ficheros en función de los permisos del usuario que accede a dicho recurso.
ABE es una funcionalidad que está incluida en Windows Vista y en Windows Server 2008, pero además está disponible como descarga para Windows Server 2003 en el siguiente enlace:
Microsoft Download Center: Windows Server 2003 Access-based Enumeration
http://www.microsoft.com/downloads/details.aspx?FamilyId=04A563D9-78D9-4342-A485-B030AC442084&displaylang=en
Antes de habilitar ABE sobre cualquier recurso compartido, debemos tener en cuenta las siguientes consideraciones:
· ABE está pensada únicamente para shares de red, por ejemplo \\servidor\carpeta. Sin embargo, si accedemos a través del explorador (ruta C:\carpeta por ejemplo) esta tecnología no nos servirá.
· Además, también es oportuno apuntar que, habilitar ABE sobre una carpeta compartida añade una carga extra de CPU al servidor (el cual comprobará los permisos del usuario que intenta acceder con el contenido de la carpeta, y determinar así qué elementos mostrar). En escenarios en los que se produzcan muchos accesos a los recursos, será necesario tener en cuenta este punto.
CONFIGURANDO ABE
1- Una vez instalado ABE, será necesario habilitarlo en cada uno de los shares que deseemos. Para ello podemos proceder de dos maneras:
a) A través de la interfaz gráfica de usuario (Clic derecho sobre el share -> Propiedades -> Pestaña Access Based Enumeration -> Marcar checkbox Enable Access-based Enumeration in this shared folder ).
b) Desde línea de comando a través de la herramienta abecmd
Se puede encontrar información detallada sobre este comando en en siguiente enlace: Windows Server 2003 Access-based Enumeration http://www.microsoft.com/windowsserver2003/techinfo/overview/abe.mspx
Se puede encontrar información detallada sobre este comando en en siguiente enlace:
Windows Server 2003 Access-based Enumeration
http://www.microsoft.com/windowsserver2003/techinfo/overview/abe.mspx
2- Una vez habilitado ABE sobre un share y, habiendo configurado los permisos oportunos para los distintos usuarios, conseguiremos el efecto que aparece en las siguientes capturas (los ejemplos que aparecen a continuación corresponden al enlace anterior):
Figura 1 - Recurso compartido “Customer Accounts” con ABE deshabilitado. Como vemos en la Figura 1, el usuario puede ver todo el contenido del share independientemente de tener permisos de acceso para cada elemento o no. Con el checkbox Enable access-based enumeration on this folder habilitado desde las propiedades de la carpeta “Customer Accounts” , el usuario únicamente ve las carpetas a las cuales puede acceder (Figura 2).
Figura 1 - Recurso compartido “Customer Accounts” con ABE deshabilitado.
Como vemos en la Figura 1, el usuario puede ver todo el contenido del share independientemente de tener permisos de acceso para cada elemento o no.
Con el checkbox Enable access-based enumeration on this folder habilitado desde las propiedades de la carpeta “Customer Accounts” , el usuario únicamente ve las carpetas a las cuales puede acceder (Figura 2).
Figura 2 - Recurso compartido “Customer Accounts” con ABE habilitado.
Hola, soy Paula, del equipo de Directorio Activo. Hoy vamos a hablar de cómo habilitar la auditoria para poder disponer de información en el caso de que se cree o elimine una zona DNS integrada en Directorio Activo.
Habilitar la auditoría va a conllevar que el log de eventos de Seguridad registre una cantidad mayor de eventos, con lo que requerirá mayor espacio en disco (para no perder eventos, se puede incrementar el tamaño del log).
Los pasos a seguir para habilitar la auditoría son los siguientes:
1. Habilitar la auditoría al acceso a los servicios de directorio (Directory Service Access):
a. Editar la política Default Domain Controllers Policy o crear una nueva GPO en la OU de los controladores de dominio. Si se tienen varios dominios y se desea auditar la actividad en todos dependiendo del tipo de replicación de la zona, habrá que habilitar la auditoría en todos ellos.
b. Habilitar Success (también se puede auditar Failure) en la siguiente ruta de la GPO:
Computer Configuration > Windows Settings > Security Settings > Local Policies > Audit Policy > Audit directory service access
2. Establecer la auditoría sobre el objeto de Directorio Activo que deseemos. Esta operación se puede realizar, por ejemplo, mediante ADSIEdit:
a. Acceder a la partición que se desee auditar (Botón derecho sobre la raíz "ADSI Edit" y seleccionar Connect to...). Como se comentó anteriormente aquí, las zonas DNS pueden albergarse bajo el contenedor MicrosoftDNS en tres particiones diferentes en Directorio Activo dependiendo de su configuración de replicación:
CN=MicrosoftDNS,CN=System,DC=domain,dc=com -> Partición del dominio: La zona está configurada para replicar a todos los DCs del dominio CN=MicrosoftDNS,DC=DomainDNSZones,DC=domain,DC=com -> Partición de aplicación DomainDNSZones: La zona replica a todos los servidores DNS del dominio CN=MicrosoftDNS,DC=ForestDNSZones,DC=domain,DC=com -> Partición de aplicación ForestDNSZones: La zona replica a todos los servidores DNS del bosque
b. Acceder a las propiedades de la partición ForestDNSZones (por ejemplo) > Seguridad > Avanzadas > Auditoría
Agregar al usuario Everyone (o al usuario/grupo que se desee auditar) Aplicar a Container objects Tipo de acceso Create dnsZone Objects y Delete dnsZone Objects
Una vez se habilite, esta configuración es homogénea para todo el dominio, es decir, todos los DCs van a auditar estos accesos. Siempre es recomendable que se realicen algunos tests en un entorno de pruebas para comprobar que la auditoria cumple los requisitos que se necesitan.
Un ejemplo del evento que se generan al crear una nueva zona:
Event Type: Success Audit
Event Source: Security
Event Category: Directory Service Access
Event ID: 566
Date: 9/18/2008
Time: 1:17:42 PM
User: HALEDOMAIN\paula
Computer: HALEDC01
Description:
Object Operation:
Object Server: DS
Operation Type: Object Access
Object Type: container
Object Name: CN=MicrosoftDNS,DC=ForestDnsZones,DC=haledomain,DC=com
Handle ID: -
Primary User Name: HALEDC01$
Primary Domain: HALEDOMAIN
Primary Logon ID: (0x0,0x3E7)
Client User Name: paula
Client Domain: HALEDOMAIN
Client Logon ID: (0x0,0x226DB)
Accesses: Create Child
Properties:
Create Child
dnsZone
Additional Info: DC=prueba.com,cn=MicrosoftDNS,DC=ForestDnsZones,DC=haledomain,DC=com
Additional Info2: DC=prueba.com,CN=MicrosoftDNS,DC=ForestDnsZones,DC=haledomain,DC=com
Access Mask: 0x1
Ejemplo de una eliminación:
Time: 1:31:20 PM
Object Type: dnsZone
Object Name: DC=..Deleted-prueba.com\0ADEL:39fd87f0-46f8-4474-8a53-1392aaf34a95,CN=Deleted Objects,DC=ForestDnsZones,DC=haledomain,DC=com
Accesses: DELETE
DELETE
Additional Info:
Additional Info2:
Access Mask: 0x10000
Esperamos que esta información os sirva en caso de que necesitéis auditar la creación/borrado de zonas DNS.
- Paula Tomás Galed
Hola, somos Tolu Igbon y Paula Tomás. Hace unos días tuvimos un caso en el que se utilizaba un script para realizar una consulta LDAP (utilizando el proveedor LDAP y determinar los miembros del grupo Domain Admins. Este script devolvía únicamente parte de los miembros del grupo, mientras que, a través de la consola de Usuarios y Equipos de Directorio Activo (dsa.msc) se obtenía un número mayor de miembros (la totalidad de ellos).
Se observó que la misma consulta en otro script que utilizaba el proveedor WinNT sí devolvía efectivamente todos los miembros del grupo Domain Admins, así como también los devolvía la ejecución del comando Net Group “Domain Admins”
Sin embargo, tanto ADSIEdit como LDP.EXE devolvían resultados parciales iguales a los que se recibían utilizando el script con el proveedor LDAP.
Ejecutamos el comando LDIFDE para obtener un volcado completo del contenedor USERS del dominio donde residen nuestros usuarios y grupos:
LDIFDE –d “CN=Users,DC=Nombredominio,DC=com” –f ARCHIVOSALIDA.TXT
En el archivo de salida vimos que, de nuevo, sólo aparecía parte de los usuarios en el atributo member del grupo Domain Admins.
dn: CN=Domain Admins,CN=Users,DC=Dominio,DC=com
changetype: add
objectClass: top
objectClass: group
cn: Domain Admins
description: Designated administrators of the domain
member: CN=User1,CN=Users, DC=Dominio,DC=com
member: CN=User2,CN=Users, DC=Dominio,DC=com
member: CN=User3,CN=Users, DC=Dominio,DC=com
member: CN=User4,CN=Users, DC=Dominio,DC=com
Posteriormente, comparamos los atributos de los usuarios que SÍ aparecían como miembros del grupo Domain Admins con los de los usuarios que NO aparecían.
Averiguamos que los usuarios que no aparecían tenían el atributo PrimaryGroupID establecido a 512. Este valor corresponde al grupo “Domain Admins”.
dn: CN=User5,CN=Users, DC=Dominio,DC=com
objectClass: person
objectClass: organizationalPerson
objectClass: user
…………………………….
memberOf: CN=Enterprise Admins,CN=Users, DC=Dominio,DC=com
memberOf: CN=Administrators,CN=Users, DC=Dominio,DC=com
…………………………
primaryGroupID: 512 Sin embargo, los demás usuarios que sí aparecían como miembros del grupo “Domain Admins” tenían el atributo PrimaryGroupID establecido a 513, correspondiente al grupo “Domain Users”.
dn: CN=User1,CN=Users, DC=Dominio,DC=com
memberOf: CN=Group1,CN=Users, DC=Dominio,DC=com
memberOf: CN=Domain Admins,CN=Users, DC=Dominio,DC=com
primaryGroupID: 513 Este comportamiento es por diseño, y aparece descrito en el siguiente artículo:
275523 Setting Primary Group Excludes the User from the Group Membership in Active Directory http://support.microsoft.com/default.aspx?scid=kb;EN-US;275523
A traves de LDAP/ADSI, un usuario no aparece como memberOf (miembro de) su grupo primario. Dicho grupo tampoco muestra los member (miembros) que lo tengan como grupo primario.
Del mismo modo, y por diseño, los usuarios no aparecen como miembros del grupo “Domain Users”, al ser éste el grupo primario de la mayoría de los usuarios por defecto.
Para que los usuarios deseados aparezcan como miembros del grupo “Domain Admins” a través de ADSI/LDAP, hay que cambiar su grupo primario a través de la consola Usuarios y Equipos de Directorio Activo y establecerlo a “Domain Users”, por ejemplo.
Se puede encontrar más información en los siguientes artículos de KB:
321360 How to use native ADSI components to find the primary group http://support.microsoft.com/default.aspx?scid=kb;EN-US;321360
297951 How to use the PrimaryGroupID attribute to find the primary group for a user http://support.microsoft.com/default.aspx?scid=kb;EN-US;297951
Esperamos que os haya resultado interesante.
- Tolu Igbon && Paula Tomás Galed
Hola, soy Tolu Igbon, del equipo de Directorio Activo. Hoy vamos a hablar sobre cómo habilitar trace logging para diferentes componentes relacionados con Directorio Activo tanto en Windows Vista como en Windows Server 2008.
La herramienta Tracelog: http://msdn.microsoft.com/en-us/library/ms797927.aspx se introdujo con el kit de recursos de Windows 2000.
Esta utilidad permite habilitar “event trace logging”, (un especie de logging detallado) de distintos componentes de Windows a la hora de intentar resolver problemas (por ejemplo autenticación Kerberos, acceso LDAP, etc).
Para interpretar los “event trace logs” (.etl) generados se necesitan otras herramientas como:
La novedad real para Vista/2008 es que ha aumentado de manera significativa el numero de proveedores con los cuales podemos realizar este tipo de “logging”.
Aquí os proporcionamos unos ejemplos de cómo generar logging para componentes relacionados con Directorio Activo.
Cliente LDAP
En primer lugar, creamos una nueva clave de registro:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\ ldap\Tracing\ProcessName
ProcessName es el nombre del proceso que queremos “tracear” (por ejemplo MMC.exe).
Dentro de esta clave, podemos crear un valor opcional de tipo DWORD llamado PID. (Si establecemos este valor a un PID concreto, solo se traceará la instancia de la aplicación con este PID).
Para habilitar el tracing, ejecutamos el siguiente comando:
tracelog.exe -start <sessionname> -guid #<guid for ldap tracing provider> -f <filename> -flag <traceFlags>
sessionname es un nombre arbitrario que utilizamos para identificar la session de tracing (tendremos que hacer referencia al mismo identificador cuando terminemos la sesión). El GUID para el proveedor de tracing LDAP es "099614a5-5dd7-4788-8bc9-e29f43db28fc". filename especifica el archive de registro donde se generarán los logs. traceFlags puede ser una combinación de los siguientes valores: DEBUG_TRACE1 0x00000001 DEBUG_TRACE2 0x00000002 DEBUG_REFCNT 0x00000004 DEBUG_HEAP 0x00000008 DEBUG_CACHE 0x00000010 DEBUG_SSL 0x00000020 DEBUG_SPEWSEARCH 0x00000040 DEBUG_SERVERDOWN 0x00000080 DEBUG_CONNECT 0x00000100 DEBUG_RECONNECT 0x00000200 DEBUG_RECEIVEDATA 0x00000400 DEBUG_BYTES_SENT 0x00000800 DEBUG_EOM 0x00001000 DEBUG_BER 0x00002000 DEBUG_OUTMEMORY 0x00004000 DEBUG_CONTROLS 0x00008000 DEBUG_BYTES_RECEIVED 0x00010000 DEBUG_CLDAP 0x00020000 DEBUG_FILTER 0x00040000 DEBUG_BIND 0x00080000 DEBUG_NETWORK_ERRORS 0x00100000 DEBUG_SCRATCH 0x00200000 DEBUG_PARSE 0x00400000 DEBUG_REFERRALS 0x00800000 DEBUG_REQUEST 0x01000000 DEBUG_CONNECTION 0x02000000 DEBUG_INIT_TERM 0x04000000 DEBUG_API_ERRORS 0x08000000 DEBUG_ERRORS 0x10000000
sessionname es un nombre arbitrario que utilizamos para identificar la session de tracing (tendremos que hacer referencia al mismo identificador cuando terminemos la sesión).
El GUID para el proveedor de tracing LDAP es "099614a5-5dd7-4788-8bc9-e29f43db28fc".
filename especifica el archive de registro donde se generarán los logs.
traceFlags puede ser una combinación de los siguientes valores:
DEBUG_TRACE1
0x00000001
DEBUG_TRACE2
0x00000002
DEBUG_REFCNT
0x00000004
DEBUG_HEAP
0x00000008
DEBUG_CACHE
0x00000010
DEBUG_SSL
0x00000020
DEBUG_SPEWSEARCH
0x00000040
DEBUG_SERVERDOWN
0x00000080
DEBUG_CONNECT
0x00000100
DEBUG_RECONNECT
0x00000200
DEBUG_RECEIVEDATA
0x00000400
DEBUG_BYTES_SENT
0x00000800
DEBUG_EOM
0x00001000
DEBUG_BER
0x00002000
DEBUG_OUTMEMORY
0x00004000
DEBUG_CONTROLS
0x00008000
DEBUG_BYTES_RECEIVED
0x00010000
DEBUG_CLDAP
0x00020000
DEBUG_FILTER
0x00040000
DEBUG_BIND
0x00080000
DEBUG_NETWORK_ERRORS
0x00100000
DEBUG_SCRATCH
0x00200000
DEBUG_PARSE
0x00400000
DEBUG_REFERRALS
0x00800000
DEBUG_REQUEST
0x01000000
DEBUG_CONNECTION
0x02000000
DEBUG_INIT_TERM
0x04000000
DEBUG_API_ERRORS
0x08000000
DEBUG_ERRORS
0x10000000
Para detener el tracing, ejecutamos el siguiente comando:
tracelog.exe -stop <sessionname>
Ejemplo práctico
Un administrador recibe un error inesperado en una aplicación que establece contraseñas para cuentas de Usuario.
Decide habilitar tracing para APP1.exe mediante los siguientes pasos:
1. Crear la clave de registro
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\ ldap\Tracing\App1.exe y habilitar una session de tracing mediante el siguiente comando: C:\>tracelog.exe -start ldaptrace -guid #099614a5-5dd7-4788-8bc9-e29f43db28fc -f .\ldap.etl -flag 0x80000
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\ ldap\Tracing\App1.exe
y habilitar una session de tracing mediante el siguiente comando:
C:\>tracelog.exe -start ldaptrace -guid #099614a5-5dd7-4788-8bc9-e29f43db28fc -f .\ldap.etl -flag 0x80000
2. Una vez ejecutado este comando, se escribirán mensajes de tipo DEBUG_BIND en el log .\ldap.etl.
3. Ejecutamos App1.exe para reproducir el comportamiento inesperado.
4. Detenemos la session de tracing:
C:\>tracelog.exe -stop ldaptrace
5. Eliminamos la clave HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\ ldap\Tracing\App1.exe para que ningún otro usuario pueda obtener información de tracing de App1.exe.
6. Utilizamos otra herramienta como Tracerpt.exe para interpreter la información del log de tracing generado:
C:\>tracerpt.exe .\ldap.etl -o -report
Autenticación Kerberos
Habilitar el “tracing detallado” de kerberos mediante el siguiente comando
tracelog.exe -kd -rt -start kerb -guid #6B510852-3583-4e2d-AFFE-A67F9F223438 -f .\kerb.etl -flags 0x43 -ft 1
Para detener el logging, una vez reproducido el problema, ejecutar el siguiente comando:
tracelog.exe -stop kerb
Autenticación NTLM
Para habilitar el logging:
tracelog.exe -kd -rt -start ntlm -guid #5BBB6C18-AA45-49b1-A15F-085F7ED0AA90 -f .\ntlm.etl -flags 0x15003 -ft 1
Para detener el logging:
tracelog -stop ntlm
KDC
Para habilitar logging en el KDC (el servicio de validación y distribución de tickets kerberos en un DC):
tracelog.exe -kd -rt -start kdc -guid #1BBA8B19-7F31-43c0-9643-6E911F79A06B -f .\kdc.etl -flags 0x803 -ft 1
tracelog.exe -stop kdc
Usando el editor del registro
Tambien podemos habilitar el logging a través del registro de Windows:
Method
Registry key setting
NTLM
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0
· Value name: NtLmInfoLevel
· Value type: DWORD
· Value data: c0015003
Kerberos
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters
· Value name: KerbDebugLevel
· Value data: c0000043
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos
· Value name: LogToFile
· Value data: 00000001 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters
· Value data: 00000001
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdc
· Value name: KdcDebugLevel
· Value data: c0000803
Ubicación de los ficheros de salida
Si habilitamos el logging mediante tracelog.exe se generarán los archivos correspondientes de registro, kerb.etl/kdc.etl/ntlm.etl en el directorio desde donde hemos ejecutado el comando
Si lo hemos habilitado en el registro, los archivos se generarán en las siguientes ubicaciones:
Esperamos que esta información os pueda resultar de utilidad a la hora de buscar las posibles causas de problemas relacionados con Directorio Activo.
Tolu Igbon
Hola a todos,
Una de las nuevas tecnologías que tenemos con Windows Server 2008 es la de virtualización mediante Hyper-V.
Pero esto nos plantea una cuestión muy importante en los entornos de alta disponibilidad o que resulten claves en la producción, ¿como hago BackUp de las máquinas virtuales que tengo afectando lo menos posible a mis usuarios?
Para esto tenemos nuestro software de BackUp DPM 2007 (Data Protection Manager) o herramientas desarrolladas por terceros que están pensadas específicamente para este entorno.
Pero investigando un poco me encontré con un post de mi compañero Rob Hefner que os traduzco esperando que os resulte de utilidad.
Para habilitar el BackUp basado en VSS de Hyper-V en la utilidad Windows Server BackUp se deben añadir las siguientes claves al registro de Hyper-V VSS. La clave WindowsServerBackUp no es generada cuando se instala la utilidad Windows Server BackUp en la máquina. Se debe crear esta clave manualmente:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT \CurrentVersion\WindowsServerBackup\Application Support\{66841CD4-6DED-4F4B-8F17-FD23F8DDC3DE}
Una vez creada la clave se necesitaran incluir un String Value con los campos:
Name: Application Identifier Type: REG_SZ Value: Hyper-V
Cuando este completado, deberán verse como esto:
La utilidad Windows Server Backup solo soporta el BackUp de volúmenes, por esto cuando se realicen los BackUps de las máquinas virtuales se deben seleccionar todos los volúmenes donde los datos de las MV estén guardados.
Por ejemplo, si se esta empleando la ubicación por defecto de los ficheros de configuración (C:\ProgramData\Microsoft\Windows\Hyper-V\Virtual Machines) y el disco VHD esta en otro volumen se deberán seleccionar los dos volúmenes en el BackUp.
Cuando se inicie la restauración del BackUp seleccionar en “Application Restore” la opción de Hyper-V, si no se selecciona este método no se podrá restaurar ficheros de las MV en funcionamiento. Como parte del proceso de restauración las MV actuales serán paradas y borradas, siendo sustituidas y registradas por las del BackUp en Hyper-V.
Hay algunas limitaciones y comportamientos que se deben conocer antes de decidirse por este método:
1. Si la máquina virtual contiene discos dinámicos no puede ser salvada mediante VSS, solo se soportara el BackUp con la máquina parada (Offline BackUp). Otra opción seria realizar el BackUp mediante un software de BackUp local en la máquina como cualquier máquina física.
2. En el caso de máquinas virtuales que no soporten VSS, como son W2000, Windows XP o máquinas sin Integration Services instalados, entraran en estado "salvada" (saved state) mientras se hace el Snapshot y se restauraran tras terminar la operación, por lo que el proceso supone una parada en la máquina (cosa que normalmente evita VSS).
Se experimentará este mismo comportamiento si se deshabilitar Integration Services en la máquina como se muestra a continuación:
3. Cuando se realiza la restauración desde el BackUp se debe restaurar todo el volumen, la restauración de máquinas virtuales independientes no esta soportada con Windows Server BackUp.
4. Si la máquina virtual tiene 2 o más Snapshots la restauración fallará. Para poder solucionarlo:
El post completo, en Ingles, lo podéis localizar en
Espero que os resulte de utilidad.
Raúl del Moral Guirado
Técnico de Soporte Microsoft Premier
Este post pretende ser el primero de una serie de post sobre los problemas más habituales que observamos día a día los ingenieros de soporte de cluster, el primero de ellos estará centrado en el cambio de firmas de los discos de cluster.
El servicio de cluster reconoce e identifica los discos por su firma. Las firmas de los discos están almacenadas en el disco físico en el Master Boot Record (MBR). El MBR es un registro que utiliza el servicio de cluster para mantener todos los discos que administra, es decir utiliza el MBR para realizar un seguimiento de los discos.
Durante el transcurso de las operaciones del servicio de cluster (arranque, reinicio, failover…), si el servicio de cluster no puede encontrar un disco que está identificado con una firma en concreto, no podrá poner online el disco.
El componente de cluster que específicamente detecta esta condición y añade el error en el cluster.log es el cluster disk filter driver (clusdisk.sys).
En la imagen de abajo se puede ver un ejemplo de la firma de un disco en el MBR.
La firma del disco en el MBR está en formato Little endien, con lo que los bytes esta al revés con lo que la firma que aparece en la imagen en la rama de registro de cluster estará como 0XA3D9A3D9.
El primer paso para en el troubleshooting de firmas de discos en cluster es verificar si la firma del disco ha cambiado.
Como determina si la firma del disco ha cambiado
Síntomas
· El servicio de cluster no arranca en ninguno de los nodos.
· El servicio de cluster arranca pero algún disco no se pone online.
Comprobaciones rápidas
Los siguientes pasos pueden facilitar una rápida evaluación para detectar si los fallos de disco se deben a un cambio de firmas. Si las firmas cambian clusdisk.sys las ignorara permitiendo al sistema operativo montar el disco.
1. Revisa el visor de eventos en busca del siguiente evento
Identificador de sucesos: 1034 Origen: ClusDisk Descripción: No se pudo encontrar el disco asociado a recurso de disco de clúster <DriveLetter>. La firma esperada del disco fue <DiskSignature>.
2. Si el evento anterior no está en el visor de sucesos continuar al paso 3 y si esta pasar a la sección “como arreglar firmas de discos que han cambiado”
3. Navegar por el Explorer y verificar si alguno de los discos compartidos que fallen aparecen listados.
4. En caso de que aparezcan intentar acceder a ellos.
5. Crear una carpeta en el disco compartido.
6. Cierra el explorer, reábrelo, conecta con la unidad y verifica que la carpeta sigue presente.
7. Si la carpeta aun está presente en el disco verifica el clusdisk.sys está cargado y ejecutándose
a. Botón derecho en MI PC selecciona administrar.
b. Selecciona administrador de dispositivos.
c. En el menú ver del administrador de dispositivos selecciona Mostrar dispositivos ocultos.
d. En la parte derecha del administrador de dispositivos, despliega dispositivos que no son plug and play
e. Doble clic en Cluster Disk Driver para abrir la ventana de propiedades
f. En la pestaña de general verificar que Utilizar este dispositivo está habilitado, si no habilítalo
g. En la pestaña Driver verifica que el tipo de arranque sea Sistema, si no selecciona system verifica que el estado sea Arrancado
h. Si el driver de disco de cluster ha sido deshabilitado o el tipo de arranque esta en manual y no esta ejecutándose configúralo de manera correcta y reinicia el nodo y verifica que el servicio de cluster este arrancado, si no está arrancado y aun puedes acceder a los discos a través del Explorer continua con el siguiente paso
8. SI los disco son accesible verifica que si ambos nodos del cluster están arrancados, si lo están apagad uno de ellos para reducir la posibilidad de corrupción de datos antes de reparar las firmas.
Como reparar las firmas que han cambiado
Cuando un recurso de disco físico es creado, la firma del disco es almacenada en el GUID del recurso en la subclave Parameters en el hive de cluster
Las siguientes imágenes muestran el GUID de un recurso de disco físico de un disco de Quorum y la subclave de parameters donde esta almacenada la firma,
Para reemplazar las firmas hay 2 herramientas:
Cluster recovery tool
1. Añade de nuevo el disco en el administrador de cluster
2. Utiliza la herramienta cluster recovery la cual reconstruirá las dependencias del disco y asignara a la nueva unidad la letra correspondiente.
3. Borra el recurso de disco fallido
Dumpcfg.exe
1. Utiliza dumpcfg.exe para reemplazar la firma del disco siguiendo los pasos de el siguiente articulo 280425 Recovering from an Event ID 1034 on a Server Cluster.
Juan Bautista Arlandis
Tecnico de Soporte Microsoft Premier.