Habilitar el Modo de Compatibilidad de una Aplicación para todos los usuarios utilizando el Editor de Registro en Windows 7

APC

Hola a todos,

Después de 39 artículos técnicos escritos en este Blog durante todo este año, llegamos finalmente al último post que cierra completamente el 2011.

Actualmente, el flamante 7 tiene la gran ventaja de ser Compatible con una gran mayoría de aplicaciones del mercado, incluso para algunas que no han evolucionado a Windows 7. Pero, no deja de existir el problema con aplicaciones “In house” o “A la medida” que manejan actualmente muchas compañías, y que además, se encuentran tal vez las más críticas para la organización, lo que representa por supuesto, un camino un poco más complejo para migrar todas las máquinas al nuevo sistema operativo.

Para fortuna de nosotros, con una gran cantidad, basta con utilizar algunas herramientas de Microsoft como ACT (Application Compatibility Toolkit) o las más poderosas de Sysinternals para detectar por qué en realidad las aplicaciones no parecen funcionar de manera nativa correctamente.

Esto sin embargo, no queda aquí, muchas de estas aplicaciones no están desarrolladas correctamente, a primera vista, parece que sólo corrieran en Windows XP, pero si utilizamos una de las características embebidas en Windows 7, denominada las Fichas de Compatibilidad, veremos que muchas, de repente, ya funcionan bien. 🙂

Para habilitar las Fichas de Compatibilidad, basta con hacer clic derecho sobre el ejecutable o accedo directo de la aplicación, seleccionar Propiedades, ir a la pestaña de Compatibilidad y seleccionar el item de “Ejecutar este programa en modo de compatibilidad para” escogiendo uno de los sistemas operativos desplegados abajo:

image

Esta configuración se puede aplicar para todos los usuarios fácilmente, basta con hacer clic en el botón inferior de “Cambiar configuración para todos los usuarios” y tendremos la misma ventana donde podremos especificar el modo que se guardará para la aplicación sin importar el usuario que inicie sesión:

image

La pregunta es: ¿Qué es lo que hace el Modo de Compatibilidad para que varias aplicaciones funcionen?
La respuesta se puede reproducir a nivel general en una palabra: ¡Mentir!

Windows internamente, una vez habilitado el modo de compatibilidad para alguna versión anterior, es interceptar la llamada que hace la aplicación al sistema para verificar, entre otras cosas, la versión del sistema operativo sobre el que está corriendo, y devolverle el resultado que espera, en las mayorías de las ocasiones –Que uno selecciona-, es decirle a la aplicación que está sobre Windows XP Service Pack 3 y no sobre Windows 7 Service Pack 1 por ejemplo. A esto se le llama: Mentira sobre versión.

Las aplicaciones que no están bien desarrolladas para medir si la plataforma sobre la que están corriendo sí es la apropiada, suelen comprobar a veces hasta con un número de versión para decir si son compatibles o no, el mentir sobre la versión solventa esto, y por eso la aplicación sigue corriendo como debería.

*Nota: Estas capas de compatibilidad hacen más tareas internamente, pero aquí estoy especificando el concepto de esta característica a nivel general con objetivos del post.

Ahora, nosotros no tenemos que preocuparnos cómo hace Windows realmente este engaño, pero para poder reproducirlo y personalizarlo, debemos aprender dónde consulta Windows las aplicaciones a las que les debe establecer el modo de compatibilidad.

Para el resto de este post, tomaré de referencia la aplicación UltraISO instalada en una máquina mía para seguir y explicar el procedimiento.

Si utilizamos Process Monitor de Sysinternals para seguir el comportamiento de Windows mientras habilito el modo de compatibilidad con Windows XP como mencioné anteriormente, y luego veo la traza que deja, podremos ver esto:

c1

La cuarta operación de la captura, muestra que al momento de establecer la Compatibilidad, Windows hace uso de la función RegSetValue para escribir el valor con la ruta completa del Ejecutable al que queremos engañar en la clave:

HKEY_CURRENT_USERSoftwareMicrosoftWindows NTCurrentVersionAppCompatFlagsLayers

En este caso, el valor mío fue la ruta a UltraISO, es decir:
C:Program Files (x86)UltraISOUltraISO.exe

Si desde Procmon accedemos al Registro, el valor por cada aplicación que se le indique el modo de compatibilidad se vería así:

image

Como nombre de Valor, la ruta completa como lo especificaba Process Monitor, y como contenido de valor (Data) el sistema operativo al que se quiere emular, en este caso WINXPSP3 que corresponde a Windows XP con Service Pack 3.

En este orden de ideas, es todo lo que Windows escribe en el registro, y lo único que necesita para saber que la ruta y el contenido especificado le dirán a qué aplicación debe mentir, y con qué sistema operativo.

Como ven, el procedimiento manual es realmente muy sencillo, pero habrán ocasiones en que como todo buen IT PRO, se quiere automatizar para ganar tiempo y productividad.

En este caso, el cambio en el Registro se podría hacer en el usuario para el que se vaya a copiar el perfil predeterminado con algún método ya conocido, o bien se puede cargar el Hive para personalizar la rama de HKCU predeterminada, o hasta cargar el Hive antes de instalar Windows para que se vuelva una configuración lista justo antes de la instalación; la decisión es de cada uno.

Esto valdría para el usuario actual, pero en caso de que la aplicación sea algo más general, para varias máquinas y usuarios, se puede forzar a que esté en este modo para todos y que no se pueda cambiar.

Modo de Compatibilidad para todos los usuarios

Predeterminadamente, Windows ya busca si existen aplicaciones en la lista de Layers para toda la máquina:

c2

El resultado, sin embargo, es NAME NOT FOUND (No encontrado), lo que indica que la clave Layers no está creada de forma predeterminada.

En este caso entonces, lo que haré será indicar el ejecutable de mi aplicación UltraISO para que se comporte en modo de compatibilidad con Windows XP para todos los usuarios que inicien sesión.

El procedimiento es exactamente el mismo, lo único que deben cambiar es la ruta del ejecutable.

*Nota: Deben tener en cuenta la ruta completa del ejecutable, incluyendo la extensión, por ejemplo para el mío sería: C:Program Files (x86)UltraISOUltraISO.exe

Lo que haremos, básicamente, será crear la clave que hace falta y hacer uso de los valores que se pueden establecer, y que sería lo que Windows haría en caso de cambiar la configuración para todos los usuarios.

Debemos hacer clic en Inicio, y ejecutar Regedit.exe para abrir el Editor de Registro de Windows.

Navegamos hasta la clave:

HKEY_LOCAL_MACHINESoftwareMicrosoftWindows NTCurrentVersionAppCompatFlags

Clic derecho sobre la clave AppCompatFlags, seleccionamos en el menú contextual Nuevo (New) y clic en Clave (Key):

image

Como nombre de clave, la debemos llamar Layers

image

Nos situamos sobre Layers, en la parte derecha, debajo del Valor predeterminado y en un espacio en blanco, clic derecho, Nuevo (New), Valor de cadena (String):

image

El nombre del Valor, debe ser la ruta completa de la aplicación, para mi caso por ejemplo, sería: C:Program Files (x86)UltraISOUltraISO.exe

image

Aquí está especificado la aplicación, pero todavía no la capa sobre mentira de versión, para esto, hacemos doble clic en el valor y en el contenido le debemos especificar la variable correspondiente al sistema operativo a emular, pondré dos de las principales correspondientes a Windows XP:

Windows XP Service Pack 2: WINXPSP2
Windows XP Service Pack 3: WINXPSP3

En mi caso, como era con Service Pack 3, la variable fue: WINXPSP3

image
Bastará con aceptar el cambio y ¡Listo! Nuestra aplicación ya maneja el modo de compatibilidad sin importar el usuario que inicie sesión, para verificarlo, basta con entrar con otro usuario, ir a las propiedades del ejecutable y pestaña de Compatibilidad:

image

Espero que les pueda ser de utilidad, y no siendo más, sólo queda por decir:

¡Muchas gracias y Feliz Año Nuevo!

Checho

Cambiar el Shell de ejecución predeterminado (Explorer.exe) en Windows 7.

Hola,

Este, más que un artículo, quiero verlo como un “Tip extendido”, puesto que es algo que he visto en varias consultas de los Foros y puede llegar a ser muy útil.

Cuando se implementa Windows en empresas Bancarias por ejemplo, o desde un Café Internet, se decide a veces que el personal sólo puede utilizar una sola aplicación todo el tiempo (En sucursales para el caso de los Bancos). A partir de esto, nace la necesidad de que el usuario no pueda interactuar con más aplicaciones ni mucho menos el algun proceso que parta del Explorador de Windows, como ventanas, barra de tareas, etc.

Lo que haremos en este post es configurar el Shell predeterminado de Windows 7, es decir, el Explorer.exe (Explorador de Windows), para que no sea el que inicie y en cambio, lo haga una aplicación que nosotros mismos definamos, como Internet Explorer o alguna de terceros.

*Nota: Explorer.exe es el proceso Padre en el sistema Operativo, a partir de este, se ve la barra de tareas, el menú de inicio, las ventanas y además representa el token de seguridad que adquieren los demás procesos que se ejecutan después de éste.

Primero veremos un poco de cómo determina Windows cuál es el Shell que debe ejecutar, cómo se configuraría por políticas de Grupo y finalmente cómo se haría lo mismo pero editando el comportamiento natural de Windows.

No hay herramienta más eficaz para comprender cómo funciona Windows que Process Monitor de Sysinternals, específicamente, la característica de Boot Logging que me permite ver todo lo que sucede internamente en el sistema operativo mientras está iniciando sesión, es decir, podremos ver qué es lo que hace Winlogon, proceso del sistema encargado del proceso de Logon en Windows.

Un poco del proceso de Winlogon

Si habilitamos la característica y hacemos el filtro por “Winlogon”, entre otras muchísimas tareas importantes, en qué momento se llama al Shell:

Winlogon1

Recordemos que de Process Monitor, podemos destacar tres principales columnas, la de la primera a la izquierda llamada “Operación” que nos dice qué tipo de operación se está haciendo, es decir, si es a nivel de Sistema de archivos, de Registro, de Red, etc; la columna central “Ruta” que nos indica dónde se está realizando la operación exactamente, y por último, la columna de “Resultado” que nos dirá con unas palabras claves si la operación que se intentó hacer en la ruta definida tuvo éxito, no se encontró, se pasó a otra operación, tuvo acceso denegado por permisos, etc.

En este orden de ideas, y analizando el resultado de la captura anterior, vemos que Windows utiliza la función RegOpenKey para abrir la clave de registro:
HKEY_CURRENT_USERSoftwareMicrosoftWindows NTCurrentVersionWinlogonShell

Sin embargo, el resutlado es NAME NOT FOUND, lo que indica que el valor Shell no existe predeterminádamente. Recordemos que HKEY_CURRENT_USER corresponde a las configuraciones por usuario, y prevalecerían con respecto a HKEY_LOCAL_MACHINE en caso de que existiera el valor y su contenido.

Después de esto, Windows utiliza la misma función pero esta vez para ir a la clave:
HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionWinLogon, la diferencia con la anterior, a parte de que consulta en HKEY_LOCAL_MACHINE que corresponde a todos los usuarios, es que esta vez el valor de Shell sí arrojó el resultado de SUCCESS (Exitoso) cuando se llamó a la función de RegQueryValue (Para consultar valores y contenido), por último cierra esta clave con la función RegCloseKey.

Después de esto, va lo interesante y es que utiliza la función de CreateFile para crear el proceso de Explorer.exe, justo después de haber leido el contenido del valor.

Si desde Process Monitor se abre el Editor de Registro haciendo clic derecho en la operación donde se consulta el valor de Shell, veremos esto:

image

El contenido del valor de Shell es “explorer.exe”, razón por la que Windows crea este proceso después de la operación de consulta.

*Nota: Esto es sólo una parte de lo que sucede al inicio de Windows y corresponde a Winlogon, hay muchas más tareas que en este artículo no se tocarán.

En conclusión, para evitar que Windows cargue el Explorer.exe y en vez de esto, ejecute de inmediato una aplicación personalizada, debemos editar el contenido de este valor poniendo la ruta completa del ejecutable y reiniciar, auque existe una alternativa más sencilla que es la Política de grupo. A continuación, pasaremos a ver los dos métodos existentes.

*Nota: El valor predeterminado está como explorer.exe (sin ruta) es porque está dentro de una variable de entorno del sistema operativo, lo que dará la posibilidad de llamar al ejecutable desde cualquier parte directamente.

*Nota 2: De aquí en adelante, me referiré a una ruta de ejemplo a la aplicación predeterminada, que en mi caso será Internet Explorer, cada uno debe cambiarla por la ruta completa de la aplicación que deseen, incluso si está en un recurso de red.

Método 1: Política de Grupo

Sea desde el Editor de Políticas de Grupo el Directorio Activo, o desde la Consola local en cada máquina, vamos al nodo de User Configuration (Configuración de usuario), Administrative Templates (Plantillas administrativas), System (Sistema), seleccionamos la política de Custom User Interface (Interfaz de Usuario personalizada):

image

Bastará entonces con seleccionar el radio de “Habilitar” y especificar la ruta completa en el cuadro de texto de la parte inferior:

image

Por último, bastará con cerrar sesión o reiniciar en los equipos unidos al dominio, o con los usuarios locales y el resultado será la ejecución sólo de la aplicación al iniciar sesión y no habrá nada del Explorador de Windows.

1.1. Modificando la política manualmente…

Como siempre, puede que haya equipos que no cuenten con la Consola del Editor de Políticas de Grupo –En el caso de las ediciones de Windows en la casa que no sean Enterprise o Ultimate-. Aquí entonces, debemos proceder a “forzar” el comportamiento de la política manualmente mediante el Editor de Registro de Windows.

Si no se sabe cómo, bastará con llamar nuevamente a Process Monitor y seguir el comportamiento de Windows mientras uno está aplicando la política en un equipo que lo soporte; aunque aquí no mostraré todo el proceso por lo que he tocado el punto en otros artículos, sí quiero que vean el resultado para esta política especialmente:

Winlogon2

El comportamiento es el mismo por cada política, los dos archivos referenciados en la captura (ntuser.pol y Registry.pol) son los que se encargan de copiar y replicar la política por cada usuario que inicie sesión en el equipo.

Ya viendo la política en cuestión, vemos que Windows hace uso de la función de RegSetValue para escribir el valor de Shell en la clave:
HKEY_CURRENT_USERMicrosoftWindowsCurrentVersionPoliciesSystem

Abriendo las propiedades de la operación haciendo doble clic o clic derecho y Properties, veremos qué es lo que está escribiendo en este valor:

Winlogon3

Como lo muestra “Data”, en este valor, después de crearlo, se está escribiendo como contenido toda la ruta a la aplicación que se especifique en la política, para mi caso: C:Program Files (x86)Internet Exploreriexplore.exe

Para replicar la política, lo que tendríamos que hacer sería:

– En cada equipo donde se desee aplicar (O distribuyéndolo), se debe ir hasta la clave:
HKEY_CURRENT_USERMicrosoftWindowsCurrentVersionPolicies

– Clic derecho, Nueva > Clave

– La llamamos System

– Seleccionamos la nueva clave, en la parte derecha, clic derecho, Nuevo > Valor de cadena

image

– Lo llamamos Shell, doble clic para editarlo y le indicamos la ruta de la aplicación a ejecutarse en vez del Explorer.exe

image

– Cerramos sesión o reiniciamos el equipo y estará hecho.

*Nota: Si algo sale mal, bastará con volver a entrar al Registro y arreglar la ruta o bien eliminar la clave para que vuelva al comportamiento natural.

Método 2: Cambiando el comportamiento predeterminado de Windows 7

Como vimos al principio, en cada inicio, Windows busca su Shell predeterminado, que es Explorer.exe y lo ejecuta para mostrar interfaz al usuario que recién ingresó.

Para modificar este comportamiento y cambiar el Shell por uno predeterminado, debemos hacer lo siguiente:

– En el Equipo que se desee tener esta configuración para todos los usuarios, hacer clic en Inicio, escribir Regedit, clic derecho, Ejecutar como administrador, y navegar hasta esta clave:
HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionWinlogon

– Doble clic en el valor Shell para modificarlo, y lo cambiamos por la ruta que deseamos sea la predeterminada, en este caso a la de Internet Explorer:

image

– Aceptamos, cerramos sesión o reiniciamos el equipo, y ahora, cada usuario que entre, tendrá como Shell predeterminado, la aplicación que hayamos configurado:

image

Si no queremos que sea para todos los usuarios, sino para algunos en especial, debemos seguir hacer lo siguiente:

-Navegar hasta la clave:
HKEY_CURRENT_USERSOFTWAREMicrosoftWindows NTCurrentVersionWinlogon

– Clic derecho sobre el espacio en blanco a la derecha, seleccionar Nuevo > Valor de cadena

– Debemos llamarla Shell, ya que como verán, no existe de forma predeterminada.

– Doble clic para editar el valor y especificar la ruta a la aplicación.

– Cerrar sesión o reiniciar el sistema, así, sólo el usuario al que se le haya personalizado el Shell predeterminado, será el que se le presente, los demás usuarios tendrán el Explorer.exe como normalmente estaría.

*Nota: En cualquiera de todos los casos, si hay problemas, bastaría con invocar el Administrador de tareas para crear el proceso de Explorer.exe, editar fácilmente el Registro de Windows para quitar o corregir la ruta en que haya quedado mal, cerrar sesión y volver a ingresar a probar.

Para cambiar de usuario, reiniciar o apagar, bastaría con presionar CTRL + ALT + Suprimir y seleccionar la opción que se busque.

¡Esto es todo!

Espero les pueda servir.

¡Feliz Navidad para todos!

Checho

Configurando Roaming Profiles (Perfiles Móviles) en Windows 7

groups

¡Hola a todos!

Ya hemos tocado en cuatro artículos anteriores (sin incluir los de solución de problemas) gran parte de lo que componen los Perfiles de usuario en Windows 7. Sin embargo, se siguen presentando nuevos requerimientos y por supuesto, Windows también entrega diferentes métodos para poder suplirlos en su mayoría.

Uno de los requerimientos o necesidades más importantes al tocar el tema de los perfiles en las diferentes organizaciones es determinar qué se hará con el perfil, ¿Se guardará, o no? ¿Se hará localmente, o no? ¿Se moverá todo el perfil?

Cada organización responde a estas preguntas de acuerdo a cómo desee que quede su infraestructura, la mayoría optan por manejar particionamiento en el equipo y redirigir cada nuevo perfil de usuario creado allí, así, no habrá peligro de perderse aún después de un formateo completo del sistema operativo.

Existe, a pesar de todo, un procedimiento adicional llamado Roaming Profiles (Perfiles Móviles), acorde a la nueva forma de ver el concepto de escritorio por parte de Microsoft llamado Escritorio flexible. Básicamente, Roaming Profiles (Perfiles móviles) nos permitirá centralizar todos los perfiles deseados en un solo repositorio central, dándole la posibilidad a cada usuario del Directorio Activo de iniciar sesión en cualquier máquina y disponer tanto de su propio perfil, como de todos sus documentos y configuraciones adicionales.

Lo que haremos en este artículo será configurar los Perfiles Móviles (Roaming Profiles) para Windows 7.

¿Qué necesitamos?

– Una infraestructura de Directorio Activo montada en Server 2008 R2.

– Una carpeta compartida donde se almacenarán los perfiles (En el artículo mostraré lo que se debe tener en cuenta a la hora de compartir el recurso).

*Nota: Esta característica es soportada desde Server 2003 y XP pero nos enfocaremos sólo a lo que concierne Windows 7 y 2008 R2.

– Equipo( S ) Windows 7 conectados al dominio y en la misma red.

Creando el recurso compartido

Antes de configurar los Perfiles Móviles, debemos tener un directorio donde se alojarán todos, para este caso, yo creé una carpeta en el Servidor dentro de la unidad raíz C: con el nombre de “Perfiles”, por lo que quedaría como C:Perfiles.

*Nota: El nombre de la carpeta lo especifico para seguir el artículo, por supuesto, cada uno de ustedes puede crearla en otra ubicación y con otro nombre.

Después de crear la carpeta, hay que configurar los permisos para que cada usuario que inicie sesión en el dominio y se le especifique el Perfil Móvil, pueda escribir en esta carpeta todos sus archivos correspondientes de usuario.

Para esto, hacemos clic derecho sobre la carpeta, seleccionamos Propiedades, en la ventana de Propiedades, vamos a la pestaña de Compartir (Sharing), clic en el botón Opciones avanzadas (Advanced Sharing),  seleccionamos la casilla de “Compartir esta carpeta” (Share this folder), cambiamos el nombre compartido si deseamos y clic en el botón de Permisos (Permissions):

image

En la ventana de Seleccionar Usuarios, Equipos, Cuentas de Servicio, o Grupos, clic en el botón Agregar (Add) digitamos o buscamos los Usuarios Autenticados (Authenticated Users) y clic en el botón Aceptar (OK):

image

En la Ventana de Permisos, seleccionamos Usuarios Autenticados (Authenticated Users) y le asignamos el Control total seleccionando la casilla de la parte inferior, Aplicamos y Aceptamos:

image

*Nota: Estamos seleccionando los Usuarios Autenticados, porque aquí estarán sólo los que vayan iniciando sesión en el Dominio, así además podremos asegurarnos de que cada usuario que inicie sesión, tendrá su propia propiedad sobre su carpeta correspondiente de Perfil.

Clic en Aceptar en la ventana de Opciones avanzadas y en la de Propiedades de la carpeta compartida. Debemos por supuesto, tener la referencia de la carpeta que acabamos de compartir, en mi caso quedó \SWATLABPerfiles

*Nota: En la ventana de Propiedades, pestaña Compartir (Sharing) se puede ver la ruta de red las veces que deseen.

Preparando el usuario

Con la carpeta compartida ya creada, en el Servidor de Dominio, abrimos la consola de Usuarios y Equipos del Directorio Activo, ubicamos el usuario que deseamos que tenga el Perfil móvil, clic derecho, Propiedades y vamos a la pestaña de Profile (Perfil).

image

En la pestaña de Profile (Perfil), tendremos dos nodos correspondientes a Perfil de usuario y Carpeta de hogar; el primer nodo, debemos ubicarnos en la caja de texto de Ruta de Perfil (Profile Path) y aquí debemos pegar o copiar exactamente la ruta compartida de red, pero, adicional a esto, para que cada usuario quede con un nombre de carpeta que se refiera por el nombre de dominio, agregamos la variable de entorno %USERNAME% al final de la ruta de red, así el Directorio activo sabrá a qué usuario se refiere y le creará su respectiva carpeta.

En mi caso, la ruta completa sería \SWATLABPerfiles%USERNAME%

image

Aplicamos y aceptamos en la ventana de Propiedades del usuario correspondiente.

*Nota: La ruta, para cada uno de ustedes segúramente variará, es importante escribirla bien porque de lo contrario, habrán problemas con el inicio de sesión del Perfil.

Esto es todo lo que tenemos que hacer, el siguiente paso será asegurarnos de que en verdad nuestro perfil ahora es móvil y no tuvo ningun problema para configurarse.

Probando nuestros Perfiles Móviles

Para este artículo, configuré en una máquina el perfil de mi usuario scalderon (Sergio Calderon), básicamente, con algunos archivos en el escritorio, y personalizaciones adicionales del menú de inicio, fondo de pantalla, imagen para mostrar y tema:

RP1

Como el usuario ya había iniciado sesión en el Equipo antes de configurarse el Roaming Profile (Perfil Móvil), se debe Cerrar completamente la sesión y volver a ingresar para que en el Servidor se creen las carpetas y archivos correspondientes del perfil que incluyen toda su información y personalizaciones – Tal cual una carpeta de perfil local-

image

*Nota: La carpeta correspondiente se crea en el primer inicio de sesión después de configurarse el Perfil Móvil (Roaming Profile), por esto el cierre de sesión; además, la finalización del nombre de la carpeta con “.V2” es porque Windows Server reconoce entre los perfiles que se creen para Windows XP y Server 2003, y los que se creen para Windows Vista, 7, Server 2008 y 2008 R2 , es decir “.V2”. La razón es porque tanto los archivos como las carpetas de usuario cambiaron de gran forma entre estas versiones de Windows no sólo en su contenido y número sino también en su ubicación.

Una vez iniciados sesión después de configurado el Perfil en el DA (Directorio Activo), procedemos a crear o guardar información, y realizar las personalizaciones que se deseen tal cual trabaja normalmente cada usuario en su equipo y perfil. Una vez cerrada la sesión por primera vez después de configurarse el Perfil Móvil (Roaming Profile) y por cada inicio de aquí en adelante, se copiarán todos los archivos a la carpeta de usuario destinada en el Servidor:

image

El hacerlo en cada cierre de sesión (Que incluye al apagarse y al reiniciarse por supuesto), garantiza que toda la información y cambios generados durante el tiempo de trabajo se guarden y así, el usuario podrá tenerlos en el próximo inicio de sesión, no solo en el equipo donde se creó todo, sino en cualquier nuevo equipo que esté en la misma red y que se haga con la cuenta de dominio.

Por ejemplo, para este artículo, inicié sesión en otro Equipo con Windows 7 x64 y además Internet Explorer 9 (Nótese que el anterior estaba en IE8) y este fue el resultado:

image

¡Esto es todo! Así de fácil ya nuestro perfil nos sigue por toda la organización Smile

Un poco más de información…

Existe, por supuesto, el caso de que el usuario no esté en la red interna y haya hecho una serie de modificaciones al tema de Windows por ejemplo, y agregado algunos archivos nuevos:

image 

Pero, como no se encuentra en la misma red, el perfil no se guardará al cerrar sesión ya que no hay comunicación con el Servidor donde está el almacenamiento, incluso Windows mismo nos advertirá:

image

En este caso, Windows seguirá trabajando con la configuración e información más actual que tenga en el Servidor de almacenamiento, actualizando así el perfil local que haya en la máquina conectada al dominio, sin embargo, cuando la máquina en la que se hizo la configuración por fuera de la red se vuelva a conectar al dominio con la cuenta implicada, al primer cierre de sesión, se actualizará nuevamente el perfil de red con toda información y configuración que se haya creado tanto en los equipos locales en los que se haya iniciado sesión, como con la que trajo la máquina que estaba por fuera.

En este orden de ideas, la próxima vez que se inicie sesión en la red de dominio, habrá un solo perfil con todas las configuraciones combinadas:

image

Con esto, nunca habrá preocupación por la cantidad de perfiles asociados a una misma cuenta, sólo la tranquilidad de mantener siempre una =)

*Importante: Dado que Windows divide en versión 1 y versión 2 el Perfil si se creó en Versiones anteriores como XP o Server 2003, sería la unica forma en la que serán dos perfiles diferentes, uno que se maneje en las máquinas de XP y 2003 y otras en las de versiones posteriores de Windows.

Espero les pueda ser de utilidad, como siempre, ¡Comentarios bienvenidos!

Saludos,

Checho