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

Bann

En este post continuaré con la serie de artículos relacionados con la Redirección de Carpetas y Perfiles en Windows 7; en el anterior post vimos un primer método utilizando las políticas de grupo, hoy veremos otra de las formas soportadas y un poco de relación entre este artículo y el anterior.

*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.

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 2: Redirección manual de carpetas desde Windows

Como en el caso de la política de grupo que se aplicaba más a entornos corporativos, el siguiente método se acogerá más a los que estén administrando pocos equipos, o bien sólo su propia PC en la casa.

Desde Windows XP hay una forma de redirecciónar la ubicación de las carpetas personales indicándole la otra locación manualmente en las propiedades de cada carpeta.

En Windows 7, a pesar del concepto de Bibliotecas, no ha cambiado mucho esto, el procedimiento sería:

– En el equipo que se quiere cambiar las ubicaciones, hacer clic en Inicio y clic en el nombre de usuario de cada uno que se visualiza en el menú de inicio.

*Nota: También se puede llegar aquí digitando y ejecutando en el menú de inicio: %USERPROFILE%

image

En el directorio del perfil de usuario podremos ver todas las carpetas que aunque son globales difieren de su contenido por usuario, y a las que apuntan las Bibliotecas predeterminádamente, por ejemplo: Documentos, Música, Videos, etc.

– Debemos escoger la carpeta que deseamos redirigir, para este artículo por ejemplo, yo seleccioné como primera a My Documents (Documentos), basta con hacer clic derecho y seleccionar Propiedades (Properties):

DF6

– En las propiedades de la carpeta seleccionada, debemos ir a la pestaña Ubicación (Location), allí es donde veremos la que se encuentra actualmente, que para Windows 7 siempre se dirige a C:Users<Nombre-Usuario><Nombre-Carpeta>, por ejemplo, para mi caso del usuario scalderon sería C:UsersscalderonDocuments.

Lo que debemos hacer es especificar explícitamente cuál deseamos que sea la ubicación, si queremos mantener el arbol que maneja Windows (Debajo de la carpeta Users), símplemente cambiamos la unidad, por ejemplo, para este artículo yo redirigí todo a E:

DF1
Como Windows es supremamente inteligente, si no hay carpetas, él se dará cuenta y crearía los mismos directorios en la unidad especificada, además de pedir la copia de archivos de un lugar a otro para centralizar:

Creación de carpeta:

DF2

Copia de archivos:

DF3

Con esto basta para que la redirección de carpetas se cumpla, ahora todo lo referente a este perfil en Documentos por ejemplo se irá diréctamente a E:, incluso las Bibliotecas de Windows harán también la referencia automáticamente:

image

*Nota: Este procedimiento se debe hacer manual para cada carpeta que deseemos (Música, Imágenes, Videos, Descargas, etc), aunque son los mismos pasos descritos anteriormente.

Lo interesante ahora es hacerse la pregunta: ¿Qué hay detrás de todo esto?

Inside Folder Redirection (Part II)

La respuesta, como siempre nos la dará Process Monitor de Sysinternals, increible herramienta para solución de problemas pero que además, nos ayuda a entender cómo funciona Windows.

El procedimiento es el corriente, abrir Process Monitor, detener el monitoreo con CTRL + E, limpiar el Log con CTRL + X y después iniciar el logging con CTRL + E nuevamente, ir hasta las propiedades de alguna de las carpetas de usuario y realizar el cambio.

Al terminar, volver al Process Monitor, detener nuevamente el monitoreo con CTRL + E y empezar a revisar.

La forma más fácil es buscando por palabras claves, o bien, de abajo hacia arriba que representa los eventos más recientes.

Para este artículo, yo seguí la misma carpeta de Documentos (Documents), y para mi sorpresa, esperando encontrar algo diferente a lo que arrojaba el procedimiento de las políticas de grupo, encontré esto:

DF4

Por supuesto que estaba equivocado yo, si comparan esta gráfica con la que vimos en el anterior artículo, específicamente en Inside Folder Redirection verán que las operaciones son exactamente igual una vez reiniciado el sistema y aplicadas las políticas a cuando cambio la ubicación desde Windows manualmente.

Básicamente, con las funciones RegOpenKey abre las claves User Shell Folders y Shell Folders y con las funciones RegSetValue asigna el contenido al valor Personal cambiándole la ubicación a la unidad E: y finalmente cerrar la operación con la función RegCloseKey.

También se crean las carpetas al Windows validar que no existen (Y es cuando nos muestra los mensajes pidiéndonos crearlas):

DF5

Primero busca si la carpeta está creada, sino, de acuerdo con el filtro utiliza la función CreateFile para ir creándolas.

*Nota:Personal” es como se refiere internamente Windows al directorio de Mis Documentos.

Aquí es entonces donde uniremos el anterior artículo con éste, la explicación es que tanto las Políticas de Grupo como el hacerlo manualmente sólo modifican el directorio en el usuario dentro de las subclaves User Shell Folders y Shell Folders. Lo que difiere a una de otra claro está, es que las políticas se pueden revertir, además de que se replican por todos los usuarios de la unidad organizacional a la que se le haya aplicado (Si se hizo con ese filtro), manualmente podemos retroceder pero habría que hacerlo para cada usuario.

Además de esto, nos da otra gran enseñanza, y es que si Windows hace este procedimiento, probáblemente modificando nosotros mismos los valores de Registro podamos lograr el mismo comportamiento. Aunque no es recomendable, a continuación con fines de conocimiento exploraremos un poco esto.

Modificando los valores manualmente en el Registro

Para este artículo, manualmente sólo cambié la ubicación de la carpeta de Documents (Documentos) como se pudieron haber dado cuenta, manualmente entonces indicaré y mostraré cómo cambiar la ubicación de las demás carpetas deseadas, en realidad basta con imitar lo que hace Windows internamente.

Abrimos el Registro de Windows con privilegios elevados haciendo clic en Inicio, digitando Regedit y sobre el resultado, clic derecho y “Ejecutar como administrador”.

En el Editor de Registro navegamos hasta las siguientes ubicaciones:

HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionExplorerUser Shell Folders

En esta primer ubicación veremos todas las carpetas por usuario a las que se les puede cambiar de ubicación y la configuración actual que tienen:

DF7

*Nota: Como ven, el valor Personal que corresponde a Documents (Documentos) ya está configurado a la unidad E:

Todas los demás valores están apuntando en su mayoría a donde se crea originalmente el perfil de usuario, es decir en C:UsersNombreUsuarioNombreCarpeta, para mi caso, haré lo mismo que Windows y modificaré la ubicación pero de la carpeta Pictures, que tiene el valor de My Pictures y lo redirigiré a E:UsersscalderonPictures

DF8

Al hacer clic en el botón Ok (Aceptar) ya se verá reflejado en el Editor de Registro, sin embargo, todavía falta otra modificación; si recordamos el procedimiento de Windows, en Shell Folders también hacía este mismo cambio.

Basta entonces con subir a Shell Folders que en su ubicación completa es:

HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionExplorerShell Folders

Aquí hacemos exáctamente la misma modificación, para mi caso de C:UsersscalderonPictures a E:Usersscalderonpictures

DF9

A pesar de que hicimos el mismo procedimiento que Windows, al reiniciar para que el Shell tome los cambios así, podremos notar que en la Biblioteca Música ya no se hace referencia a la carpeta de Música del usuario e incluso donde debería estar ubicada no se encuentra:

DF10

La razón por la que no se creó la carpeta puede ser relativamente sencila, Windows, como ya lo he dicho en varias ocasiones, es muy inteligente y cuando le estamos indicando la ruta a través de las Políticas de Grupo o incluso manualmente como expliqué en este artículo, él utiliza sus propias funciones de QueryDirectory y CreateFile para consultar y crear las respectivas carpetas, al hacerlo manualmente sobre un perfil ya creado Windows sigue haciendo referencia a la ubicación pero esta vez no creará las carpetas por sí solo, ésto solo lo hace en los escenarios anteriores o bien en el primer inicio de sesión del respectivo perfil.

En este orden de ideas, el experimento consiste en crear la carpeta manualmente y ver qué sucede, para esto basta con ir al directorio donde se supone debería estar y crearla desde el Explorador de Windows (También se podría desde línea de comandos):

image

El nombre debe ser idéntico a como a como la especifiqué en el Registro de Windows, para mi caso que redireccioné Pictures (Imágenes) debe tener el nombre de Pictures:

image

De nuevo, al reiniciar o cerrar sesión en el sistema y volver a entrar, la sorpresa ahora sí será grata y desde las Bibliotecas ya se hará referencia a ésta:

image

El que diga “Unresponsive” hace referencia a que la carpeta no se está comportando igual que la original, puesto que las originales de Mis ocumentos y Mis Imágenes son links simbólicos que van a Documentos e Imágenes.

Aquí sólamente estamos redireccionando, a pesar de todo, funcionará sin ningún problema pero, aunque lo haga, no deja de ser un procedimiento No recomendado para implementar, más sí para aprender =)

Como comenté antes, si se quisiera que todos los usuarios funcionaran con redirección de carpetas manuales y sin creárselas manualmente, antes de crear los perfiles locales habría que Modificar esta misma ruta en el Editor de Registro pero del Hive correspondiente al Default User para que cada nuevo usuario creado lleve su contenido de carpetas directo a E:, el riesgo claro está como siempre con los Hives es que son los predeterminados y cualquier daño afectará a todos los usuarios.

Espero les pueda servir a los que se tomen el trabajo de leer todo el artículo, como siempre comentarios bienvenidos.

En el próximo artículo de esta serie entraremos a la parte de redirección completa de los Perfiles de usuario y lo que esto implica.

Saludos,

Checho

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

Log

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.

*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.

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:

image

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):

image

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):

FD2

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

image

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):

image

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:

FD3

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:scalderonDocuments

*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:

image

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:

FD4

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_USERSoftwareMicrosoftWindowsCurrentVersionExplorerShell 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:

FD5

Date & Time:    10/18/2011 11:06:36 PM
Event Class:    Registry
Operation:    RegSetValue
Result:    SUCCESS
Path:    HKCUSoftwareMicrosoftWindowsCurrentVersionExplorerUser Shell FoldersPersonal
TID:    1028
Duration:    0.0000065
Type:    REG_EXPAND_SZ
Length:    46
Data:    E:scalderonDocuments

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:scalderonDocuments, 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:

image

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

FD6

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:

FD7

La clave en cuestión es:
HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionExplorerShell FoldersPersonal

image

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:

FD8

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

Sysinternals y Windows Deployment mejor juntos: Establecer políticas y cambios en el registro a una imagen offline de Windows 7

Hola a todos,

En ambientes empresariales es normal que cuando los equipos están bajo Tecnología Microsoft y hay un Dominio de por medio, todos los equipos que estén unidos se les crearán unas políticas de grupo para controlar comportamientos sobre sus objetos (Usuarios, máquinas, etc), así se logra estandarizar en gran parte las imágenes que se despliegan a través de la organización.

Las Políticas de Grupo tienen su propio comportamiento muy inteligente por cierto, aunque a grandes rasgos, lo único que hacen es una serie de cambios en el Registro de Windows de forma gráfica y replicarlos para todos los usuarios con unos archivos que se actualizan al iniciar sesión o al forzar las políticas de grupo con el comando gpupdate /force.

Normalmente sin embargo, no sólo se hacen configuraciones desde GPO para estandarizar o adaptar Windows a nuestro estilo o entorno, muchas veces por temas de Compatibilidad o símplemente por personalización específica también requerimos hacer cambios detallados en el Registro de Windows.

La otra cara de la moneda, es que no en todas las empresas existe Windows 7 Enterprise o Ultimate y no todo es empresa, ¿Qué pasa con el usuario hogareño que requiere administrar las máquinas con ediciones que no soportan el Editor de políticas de grupo y no hay dominio?

En la mayoría de las ocasiones tenemos dos alternativas, hacer estos cambios antes de capturar la imagen para copiar el perfil y que queden una vez instalado Windows en las estaciones de trabajo o bien hacer los cambios después de implementado Windows.

Estos procedimientos, aunque son rápidos, requieren a veces un poco más de tiempo o cuidado y por lo general, para los Profesionales de Tecnología (ITPROS), o incluso para las personas que manejan los equipos en casa, tiempo es lo que menos tienen y lo que más necesitan ahorrar.

Afortunádamente, éstos no son los unicos métodos para hacer configuraciones específicas sobre el Registro de Windows, nostros desde Windows Vista y gracias a WAIK (Específicamente a Dism) ahora podemos hacer estos y muchos otros tipos de cambios a una imagen offline (Sin conexión, no instalada), y mejor aún… gracias a Windows Sysinternals tampoco necesitamos del Editor de políticas de grupo para realizar los cambios a nivel de Registro que establezcan el objetivo de las políticas (En una gran mayoría).

En este artículo veremos cómo realizar cualquier tipo de cambio en el Registro de Windows sin necesidad de instalar completamente el sistema operativo pero además lo enfocaré a encontrar y desplegar configuraciones específicas de políticas de grupo manualmente para que tenga mucho más valor (espero).

¿Qué necesitamos?

1. Antes que nada, requerimos los archivos de instalación de Windows 7, específicamente el archivo de imagen Install.wim. Si todavía no tienen Windows 7, pueden descargar un Trial desde aquí: http://technet.microsoft.com/evalcenter/cc442495.aspx

2. Para poder desplegar alguna política modificando manualmente el Registro de Windows, debemos rastrear el comportamiento de la misma una vez aplicada, para eso debemos descargar y ejecutar Process Monitor de Sysinternals. Lo pueden descargar desde aquí: http://technet.microsoft.com/es-co/sysinternals/bb896645

3. Equipo Técnico donde se instalé el trial o una edición activada de Windows 7 Enterprise o Ultimate si queremos buscar el cambio de alguna política con Process Monitor; además de esto donde se podrá montar la imagen offline para realizar los cambios (Para esto no es necesario que sea Enterprise).

“Montando” la imagen…

Una vez tengamos todos los requisitos, ¡Hora de empezar!

Antes de cualquier cosa, tenemos que montar la imagen en algun directorio dentro del Equipo técnico, si el medio de Windows 7 está en un medio físico o imagen .ISO, debemos insertarlo en la unidad o virtualizar la unidad con aplicaciones como UltraISO en el caso de la imagen y posteriormente copiar todos los archivos al directorio creado.

Para este artículo, yo creé una carpeta llamada “7” en la Unidad C:, me quedaría: C:7 para hacer referencia a ella, una vez copiados los archivos, deberíamos ver algo similar a la siguiente captura:

image

En el mismo equipo técnico, hacemos clic en Inicio, tecleamos CMD y sobre el resultado Clic derecho y seleccionamos “Ejecutar como administrador”.

Al ejecutarse con un token administrativo, la consola de comandos debe quedar ubicada en C:WindowsSystem32, debemos ejecutar desde ahí el siguiente comando para montar la imagen: Dism /Mount-Wim /WimFile:<ImagenWIM> /Index:# /MountDir:<DirectorioMount>

Donde <ImagenWIM> se refiere al archivo de imagen .WIM que está ubicado bajo la carpeta Sources en los archivos de instalación de Windows, para este caso estaría en C:7Sourcesinstall.wim, “#” se refiere al número de índice de la imagen que queremos montar, recordemos que una sola imagen pueden contener varias imágenes, si es una Enterprise, el índice sería “1”; <DirectorioMount> se refiere a la carpeta donde queremos que esté montada la imagen de Windows que estamos referenciando, para este caso yo creé una carpeta llamada “Mount” en la unidad C:, por lo que sería C:Mount.

En este orden de ideas, para mi caso el comando sería:

Dism /Mount-Wim /WimFile:C:7Sourcesinstall.wim /Index:1 /MountDir:C:Mount

P2

*Nota: Cabe recordar que el archivo install.wim representa el nuevo formato de imágenes de Windows y es el que contiene toda la captura completa de lo que es el sistema operativo.

Una vez montada la imagen, veremos que en el directorio especificado se crearon una serie de carpetas muy familiares a cuando Windows se encuentra instalado:

image

Por ahora, no tocaremos más a Dism, ya que tenemos la imagen montada podemos empezar a inyectar configuraciones en su Registro para posteriormente guardarla y que queden al desplegar Windows.

Sobre Registry Hives

Antes de proceder a editar, es bueno recordar algo sobre los Hives, básicamente se conocen como Árboles que contienen una set de claves, subclaves y valores en el registro.

Un hive se puede ver como una plantilla para cada rama de Registro (HKCU, HLM, HKCR, etc), cuando un usuario inicia sesión, se le crea un nuevo Hive de usuario que contiene toda la configuración a nivel de Usuario, es decir ubicada en HKEY_CURRENT_USER y se toma de la plantilla NTUSER.DAT ubicada en el directorio C:UsersDefault que corresponde al usuario predeterminado en Windows 7.

Éste es el único Hive que difiere para cada usuario, pero no es el único Hive que existe puesto que casi todas las ramas del Registro tienen un Hive correspondiente y es del que todos los usuarios al instalar Windows hacen uso.

La mayoría de los Hives están en el directorio %SystemDrive%System32Config, normalmente C:WindowsSystem32Config

Lo que haremos con mucho cuidado es empezar a cargar los Hives que necesitemos según la configuración, normalmente sería el de usuario (NTUSER.DAT) para modificar todo lo que esté en HKEY_CURRENT_USER o alguno de los de máquina para modificar HKEY_LOCAL_MACHINE.

*Nota: HKEY_LOCAL_MACHINE tiene hive único para SAM, Security, System y Software, por lo que tenemos que saber cuál es el que requiere el cambio para cargarlo.

Aquí pueden ver más documentación al respecto: http://msdn.microsoft.com/en-us/library/windows/desktop/ms724877(v=vs.85).aspx

Identificando la clave de Registro a modificar con Sysinternals

Antes de proceder a cargar el Hive correspondiente de la imagen que montamos en los pasos anteriores debemos identificar qué es lo que vamos a modificar en el Registro.

Cada persona probablemente podrá saltar estos pasos puesto que por lo general, ya sabemos qué llave de registro es la que necesitamos cambiar y cómo la debemos cambiar.

Para este artículo sin embargo, pondré el ejemplo con una configuración básica a nivel de políticas que identificaré para hacer el cambio a nivel de Registro.

La política que seguiré es la de “Ocultar y deshabilitar todos los elementos del escritorio” ubicada en Configuración de usuarioPlantillas AdministrativasEscritorio en el Editor de Políticas de Grupo.

image

Existe sólo una herramienta que me ayudará a comprender cuál es el cambio cuando selecciono “Habilitada (Enabled)” y le doy a Aplicar (Apply), por supuesto, tiene nombre propio: Process Monitor de Sysinternals.

El procedimiento es relativamente sencillo, debemos poner a ejecutar Process Monitor para que inicie el log del sistema, posteriormente abrir el editor de políticas, ir directamente a la política y activarla, después de esto volvemos a Process Monitor, detenemos el log con CTRL + E o bien en File, Capture Events.

Ya en Process Monitor, la primera distancia puede ser algo confusa (Tanto aquí como haciendo Troubleshooting por ejemplo), la recomendación que di en mi anterior artículo y que vuelvo a dar aquí es simpre iniciar la búsqueda por palabras claves que tengan que ver el problema o lo que se esté buscando, si no dan resultado, variar con palabras alternativas o en últimas empezar a analizar línea por línea descartando las que no corresponden.

Para mi caso, empecé por la que más creí se asemejaba, la palabra: Desktop

*Nota: En lo posible, hacer la búsqueda con las palabras en inglés.

Para hacer la búsqueda en Process Monitor, basta con presionar las teclas CTRL + F o bien en el menú Edit, Find y poner la palabra:

image

A pesar de que me costó un poco en este caso, identifiqué tal vez lo que estaba buscando, primero por el proceso asociado (MMC.exe) y segundo por la operación y ruta que implicaba:

P3

Como ven, se está abriendo y haciendo consulta sobre la clave:
HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionGroupPolicyObjects

Esta clave sólo se ve afectada (Creada y editada) cuando se establece una política de grupo, desde Process Monitor se puede hacer clic derecho y seleccionar Jump To para ir directamente a la ubicación en el Registro, así se puede ver lo que establece específicamente:

image

Dentro de la clave en cuestión, se hace referencia a otra subclave ubicada por usuario en el Registro: UserSoftwareMicrosoftWindowsCurrentVersionPoliciesExplorer

En el lado derecho vemos que se creó un valor llamado NoDesktop con un valor “1” que se refiere a habilitado.

Ésta es la política, sin embargo desde aquí no se puede replicar porque siempre se crea un identificador (La serie de letras y números), pero podemos sacar ventaja de la segunda parte de la ruta especificada en la clave (UserSoftwareMicrosoftWindowsCurrentVersionPoliciesExplorer) esto indica dónde escribirá finalmente la configuración y es la que se replica a los demás usuarios, para este caso sería en:

HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionPoliciesExplorer

image

El contenido del valor NoDesktop es el que activará o desactivará la política, si está en 1 permanecerá activa, sin está en 0 sin embargo, permanecerá desactivada (Igual que si se elimina).

Ahora, como está en HKEY_CURRENT_USER, la configuración sólo aplicará en el usuario que se importe el fichero de registro, el Editor de Políticas es el que se encarga de replicarlo cuando se crea por ahí, pero todavía hay otra ventaja que por lo general funciona:

Gran parte de los cambios sobre las claves y subclaves de usuario, Windows los puede reconocer si se hacen en las mismas claves a nivel de máquina, es decir desde HKEY_LOCAL_MACHINE, en este orden de ideas para mi caso probé haciendo estableciendo el valor de NoDesktop (1) en la clave:

HKEY_LOCAL_MACHINESoftwareMicrosoftWindowsCurrentVersionPoliciesExplorer

*Nota: Noten que ya empieza en HKLM (HKEY_LOCAL_MACHINE).

image

Afortunádamente para mí, en este caso funcionó y ahora todos los usuarios se les desactivaban los elementos del escritorio, ¡Esto era lo que buscaba!

*Nota: Si desean de pronto aplicar esta misma política, les dejo la descarga del Archivo de Registro desde mi Skydrive:

Este sin embargo, es sólo el cambio en Windows pero debemos especificarlo es en la imagen Offline.

Cargando y modificando el Hive en la imagen sin conexión

Cabe destacar que si realizamos el cambio en el Hive de usuario (NTUSER.DAT), la política se aplicará para todos los que se creen desde el predeterminado, pero para este artículo lo aplicaré diréctamente en la rama de HKEY_LOCAL_MACHINE con el ánimo de que veamos que cualquiera puede sufrir el cambio.

El cambio está bajo Software, por lo que el Hive que se debe cargar es el de Software.dat ubicado en la carpeta Config de los archivos de instalación de Windows, en este artículo es el directorio: C:MountWindowsSystem32ConfigSoftware

En el equipo técnico, abrimos una consola de comandos con privilegios elevados (Clic derecho, Ejecutar como administrador) y debejos ejecutar:

Reg Load HKLMTemp <RutaHive>

Donde <RutaHive> es la ubicación del archivo Hive que deseamos cargar, para este caso por ejemplo sería C:MountWindowsSystem32ConfigSoftware

El comando para este artículo quedaría:

Reg Load HKLMTemp C:MountWindowsSystem32ConfigSoftware

image

*Nota:Temp” no es un nombre obligatorio, es sólo una variable para que se cree la clave en el Registro de Windows, por lo que se le puede poner el nombre que deseemos.

Abrimos el Registro de Windows haciendo clic en Inicio, tecleando Regedit, clic derecho y Ejecutar como administrador.

Debemos buscar la clave Temp debajo de HKEY_LOCAL_MACHINE (HKLM) y a partir de ahí buscar la ruta normal como mostré en el anterior punto al encontrar la clave de registro que se debe modificar:

P4

En vez de hacerlo manualmente, fácilmente podríamos exportar el cambio en el Reigstro normal de HKEY_LOCAL_MACHINE y modificarlo para especificar que agregue en la ruta la clave que contiene el Hive (Temp), por ejemplo, si el cambio es en:

HKEY_LOCAL_MACHINESoftwareMicrosoftWindowsCurrentVersionPoliciesExplorer,

Se modificaría el registro para que quedara:

HKEY_CURRENT_USERTempSoftwareMicrosoftWindowsCurrentVersionPoliciesExplorer

*Nota: No especificaré aquí de nuevo el paso a paso para la creación del valor que establece la política porque varía en este punto varía dependiendo de lo que cada quién quiera modificar en el registro.

Al terminar esto, cerramos el Registro de Windows, volvemos a la Consola de comandos y descargamos el Hive ejecutando: Reg Unload HKLMTemp

image

*Nota: Si planeamos hacer más cambios en el Registro debemos dejarlo cargado, realizar los cambios y una vez terminado, descargamos el Hive.

Desmontando Imagen…

¡Todo está listo! Finalmente en este punto si no vamos a realizar más cambios ya a nivel de Servicing (Con Dism como agregar actualizaciones), es tiempo de desmontar la imagen guardando los cambios para que todo lo que hicimos en el Hive y en general cualquier operación se mantenga para la instalación.

Para desmontar la imagen, hacemos clic en Inicio, digitamos CMD, clic derecho, Ejecutar como administrador.

En la Consola de comandos debemos ejecutar:

Dism /Unmount-Wim /MountDir:<DirectorioMount> /Commit

Donde <DirectorioMount> es como se llama donde montamos la imagen, para este artículo por ejemplo, es “Mount” y está ubicado en C:.

En mi caso el comando quedaría:

Dism /Unmount-Wim /MountDir:C:Mount /Commit

image

*Nota: La bandera /Commit es para que se guarden los cambios, en caso de que nos hayamos equivocado y queramos desmontar la imagen sin guardar los cambios se debe cambiar a /Discard

Preparando y probando…

Sólo queda crear la imagen .ISO si se quiere desplegar desde un Medio o bien proceder a montar el Install.wim en algun servidor WDS, MDT o cualquier otra tecnología de despliegue.

Al instalar Windows, sin tocar nada más, el cambio en el Registro estará embebido, para mi caso que integré el NoDesktop en HKEY_LOCAL_MACHINE para que ningun usuario pudiera cambiar o ver elementos en el escritorio, este fue el resultado:

P

*Nota: Nuevamente, recordemos que se puede hacer cualquier cambio en el Registro pero deben tener cuidado porque aquí estamos obligando a que las plantillas o Hives predeterminadas que son las más limpias estén viniendo ya con cambios.

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

Saludos,

Checho

El mensaje “…Inició sesión con un perfil temporal…” al intentar ingresar en Windows 7, Process Monitor y su solución.

¡Hola!

Me alegra mucho estar de nuevo por acá, y espero traerles en estas próximas semanas un par de artículos de detalles que he podido aprender en los últimos meses y que tal vez les pueda ser de utilidad.

No empiezo con eso porque afortunádamente, mientras preparaba uno de esos artículos me encontré con un problema que mucho había visto pero que no me había tocado enfrentar.

No sobra decirlo, como siempre nos iremos por diferentes fases, El problema, La causa y La solución, el que desee puede pasar a lo último para que compare e intente solucionar el problema si es que es el mismo comportamiento. Esta vez no hay Fix para descargar porque aunque puede ser la misma solución varían varios aspectos que se darán cuenta en el artículo.

El problema

Pues bien, el adelanto es que estaba haciendo una serie de pruebas sobre diferentes escenarios que tiene la Redirección de carpetas de usuario pero en una de todas, reinicié el equipo y al intentar ingresar a la cuenta, el inicio era como si fuera primera vez que estuviera entrando, por lo que tardó más y recibí el siguiente mensaje:

ProfileError

You have been logged on with a temporary profile.
You cannot access your files and files created in this profile will be deleted when you log off. To fix this, log off and try logging on later.
Please see the event log for details or contact your system administrator.”

No se cargó correctamente su perfil de usuario. Inició sesión con un perfil temporal.
Los cambios que se efectúen en este perfil se perderán cuando se cierre la sesión. Consulte el registro de eventos para obtener información detallada o póngase en contacto con el administrador.”

El funcionamiento de Windows en general se comportaba bien, excepto porque aunque tenía el mismo nombre de mi perfil no era mi perfil y por más que volviera a reiniciar siempre me creaba uno temporal.

Lo extraño era que el perfil de Administrador integrado estaba iniciando bien por lo que el problema se estaba causando sólo en este perfil en particular.

La causa

*Nota: Este problema está documentado en una KB de Microsoft para Windows Vista que debería ser muy similar en Windows 7: http://support.microsoft.com/kb/947242/es 

Lamentablemente, la solución propuesta no me sirvió, por tanto tenía que encontrar alguna por mi cuenta si quería recuperar mi perfil.

Sólo existe una herramienta lo suficientemente estupenda para que me hubiera podido ayudar, por supuesto estoy hablando de Process Monitor de Sysinternals.

No había nada que pudiera encontrar en Windows puesto que una vez iniciado ya el problema estaba ocurriendo, pero como cada vez se creaba una cuenta nueva, pensé que podría encontrar pistas si analizaba qué estaba ocurriendo en el inicio de sesión, ¡Process Monitor sabe qué hacer!

Hace un tiempo en el problema de los Remitentes pantallazos azules con el controlador de Procmon comenté que Process Monitor tiene una funcionalidad para habilitar Boot Logging que, básicamente carga un controlador en el inicio de Windows antes que casi todos por lo que me permite monitorear lo que sucede antes de que se inicie una sesión, basta con ir al menú Options, seleccionar Enable Boot Logging:

PE11

Procedí, reinicié el sistema y al ingresar nuevamente me encontré con el mismo mensaje, sin embargo ejecuté Process Monitor y efectivamente ya tenía toda la traza generada al ingresar, era el turno de empezar a buscar.

Considero una buena práctica utilizar la función de búsqueda en Process Monitor (En varias de las herramientas de Sysinternals en realidad) y tratar de encontrar resultados con palabras clave referentes al problema, en esta ocasión mi búsqueda fue por : profile

*Nota: Como dije en otro artículo, recomiendo en estas búsquedas utilizar los nombres en inglés porque internamente Windows siempre los referenciará así cuando existen.

Después de pasar algunos eventos que no se relacionaban mucho, encontré la clave de todo:

PE10

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

Como verán, hay varias operaciones que se están realizando, todas con resultados exitosos (SUCCESS), pero detengámonos a analizar un poco:

La primera operación que referencio está abriendo en la clave de Registro ProfileList una subclave que hace referencia a un SID (Identificador único) en:
HKLMSoftwareMicrosoftWindows NTCurrentVersion

La clave completa es:
HKLMSoftwareMicrosoftWindows NTCurrentVersionProfileListS-1-5-21-817817061-500146855-1629396408-1003

*Nota: Recordemos que HKLM hace referencia a HKEY_LOCAL_MACHINE.

Un SID se reconoce por una serie de números que tienen un comienzo muy similar (En este caso S-1-5-21-), existe SID por usuario y por máquina, en este caso, estaba referenciando a un usuario, el problema es que no sabía a quién todavía.

*Nota: El SID varía por usuario y por máquina por lo que si tienen el mismo problema verán otro número diferente en caso de que decidan analizarlo igual.

Para saber si esto tenía algo que ver con lo que buscaba, aproveché a Process Monitor así que hice clic derecho sobre la clave que se estaba abriendo y seleccioné Jump To (Para ir directamente a la ubicación en el Registro de Windows).

En el Registro me encontré con dos cosas sumamente interesantes, por el lado del Arbol de registro esto fue lo que vi:

PE7

La primera subclave que tengo encerrada (S-1-5-21-817817061-500146855-1629396408-1003) era la que me hizo referencia Process Monitor y su contenido era el siguiente:

PE12

Efectivamente los valores estaban relacionados con un perfil de usuario, el valor específico de ProfileImagePath que además está referenciado en la captura de Process Monitor y al cual hace consultas (RegQueryValue) está indicando la ruta de un perfil Temporal:

C:UsersTEMP.WIN-07Q5QALI9TH.008

Lo que no entendía es que este no era mi usuario, aquí estaba utilizando su nombre real pero en Windows yo seguía apareciendo con mi nombre de usuario (Demo).

Me devolví hasta el arbol de Registro y para mi sorpresa detallé que la otra subclave que está subrayada en la captura que mostré más arriba tenía exactamente el mismo SID que la anterior (S-1-5-21-817817061-500146855-1629396408-1003), con excepción de que éste terminaba en .bak que hace referencia normalmente a Backup.

Esta fue mi sorpresa cuando decidí ver su contenido:

PE13

Como verán, también hace referencia a un perfil de usuario, pero esta vez el contenido del valor ProfileImagePath sí hace referencia a mi usuario (E:UsersDemo), además difiere del anterior en que está tratando de buscarlo en otra unidad (E:), aquí pensé en la Redirección de carpetas que estaba trabajando (Ya tocaremos el tema en específico en otro artículo).

Obviamente no quería renunciar a la redirección de carpetas y perfiles puesto que ya había especificado que quería escribir en E:, sin embargo no entendía:

¿Por qué dos cuentas con el mismo SID?

¿Porqué está iniciando con el temporal y no con el real?

Para tratar de responder esto volví al Process Monitor para ver un poco más las tareas posteriores y si detallamos la primera captura, hay algo que me llamó la atención y que hace justo después de terminar estas tareas en el Registro:

PE14

Había una operación exitosa a nivel de sistema de archivos (Se reconoce por el icono de la lupa sobre la carpeta amarilla) que estaba creando, consultando y cerrando justo en la carpeta del perfil que hace poco había detallado en el Registro y que estaba como primario: C:UsersTEMP.WIN07Q5QAL19TH.005

Me pareció extraño sin embargo que la terminación fuera diferente, así que fui a la carpeta de Perfiles de usuario desde el Process Monitor y encontré que había una carpeta de perfil temporal por cada usuario que se estaba creando al reiniciar Windows:

image

Ahí estaba mi carpeta anterior sin embargo de “Demo” pero haciendo referencia a su primera ubicación original (C:UsersDemo), como yo había cambiado de unidad busqué en Process Monitor para ver si también se estaba creando la nueva carpeta en la unidad E: pero:

PE2

Mi carpeta no se estaba creando cuando cargaba Windows.

Me devolví al Registro de Windows gracias a que vi que en la traza de Process Monitor había dicho que la referencia a estas carpetas estaba en la clave ProfileList, ésta contiene toda la redirección de perfiles de usuario, incluyendo la de ProgramData que se refiere a ubicación general para todos los perfiles:

image

Hasta aquí se podía entender que no se creaba la carpeta del nuevo perfil “Demo” en la unidad E: que era la que trataba de buscar pero sí se creaba un perfil temporal, la ubicación era en C:Users porque el valor ProfilesDirectory de la clave ProfileList especifica %SystemDrive%Users.

*Nota: %SystemDrive% es una variable de entorno que hace referencia a la unidad donde está instalada Windows, en la mayoría de los casos en C:

A parte de esto, puedo asegurar que Windows es suprémamente inteligente porque es autosuficiente para valerse de cuentas temporales y poder ingresar al sistema, aunque obvio se borraba todo el contenido al volver a reiniciar.

No me iba a dar por rendido sin embargo, así que pensé que si yo creaba la carpeta explícitamente en la unidad E: de nombre UsersDemo, Windows debía encontrarla y así podría iniciar con el perfil nuevamente.

Para mi mala fortuna, aunque la creé, esto no fue así y Windows seguía creando perfiles temporales.

Me acordé que que la carpeta del perfil con todo el contenido normal sí seguía en la ubicación original y predeterminada de C:Users, así que pensé que si era porque no encontraba su ubicación, volviendo a poner la unidad en el valor ProfileImagePath en vez de E: a C: se debía reparar el problema:

image

Reinicié el sistema y ¡Oh sorpresa! Ya no había más perfil temporal, y funcionaba.

Me alegró esto porque ya sabía que era a la carpeta específica que se había creado originalmente la que se debíe referencia para que el perfil cargara pero no entendía qué tenía esa carpeta que no se volviera a referenciar en la otra unidad si después de todo los Documentos, Imágenes, Música y demás son para almacenamiento.

Aquí es donde me detuve y pensando un poco me acordé de algo suprémamente importante, cuando se crea un perfil no sólo se le establecen estas ubicaciones sino que además sele asigna una plantilla que tiene toda la configuración a nivel de usuario, es decir a NTUSER.DAT, además de otros archivos que pemanecen ocultos y que no se podían crear tan fácilmente, esto dio luz a mi solución.

La esperada Solución

No me iba a quedar con las ganas de que la ubicación de perfil se referenciara a la unidad E: que era donde la requería para las pruebas que estaba realizando.

Estos son los pasos de cómo conseguí entonces solucionarlo a la medida:

1. Navegué hasta la clave que referenciaba mi perfil de usuario debajo de la clave ProfileList:

HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionProfileListS-1-5-21-817817061-500146855-1629396408-1003

*Nota: El SID pueden saberlo viendo algun proceso con Process Monitor en la pestaña Seguridad, aunque también pueden ir hasta la ubicación HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionProfileList

Allí buscar entre todos los SID cuál corresponde a su usuario.

2. Hice doble clic en el valor ProfileImagePath y cambié la ruta de C:UsersDemo a la que originalmente quería: E:UsersDemo

PE15

3. Como sabía que dejándolo así iba a tener otra vez el famoso problema de los perfiles temporales, había que darle a Windows lo que estaba buscando (La verdadera carpeta “Demo” que tenía todos los archivos referentes a mi perfil como NTUSER.DAT propio) así que inicié sesión con otro usuario que tuviera privilegios,  fui hasta C:Users copié la carpeta “Demo” desde el Explorador de Windows hasta la carpeta “Demo” de mi ubicación en E:

image

Básicamente, para remplazar todo el contenido vacío de Demo en la unidad E: por el originario del perfil de usuario.

El resultado final de mi carpeta en E: sería similar a este:

image

4. Reinicié el equipo, inicié sesión con el usuario Demo y ahora felizmente cargaba el perfil como siempre lo había hecho y además estaba ahora apuntando a donde yo había querido desde el principio.

¡Problema solucionado! Smile

*Nota: La verdadera solución realmente es asegurarse de que el valor ProfileImagePath esté apuntando a donde se creó la carpeta de Perfil originalmente, el valor de ProfilesDirectory en la clave ProfileList puede asegurar con certeza dónde se están guardando los perfiles de usuario, una vez identificada la ruta de la carpeta del perfil se debe hacer referencia completa a ella y así Windows dispondrá de todo lo que requiere para cargar y mostrar el perfil.

Mover estas carpetas de Perfiles de usuario no es una muy buena práctica completa, siempre es mejor dejarlos en C:Users y así también estar seguros de que estos valores apuntan a su respectivo perfil para que este tipo de problemas no suceda.

Si este problema les llega a pasar a nivel de Dominio y tienen redirección de carpetas o de Perfiles de algun modo con gran seguridad siempre Windows estará buscando una carpeta de perfil donde no existe así que se deben asegurar de que sepa dónde está.

Como vieron además, vuelvo a decir que Windows es demasiado inteligente porque él mismo al saber dónde tenía el perfil verdadero borró y hizo uso del perfil temporal más.

Espero les pueda ser de utilidad y pueda haber podido lo poco que pude aprender de esto.

Saludos,

Checho