Consulta con el equipo de Windows : Troubleshooting

En Julio 2010 termina el soporte de W2000, ¿cómo podemos migrar?

esplat — Tue, 01 Dec 2009 13:41:45 GMT

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.

¿Donde encuentro una lista de parches para Hyper-V?

esplat — Tue, 01 Dec 2009 09:21:33 GMT

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.

KB976246 El borrado de un VHD en SCVMM 2008 R2 borra el fichero del servidor de Hyper-V

esplat — Mon, 30 Nov 2009 14:24:20 GMT

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.

¿Por qué cuando un usuario se conecta a un servidor de Terminal Server el servidor de licencias registra un evento 4105 en el visor de sistema?

esplat — Wed, 25 Nov 2009 11:09:00 GMT

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

Monitorizando el tipo de consultas LDAP que llegan a nuestros DCs

esplat — Tue, 11 Aug 2009 23:25:00 GMT

Hola de nuevo. Volvemos a la “carga” con LDAP. Hoy vamos a hablar sobre cómo obtener un logging detallado de las consultas LDAP llevadas a cabo por un controlador de dominio. Esto puede resultarnos útil a la hora de comprobar el tipo de consultas LDAP que se efectúan, comprobar si están optimizadas en cuanto a objetos recorridos, etc.

Para qué nos sirve

Los datos obtenidos pueden ayudarnos a determinar, por ejemplo, si hay un cliente que está efectuando muchas consultas y que, en principio, no debería estar realizando, lo que puede indicar la presencia de alguna aplicación no deseada.

También puede ayudarnos a determinar si es necesario indexar algún atributo concreto para optimizar un tipo de búsqueda concreta que se realiza de forma frecuente y con un filtro que utiliza un atributo específico no indexado (lo que provoca recorrer innecesariamente múltiples objetos por cada búsqueda).

Es posible que estemos realizando la búsqueda en un scope o ámbito muy amplio y con un DN base muy general cuando podemos restringirla a una OU concreta y no a todo el sub-árbol del dominio: si buscamos usuarios de una oficina concreta que cumplen un requisito y sabemos que todos los usuarios de dicha oficina están en una OU específica, deberíamos utilizar dicha OU como DN base de la búsqueda y no todo el dominio.

Este logging de las consultas LDAP se realiza en el visor de sucesos en forma de eventos. Los eventos generados proporcionan, además de los datos del cliente y la propia consulta, información adicional como el tiempo empleado en las queries LDAP y los objetos recorridos.

Para leer información sobre cómo funcionan las búsquedas LDAP: How Active Directory Searches Work

Cómo configurar este nivel de logging

Para conseguir este nivel de logging, en los DCs hay que hacer varias modificaciones en el registro para:

Definir lo que consideramos una búsqueda LDAP costosa/ineficiente
Habilitar el log de eventos de diagnóstico de Directorio Activo para Field Engineering

En primer lugar hay que definir los límites a partir de los cuales se considera que una consulta es costosa/ineficiente. Estos límites se especifican en términos de objetos recorridos, y sólo se registrarán eventos que superen estos límites.

Una búsqueda costosa es aquella que visita un alto número de objetos. La eficiencia de una búsqueda se mide comparando el número de registros devueltos con respecto al número de registros visitados. Es decir, si la búsqueda devuelve 300 objetos después de recorrer 300 objetos, entonces estamos ante una búsqueda eficiente.

Los límites se especifican con creando o modificando los siguientes valores de la clave de registro que se proporciona a continuación (si se desea que se muestren todas las consultas LDAP, el valor de ambos límites deberá ser 1, aunque esto puede suponer un incremento no deseado de la carga de CPU del DC):

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters

Valor: Expensive Search Results Threshold

Tipo: DWORD

Datos: 10000 (Valor por defecto)

Valor: Inefficient Search Results Threshold

Tipo: DWORD

Datos: 1000 (Valor por defecto)

Con estos valores por defecto, una búsqueda se considerará costosa si el DC recorre más de 10000 objetos (Expensive Search Results Threshold). Una búsqueda se considerará ineficiente si recorre más de 1000 objetos (Inefficient Search Results Threshold) y se devuelve como resultado menos de un 10% de los objetos visitados.

Los valores de Expensive e Inefficient Search Results Threshold son valores subjetivos, por lo que habrá que adecuarlos al entorno y al tipo de consultas que se efectúen en los DCs.

Se puede encontrar más información sobre estos valores en el siguiente enlace:

Creating More Efficient Microsoft Active Directory-Enabled Applications

Hasta aquí ya hemos determinado nuestros valores límite de lo que consideramos una búsqueda costosa o ineficiente. Sin embargo, esto no es suficiente para generar los eventos.

Los eventos de log de actividad LDAP se generan en el visor de sucesos de Directorio Activo en la categoría de Field Engineering. Por lo tanto, tendremos que activar el log de diagnóstico de esta categoría en los DCs en los que queramos monitorizar la actividad LDAP.

Para ello es necesario modificar el siguiente valor de la clave de registro que se muestra a continuación:

HKLM\system\CCS\Services\NTDS\Diagnostics

Valor: 15 Field Engineering

Datos: 5

Nota: Para que los valores sean efectivos no es necesario reiniciar el DC en el que se modifiquen

A partir de dicho momento, por cada query LDAP costosa/ineficiente aparecerá en el Visor de Sucesos de Directory Services un evento 1644 de categoría Field Engineering con la información de la búsqueda, tipo, filtro, ámbito de búsqueda (scope), entradas recorridas, entradas encontradas, etc.:

Event Type: Information

Event Source: NTDS General

Event Category: Field Engineering

Event ID: 1644

Description:

Internal event: A client issued a search operation with the following options.

Client:

127.0.0.1

Starting node:

DC=dominio,DC=com

Filter:

(objectClass=computer)

Search scope:

subtree

Attribute selection:

[types_only]

Server controls:

Visited entries:

3448

Returned entries:

Otro tipo de log de diagnóstico que puede resultar útil es el siguiente, que nos permite obtener información sobre el tiempo empleado en las búsquedas:

Valor: 16 LDAP Interface Events

Datos: 3

Después de habilitarlo obtendremos un evento 1139 de LDAP Interface indicando el tiempo que ha costado realizar cada búsqueda:

Event Type:          Information

Event Source:      NTDS LDAP

Event Category:   LDAP Interface

Event ID:               1139

Description:
Internal event: Function ldap_search completed with an elapsed time of 30 ms.

Para revisar los eventos generados por los DCs y obtener, por ejemplo, todos los eventos con ID 1644 y fuente NTDS General de todos los DCs que estemos monitorizando, podemos usar una herramienta como EventCombMT. La herramienta EventCombMT se puede descargar desde el siguiente enlace:

También es recomendable que aumentemos el tamaño del log de Directory Services, ya que se van a generar varios eventos por cada consulta LDAP registrada, lo que podría provocar que dicho visor de sucesos llegara a su tamaño máximo.

Hasta la próxima.

Paula Tomás Galed

Analizando el rendimiento de un equipo con PAL

esplat — Mon, 03 Aug 2009 12:56:00 GMT

Hola nuevamente!

Todos sabemos que para diagnosticar problemas de performance en un servidor debemos configurar contadores de performance de los objetos que deseamos analizar.

Ahora bien, ¿Quién sabe leer toda la información que se genera con el performance monitor?

Solemos tener mucha cantidad de información, muchos contadores, mucha interacción entre ellos y muchas veces se hace imposible lograr una idea de lo que está sucediendo.

Para solucionar este problema contamos con la herramienta llamada PAL.

Esta herramienta de uso libre y gratuito genera reportes gráficos y muy detallados del rendimiento de un servidor.

También analiza rendimiento de Microsoft Exchange, SQL Server y Biztalk Server, entre otros.

Una vez que utilicéis dicha herramienta llegará un momento donde os toparéis con un problema. Sólo funciona cuando los contadores están en inglés.

Para ello se desarrolló una herramienta que realiza la traducción de los logs del Español al Inglés y así ser capaces de poder utilizar el PAL sobre dicho log.

Esta herramienta de traducción puede ser descargada desde aquí.

¿Cómo utilizarla?

Ejecutar el fichero PLT.exe
Seleccionar el log de performance en Español.
Dejar seleccionado como idioma Español.
Dejar el Encoding en Default
El CultureInfo es el local de tu máquina. (Si tienes el sistema en inglés deja en-US)
Por último Execute!
Como resultado tendremos un nuevo fichero _PLT el cual podremos analizar con el PAL

Espero que les sea de utilidad.

Hasta la próxima

Gastón Gardonio

¿Como ejecuto mis antiguas aplicaciones en las nuevas plataformas?

esplat — Fri, 22 May 2009 12:31:00 GMT

Hola a tod@s,

Ante la continua aparición de nuevos sistemas operativos y service packs, en los entornos grandes y heterogéneos (no hace falta que sean gigantes, creo que muchos administradores tienen maquinas con W2K, XP, Vista en el mismo entorno) y la prevista a aparición en breve de Windows 7 (se puede descargar la versión Release Candidate Download W7 RC ) hace que las aplicaciones que tenemos instaladas no siempre se puedan mover de una plataforma a otra con facilidad debido a cambios en la arquitectura, diseño, ...

Esto supone cambios en el desarrollo de la aplicación, testear la aplicación o ejecutarla en modo de compatibilidad con lo que esto supone para un entorno de producción o una aplicación desplegada a un gran numero de usuarios.

Para facilitar la gestión del sistema en estos casos tenemos una aplicación dentro de Microsoft Desktop Optimization Pack MDOP llamada MED-V (Microsoft Enterprise Desktop Virtualization) que permite la ejecución de aplicaciones legacy en los nuevos sistemas desplegados en los que es incompatible su ejecución.

La información sobre esta herramienta se puede revisar en:

http://www.microsoft.com/windows/enterprise/products/med-v.aspx

Announcing MDOP 2009 to include MED-V 1.0, App-V 4.5 CU1 and AIS 1.5 Updates

Aquí podéis descargar los manuales y white papers sobre su funcionamiento y empleo.

Básicamente esta herramienta lo que crea es una maquina virtual, en la maquina con un SO incompatible con la aplicación, que permite que la aplicación se ejecute en una plataforma virtual para la que es compatible (W2000, XP), independientemente del SO que esta albergando el cliente Med-V.

El producto esta creado de forma que, en caso de configurarse de este modo, para el usuario es transparente la existencia de una maquina virtual, y los programas se publican en menú inicio como cualquier aplicación local.

La administración se realiza de forma centralizada, mediante una consola de administración y, como casi todas las soluciones de MDOP, tiene un repositorio central para ficheros (en este caso imágenes de maquinas virtuales), una consola de administración y una base de datos para generar reportes y albergar los eventos generados. Se puede controlar mediante políticas y plantillas de seguridad, por lo que resulta sencilla de administrar, mantener y actualizar las imágenes.

Permite varias formas de distribución (incluido a través de DVD de forma que no se precisa trafico de red para su despliegue), solo precisa conexión de red la primera vez que se conecta (esto es configurable permitiendo establecer periodos de reconexión para actualizar seguridad o las imágenes desplegadas).

Una vez desplegado, para el mantenimiento de las maquinas virtuales, emplea Trim Transfer, de forma que solo se transfieren los bloques de datos actualizados, no precisando la descarga de la imagen completa.

Espero haberos dado a conocer una herramienta que simplifique las tareas de administración, ya solo queda que la probéis y comprobéis su utilidad en vuestros entornos.

Un saludo.

Raúl del Moral.

Consulta con el equipo de Windows.

Logs que utiliza System Center Configuration Manager 2007

esplat — Wed, 20 May 2009 10:49:00 GMT

Hola!

El objetivo de este post es ayudarles a ustedes a saber que logs buscar para resolver problemas en SCCM 2007.

Les adjunto un documento donde se detallan todos los principales componentes de SCCM y todos los logs que ellos poseen.

Este documento les será de utilidad para saber que logs mirar cuando falla un componente en especial y así evitar controlar logs que no tienen que ver con el componente en sí.

Recordad que estamos siempre abiertos a cualquier solicitud de su parte, acérquenos sus consultas e intentaremos escribir material para resolverlas.

Saludos

Gastón Gardonio

Modificar nivel de log en APP-V Softgrid Server

esplat — Thu, 07 May 2009 14:50:44 GMT

Hola a todos.

Hemos tenido algunos casos sobre virtualización de aplicaciones y uno de los pasos a tener siempre en cuenta es la modificación del nivel del log que genera el servidor.

El log es generado por defecto en el servidor y se puede localizar en el fichero sft-server.log file de C:\Program Files\Microsoft System Center App Virt Management Server\App Virt Management Server\logs\ (en alguna versión puede variar esta ruta)

Con el método que adjunto bastara con reiniciar el servicio de Softgrid para que vuelva al nivel normal de log tras finalizar la reproducción de la situación a analizar.

Niveles de log disponible (ve de menos a mas intenso, generando mayor numero de datos):

1. Transactions

2. Fatal Errors

3. Errors (Default)

4. Informational

5. Debug (Verbose)

6. Trace

Para cambiar en nivel de log:

1. Desde las propiedades de App-V Server service:

2. Ir a las propiedades de App-V Server service.

3. Parar el servicio.

4. En los parámetros de inicio añadir -d X (X es el nivel deseado de log).

5. Arrancar el servicio desde la ventana de propiedades del servicio App-V Server.

Si el servicio es reiniciado desde fuera de la ventana de propiedades del servicio o el servidor es reiniciado, los parámetros de inicio son automáticamente limpiados y el nivel de log vuelva a su valor por defecto (3 Errores)

Un saludo.

Raúl del Moral

Técnico de soporte Windows.

Fechas del ciclo de soporte de W2K3 SP1

esplat — Mon, 13 Apr 2009 18:36:18 GMT

Hola a todos.

Mañana 14 de abril de 2009 dejará de tener soporte la versiones de Windows 2003 con Service Pack 1.

Mañana hará 24 meses en el que el Service Pack 2 de Windows 2003 está disponible para ser descargado. Las políticas del ciclo de vida de los service packs detallan cada cuanto tiempo los productos quedan fuera del soporte.

Lifecycle Supported Service Packs

http://support.microsoft.com/default.aspx?scid=fh;%5bln%5d;lifesupsps

Producto:	Disponible desde:	Service Pack queda sin Soporte:
Windows Server 2003 Service Pack 0 (RTM)	28-May-2003	10-Apr-2007
Windows Server 2003 Service Pack 1	30-Mar-2005	14-Apr-2009
Windows Server 2003 Service Pack 2	13-Mar-2007	24 meses luego del próximo SP*

*Son 24 meses luego del próximo service pack o del fin del ciclo de vida del producto. Puedes obtener más información en el siguiente enlace:

http://support.microsoft.com/lifecycle/default.aspx#service%20pack%20support

Últimamente hemos recibido varios casos donde los equipos todavía seguían el Windows 2003 con Service Pack 1. A todos ellos le hemos comentado que dichos equipos iban a quedar fuera de soporte y de todos ellos han surgido diferentes dudas.

Que sucede si tengo un problema con el equipo y este posee el Service Pack 1?

Lamentablemente el equipo de soporte de Microsoft no va a poder prestar soporte a dicho equipo hasta que el mismo este dentro de soporte.

Microsoft tiene a disposición de todos la descarga del Windows 2003 Service Pack 2 desde el siguiente link:

http://technet.microsoft.com/en-us/windowsserver/bb229701.aspx

Cuál es la mejor alternativa para instalar o distribuir el Service Pack 2?

Existen diferentes alternativas para instalar el Service Pack 2. Dependiendo de su entorno puede optar por las siguientes:

Directamente desde Windows Update http://windowsupdate.microsoft.com/

Utilizando WSUS

Utilizando SMS http://support.microsoft.com/kb/926030

Que precauciones tengo que tener a la hora de instalar el Service Pack 2?

En la siguiente pagina podrán obtener las recomendaciones que deben tener para instalar el Service Pack 2.

http://technet.microsoft.com/en-us/library/cc755981.aspx

Que problemas puedo llegar a tener luego de instalar el Service Pack 2?

No podemos decir a ciencia cierta que problemas puede llegar a tener si actualiza su equipo a Service Pack 2. Microsoft recomienda que luego de actualizar su equipo a Service Pack 2, actualice el mismo también con todos los parches de seguridad y de actualizaciones disponibles.

También tenga en cuenta que sus controladores de terceros pueden no ser compatibles con Windows 2003 Service Pack 2, por lo cual le recomendamos estar en contacto con su proveedor y actualizar los controladores a la versión que el mismo le indique.

Saludos

Gastón Gardonio

Introducción a la solución de problemas de WMI

esplat — Sun, 12 Apr 2009 22:34:00 GMT

Últimamente en nuestro equipo de soporte hemos estado recibiendo muchas consultas y problemas relacionados con WMI. Dado que este componente está siendo utilizado últimamente por varias aplicaciones y cada vez lo será más, creo que va a ser de mucha utilidad para todos la siguiente serie de posts que les presento.

Estarán divididos dado que es mucho material para un solo post.

Cubriremos:

Arquitectura Básica de WMI

Accediendo al repositorio WMI

Pasos Básicos de Troubleshoot de WMI

Troubleshoot de Problemas de Performance de WMI

Hoy comenzaremos con los aspectos básicos de la arquitectura de WMI

Que es el WMI? WMI es un sistema basado en el standard Web-based Enterprise Management (WBEM). Con el podemos acceder a gran cantidad de información almacenada en nuestro sistema operativo Windows. Este acceso a esta información puede ser realizado mediante scripts, .Net (clase system.management) o por líneas de comando.

Podemos dividir la arquitectura de WMI de la siguiente forma:

Como vemos en el punto 2, la estructura de WMI está dividida en 2, el servicio de WMI (winmgmt) y el Repositorio.

El repositorio usa namespace que contienen a su vez sub-namespaces y estos están ordenados en una jerarquía de objetos. Las aplicaciones se conectan primero a un namespace y luego a través de ese namespace puede acceder a los objetos.

El comienzo de estos namespace esta dado desde ROOT/ Luego al iniciar el servicio de WMI se crean namespaces como ROOT/DEFAULT ROOT/CIMV2 . Como vemos en el grafico, el servicio de WMI es el intermediario entre los Providers, las aplicaciones y el repositorio.

Este repositorio aloja información estática de objetos como las clases definidas por los objetos y toda esta información obtenida de los providers cuando el cliente lo requiere.

Un Provider es un objeto COM que controla los objetos de WMI. Este objeto es un componente que puede ser un disco rigido, una tarjeta de red o un servicio. El Provider entrega al WMI la información sobre el objeto y controla los mensajes de los mismos.

Los Providers son una DLL y un fichero Managed Object Format (MOF) que define las clases para el Provider. Los Providers son clasificados por el WMI de acuerdo a lo que realiza el provider.

Clasificaciones	Descripción
Clase	Puede entregar, modificar, eliminar y listar una clase especifica. También soporta las queries realizadas. Por ejemplo el Directorio Activo es un ejemplo de un servicio que también entrega clases.
Instancia	Puede entregar, modificar, eliminar y listar una instancia especifica. Una instancia representa a un objeto. También soporta que se le realicen queries.
Propiedad	Puede entregar y modificar los valores de las propiedades de los objetos.
Metodo	Métodos específicos para clases de un provider.
Evento	Genera eventos de notificaciones.
“Event Consumer”	Crea una relación entre el objeto físico y el objeto lógico para poder crear la notificaciones de eventos.

Por último, debemos hablar de Common Information Model (CIM) y de los ficheros Managed Object Format (MOF).

CIM es un modelo para lenguajes orientados a objetos como C++ y Java. Los desarrolladores de WMI escriben sus clases en lenguaje MOF, una vez que estas clases están estructuradas en MOF, los desarrolladores pueden dar definiciones a las clases.

Esto se hace compilando un fichero MOF en un binario (BMF) e introduciéndola dentro del Windows Driver Model (WDM).

Los Providers se pueden compilar también en MOF y utilizar las APIs de WMI COM para crear la estructura de WMI con sus definiciones.

Finalmente, los Providers pueden usar un compilador MOF (mofcomp.exe) para agregar las clases al repositorio WMI.

Nos vemos en el próximo post

Saludos

Gastón Gardonio

TAGs: WMI arquitectura, basico, providers

Replicación de drivers de impresora en un clúster Windows 2003

esplat — Wed, 04 Feb 2009 18:42:06 GMT

Replicación de drivers de impresora en un clúster Windows 2003

En Windows Server 2003, los drivers de impresora en un servidor de impresión en clúster son almacenados en un disco compartido y replicados a todos los nodos del clúster. Los drivers son guardados en un directorio bajo el raíz del disco compartido del cual el servicio spooler o cola de impresión depende, llamado PrinterDrivers

Nota Este nombre de carpeta no podrá ser cambiado aunque haya una propiedad privada de recurso que de pie a ello.

Cuando un driver de impresora es actualizado, es establecido el valor TimeStamp en el registro al sello de fecha y hora incluidas en el driver. Cuando el recurso spooler o cola de impresión su estado pasa a Online, él comprueba este valor bajo la siguiente rama del registro:

HKLM\Cluster\Resources\%GUID%\Parameters\Environments\Windows NT x86\Drivers\Version-3\%DriverName%\TimeStamp

Y lo compara con el valor:

HKLM\Software\Microsoft\Windows NT\CurrentVersion\Print\Cluster\%GUID%\Windows NT x86\Version-3\%DriverName%\TimeStamp

Nota %GUID% corresponde al identificador en el registro del recurso spooler o cola de impresión

Si él encuentra que la versión bajo la primera rama es mas nuevo que el de la segunda, el driver actualizado es descargado desde el disco compartido al disco del sistema operativo del nodo.

Se comprueba driver por driver, y si hay alguna diferencia de versión, son descargados desde la carpeta o directorio \PrinterDrivers del disco compartido a la siguiente ruta local del nodo %SystemRoot%\System32\Spool\ResourceGUID\Drivers, donde ResourceGUID es el identificador único global (GUID) que representa al recurso spooler o cola de impresión. Estos drivers son mantenidos aparte de cualquier driver instalado en el nodo o de otro recurso spooler en configuraciones activo/activo.

Imagen 1: Directorio con el GUID del recurso spooler

En un servidor de impresión no en clúster, los drivers para cada sistema operativo son almacenados en directorios diferentes. Una simple impresora puede tener diferentes drivers cargados y cada uno de estos está almacenado en una carpeta diferente bajo Drivers. El Cluster mantiene las mismas convenciones en la separación de drivers bajo cada carpeta GUID de cada recurso de spooler o cola de impresión.

La replicación de todos los drivers puede incrementar el tiempo que a un recurso spooler o cola de impresión pasar su estado a online, porque cuando un driver es actualizado, el spooler debe comprobar la lista de todas las impresoras pare ver cuáles son las impresoras afectadas (y ver si usa algún archivo actualizado) y si así fuera, decir a la impresora que actualice su información de driver. No se pasara el estado del recurso spooler o cola de impresión a Online hasta que esta comprobación y actualización este completa. Este retraso no afectara a otros nodos hasta que el recurso spooler se ponga online por primera vez en ellos. Cuando tu agregas un gran número de colas de impresión y drivers de una vez, es altamente recomendado que después de haberlas añadido, muevas el recurso spooler o cola de impresión a cada uno de los nodos en el clúster. Esto necesita ser hecho solo una vez, y cuando el recurso es puesto online ocurrirá la replicación de los driver. Esto asegura que todos los nodos tienen los drivers más actuales. El tiempo de failover será menor después que la que mayoría de los drivers estén replicados para las siguientes impresoras que añadas.

El spooler y otras aplicaciones no deberían copiar drivers de impresora directamente al disco compartido, porque si se produjese un failover el proceso de carga de drivers obtendría un error de E/S. Esto es el por qué los drivers son descargados y mantenidos en cada uno de los nodos localmente. Cuando se accede a un driver, se usa rutas UNC (\\%VirtualServer%\print$\%GUID%) en vez de la ruta local al driver (%SystemRoot%\System32\spool\Driver).

El sitio de Windows Update es seguro usarlo en los clúster. Si es usado el actualizara los drivers en el nodo local y también en los servidores virtuales, pero para poder hacerlo el recurso spooler debe estar online en el nodo donde se está usando Windows Update.

A la hora de borrar un recurso cuando un nodo está offline, la próxima vez que el nodo este online borrara la carpeta GUID del nodo local.

Cuando borras un recurso spooler, ocurren dos cosas:

La carpeta GUID es borrada del nodo local (o marcada para borrar en el reinicio si los archivos de un driver están en uso).
La carpeta PrinterDrivers es borrada del disco compartido.

El resto de los nodos (sin hacer caso si están online u offline) llevaran a cabo una limpieza cuando el Servicio de clúster inicie (ya que había una marca para borrado porque los archivos del driver estaban en uso). Esto es debido a cuando un recurso es borrado el servicio de clúster solo notifica a la DLL de recursos en el nodo donde el recurso está siendo borrado.

Una cosa a tener en cuenta a la par de la replicación de los drivers entre los discos compartidos y los nodos es la información que se pasan los nodos a través de la rama CLUSTER del registro. A veces debemos ser cuidadosos a la hora de agregar muchas impresoras y tenemos configurado un reseteo del log de quórum cada pocos KB. En un movimiento o failover puede perderse información relacionada con colas de impresión si es muy bajo el valor.

Para incrementarlo sigue estos pasos:

Abrir la consola de administración de clúster (CluAdmin.exe).
Clic con el botón derecho sobre el nombre de clúster en la parte superior izquierda, y luego Propiedades.
Clic en el tabulador de Quorum.
En la caja Reset quorum log at, teclear un valor mayor que el tamaño del archive CLUSDB en el carpeta \windows\cluster.

Nota Introducir un valor múltiplo de 64. Por ejemplo, 5120 o 8192.

Nota Este valor es global y solo necesita cambiarse en un nodo. El servicio de clúster llevara este cambio al resto de nodos y el cambio es dinámico no es necesario reiniciar el servicio de clúster.

Troubleshooting (solucionando problemas)

Directorio o carpeta del driver corrupta

Cuando una carpeta de un driver esta corrupta, cualquier impresora cuyo driver este corrupto no imprimirá. Puedes encontrar en alguna situación que una impresora en un nodo puede imprimir correctamente, pero desde otro nodo por la misma impresora no es posible. Esto puede ser debido a un driver corrupto o faltan archivos del driver en el nodo. Para corregir esto tú puedes manualmente forzar el borrado de todos los drivers del nodo y luego llevar a cabo una replicación completa desde el nodo que no tiene problemas.

Ya que el Servicio de clúster comprueba si las versiones coinciden en el failover, sería raro que en un failover el recurso spooler no propagara los drivers correctos al otro nodo..

Si la carpeta GUID en uno de los nodos esta corrupta puedes hacer una de estas cosas:

Restaurarla de un backup
Quitar y volver añadir el nodo problemático de la lista de la caja Possible Owners para recrear los drivers.

Con esta última opción el servicio de clúster copiara los drivers del disco compartido al disco local del nodo:

Abrir el administrador de cluster, y mover el grupo que contiene el spooler al nodo que sospechamos que no tiene los drivers corruptos.
Clic con el botón derecho en el recurso del spooler o cola de impression y luego Take Offline.
Doble clic en el recurso Spooler, y luego clic en Modify bajo Possible Owners.
Mover el nodo que sospechas que tiene el problema a la lista Available Nodes, y luego clic en OK.
Clic en Apply.
Clic en Modify bajo Possible Owners, y luego mueve de vuelta el nodo problemático a la lista Possible Owners.
Clic en OK, y luego clic en OK.
Mover el grupo que contine el recurso spooler al nodo problematico.
Clic con el derecho sobre el recurso Spooler, y luego en Bring Online.

Esto causara que el recurso Spooler recree los drivers en el nodo local. Los driver viejos pueden ser movidos dentro de una carpeta llamada old dependiendo si pueden ser borrados o no. Si los driver en el nodo problemático todavía parecen estar corruptos, reinicia el nodo después de que lo hayas quitado de Possible Owners. Cuando tú hagas esto, cualquier driver que tuvieran handles abiertos serán cerrados. Normalmente este paso no es necesario.

Nosotros recomendamos que uses drivers de nivel 3 en pro de la estabilidad del clúster. Evita los de nivel 2 o de modo núcleo. Ellos pueden causar un stop e inestabilidad en el sistema.

Carpeta PrinterDrivers esta corrupta o le faltan archivos

Si por cualquier razón, la carpeta \PrinterDrivers en el disco compartido se pierde o la información que contiene se daña o se borra, tu puedes usar uno de los siguientes métodos para recuperarla:

· Restaurar de un backup.

· Copiar desde la carpeta %SystemRoot%\System32\Spool\SpoolerResource GUID a %SharedSpoolerDisk% y renombrar SpoolerResource GUID a PrinterDrivers.

· Reinstalar las impresoras (la carpeta PrinterDrivers es recreada cuando un driver es instalado).

Failover clustering Windows 2008 – registro

esplat — Mon, 02 Feb 2009 18:32:00 GMT

Como ya hemos hablado otras veces, con 2008 se he realizado un rediseño del antiguo clúster MSCS que utilizábamos en versiones anteriores de Windows.

De entre todos los cambios introducidos hoy nos centraremos en el registro.

HKLM\Cluster

También conocida como “Cluster hive”, continua siendo la clave principal dentro del registro, almacenando información sobre la configuración del clúster. Residente en todos los nodos del clúster es también replicada al disco de witness en caso de haberse definido.

Las claves modificadas son:

HKLM\Cluster

HKLM\Cluster\Checkpoints

HKLM\Cluster\Dependencies

HKLM\Cluster\Groups

HKLM\Cluster\Networks

HKLM\Cluster\Nodes

HKLM\Cluster\Quorum

HKLM\Cluster\ResourceTypes

HKLM\System\CCS\Services\clusdisk

HKLM\System\CCS\Services\ClusSvc

HKLM\System\CCS\Services\Netft

A continuación adjunto el acceso al documento con toda la información, pantallazos y ejemplos de configuración.

Espero que os resulte de utilidad.

Un saludo, Paloma García

Técnico de Soporte Microsoft Premier

Windows 2008 – evento 49

esplat — Fri, 30 Jan 2009 15:16:01 GMT

Con Windows 2008, aparece un nuevo evento que nos avisa de que el archivo de paginación no tienen el tamaño suficiente como para que se genere un fichero de dump en caso de crash del sistema.

Event ID: 49

Source: volmgr

Level: Error

Description: Configuring the Page File for crash dump failed. Make sure there is a page file on the boot partition and that is large enough to contain all physical memory.

Si os encontráis con este evento lo primero es revisar que el tamaño del archivo de paginación para asegurarnos que su tamaño es de al menos el tamaño de la memoria +50 Mb.

Si a pesar de esto sigue apareciendo el evento, es posible que nos encontremos ante un problema con el componente Crashdmp.sys. reportado en el articulo siguiente.

950858 Dedicated dump files are unexpectedly truncated to 4 GB on a computer that is running Windows Server 2008 or Windows Vista and that has more than 4 GB of physical memory

http://support.microsoft.com/default.aspx?scid=kb;EN-US;950858

Un saludo, Paloma García

Técnico de Soporte Microsoft Premier

Directorio Activo, RPC, puertos efímeros y firewalls

esplat — Fri, 28 Nov 2008 00:51:00 GMT

Hola de nuevo. Soy Paula del equipo de Directorio Activo.

Hoy hablaremos sobre el funcionamiento básico de RPC que afecta a diferentes operaciones de Directorio Activo. Como seguramente la mayor parte de vosotros ya sabe, la comunicación utilizada para múltiples operaciones en Directorio Activo es RPC. Estas operaciones incluyen, por ejemplo, la replicación de DA, la replicación FRS, la promoción de un nuevo Controlador de Dominio, etc. También realizan conexiones RPC a los DCs la ejecución del comando dcdiag /v o incluso consultar qué DCs son los maestros de operaciones (mediante el comando netdom query fsmo). También es muy común que tratemos casos con problemas de conectividad RPC en que la replicación de DA y/o FRS no se lleva a cabo de manera satisfactoria o incluso que la replicación de DA funcione perfectamente pero los Controladores de Domino no puedan replicar SysVol por FRS.

En una comunicación RPC, el cliente se conecta al puerto TCP 135 del servidor y solicita un puerto al End Point Mapper (EPM) para comenzar la conversación RPC. El EPM del servidor reserva un puerto (llamado puerto dinámico) para este cliente y se lo envía. A partir de este punto, el cliente abre una nueva conexión TCP a dicho puerto del servidor y comienza la comunicación.

Los puertos dinámicos RPC (o puertos efímeros) que puede utilizar el EPM de RPC (o RPCSS) van del 1025 hasta el 65535, aunque Windows 2000/XP/2003 por defecto utilizan puertos que están comprendidos en el rango 1025-5000 (en total 3976 puertos). En Windows Vista y Windows Server 2008, el rango de puertos por defecto es 49152-65535 (un total de 16384 puertos).

Puede encontrarse más información en el siguiente artículo (muy recomendable para identificar y entender los pasos a seguir cuando nos encontramos ante un problema con el RPC Endpoint Mapper):

839880 Troubleshooting RPC Endpoint Mapper errors using the Windows Server 2003 Support Tools from the product CD

Cuando no se puede establecer la conexión por estos puertos efímeros, al realizar las operaciones que hemos comentado anteriormente podemos recibir errores como el siguiente:

There are no more endpoints available from the endpoint mapper.

Vamos a ver unas trazas de red de ejemplo de un establecimiento de una comunicación RPC fallida debido a que el cliente no puede establecer la sesión al puerto dinámico que le indica el EPM del servidor.

Las trazas de red las podéis capturar con cualquier sniffer, por ejemplo en este caso nosotros hemos utilizado Microsoft Network Monitor 3.2.

Esta es la conversación inicial RPC entre un DC y una máquina desde la que se ejecuta la operación netdom query fsmo:

Fuente	Destino	Protocolo	Descripción
cliente	dc	TCP	TCP:Flags=......S., SrcPort=1687, DstPort=DCE endpoint resolution(135), PayloadLen=0, Seq=721180773, Ack=0, Win=65535 ( ) = 65535
dc	cliente	TCP	TCP:Flags=...A..S., SrcPort=DCE endpoint resolution(135), DstPort=1687, PayloadLen=0, Seq=3452375582, Ack=721180774, Win=16384 ( Scale factor not supported ) = 16384
cliente	dc	TCP	TCP: [Bad CheckSum]Flags=...A...., SrcPort=1687, DstPort=DCE endpoint resolution(135), PayloadLen=0, Seq=721180774, Ack=3452375583, Win=65535 (scale factor 0x0) = 65535
cliente	dc	MSRPC	MSRPC:c/o Bind: UUID{E1AF8308-5D1F-11C9-91A4-08002B14A0FA} EPT Call=0x1 Assoc Grp=0x0 Xmit=0x16D0 Recv=0x16D0
dc	cliente	MSRPC	MSRPC:c/o Bind Ack: Call=0x1 Assoc Grp=0x14EE2 Xmit=0x16D0 Recv=0x16D0
cliente	dc	EPM	EPM:Request: ept_map: NDR, DRSR {E3514235-4B06-11D1-AB04-00C04FC2DCD2} v4.0, RPC v5, 0.0.0.0:135 (0x87) [DCE endpoint resolution(135)]
dc	cliente	EPM	EPM:Response: ept_map: NDR, DRSR {E3514235-4B06-11D1-AB04-00C04FC2DCD2} v4.0, RPC v5, 10.200.8.59:1025 (0x401) [*1025*]
cliente	dc	TCP	TCP: [Bad CheckSum]Flags=...A...F, SrcPort=1687, DstPort=DCE endpoint resolution(135), PayloadLen=0, Seq=721181002, Ack=3452375795, Win=65323 (scale factor 0x0) = 65323
dc	cliente	TCP	TCP:Flags=...A...., SrcPort=DCE endpoint resolution(135), DstPort=1687, PayloadLen=0, Seq=3452375795, Ack=721181003, Win=65307 (scale factor 0x0) = 65307
dc	cliente	TCP	TCP:Flags=...A...F, SrcPort=DCE endpoint resolution(135), DstPort=1687, PayloadLen=0, Seq=3452375795, Ack=721181003, Win=65307 (scale factor 0x0) = 65307
cliente	dc	TCP	TCP: [Bad CheckSum]Flags=...A...., SrcPort=1687, DstPort=DCE endpoint resolution(135), PayloadLen=0, Seq=721181003, Ack=3452375796, Win=65323 (scale factor 0x0) = 65323

En la respuesta del End Point Mapper (EPM) del DC ante la solicitud de conexión del cliente (trazas en rojo), el DC indica que van a continuar hablando por el puerto TCP 1025. Si filtramos el tráfico generado en el cliente con destino el DC y puerto 1025, vemos los siguientes intentos de conexión al mismo:

Fuente	Destino	Protocolo	Descripción
cliente	dc	TCP	TCP:Flags=......S., SrcPort=1688, DstPort=1025, PayloadLen=0, Seq=570735085, Ack=0, Win=65535 ( ) = 65535
cliente	dc	TCP	TCP:[SynReTransmit #63]Flags=......S., SrcPort=1688, DstPort=1025, PayloadLen=0, Seq=570735085, Ack=0, Win=65535 ( ) = 65535
cliente	dc	TCP	TCP:[SynReTransmit #63]Flags=......S., SrcPort=1688, DstPort=1025, PayloadLen=0, Seq=570735085, Ack=0, Win=65535 ( ) = 65535
cliente	dc	TCP	TCP:[SynReTransmit #63]Flags=......S., SrcPort=1688, DstPort=1025, PayloadLen=0, Seq=570735085, Ack=0, Win=65535 ( ) = 65535

Como podemos ver claramente en las trazas de red, el cliente trata de conectarse varias veces a dicho puerto en el DC y no recibe respuesta (ver retransmisiones). Si observamos unas trazas de red simultáneas a las anteriores pero obtenidas en el DC (capturar el tráfico en ambos extremos es muy recomendable en este tipo de situaciones), únicamente se observa la conversación inicialmente descrita en la primera tabla. Es decir, el DC no llega a recibir los paquetes que el cliente le envía por el puerto 1025.

Lo más probable en este caso es que haya un firewall que esté bloqueando las comunicaciones. Puede ser un firewall hardware/software, el firewall integrado de Windows o incluso un antivirus con funcionalidad de firewall. (Tened también en cuenta que no todos los problemas relacionados con conectividad RPC se deben a la configuración de los firewalls!!!)

Ante esta situación tenemos dos opciones para evitar el bloqueo:

Abrir los puertos comprendidos entre el 1025 y el 5000 en el firewall para permitir la negociación/tráfico RPC entre las máquinas implicadas
Configurar RPC en el DC para utilizar un rango de puertos específicos y abrir dichos puertos en el firewall para permitir la negociación/tráfico RPC entre dichas máquinas

La desventaja que hay que tener en cuenta es la posibilidad de que en determinados momentos no haya puertos disponibles al estar todos en uso, por lo que habrá que realizar pruebas y verificar cuál es el número de puertos adecuado para el entorno. Hay que tener en cuenta que los DCs utilizan RPC para multitud de funcionalidades, como puede ser la replicación de DA o FRS.
El mecanismo para Windows 2000/XP/2003 se define en el siguiente artículo: 154596 How to configure RPC dynamic port allocation to work with firewalls
El artículo anterior también apunta a mecanismos para configurar si se prefiere, por ejemplo, un único puerto concreto para la replicación FRS en lugar de un rango de puertos.
El mecanismo para Windows Vista/2008 se define en el siguiente artículo: 929851 The default dynamic port range for TCP/IP has changed in Windows Vista and in Windows Server 2008

Si queréis obtener una lista completa de los puertos necesarios para el correcto funcionamiento de un entorno de Directorio Activo, echadle un vistazo a los siguientes artículos:

Espero que esta información os sirva de utilidad, ya que es uno de los problemas que tratamos más frecuentemente y su detección es relativamente sencilla a partir de unas trazas de red.

- Paula Tomás Galed