Checho's Blog : Windows 7, Redirección de Carpetas, Windows 7 Deployment

Redirección de Perfiles y Carpetas en Windows 7 (Parte IV)

Checho — Mon, 07 Nov 2011 10:05:00 GMT

¡Hola a todos!

Finalmente, hemos llegado al final de la serie de artículos denominados: Redirección de Perfiles y Carpetas en Windows 7.

En esta cuarta y última parte veremos cómo reproducir el comportamiento que iniciamos y automatizamos en el artículo anterior utilizando el Archivo de autorespuesta. A diferencia de éste, veremos primero qué es lo que hace realmente el Archivo de autorespuesta y a partir de allí hacer el procedimiento manual de dos formas diferentes.

*Importante: Recomiendo que los que deseen probar los métodos que explicaré en estos artículos lo haga bajo un entorno explícito de pruebas, además de tener respaldo de las claves de registro modificadas e información que pueda verse afectada.

¿Qué hace el archivo de autorespuesta realmente?

Ya en el artículo anterior desplegamos un equipo en el que todos los perfiles nuevos que se crean se van diréctamente para la unidad D:\Users.

Sólo existe una forma de saber de dónde sale este cambio en Windows y es utilizando la mejor de todas las herramientas: Process Monitor de Sysinternals.

Específicamente, la función de Boot Logging que se puede habilitar desde el menú Options, Enable Boot Logging. Para este caso, hice esto y al reiniciar el sistema abrí nuevamente Process Monitor para guardar todo el log; una vez guardado, era tiempo de buscar qué información podría darme.

Como siempre, buscando por palabras que sirvan de patrón, utilice la de “profile” que es “Perfil” en inglés, después de algunos resultados, encontré lo que responde la pregunta inicial:

*Nota: Recomiendo hacer clic en la imagen para verla en tamaño completo.

Analizando un poco más a fondo el log, al crearse e iniciarse un nuevo usuario (Principalmente al iniciarse que es cuando ocurre todo), primero Windows utiliza la función RegOpenKey para abrir la clave:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList

Al abrir esta clave, utiliza la función de RegQueryValue para consultar el contenido del valor ProfilesDirectory, que para este caso, las mismas propiedades de la operación lo indican:

Como se ve en el valor de “Data”, el contenido es D:\Users, que es la unidad y directorio especificado en el Archivo de autorespuesta y destinado a donde se desea que Windows guarde todos sus nuevos perfiles creados.

En pocas palabras, cuando en el Archivo de autorespuesta indicamos en las propiedades del componente FolderLocation (Ver artículo anterior), Windows en su fase de oobeSystem que es la última establece el contenido del valor ProfilesDirectory a D:\Users, al igual que ProgramData. si desde Process Monitor lanzamos el Registro haciendo clic derecho y Jump To veremos cómo quedó:

Obviamente, Windows hace el cambio incluso antes de que se cree el primer usuario, por lo que todos quedan con esta redirección a la nueva unidad.

Ahora, si seguimos analizando la parte de la captura, vemos que luego de hacer esto, Windows cierra el trabajo con esta clave con RegCloseKey e inmediátamente pasa a hacer varias operaciones a nivel de sistema de archivos, entre las que se incluyen, crear la carpeta por usuario en la nueva unidad. Primero trata de abrir el directorio D:\Users\WinGuy2 pero con el resultado NAME NOT FOUND, por lo que todavía no está creado, así que pasa a crearlo utilizando la función CreateFile tal cual lo había buscado, es decir: D:\Users\WinGuy2

Lo está creando en D:\ porque ya previamente leyó dónde tenían que estar los perfiles de usuario almacenados.

Después de esto, viene lo más importante, Windows utiliza la función RegSetValue para crear el valor y su contenido de ProfileImagePath en la clave:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\ProfileList\S-1-5-21-790306392-3545880310-3045740698-1007

Si nos damos cuenta, después de ProfileList, hay un SID (Identificador único) para un usuario, aunque puede ser difícil detectar a cuál pertenece, sin embargo, al hacer clic derecho e ir a las propiedades, podemos ver algo que nos ayude a identificarlo:

En Data, nuevamente está escribiendo D:\Users\WinGuy2, lo que quiere decir que posíblemente este SID corresponda al usuario WinGuy2, entre otras, porque antes de esto recordemos que se creó la carpeta con el mismo nombre en la unidad D:\.

*Nota: Si traducimos “ProfileImagePath” puede ser algo como: Ruta de imagen de perfil, es decir, donde tendrá todo lo relacionado a éste.

A pesar de todo, si deseamos asegurarnos completamente de que este es el SID del usuario, basta con utilizar otra estupenda herramienta de Sysinternals (¡Lo tiene todo!) llamada PsGetSid.

Esta herramienta, como todas las que empiezan por “Ps” de Sysinternals, se hace por línea de comandos y tiene la capacidad de ejecutarse tanto en equipos locales como remotos, y para obtener información del SID tanto de usuario como de máquina.

Como estamos en un equipo local, basta con ejecutar PsGetSid y determinarle el usuario para el que se quiere obtener el SID, por ejemplo, en este caso que quiero confirmar el SID del usuario WinGuy2 bastaría con ejecutar:

PsGetSid WinGuy2

El resultado era el esperado, el SID correspondiente a WinGuy2 era:

S-1-5-21-790306392-3545880310-3045740698-1007

Exactamente el mismo que Windows estaba estableciendo según el resultado del log de Process Monitor.

Por último, Windows utiliza de nuevo la función de RegCloseKey para cerrar la operación en la subclave correspondiente al usuario.

Ahora que el sistema operativo sabe dónde debe almacenar el contenido del perfil y tiene el directorio creado, empieza a generar todos los archivos necesarios y unicos por perfil un poco más adelante, por ejemplo el de NTUSER.DAT que indica la configuración de HKEY_CURRENT_USER:

Hasta aquí, sabemos las claves determinantes que modificó el Archivo de autorespuesta para que Windows después hiciera la redirección del perfil de usuario, con esto podemos “jugar” para lograr finalmente el mismo comportamiento.

Redirección de Perfil de Usuario manualmente

Existen dos posibles formas de cambiar la ubicación del perfil, la primera desde Windows de forma Online y la otra desde la imagen offline, ambas no muy recomendadas ni soportadas, por esto mismo, recomiendo de nuevo hacer las pruebas para los que deseen en un ambiente totalmente controlado, el fin de este artículo es de enseñanza.

Método Online

La recomendación aquí, es hacer el cambio desde un único usuario en el sistema, con el fin de no modificar la ubicación de éste y en cambio sí asegurarse de que la ubicación de todos los demás sea en la nueva partición.

Si tomara como referencia la misma imagen instalada para estos dos artículos, ya todo está en D:\ porque el archivo de autorespuesta hizo el cambio, por lo que tendría que pensar en llevarlo a otra unidad o bien devolverlo todo a C:\

Con fines de ver cómo es el procedimiento, lo que haré será devolverlo a la unidad C:\ todos los nuevos usuarios creados.

Como dije, recomiendo utilizar sólo un usuario actual en el sistema para evitar riesgos, lo más fácil es borrar todos los que hayan y utilizar el Administrador integrado, para esto hacemos clic en Inicio, digitamos CMD, clic derecho y “Ejecutar como administrador”.

En la consola de comandos, ejecutamos:

Net User Administrator /Active:Yes

*Nota: Si el sistema está en español, se debe poner el mismo comando pero con la palabra Administrador, es decir: Net User Administrador /Active:Yes

Debe indicar que el comando se completó satisfactóriamente, cerramos sesión, iniciamos con el usuario Administrador integrado y borramos las cuentas que puedan existir desde la ventana de Cuentas de Usuario, para que sólo quede el Administrador y el Usuario invitado que está desactivado:

Ahora que está hecho esto, procedemos a modificar la ubicación de los nuevos perfiles de la siguiente forma:

1. Clic en Inicio, digitar Regedit, clic derecho y Ejecutar como administrador.

2. En el Editor de Registro, navegar hasta la clave:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList

3. Hacemos doble clic sobre el valor ProfilesDirectory y ahí le indicamos la unidad donde deseamos que queden los nuevos perfiles de usuario, para mi caso por ejemplo, lo moveré a la unidad G:\SoftPack\Users

*Nota: Windows es extremadamente inteligente, si el directorio no está, él lo creará

Basta con reiniciar, crear un nuevo usuario, y ver que todo funcione:

Como es de extremo riesgo dejar la cuenta de Administrador integrada habilitada, se debe ejecutar el comando de Net User para deshabilitarla otra vez:

Net User Administrator /Active:No

De ahora en adelante, a menos de que se modifique otra vez, todos los usuarios que se creen, se irán al nuevo directorio.

*Nota: Adicionalmente se puede mover el directorio de ProgramData, el de Public y el de Default, pero nuevamente, que sea desde un único usuario que no se afecte para que los demás no tengan problemas.

Método Offline

Este método consiste básicamente en montar la imagen Offline (Install.wim) antes de instalarse y modificar el Hive correspondiente a HKEY_LOCAL_MACHINE, hacer el cambio a los nuevos directorios (En la misma clave que el método Online), desmontar la imagen guardando los cambios y desplegarla.

No entraré en detalle, porque tengo un artículo totalmente dedicado a esto, lo único que varía es la clave que se va a modificar, pueden verlo desde aquí:

http://geeks.ms/blogs/checho/archive/2011/10/11/sysinternals-y-windows-deployment-mejor-juntos-establecer-pol-237-ticas-y-cambios-en-el-registro-a-una-imagen-offline-de-windows-7.aspx

*Importante: Los cambios mal hechos en el Hive de HKLM pueden ocasionar corrupción completa en la imagen de Windows, así como los que se hacen en el Registro de Windows, por eso no es un procedimiento soportado.

Adicional a esto, pueden tener problemas de perfiles temporales, en caso de que sea así, es porque se hace referencia a ubicaciones de perfiles que no existen o bien que no se encuentran los archivos necesarios por perfil como el NTUSER.DAT, pueden revisar este artículo en caso de tener el problema.

Con esto llegamos al final, espero haber cubierto todo o la gran mayoría de los métodos existentes para direccionar tanto los perfiles como las carpetas de usuario.

Ojalá les sea de utilidad tanto como para mí lo fue aprenderlo.

PD. No olviden seguirme en Twitter: http://twitter.com/#!/Checho_L

Saludos,

Checho

Redirección de Perfiles y Carpetas en Windows 7 (Parte I)

Checho — Wed, 19 Oct 2011 13:38:00 GMT

Hola a todos,

Varias cosas hemos estado viendo con respecto al comportamiento de los perfiles en Windows 7, sea por casos de Troubleshooting como que hay un perfil temporal o bien en otros escenarios muy comunes de implementación donde se desea modificar el comportamiento del perfil predeterminado.

Éstos sin embargo, no son los aspectos más importantes o determinantes sobre los perfiles de usuario, una compañía o nosotros como usuarios finales o técnicos de nuestras casas siempre nos preocuparemos por el dónde se encuentra nuestra información almacenada pero además, por el cómo estoy respaldando los perfiles que se encuentran actualmente en mis equipos Windows 7.

A esto se le llama Redirección de Perfiles o Carpetas y en realidad existe y se practica en Windows XP (Seguramente antes); lo que veremos en una serie de artículos, serán los diferentes métodos Automatizados, manuales, soportados o no soportados por Microsoft que existen para asegurar la ubicación de nuestros contenidos o perfiles de usuario enfocado a Windows 7.

Lo expuesto aquí además es con fines de compartir conocimiento por lo que como comenté previamente, puede no estar soportado por Microsoft.

Método 1: Políticas de Redirección de Carpetas

Éste escenario sólo lo cubren los equipos que estén bajo un Dominio, por lo que no sería algo normal para los equipos personales.

La política específica de Redirección de carpetas se aplica desde el Editor de políticas en el Servidor; aquí explicaré el paso a paso para la configuración básica pero no profundizaré mucho puesto que nuestro enfoque ahora es Windows 7 y no Server 2008 R2.

Partiendo de la idea general para todos los artículos que mis equipos tienen dos particiones locales, la intención es almacenar el contenido de las principales carpetas (Documentos, Imágenes, Música y videos) en la segunda partición para que no se vea afectada en caso de daños o formateo del equipo y que además sea transparente para el usuario.

En el Server, clic en Inicio, Herramientas administrativas, Gestor de Políticas de Grupo:

En la ventana del Administrador de Políticas de Grupo, expandimos el nodo de Dominios, luego el Servidor local (Para este artículo swatlab.local), clic derecho sobre Política de dominio predeterminada (Default Domain Policy) y seleccionamos Editar (Edit):

En la ventana del Editor de Políticas de Grupo expandimos el nodo Configuración de usuario (User Configuration), Políticas (Policies), Configuraciones de Windows (Windows Settings), Redirección de carpetas (Folder Redirection):

Dentro del nodo Redirección de carpetas (Folder Redirection) veremos el árbol de carpetas principales que tenemos normalmente en Windows 7:

Para especificar la redirección de carpetas locales a través del dominio, se debe seleccionar la carpeta preferida (Por ejemplo Documents), hacer clic derecho y seleccionar Propiedades (Properties):

En la ventana de Propiedades es donde se configurarán todos los parámetros, se puede definir para usuarios específicos, unidades de red específicas o bien la parte más sencilla que es una partición local en cada equipo.

En Settings (Configuraciones), debemos especificar si queremos que todos los perfiles se vayan a una misma ubicación (Basic) o bien si deseamos especificar diferentes ubicaciones por grupos (Advanced), para este artículo seleccioné Basic para que todos los perfiles creados en cada máquina se guarden en la otra partición.

Debajo de Ubicación de la carpeta de destino (Target Folder Location) seleccionamos: “Crear una carpeta por usuario debajo de la raíz” y ahí es donde debemos especificar cuál es la unidad en la que se guardará en cada equipo, para este artículo es la E:\

Como ven, según el ejemplo, en la unidad de cada equipo se creará una carpeta por usuario y dentro de ésta la carpeta que se haya redirigido, por ejemplo, para el caso de Documents, en mi usuario de dominio “scalderon” sería: E:\scalderon\Documents

*Nota: Si no se indica una unidad o ubicación existente, la política no se aplicará y los usuarios seguirán teniendo sus carpetas en la del perfil donde predeterminádamente están (C:\Users).

La recomendación sería asegurarse que todos los equipos al momento de deplegar Windows se les cree las dos particiones y que tengan las mismas letras.

Esto es todo, al aplicar, la política se desplegará por todos los equipos que inicien sesión o reinicien, por supuesto, que estén dentro del dominio y pegados a la red.

*Nota: Para cada carpeta que se quiera hacer redirección se debe hacer la misma configuración en el Editor de políticas, para este artículo por ejemplo, yo configuré Documents, Music y Pictures, este es el resultado en el equipo cliente:

Esto además cambia la ubicación de las Bibliotecas en Windows 7 y, afortunádamente es el proceso más sencillo y fácil de devolver; en conclusión, es el proceso recomendado para todos.

Hasta aquí todo perfecto, pero, ¿Qué es lo que pasa realmente en Windows 7 cuando reinicia y recibe las políticas de redirección?

Inside Folder Redirection…

Mis conocimientos por ahora lamentáblemente no me permiten mostrar y explicar detalladamente todo el proceso que hay en los Equipos cliente cuando se aplica una política como esta, sin embargo, Process Monitor como siempre nos puede dar algunos detalles muy precisos para acercarnos más a esto.

Políticas como las de redirección de carpetas se aplican sólo después de cerrar sesión o reiniciar porque hay un cambio en el Shell de Windows que sólo se ve reflejado cuando no hay actividad sobre el escritorio y en general sobre los procesos padre como el de Explorer.exe.

Como debe reiniciar, haciendo uso de la característica de Boot Logging de Process Monitor yendo al menú Options, Enable Boot Logging, podemos habilitarla justo antes de reiniciar el equipo, proceder y una vez en Windows guardar el log que se genera abriendo nuevamente Procmon (Process Monitor); así, nos da todo el camino a buscar qué sucedió mientras se reiniciaba el equipo y entraba en Windows que es cuando segúramente tomará y aplicará los cambios.

El Log, si siguen el procedimiento es realmente extenso y entre más tiempo nos demoremos en abrir Process Monitor al iniciar Windows, más pesado se volverá puesto que va acumulando dinámicamente hasta que le indiquemos que guarde.

Como siempre, la mejor forma de buscar es utilizando palabras que estén relacionadas con el cambio en inglés utilizando la opción de búsqueda CTRL +F, por ejemplo: “folder”.

Para este artículo, recién aplicada la anterior política me puse a buscar con este resultado y entre varios filtros encontré la operación que hacía más claro el cambio del cómo reconoció Windows que la carpeta debía ser redirigida a E:\

Trataré entonces, –Hasta donde mis conocimientos me lo permiten- de explicar por qué son estas las operaciones que considero más decisivas en cuanto al redireccionamiento de carpetas con la ayuda de Process Monitor:

La primera operación que se realiza utiliza la función RegOpenKey para abrir la clave: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders, antes de esto aunque la captura no lo alcanza a mostrar también se abre la clave User Shell Folders ubicada en la misma clave Explorer, las dos con resultado Exitoso (SUCCESS).

Después de esto se utiliza la función RegSetValue para modificar y establecer el contenido del valor Personal de ámbas claves, User Shell Folders y Shell Folders respectivamente, las dos con resultado SUCCESS también.

Hasta aquí no nos dice más que esto pero, Process Monitor tiene dos características más que nos llevan un poco más adentro de esta operación, tanto en la siguiente columna Detail como si hacemos clic derecho sobre la ruta y seleccionamos Properties podremos ver incluso los datos implicados en la operación que se está realizando, para este caso, yendo a las propiedades de la primera operación sobre User Shell Folders, este se puede ver esto:

Date & Time:    10/18/2011 11:06:36 PM
Event Class:    Registry
Operation:    RegSetValue
Result:    SUCCESS
Path:    HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders\Personal
TID:    1028
Duration:    0.0000065
Type:    REG_EXPAND_SZ
Length:    46
Data:    E:\scalderon\Documents

Lo importante y que me hizo detener en esta operación es que se está estableciendo por primera vez como datos la ubicación que se le había dado desde las Políticas de grupo, es decir, la ruta de E:\scalderon\Documents, por lo que el valor “Personal” se refiere internamente a la carpeta Documentos en Windows 7 y aquí es donde se le está indicando a Windows la redirección que se requiere.

*Nota: Si vamos a la pestaña de Stack podremos ver incluso la Cola de ejecución sobre esta operación para ir más a fondo con las funciones y utilizadas, las Dlls implicadas y demás.

Para estar más seguros, entra la otra característica ya conocida en otros artículos de Process Monitor y es la de ir directamente al Registro de Windows haciendo clic derecho sobre la ruta y seleccionando Jump To:

Éste es el resultado de lo que quedó en el Registro, más específicamente en el valor Personal dentro del Registro de Windows:

Como había comentado antes, el valor “Personal” se refiere internamente a Documentos (Documents), pero además, podemos ver que My Music y My Pictures (Imágenes y Música) también cumplieron su propia operación, no la vimos porque me centré en el resultado de Documentos pero las operaciones son exactamente las mismas.

Con esto, lo que hace Windows es cambiar la ruta que tiene como contenido y establecerla en la nueva ruta, para este caso en E:\scalderon\<NombreCarpeta>.

No podemos olvidar que según Process Monitor, se hacen estos cambios en la subclave User Shell Folders pero además también en Shell Folders:

La clave en cuestión es:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Personal

La última operación que hace Windows es utilizar la función RegCloseKey para cerrar el trabajo con el Registro de Windows.

Por supuesto, Windows es supremamente inteligente y al ser el primer inicio de sesión después de aplicadas las políticas, él mismo se encarga de crear las carpetas necesarias según las carpetas a las que se les haya hecho redirección:

En este orden de ideas, la política lo único que hace en Windows es cambiar los valores en ambas claves (User Shell Folders y Shell Folders) y crear la carpeta especificada que lea, además claro de remplicarlo por todos los usuarios que inicien sesión. Así entonces, podríamos pensar en que sería posible duplicar este comportamiento haciéndolo manualmente y sin necesidad de políticas de grupo, ¿No creen? =)

Sin embargo, eso se tocará en el próximo artículo de la serie ya que implica un proceso y algunos riesgos implicados.

Espero este haya sido útil, disculpándome por la extensión del artículo y agradeciendo a todos los que se toman el trabajo de leerlo.

En pocos días estaré publicando los demás.

Saludos,

Checho