La perdida de asociación de accesos directos y ejecutables en Windows 7. Process Monitor, Process Explorer, PsExec y su solución.

Hola,

En artículos anteriores ya hemos visto problemas relacionados con Asociación de iconos en Windows 7 o Asociación de Carpetas y Directorios pero, Windows maneja internamente distintos tipos de asociación y aun nos falta la de archivos o extensiones en general pues están implicadas diferentes claves o subclaves de Registro.

En este post exploraremos uno de los problemas más frecuentes con respecto a la Asociación de archivos que se refieren a los Accesos directos (.lnk), Ejecutables (.exe) y diferentes formas de solucionar el inconveniente que van desde la más fácil hasta la que se vuelve un poco más compleja acudiendo a Sysinternals.

*Nota: El Artículo puede estar extenso por lo que se planteará cada solución al detalle posible, la idea es que puedan encontrar diferentes caminos para solventar el problema.

El problema

Cada aplicación que se instala en Windows puede manejar un tipo de extensión de archivo propia para identificar que los archivos se ejecutan y trabajan con esa aplicación, por ejemplo la extensión PDF es propia de Adobe Reader aunque la extensión puede estar dentro de un estándar general para que otras aplicaciones también puedan administrar estos archivos como la misma .PDF o por ejemplo .ISO

Cuando se instala el Software, automaticamente toma posesión de sus extensiones pero, Windows puede cambiar este comportamiento para nosotros decidir con qué aplicación queremos abrir el archivo determinado. El problema está cuando por accidente o desconocimiento cambiamos una extensión que administra Windows por ejemplo o que es desconocida para la áplicación como la de los Accesos directos (.lnk).

El resultado será entonces que los iconos cambian al de la aplicación seleccionada y además todo lo que tenga esa extensión .lnk intentará abrirlo sin resultado.

Si por ejemplo, afectamos la asociación de accesos directos (.lnk) para que se abra con Windows Media Player, podremos tener una visualización de nustros accesos así:

image image

Al ejecutar el archivo, a menos de que sea de tipo audio o video (Para este caso), recibiremos un mensaje de error que nos indica que no se puede reproducir esa extensión:

image

“El archivo seleccionado tiena una extensión (.lnk) que <Aplicación> no reconoce”

La causa

El primer paso si no se sabe qué está sucediendo sería recurrir a Process Monitor de Sysinternals y a continuación comparar el comportamiento de un equipo que esté funcional con respecto al equipo del problema cuando se trata de abrir el Acceso directo.

Analizando con calma, podemos ver una gran diferencia en una operación relacionada con la clave de Registro: HKCUSoftwareMicrosoftWindowsCurrentVersionExplorerFileExts.lnkUserChoice

Equipo Funcional:

LNK2

Equipo NO Funcional:

LNK1

Como ven, en el Equipo funcional trata de abrir la clave de registro HKCUSoftwareMicrosoftWindowsCurrentVersionExplorerFileExts.lnkUserChoice, al obtener como resultado NAME NOT FOUND (La clave no existe) procede a cerrarla, mientras que en el equipo NO funcional, a parte de que sí obtiene un resultado exitoso indicado con SUCCESS (La clave existe) hace una consulta a una de las subclaves “Progid” también con un resultado exitoso y finalmente cierra la operación.

En definitiva, esta clave tiene que ver con el problema, si vamos más a fondo con el Process Monitor haciendo clic derecho y Jump To para abrir el registro, la agradable sorpresa sobre el valor “Progid” es:

image

Progid (Identificador de aplicación) es el valor que se encarga de asociar la aplicación que se haya seleccionado accidental o no accidentalmente (UserChoice) por el usuario para que abra esas extensiones, en este caso la de los Accesos directos.

Para este artículo, el afectado fue el Windows Media Player (wmplayer.exe).

*Nota 1: La clave implicada será la misma, lo unico que variará para cada persona con el problema será el programa asociado.

*Nota 2: Este tipo de problemas por lo general afectan sólo por configuración de usuario, por eso están ubicados en la ruta de HKEY_CURRENT_USER (HKCU)

Primera solución – Para accesos directos (.lnk) –

Si sólo tenemos afectados los Accesos directos, el procedimiento para volver a las asociaciones funcionales y originales es:

– En el Equipo NO funcional, clic en el botón Inicio, teclear Regedit y sobre el resultado, clic derecho y Ejecutar como Administrador:

image

– En el Registro de Windows, navegar hasta la clave:
HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionExplorerFileExts.lnk

image

– Expandimos la clave .lnk (>), clic derecho sobre la subclave UserChoice y seleccionamos Eliminar:

image

– Después de eliminar la subclave, reiniciamos el sistema y los Accesos directos deberían estar funcionales nuevamente.

El problema extendido – Con perdida de asociacion de ejecutables (.exe)-

Recordemos que cuando algo está mal, ¡Se puede poner mucho peor!
Para este caso, se da mucho que al perder la asociación de los Accesos directos también se pierde la de los ejecutables (.exe) y es ahí cuando surgen preguntas como ¿Y cómo entro al Registro si no puedo abrir ningun ejecutable? ¿Cómo lo soluciono?

image

De lo que podemos estar en la mayoría de las ocasiones seguros es de que la causa no cambia, y en términos generales la solución tampoco ya que, se trata de eliminar la asociación que sea crea en el registro pero además de la de accesos directos diriginos a la de ejecutables que está ubicada en:
HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionExplorerFileExts.exe

El problema ya mencionado por supuesto, es que al estar afectada la asociación de ejecutables (.exe) no se puede entrar ni siquiera al Registro de Windows – Recordemos que es Regedit.exe-

La solución extendida – Para Accesos directos (.lnk) y Ejecutables (.exe)-

No todo está perdido y es que si en la solución anterior aprovechamos el buen estado de la asociación de ejecutables para arreglar la de accesos directos, en este caso aprovecharemos la asociación de la que quizás sea una de las mejores herramientas que integra Windows: El blog de Notas (Notepad) en conjunto con los archivos de registro (.reg).

Si bien también es un ejecutable (Notepad.exe), para crear un archivo de texto plano no es necesario invocar a la aplicación, aprovecharemos esto entonces para generar una clave de registro desde el texto plano (Cambiando a extensión .Reg) para borrar las claves de registro implicadas en el problema (Aunque suene un poco contradictorio).

¿Cómo hacerlo?

– Sobre el Escritorio o cualquier directorio de preferencia del equipo NO funcional hacemos clic derecho y seleccionamos Nuevo > Documento de texto

image


*Nota:

La estructura general de un archivo de Registro se compone de la siguiente forma:

versiónEditorRegistro
línea en blanco
[rutaRegistro1]
"nombreDato1"="tipoDatos1:valorDatos1"
nombreDato2"="tipoDatos2:valorDatos2"
línea en blanco
[rutaRegistro2]
"nombreDato3"="tipoDatos3:valorDatos3"

Por ejemplo, si quisieramos crear una nueva clave llamada “Demo” dentro de HKEY_CURRENT_USER teniendo en cuenta la versión del Registro en Windows 7 y la ruta, quedaría así:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USERDemo]

Se guarda con el nombre que se quiera y la extensión .REG y al ejecutarlo e importarlo la clave quedará creada.

Así mismo, como se puede crear generando la clave, se puede eliminar claves, subclaves y valores, sólo se debe anteponer el signo de menos (-) dependiendo de lo que se quiera quitar.

Por ejemplo, si quisiera quitar la Clave que acabé de crear previamente “Demo” dentro de la rama de registro HKEY_CURRENT_USER quedaría así:

Windows Registry Editor Version 5.00

[-HKEY_CURRENT_USERDemo]

Igualmente, se guardaría con extensión .REG y al ejecutarlo e importarlo ya no existiría esa clave den el Registro de Windows.


En este orden de ideas, para eliminar la clave que nos está generando el problema en las dos asociaciones (.lnk y .exe) debemos agregar el signo de menos (-) antes de toda la clave correspondiente, como podemos de una vez integrar las dos ejecuciones en un mismo archivo, nuestro Blog de notas tendría que quedar así:

Windows Registry Editor Version 5.00

[-HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionExplorerFileExts.lnkUserChoice]

[-HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionExplorerFileExts.exeUserChoice]

image

Ahora, clic en Archivo, Guardar como, le pones cualquier nombre y no podemos olvidar la extensión .REG, para este artículo yo le puse FixLNKEXE.REG:

image

image

*Nota: Si no se le pone el signo de menos (-), lo que hará es crear otra vez la clave de registro (Cosa que no nos servirá).

Si desean, pueden descargar el Fichero de Registro que realiza esta operación (Eliminar las claves afectadas) desde aquí:

*Nota: Este fichero de registro es válido para reparar el problema con sólo una de las dos asociaciones afectadas también, por ejemplo la de Accesos directos (.lnk) por lo que lo pueden descargar y ejecutar en vez de seguir la solución manual documentada anteriormente.

Al ejecutar el fichero, importarlo y reiniciar o cerrar sesión en el equipo, los iconos y las aplicaciones deberían volver a su estado funcional nuevamente.

El problema en el peor de los casos

Por lo general, este problema no llega hasta este punto pero por supuesto ¡Se puede dar! y, ¿Cuál es el peor de los casos?

¿Qué sucede si además de los Accesos directos (.lnk) y los Ejecutables (.exe) ni siquiera la extensión de Texto plano (.txt) y de Registro (.reg) están funcionales?

image

Para este punto, así se afecte uno de los dos (txt ó reg) ya se vuelve algo bastante complejo de solucionar y de hecho desde la cuenta de usuario afectada ya no se podría y es ahí cuando uno podría en primera instancia pensar en restaurar sistema o hasta reinstalar Windows.

Afortunadamente, como comenté en el principio del artículo, el fallo de asociación en la mayoría de las ocasiones afecta por perfil sólamente, es decir en la rama de registro que cada usuario nuevo creado tiene con configuraciones únicas (HKEY_CURRENT_USER).

Lo que indica esto es que en la mayoría de las veces, creando o accediendo a otra cuenta local, podremos tener acceso a la funcionalidad que debe tener Windows para abrir estos tipos de archivos.

Esto sin embargo, no significa que ya nos resignemos y pasemos todo para la nueva cuenta, significa que podremos hacer uso de esta ventaja para acceder y reparar el registro de otro usuario local.

Aquí es donde finalmente damos paso a Sysinternals, específicamente PsExec.

La solución para el peor de los casos

PsExec nos permite básicamente ejecutar procesos y aplicaciones de forma remota en otros equipos o hasta en otras cuentas de usuario locales, lo interesante es que es portable y no es necesario instalar ni realizar configuraciones adicionales, sólo ejecutar y trabajar!

*Nota: PsExec requiere específicamente entregarle credenciales para darle los permisos de ejecución de acuerdo a la tarea que se vaya a realizar.

Volviendo al caso…

Como desde la cuenta NO funcional ya no se puede hacer nada más, debemos Cambiar de usuario e iniciar con otra cuenta que pertenezca al Grupo de Administradores en modo Aprobación de administrador.

Lo que haremos es ingresar al Registro en la rama HKEY_CURRENT_USER pero equivalente al usuario no funcional (De nuevo recordemos que el HKCU varía por usuario) y eliminar las claves de UserChoice en todas la extensiones afectadas.

En realidad, a parte del PsExec, hay otra forma para realizarlo directamente desde Windows por lo que a manera de conocimiento, explicaré las dos aunque enfatizando y recomendando que es mucho más fácil proceder directamente con PsExec.

Forma manual:

Entre todas las ramas que existen en el Registro, hay una específica que contiene la de HKEY_CURRENT_USER entre otras por usuario, específicamente la rama de HKEY_USERS, el problema es que la identificación por usuario lo hace con el SID (Identificador único de usuario) por lo que a simple vista sería complicado determinar cuál es la del perfil que necesitamos arreglar:

image

¿Cómo identificar entonces el SID que pertenece a nuestra cuenta afectada?

¡Aquí es donde entra Process Explorer de Sysinternals!

Como hicimos cambio de usuario (Si no fue así, entren a la cuenta afectada y hacen clic en Inicio, clic en la flecha del botón apagar y Cambiar de usuario) los procesos que están activos en la cuenta NO funcional se visualizarán en Process Monitor, si no habían procesos abiertos, siempre se visualizará el proceso padre: Explorer.exe.

Como predeterminadamente, el usuario al que pertenece no se visualiza debemos hacer clic en el menú View y Select Columns:

image

 

 

 

 

 

 

 

 

 

 

En la ventana de Select Columns en la pestaña de Process Image debemos seleccionar User Name para poder ver esta información y clic en Aceptar para que se visualice en Process Explorer:

image

Ahora, en Process Explorer podremos ver en cuál de los dos procesos de Explorer.exe corresponde al usuario afectado con la columna de User Name:

image

Hacemos doble clic sobre el proceso y nos abrirá la ventana de Propiedades, allí nos pasamos a la pestaña de Seguridad y podremos ver la información que necesitamos:

image

Como ven, debajo de "User” tenemos el “SID” correspondiente a ese proceso que previamente aseguramos que correspondiera al Explorer.exe del usuario NO funcional, específicamente el SID es: S-1-5-21-1231788061-2787996694-3405420119-1006

Teniendo esto en cuenta, procedemos a solucionar el problema, para esto:

Hacemos clic en Inicio, tecleamos Regedit y sobre el resultado clic derecho y Ejecutar como administrador.

Expandimos la rama de HKEY_USERS y posteriormente expandimos la que corresponde al SID que nos entregó Process Explorer del usuario NO funcional. Pueden haber más de 4 que correspondan con el SID, debemos buscar en la primera.

Una vez hecho esto, símplemente buscamos la Clave que corresponde a cada asociación como si lo estuviéramos haciendo desde el Regedit del usuario en cuestión.

Como hay varias extensiones afectadas, debemos ubicar la clave que contiene todas nuevamente y después empezar a reparar una por una. Recordemos que la clave de Asociación de archivos por usuario está en:
HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionExplorerFileExts.exe

Para este caso, variarían la primera por HKEY_USERS y a continuación el SID, por ejemplo si fuera a buscar por el Acceso directo (.lnk) sería:

HKEY_USERSS-1-5-21-1231788061-2787996694-3405420119-1006SoftwareMicrosoftWindowsCurrentVersionExplorerFileExts.lnk

image

Aquí de nuevo, procedemos por extensión afectada (Por ejemplo .lnk, .exe, .txt, .reg) a borrar la sublcave de UserChoice haciendo clic derecho y Eliminar.

Después de esto, reinciamos el equipo y al entrar de nuevo pero en la cuenta NO funcional, todo debe estar asociado correctamente.

Utilizando PsExec:

Como escribí en la descripción de PsExec, nos permite ejecutar procesos pensandos más para una máquina remota pero como todas las herramientas de Sysinternals tiene sorpresas estupendas y es que también lo puedo utilizar para ejecutar procesos en otras cuentas locales.

Desde aquí pueden descargar PsExec y además ver una descripción directa del autor:
http://technet.microsoft.com/es-es/sysinternals/bb897553

Si no queremos complicarnos más de lo que ya estamos con este problema, debemos cerrar sesión desde la cuenta NO funcional (También se puede cambiar de usuario), a continuación Iniciar sesión con una cuenta que esté en el Grupo de Administradores en modo aprobación de administrador y allí descargar PsExec en el Escritorio o en un Directorio de preferencia.

Hacemos clic en Inicio, tecleamos CMD y sobre el resultado clic derecho y Ejecutar como administrador:

image 
Desde la consola de Comandos debemos situarnos en el directorio donde se haya descargado PsExec utilizando el comando “cd”, por ejemplo, para este artículo que descargué la herramienta en el Escritorio, el comando sería:
cd “C:UsersAdministradorDesktop” donde “Administrador” es el nombre de usuario de la cuenta que iniciaron sesión y ENTER:

image

Ahora, como PsExec está en este directorio, podremos conectarnos al Regedit del otro usuario NO funcional, para esto utilizaremos este comando:

PsExec –u <UsuarioActual><UsuarioNOFuncional> –p <PasswordNOFuncional> –h –i C:WindowsRegedit.exe

Donde <UsuarioActual> es la cuenta del Grupo de Administradores con la que iniciamos sesión y descargamos PsExec, <UsuarioNOFuncional> es el nombre de la cuenta que tiene el problema de asociación que deseamos corregir, <PasswordNOFuncional> es la contraseña del usuario NO funcional (El del problema), –h es para que haga la elevación del Token de usuario (Por el UAC) con las credenciales que le estamos enviando e –i es para que ejecute el programa con la ventana interactiva del usuario actual (Para que veamos el Regedit corriendo en el usuario Administrador).

Para este caso por ejemplo sería:

PsExec –u AdministradorDemo –p demopass –h –I C:WindowsRegedit.exe

image

(Hacer clic para ver la captura para verla en tamaño real)

Sin darle mucha importancia al “Acceso denegado”, en unos pocos segundos se debe abrir una ventana de Regedit y para estar seguros de que pertenece al otro usuario NO funcional, podemos abrir Process Explorer, entrar en sus propiedades y ver que tanto el usuario como el SID pertenecen al perfil con problemas:

image

Desde la ventana de Registro ahora ya no tenemos que expandir HKEY_USERS sino que hacemos la búsqueda en la rama de HKEY_CURRENT_USER como si estuviéramos logueados en la cuenta con el problema buscando las claves que originan el problema (Para este artículo por ejemplo .lnk, .exe, .txt, .reg):

image

Aquí, como en todo el artículo, clic derecho sobre la subclave UserChoice y seleccionamos Eliminar, hay que repetir todo esto para cada extensión afectada debajo de la clave:

HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionExplorerFileExts

Reiniciamos el sistema, volvemos a iniciar sesión pero desde la cuenta afectada y el problema ahora debería estar resuelto.

¡Todo listo!

La otra posibilidad de que se empeorara el problema es que afectara por máquina y eso sería a nivel de HKEY_CLASSES_ROOT cosa que en realidad ocurre poco.

Espero les sea de utilidad y puedan ayudarse o disfrutar tanto como yo lo hice.

Saludos,

Checho

 

El Malware “Umgqgk.exe”, la carpeta “RECYCLER” que se creaba al conectar USB, Process Monitor y su solución.

Hay algo que personalmente me molesta y son los diferentes tipos de Malware en los que puede resultar infectado un Equipo por culpa de un dispositivo USB y es que lamentablemente, están los que a pesar de ser muy comunes los Antivirus por ejemplo no los detectan y por supuesto el dispositivo en sí es el que resulta más afectado.

Problema y Solución

En este caso, al conectar cualquier dispositivo USB al equipo en cuestión, me encontraba con una no tan grata sorpresa y es que se creaba una carpeta oculta llamada RECYCLER que incluía un archivo .ini y un ejecutable en su interior:

RC1

Los archivos se denominaban “b845ef76.exe” y “Desktop.ini”.

Además de todo esto, cada carpeta que incluyera la USB se modificaba como Acceso directo por lo que al portar esto la USB, fácilmente podía infectar otro equipo con sólo intentar abrir los directorios.

Por más que analizara el dispositivo con la solución de seguridad (Microsoft Security Essentials) o le diera formato al dispositivo, cuando se reconectaba volvía a reproducirse.

Es ahí entonces cuando decidí ejecutar la mejor herramienta que se puede tener cuando lo demás siempre está perdido, Process Monitor de Sysinternals.

Como no sabía qué proceso analizar (El más opcionado a lo mejor sería Explorer.exe) corrí el monitoreo completo del sistema, di formato al USB previamente y reproducí todo el comportamiento, al terminar paré Process Monitor y empecé a revisar el Log.

Como en estas situaciones de novato con la herramienta, lo que empecé a buscar fue patrones o nombres que tuvieran relación con el problema, por ejemplo RECYLCER y el nombre en cuestión del ejecutable “b845ef76.exe”.

Es normal que en toda la Traza que captura Process Monitor hayan múltiples llamadas y operaciones con estos mismos nombres pues las Aplicaciones o Windows puede verificar siempre que la llave o el registro exista y después realizar las consultas.

Tenía entonces que tratar de subir hasta donde empezaba el llamado y desde ahí ver los comportamientos y bajando un poco me encontré con esto:

RC3

La creación de la carpeta no lo podía impedir ya que era un proceso de Explorer.exe y se completaba satisfactoriamente (No sé cómo impedir que haga algo que no se esté llamando por Registro todavía Winking smile) , sin embargo, como ven hay una serie de consultas a un directorio del sistema: C:UsersHaderAppDataRoamingUmgqgk.exe

Después de esto era que se completaba satisfactoriamente la creación a b845ef76.exe lo que indicaba que ya el dispositivo quedaba infectado y con los archivos dentro de la carpeta.

Ahí estuvo mi primera pista, lo que hice fue entonces desde el Process Monitor hacer clic derecho y Jump To para ir a ese directorio y en efecto habían dos Aplicaciones de extraña procedencia:

RC4

Supuse que éstas eran las que estaba ocultando la carpeta y que además estaban creando tanto los directorios como los archivos que incluían.

Verificando primero con Autoruns que estos archivos no estuvieran arrancando con Windows, procedí a eliminarlos de este directorio.

A continuación, le di formato otra vez al dispositivo, lo desconecte y reconecté para ver si se volvía a reproducir el problema.
Para mi fortuna, ya no se hacían los accesos directos en las carpetas que incluyera el dispositivo y no había nada oculto pero la carpeta “RECYCLER” seguía creándose aunque ya sin ningun archivo.

image

Afortunadamente, las llamadas a los ejecutables y demás archivos ya no se encontraban por lo que había salido ya de algo pero, aún me faltaba descubrir el por qué la carpeta se seguía creando (Esto indicaba además, que la infección en parte seguía).

Volví a correr Process Monitor, reproducí el comportamiento y de nuevo ¡A buscar!

Por más que trataba de encontrar otra llamada a algun ejecutable o que fuera extraño (Dentro de mis pocos conocimientos) no logré tener un buen resultado por lo que se empezaba a volver más complicado de lo que había pensado en un primer momento.

Es aquí cuando recordé que una práctica que puede ayudar con Process Monitor en estos casos es ver dónde empieza a reproducirse el problema (Ya encontrado) y monitorear qué operaciones se estaban realizando antes y esto fue lo que encontré:

I1

Lo primero que hacía antes es realizar unas consultas a controladores de dispositivos USB (La lista era larga antes de que empezara el problema).

No sabía realmente qué hacer, pero, algunas veces el “probar” suele traer buenos resultados, lo que supuse es que la infección podría venir de un controlador USB de los tantos que se estaban llamando y que se activaba al conectar el dispositivo y hacer la consulta.

Por este motivo, abrí el Administrador de dispositivos, localicé todos los Controladores USB y empecé a desinstalarlos uno por uno desde el controlador de Raíz:

RC5

Además de esto, también desinstalé el Controlador USB en el nodo de Controlador de Disco más abajo, le di formato (Otra vez) al dispositivo USB, reinicié el equipo, lo volví a conectar y ¡Wualá! Ya no se creaba la carpeta ni se reproducía comportamiento extraño dentro del dispositivo.

Probé en todos los puertos puesto que en cada uno se reproducía pero para mi alegría, el Malware se había ido!

Queda la duda de cuál controlador en cuestión estaba cargando el Malware sin embargo, quedó un buen aprendizaje de todo esto y es primero siempre tratar de encontrar el origen del problema para poder aprender que considero lo más importante y en ocasiones se vale seguir nuestras propias teorías.

Por supuesto… ¡Continuar aprendiendo Sysinternals!

Espero que le pueda ser útil a alguien el procedimiento que seguí por si tiene un comportamiento similar.

Saludos,

Checho

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

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

DUP2

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:ProgramDataMicrosoftUser 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.

DUP4

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:

DUP3

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:

DUP5

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:

DUP1

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 HKLMSoftwareMicrosoftWindowsCurrentVersionPoliciesExplorer, 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: HKCUSoftwareMicrosoftWindowsCurrentVersionPoliciesExplorer 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:

DUP6

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:

DUP7

DUP8

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

DUP9

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

DUP10

Automaticamente, todas las cuentas tomarían el cambio:

DUP11

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:ProgramDataMicrosoftUser 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_MACHINESOFTWAREMicrosoftWindowsCurrentVersionPolicies

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

DUP12

La debemos llamar Explorer:

DUP13

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:

DUP14

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:

DUP15

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

DUP16

Espero les pueda ser de utilidad.

Saludos,

Checho

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

image

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:

Capture1

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:

Capture2

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:

Capture3

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:

Capture4

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:

Capture5

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

Capture6

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

Capture7

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.

Capture8

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:

Capture9

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.

Capture10

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:

Capture11

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

Capture12

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

Capture13

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

Capture14

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

Capture15

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:

Capture01Capture02

Capture03

Capture04Capture05

Capture06Capture07

Capture08Capture09

Capture010

Capture011

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

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