En Microsoft System Center Virtual Machine Manager 2008 R2, cuando eliminas un disco duro virtual (VHD) de una máquina virtual espera que el fichero .vhd únicamente se desasigne de la maquina virtual. Si embargo el fichero vhd es eliminado del servidor de Hyper-V.

Hemos publicado un Fix que soluciona este comportamiento.  Puedes leer los detalles y acceder al Fix para instalarlo en:

KB976246 - When you remove a virtual hard disk from a virtual machine in System Center Virtual Machine Manager 2008 R2, the .vhd file on the Hyper-V server is deleted without warning

Tras aplicar este fix aparece el siguiente mensaje al realizar esta acción:

You have chosen to remove virtual hard disks from virtual machine VMName. This action will delete the .vhd files.
Do you want to continue?

Si pulsas Yes, el fichero .vhd es borrado del  Hyper-V server. Si pulsas en No, el fichero .vhd se mantiene unido a la maquina virtual y no es eliminado del Hyper-V server.

Un saludo.

Consulta con el equipo de Windows.

Hola a todos,

Como todos sabéis, los Controladores de Dominio de un dominio sincronizan su servicio de tiempos siguiendo la jerarquía del dominio. Generalmente, el PDC Emulator del dominio raíz del bosque se configura para que sincronice su hora con una fuente externa o con su propio reloj hardware, tal y como se indica en el artículo:

816042    How to configure an authoritative time server in Windows Server

Si el rol de PDC Emulator en el dominio raíz del forest se mueve a otro DC, además de configurar el nuevo PDC, también debe indicarse al PDC antiguo que ya no es una fuente de hora autoritativa en el entorno, ya que la operación de transferencia del rol no realiza esta operación sobre el servicio de tiempos.

Si no se realiza la operación, el antiguo PDC sigue anunciándose y actuando como fuente de tiempos autoritativa, lo que hace que el resto de DCs, si no tienen fallos al contactar con él o no realizan de nuevo el proceso selección de una nueva fuente de tiempos, sigan sincronizándose contra esta máquina.

El procedimiento que hay que llevar a cabo en el PDC antiguo se describe en el artículo Change the Windows Time service configuration on the previous PDC emulator y consiste en ejecutar los comandos que aparecen a continuación:

• Ejecutar el siguiente comando para configurar el servicio de tiempos para que siga la jerarquía del dominio:

w32tm /config /syncfromflags:domhier /reliable:no /update

• Parar y arrancar el servicio de tiempos (W32Time)

net stop w32time && net start w32time

Tras realizar esta modificación, el antiguo PDC deja de anunciarse como fuente de tiempos y, por lo tanto, el resto de los DCs procederán a buscar una nueva fuente de tiempos una vez agotados los tiempos de polling. 

Espero que encontréis útil esta información.

Paula Tomás Galed

Hola a todos.

Frecuentemente recibimos preguntas en soporte relacionadas con la distribución de la configuración 802.1x para los puestos cliente de una infraestructura de red.

Como veremos a continuación, la respuesta a esto depende del sistema operativo sobre el que queramos realizar la configuración:

Windows XP SP3  (válido para Windows Vista, Windows 7 y Windows Server 2008 y R2)

En el caso del Windows XP, necesitaremos crearnos un perfil en un fichero .xml a través de la herramienta netsh.

La idea sería:

1. Realizar la configuración deseada en un puesto cliente.

2. Exportar la configuración a un fichero .xml a través de la siguiente sentencia desde la línea de comandos:

    netsh lan export profile folder=c:\Ruta

3. En la ruta seleccionada, encontraremos un fichero .xml 

4. Para cargar la configuración en otro equipo diferente, ejecutaríamos lo siguiente:

    netsh lan add profile filename=FicheroPerfil.xml

A partir de aquí, podríamos crear un script (o utilizar aplicaciones de distribución de software como System Center Configuration Manager) para ejecutar esta última sentencia en todos los puestos Windwos XP SP3 en los que nos interese configurar 802.1x.

Por políticas de dominio (válido para Windows Vista, Windows 7 y Windows Server 2008 y R2)

A diferencia del punto anterior, para estos sistemas operativos disponemos de políticas de dominio para realizar la configuración deseada en:

Computer Configuration/Windows Settings/Security Settings/Wired Network (IEEE 802.3) Policies

Podéis encontrar más información relacionada con este tema en los siguientes artículos:

• Netsh Commands for Wired Local Area Network (LAN) in Windows Server 2008 and Windows Server 2008 R2
• 929847 - How to enable computer-only authentication for a 802.1X-based network in Windows Vista, in Windows Server 2008, and in Windows XP Service Pack 

Esperamos que esta información os haya sido de utilidad.

Un saludo,

Javier Rama.

Hola a todos,

Recientemente nos hemos encontrado con un caso curioso, en el que hemos estado trabajando unas cuantas semanas, que implica tanto a la parte de Core como de Directorio Activo y queríamos comentároslo. Esperamos que os sea de utilidad :).

Cuando un usuario se conecta a un servidor de Terminal Server, el servidor de licencias registra el siguiente evento:

Event ID 4105

Source Microsoft-Windows-TerminalServices-Licensing

Type Warning

Description

The Terminal Services license server cannot update the license attributes for user "user" in the Active Directory Domain "domain". Ensure that the computer account for the license server is a member of Terminal Server License Servers group in Active Directory domain "domain".

If the license server is installed on a domain controller the Network Service account also needs to be a member of the Terminal Server License Servers group.

If the license server is installed on a domain controller after you have added the appropriate accounts to the Terminal Server License Servers group you must restart the Terminal Services Licensing service to track or report the usage of TS Per User CALs.

Win32 error code: 0x80070005

El error 4105 ocurre en los usuarios migrados desde un entorno NT/2000. Cuando se actualiza el esquema del dominio a 2003, los usuarios creados a partir de ese momento, incluyen permisos de lectura/escritura para el grupo Terminal Server License Servers en su security descriptor. Esto es debido a que el grupo Terminal Server License Servers se crea al ampliar el esquema a 2003 ya que en 2000 no existía y se modifica el defaultSecurityDescriptor de la clase user añadiendo la siguiente ACE:

(OA;;WPRP;6db69a1c-9422-11d1-aebd-0000f80367c1;;S-1-5-32-561)

Donde:

• 6db69a1c-9422-11d1-aebd-0000f80367c1 –> es la propiedad sobre la que damos los permisos (terminalserver)
• WPRP –> Write/Read property
• S-1-5-32-561 –> SID del grupo Terminal Server License Servers

Llegados a este punto tenemos dos posibilidades:

• Aplicar la ACE para todos los objetos en el naming context de dominio.

Para ello, lo que tenemos que hacer es ejecutar el comando dsacls "dc=XXXX,dc=XXXX,dc=XXXX,dc=XXXX” /I:T /G "BUILTIN\Terminal Server License Servers”:WPRP;terminalServer”. Por ejemplo, si nuestro dominio se llamase contoso.com el comando sería:

dsacls "dc=contoso,dc=com” /I:T /G "BUILTIN\Terminal Server License Servers”:WPRP;terminalServer”

• Dar permisos usuario a usuario utilizando el comando:

dsacls "CN=XXXX,OU=XXXX,OU=XXXX,OU=XXXX,DC=XXXX,DC=XXXX,DC=XXX" /G "BUILTIN\Terminal Server License Servers:WPRP;terminalServer"

Este comando lo que hace es precisamente dar permisos de lectura/escritura al grupo Terminal Server License Servers sobre la propiedad terminalServer de un usuario. Por tanto, lo que necesitamos para resolver el problema es identificar todos los usuarios creados antes de actualizar el esquema a 2003 (y que vayan a acceder a través de terminal server) y darle los permisos antes mencionados.

En este punto es necesario identificar los usuarios sobre los que necesitamos dar los permisos, basándonos en la pertenencia a un grupo o en la fecha de creación. Si os vais a basar en la pertenencia a grupos, os recomendamos seguir los pasos descritos en el siguiente post:

Diversas herramientas no muestran todos los miembros de un grupo en el Directorio Activo

De acuerdo con el post, un posible script sería como el siguiente:

Set objGroup = GetObject _     ("LDAP://cn=XXXX, ou=XXXX, dc=XXXX, dc=XXXX”) set objShell = WScript.CreateObject("WScript.Shell") For Each strUser on objGroup.Member         Wscript.Echo strUser          set objExec = objShell.Exec("dsacls """ + strUser + """ /G ""BUILTIN\Terminal Server License Servers:WPRP;terminalServer""")

El anterior script daría permisos a 1000 usuarios pertenecientes a un grupo administrativo. Si el número de usuarios es mayor, habría que utilizar otro script.

Nuestros compañeros de desarrollo nos han comentado que el script se complicaría bastante por lo que os recomendamos abrir un caso con ellos para que os puedan guiar de la mejor manera. Asimismo, si lo que queremos es dar permisos a usuarios de una OU específica el script también sería diferente.

Por último, si os queréis basar en la fecha de creación de los usuarios también deberíamos utilizar un script diferente y bastante más complejo. Además, necesitaríamos utilizar un filtro para la query LDAP del tipo (&(objectclass=user)(whenCreated>=20010420235531.0Z)(whencreated<=20010420235531.0Z).

Un saludo,

Rafael Basterra Careaga y Yolanda Muñoz Muñoz

Hola a todos.

Recientemente se nos planteó un caso de este tipo en soporte. En este caso era debido a que los DCs Windows Server 2003 se estaban “comportando” como Windows NT. Aquí tenéis toda la histora:

Entorno:

• Dominio con 3 DCs Windows Server 2003 (SP2) y múltiples BDCs Windows NT4.0
• Modo functional Windows 2003 Interim
• How to raise domain and forest functional levels in Windows Server 2003
• Functional Levels Background Information
• Servidores miembro Windows Server 2003

Problema:

• No se podía unir equipos Windows Server 2008R2 al dominio como servidores miembro
• Al intentar unirse especificando el nombre FQDN del dominio se recibía el error:

An Active Directory Domain Controller (AD DC) for the domain DOMINIO.COM could not be contacted. Ensure that the domain name is typed correctly

• Al intentar unirse especificando el nombre NETBIOS del dominio se recibía el error:

The following error occurred attempting to join the domain DOMINIO: The specified domain either does not exist or could not be contacted

• El problema se repetía al intentar unir equipos Windows Server 2003 al mismo dominio mediante el nombre FQDN, pero NO ASÍ por mediante el nombre NETBIOS donde SÍ lograban unirse correctamente al mismo dominio.

A su vez, determinamos que los mismos servidores Win2008R2 SÍ podían unirse correctamente utilizando el nombre FQDN a otros dominios del mismo entorno

• Durante nuestra investigación obtuvimos y analizamos trazas de red del tráfico entro los equipos Win2008R2 y los DCs

Observamos que, en principio, los DCs respondían “correctamente” a las peticiones de los clientes (no había cortes de tráfico ni errores en las comunicaciones entre los prospectivos servidores miembros 2008R2 y los DCs). A pesar de ver que recibían “respuestas” por parte de los DCs, los equipos Win2008R2 persistían en repetir las mismas peticiones para localizar información del dominio al que se querían unir, hasta finalmente fallar con los errores ya citados

Investigación

El problema finalmente tenía 2 matices:

1)

• A pesar de ser Win2003, los 3 DCs del dominio, a ojos de los clientes “actuaban” como servidores Windows NT4.
• Tenían configurados una clave de registro NT4Emulator,  que existe (como medida temporal) para evitar que se sobrecarguen los nuevos DCs de tipo directorio activo durante la migración de un dominio de tipo Windows NT4 a directorio activo
• La descripción y la funcionalidad de la clave de registro se encuentran en el siguiente artículo:

298713 How to prevent overloading on the first domain controller during domain upgrade

The NT4Emulator parameter specifies whether this domain controller will emulate the behavior of an Windows NT 4.0-based domain controller. By default, the domain controller does not emulate this behavior. Emulation of the Windows NT 4.0 behavior is desirable when the first domain controller that is running Windows 2000 or a later version of Windows is promoted to a primary domain controller in a Windows NT 4.0 domain that has many Windows 2000-based clients. Unless you emulate the Windows NT 4.0 behavior, all the Windows 2000-based clients will target the Windows-based domain controller and potentially overload it. This parameter is ignored on computers that are not domain controllers.

• Respecto a este caso concreto, observamos los comportamientos descritos en rojo

If this parameter is set to TRUE, the following scenario occurs on a domain controller:

• Incoming LDAP locator pings are ignored unless the ping comes from an admin computer. (See the "Neutralizing Windows NT 4.0 Emulation for Some Computers" section.)
• The flags that are negotiated during the incoming security channel setup will be set to what an Windows NT 4.0-based domain controller can support unless the channel setup comes from an admin computer.

• Ambos puntos explicaban por qué los clientes Win2008R2 repetían sus peticiones a pesar de recibir “respuesta”, tanto en los intentos de unirse al dominio mediante nombre FQDN como mediante nombre Netbios

2)

• A su vez el hecho de que los servidores Win2008R2 no se unieran al dominio pero los equipos Win2003 sí  (a través de NETBIOS )se explica en el siguiente artículo:

940268  Error message when you try to join a Windows Vista, Windows Server 2008, Windows 7, or Windows Server 2008 R2-based computer to a Windows NT 4.0 domain: "Logon failure: unknown user name or bad password"

• En resumen, los DCs se comportaban como máquinas NT4, y Win7/Win2008R2 no pueden unirse a un dominio de tipo NT4.

Resolución

• Pudimos unir los equipos Windows Server 2008R2 correctamente al dominio tras crear el valor de registro NeutralizeNT4Emulator que les permitía contactar con los DCs Windows Server 2003 y que éstos les respondiesen “correctamente”

Tolu Igbon