Checho's Blog : Windows 7 Deployment, Windows 7

Migración manual de Windows XP a Windows 7 utilizando USMT 4.0

Checho — Tue, 17 Jan 2012 15:24:00 GMT

Hola a todos,

Para nadie es un secreto que estamos a puertas de lo que conocemos hasta ahora como Windows 8, y por supuesto, la idea es empezar a cubrir la mayor cantidad de detalles posibles que vayan desde características hasta mejoras en implementación y solución de problemas.

Sin embargo, las compañías – Siendo un proceso y tiempo normal- es cuando en este momento, están planeando en gran parte la migración a Windows 7 y claro está, teniendo en cuenta y evaluando una cantidad inmensa de detalles, como la Compatibilidad de aplicación, las características del sistema operativo, y las diferentes soluciones de migración e implementación que existen por parte de Microsoft.

En el tiempo que llevo escribiendo en el blog, he tratado de mostrar varios y diferentes procesos de implementación manuales y automatizados que, en mi concepto, me han resultado útiles; obviamente, se me han quedado muchos por cubrir, pero se trata de compartir y de poder ayudar un poco en la medida posible.

Hoy quiero escribir y exponerles el proceso de uno que suele ser muy común, y es la migración desde Windows XP a Windows 7, hace ya tiempo escribí detallando el proceso para automatizar una migración fácil utilizando Microsoft Deployment Toolkit (MDT), pero por debajo de todo esto, el de la magia es la herramienta llamada Migración de Estado de Usuario (USMT) que se puede utilizar manualmente y de una manera relativamente fácil.

USMT es una herramienta mucho más robusta que Windows Easy Transfer que es la que viene embebida en Windows 7. Está incluida dentro del Kit de Instalación Automatizada para Windows 7 (AIK) y se compone básicamente de dos herramientas:

Scanstate: Esta hará una copia de todos los archivos, perfiles y configuración de aplicaciones que esté en el sistema operativo y brindará la posibilidad de especificar el lugar de almacenamiento, además de filtrar lo que se migrará. Funciona desde Windows XP.

Loadstate: Desde esta herramienta, también de línea de comandos, es donde se cargará todo lo que Scanstate haya recopilado previamente en el nuevo equipo, o incluso en el mismo equipo si así se decidió (Un refresh), por supuesto, tiene sus propias banderas para hacer filtros y, a diferencia de la anterior, funciona sólo en Windows Vista y superiores.

*Nota: Hay más sobre los scripts que administran estas dos herramientas, pero la idea del post es explorar un poco el proceso básico, lo que sigue es que cada uno indague un poco más de acuerdo a la necesidad.

Lo que haremos aquí será hacer la migración completa desde Windows XP a Windows 7 manualmente con USMT paso a paso.

Actualmente, el equipo que migraré cuenta con dos cuentas y algunos archivos que se requieren pasar al nuevo equipo, ubicados en el escritorio y en la carpeta de documentos:

¿Qué necesitamos?

Para proceder a la migración, necesitamos básicamente:

Kit de Instalación Automatizada para Windows 7: Desde el Kit es donde vamos a extraer la herramienta de USMT necesaria para la migración. Si no tienen todavía AIK, pueden descargarlo gratuitamente desde Aquí

Equipo técnico: Donde instalaremos el Kit de Instalación Automatizada (AIK), desde este equipo es donde copiaremos todos los archivos al equipo con Windows XP.

Recurso compartido de red o unidad de almacenamiento extraible: Mientras hacemos la migración, y después de ésta, necesitamos almacenar los archivos de usuario en un repositorio.

*Nota: Aunque puede ser cualquiera de los dos, para este artículo, trabajaré sólo con un recurso compartido de red.

Equipo de pruebas: Donde estará instalado Windows XP, se hará el respaldo de los datos y configuración del perfil, se instalará Windows 7 y se hará la migración de todo lo que tenía en XP.

Medio de instalación de Windows 7: Por supuesto, necesitamos tener todo lo necesario para desplegar Windows 7 en el equipo.

¡Empecemos!

Lo primero que tenemos que hacer, es pasar los archivos correspondientes de USMT al equipo local con Windows XP, en el equipo donde esté instalado Windows AIK, están ubicados en:

C:\Archivos de Programa\Windows AIK\Tools\USMT\<Arquitectura>

Donde <Arquitecturaz> es x86 si se van a pasar los archivos de 32 bits, o amd64 si se van a pasar los archivos de 64 bits.

Normalmente, sería el de x86.

Se puede hacer a través de Windows, o bien por la línea de comandos utilizando la herramienta de Xcopy.

Por ejemplo, para mi caso que los archivos los copié a una unidad de red V:\, dentro de la carpeta USMT\x86, desde el Equipo XP podría hacer la copia localmente a la unidad C:\ en la carpeta llamada también USMT con el comando:

xcopy V:\USMT\x86 C:\USMT

Ahora, nos debemos situar desde la línea de comandos en la carpeta que acabamos de copiar donde están todos los archivos de USMT, para este caso en C:\USMT

Para que capture todo lo necesario de este equipo de referencia, utilizamos la herramienta Scanstate con la siguiente línea de ejecución:

Scanstate <RecursoCompartido> /i:migdocs.xml /i:migapp.xml /v:13

Donde <RecursoCompartido> es el directorio en red donde deseamos almacenar todo el contenido que se migrará al nuevo equipo, en mi caso, la sitaxis completa sería:

Scanstate V:\Store /i:migdocs.xml /i:migapp.xml /v:13

*Nota: La bandera /i: hace referencia a cualquier XML que contenga configuración de lo que se migrará, USMT ya trae Migdocs para los archivos y Migapp para lo que corresponda a las aplicaciones.

Después de que termine, y que estemos seguro de que corrió de forma normal el scan de todo lo referente al equipo de referencia, debemos instalar normalmente Windows 7, sea en el mismo equipo haciendo el formato completo, o bien en un nuevo equipo que pueda luego tener acceso al recurso compartido también.

Recuperando perfil y archivos de usuario

Después de instalado Windows 7, el proceso es supremamente sencillo, desde cualquier cuenta que se haya creado, debemos copiar otra vez todo el contenido del recurso compartido donde están los archivos de USMT localmente.

De nuevo, se puede hacer desde el Explorador de Windows, o bien mediante línea de comandos utilizando la herramienta de Xcopy, en mi caso, que todo estaban en el recurso de red con unidad V:\, llamado USMT; lo copié a una carpeta local otra vez con el mismo nombre con la siguiente sintaxis: xcopy V:\USMT C:\USMT

Después de copiar todo el contenido, como en el caso de Scanstate, en una Consola de comandos con privilegios elevados nos ubicamos en el directorio donde se copió todo, en mi caso en C:\USMT.

Ahora, restableceremos todos nuestros usuarios y archivos que están en el repositorio de la red, para esto ejecutamos:

Loadstate <RecursoCompartido> /i:MigDocs.xml /i:MigApp.xml /lac /lae /V:13

Donde <RecursoCompartido> es el mismo donde almacenamos todo lo guardado con respecto a los perfiles y configuraciones de la máquina cuando corrimos Scanstate.

En mi caso, el comando sería:

Loadstate V:\Store /i:MigDocs.xml /i:MigApp.xml /lac /lae /V:13

*Nota: /lac es una bandera que se utiliza para que Windows cree los usuarios locales que haya detectado durante el Scanstate (A menos de que se le haya especificado sólo uno), y /lae es para que habilite dichos usuarios. Predeterminadamente Windows no lo hará.

Después de que USMT complete el proceso, y no haya ningún error, se debe reiniciar el equipo, con esto Windows reconocerá las nuevas cuentas para poder ingresar:

*Nota: Al ingresar por primera vez a cada cuenta, predeterminadamente, a menos de que se especifique en la línea de comandos una contraseña predeterminada con la bandera de /lac, por ejemplo: lac:Passw0rd.
Toda la línea de comandos de Loadstate, la pueden consultar aquí:
http://technet.microsoft.com/en-us/library/dd560804(WS.10).aspx

Espero les pueda ser de utilidad.

Saludos,

Checho

Windows 7, Internet Explorer 9 y la Vista de Compatibilidad

Checho — Wed, 04 Jan 2012 15:09:00 GMT

Hola a todos,

Antes que nada, espero que este sea un gran año para todos ustedes.

Cuando una compañía está evaluando Compatibilidad de Aplicaciones sobre un nuevo sistema operativo, como lo es Windows 7 ahora, o bien piensa entrar en un piloto para hacerlo – Como tal vez varias empresas lo harán este año-, no sólo se pueden tener en cuenta lo que corra bien, o se haga correr en el escritorio, existe la necesidad de encontrar y solventar problemas de compatibilidad con aplicaciones web (Que trabajan desde un browser), o bien, las mismas páginas públicas o de intranet con la que los empleados requieren estar interactuando.

Esto no es un trabajo fácil, puesto que es necesario que la aplicación o la página web se desenvuelva bien en la nueva versión del navegador, antes de ir a aprobar una migración. Afortunadamente, como con la Compatibilidad de aplicaciones de escritorio, Windows, y más específicamente Internet Explorer en su versión 8 y 9 integran una característica llamada Vista de Compatibilidad (Compatibility View).

A diferencia del Modo de Compatibilidad para las aplicaciones de escritorio, la Vista de Compatibilidad se puede activar en cualquier página que lo requiera símplemente con hacer clic en el icono de la parte superior derecha de la barra de Direcciones, identificado con una hoja partida a la mitad:

A partir de que se active la Vista de Compatibilidad, la página se verá y se comportará como si estuviera trabajando sobre Internet Explorer 7.

Con esto basta para que una gran cantidad de aplicaciones o páginas web sigan funcionando sin ningún tipo de problema.

¿Cómo funciona?

Ahora bien, ¿Qué sucede cuando activamos la Vista de Compatibilidad realmente?

Cuando visitamos un sitio web, el navegador en el que estemos siempre entrega una Cadena de Agente de Usuario al servidor donde está alojado la página web, ésta cadena incluye información relevante como la versión del sistema operativo, la versión del navegador en el que estamos, entre otros datos que utiliza el servidor para generar y mostrar el contenido de acuerdo al navegador en el que estemos y sus características.

Podemos ver un ejemplo de esto visitando la página: http://whatsmyuseragent.com/

Apenas ingresamos, veremos que nos entrega La cadena de agente de usuario que el Servidor haya identificado (Y que el navegador le haya enviado):

Como ven, la Cadena de Agente de Usuario me devolvió datos tanto de mi navegador como de mi sistema operativo, para este caso específico, la versión del navegador que detecta es MSIE 9.0, es decir, Microsoft Internet Explorer 9.0.

*Nota: Internet Explorer se identifica él mismo como Mozilla, no se alarmen =)

Esta es la misma información que recibe cada servidor de las páginas web, lo unico malo es que al renderizar el contenido de la página web, muchos dependen sólo de la versión que detecten, similar a lo que sucede con las aplicaciones de escritorio, por lo tanto, si un servidor host detecta una versión de IE 9 en vez de IE 7, y sólo se basa en esto, presentará la página con algunas incoherencias o fallos funcionales.

Aquí, cuando surgen los problemas, es cuando actúa la Vista de Compatibilidad, y afortunadamente, el concepto se asemeja mucho al de la compatibilidad de escritorio (Aunque funciona diferente), básicamente, Internet Explorer 9 devolverá una Cadena de Agente de Usuario diferente a la que realmente es, específicamente, devolverá la correspondiente a la que se mostraría si el navegador que estuviera instalado fuera Internet Explorer 7, es decir, “Mentira sobre versión”.

En la misma página de whatsmyuseragent.com, si se activa la Vista de compatibilidad, devolvería esto:

Los servidores host detectarán Mozilla 4.0, que equivale a Internet Explorer 7 (MSIE 7.0), y con esta información, renderizarán el contenido de la página para que se muestre como si estuviera allí, lo que hará que nuestro sitio probablemente, funcione bien.

Para identificarlo de una forma visual, cuando se activa la Vista de Compatibilidad, el mismo icono de la hoja partida a la mitad de la barra de direcciones en el navegador se verá de color azúl:

La Vista de Compatibilidad se puede activar manualmente página por página, o bien ingresando toda una lista manual de sitios desde el navegador, para esto basta con presionar la tecla ALT para mostrar la barra de menú de Internet Explorer, ir al menú Herramientas y seleccionar “Configuraciones de la vista de compatibilidad”:

En la ventana de Configuración, podemos especificar todos los sitios que deseemos que estén en Vista de compatibilidad escribiéndolos debajo de “Agregar este sitio web”, cada que vayamos adicionando sitios, los veremos en una lista inferior desde la que podemos agregar o remover según nuestra necesidad:

Sin embargo, esta configuración no se guarda para todos los usuarios, por lo que viene el primer problema, a pesar de ser fácil, desde el navegador no es posible generar la Vista de compatibilidad para cada usuario que inicie sesión en el equipo.

Para hacer esto, como casi todo en Windows, hay dos posibilidades, tratar de replicar la configuración que se haga en el Registro de Windows en todos los usuarios (No siempre se Windows lo reconoce), o hacer esta personalización para todos los usuarios a nivel de Políticas de Grupo – Si es que la política existe claro está-.

Por supuesto, la segunda opción es la más soportada, fácil y rápida, y en este caso, Internet Explorer 9 tiene unas políticas listas para personalizar la Lista de Compatibilidad para todos los usuarios, pero, primero veremos un poco cómo se comporta Windows para identificar un sitio que debe estar en Vista de compatibilidad según se lo hayamos especificado.

Como siempre, Process Monitor de Sysinternals es la herramienta adecuada para intentar seguir a Windows, aprender y determinar su comportamiento.

Si habilitamos un sitio en Vista de compatibilidad, y posteriormente volvemos a Process Monitor y seguir el resultado de la traza, encontraremos que hay un comportamiento muy interesante dentro de las claves de Registro correspondientes a Internet Explorer:

La operación que Windows hace es utilizar la función de RegCreateKey para crear la clave de ClearableLisData en la ruta: HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer \BrowserEmulation, posteriormente, usa la función de RegSetValue para establecer el valor de UserFilter y por último hace uso de la función RegCloseKey para terminar la operación en la clave.

Pero, ¿Qué tiene de importante este valor? Si desde Process Monitor hacemos clic derecho, Jump To a la clave que se creó, podremos ver el valor UserFilter, que es de tipo Binario:

Pero si lo abrimos haciendo doble clic para modificarlo, podemos identificar algo verdaderamente interesante:

Un Valor binario en el Registro, se compone por dos características claves, la primera columna completa de letras y números de la izquierda, son los digitos binarios que representan las letras y símbolos que se ven en la segunda columna de la derecha, aunque no siempre son exactamente los mismos – Y esa es una respuesta que todavía no estoy en capacidad de dar para el que se pregunte la razón –.

Para este caso, al yo activar La vista de compatibilidad en la página une.com.co, en el valor Binario de UserFilter, almacenará esta página para que Windows sepa que la debe mostrar en Vista de compatibilidad en el usuario en que se haya establecido. Como ven, después del valor resaltado en rojo, se puede ver la dirección de la página.

Cabe destacar que no se crea un valor binario por cada página en la que se indica la vista de compatibilidad, el mismo valor UserFilter guarda todas las páginas que se establezcan sea manualmente o por la Lista de compatibilidad desde el menú de Herramientas de Internet Explorer.

Lamentablemente, de esta forma, así se replique en HKEY_LOCAL_MACHINE, no se refleja la Vista de Compatibilidad en los demás nuevos usuarios que ingresen en el equipo, sólo si se exporta la llave de registro y se importa en el nuevo usuario funciona.

A pesar de todo, siempre quedan las políticas de Grupo para cubrir esta necesidad.

Lista de Compatibilidad a través de GPO

Para establecer una Lista de Compatibilidad utilizando GPO, que en palabras generales, son varios sitios en vista de compatibilidad, se debe abrir el Editor de Políticas (Gpedit.msc), navegar hasta Configuración de Equipo\Plantillas Administrativas\Componentes de Windows\Internet Explorer\Vista de Compatibilidad.

En el panel derecho donde se encuentran las plantillas disponibles, doble clic en “Usar Lista de Política para sitios de Internet Explorer 7” (Use Policy List of Internet Explorer 7 sites).

Seleccionar habilitar y clic en el botón Mostrar para adicionar todos los sitios que deseamos se mantengan en Vista de Compatibilidad predeterminádamente:

En la ventana de Mostrar contenidos, debemos escribir todos los sitios que predeterminádamente estarán en Vista de Compatibilidad para cada usuario nuevo que inicie sesión, posteriormente aceptar y aplicar la política para que empiece a suritir efecto:

Mientras se mantenga activa la política, todos los sitios que se pusieron en Vista de Compatibilidad, se les desaparecerá el icono que identifica la característica para que no pueda ser deshabilitada:

Hasta aquí y con esto, sería suficiente para garantizar el comportamiento en todos los usuarios, la nueva inquietud es: ¿Qué hacer los que no no tienen una edición de Windows 7 que integre el Editor de políticas de grupo? ¿Qué hacer con los que no están unidos a un dominio además?

Recordemos que, como hemos visto en varios artículos, cada política lleva por debajo una o más modificaciones al Registro de las que tal vez no nos damos cuenta, por lo que la respuesta sería: ¡Busquemos y repliquemos!

Analizando la política…

Cuando se aplica esta política para mantener una Lista de Compatibilidad, si nos ayudamos con Process Monitor nuevamente, veremos dónde opera internamente Windows en el Registro para que el sistema operativo reconozca y encuentre los sitios que debe mantener compatibles:

Windows, como es supremamente inteligente, siempre busca las claves y los valores que requiere, si no los encuentra, los crea, en la captura de arriba es donde crea por primera vez lo que necesita.

Básicamente, utiliza la función de RegCreateKey para crear la clave:
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Internet Explorer\BrowserEmulation

Hasta ahí mantiene el mismo patrón del comportamiento de Windows cuando se activa la vista de compatibilidad, sin embargo, abajo Windows utiliza nuevamente la función de RegCreateKey para crear la clave:
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Internet Explorer\BrowserEmulation\PolicyList

Una vez creada esta clave, establece los valores que identifican las páginas que se agregaron a la Lista de compatibilidad, en este caso el de “www.une.net.co” por ejemplo, si se ve directamente desde el Registro de Windows aparecen todos los que se integraron en la lista de la Política:

Como siempre, una vez terminadas las operaciones, Windows vuelve a cerrar las llaves de registro utilizadas.

Ya sabemos cómo Windows identifica una vez creada la política, las páginas que debe mantener en modo de compatibilidad.

Para replicar esto sin Editor de políticas, hacemos lo siguiente:

Nota: Para temas de seleccionar una página, utilizaré la de www.wintecnico.com del gran Maestro Daniel Martín.

En el Equipo donde queramos crear la lista de compatibilidad para todos los usuarios, hacemos clic en Inicio, digitamos Regedit y presionamos INTRO, esto nos abrirá el editor de registro de Windows.

Navegamos hasta la clave:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft

Clic derecho sobre la clave de Microsoft, seleccionamos Nuevo (New) > Clave (Key):

La llamamos Internet Explorer

Nos ubicamos en la clave de Internet Explorer, clic derecho, Nuevo (New) > Clave (Key) y la llamamos BrowserEmulation

Sobre la clave de BrowserEmulation, hacemos clic derecho, Nuevo (New) > Clave (Key) y la llamamos PolicyList; el arbol creado debería verse así:

Finalmente, sobre PolicyList, en el espacio en blanco de la parte derecha, hacemos clic derecho, Nuevo (New) > Valor de cadena (String Value):

El nombre debe ser la dirección completa de la página que deseamos emular en Vista de compatibilidad (Puede ir con o sin www. al principio). Por ejemplo, para este artículo, creé el valor de wintecnico.com

Debemos abrir el Valor recien creado y como contenido, especificamos también la dirección completa de la página, es decir, igual que su propio nombre de valor:

¡Esto es todo!

Si el sitio quedó bien indicado, al abrir nuevamente la página desde cualquier usuario debería quedar en Vista de compatibilidad, sin posibilidad de quitarla:

*Nota: Noten que si no estuviera en Vista de compatibilidad, y se pudiera editar, la barra de direcciones se vería con el icono de la hoja partida a la mitad:

Cada nueva página que deseemos agregar, tendríamos que crearla con los pasos anteriores como un valor de cadena, replicar esto ya pero para otros equipos, bastaría con exportar toda la clave de HKEY_LOCAL_MACHINE e importarla en donde queramos.

Espero que les pueda ser de utilidad, ¡Comentarios bienvenidos!

Saludos,

Checho

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

Checho — Sun, 04 Dec 2011 22:09:00 GMT

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

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

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:

*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ó \\SWATLAB\Perfiles

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

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 \\SWATLAB\Perfiles\%USERNAME%

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:

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-

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

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:

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

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:

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

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:

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

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

Checho — Fri, 04 Nov 2011 15:03:00 GMT

Ya estamos finalizando la serie de artículos sobre la Redirección de Carpetas y Perfiles en Windows 7; en las anteriores entregas, vimos cómo Windows controla y administra la redirección de sus carpetas por medio de Políticas de Grupo, además de cómo era el comportamiento cuando hacíamos la configuración manualmente.

A pesar de esto, como nos hemos dado cuenta, hasta ahora sólo hemos tocado lo que concierne a la redirección de las carpetas de usuario (Documentos, Imágenes, Música, etc), el perfil hasta ahora sigue en su ubicación predeterminada al instalar Windows, es decir, en %SystemDrive%\Users, que normalmente es C:\Users

En este post veremos el procedimiento que corresponde a la redirección de Perfiles, que básicamente, es que no se vayan sólo las carpetas sino todos los archivos que requiere cada perfil para otra partición o ubicación definida.

El procedimiento soportado consiste en utilizar un Archivo de autorespuesta, a comparación con las anteriores maneras, se configura el redireccionamiento desde la instalación de Windows y no cuando éste ya está online (Instalado).

¿Qué necesitamos?

- Los archivos de instalación de Windows 7, tengamos en cuenta que vamos a preparar una imagen, necesitamos entonces copiarlos todos a una carpeta local, para este artículo, estarán en C:\7

- En el Equipo técnico donde está la carpeta con los archivos de instalación, necesitamos tener instalado el Kit de Instalación Automatizada para Windows 7 (WAIK). Si aún no lo tienen, pueden descargarlo desde Aquí.

- Un equipo virtual o físico donde probar el despliegue del sistema operativo.

Configurando Archivo de autorespuesta

Ya hemos visto desde hace tiempo y en varios artículos que el Archivo de autorespuesta es básicamente, un XML de texto plano que le indica a Windows qué debe hacer conforme va transcurriendo la instalación, es decir, le dice qué particionamiento debe tener, idioma, usuarios, y configuraciones adicionales.

Esto da la estupenda oportunidad de pensar en un despliegue totalmente desatendido (Sin interacción de usuario) tanto en Windows como en Server y configurable desde varios gestores (MDT, WDS, SCCM, etc).

Como dije, el Archivo de autorespuesta entrega una grandísima cantidad de configuraciones y personalizaciones que se pueden asegurar en la imagen que quedará finalmente implementada, esto lo hace utilizando el Administrador de imágenes de Windows (SIM) incluido en el WAIK y, básicamente utiliza unos componentes que alojan todas las configuraciones y que se adhieren en diferentes fases que tiene el Archivo de autorespuesta y que a la vez, representan las fases de instalación de Windows.

Lo que haremos será utilizar el subcomponente de FolderLocation, ubicado en el componente de Windows-Shell-Setup para redirigir el perfil a la partición D:\ o a cualquier otra.

¡Empecemos!

Para ejecutar el Administrador de Imágenes de Windows (SIM), hacemos clic en Inicio, Todos los programas, Microsoft Windows AIK; clic derecho en Windows System Image Manager y seleccionar “Ejecutar como Administrador”.

SIM se divide en tres grandes páneles, el primero de Izquierda a derecha donde se encuentra divido en dos llamados Distribution Share que es donde se ubican los recursos adicionales como paquetes a distribuir con la imagen y el que nos interesa aquí que es Windows Image, en éste debemos seleccionar sea la Imagen de instalación (install.wim) o su respectivo archivo de catálogo (install_Windows 7 <Edicion>.clg) para que se presenten los catálogos.

Hacemos clic derecho sobre Select a Windows Image or catalog file y escogemos Select Windows Image…

Debemos ir hasta la carpeta donde ubicamos los archivos de instalación de Windows 7 (En mi caso, en C:\7), ubicar la carpeta Sources y seleccionar el archivo de imagen o catálogo, el más rápido y que sirve sin problemas es el archivo de Catálogo, en mi caso, como es Windows 7 Enterprise, tiene el nombre de install_Windows 7 ENTERPRISE.clg:

Cuando se abre el archivo de catálogo, en el SIM debajo de Windows Image ahora se verá la imagen seleccionada y las carpetas de Components y Packages:

El segundo pánel está compuesto por el de Answer File, aquí irá el Archivo de autorespuesta y todos los componentes adicionados a éste.

Debemos hacer clic derecho sobre Create or open an Answer file y seleccionar New Answer file…

El resultado será el Archivo de autorespuesta con todos los nodos disponibles para agregar componentes:

Hasta aquí sólo agregamos el archivo de catálogo con los componentes y creamos el archivo de Autorespuesta, lo que sigue ahora será enfocarnos en agregar el componente de FolderLocation que hará la redirección de perfiles para que la imagen al instalarse se vayan directo a D:\

A pesar de que el componente principal es FolderLocation para lo que queremos, debemos hacer una configuración adicional y se basa en las particiones del disco, debemos asignarlas desde el Archivo de autorespuesta para que la redirección funcione, si no se hace, no funcionará así se haya especificado el FolderLocation.

La aparente razón es porque Windows no utiliza el nombre para las particiones sino hasta el final cuando las asigna, por tanto, la configuración no se establece al no encontrar la partición a la que se redireccionó ya aplicada (Ver captura de “Sobre asignación de particiones” en la última parte)

El primer paso entonces es ir al panel inferior izquierdo, debajo de Windows Image, expandir el nodo de Components y buscar el de Microsoft-Windows-Setup_6.1.7600.16385_neutral, expandir el subcomponente DiskConfiguration, Disk, CreatePartition, clic derecho y seleccionar Add settings to Pass 1 windowsPE

Debajo de CreatePartition, está ModifyPartition, debemos agregarla de la misma forma también a windowsPE.

Hacemos esto tres veces para cada una, es decir, tres para CreatePartition y tres para ModifyPartition.

En el Archivo de autorespuesta, debajo de windowsPE, se deben ver todos los componentes agregados y aún sin configurar (Color azul claro):

La razón de la que son tres particiones es porque la primera será la Oculta de 200 MB que Windows utiliza para los archivos de BitLocker y de arranque, la segunda será la de instalación del sistema operativo, normalmente C:\, y la tercera será la destinada a la redirección de perfiles, normalmente y para este artículo, la particón D:\

Esta es la configuración que debe tener todo el componente de DiskConfiguration:

DiskConfiguration	WillShowUI: OnError
Disk	DiskID: 0 WillWipeDisk: True
CreatePartition	Order: 1 Size: 200 Type: Primary
CreatePartition	Order: 2 Size: <TamañoEnMB> Type: Primary
CreatePartition	Extend: True Order: 3 Type: Primary
ModifyPartition	Active: True Format: NTFS Label: System Order: 1 PartitionID: 1
ModifyPartition	Format: NTFS Label: Windows Order: 2 PartitionID: 2
ModifyPartition	Format: NTFS Label: Perfiles Order: 3 PartitionID: 3

En el componente de InstallTo, si es que se especifica una instalación desatendida, se le debe indicar que sea en la segunda partición, es decir en DiskID 0, PartitionID 2:

Después de indicadas estas configuraciones para el particionamiento, se debe abrir el componente de Microsoft-Windows-Shell-Setup, clic derecho en FolderLocation y seleccionar Add setting to Pass 7 oobeSystem

En el Archivo de autorespuesta, se selecciona y en la tercera columna de propiedades se le debe indicar una partición y carpeta preferida si se desea a FolderLocation y ProgramData, en mi caso, todo para D:\Users y D:\ProgramData respectivamente.

*Nota: Ambas carpetas se recomiendan enviarlas a la misma ubicación.

*Nota: Recomiendo siempre poner una carpeta a crear, preferiblemente de igual nombre que la que maneja Windows (Users ó Usuarios y ProgramData), si sólo se pone la unidad, pueden dañar el servicio de perfiles y obtener este error al intentar ingresar por primera vez:

Esto es todo, adicionalmente se puede configurar el Archivo de autorespuesta para que la instalación sea totalmente desatendida.

Una vez terminado, se debe ir al menú File, Save as y guardar el archivo en la carpeta Raiz de los archivos de instalación de Windows con el nombre Autounattend.xml, en mi caso en C:\7

Si desean, pueden descargar el Archivo que utilicé para este artículo que redirige a D:\ y está totalmente desatendido, exceptuando el nombre del equipo y el de usuario, además de que copia el perfil de usuario predeterminado teniendo en cuenta que se puede trabajar con una imagen maestra capturada. Todo para que lo tengan como referencia:

Construyendo Imagen…

Ya todo está listo, nos queda crear la imagen .ISO de nuestra instalación, para eso vamos a Inicio, Todos los programas, Microsoft Windows AIK, clic derecho sobre Deployment Tools Command Prompt y seleccionamos “Ejecutar como administrador”

El comando para construir la imagen es:

oscdimg –b<Directorio7>\Boot\Etfsboot.com –u2 –h <Directorio7> <Ubicacion>\Name.iso

Donde <Directorio7> es la carpeta que contiene los archivos de instalación de Windows, <Ubicacion> es el directirio donde deseamos guardar la imagen ISO y “Name.iso” es como deseamos llamar la imagen con la extensión .ISO.

En mi caso, sería:

oscdimg –bC:\7\Boot\Etfsboot.com –u2 –h C:\7 C:\Win7FD.ISO

Sobre asignación de particiones

Como había mencionado en el principio del artículo, estamos particionando desde el Autorespuesta es porque así se haga el particionamiento dinámico en Windows, nos estamos asegurando de que el XML le diga al sistema operativo que la segunda partición es la que tendrá los Perfiles, si no lo hacemos, tal vez habría que jugar con el cómo Windows administra las letras de particiones:

En la captura anterior por ejemplo, mientras se hace la expansión de archivos en la instalación de Windows, la primera letra asignada es la C:\, pero no es a Windows, sino a la partición oculta de 200 MB mientras se hace la instalación, la letra que es Windows es la D:\ y la que tiene Perfiles es finalmente la F:\, por lo que si no particionáramos desde el Autorespuesta habría que saber en este caso esto e indicarle a FolderLocation que guarde en F:\, probáblemente al terminar la instalación que Windows pasa a ser C:\ porque la partición oculta se queda sin unidad y Perfiles pasa a ser D:\, tendría ahí los perfiles de usuario entonces.

*Nota: Estaré probando esta teoría pronto, pero veo innecesario teniendo el Autorespuesta de complicarnos en este artículo buscando cuál es cuál.

El último paso es finalmente instalar grabando la ISO en alguna unidad DVD/USB o bien montándolo en un equipo virtual y una vez terminado, verificar que efectivamente en la partición D:\ (O en la que se haya escogido) esté la carpeta de Users con el respectivo perfil creado:

Como ven, quedó la carpeta Users en la unidad D:\ tal y como debería de ser.

En el próximo post estaremos terminando esta serie de artículos explicando cómo realizar este mismo proceso manual, aunque no soportado.

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

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

Checho — Tue, 11 Oct 2011 19:57:00 GMT

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:

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:\Windows\System32, 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:\7\Sources\install.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:\7\Sources\install.wim /Index:1 /MountDir:C:\Mount

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

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:\Users\Default 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%\System32\Config, normalmente C:\Windows\System32\Config

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 usuario\Plantillas Administrativas\Escritorio en el Editor de Políticas de Grupo.

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:

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:

Como ven, se está abriendo y haciendo consulta sobre la clave:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\GroupPolicyObjects

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:

Dentro de la clave en cuestión, se hace referencia a otra subclave ubicada por usuario en el Registro: User\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer

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 (User\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer) 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_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer

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_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer

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

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:\Mount\Windows\System32\Config\Software

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

Reg Load HKLM\Temp <RutaHive>

Donde <RutaHive> es la ubicación del archivo Hive que deseamos cargar, para este caso por ejemplo sería C:\Mount\Windows\System32\Config\Software

El comando para este artículo quedaría:

Reg Load HKLM\Temp C:\Mount\Windows\System32\Config\Software

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

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_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer,

Se modificaría el registro para que quedara:

HKEY_CURRENT_USER\Temp\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer

*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 HKLM\Temp

*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

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

*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 controlador de Process Monitor que causaba un remitente Pantallazo Azul; Windows PE, Autoruns y su solución.

Checho — Wed, 31 Aug 2011 08:25:00 GMT

Hola a todos,

Quizá este caso les pueda parecer un poco extraño por el posible causante, pero es una excelente oportunidad de ver que cuando hasta en el más fatal de los casos siempre quedará “algo” por hacer.

Como he venido escribiendo en los anteriores artículos que guardan similitud con este, lo dividiré en “El Problema”, “La posible causa” y “La solución”. El objetivo es como siempre, poder compartir todo lo que más pueda hasta donde mi conocimiento me lo permita y claro está, dejar abierto el espacio para que compartan sus comentarios al respecto si así lo desean.

El problema

Desde hace unos días estaba escribiendo un artículo del que estoy muy agradecido porque por fin, tenía la oportunidad de ver una característica muy interesante del fantástico Process Monitor llamada Boot Logging.

Básicamente, consiste en activar el monitoreo de Process Monitor para que en el próximo reinicio de Windows, su controlador se active como uno de Arranque de inicio, lo que le permite correr como uno de los primeros en la secuencia de inicio, mucho antes que la mayoría de los demás controladores. Al poder hacer esto, Process Monitor podrá monitorear toda la primera actividad, incluyendo lo que se carga adicionalmente mientras Winlogon hace su tarea y podrá estar disponible la próxima vez que se ejecute Process Monitor.

Este log es muy útil porque podríamos llegar a diagnosticar y reparar problemas que no se podrían detectar fácilmente mientras Windows ya está en ejecución.

Para activar esta funcionalidad, basta con abrir Process Monitor, ir al menú Options y habilitar “Enable Boot Logging”:

Al hacer esto, basta con cerrar Process Monitor y reiniciar el sistema para que funcione. El problema en mi caso es que después de activarlo y reiniciar el sistema me encontré con este grata sorpresa:

*Nota: El proceso lo estuve realizando en una máquina virtual, lo que me permitió tener todas las capturas de una forma clara.

Como ven, lo que obtuve fue el famoso Pantallazo Azul o Blue Screen Of Death (BSOD) como se le conoce. En la mayoría de las ocasiones, el equipo presenta muy esporádicamente este comportamiento y por lo general al segundo reinicio Windows entra normalmente.

Lamentablemente para mí, esto no pasó y sin importar de qué forma intentara iniciar (Modo seguro, Modo de consola, Mido de depuración, sin funciones de red), siempre volvía a dar el pantallazo azul justo después de la animación inicial.

Un Pantallazo Azul como tal, realmente es un mecanimos de protección que nos indica que por lo general, se están produciendo operaciones a nivel de kernel no permitidas como que un controlador está intentando acceder a un espacio de memoria privado. Este tipo de inconvenientes por controladores causan casi un 90% o más de los Pantallazos Azules, otro pequeño porcentaje se da por fallos de Hardware como energía o cuando algun componente está dañado.

Windows entonces, para proteger su propia integridad detiene todas las operaciones, dibuja el BSOD con un formato estándar (Operación, información, código, etc) y posteriormente colecta los datos para general el Volcado de memoria (Dump File) que guarda en el próximo reinicio en el directorio de Windows con el nombre MEMORY.DMP, además de otros Minidumps que guarda en la carpeta con el mismo nombre y que son útiles para un análisis muy general puesto que el volcado de memoria completo puede llegar a ser muy pesado ya que almacena todo lo que había en RAM hasta el momento del Pantallazo Azul.

La posible causa

Así como Windows se protege así mismo con el Pantallazo Azul, también tiene una serie de herramientas embebidas para hacer diagnóstico y reparación sobre todo para casos en que el sistema operativo no inicia normalmente.

Para esto basta con presionar varias veces F8 al prender el equipo para que en las opciones avanzadas podamos entrar en la Reparación de equipo. En estos casos, como Windows es lo suficientemente inteligente, después de un reinicio forzado presenta la opción de reparación sin que presionemos alguna tecla:

Al iniciar Reparación de equipo, normalmente Windows busca problemas en los archivos de arranque de Windows, si los encuentra y está en la posibilidad de repararlos lo hace, si no encuentra sin embargo y existe un punto de restauración lo presenta para que volvamos a ese estado de imagen donde el equipo estaba funcionando correctamente:

*Nota: El entorno de Reparación de equipo está basado en un Windows PE.

Como estaba sobre un entorno virtual y no era mi prioridad reparar el problema, decidí restaurar el sistema para poder continuar escribiendo el contenido que había dejado pendiente. En efecto, Windows se restauró y estaba operacional nuevamente, así que realicé otras operaciones para el artículo y como ví que reiniciaba correctamente de nuevo pensé en activar la función de Boot Logging puesto que aún no lo había podido ver en acción y lo requería.

Confiado entonces, lo habilité reinicié mi equipo pero para mi gran sorpresa, nuevamente obtuve el mismo Pantallazo Azul, y otra vez recurrente, así que no podía iniciar Windows normalmente.

¿A qué se debía?

Definitivamente, la característica que estaba activando en Process Monitor tenía algo que ver con que al próximo reinicio de Windows siempre volviera a ocurrir el Pantallazo Azul.

Me costaba creer que la mejor herramienta que existe en mi concepto para hacer Windows Troubleshooting y que tanto me ha ayudado, esta vez estuviera en la lista negra.

A pesar de todo me inclinaba más porque fuera otro controlador pero, me acordé que cuando se activa el Boot Logging, el controlador de Process Monitor pasa a ser uno de los primeros en iniciar en el orden de arranque de Windows (Como lo describí anteriormente). En este orden de ideas, si era uno de los primeros en iniciar (Tal vez el primero) con más seguridad sí sería culpable.

Para comprobarlo debía entonces lograr desactivar ese controlador pero, con Windows impidiéndome reiniciar y la reparación de inicio sin darme muchas alternativas ya que ni el Volcado de memoria (MEMORY.DMP) se estaba creando sólo quedaba una posible forma.

Paradógicamente, para reparar el problema que estaba generando una herramienta de Sysinternals, requería otra de las que componen la suite; me estoy refiriendo por supuesto a Autoruns.

La solución

Autoruns, entre sus tantas estupendas funcionalidades provee una única que consiste en realizar un análisis de lo que está iniciando con Windows aun cuando el equipo se encuentra apagado u offline. A esta característica se le llama “Analyze Offline System” y se activa desde el menú File de Autoruns.

Para esto, debo garantizar que Autoruns tenga acceso al equipo afectado y que está Offline y como no puedo entrar a Windows requiero recurrir al mismo método que utiliza Windows para reparar el equipo y es a un Windows PE (Entorno de Preinstalación).

Como el que está en el medio de Windows y de forma embebida con su instalación puesto que no tiene ninguna herramienta de Sysinternals, Autoruns en este caso, debía proceder a crear mi propio Windows PE y asegurarme de que la herramienta estuviera disponible una vez hecha la imagen.

Esta gran ventaja me la da el Kit de Instalación Automatizada para Windows 7 (WAIK); específicamente el Deployment Tools Command Prompt que es desde donde puedo copiar los archivos necesarios para el Windows PE.

Como el Windows PE es un mini sistema operativo que carga en memoria RAM, tiene la ventaja de que sigue siendo un sistema operativo y cuenta con varias funciones como las de red, además de poder interactuar con varias aplicaciones que soporten esta ejecución. Así, podría ejecutar Autoruns desde el Windows PE corriéndolo en el Equipo afectado y podría hacer uso de su característica de análisis sin conexión para desactivar el controlador de Process Monitor y ver si en verdad había ocasionado todo.

Construyendo el medio Windows PE + Autoruns

Como dije antes, para construir el Windows PE necesitamos tener WAIK instalado, ya he mostrado cómo es todo el procedimiento en otros artículos pero lo repetiré aquí por el valor agregado de que no usaremos esto para despliegue sino para solución de problemas.

*Nota: Si no tienen WAIK, lo pueden descargar desde Aquí.

Debemos instalar el WAIK en un equipo, ir a Inicio, Todos los programas, Microsoft Windows AIK, clic derecho sobre Deployment Tools Command Prompt y seleccionar “Ejecutar como administrador”

En la consola ejecutamos: Copype.cmd x86 <DirectorioPE>

Donde <DirectorioPE> es una ruta local o de red donde queremos guardar los archivos del Windows PE. Para mi caso, no me compliqué mucho y lo creé en el directorio C:\ con el nombre WinPE, el comando quedaría entonces así: Copype.cmd x86 C:\WinPE

*Nota: Sin importar que sea para reparar un problema utilizando Autoruns en un sistema de 32 o 64 bits, se debe crear el Windows PE de 32 bits.

Dentro de la carpeta que se crea (En este artículo por ejemplo WinPE) veremos dos carpetas (ISO y Mount) y dos archivos (etfsboot.com y winpe.wim). En la carpeta ISO es donde debemos guardar todo lo que deseamos que tenga el Windows PE ya que es desde la que generaremos la imagen .ISO.

En entornos de implementación, normalmente copiabamos la herramienta de ImageX.exe desde los archivos del WAIK a la carpeta ISO, en este caso lo que haremos será copiar Autoruns.exe, por supuesto, previamente lo debemos descargar desde la página oficial.

La carpeta ISO debería verse así:

Una vez copiamos el ejecutable de Autoruns (Autoruns.exe) volvemos a abrir el Deployment Tools Command Prompt y esta vez haremos la copia del winpe.wim a la carpeta \Sources renombrandolo a boot.wim para que el Windows PE pueda arrancar correctamente cuando se cargue.

Para esto, ejecutamos:
copy <DirectorioPE>\winpe.wim <DirectorioPE>\ISO\Sources\boot.wim

Para este artículo, sería:
copy C:\WinPE\winpe.wim C:\WinPE\ISO\Sources\boot.wim

*Nota: Desde el Explorador también podemos hacer la copia, además de esto podemos verificar que la carpeta Sources sí tenga el archivo boot.wim.

Ejecutamos por última vez el Deployment Tools Command Prompt y ya que tenemos los archivos necesarios para hacer Troubleshooting (Solución de problemas) podemos crear la imagen .ISO del Windows PE con el siguiente comando:

oscdimg –b<DirectorioPE>\etfsboot.com –u2 –h <DirectorioPE>\ISO <DirectorioISO>\WinPE.iso

Donde <DirectorioISO> es también una ubicación donde deseemos guardar la imagen .ISO del Windows PE.

Para mi caso, el comando sería:

oscdimg –bC:\WinPE\etfsboot.com –u2 –h C:\WinPE\ISO C:\WinPE.iso

¡Listo! Con esto ya podemos analizar cualquier sistema offline con sólo arrancar desde el Windows PE, obviamente debemos grabarlo sea en una USB o bien en un medio CD/DVD.

Esto fue lo que yo hice, posteriormente inicié el equipo en el que tenía el Pantallazo Azul que no dejaba arrancar correctamente.

Volviendo al caso…

Una vez entró al Windows PE, lo primero que hice fue identificar cuál era la unidad que le había asignado ya que es la que contiene todos los archivos del medio. Normalmente, X: es la unidad temporal del Windows PE, C:\ la del sistema operativo y si no hay más dispositivos, la unidad D:\ será la del Windows PE.

*Nota: Si hay más dispositivos que requieran tener letras de unidad, se debe seguir buscando en orden alfabetico para hallar la del Windows PE o bien utilizar la línea de comandos de Diskpart para identificar los volúmenes que estén disponibles.

Para verificar el contenido, basta con ejecutar Dir una vez estemos en la unidad:

En mi caso, procedí a ejecutar Autoruns.exe desde la raiz de mi Windows PE, al abrir me dirigí al menú File y seleccioné “Analyze Offline System” para poder tener control de lo que estaba arrancando con Windows:

En la ventana de Offline System siempre se debe especificar el directorio donde está instalado Windows (Normalmente C:\Windows) y el directorio del usuario a analizar. Para este caso, como ocurría para todos (Ya que era antes de iniciar sesión inclusive), le indiqué el directorio donde están todos los usuarios, es decir: C:\ProgramData

Después presioné F5 para que actualizara los resultados que estaba arrojando Autoruns y me fui directamente a la pestaña de Drivers para poder ver todos los controladores que estaban iniciando con Windows.

En caso de que estemos realizando este proceso y no sepamos por qué controlador empezar, lo más normal es desactivar primero los controladores que no hacen parte de Microsoft, para hacerlo basta con quitar la selección sobre el controlador específico y cerrar Autoruns, el trabajo de él será hacer los cambios pertinentes para que Windows no tome el controlador en el próximo reinicio.

Lo que yo hice, sabiendo que algo tendría que ver Process Monitor (Más específicamente su controlador) fue utilizar la función de búsqueda (CTRL + F) e indicarle el nombre del proceso interno “procmon”:

Como pensé, el controlador estaba iniciando con Windows (Por haber activado el Boot Logging claro está):

Lo que hice fue quitarle la selección para arriesgarme a realizar la prueba otra vez iniciando Windows:

Cerré Autoruns, cerré la ventana de Consola de comandos para que Windows reiniciara automáticamente, esta vez no entré al Windows PE sino que dejé iniciar Windows normalmente y ¡Oh sorpresa!

Ahora no hubo ningun pantallazo azul, Windows entonces inició normalmente y sin ningún tipo de problema:

Quizá en este caso tuve mucha suerte puesto que pude identificar rápidamente un posible causante y de ahí tener una base, pero en estos casos suele ser muy útil deshabilitar todo lo que no sea de Microsoft al inicio (Aunque este en parte lo era) e ir probando el arranque. A menos de que sea problema de máquina, podríamos llegar a tener esta suerte en la mayoría de las ocasiones cuando ni Windows deja iniciar.

He aquí otra gran ventaja de Windows PE y de Windows Sysinternals, espero que les pueda ser de utilidad a algunos.

Estaré actualizando el post en caso de que obtenga más información sobre lo que me sucedió con Process Monitor.

Saludos,

Checho

Establecer un fondo de pantalla predeterminado de forma manual para todos los usuarios en Windows 7

Checho — Wed, 17 Aug 2011 23:49:00 GMT

Normalmente, como ya lo hemos visto en otros artículos, existen varias formas de predeterminar o establecer configuraciones o personalizaciones en un ambiente Windows, la más común es hacerlo manualmente, tal vez por implementación, utilizando herramientas del sistema operativo o de terceros o hacer un despliegue de políticas de grupo sea local o a nivel de Dominio.

El propósito de este post es lograr establecer una simple operación como el fondo de pantalla para que se convierta en el predeterminado para todos los usuarios, la diferencia será que lo haremos a nivel de registro que aunque se convierta en tal vez la última opción normalmente por lo que puede representar, indagándolo es tal vez la forma en que “configurando se aprende” como pretendo mostrar aquí, por lo menos desde donde mis pocos conocimientos me lo permiten.

*Nota: El artículo en su gran mayoría está como he tratado de hacerlos todos, explicando lo más que puedo para terminar con lo que se consideraría la solución o el Tip en este caso, como siempre, pueden saltarse si quieren e ir a la última parte:
“Por fin, Predeterminando el Fondo de pantalla para todos los usuarios…”

Explorando Windows…

Windows predeterminadamente establece un Tema que contiene el fondo de pantalla con el logo principal del sistema operativo pero, ¿Qué pasa cuando se establece ese tema? para ver los que nos conviene que es el fondo de pantalla, podemos hacer uso de Process Monitor de Sysinternals, activarlo cuando cambiemos el fondo y volver a ver los resultados.

Si buscamos por “Wallpaper”, siguiendo el patrón de detenernos en palabras que concuerten dentro de todo el trazo que entrega Process Monitor, podremos ver lo siguiente:

La primera columna de “Operation” determina el tipo de operación que se está haciendo, además de la función que se está utilizando.

Como ven en la captura anterior, la primera operación que resalto está utilizando la función ReadFile e indica la ruta de una imagen llamada “img0.jpg” ubicada en:
C:\Windows\Web\Wallpaper\Windows\img0.jpg

Si abrimos en el Explorador de Windows o desde Process Monitor, hacemos clic derecho sobre la ruta y seleccionamos “Jump to”, veremos que la imagen hace referencia a la que precísamente Windows utiliza en el tema predeterminado:

Como la ruta está en un directorio global, todos los usuarios que se crean y que mantienen este tema predeterminado, harán la misma consulta al fondo de pantalla por lo que, si remplazáramos este fondo de pantalla por una imagen personalizada en formato .jpg lograríamos que todas las cuentas tuvieran el mismo fondo. Sin embargo, no es lo recomendado ni lo que haremos porque está protegido y administrado con una de las cuentas que actúan como servicio para operaciones especiales TrustedInstaller.

Como el resultado es satisfactorio (SUCCESS), Windows procede a realizar la segunda operación (Retomando la primera captura) y procede a utilizar la función WriteFile que escribe sobre el directorio de Roaming destinado para el usuario desde donde se está consultando, por ejemplo para el mío que se llama Ult64 escribe en:
C:\Users\Utl64\Roaming\Microsoft\Windows\Themes un archivo llamado TranscodedWallpaper.jpg. Como en la anterior operación, si vamos más a fondo y vemos qué imagen contiene ese archivo, veremos lo siguiente:

Como ven, se trata del mismo fondo de pantalla de la imagen (img0.jpg), esto quiere decir que Windows después de leer la ubicación del primero, sobreescribe este con diferente nombre, (Pueden probarlo cambiando de tema y verán que el fondo siempre corresponderá al que está aplicado a la pantalla en el momento).

La pregunta es, ¿Para qué sirve esta ruta? Pues bien, la respuesta como siempre la tiene Process Monitor; y es que si seguimos buscando nos encontraremos esto:

Básicamente, Windows utiliza la función RegOpenKey para abrir la clave de HKEY_CURRENT_USER\Control Panel\Desktop, hacer la consulta del valor (RegQueryValue) Wallpaper y además de establecerlo utilizando la función RegSetValue (Ver lo que está resaltado en rojo).

Es muy normal este tipo de operaciones, lo interesante está es que si abrimos el contenido del valor Wallpaper desde el Editor de Registro de Windows (Regedit.exe), nos encontramos con una grata sorpresa:

¡Aquí es donde aparece la famosa ruta!
A las conclusiones que puedo llegar es que al establecerse un tema, a pesar de realizar la primera consulta en los fondos predeterminados, utiliza el directorio y el nombre de TranscodedWallpaper.jpg donde Windows puede escribir a su gusto por lo que los cambios serán siempre dinámicos y sin problema de permisos.

Lastimosamente no podemos predeterminar un fondo de pantalla remplazando sólo la ruta que aparece en el valor de Wallpaper porque cada que se cambia manualmente el fondo, la ruta se sobreescribe por lo que el cambio no servirá de nada.

Ya vimos qué sucede cuando aplicamos un tema con su respectivo fondo de pantalla manualmente, ahora, analicemos un poco el procedimiento cuando se aplican las políticas de grupo:

Explorando las Políticas…

Las políticas de grupo (GPO) son el mejor y más correcto método para administrar nuestros equipos clientes, por lo general unidos a un Dominio donde siempre se manejará una gestión centralizada pero además existen políticas locales que pueden ser creadas o manipuladas desde Windows en ediciones específicas, para Windows 7 en las ediciones Enterprise y Ultimate.

Si se quiere predeterminar un fondo de pantalla para todos los usuarios, si los equipos están unidos a un dominio, esta debería ser la forma de hacerlo, y aunque no nos centraremos en esto, el procedimiento es relativamente fácil:

En el Editor de políticas de grupo, se debe ir a la siguiente ruta:

Configuraciones de usuario\Plantillas administrativas\Escritorio\Active Desktop

La política en cuestión se llama Tapiz de escritorio:

Al abrir la Política, veremos que basta con habilitarla, indicarle una ruta a una imagen con formato .jpg y un Estilo de papel tapiz (Ajustado, Centrado, Expandido, etc):

*Nota: Como las opciones de la política lo especifican, se le puede indicar tanto una ruta local como un recurso compartido con el formato estándar.

Hasta aquí es el procedimiento normal, pero nuevamente ¿Qué pasa cuando se aplica esta política?

Si monitoreamos nuevamente con Process Monitor y volvemos a utilizar búsquedas basándonos en palabras relacionadas con lo que estamos haciendo, por ejemplo “Wallpaper” empezaremos a ver algunos resultados muy interesantes:

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

Como verán, Windows al momento de aplicar las políticas hace unas operaciones sobre la clave respectiva a Configuración de usuario en las Políticas de grupo:

HKCU\Software\Microsoft\Windows\CurrentVersion\Group Policy Objects\{B14D9D7C-7728-4C31-96FC-A59F1AB2D6E3}User

Allí crea y consulta dos valores, Wallpaper y WallpaperStyle bajo la subclave:

User\Software\Microsoft\Windows\CurrentVersion\Policies\System

Si aprovechamos de nuevo las ventajas de Process Monitor, más específicamente su función de hacer Jump to directo a la clave desde la que se lanza veremos que estos dos valores contienen lo que quizá terminarían de configurar que pertenecen a los que estableció la Política de grupo:

El contenido de la cadena del primera valor corresponde a la ruta de la imagen que establecí como fondo de pantalla predefinido para todos los usuarios (Wallpaper), el contenido del segundo valor (WallpaperStyle) corresponde al tipo de ajuste que tendrá la imagen en el escritorio (Extendida, Ajustada, etc).

Sin embargo, todo lo que se escriba en esta clave (HKCU\Software\Microsoft\Windows\CurrentVersion\Group Policy Objects) sea por usuario o máquina, sólo determina las políticas aplicadas y los valores utilizados. Es decir, crear estas claves y subclaves junto con sus valores manualmente no aplicarán la política de la misma forma (En un principio creí que así sería) y es que, cada que se aplica una nueva política se crea un tipo de identificador para ésta debajo de esta clave.

Para encontrar dónde realmente estaba haciendo el cambio en el registro y que el sistema operativo tomara la configuración bastaba con deterse a mirar más la segunda parte de esta clave; como nos damos cuenta la primera parte hasta “Group Policy Objects” se refiere a la ubicación en el subarbol de HKEY_CURRENT_USER (HKCU) pero, después del ID está indicando otro adicional (User\Software\Microsoft\Windows\CurrentVersion\Policies\System), si seguimos esto, adicionándole por supuesto el HKEY_CURRENT_USER al principio veremos que en efecto esta clave existe y que además nos da más información:

Tal cual lo había especificado la política y las claves anteriores, aquí estaban de nuevo los valores Wallpaper y WallpaperSytle con la configuración que se le entregó utilizando el Editor de políticas de grupo.

Para confirmar de que esta clave y valores se creaban sólo así, volví al Editor de Políticas, abrí la de Papel tapiz nuevamente y la cambié a No configurada que se comporta en este caso de la misma forma que Desactivada y en efecto, la clave despareció (Después de actualizar con F5 el Editor de Registro claro):

En conclusión, lo que hace la política es crear los valores Wallpaper y WallpaperStyle con sus respectivas cadenas tanto en la clave donde almacena las políticas creadas como en la ruta dentro del Registro para que aplique la configuración, en este caso del fondo de pantalla en:

HKEY_CURRENT_USER\Software\Microsoft\Windows\Current Version\ Policies\System

Lo triste en mi perspectiva de esto es que la configuración para un fondo de pantalla predeterminado está bajo el subarbol de HKEY_CURRENT_USER (HKCU) y si recordamos bien, cada Perfil de usuario en Windows contiene una configuración diferente de este subarbol partiendo de lo que entrega la plantilla predeterminada de Windows almacenando todo en el archivo NTUSER.DAT dentro de la carpeta por perfil. Pueden ver un poco más en detalle lo del Perfil de usuario en Este artículo.

La pregunta es entonces, si esto era así ¿Cómo replica Windows la configuración por usuario a todos los perfiles que existen actualmente en el sistema cuando se aplica una de estas políticas?

La respuesta a esa pregunta tenía que estar en tratar de entender un poco más el proceso y es aquí cuando se llama nuevamente al Log que anteriormente había recogido con Process Monitor, y después de buscar un poco aún con la palabra “Wallpaper” encontré esto:

Primero, hay unas operaciones a nivel de sistema de archivos que utilizan un archivo Registry.pol, posteriormente Windows realizaba unas operaciones a nivel de Registro que incluían la creación de nuestra clave en cuestión con su respectivo valor (Wallpaper), después de hacer unas lecturas, procede a cerrar la clave y posteriormente a escribir un archivo en la carpeta del perfil con el que estaba activo en el momento llamado ntuser.pol, por último de nuevo hace la operación de creación de claves y valores respectivos pero para el segundo valor (WallpaperStyle). Siguiendo el monitoreo, volvía a escribir el archivo ntuser.pol pero no se muestra en la captura anterior.

Resulta que estos archivos cumplen una función específica y que daba respuesta a la pregunta planteada anteriormente. Ambos son creados y utilizados sólo cuando se activan o se gestionan políticas de grupo pero el primero, Registry.pol contiene toda la configuración de las políticas aplicables y además determina cómo se deben aplicar, el segundo por su parte, ntuser.pol es el que hace el trabajo “duro” y es el de replicar estas configuraciones que aplican por usuario a todos los perfiles de la máquina, forzando así que cuando el usuario inicia sesión tome los cambios que se han establecido.

Como ven, éste último es el que hace la réplica y con esto sabemos cómo es que resultan afectados todos los perfiles bajo HKEY_CURRENT_USER y además del por qué con establecer manualmente la política no basta.

De cualquier forma, esto es un resultado algo triste porque esta configuración no se puede realizar a nivel de máquina, es decir por HKEY_LOCAL_MACHINE (Aún así lo intenté) y no hay cómo (O no se cómo todavía) replicar lo que hace cuando se aplica una política.

Con esto confirmamos que el mejor método es hacerlo por políticas locales o de dominio pero, por fin entra lo que en primera es el objetivo del artículo:

¿Qué pasa cuando yo no tengo una edición con la que pueda trabajar con políticas de grupo y quiero tener este comportamiento de fondo predeterminado?

Por fin, Predeterminando el Fondo de pantalla para todos los usuarios…

Si no contamos con una edición como Windows 7 Enterprise o Ultimate o por lo menos, estamos unidos a un Dominio con Windows 7 Professional para que tome estas configuraciones y queremos tener un fondo de pantalla predeterminado, debemos entonces pasar a “forzar” nosotros este comportamiento ayudánonos de lo que descubrimos previamente siguienteo las políticas de grupo.

Hay dos cosas que debemos de tener en cuenta, los usuarios próximos a crear su propio perfil y los que actualmente tienen un perfil asignado en la máquina local, lamentablemente con este método no todo puede ser tan automatizado pensando en lo segundo (Usuarios que ya tienen perfil) pero se puede tratar de mitigar lo más posible.

Primero tomaremos ventaja de lo que podemos forzar a predeterminar y es el comportamiento para los nuevos perfiles de usuario que se van a crear y es que si la clave de HKEY_CURRENT_USER no contiene las claves y valores que predeterminan un fondo de pantalla podemos cargar el perfil predeterminado de Windows e indicar nosotros qué es lo que queremos que tenga como fondo de pantalla desde el momento que crea el perfil.

El proceso detallado para cargar y detallar el perfil predeterminado está en este artículo por lo que no entraré mucho en detalle, sin embargo mostraré de nuevo los parámetros para hacerlo por línea de comandos para que se entienda el paso a paso.

En el Equipo donde se crearán los perfiles, buscamos y seleccionamos una imagen de algun directorio del sistema, preferiblemente ubicarla en alguna unidad que sea global para todos los usuarios y que no corra el peligro de ser eliminada si un usuario se borra con su contenido, debe tener un formato (.JGP). Después de esto, hacemos clic en Inicio, tecleamos CMD, clic derecho sobre el resultado y seleccionamos “Ejecutar como administrador”.

En la consola de comandos ejecutamos la siguiente línea para cargar el Perfil predeterminado:

Reg Load HKLM\Default %SystemDrive%\Users\Default\NTUSER.DAT

Lo que haremos será crear la clave de System y los valores de Wallpaper y WallpaperStyle que determinarán el fondo de pantalla a ser utilizado y la ubicación dentro del escritorio.

Abrimos el Editor de Registro de Windows yendo al menú de inicio, tecleando Regedit y tecla ENTER.

En el Editor de Registro navegamos hasta la siguiente clave:

HKEY_LOCAL_MACHINE\Default\Software\Microsoft\Windows\CurrentVersion\Policies

Hacemos clic derecho sobre la clave de Policies y seleccionamos Nuevo, Clave:

El nombre de la clave debe ser System

En el panel de la mitad de la ventana de Editor de Registro hacemos clic derecho, seleccionamos Nuevo y Valor de cadena:

El nombre que le debemos indicar es: Wallpaper

Repetimos el paso de creación del valor de cadena y el nombre se lo especificamos como WallpaperStyle.

Debe verse similar a la siguiente captura:

Como no tiene nada aún, no nos servirá, para que funcione hacemos doble clic en cada una, en la primera Wallpaper debemos especificar como contenido la ruta del Fondo de pantalla que deseamos que todos los nuevos usuarios que se creen tengan, teniendo en cuenta que no lo podrán cambiar:

Hacemos clic en Aceptar para guardar el cambio y posteriormente doble clic en el segundo Valor WallpaperStyle, en éste debemos especificar la forma en que deseamos que se acomode en el escritorio con un número que identifique el comportamiento:

1: Rellenar
2: Expandida
3: En mosaico
4: Centrada
5: Ajustar

El resultado final debe ser similar al siguiente:

Cerramos el Editor de Registro, abrimos la Consola de comandos sea porque se haya minimizado o repitiendo los pasos para volver a abrir (Menú inicio, CMD, clic derecho, Ejecutar como administrador) y descargamos el Hive para que guarde los cambios y los establezca en cada nuevo perfil con el siguiente comando:

Reg unload HKLM\Default

*Nota: Asegúresen de que tanto en la carga como en la descarga del Perfil predeterminado el resultado indique que se completó correctamente, de lo contrario no se realizará la operación y puede generar problemas a los nuevos o existentes perfiles.

Todo está listo, la prueba de fuego es crear una nueva cuenta cuenta de usuario y ver que en efecto, se le esté aplicando el fondo de pantalla elegido y que además, no lo pueda cambiar:

Ya los nuevos Perfiles funcionarán como deseamos, el problema sigue es con los que ya están existentes y para nuestra mala fortuna, como comenté en la fase donde exploraba el comportamiento de las Políticas de grupo (Ver Explorando las Políticas) no podemos replicar el mismo comportamiento de forma masiva a nivel de registro porque el cambio está bajo HKEY_CURRENT_USER, sin embargo está en nostros encontrar alternativas.

Lo que podemos hacer es primero crear la correspondiente clave para que se fuerce la política (Muy similar a la anterior) y posteriormente distribuirla y ejecutarla en todos los usuarios que ya estaban activos localmente para que se aplique.

Para crear la clave, abrimos el Editor de Registro yendo a Inicio, teclea Regedit, clic derecho sobre el resultado y seleccionar “Ejecutar como administrador”.

Navegamos hasta la clave:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies

Aquí como para el perfil predeterminado, hacemos clic derecho sobre la clave de Policies, seleccionamos, Nuevo y Clave.

La clave debe llamarse igualmente System.

Ahora, sobre la derecha debajo del Valor predeterminado hacemos clic derecho, Nuevo, Valor de cadena y la llamamos Wallpaper.

Realizamos el paso nuevamente y llamamos a la nueva clave WallpaperStyle

Para crear esto también bastaría con abrir un Blog de notas y copiar:

Guardarlo con cualquier nombre y extensión .REG, ejecutarlo, luego dirigirse hasta la clave y rellenar el contenido tanto de Wallpaper como de WallpaperStyle entregándole la ruta del fondo de pantalla y el tipo de acomodación en el escritorio.

*Notas:
No hice capturas de pantalla porque es exactamente el mismo proceso descrito en la creación del la clave para el Perfil predeterminado.

La distribución se podría pensar en apoyarse por ejemplo de PsExec de Sysinternals.

¡Todo está listo! Una vez reiniciemos el equipo luego de aplicarle estos cambios a los usuarios que ya tenían perfil local, el fondo de pantalla se les debe cambiar al especificado y no se podrá cambiar.

De antemano disculpas por la extensión del post pero espero que pueda ser de utilidad.

Saludos,

Checho

Editando el Perfil de Usuario Predeterminado en Windows 7

Checho — Thu, 11 Aug 2011 12:23:00 GMT

Hola a todos,

De nuevo como cada determinado tiempo, pido disculpas por la poca recurrencia en los artículos, afortunádamente de nuevo estoy más liberado y como todos sabemos en el próximo mes de Septiembre probáblemente inicie un nuevo ciclo de Windows (Build) con el que trataré de compartir todo el contenido y aprendizaje que obtenga aquí en el Blog.

Hoy quiero compartirles un pequeño Tip que, personalmente me ha servido mucho.

Introducción a los Perfiles de Usuario

Como les he contado en artículos anteriores, cada que una nueva cuenta de usuario, más conocido como un Perfil se crea en Windows 7 (En versiones anteriores sucede lo mismo) bajo el arbol de registro, el subarbol HKEY_CURRENT_USER (HKCU) contiene las personalizaciones propias del usuario, es decir, por cada perfil que hay en el equipo hay una configuración diferente en HKEY_CURRENT_USER (HKCU) para las aplicaciones, redes, entorno, etc.

Esto entrega ventajas y desventajas dependiendo del caso porque todo lo que se dañe en el Perfil de usuario que contenga la configuración bajo ese subarbol de registro afectará sólo al Perfil como tal y no a los otros usuarios que actualmente se hayan logueado o creado en el equipo, así pues siempre que haya un problema muy complejo es importante determinar si afectó sólo al perfil porque de ser así, siempre se puede rastrear la fuente y en gran parte de las ocasiones el inconveniente se soluciona importando nuevamente las claves con su configuración adecuada desde otro perfil funcional.

Por supuesto, aunque para cada usuario se cree una configuración específica Windows necesita una plantilla predeterminada que contiene una personalización definida y que se encuentra en un estado funcional, esta plantilla se llama NTUSER.DAT y se ubica como un archivo oculto y protegido de Windows en la carpeta correspondiente del perfil predeterminado de Windows 7 en el directorio %SYSTEMDRIVE\Users\Default:

*Notas:
1. %SystemDrive% es una Variable del Sistema operativo que hace referencia a la unidad donde se encuentra instalado Windows, normalmente C:\

2. Para ver los archivos y carpetas ocultos, además de los archivos protegidos por el sistema, se debe ir a las Opciones de carpeta haciendo clic en el botón Organizar dentro de cualquier ventana del Explorador de Windows, Opciones de búsqueda y carpeta, pestaña Ver, seleccionar Mostrar archivos y carpetas ocultos y quitar la selección de Ocultar archivos protegidos del sistema operativo (Recomendado).

Después de que se copia el contenido de la plantilla que se le llama como Subarbol (Hive en inglés) Windows almacena una copia por usuario en su respectiva carpeta, por ejemplo, si el usuario se llama Ult64, se creará un archivo de Subarbol (NTUSER.DAT) en la carpeta C:\Users\Ult64\NTUSER.DAT

*Nota: El subarbol (Hive) se crea al Iniciar por primera vez con el nuevo perfil.

Cada que un usuario Inicia sesión, desde cualquier cuenta que tenga acceso al Registro de Windows puede ver el Subarbol correspondiente por usuario que se identifica por el SID bajo la rama HKEY_USERS.

*Nota: La clave .DEFAULT NO corresponde al usuario predeterminado de Windows 7, es la que contiene la información para la cuenta de usuario LocalSystem.

Para escenarios de Implementación o Solución de problemas, aunque no es un proceso que pueda estar enteramente soportado por Microsoft o sea lo más recomendable por los riesgos que implica resutaría muy útil poder personalizar el comportamiento en configuraciones específicas para aplicaciones que lo requieran como la Configuración regional (HKEY_CURRENT_USER\Control Panel\International) o cualquier otra personalización para asegurarnos de que cada que se cree un nuevo perfil de usuario las mantendrá de forma predeterminada.

En Implementación podríamos asegurarnos de que al capturar y desplegar la imagen, todo estará configurado como nosotros lo indicamos, en Solución de problemas podríamos mitigar un problema que esté ocurriendo por alguna de las configuraciones que están predeterminadas cambiando su comportamiento, aunque aquí en primera medida habría que preguntarse por qué la aplicación no funciona como debería hacerlo.

Windows entonces presenta dos alternativas para cargar el Subarbol (Hive) correspondiente al perfil predeterminado y así poder realizar todas las personalizaciones deseadas para luego descargarlo y asegurarnos que de ahí en adelante todos los Perfiles creados mantendrán estas configuraciones.

Editando el Subarbol del Perfil Predeterminado

Como comenté previamente, existen dos formas de Montar el Subarbol, por la Consola de comandos utilizando la herramienta Reg.exe y desde la interfaz gráfica del Registro de Windows, a continuación detallaré cada una:

Utilizando la ventana del Registro de Windows

- En el Equipo donde se quiera personalizar el Perfil predeterminado, hacer clic en Inicio, teclear Regedit, clic derecho y seleccionar “Ejecutar como administrador”

- En el Registro de Windows, hacemos clic sobre el Subarbol HKEY_LOCAL_MACHINE, a continuación vamos a Archivo, Cargar Subarbol:

- En la ventana de Explorador de Windows, buscamos el archivo NTUSER.DAT ubicado en el directorio C:\Users\Default y hacemos clic en el botón Abrir:

- En la ventana de Cargar subarbol debemos indicar un nombre para identificar el Subarbol y con el que se ubicará como Clave debajo de HKEY_LOCAL_MACHINE, para este artículo por ejemplo lo puse “Default”:

- Al hacer clic en Aceptar, la clave se debe cargar y visualizar correctamente en HKEY_LOCAL_MACHINE y dentro de ella debe de estar todo lo que correspondría a HKEY_CURRENT_USER por cada usuario:

Una vez hecho esto, lo que queda es realizar todas las configuraciones que se quieren tener de forma predeterminada para todos los usuarios.

Es importante tener en cuenta que todo lo que se haga aquí aplicará para todos y a menos de que se exporten las claves modificadas no habrá forma de devolver los cambios en caso de fallos.

Cuando se terminen de hacer los cambios se debe Descargar nuevamente el Subarbol, de lo contrario cada perfil que se cree quedará inaccesible presentando un error al intentar iniciar sesión.

Para descargar el Subarbol (Hive), debemos seleccionar la Clave dependiendo del nombre que le hayamos puesto debajo de HKEY_LOCAL_MACHINE, para este caso Default y posteriormente clic en Archivo y seleccionar Descargar subarbol:

*Nota: Si no se selecciona la clave que se cargó no se habilitará la opción de Descargar subarbol.

Al descargarla, les pedirá confirmación, al darle Sí, la clave ya no aparecerá y todos los cambios se habrán guardado:

Utilizando la Línea de Comandos

Como siempre, hay quienes prefieren la automatización por lo que todo el proceso de carga y descarga del Subarbol se puede hacer perfectamente desde la Línea de comandos.

- Para hacerlo, clic en Inicio, digitamos CMD, clic derecho y seleccionamos “Ejecutar como administrador”.

- En la Consola de comandos de Windows ejecutamos:

reg.exe load HKLM\<NombreClave> %SystemDrive\Users\Default\NTUSER.DAT

Donde <NombreClave> es como deseamos que se visualice el Subarbol debajo de HKEY_LOCAL_MACHINE, para este artículo por ejemplo lo llamé como en los pasos anteriores “Default”, por lo tanto quedaría:

reg.exe load HKLM\Default %SystemDrive\Users\Default\NTUSER.DAT

De nuevo, si abrimos el Registro de Windows, podremos verificar que efectivamente la clave se cargó correctamente:

Lo siguiente nuevamente es hacer todos los cambios respectivos y cerrar el Registro de Windows antes de Descargar nuevamente el Subarbol.

Una vez cerremos el Registro de Windows, ejecutamos:

reg.exe unload HKLM\<NombreClave>

Para este artículo por ejemplo sería:

reg.exe unload HKLM\Default

*Nota: Es de vital importancia cerrar el Registro antes de realizar los pasos desde la línea de comandos, además de asegurarnos siempre que la clave se haya cargado y descargado entrando al Registro de Windows.

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

Saludos,

Checho

Windows Deployment & Sysinternals, mejor juntos: Desplegar una imagen para mostrar a todos los usuarios desde un perfil predeterminado

Checho — Mon, 06 Jun 2011 19:10:00 GMT

¡Hola!

*Nota: La primera parte del artículo explico el problema y los caminos para encontrar la solución que buscaba, si desean ir directo al proceso mencionado en el título, pueden empezar desde “A todas estas… ¿Cuál es entonces la solución?” más abajo en este artículo.

Realmente me alegra mucho cuando puedo escribir algo aquí que considero de utilidad, en este caso aunque puede ser algo tan sencillo como la imagen del perfil de usuario, puede que para muchas compañías que busquen estandarizar su imagen maestra llegue a tener una importancia relevante.

Básicamente la imagen del perfil de usuario no representa mayor cosa que sólo una forma de mostrar un distintivo por usuario, normalmente puede ser una foto o en general cualquier imagen que sea de nuestro gusto. Para las empresas sin embargo, se convierte en una oportunidad para especificar el logo por ejemplo representativo de la organización.

El problema, es que si creamos una Imagen de Windows 7 con un perfil personalizado, la foto de perfil sólo aplica a esa primera cuenta (Que seguramente sería la de Administrador integrada que resellamos); sin embargo, al crear otra cuenta, Windows nuevamente asigna una al azar y no lograríamos nada.

Seguramente se preguntarán ¿Qué tiene que ver Sysinternals con todo esto? Pues bien, hasta este punto estaba yo y es que a pesar de que la personalización del perfil obtiene fondos de pantalla, modificaciones en el registro y hasta configuraciones del menú inicio, estos detalles no. Debía entonces averiguar qué hacía Windows cuando creaba la cuenta y asignaba la imagen para tratar de personalizar el comportamiento.

Lo primero que indagué, gracias a la ayuda de David Nudelman es que hay dos imágenes predeterminadas para el primer usuario y para la cuenta de invitado, ámbas están en el directorio: C:\ProgramData\Microsoft\User Account Pictures, los nombres son guest.bmp y user.bmp:

*Nota: El directorio ProgramData está oculto de forma predeterminada, para verlo hay que entrar a las opciones de carpeta, pestaña ver y seleccionar Mostrar archivos y carpetas ocultos.

Teniendo esto presente, podría remplazar las dos con la imagen que quería pero esto sólo me garantizaría que la primera cuenta de usuario y la de invitado además de la del perfil predeterminado tendrían la imagen personalizada. ¿Qué pasaba entonces con el resto de cuentas que creara?

Dentro de la carpeta Default Pictures están todas las imágenes que Windows trae de forma predeterminada en la instalación para repartirlas entre todas las cuentas de usuario que se creen, y al entrar me di cuenta que tenían algo en común y era el nombre “usertile#”

¡Aquí es donde entra a jugar Process Monitor!

Sabiendo que la elección es aleatoria y que “algo” podría darme el nombre de las imágenes, decidí hacer el monitoreo completo para ver qué podía encontrar. Lo primero que hice fue como siempre ir al menú Filter, Filter… y establecer los parámetros de monitoreo al proceso Explorer.exe:

Para reproducir el comportamiento bastaba con crear una nueva cuenta, para esto clic en Inicio, clic en la imagen de perfil y posteriormente clic en el enlace de Administrar otras cuentas y finalmente crear una nueva cuenta ingresándole el nombre de Usuario y el tipo de usuario, por último clic en Crear cuenta:

Como no sabía por dónde empezar a buscar en el Monitoreo de Process Monitor, decidí buscar por lo que estuviera relacionado a “tile” que era como finalizaba cada imagen dentro de la carpeta Default Pictures.

Para hacer el filtro basta presionar CTRL + F dentro de Process Monitor y buscar.

El primer resultado, bastante satisfactorio para mí fueron unas líneas en el registro que me llamaron bastante la atención:

Si nos detenemos un poco a analizar, hay cuatro operaciones que se realizan y en donde está la clave a lo que buscaba:

Primero utilizando la función RegOpenKey, Windows abre la llave de Registro en HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer, lamentablemente el resultado aquí es NAME NOT FOUND y recordemos que HKLM hace referencia a HKEY_LOCAL_MACHINE donde están ubicadas todas las llaves que representan la configuración de aplicaciones y de Windows a nivel de equipo o máquina.

Al no poder encontrar esta llave, pasa a abrirla en la misma ruta pero a nivel de usuario, es decir en: HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer con un resultado de SUCCESS que indica que la llave existe, por lo que esta vez sí se abre para empezar a trabajar con ella.

*Nota: Recordemos que en HKEY_CURRENT_USER (HKCU) están las configuraciones de aplicaciones y de componentes propias por usuario, por lo que la configuración puede variar por cada perfil que se cree.

Ahora que la llave estaba abierta, Windows utilizó la función RegQueryValue para realizar una consulta a un valor dentro de esa llave de registro que era UseDefaultTile, aunque con un resultado de NAME NOT FOUND que indicaba que el valor no estaba creado, posteriormente pasó entonces a terminar la operación con la clave de registro cerrándola haciendo uso de RegCloseKey.

Claramente, la clave que no estaba creada UseDefaultTile es la que especifica el uso de la Imagen predeterminada para el usuario, normalmente estas claves se crean caundo se implementa una política de grupo y aunque no esté, Windows hace la consulta (Aquí otra pista es que venía de \Policies).

Para comprobarlo entonces, procedí a ir hasta esa llave de Registro haciendo clic derecho en la llave anterior que había resultado exitosa con Process Monitor y seleccionando Jump To:

Una vez allí, procedí a crear un nuevo Valor DWORD de 32 bits y lo llamé tal cual estaba buscando Windows UseDefaultTile y le asigné el valor de 1 para que quedara activo:

Al entrar de nuevo en la Administración de cuentas y ver el comportamiento al crear otra cuenta me encontré con esto:

La imagen por más que creara otra cuenta nueva era la que predeterminada está para “user” en el directorio que mencioné el principio del artículo: C:\ProgramData\Microsoft\User Account Pictures

Sin embargo, esta no era la imagen que yo tenía para el usuario actualmente por lo que la cadena estaba completa:

Las dos imágenes (user.bmp y guest.bmp) que están en la carpeta User Account Pictures se asignan a la primera cuenta que se crea pero con este valor además, se utilizan para predeterminar todas las cuentas con la misma imagen.

La solución consistía entonces en sí remplazar las imágenes predeterminadas por la que quería que tuvieran todas las cuentas para que se visulizara también en las cuentas creadas:

Automaticamente, todas las cuentas tomarían el cambio:

Hasta aquí estaba casi todo listo, exceptuando por un detalle más y es que el cambio en la llave de Registro lo había hecho en la de HKEY_CURRENT_USER que indica que las cuentas que se creen desde otra cuenta no tomarán esta imagen predeterminada y sería volver a lo mismo.

A todas estas… ¿Cuál es entonces la solución?

Afortunádamente, aunque esa misma llave no estuviera en HKEY_LOCAL_MACHINE, Windows hacía consulta primero en ella, pensé entonces que creándola y agregándole la clave podría haber una posibilidad puesto que obligaría a nivel de equipo y no de usuario.

A continuación, indicaré paso a paso el procedimiento exacto para asegurarnos de que todas las cuentas que se creen mantengan la misma imagen y no se puedan cambiar:

- Lo primero es habilitar la visualización de archivos y carpetas desde las Opciones de carpeta, ahora navegamos hasta el directorio ya mencionado donde están todas las imágenes para mostrar de Windows:

C:\ProgramData\Microsoft\User Account Pictures

- En la carpeta, borramos las dos imágenes con el nombre de guest y user respectivamente.

- Buscamos la imagen que deseamos predeterminar para todos los usuarios y la pegamos en esa misma ruta, debemos crear una copia y renombrarla para que tengamos finalmente las dos imágenes guest y user

- Una vez hecho esto, hacemos clic en Inicio, tecleamos Regedit, clic derecho y “Ejecutar como administrador”

- En el Registro de Windows navegamos hasta:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies

- Allí, hacemos clic derecho sobre la carpeta de Policies, sobre el menú contextual seleccionamos Nueva > Llave (New > Key):

La debemos llamar Explorer:

Nos situamos sobre la nueva carpeta o llave creada Explorer y en el panel derecho, debajo de la clave de Default hacemos clic derecho, Nuevo > Valor DWORD (32 bits) (New > DWORD (32 bit) Value) y lo llamamos UseDefaultTile con un valor de 1:

Si lo prefieren, pueden bajar la llave de Registro que crea la llave y la clave desde aquí:

¡Todo listo! Ahora no importa desde dónde se cree, siempre tomará la imagen que remplazamos por lo que habremos logrado nuestra personalización:

Además de esto, desde ninguna cuenta se podrá hacer el cambio de imagen (A menos de que sea por el Registro de Windows):

Espero les pueda ser de utilidad.

Saludos,

Checho

Una vista al futuro: Implementando Windows 7 a un VHD con Microsoft Deployment Toolkit 2012 Beta!

Checho — Thu, 02 Jun 2011 14:21:00 GMT

Hola,

Quiero empezar por supuesto con la noticia principal de este artículo, desde ahora tenemos la Descarga oficial de la primera Beta de Microsoft Deployment Toolkit en su versión 2012 disponible desde el sitio de Microsoft Connect: MDT 2012 Beta 1

Hasta ahora como fase Beta apenas empieza a suspirar los primeros cambios; sin embargo, ya hay unos muy interesantes como la posibilidad de unión con System Center Configuration Manager 2012, despliegue de Windows ThinPC, interfaz mucho más simple y la que tocaremos hoy: Despliegue de Windows 7 a un VHD (Disco Duro Virtual) agregada como una nueva Secuencia de Tareas.

Hasta ahora lamentablemente la documentación sobre los escenarios y las nuevas características que cubre esta versión es muy poca (Prácticamente nada) y la disponibilidad no será sino hasta la Beta 2. Por esta razón lo que deseo es tratar de reproducir la mayor cantidad de características y compartirlas por aquí para que podamos seguir descubriendo los grandes beneficios de MDT y claro está ¡Para que el que desee aportar, lo haga!

Una de las nuevas e interesantes características que trajo Windows 7 fue el soporte para los Discos Duros Virtuales (VHDs) que básicamente me proporciona la posibilidad de crear una partición que trabaja como disco pero que me provee la capacidad de moverlo como un archivo y además arrancar un sistema operativo en una máquina física desde el VHD o bien montarlo como máquina virtual (Con Hyper-V por ejemplo).

Los procedimientos de administración en general del VHD se realizan a través de la herramienta de línea de Comandos con Diskpart o bien parte desde el Administrador de discos incorporado en Windows 7 y además tiene varios escenarios que se pueden seguir.

La garantía que nos entrega ahora MDT 2012 es que podremos crear un VHD, instalarle Windows 7 y posteriormente desplegarlo como cualquier sistema operativo a una máquina física de forma automatizada, lo que nos ahorrá el trabajo de Crearlo bajo línea de comandos, de instalarle el sistema operativo y de modificar las entradas del arranque de Windows para poder hacer boot desde éste. ¿Interesante, no?

¡Esto será lo que haremos en este artículo!

Requisitos

- Archivos de instalación de Windows 7. Si todavía no tienen los medios de Windows 7, pueden bajar un trial de Enterprise desde aquí.

- Equipo técnico con Microsoft Deployment Toolkit 2012 (MDT 2012) instalado y el Kit de Instalación Automatizada de Windows 7. MDT lo pueden descargar registrándose a la Beta pública desde aquí, WAIK lo pueden descargar desde aquí.

*Nota: En este artículo no tocaremos la instalación y configuración de MDT ya que se ha visto en otros hilos, pueden ver todo el paso a paso de la primera configuración desde este artículo, o siguiendo el Blog por los tags de MDT.

*Nota 2: El arranque por VHD sólo está soportado en las Ediciones Enterprise y/o Ultimate de Windows 7, por lo que son éstas las que se deben agregar en la fase del Procedimiento.

- Equipo de referencia que esté en la misma red que el Equipo técnico para realizar el despliegue del VHD.

El procedimiento

Como haremos el procedimiento básico (Hasta donde he probado la funcionalidad de esta secuencia de tareas) debemos agregar el sistema operativo que queremos desplegar al Deployment Workbench, crear la secuencia de tareas y realizar el despliegue.

En el Equipo técnico abrimos el Deployment Workbench haciendo clic en Inicio, Todos los programas, Microsoft Deployment Toolkit, Deployment Workbench

Expandimos el Deployment Share (Recurso compartido de implementación) y hacemos clic derecho sobre el nodo de Operating Systems, seleccionamos Import Operating System:

Se abrirá el Asistente para importar un nuevo sistema operativo, hacemos clic en Full set of source files que indica la importación de todos los archivos de instalación y clic en el botón Next:

En la ventana de Source, clic en el botón Browse y debemos especificar la unidad donde se encuentran los archivos de instalación de Windows 7 (Los que vienen predeterminadamente en el DVD o imagen ISO de Windows 7) y clic en el botón Next:

En las siguientes páginas, debemos especificar el nombre del Directorio (Pueden dejar el predeterminado Windows 7 <Arquitectura>), verificar en la página de Resumen que todo haya quedado bien y clic en Next y Finish para que se importe el sistema operativo.

Creando la secuencia de tareas

Una vez agregado el sistema operativo que deseamos desplegar, debemos crear la secuencia de tareas aprovechando la nueva plantilla agregada en MDT 2012.

Para esto, dentro del Deployment Workbench hacemos clic derecho en el nodo de Task Sequences y seleccionamos New Task Sequence para abrir el asistente de nueva secuencia de tareas:

En la página de General Settings como siempre especificamos un ID único para la Secuencia de tareas (Para este artículo VHD-1), un nombre y una Descripción y clic en el botón Next:

En la página de Select Template es donde debemos seleccionar la nueva Secuencia con la que viene dotado el MDT 2012: Deploy to VHD Client Task Sequence

*Nota: Hay otra llamada Deploy to VHD Server Task Sequence que básicamente realiza el mismo proceso pero para un Windows Server 2008 R2.

Clic en el botón Next para continuar.

En la página de Select OS debemos escoger el sistema operativo que queremos desplegar, recordemos que sólo puede ser Windows 7 Enterprise ó Windows 7 Ultimate. Después hacemos clic en Next para continuar el asistente:

En la página de Specify Product Key, seleccionamos Do not Specify a Product key at this moment y clic en el botón Next.

En la página de OS Settings debemos especificar un nombre de usuario para el Registro de Windows, una compañía y una página de Inicio para Internet Explorer y clic en Next:

En la página de Admin Password decidimos si especificar o no una contraseña para la cuenta de Administrador integrada (La que se habilita predeterminadamente con la instalación) y clic en el botón Next.

*Nota: Para este artículo yo no especifiqué clave de Administrador.

En la página de Summary finalmente verificamos toda la información entregada y hacemos clic en el botón Next para iniciar el proceso de creación de la Secuencia de tareas, al terminar, clic en Finish para cerrar el asistente.

La Secuencia de tareas debe haberse creado y si todo sale bien, se visualizará en el Nodo de Task Sequences:

¡Todo listo! Ahora que está creada la Secuencia de tareas, debemos actualizar el Deployment Share para que se cree (O se actualice) el Windows PE que será el encargado de iniciar la instalación de Windows en el Equipo de referencia.

Para esto, clic derecho en el Deployment Share y clic en Update Deployment Share para iniciar el Asistente de actualización del recurso compartido de implementación (Deployment Share):

En la página de Options seleccionamos cualquiera de las dos opciones (Harán casi lo mismo) y clic en el botón Next.

En la página de Summary, clic en el botón Next para que inicie la actualización o creación del Windows PE.

*Nota: El proceso puede tardar unos minutos dependiendo de qué tanto hayamos agregado y personalizado dentro del Deployment Share.

Finalmente, clic en el botón Finish para terminar.

Todo está creado, el último paso es ir a la carpeta dentro del DeploymentShare llamada \Boot y guardar la imagen .wim o ISO dependiendo del método de despliegue que vayamos a realizar, el nombre genérico es LiteTouchPE_<Arquitectura>

Donde <Arquitectura> puede ser x86 ó x64:

Si tenemos un Windows Deployment Services (WDS) bien podremos agregar esta imagen .wim al nodo de Boot images para que los equipos que se conecten por red la reconozcan y luego se peguen al MDT 2012; si no tenemos WDS, podemos grabar la imagen .ISO en una USB o DVD y arrancar el Equipo de referencia desde allí asegurándonos de nuevo que estén en la misma red con el MDT para que se pueda conectar al recurso compartido en el proceso de instalación. La decisión dependerá del entorno que tenga cada uno, el resultado final será el mismo.

Como comentario general, aunque las preguntas del Asistente de implementación en un despliegue no automatizado son las mismas, la interfaz ha cambiado por algo más simple y fresco:

Al terminar la instalación, notarán que la diferencia no se nota puesto que el VHD utiliza también los recursos físicos de máquina aunque, si vamos a la ventana de Equipos veremos dos particiones correspondientes al sistema de archivos y a donde está alojado el archivo del Disco Duro Virtual (VHD):

*Nota: El peso del VHD será el que tenga la partición del disco físico del equipo de referencia.

Falta mucho por explorar en MDT 2012, de a poco entonces trataré de traer el paso a paso de los nuevos procesos.

Espero sea de utilidad.

Saludos,

Checho

Integrar Temas personalizados en imagen de Windows 7 con Microsoft Deployment Toolkit 2010 Update 1

Checho — Thu, 12 May 2011 13:34:00 GMT

Hola a todos,

Como seguramente muchos se han dado cuenta u otros lo pueden estar viviendo (Con todo lo que implica) que Windows 7 está llegando y hoy por hoy empiezan los procesos Piloto y posterior implementación del sistema a nivel de la organización.

Por supuesto la primera y gran preocupación es la Compatibilidad de aplicaciones pero menos mal para todos nosotros, hay muchos caminos que van desde evaluar el comportamiento de la aplicación hasta la Virtualización.

Una vez superado esto podemos ahora preocuparnos por la forma en cómo desplegaremos Windows 7 y cúal es el mejor camino, aquí en el Blog ya hemos visto varios caminos (¡Quedan faltando muchos!) pero hoy específicamente nos enfocaremos a algo tal vez básico pero que puede representar una forma útil de estandarizar la visualización de los perfiles desplegados.

Windows 7 incluyó una característica muy particular con respecto a la personalización y es que ahora nosotros podemos crear nuestros propios Temas e implementarlos sea en nuestro equipo o incluso compartirlos desde la ventana de Personalización en el Panel de Control. Estos temas al quedar en un solo paquete fácilmente se pueden instalar en otro Equipo Windows 7 con solo ejecutarlo.

Lo que haremos será aprovechar esta función para integrar un tema personalizado dentro de una imagen Maestra de Windows 7 utilizando nuestro famoso Microsoft Deployment Toolkit 2010 Update 1 (MDT), así cuando implementemos además de las aplicaciones y configuraciones (Que MDT nos entrega), podremos tener nuestro propio tema =)

Lo que necesitamos:

- Servidor Windows Server 2008, 2008 R2 ó Windows 7 con Microsoft Deployment Toolkit instalado. Si no tienen MDT, pueden descargarlo desde aquí:
http://www.microsoft.com/downloads/en/details.aspx?familyid=3bd8561f-77ac-4400-a0c1-fe871c461a89&displaylang=en

- Los archivos de instalación de Windows 7, si todavía no lo tienen, pueden bajar un trial de 90 días para Windows 7 Enterprise desde aquí:
http://technet.microsoft.com/evalcenter/cc442495.aspx

- Archivo .themepack, se puede crear desde el panel de Personalización o bien pueden descargar temas personalizados de alguna página o de la web directa de Microsoft:
http://windows.microsoft.com/es-XL/windows/downloads/personalize/themes

¡Empezemos!

Lo primero que hacemos siempre es desde MDT crear un recurso compartido cuando recien estamos empezando, y dentro de este recurso hay otra serie de recursos destinanos a Aplicaciones, Sistemas, actualizaciones, scripts, etc.

Ya hemos visto algunos, pero hoy nos centraremos en una de las carpetas que tal vez poco usamos pero que le sacaremos provecho y es la de $OEM$

Para este artículo que el Recurso de implementación lo dejé con el nombre predeterminado, y en otra partición, la ubicación sería: D:\DeploymentShare\$OEM$

Esta carpeta $OEM$ existe y se utilizaba incluso en las implementaciones de Windows XP, y básicamente es un repositorio donde podremos copiar contenido adicional que necesitemos que tenga Windows (Para este caso el tema!).

Hay dos carpetas además de estas que podremos crear para referenciar directorios importantes:

$$: Al crear esta carpeta estamos asegurándonos de que todo el contenido que copiemos allí, o subcarpetas que creemos se ubiquen en directorio de Windows, normalmente C:\Windows\.

Si nosotros queremos que nuestro archivo de Tema se ubique en C:\Windows\PerTheme\Tema.themepack el directorio dentro del DeploymentShare quedaría: $OEM$\$$\PerTheme\Tema.themepack

Básicamente es porque esto hace una réplica de todas las carpetas ubicadas en %SystemRoot%

$1: Trabaja exactamente igual que la anterior con excepción de que creando esta carpeta nos estaríamos ubicando en la Unidad del sistema operativo, por lo general en C:\

Para este artículo, crearemos la carpeta DefaultTheme en el directorio C:\ por lo que el arbol quedaría: $OEM$\$1\DefaultTheme\Tema.themepack

*Nota: Cada uno puede variar como desee dentro de estas carpetas ya que como ven se pueden crear otras, o inclusive las dos, lo importante será tener en cuenta el directorio exacto donde quedará el Tema para poderlo referenciar y que aplique.

Configurando Secuencia de Tareas en MDT

Ya tenemos nuestro tema en el directorio específico pero así lo unico que estamos asegurando es que quede copiado cuando se haga la instalación de Windows, sin embargo como no estamos referenciando el tema predeterminado por el Archivo de autorespuesta (No he sido capaz!) tendremos que decirle a la Secuencia de tareas explícitamente dónde está el tema y que lo ejecute al terminar todo el proceso.

En el Equipo técnico donde tengamos instalado MDT, abrimos el Deployment Workbench haciendo clic en Inicio, Todos los programas, Microsoft Deployment Toolkit, Deployment Workbench (Si es en 7, se debe hacer clic derecho y “Ejecutar como administrador”).

Dentro del Deployment Workbench debemos modificar o crear la secuencia de tareas para integrarle la referencia al tema, para este artículo será con una básica y sin mayores personalizaciones.

Recordemos que para crear una Secuencia de tareas hacemos clic derecho sobre el Nodo Task Sequences y seleccionamos New Task sequence:

Se abriá el asistente para la creación de una nueva secuencia de tareas en el que básicamente debemos especificar un ID propio para la secuencia, un nombre, un sistema operativo y algunas configuraciones básicas como nombre de usuario registrado, clave de administrador, serial, sistema operativo a instalar, etc.

*Nota: No entro en detalle paso a paso para no repetir lo de artículos anteriores, al final de este post dejo algunos enlaces donde pueden seguir todo el procedimiento en este mismo Blog.

Para este artículo, mi secuencia de tareas la he llamado “Windows 7 PRO ES”.

Una vez creada, accedemos a las propiedades de la misma haciendo doble clic o bien clic derecho y seleccionando Properties:

En la ventana de Propiedades de la secuencia de tareas, nos pasamos a la pestaña de Task Sequence. Aquí es de donde la Secuencia de tareas recibe el orden de instalación y de tareas que se realizan durante todo el despliegue del sistema, aplicaciones, etc.

Lo que haremos será agregar algunos comandos más al final de toda la instalación para apuntar al Tema agregado en los pasos anteriores.

Para esto, dentro de esta pestaña de Task Sequence hacemos clic en el botón Add, menú General y clic en Run Command Line:

Debemos asegurarnos de que el Nodo creado quede como último paso (Para estar seguros también de que se ejecutará cuando el tema ya esté copiado en C:\), para esto con el botón de “Down” lo ubicamos después del último nodo que es “Restore Groups”.

A continuación nos paramos sobre el seleccionándolo y en las propiedades del mismo debemos modificar el Nombre que queramos que se visualize (No importa si se deja el predeterminado) pero más importante la línea de comandos (Command Line) ya que es donde debemos indicarle el directorio exacto donde está el tema para que vaya y lo ejecute.

Para este artículo que el Tema está dentro de $OEM$\$1\DefaultTheme\Tema.themepack, el comando sería: C:\DefaultTheme\Tema.themepack

Hacemos clic en el botón Apply y OK para guardar los cambios.

¡Listo! Ya está también referenciado el tema que se utilizará (Recordemos llamar el tema exactamente igual a como lo estamos buscando en la ruta), ahora el siguiente paso es Actualizar el Recurso compartido de implementación (Deployment Share) para que se apliquen los cambios en el Windows PE que crea y se pueda desplegar en cualquier equipo.

Para esto hacemos clic derecho sobre el nodo de Deployment Shares y seleccionamos Update Deployment Share:

En la ventana de Update Deployment Share seleccionamos Optimize the boot image updating process, clic en Next, Next y Finish para que actualice el Deployment Share:

Una vez terminado, buscamos el Windows PE dentro de la carpeta Boot del DeploymentShare con el nombre LiteTouchPE_x86.iso ó LiteTouchPE_x64.iso de acuerdo a la arquitectura que estemos desplegando y con esa imagen arrancamos el equipo de referencia donde haremos la instalación.

*Nota: Como se crea un .WIM también lo podríamos inicializar desde un WDS, para este artículo que nos estamos centrando sólo en aplicar el tema lo haremos manualmente pero es importante que los dos equipos siempre estén en la misma red para que el Equipo de referencia se pueda pegar correctamente al Equipo técnico.

De a cuerdo a si automatizamos o no la instalación nos puede pedir las credenciales y otras configuraciones y, si todo sale bien, después de terminada la instalación del sistema operativo se debería aplicar el tema al ejecutar la línea de comandos:

*Nota: “Algo” es el nombre que le puse al tema a la hora de crearlo dentro de Windows 7.

Como ven, es algo sencillo y tal vez de poca importancia pero si vamos a implementar 7 ¡Que sea como nos gusta que se vea! =)

Si de pronto es primera vez que están utilizando MDT, los invito a ver este artículo de configuración inicial de Microsoft Deployment Toolkit que hice para el Centro de Estudiantes Microsoft:
http://centrodeestudiantesmicrosoft.wordpress.com/2011/05/06/el-primer-paso-del-paso-a-paso-deployment-de-windows-7-y-compatibilidad/

Además de esto, el Webcast donde explico esto y cómo realizar el primer despliegue con MDT:
https://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032476336&Culture=es-AR

Aquí en el Blog pueden ver otro tipo de artículos realizando varias tareas con MDT.

Espero les sea de utilidad.

Saludos,

Checho