La herramienta oficial de Microsoft diseñada específicamente para desempeñar esta tarea se llama USMT (User State Migration Tool), en castellano Herramienta de Migración del Estado de Usuario. El problema consiste en que dicha herramienta no migra el perfil Outlook del usuario.

Para migrar el perfil Outlook del usuario existen herramientas de terceros de BackRex, ABF, etc. aunque los resultados finales después de usar estas herramientas no son demasiado convincentes por no migrar el perfil por completo.

El modo más sencillo y efectivo para migrar los datos de usuario es el siguiente:

1.       En primer lugar debemos hacer un backup del o de los ficheros PST que tenga el usuario. Para ellos podemos acudir directamente a la carpeta almacén que por defecto se encuentra en C:\Documents and Settings\%USERNAME%\Configuración local\Datos de programa\Microsoft\Outlook o desde el propio Outlook en Archivo->Importar y Exportar.

2.       Lo siguiente sería realizar un backup de la configuración de cuentas, reglas, vistas, etc. Que se almacena en el registro de Windows bajo la siguiente clave: [HKEY_USERS\S-1-5-21-xxxxxxxx-xxxxxxxx-xxxxxxxx-xxxx\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\Outlook desde el editor del registro de Windows exportándola a un fichero.

Después de realizar estos pasos tendremos un backup completo del perfil y el fichero PST del usuario.

Para restaurar el backup completo de Outlook en el equipo destino debemos de proceder de la siguiente manera:

1.       Se restaura la copia del o de los ficheros PST en la ruta que establece Outlook por defecto (C:\Documents and Settings\%USERNAME%\Configuración local\Datos de programa\Microsoft\Outlook) o a la carpeta original en la que se encontraban en el equipo origen.

2.       Debemos de asegurarnos de que el SID del usuario del equipo destino es el mismo que el del equipo origen, como podría ser el caso de un usuario del dominio de Windows. Si el equipo destina no forma parte de un dominio, es muy probable que tengamos que editar el fichero .reg exportado como backup para que el SID del usuario coincida con el del equipo destino haciendo un simple replace con un editor de texto.

Siguiendo estos pasos se habrá restaurado el backup completo en el equipo destino.

Nota: Las contraseñas de las cuentas de correo no pueden ser exportadas.

Según Microsoft, la herramienta Dr. Watson es una herramienta de diagnóstico que recopila información acerca del equipo cuando ocurre un problema en un programa.

Dicho de otra manera, cuándo un programa se cierra inesperadamente Dr. Watson comienza a recopilar información generando una Instantánea (Snapshot). Dichas instantáneas son guardadas en la ruta \Windows\Drwatson para poder ser analizadas posteriormente.

En un principio podría parecer una herramienta inofensiva aunque mi experiencia personal ha sido diferente:

En su día, pude observar que los Contadores de Rendimiento (Performance Counters) de uno de los servidores de Terminal Server mostraba un uso excesivo de CPU durante minutos. Después de analizar el problema buscando el proceso que provocaba esta anomalía observé que el proceso en concreto era dw20.exe. Solamente había una solución a este problema, deshabilitar la herramienta Dr. Watson:

DESHABILITAR LA HERRAMIENTA DR. WATSON

Para deshabilitar el proceso solamente hay que eliminar la entrada de registro HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\AeDebug

Nota: Se recomienda realizar un backup de dicha entrada antes de eliminarla.

HABILITAR LA HERRAMIENTA DR. WATSON

Para habilitarlo de nuevo simplemente hay que restaurar el backup del registro y ejecutar el comando drwtsn32 -i.

En este artículo se describe cómo configurar correctamente el servidor IIS con aplicaciones que usan la impersonación (autenticación de Windows) en un entorno con servicio de equilibrio de carga de red de Windows (WLBS).

Cada vez son más las aplicaciones que se migran a WEB debido a su facilidad de implantación, mantenimiento, etc. Otro punto importante es la seguridad de la aplicación la cual se puede lograr fácilmente haciendo uso de la autenticación de Windows (Kerberos). No obstante, se debe tener en cuenta que con este escenario se crea un punto crítico que es el servidor Web en este caso. Para garantizar la alta disponibilidad de nuestra aplicación podemos optar por varias soluciones aunque disponemos de una gratuita, incluida en nuestro sistema operativo Windows Server que es el Equilibrio de carga de red. Con esta tecnología, podemos crear un IP clúster el cual balancea la carga entre los nodos para garantizar la alta disponibilidad, escalabilidad, etc.

El mayor problema consiste en conseguir la autenticación de Windows realizando llamadas a la cabecera del clúster. En este caso, las credenciales se pierden y el usuario se convierte en Null. Para conseguir pasar las credenciales incluso realizando llamadas a la cabecera del mismo debemos de hacer lo siguiente:

• Configurar la cuenta de equipo de cada uno de los miembros del clúster para confiar en su delegación.
• Crear una cuenta de usuario del dominio el cual ejecutará los grupos de aplicaciones del IIS.
• Al igual que en la cuenta de cada equipo, la cuenta de usuario del dominio debe estar configurada para confiar en su delegación.
• El usuario del dominio debe ser miembro del grupo IIS_WPG en cada uno de los equipos miembros del clúster.
• Crear un nuevo grupo de aplicaciones en nuestros servidores IIS y ejecutarlos con el usuario del dominio.
• Configurar nuestro Sitio Web para usar la autenticación de Windows integrada.
• Registrar los SPN’s (ServicePrincipalName) para cada uno de los equipos miembros del clúster.

Para aquellos que no saben cómo configurar un clúster NLB, recomiendo la lectura de las siguientes páginas:

• Create and Manage Network Load Balancing Clusters

Nota: Para la realización del artículo se ha usado un dominio llamado pruebas.local  con el nivel funcional en Windows Server 2003. El clúster IIS está compuesto por dos nodos NODO1 y NODO2 cuyo nombre es CLUSTER.PRUEBAS.LOCAL.

Configuración de los nodos del clúster:

Una vez que los nodos del clúster están unidos al dominio accedemos la MMC Usuarios y equipos de Active Directory y buscamos las cuentas de los equipos miembros del clúster. En las propiedades de cada una de las cuentas marcamos la opción Confiar en este equipo para la delegación a cualquier servicio (sólo Kerberos):

Creación y configuración del usuario del dominio:

En segundo lugar vamos a crear un usuario del dominio que se encargará de ejecutar los grupos de aplicaciones de los servidores IIS. En este caso le llamará IIS_USER:

En el siguiente paso vamos a configurar la cuenta del usuario IIS_USER para que, al igual que en las cuentas de equipo, se confie en ella para su delegación. Accedemos a la propiedades del usuario IIS_USER desde Usuarios y equipos de Active Directory y nos vamos a la ficha Delegación.

Importante: Si la ficha Delegación no está visible, se debe a que aún no hay ningún SPN creado:

Configuración de los grupos de los servidores IIS:

Debemos de añadir al usuario IIS_USER al grupo IIS_WPG local de cada uno de los nodos del clúster:

Creación y configuración del grupo de aplicaciones IIS

Para crear un nuevo grupo de aplicaciones accedemos a la MMC de Administrador de Internet Information Services (IIS)àGrupos de aplicacionesàBotón derecho Nuevo-Grupo de aplicaciones. Le asignamos un nombre y usaremos el grupo de aplicaciones DefaultAppPool como plantilla.

Seguido accedemos a las propiedades de nuestro nuevo grupo de aplicaciones y le configuramos para ser ejecutado con las credenciales de nuestro usuario de dominio IIS_USER.

Configuración del sitio Web:

Dado que nuestro sitio Web tiene que ejecutarse bajo el grupo de aplicaciones que hemos creado, en este caso Kerberos, tenemos que acceder a las propiedades del mismo para realizar el cambio:

Del mismo modo tenemos que configurar nuestro sitio Web para usar solamente la autenticación de Windows integrada:

Creación de los SPN’s:

Para poder crear los SPN’s (ServicePrincialName) es necesario tener instalados los Windows Server 2003 Support Tools ubicados en la carpeta SUPPORT\TOOLS\SUPTOOLS.MSI dentro del CD de instalación de Windows. Después de instalar las herramientas de soporte, dispondremos de un nuevo comando llamado setspn. Su sintáxis es la siguiente:

setspn -a Servicio/NombreEquipo Dominio\NombreUsuario

Debemos de crear el SPN asociado a la “cabecera” de nuestro clúster que en este caso es cluster.pruebas.local por lo que quedaría de la siguiente manera:

setspn -a http/cluster pruebas\iis_user

Para que la autenticación de Windows funcione llamando a un solo nodo después de crear el SPN para el clúster es necesario agregar un SPN para cada nodo del clúster:

setspn -a http/nodo1 pruebas\iis_user

setspn -a http/nodo2 pruebas\iis_user

]]> http://adminexperience.wordpress.com/2008/10/26/autenticacion-kerberos-en-un-entorno-nlb/feed/ 0 adminexperience Delegación del equipo IIS_USER Delegación del usuario IIS_USER IIS_WPG apppool_kerberos apppool_kerberos_iis_user website_apppool website_security http://adminexperience.wordpress.com/2008/09/24/el-comienzo-de-un-proyecto-personal-y-profesional/ http://adminexperience.wordpress.com/2008/09/24/el-comienzo-de-un-proyecto-personal-y-profesional/#comments Wed, 24 Sep 2008 09:24:28 +0000 adminexperience http://adminexperience.wordpress.com/?p=3 ]]> Para los que no me conocéis, me llamo René Souren Pérez y trabajo como administrador de sistemas en una importante empresa de fabricación de ventanas de PVC en Cantabria.

Llevo varios meses con la idea de publicar un blog en el cual publicar pequeñas guías “howto” relacionadas con las tareas diarias de un administrador de sistemas. Tampoco descarto publicar otros temas que me interesan a nivel personal como la electrónica de consumo, etc.

Espero poder publicar algún que otro artículo durante el próximo fin de semana. Tengo mucho que contar, aunque dispongo de poco tiempo para hacerlo. En fin, espero poder colaborar con la comunidad de bloggers e Internautas para así hacer el trabajo diario un poquito más sencillo para todos.