Si alguna vez te pasa, no es magia, no es un virus, es solo que el sistema que es muy organizado y te los ha borrado.
Ahora en serio, este post trata de accesos directos se nos han estropeado, por ejemplo porque el destino ya no existe. Este tipo de accesos directos son detectados por el “Solucionador de problemas” que si cuando lanza sus labores semanales de mantenimiento encuentra que hay más de cuatro, los borra.
Se trata de una funcionalidad a priori muy útil, pero si ni te gusta siempre puedes deshabilitarla cambiando la configuración del Solucionador de Problemas y marcando la opción “Desactivado”.
Nuestra recomendación, dejarlo activado pero estar atentos de no tener más de cuatro accesos directos rotos.
Panel de Control – Solución de Problemas – Cambiar la configuración.
Hasta la próxima.
Paloma Garcia
Soporte Premier
Hola de nuevo,
He localizado algunos casos de soporte en los que, en el log del cliente APP-V, se genera el error XXXXXXA-0000E005 cuando se abre más una aplicación virtualizada en el cliente.
Si tenemos una solo aplicación abierta todo funciona con normalidad, pero en el momento en que abrimos una nueva aplicación en el mismo cliente se genera este evento.
Tenemos documentado el articulo:
930623 Error message when you try to start an application in Microsoft SoftGrid: "Error code: xxxxxx-xxxxxx0A-0000E005"
http://support.microsoft.com/default.aspx?scid=kb;EN-US;930623
Pero en este caso no tiene nada que ver con la parte cliente, como se indica en este artículo. sino con la parte servidora, por lo que el modo de actuación publicado no resulta de utilidad.
Una explicación del comportamiento del cliente es la siguiente.
En el log del cliente aparece:
[01/13/2010 xx:xx:xx AMGR INF] {tid=B00}
Pasando a operación sin conexión
Dirección URL: RTSP://ServidorAppV.es:554/adobe/adobeacrobat2.sft
Error: 0000008A-00000001
[01/13/2010 xx:xx:xx AMGR INF] {hap=67:app=Adobe Reader 9 9.2.0.124:tid=B00}
Application Virtualization Client perdió el contacto con un servidor y pasó al modo sin conexión.
[01/13/2010 xx:xx:xx JGSW ERR] {hap=67:app=Adobe Reader 9 9.2.0.124:tid=10DC:usr=Test}
Application Virtualization Client no pudo establecer conexión con la dirección URL de transmisión "RTSP://ServidorAppV.es:554/adobe/adobeacrobat2.sft" (rc 16D1120A-0000E005, original rc 16D1120A-0000E005)
Este error en este caso se ha generado por una limitacion del servidor de APP-V, este no dispone de recursos suficientes para gestionar la segunda sesión de aplicación en el cliente y no le permite el acceso, pasando este a funcionamiento sin conexion y generando los errores anteriormente descritos.
Esta situación se soluciona ampliando los recursos del servidor, una vez realizada esta operación el error desaparece.
Espero que esta información os resulte de utilidad.
Un saludo.
Raúl del Moral.
Técnico de Soporte Premier
Aunque no es objeto de este blog avisaros de todos los parques que van saliendo, creemos que es interesante hacer hincapié en este, porque ¿quién no ha tenido algún problema los clústeres de impresión y los monitores de impresión?
http://support.microsoft.com/kb/976571/en-us
Yo me lo instalaría ya, ¿y tu?
Paloma Garcia
Soporte Premier
Hola a todos. Empezamos el año con una breve nota sobre Windows Server 2008 R2.
Hemos tenido últimamente varios casos en los que determinados servicios configurados para utilizar únicamente encriptación DES no son capaces de obtener un ticket Kerberos.
Esto se debe a que en Windwos Server 2008 R2 y Windows 7 los tipos de encriptación DES están deshabilitados por defecto. Si no modificamos la configuración, las suites de encriptación soportadas son las siguientes:
- AES256-CTS-HMAC-SHA1-96
- AES128-CTS-HMAC-SHA1-96
- RC4-HMAC
No obstante, si es necesario, se pueden habilitar tanto DES-CBC-MD5 como DES-CBC-CRC.
Supongamos que tenemos una aplicación que no es capaz de obtener tickets Kerberos en un entorno donde los DCs son Windows Server 2008 R2. Si echamos un vistazo al visor de sucesos de los DCs probablemente nos encontraremos con eventos con ID 16 y 27 con origen Microsoft-Windows-Kerberos-Key-Distribution-Center.
ID: 27
Source: Microsoft-Windows-Kerberos-Key-Distribution-Center
Symbolic Name: KDCEVENT_UNSUPPORTED_ETYPE_REQUEST_TGS
Message: While processing a TGS request for the target server %1, the account %2 did not have a suitable key for generating a Kerberos ticket (the missing key has an ID of %3). The requested etypes were %4. The accounts available etypes were %5.
ID: 16
Source: Microsoft-Windows-Kerberos-Key-Distribution-Center
Symbolic Name: KDCEVENT_NO_KEY_INTERSECTION_TGS
Message: While processing a TGS request for the target server %1, the account %2 did not have a suitable key for generating a Kerberos ticket (the missing key has an ID of %3). The requested etypes were %4. The accounts available etypes were %5. Changing or resetting the password of %6 will generate a proper key.
En este caso, habría que determinar si la aplicación, efectivamente, sólo puede utilizar DES. Si no es posible configurar la aplicación para utilizar métodos de encriptación más fuertes y es necesario el uso de Kerberos, se podrá proceder a habilitar el tipo de encriptación DES para la autenticación Kerberos en las máquinas Windows 7 o Windows Server 2008 R2:
- Acceder a la siguiente política:
Computer Configuration\ Windows Settings\ Security Settings\ Local Policies\ Security Options
- Seleccionar la opción Network security: Configure encryption types allowed for Kerberos
- Seleccionar Define these policy settings y marcar todas las casillas de métodos de encriptación para habilitarlos todos.
- Aceptar los cambios.
Esta información se puede encontrar de forma más detallada en el siguiente artículo:
977321 The security principals and the services that use only DES encryption for Kerberos authentication are incompatible with the default settings on a computer that is running Windows 7 or Windows Server 2008 R2
Espero que la información os resulte de utilidad.
- Paula Tomás Galed
Hola a todos.
Como ya habréis visto, hemos hecho un pequeño descanso durante las vacaciones de Navidad, pero ya estamos casi de vuelta.
Queremos agradeceros a todos que durante este año hayáis leído nuestros artículos, los hayáis comentado y hayáis participado en el blog. Intentaremos daros todavía podamos más información este año y os invitamos a participar con vuestros comentarios y sugerencias.
Desde aquí queremos desearos a todos un Feliz Año 2010.
Gracias.
- Consulta con el equipo de Windows
Una de las preguntas más frecuentes que nos encontramos los ingenieros de soporte a Directorio Activo en nuestro día a día, ¿Cómo puedo saber si el Directorio Activo está replicando correctamente? ¿Cuándo fue la última vez que replicaron los DCs?. En entornos donde el número de DCs es muy elevado, el hecho de verificar el estado de la replicación se puede convertir en una tediosa tarea que debería realizarse diariamente. Para ayudarnos, utilizaremos la herramienta repadmin disponible en las Support Tools de Windows 2003.
El comando a ejecutar para determinar el estado de la replicación de AD es:
repadmin /replsummary /bysrc /bydest /sort:delta
La salida queda dividida en dos tablas:
- Cada DC cuando es origen de replicación – tabla Source
- Cada DC cuando es destino de replicación – tabla Destination
También podremos encontrar los DCs que no pudieron ser contactados en la parte final.
La columna Largest Delta muestra el máximo tiempo sin replicar satisfactoriamente alguna partición (naming context) entre todos los partners de replicación de un controlador de dominio particular. Las tablas se encuentran ordenadas por esta columna de mayor a menor. La columna Total muestra el número de enlaces de replicación (1 por DC por naming context) y la columna Fails (fallos) muestra el número de enlaces que han reportado error y el tipo del mismo.
Un ejemplo de la salida mencionada se encuentra en la siguiente tabla:
La salida de repdmin /showrepl nos muestra que el equipo HALEDC02 está replicando correctamente las particiones indicadas con su partner de replicación, HALEDC01 y no así con GUPTADC01.
La ultima replicación correcta para HALEDC01, tuvo lugar a las 8:56:57 del día 1 de Diciembre de 2009 para la partición de Schema y a las 9:43.21 del mismo día para la partición del dominio haledomain.com.
Entendemos que este resultado es lógico para el resto de particiones ya que al encontrarse todos los DCs en el mismo Site donde la replicación de AD funciona mediante notificaciones cuando se realiza un cambio para que la sincronización sea prácticamente inmediata. En caso de no existir ningún cambio en la partición la replicación respetará el intervalo configurado en el Site para la misma, por defecto una hora.
Sin embargo, la replicación con el partner GPTADC01 no está funcionando adecuadamente. En la salida se observa que la última replicación satisfactoria tuvo lugar el día 30 de Noviembre de 2009 a las 11:06:32 Posteriormente todos los intentos de replicación (574 intentos) han fallado con el error 1722 (RPC Unavailable).
El ejemplo de la salida mencionada se encuentra en la siguiente tabla:
Espero que esta información os sirva para monitorizar regularmente la replicación de vuestros DCs y para detectar problemas existentes antes de que sea tarde.
Yolanda Muñoz Muñoz
Hola
Queremos esta vez hacer referencia a un post creado por nuestros compañeros del grupo de soporte de Latinoamérica comentando un problema que están experimentando varios de nuestros clientes.
Tras la instalación del KB973917 el Internet Information Server deja de responder porque la versión de la DLL iisutil.dll no corresponde a la versión incluida en Windows 2003 SP2
Leer el artículo ya que está muy detallado:
IIS 6 puede dejar de responder después de instalar la actualización KB 973917
http://blogs.technet.com/latam/archive/2009/12/11/iis-6-puede-dejar-de-responder-despu-s-de-instalar-la-actualizaci-n-kb-973917.aspx
Gracias a nuestros compañeros de LATAM
Saludos
Gastón Gardonio
Hola a todos,
En algunas ocasiones recibimos preguntas sobre cómo realizar la exportación (y posterior importación) de una zona no integrada en Directorio Activo de nuestros servidores DNS.
A continuación os detallamos un sencillo procedimiento para llevar a cabo esta tarea:
Backup de la zona
- Hacer un backup del fichero zona.dns (ubicado en %windir%\system32\dns ) correspondiente a la zona que queremos exportar.
- Hacer una copia de la rama del registro correspondiente a la zona en:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\DNS Server\Zones\Zona
Recuperación de la zona
- Paramos el servicio DNS Server en el servidor.
- Restaurar la clave de registro. (Con esto se creará la zona de nuevo )
- Copiar manualmente el fichero zona.dns otra vez en %windir%\system32\dns
- Arrancar el servicio DNS Server de nuevo.
Información adicional relacionada con el tema
280061 - How to move Windows 2000 DNS zones to another Windows 2000-based server
Esperamos que esta información os haya sido útil.
Un saludo,
Javier Rama.
Hola a todos.
Como bien sabéis en Julio del 2010 se termina el soporte extendido para Windows 2000, por lo que seria conveniente migrar las plataformas que aun tengan este sistema a otro con soporte, pero, existe algún sitio donde se nos pueda guiar-ayudar en este proceso.
Pues sí, se ha creado una web donde se trata este tema ampliamente y se da acceso a recursos que ayudan durante el proceso, guías, etc, estructuradas en temas según se trate de plataforma servidora, cliente, redes o compatibilidad con aplicaciones.
Para poder consultarla podéis dirigiros a este link (esta en ingles es la única pega):
http://support-preview.partners.extranet.microsoft.com/default.aspx?scid=gp;en-us;gp_win2keol_master#tab4
Creo que esta recopilación de información será de gran ayuda para todos los que tengan que enfrentarse a esta migración.
Un saludo.
Consulta con el Soporte de Windows.
Hola a todos,
En alguna ocasiones necesitamos actualizar un equipo y esta tarea se nos complica al tener que buscar los parches que existen publicados para una tecnología concreta.
Tenemos Windows Update, pero puede ser complicado diferenciar que parches aplican a una tecnología u otra y no permite ver los fixes publicados, ante esta situación localicé, para uno de nuestros casos, una web de Technet que contiene las ultimas actualizaciones que hemos publicado respecto a Hyper-V.
En ella viene detallado el artículo, si esta en Windows Update o solo como Fix, y para que entorno aplica cada uno, todo esto en un cuadro, lo que simplifica mucho esta tarea.
Lo tenéis en: http://technet.microsoft.com/en-us/library/dd430893(WS.10).aspx
Espero que os resulte de utilidad.
Consulta con el equipo de Windows.
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:
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
- 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
