Mes: agosto 2011

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>ISOSourcesboot.wim

Para este artículo, sería:
copy C:WinPEwinpe.wim C:WinPEISOSourcesboot.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:WinPEetfsboot.com –u2 –h C:WinPEISO 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

Hola a todos,

De lo más interesante en ir conociendo poco a poco las herramientas de Sysinternals es que además de que son tal vez, y para mí, la mejor ayuda en casos de Solución de problemas, también se pueden utilizar como medio de conocimiento ya que, podemos utilizar por ejemplo, a Process Monitor para hacer seguimiento de aplicaciones o de comportamientos de Windows y aprender cómo se efectúan internamente y al hacerlo se aprende el comportamiento, el modo en que Windows funciona para dicho comportamiento y cómo se debe establecer para que en efecto funcione.

El siguiente artículo proviene de una de esas tantas dudas que me han surgido del funcionamiento de Windows y de las que afortunadamente he tenido la fortuna de entender un poco más utilizando Process Monitor. Como me encanta escribir aquí, quise otra vez compartir algo de lo que aprendí.

*Nota: Si desean no seguir la explicación técnica del comportamiento e ir directamente al Tip, pueden seguir directamente la última parte del artículo: “Entonces, ¿Cuál es el proceso para el Autologon manual?”.

Quizá a bastantes personas de los que puedan leer este artículo y lleven ya un tiempo probando Windows 7, en alguna ocasión se habrán preguntado cómo puedo hacer para que una de las tantas cuentas que inicia sesión en el equipo se predetermine e inicie automáticamente sin tener que ingresar credenciales; así, cuando esporádicamente se quiera cambiar a otra cuenta, símplemente sea cerrar sesión o bien cambiar de usuario.

Si estamos preparando una imagen personalizada o realizando Ingeniería de Imagen como formalmente se le conoce, utilizar un Archivo de autorespuesta en la instalación desatendida o para automatizar algunos procesos, esto lo podríamos especificar con el Componente de Autologon que incluye el System Image Manager (SIM) y al que le podemos personalizar fácilmente el nombre de usuario con el que deseamos iniciar automáticamente, sus respectivas credenciales y la cantidad de veces que deseamos que se produzca el inicio automático o Autologon:

Una vez instalado Windows, sigue realizando este Autologon después de cada reinicio dependiendo de la cantidad de veces especificadas (LogonCount).

La pregunta es: ¿Qué si no estoy haciendo Ingeniería de Imagen?

Para esta respuesta, Sysinternals entrega una estupenda herramienta llamada Autologon que brinda la posibilidad de programar el inicio automático tanto para usuarios locales como a nivel de dominio dejándome activar o desactivar cuantas veces quiera:

Este sería el método más fácil, pero personalmente me parece que se pierde dirversión =)

Lo interesante está, en saber ¿Qué es lo que hace Autologon para que pueda activar y desactivar los inicios automáticos tan fácilmente?

Investigando un poco el Autologon de Windows…

El proceso de Inicio de sesión de Windows está ligado al Servicio de Winlogon que administra el modo y la autenticación que realiza cada usuario para ingresar en el sistema operativo.

Process Monitor nos da una forma fácil de ver un poco el comportamiento cada que se realiza un inicio de sesión con una característica llamada Enable Boot Logging en el menú Options de la ventana principal:

Activando esta característica y cambiando de usuario para ingresar nuevamente con el que hayamos iniciado sesión podremos ver ya un poco lo que sucede de acuerdo a la Traza entregada por Process Monitor.

Como siempre, son demasiados eventos y la forma más fácil de empezar a filtrar es utilizando el cuadro de búsqueda presionando CTRL + F o bien en el menú Edit, opción Find.

La recomendación personal es siempre buscar por palabras que sean familiares a la tarea o proceso que estamos tratando de identificar, para este caso por ejemplo: Autologon, User, Username, etc.

Afortunadamente con el primer criterio (Autologon), después de unas cuentas repeticiones encontré esto:

Si nos fijamos en las dos selecciones que hice con color rojo, veremos que la primera Operación utiliza la función RegQueryValue (Operación de consulta) sobre la clave:
HKLMSOFTWAREMicrosoftWindows NTCurrentVersionWinlogonAutoAdminLogon

El resultado de esta Operación es SUCCESS que indica que la clave y Valor existen. Al navegar desde Process Monitor haciendo clic derecho y Jump To podemos ver que el contenido de este valor es “0” de forma predeterminada, lo que indica que el Autologon está desactivado:

Lo que sigue, es modificar el valor para asignarle “1” que sería Activado.

El mismo nombre lo indica, pero si queremos saber qué cuenta intenta iniciar automáticamente al reiniciar nos podremos dar cuenta que Windows no mostrará ninguna cuenta de usuario y en vez de esto nos pedirá ingresar manualmente usuario y contraseña con el que deseamos ingresar, básicamente para Autogestionar el Inicio de Sesión (AutoAdminLogon):

La parte importante está en la segunda clave subrayada en rojo de la captura anterior. Como ven también hace una operación de consulta utilizando la función RegQueryValue sobre la clave:
HKLMSOFTWAREMicrosoftWindows NTCurrentVersionWinlogonDefaultUserName

Sin embargo, el resultado es NAME NOT FOUND que, como ya hemos visto en numerosos artículos, se refiere a que el valor no existe (Puede implicar también las claves).

El nombre en este caso es también bastante claro, DefaultUserName en su traducción sería Nombre de usuario Predeterminado pero para saber cómo funciona, lo mejor es crear la clave y ver qué sucede.

*Nota: Podemos asegurarnos de antemano que no es un valor DWORD porque no está validando una condición de Verdadero o Falso sino que está buscando por contenido, el valor más apropiado entonces es de Cadena.

Para este artículo, yo creé la clave y le asigné el nombre exacto de una de las cuentas de usuario, (La misma que utilicé con Autologon que era Utl64):

*Nota: Para crear el valor, desde Process Monitor haciendo clic derecho sobre la clave y seleccionando Jump To iremos directamente al Editor de Registro situándonos en la respectiva clave, allí basta con hacer clic derecho, Nuevo y seleccionar Valor de cadena.

Lo que seguía ahora era reiniciar el equipo sin modificar el valor de AdminAutoLogon anterior y esperar para ver qué sucedía, lo que me encontré en mi caso fue esto:

El mensaje de “El nombre de usuario o contraseña no es correcto” indicaba que había algun problema con las credenciales, al darle al botón Aceptar reconocía el usuario con el que deseaba realizar Autologon pero me pedía la contraseña, ¡Ahí estaba el problema, en la Contraseña!

Efectivamente se está haciendo el Autologon porque trata de iniciar con la cuenta especificada, sin embargo, la contraseña que está intentando ingresar no es necesariamente la que corresponde.

Volví a mirar en el Log de Process Monitor buscando por la contraseña (Password) pero no encontré nada (Sin contar los llamados que hacía a la SAM).

Tengamos en cuenta que Autologon de Sysinternals sí utiliza el campo de la contraseña por lo que pensé que aún cuando la maneja de una forma encriptada podría descubrir algo que me ayudara para utilizarla.

De nuevo entonces, corrí Process Monitor mientras hacía el proceso con Autologon.exe, a continuación fui al Log y busqué otra vez por “Password”, el resultado para mi satisfacción esta vez fue algo más gratificante:

Hay una operación de consulta sobre la clave:
HKLMSOFTWAREMicrosoftWindows NTCurrentVersionWinlogon

*Nota: Recordemos que HKLM hace referencia a HKEY_LOCAL_MACHINE

Está buscando el valor de DefaultPassword pero con un resultado de NAME NOT FOUND.

La otra operación que realizaba Windows según Process Monitor y que no se muestra en la captura anterior era que borraba ese valor después de haber hecho una consulta, sin mucho criterio en este caso podría proponer que hace parte de la encripción que utiliza Autologon de Sysinternals con respecto a la contraseña de usuario.

A pesar de todo, esto me dio un gran pie para lo que necesitaba y es que si Windows buscaba este valor quería decir que lo podría utilizar tal como DefaultUserName y DefaultDomainName (Lo utiliza Autologon para identificar el dominio o el Grupo de Trabajo local), y poder tal vez indicar la contraseña de usuario.

Lo que hice fue ir nuevamente a la clave, hacer clic derecho sobre un espacio en blanco, seleccionar Nuevo > Valor de cadena.

El nombre que le asigné fue el que tenía DefaultPassword y en su contenido le puse la contraseña que correspondía al usuario que había indicado en DefaultUserName para que al hacer el arranque automático, también tomara su correspondiente contraseña:

Después de esto, reinicié el equipo y ¡Funcionó!. Windows pasó el inicio de sesión automáticamente sin solicitar credenciales ni nombre de usuario y justo con la cuenta que debía ser (Ult64 en mi caso).

Entonces, ¿Cuál es el proceso para el Autologon manual?

En todo el contenido anterior traté de especificar y mostrar cómo es el comportamiento en el Proceso de Autologon que reconoce Windows tanto con la herramienta de Sysinternals como forzándolo manualmente. A continuación, detallaré el proceso que cada persona debe seguir si quiere personalizarlo a sus cuentas de usuario:

1. Determinar qué nombre de usuario y contraseña es la que se quiere utilizar para que inicie de forma predeterminada y automáticamente en Windows 7.

2. Al iniciar sesión, clic en Inicio, digitar Notepad y presionar la tecla ENTER para abrir el Blog de Notas.

3. En el Blog de Notas copiamos lo que estará dentro de la división de la siguiente división de líneas:

---

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionWinlogon]
"AutoAdminLogon"="1"
"DefaultUserName"="<NombreUsuario>"
"DefaultPassword"="<ContraseñaUsuario>"

---

Donde <NombreUsuario> es como se llama la cuenta que desean automatizarle el proceso de inicio de sesión, por ejemplo, para este artículo se llama Utl64.

<ContraseñaUsuario> se refiere a la Contraseña que tiene asignada el <NombreUsuario>, por ejemplo, para este artículo es Passw0rd

En este orden de ideas, si el anterior texto lo acomodara a mi necesidad, quedaría así:

4. En el Blog de Notas, clic en el menú Archivo, seleccionar Guardar como… y ponerle un nombre con el que se pueda identificar el proceso que hará como “Autologon”, pero más importante, indicarle la extensión .REG para que se establezca como un fichero de Registro.

Para este artículo por ejemplo, se llamaría Autologon.reg

5. Doble clic sobre el fichero de Registro y nos aparecerá la ventana de Advertencia indicándonos que escribiremos en el Registro de Windows por lo que podría llegar a ocasionar problemas con el funcionamiento del sistema operativo, posteriormente nos indicará el mensaje de información donde debe decir que el Registro se importó satisfactoriamente:

*Nota: Es de vital importancia el que indique que se agregó correctamente, de lo contrario no habrá cambios en el Registro y no se verá reflejado el Autologon.

6. Reiniciar el equipo y verificar que en efecto, inicie con la cuenta indicada en el fichero de Registro creado e importado anteriormente.

*Nota: Antes de hacer cualquier cambio en el Registro, se recomienda exportar la clave original que se verá afectada haciendo clic derecho sobre ésta y seleccionar Exportar. Así, si pasa algun daño, se podrá reestablecer completamente.

Cabe aclarar que la herramienta Autologon de Sysinternals brinda mucho más ventajas que hacerlo manualmente ya que no hay un riesgo mayor de hacer algun daño en el Editor de Registro, la contraseña está encriptada y es muy fácil de utilizar.

Hacerlo manualmente a pesar de todo, como han visto entrega algo que considero mucho más importante y es el aprendizaje.

¡Comentarios bienvenidos!

Saludos,

Checho

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:WindowsWebWallpaperWindowsimg0.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:UsersUtl64RoamingMicrosoftWindowsThemes 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_USERControl PanelDesktop, 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 usuarioPlantillas administrativasEscritorioActive 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:

HKCUSoftwareMicrosoftWindowsCurrentVersionGroup Policy Objects{B14D9D7C-7728-4C31-96FC-A59F1AB2D6E3}User

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

UserSoftwareMicrosoftWindowsCurrentVersionPoliciesSystem

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 (HKCUSoftwareMicrosoftWindowsCurrentVersionGroup 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 (UserSoftwareMicrosoftWindowsCurrentVersionPoliciesSystem), 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_USERSoftwareMicrosoftWindowsCurrent Version PoliciesSystem

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 HKLMDefault %SystemDrive%UsersDefaultNTUSER.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_MACHINEDefaultSoftwareMicrosoftWindowsCurrentVersionPolicies

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 HKLMDefault

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

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

Hola a todos,

De nuevo, como comenté hace unos días en mi anterior artículo, quiero traerles algunos tips que he ido aprendiendo y que pueden ser útiles mientras va llegando el momento del gran “8” =).

Ya hemos hablado que tanto en escenarios corporativos como en hogareños, la personalización de nuestra imagen de Windows se convierte en algo importante de manejar ya que se vuelve una forma de estandarizar y volver algo como las instalaciones algo representativo para la persona u organización.

Windows 7 ha presentado diferentes alternativas que brindan un entorno más flexible para adecuar un poco más a profundidad el entorno de Windows acorde a como nosotros queremos, empezando desde la pantalla de bienvenida hasta lo que llamamos Temas que incluye papel tapiz, sonidos, colores, etc. Esto, afortunadamente no se queda ahí, ahora Windows 7 nos entrega una forma más fácil de integrar algunos campos de información de Soporte dentro de las propiedades del Sistema (Esto estaba desde Windows XP pero el proceso era un poco más complejo); podremos agregar enlace de soporte, logo personalizado, teléfonos y hasta un nombre de fabricante.

Esta información adicional normalmente las agregan son los fabricantes de equipos OEM pero, personalmente creo que agregarlos a una instalación personalizándolos le da un aspecto mucho más interesante.

Requerimientos:

– Necesitaremos un Logo personalizado que tenga una medida de 120×120 Pixeles en formato (.BMP), esto lo pueden conseguir con cualquier aplicación de diseño como Photoshop o hasta Microsoft Paint.

– Opcional: Información adicional como un enlace a nuestro sitio web, teléfono, modelo y nombre de compañía.

Procedimiento:

Información adicional: Windows predeterminadamente ya reconoce y hace la consulta sobre la información que contienen estos campos, como con casi todo a nivel de Registro, por supuesto las consultas y operaciones dependen de lo que uno esté haciendo; para este caso al entrar a las Propiedades del Equipo, este es el resultado:

Básicamente, se abre la clave OEMInformation ubicada en HKLMSoftwareMicrosoftWindowsCurrentVersionOEMInformation y desde aquí consulta los valores de HelpCustomized, SupportPhone, SupportHours, SupportURL, Manofacturer, Model y por último el de Logo. Como los valores no existen, devuelve un resultado de NAME NOT FOUND y procede entonces a cerrar la clave (RegCloseKey).

En lo que vemos dentro de Windows, símplemente no muestra nada de esto cuando despliega toda la información en las Propiedades y deja sólo lo que Windows predeterminadamente tiene.

Lo que nosotros haremos es crear estos valores para que Windows los encuentre y finalmente los refleje.

*Nota: El monitoreo de esta información se muestra bajo el resultado que da Process Monitor de Sysinternals.

¿Cómo empezar?

• En el Equipo, hacemos clic en el botón Inicio, digitamos Regedit y sobre el resultado, clic derecho y seleccionamos “Ejecutar como administrador”:

• En la ventana de Registro de Windows, navegamos hasta la clave: HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionOEMInformation
• Lo que haremos será empezar a crear los valores binarios de acuerdo a lo que se desee integrar, para este artículo habilitaré el Logo (Logo), Fabricante (Manufacturer), Enlace de soporte (SupportURL) y Horas de Soporte (SupportHours), para esto hacemos clic derecho sobre el espacio en blanco de OEMInformation, seleccionamos Nuevo y Valor de cadena:

  

• Cada valor de cadena debe tener como nombre el que Windows reconoce en Inglés y como contenido debe tener la información o la URL si es el logo por ejemplo.

  Para este artículo, el Logo yo lo ubiqué en la unidad C: para que esté disponible en todos los usuarios por lo que el primer valor Logo en su cadena debe hacer referencia a esa ubicación (C:Logo.bmp):

• Para el resto basta con escribir correctamente el nombre e indicarle información sea verdadera o falsa, para este artículo esto fue lo que indiqué:

  Manufacturer: Checho’s Blog
  SupportURL: http://geeks.ms/blogs/checho
  SupportHours: 24/7

• El resultado debería ser similar al siguiente variando sólo en la información de cada uno:

  

Después de esto, cerramos el Editor de Registro, abrimos las Propiedades del sistema yendo al botón Inicio, clic derecho en Equipo y Propiedades y si todo salió bien, deberíamos ver los cambios con respecto a como estaba de forma predeterminada:

Espero les pueda ser de utilidad.

Saludos,

Checho

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 %SYSTEMDRIVEUsersDefault:

*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:UsersUlt64NTUSER.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_USERControl PanelInternational) 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:UsersDefault 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> %SystemDriveUsersDefaultNTUSER.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 HKLMDefault %SystemDriveUsersDefaultNTUSER.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 HKLMDefault

*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