Checho's Blog : Windows 7, Process Monitor

La “Cuenta fantasma” que quería iniciar sesión, Process Monitor y su solución.

Checho — Fri, 03 Feb 2012 12:20:00 GMT

El problema

Normalmente, suelo tener algunas máquinas virtuales en las que me apoyo para los diferentes artículos que escribo aquí, o bien para las pruebas que requiera hacer, sea reproduciendo problemas, o tratando de entender comportamientos de Windows.

Las máquinas virtuales las administro desde VMware, y una de las características de éste gran Gestor, es que si se instala Windows utilizando el asistente, sea con los pasos básicos o avanzados, al darle el usuario que sea quiere crear, además de que no lo pregunta en la instalación (Lo hace de forma desatendida), es que Windows siempre hará autologon con el usuario.

*Nota: Pueden ver más a fondo los procesos de Autologon en Este artículo.

Lamentablemente, en una de las máquinas, tuve que eliminar una de las cuentas porque la dañé completamente; no tuve problema con este proceso, el problema empezó al empezar a reiniciar normalmente el equipo, ya que cada que entraba, obtenía un mensaje de error con respecto a una contraseña:

Al darle al botón Ok, mi sorpresa fue que Windows todavía estaba intentando ingresar con el usuario que yo había borrado (WinBoy):

Por supuesto, no podía iniciar de ninguna forma sesión con el usuario, por lo que siempre tenía que darle al botón de Cambiar de usuario, escribir manualmente alguno de los otros usuarios e iniciar sesión.

Lo primero que hice fue ir hasta la ventana de Administración de usuarios, pero la cuenta (Tal como debía ser), no aparecía por ningún lado:

Los archivos de usuario, a pesar de que yo pensé haberlos borrado también, seguían existiendo en el directorio de C:\Users, pero esta no debería ser razón para que iniciara, puesto que la cuenta no estaba creada.

¿Cuál era el problema entonces?

La causa

El problema estaba sucediendo antes de que se iniciara Windows, por lo menos el escritorio; sólo existe una herramienta capaz de darme un diagnóstico de lo que sucede antes, por supuesto, me refiero a Process Monitor de Sysinternals.

Process Monitor tiene una característica llamada “Enable Boot Logging” que, permite ubicar el controlador de Process Monitor (PROCMON20.SYS) para que inicie antes que todo, por lo que generará un log que irá incrementandose hasta que se abra nuevamente dentro de Windows y se guarde.

Gracias a esto, podemos ver las Operaciones que suceden incluso desde el Winlogon, cosa que no es posible ni con el mismo sistema operativo.

Para habilitar la característica, basta con Abrir Process Monitor, e ir al menú Options y seleccionar “Enable Boot Logging”:

Lo habilité, abrí Process Monitor para empezar a analizar el log, y empecé a buscar por la palabra clave que pudiera darme más ayuda, en este caso, por supuesto, el nombre de usuario: “WinBoy”.

Después de algunos resultados que me decían que las claves del usuario en ProfileList todavía existían, encontré esto:

*Nota: Clic en la imagen para verla en tamaño real.

Windows estaba abriendo la clave Winlogon que contiene todas las claves y subclaves que hacen referencia a alguna operación en el proceso de inicio de sesión; a continuación estaba haciendo unas consultas a unos valores llamados DefaultUserName, DefaultDomainName y DefaultPassword. En el artículo acerca del Autologon, vimos un poco de lo que trataban estos valores, pero básicamente, junto con AutoAdminLogon, habilitan el Inicio automático (Autologon) y además establecen el nombre de usuario, dominio y contraseña que debe utilizarse.

DefaultUserName, en este caso estaba todavía haciendo referencia a la cuenta que estaba eliminada:

*Nota: “Data” es el contenido que tendrá, en este caso “WinBoy”.

Esta era la primera respuesta del por qué intentaba iniciar con una cuenta que ya no existía, al estarla referenciando, y todavía existir sus claves correspondientes, Windows aún la referenciaba.

DefaultDomanName no tenía valor, por lo que estaba tomando el Grupo de Trabajo predeterminado que tenía Windows.

Ahora, el valor de DefaultPassword, a diferencia de los anteriores, tenía como resultado NAME NOT FOUND, esto quiere decir que, a pesar de tener el Autologon indicado, Windows no encontraba la contraseña por ninguna parte; esto nos da la respuesta del por qué el primer mensaje de que el nombre de usuario o contraseña eran incorrectos.

La solución

Ya tenía detectado el problema, la solución consistía en evitar que Windows suigiera intentando hacer el Autologon, para esto entonces, desde Process Monitor utilicé la característica de “Jump to” para ir directamente a la clave de Registro de Winlogon y ubicar los valores que estaban causando el problema:

Lo que hice fue primero, modificar el contenido de AutoAdminLogon para cambiarlo de “1” a “0” y que se desactivara, y posteriormente eliminé el valor de DefaultUserName para que no tuviera nada que buscar ahí =)

Al reiniciar el equipo, el agradable resultado fue:

El inicio de sesión común en Windows había retornado a su normalidad.

¡Problema solucionado!

Saludos,

Checho

La Subclave de Registro que no quería eliminarse, el pequeño bug de PowerShell, Process Monitor y su solución

Checho — Thu, 02 Feb 2012 13:41:00 GMT

Hola a todos,

Este no iba a ser el artículo que iba a poner de primero, pero resultó y es para mí, de lo más interesante porque personalmente, aprendí y eso le da un buen sentido.

El problema

Estoy tratando de conocer y comprender, hasta donde sea capaz mi conocimiento, un poco más a fondo el funcionamiento de la Asociación de archivos en Windows (En esta semana pondré el artículo completo refiriendome al tema).

Una de las formas más sencillas de aprender sobre Windows, es dañando y tratando de arreglar, por lo que modifiqué para reproducir el problema común de la perdida de asociación a los accesos directos, lo que causa que todo se abra con un solo programa:

A continuación, estaba tratando de utilizar PowerShell, para hacer uso de un cmdlet para eliminar la subclave de registro que causa este problema, es decir:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.lnk\UserChoice

Como PowerShell trabaja las claves de registro de la misma forma que lo hace con los archivos, bastaba con hacer referencia a una pequeña línea de comandos utilizando Remove-Item, así:

Remove-Item –Path HCKU:\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.lnk\UserChoice

El problema, es que cada que ejecutaba la línea anterior, recibía un mensaje un poco extraño de PowerShell:

Según el mensaje que PowerShell me daba, Remove-Item no podía eliminar la subclave de Registro porque no existía, aunque efectivamente la clave estaba:

Aunque PowerShell estaba reconociendo la excepción, no necesariamente estaba entregando el mensaje que correspondía, ¿Cuál era el problema entonces si la clave existía?

La causa

Como PowerShell no era capaz de indicar qué era lo que realmente le pasaba, había que pasar a preguntarle directamente a Windows, y para hacer esto, como siempre, nada mejor que Process Monitor de Windows Sysinternals.

Después de correr Process Monitor e intentar ejecutar la línea de comandos, bastó con volver a Procmon, parar el monitoreo y buscar directamente por la subclave UserChoice, como se recomienda, de abajo hacia arriba; esto fue lo que encontré:

*Nota: Clic para ver la imagen en tamaño completo.

El proceso powershell.exe estaba tratando de abrir la clave de UserChoice, pero como ven, el resultado era ACCESS DENIED, lo que llevaba a la respuesta, el problema estaba en permisos, ¡No en ausencia de la clave!

Process Monitor permite saltar directamente a la clave, así que lo hice, y después de esto entré a la ventana de Permisos de la clave haciendo clic derecho, Permisos, y en primera instancia, todo estaba bien para los usuarios de los grupos Administradores; el único y más importante problema, es que el usuario con el que había iniciado sesión, y con el que estaba tratando de eliminar la clave, tenía un permiso especial que me estaba denegando algo:

*Nota: Los Permisos Especiales en Windows contienen un filtro mucho más completo de denegación o aprobación en las operaciones que se pueden hacer a nivel de sistema de archivos, o bien sobre claves y valores del Registro de Windows.

Para poder ver los permisos especiales, basta con hacer clic en el botón inferior de Avanzado (No visto en la captura anterior), detecté el usuario que tenía los permisos especiales denegados e hice clic en el botón Editar para verlos:

Mi usuario tenía en blanco todo lo que fuera permitir, eso quiere decir que los tomaría de los permisos predeterminados, pero tenía como Denegado el permiso a establecer valores (Set Value), lo que equivale a escribir:

La solución

Con el problema detectado, ya la solución sería un poco más sencilla, al saber que tenía problemas de permisos, específicante de escritura, PowerShell no iba a ser capaz de eliminar la clave (No podía escribir nada encima); así que para no modificar mucho los permisos, símplemente cambié el de Denegar para Establecer Valor (Set Value) a Permitir (Allow):

Finalmente, volví a ejecutar la línea de comandos en PowerShell y este fue el resultado:

¡Todo blanco! Lo que indica que se había ejecutado correctamente, y además la clave se elimino en efecto sin ningun problema:

El pequeño Bug sobre los mensajes de información en las excepciones de PowerShell ya llegó al Equipo de PowerShell para mejorarlo en futuras actualizaciones.

Saludos,

Checho

La aplicación “BlenderPortable.exe” que no quería instalar en Windows 7, Process Monitor y su solución.

Checho — Thu, 26 Jan 2012 10:45:00 GMT

Ya lo he dicho en otras ocasiones (Artículos), pero no me canso de repetirlo, los Foros de Microsoft TechNet y Microsoft Answers, son el mejor lugar tanto para compartir conocimiento, aprender e interactuar con nuevos problemas al mismo tiempo que se trata de ayudar a otras personas en situaciones complicadas.

Hoy quiero compartirles un inconveniente que tuve al tratar de instalar una aplicación llamada BlenderPortable en un Equipo Windows 7, justo co la intención de investigar otro comportamiento.

El Problema

Cada que trataba de instalar la aplicación Blender Portable, al ejecutarlo haciendo doble clic, justo después de indiciar la ruta de instalación, estaba recibiendo un mismo mensaje de error:

El error indicaba que tenía problemas para escribir en la ruta de instalación, es decir en C:\Program Files\BlenderPortable\

Si le daba reintentar, ocurría el mismo mensaje de error, si le daba Ignorar, me entregaba de nuevo lo mismo pero con otro archivo diferente, por lo que el problema no era del archivo a copiar en cuestión, sino de cualquier archivo que estaba tratando de escribir en el directorio.

La causa

Como he dicho en otros problemas, suele ser una buena práctica ejecutar de nuevo las aplicaciones que presentan estos errores con privilegios elevados, es decir, haciendo clic derecho sobre el ejecutable, y seleccionando “Ejecutar como administrador”.

Como se esperaba, la aplicación pasó a instalarse normalmente, esto indicaba que el problema iba por algun tema probablemente de permisos.

Para asegurarme específicamente dónde, procedí a ejecutar Process Monitor de Sysinternals, seguir el comportamiento de Windows mientras intentaba instalar la aplicación y este fue el resltado al ver el log después:

En principio, cuando Windows hacía uso de la API con la función CreateFile para generar el directorio de C:\Program Files\BlenderPortable y empezar a escribir, no estaba encontrando la ruta, como muestra el resultado de PATH NOT FOUND.

A continuación, Windows consulta los eventos que tiene registrados, y hace el llamado del mensaje de error, junto con el típico sonido, que incluso lo consulta en C:\Windows\Media\Windows Critical Stop.wav.

Predeterminadamente, Windows debería estar en la capacidad de crear el directorio, siendo primera vez que lo consulta, la pregunta era: ¿Por qué no lo estaba creando?

Buscando un poco más a fondo en el Log, este fue el resultado:

Cuando el proceso BlenderPortable.exe estaba tratando de crear el directorio C:\Program Files\BlenderPortable estaba obteniendo un ACCESS DENIED (Acceso Denegado), ¿Qué significaba? ¡No tenía permisos!

El Control de Cuentas de Usuario (UAC) en Windows 7, entre otras cosas, es capar cuando una aplicación está intentando escribir en directorios protegidos del sistema, y mediante un engaño, les hace creer que tienen permisos de escritura y que la aplicación no tenga ningun problema.

Como muy amablemente me hizo caer en cuenta Mark Russinovich sobre este problema, seguramente la característica llamada Deteccción Heurística (Que detecte que es un instalador), no estaba funcionando con esta aplicación en cuestión.

La solución

Por seguridad, no es prudente entonces permitirle a la aplicación que escriba a su antojo en el directorio, sin embargo, la solución consisitió en crear manualmente la carpeta BlenderPortable en el directorio C:\Program Files, a continuación entrar a las Propiedades de dicha carpeta, pestaña de Seguridad, botón Editar y darle a los usuarios estándar permisos de escritura sobre la carpeta:

Después de esto, procedí a ejecutar la aplicación nuevamente con doble clic, y para mi fortuna, ¡Caso solucionado! La aplicación instaló correctamente.

Espero que si tienen algun problema similar, se animen a intentar segurilo, se darán cuenta de que es sumamente grato y productivo lo que se puede aprender al lograr solucionarlo.

Saludos,

Checho

El icono de la función “Crear carpeta” en el menú contextual que no se encontraba, Process Monitor y su solución

Checho — Thu, 05 Jan 2012 17:35:00 GMT

De nuevo estamos por aquí, esta vez quiero compartirles un pequeño problema que tuve hace poco en un equipo con Windows 7 que, aunque no interfería en el funcionamiento normal, no podía dejar pasarlo.

El problema

Una de las tareas que uno más realiza en Windows, es utilizar el menú contextual que se despliega al hacer clic derecho con el mouse, el comportamiento de éste depende de donde estemos, es decir, una página web, una aplicación, etc.

Normalmente en Windows, se pueden realizar una serie de tareas predeterminadas y básicas que nos dan acceso rápido a características o a funciones.

En este caso, estaba tratando de crear una simple carpeta haciendo clic derecho en un espacio vacío, seleccionando Nuevo, y Carpeta.

No tenía problema para crear la carpeta, sin embargo siempre que trataba de escoger la opción, el icono de la función de “Carpeta” no era el que Windows trae de forma predeterminada:

Como ven, el icono era el de una hoja en blanco con unos pequeños signos encima, y no el de la carpeta en miniatura.

La causa

Comparar este con otro tipo de problemas que seguramente ustedes han visto, o que he escrito aquí, no sería la gran cosa, sin embargo, ¿Por qué aceptarlo si no debería funcionar así?

Cuando se pierden los iconos que identifican una aplicación o función, indica que hay un problema con su asociación, aunque en este caso tenía que investigar cuál era. Para esto, como siempre, corrí Process Monitor de Sysinternals y a continuación reproducí el comportamiento, es decir, crear una carpeta cualquiera.

Lo siguiente era llenarme de paciencia y empezar a buscar en la traza que arroja Process Monitor e intentar identificar qué era lo que causaba que Windows no encontrar el problema.

En principio busqué por “folder”, pero eran demasiados resultados y no pude acomodarme fácilmente, así que decidí empezar a buscar por “new” en separado, hasta que después de unos minutos, di con la clave que podría ayudarme a entender un poco más el inconveniente:

Windows estaba intentando hacer una consulta a la clave HKEY_CLASSES_ROOT\Folder\ShellNew\IconPath con un resultado de SUCCESS.

La razón por la que era importante esto a pesar de que diera exitoso el resultado, es que en HKEY_CLASSES_ROOT se alojan todas las asociaciones que administra el sistema operativo, aunque en HKEY_CURRENT_USER guarda gran parte por usuario.

Aquí además se estaba refiriendo específicamente a la de “Folder” por lo que estaba en la asociación correcta.

El valor IconPath referencia a la ruta interna dentro de Shell32.dll donde Windows puede extraer el icono necesario, pero al dar resultado exitoso descarté de que estuviera faltante o algo similar.

Lo que me llamó la atención, son las dos operaciones un poco ilógicas que intentaba hacer Windows después de hacer el Query al anterior valor, ambas utilizaban la función de CreateFile, la primera para intentar crear un directorio con nombre “Windowssystem32shell32.dll” y la segunda para intentar crear el archivo Shell32.dll dentro de la carpeta de C:\Windows. Ambos sin embargo, tenían un resultado de NAME NOT FOUND.

A primera vista, si se divide con el signo de Backslash (\) los directorios que intentaba crear Windows, existen realmente, es decir C:\Windows\System32\Shell32.dll, pero ¿Por qué sin los signos?

Decidí entonces seguir el comportamiento en un equipo que tuviera el icono de la carpeta asociado correctamente, y este fue el resultado en la misma clave y valor:

También tiene SUCCESS, pero esta vez, inmediatamente hace la consulta en el valor de IconPath, utiliza la función de RegCloseKey para terminar la operación en la clave HKEY_CLASSES_ROOT\Folder\ShellNew.

¿Por qué en el sistema funcional no intentaba crear también estos directorios?

La respuesta la tenía Process Monitor por supuesto, desde la misma herramienta en la columna siguiente a Result “Detail”, se puede ver todos los detalles de la operación que se está haciendo, pero se puede ir mucho más a fondo si se hace clic derecho sobre la operación y se selecciona Properties, o bien con hacer doble clic que abre la misma ventana.

Casi todas las operaciones a nivel de Sistema de archivos o de Registro, manejan algun contenido, cuando son consultas por supuesto, tiene que hacer referencia al contenido que consultó, esto lo muestra en un campo llamado “Data”.

Para mi sorpresa, esto fue lo que vi y que me dio la respuesta al abrir las propiedades tanto de la operación en el sistema funcional, como en el que no mostraba el icono correctamente:

Sistema funcional:

Sistema NO funcional:

“Data”, era la misma ruta en ambos, pero como ven, en el primero hacía referencia correctamente a la ruta, es decir a %SystemRoot%\System32\Shell32.dll,3, en cambio abajo trataba de buscar en el mismo directorio pero sin que estuviera separado por el backslash correctamente: %SystemRoot%system32shell32.dll,3

Si Windows no puede encontrar el directorio que está buscando, presentará los iconos (Si es de asociación) genéricos cuando no puede determinar el que le corresponde.

La solución

Sambiendo esto, desde Process Monitor utilicé la característica de “Jump to” para ir directamente a la clave de Registro implicada:

Hice doble clic en el valor IconPath y corregí correctamente la ruta de forma manual haciendo doble clic sobre ésta, es decir, de %SystemRoot%system32shell32.dll,3 a %SystemRoot%\system32\shell32.dll,3

Cerré el Registro y después de unos segundos, hice nuevamente clic derecho para abrir el menú contextual, el item de Nuevo y para mi fortuna, ¡Mi icono estaba de vuelta!

Lo importante, a mi forma de ver, el solucionar un problema que aparentemente no es muy dañino, no sólo permitirá garantizar el nivel funcional como debe ser, sino lo más importante, siempre podremos aprender mucho del gran mundo de Windows con los detalles más mínimos y tal vez insignificantes.

Claro esta, con una herramienta igual de increible que Windows como lo es Process Monitor.

Saludos,

Checho

Windows 7, Internet Explorer 9 y la Vista de Compatibilidad

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

Hola a todos,

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

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

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

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

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

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

¿Cómo funciona?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Lista de Compatibilidad a través de GPO

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

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

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

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

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

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

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

Analizando la política…

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

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

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

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

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

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

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

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

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

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

Navegamos hasta la clave:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft

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

La llamamos Internet Explorer

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

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

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

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

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

¡Esto es todo!

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

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

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

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

Saludos,

Checho

Habilitar el Modo de Compatibilidad de una Aplicación para todos los usuarios utilizando el Editor de Registro en Windows 7

Checho — Wed, 28 Dec 2011 20:15:00 GMT

Hola a todos,

Después de 39 artículos técnicos escritos en este Blog durante todo este año, llegamos finalmente al último post que cierra completamente el 2011.

Actualmente, el flamante 7 tiene la gran ventaja de ser Compatible con una gran mayoría de aplicaciones del mercado, incluso para algunas que no han evolucionado a Windows 7. Pero, no deja de existir el problema con aplicaciones “In house” o “A la medida” que manejan actualmente muchas compañías, y que además, se encuentran tal vez las más críticas para la organización, lo que representa por supuesto, un camino un poco más complejo para migrar todas las máquinas al nuevo sistema operativo.

Para fortuna de nosotros, con una gran cantidad, basta con utilizar algunas herramientas de Microsoft como ACT (Application Compatibility Toolkit) o las más poderosas de Sysinternals para detectar por qué en realidad las aplicaciones no parecen funcionar de manera nativa correctamente.

Esto sin embargo, no queda aquí, muchas de estas aplicaciones no están desarrolladas correctamente, a primera vista, parece que sólo corrieran en Windows XP, pero si utilizamos una de las características embebidas en Windows 7, denominada las Fichas de Compatibilidad, veremos que muchas, de repente, ya funcionan bien. :)

Para habilitar las Fichas de Compatibilidad, basta con hacer clic derecho sobre el ejecutable o accedo directo de la aplicación, seleccionar Propiedades, ir a la pestaña de Compatibilidad y seleccionar el item de “Ejecutar este programa en modo de compatibilidad para” escogiendo uno de los sistemas operativos desplegados abajo:

Esta configuración se puede aplicar para todos los usuarios fácilmente, basta con hacer clic en el botón inferior de “Cambiar configuración para todos los usuarios” y tendremos la misma ventana donde podremos especificar el modo que se guardará para la aplicación sin importar el usuario que inicie sesión:

La pregunta es: ¿Qué es lo que hace el Modo de Compatibilidad para que varias aplicaciones funcionen?
La respuesta se puede reproducir a nivel general en una palabra: ¡Mentir!

Windows internamente, una vez habilitado el modo de compatibilidad para alguna versión anterior, es interceptar la llamada que hace la aplicación al sistema para verificar, entre otras cosas, la versión del sistema operativo sobre el que está corriendo, y devolverle el resultado que espera, en las mayorías de las ocasiones –Que uno selecciona-, es decirle a la aplicación que está sobre Windows XP Service Pack 3 y no sobre Windows 7 Service Pack 1 por ejemplo. A esto se le llama: Mentira sobre versión.

Las aplicaciones que no están bien desarrolladas para medir si la plataforma sobre la que están corriendo sí es la apropiada, suelen comprobar a veces hasta con un número de versión para decir si son compatibles o no, el mentir sobre la versión solventa esto, y por eso la aplicación sigue corriendo como debería.

*Nota: Estas capas de compatibilidad hacen más tareas internamente, pero aquí estoy especificando el concepto de esta característica a nivel general con objetivos del post.

Ahora, nosotros no tenemos que preocuparnos cómo hace Windows realmente este engaño, pero para poder reproducirlo y personalizarlo, debemos aprender dónde consulta Windows las aplicaciones a las que les debe establecer el modo de compatibilidad.

Para el resto de este post, tomaré de referencia la aplicación UltraISO instalada en una máquina mía para seguir y explicar el procedimiento.

Si utilizamos Process Monitor de Sysinternals para seguir el comportamiento de Windows mientras habilito el modo de compatibilidad con Windows XP como mencioné anteriormente, y luego veo la traza que deja, podremos ver esto:

La cuarta operación de la captura, muestra que al momento de establecer la Compatibilidad, Windows hace uso de la función RegSetValue para escribir el valor con la ruta completa del Ejecutable al que queremos engañar en la clave:

HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers

En este caso, el valor mío fue la ruta a UltraISO, es decir:
C:\Program Files (x86)\UltraISO\UltraISO.exe

Si desde Procmon accedemos al Registro, el valor por cada aplicación que se le indique el modo de compatibilidad se vería así:

Como nombre de Valor, la ruta completa como lo especificaba Process Monitor, y como contenido de valor (Data) el sistema operativo al que se quiere emular, en este caso WINXPSP3 que corresponde a Windows XP con Service Pack 3.

En este orden de ideas, es todo lo que Windows escribe en el registro, y lo único que necesita para saber que la ruta y el contenido especificado le dirán a qué aplicación debe mentir, y con qué sistema operativo.

Como ven, el procedimiento manual es realmente muy sencillo, pero habrán ocasiones en que como todo buen IT PRO, se quiere automatizar para ganar tiempo y productividad.

En este caso, el cambio en el Registro se podría hacer en el usuario para el que se vaya a copiar el perfil predeterminado con algún método ya conocido, o bien se puede cargar el Hive para personalizar la rama de HKCU predeterminada, o hasta cargar el Hive antes de instalar Windows para que se vuelva una configuración lista justo antes de la instalación; la decisión es de cada uno.

Esto valdría para el usuario actual, pero en caso de que la aplicación sea algo más general, para varias máquinas y usuarios, se puede forzar a que esté en este modo para todos y que no se pueda cambiar.

Modo de Compatibilidad para todos los usuarios

Predeterminadamente, Windows ya busca si existen aplicaciones en la lista de Layers para toda la máquina:

El resultado, sin embargo, es NAME NOT FOUND (No encontrado), lo que indica que la clave Layers no está creada de forma predeterminada.

En este caso entonces, lo que haré será indicar el ejecutable de mi aplicación UltraISO para que se comporte en modo de compatibilidad con Windows XP para todos los usuarios que inicien sesión.

El procedimiento es exactamente el mismo, lo único que deben cambiar es la ruta del ejecutable.

*Nota: Deben tener en cuenta la ruta completa del ejecutable, incluyendo la extensión, por ejemplo para el mío sería: C:\Program Files (x86)\UltraISO\UltraISO.exe

Lo que haremos, básicamente, será crear la clave que hace falta y hacer uso de los valores que se pueden establecer, y que sería lo que Windows haría en caso de cambiar la configuración para todos los usuarios.

Debemos hacer clic en Inicio, y ejecutar Regedit.exe para abrir el Editor de Registro de Windows.

Navegamos hasta la clave:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags

Clic derecho sobre la clave AppCompatFlags, seleccionamos en el menú contextual Nuevo (New) y clic en Clave (Key):

Como nombre de clave, la debemos llamar Layers

Nos situamos sobre Layers, en la parte derecha, debajo del Valor predeterminado y en un espacio en blanco, clic derecho, Nuevo (New), Valor de cadena (String):

El nombre del Valor, debe ser la ruta completa de la aplicación, para mi caso por ejemplo, sería: C:\Program Files (x86)\UltraISO\UltraISO.exe

Aquí está especificado la aplicación, pero todavía no la capa sobre mentira de versión, para esto, hacemos doble clic en el valor y en el contenido le debemos especificar la variable correspondiente al sistema operativo a emular, pondré dos de las principales correspondientes a Windows XP:

Windows XP Service Pack 2: WINXPSP2
Windows XP Service Pack 3: WINXPSP3

En mi caso, como era con Service Pack 3, la variable fue: WINXPSP3

Bastará con aceptar el cambio y ¡Listo! Nuestra aplicación ya maneja el modo de compatibilidad sin importar el usuario que inicie sesión, para verificarlo, basta con entrar con otro usuario, ir a las propiedades del ejecutable y pestaña de Compatibilidad:

Espero que les pueda ser de utilidad, y no siendo más, sólo queda por decir:

¡Muchas gracias y Feliz Año Nuevo!

Checho

Cambiar el Shell de ejecución predeterminado (Explorer.exe) en Windows 7.

Checho — Sun, 18 Dec 2011 22:38:00 GMT

Hola,

Este, más que un artículo, quiero verlo como un “Tip extendido”, puesto que es algo que he visto en varias consultas de los Foros y puede llegar a ser muy útil.

Cuando se implementa Windows en empresas Bancarias por ejemplo, o desde un Café Internet, se decide a veces que el personal sólo puede utilizar una sola aplicación todo el tiempo (En sucursales para el caso de los Bancos). A partir de esto, nace la necesidad de que el usuario no pueda interactuar con más aplicaciones ni mucho menos el algun proceso que parta del Explorador de Windows, como ventanas, barra de tareas, etc.

Lo que haremos en este post es configurar el Shell predeterminado de Windows 7, es decir, el Explorer.exe (Explorador de Windows), para que no sea el que inicie y en cambio, lo haga una aplicación que nosotros mismos definamos, como Internet Explorer o alguna de terceros.

*Nota: Explorer.exe es el proceso Padre en el sistema Operativo, a partir de este, se ve la barra de tareas, el menú de inicio, las ventanas y además representa el token de seguridad que adquieren los demás procesos que se ejecutan después de éste.

Primero veremos un poco de cómo determina Windows cuál es el Shell que debe ejecutar, cómo se configuraría por políticas de Grupo y finalmente cómo se haría lo mismo pero editando el comportamiento natural de Windows.

No hay herramienta más eficaz para comprender cómo funciona Windows que Process Monitor de Sysinternals, específicamente, la característica de Boot Logging que me permite ver todo lo que sucede internamente en el sistema operativo mientras está iniciando sesión, es decir, podremos ver qué es lo que hace Winlogon, proceso del sistema encargado del proceso de Logon en Windows.

Un poco del proceso de Winlogon

Si habilitamos la característica y hacemos el filtro por “Winlogon”, entre otras muchísimas tareas importantes, en qué momento se llama al Shell:

Recordemos que de Process Monitor, podemos destacar tres principales columnas, la de la primera a la izquierda llamada “Operación” que nos dice qué tipo de operación se está haciendo, es decir, si es a nivel de Sistema de archivos, de Registro, de Red, etc; la columna central “Ruta” que nos indica dónde se está realizando la operación exactamente, y por último, la columna de “Resultado” que nos dirá con unas palabras claves si la operación que se intentó hacer en la ruta definida tuvo éxito, no se encontró, se pasó a otra operación, tuvo acceso denegado por permisos, etc.

En este orden de ideas, y analizando el resultado de la captura anterior, vemos que Windows utiliza la función RegOpenKey para abrir la clave de registro:
HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell

Sin embargo, el resutlado es NAME NOT FOUND, lo que indica que el valor Shell no existe predeterminádamente. Recordemos que HKEY_CURRENT_USER corresponde a las configuraciones por usuario, y prevalecerían con respecto a HKEY_LOCAL_MACHINE en caso de que existiera el valor y su contenido.

Después de esto, Windows utiliza la misma función pero esta vez para ir a la clave:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\WinLogon, la diferencia con la anterior, a parte de que consulta en HKEY_LOCAL_MACHINE que corresponde a todos los usuarios, es que esta vez el valor de Shell sí arrojó el resultado de SUCCESS (Exitoso) cuando se llamó a la función de RegQueryValue (Para consultar valores y contenido), por último cierra esta clave con la función RegCloseKey.

Después de esto, va lo interesante y es que utiliza la función de CreateFile para crear el proceso de Explorer.exe, justo después de haber leido el contenido del valor.

Si desde Process Monitor se abre el Editor de Registro haciendo clic derecho en la operación donde se consulta el valor de Shell, veremos esto:

El contenido del valor de Shell es “explorer.exe”, razón por la que Windows crea este proceso después de la operación de consulta.

*Nota: Esto es sólo una parte de lo que sucede al inicio de Windows y corresponde a Winlogon, hay muchas más tareas que en este artículo no se tocarán.

En conclusión, para evitar que Windows cargue el Explorer.exe y en vez de esto, ejecute de inmediato una aplicación personalizada, debemos editar el contenido de este valor poniendo la ruta completa del ejecutable y reiniciar, auque existe una alternativa más sencilla que es la Política de grupo. A continuación, pasaremos a ver los dos métodos existentes.

*Nota: El valor predeterminado está como explorer.exe (sin ruta) es porque está dentro de una variable de entorno del sistema operativo, lo que dará la posibilidad de llamar al ejecutable desde cualquier parte directamente.

*Nota 2: De aquí en adelante, me referiré a una ruta de ejemplo a la aplicación predeterminada, que en mi caso será Internet Explorer, cada uno debe cambiarla por la ruta completa de la aplicación que deseen, incluso si está en un recurso de red.

Método 1: Política de Grupo

Sea desde el Editor de Políticas de Grupo el Directorio Activo, o desde la Consola local en cada máquina, vamos al nodo de User Configuration (Configuración de usuario), Administrative Templates (Plantillas administrativas), System (Sistema), seleccionamos la política de Custom User Interface (Interfaz de Usuario personalizada):

Bastará entonces con seleccionar el radio de “Habilitar” y especificar la ruta completa en el cuadro de texto de la parte inferior:

Por último, bastará con cerrar sesión o reiniciar en los equipos unidos al dominio, o con los usuarios locales y el resultado será la ejecución sólo de la aplicación al iniciar sesión y no habrá nada del Explorador de Windows.

1.1. Modificando la política manualmente…

Como siempre, puede que haya equipos que no cuenten con la Consola del Editor de Políticas de Grupo –En el caso de las ediciones de Windows en la casa que no sean Enterprise o Ultimate-. Aquí entonces, debemos proceder a “forzar” el comportamiento de la política manualmente mediante el Editor de Registro de Windows.

Si no se sabe cómo, bastará con llamar nuevamente a Process Monitor y seguir el comportamiento de Windows mientras uno está aplicando la política en un equipo que lo soporte; aunque aquí no mostraré todo el proceso por lo que he tocado el punto en otros artículos, sí quiero que vean el resultado para esta política especialmente:

El comportamiento es el mismo por cada política, los dos archivos referenciados en la captura (ntuser.pol y Registry.pol) son los que se encargan de copiar y replicar la política por cada usuario que inicie sesión en el equipo.

Ya viendo la política en cuestión, vemos que Windows hace uso de la función de RegSetValue para escribir el valor de Shell en la clave:
HKEY_CURRENT_USER\Microsoft\Windows\CurrentVersion\Policies\System

Abriendo las propiedades de la operación haciendo doble clic o clic derecho y Properties, veremos qué es lo que está escribiendo en este valor:

Como lo muestra “Data”, en este valor, después de crearlo, se está escribiendo como contenido toda la ruta a la aplicación que se especifique en la política, para mi caso: C:\Program Files (x86)\Internet Explorer\iexplore.exe

Para replicar la política, lo que tendríamos que hacer sería:

- En cada equipo donde se desee aplicar (O distribuyéndolo), se debe ir hasta la clave:
HKEY_CURRENT_USER\Microsoft\Windows\CurrentVersion\Policies

- Clic derecho, Nueva > Clave

- La llamamos System

- Seleccionamos la nueva clave, en la parte derecha, clic derecho, Nuevo > Valor de cadena

- Lo llamamos Shell, doble clic para editarlo y le indicamos la ruta de la aplicación a ejecutarse en vez del Explorer.exe

- Cerramos sesión o reiniciamos el equipo y estará hecho.

*Nota: Si algo sale mal, bastará con volver a entrar al Registro y arreglar la ruta o bien eliminar la clave para que vuelva al comportamiento natural.

Método 2: Cambiando el comportamiento predeterminado de Windows 7

Como vimos al principio, en cada inicio, Windows busca su Shell predeterminado, que es Explorer.exe y lo ejecuta para mostrar interfaz al usuario que recién ingresó.

Para modificar este comportamiento y cambiar el Shell por uno predeterminado, debemos hacer lo siguiente:

- En el Equipo que se desee tener esta configuración para todos los usuarios, hacer clic en Inicio, escribir Regedit, clic derecho, Ejecutar como administrador, y navegar hasta esta clave:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon

- Doble clic en el valor Shell para modificarlo, y lo cambiamos por la ruta que deseamos sea la predeterminada, en este caso a la de Internet Explorer:

- Aceptamos, cerramos sesión o reiniciamos el equipo, y ahora, cada usuario que entre, tendrá como Shell predeterminado, la aplicación que hayamos configurado:

Si no queremos que sea para todos los usuarios, sino para algunos en especial, debemos seguir hacer lo siguiente:

-Navegar hasta la clave:
HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon

- Clic derecho sobre el espacio en blanco a la derecha, seleccionar Nuevo > Valor de cadena

- Debemos llamarla Shell, ya que como verán, no existe de forma predeterminada.

- Doble clic para editar el valor y especificar la ruta a la aplicación.

- Cerrar sesión o reiniciar el sistema, así, sólo el usuario al que se le haya personalizado el Shell predeterminado, será el que se le presente, los demás usuarios tendrán el Explorer.exe como normalmente estaría.

*Nota: En cualquiera de todos los casos, si hay problemas, bastaría con invocar el Administrador de tareas para crear el proceso de Explorer.exe, editar fácilmente el Registro de Windows para quitar o corregir la ruta en que haya quedado mal, cerrar sesión y volver a ingresar a probar.

Para cambiar de usuario, reiniciar o apagar, bastaría con presionar CTRL + ALT + Suprimir y seleccionar la opción que se busque.

¡Esto es todo!

Espero les pueda servir.

¡Feliz Navidad para todos!

Checho

La aplicación “DLTCAD 2010” que no corría en Windows 7, Process Monitor y su solución.

Checho — Thu, 17 Nov 2011 14:31:00 GMT

Hola a todos,

Realmente me da alegría volver a escribir por aquí después de algunos días, especialmente cuando tengo algo que me haya ayudado a mi aprendizaje y que quiero compartir.

En este caso, como en muchas ocasiones, se trata de un problema reportado con una aplicación llamada DLTCAD 2010 desde los estupendos Foros de Microsoft Answers en Español, me tomé el trabajo entonces de descargar un trial de la aplicación en cuestión y probar yo mismo, afortunádamente, también me dio un error y pude solucionarlo.

A continuación, como siempre divido en: El problema, La causa y su Solución.

El problema

Cuando se instala la aplicación en Windows 7, después de tratar de ejecutarla por primera vez, estaba recibiendo un Crash de la aplicación, es decir, que dejaba de responder sin ni siquiera haber iniciado:

“dlt2010D.exe dejó de funcionar”

Al intentar cerrar la aplicación, inmediátamente recibía un mensaje de error bastante extraño:

Estaba ocurriendo una Excepción y, según el mensaje, no se podía encontrar el archivo Config.tmp en la ruta de instalación: “C:\Program Files (x86)\DLTCAD2010 DEMO\”

Al aceptar el mensaje (OK), la aplicación no terminaba de iniciar. Sin importar cuántas veces la tratar de ejecutar, siempre era el mismo procedimiento, crash y posterior mensaje de error para finalmente cerrar el proceso y no abrir nada.

La causa

Lo primero que intenté hacer fue buscar el archivo Config.tmp pero por supuesto, no apareció por ningún lado, a juzgar por su extensión y nombre además, parecer ser algún tipo de archivo temporal que se ejecuta antes de iniciar la aplicación y que tal vez, pueda contener la configuración o los parámetros iniciales necesarios para que la aplicación arranque correctamente.

*Nota: Claro está, sólo estoy suponiendo porque la verdadera respuesta, la tiene sólo el fabricante implicado en el desarrollo.

En la compatibilidad de aplicaciones con Windows 7, suele ser práctico como primera instancia, intentar con dos alternativas, pestaña de compatibilidad que hará una “Mentira sobre la versión” haciéndole creer a la aplicación que está en una versión anterior de Windows o bien Ejecutarla como administrador elevando los permisos por el cambio en materia de seguridad que sufrió Windows desde XP a Windows 7 ya que todos los usuarios en Vista y 7 trabajan predeterminádamente como usuarios estándar.

Sin embargo, aplicando el modo de compatibilidad con Windows XP Service Pack 3 o inferior, de una vez el ejecutable pasa a pedir elevación de privilegios para que se cambie el token de acceso y sí se esté ejecutando realmente como un administrador (Tal cual se hacía en Windows XP).

Esto fue lo que hice con el ejecutable, fui a las propiedades (clic derecho, propiedades), pestaña de Compatibilidad y seleccioné Ejecutar este programa en modo de compatibilidad para Windows XP (Service Pack 3):

A continuación, ejecuté el programa, elevé los privilegios y de sorpresa, la aplicación estaba corriendo perfectamente:

Aquí había una gran incógnita, realmente la aplicación sí era compatible con Windows 7, pero pudo haberla hecho funcionar o la mentira sobre versión o la elevación de privilegios.

En un escenario emergente, ésta solución podría bastar, pero no en todas las empresas están dispuestas a dejar que se eleven permisos aunque sea para un proceso porque entonces tendrían que garantizar una cuenta que lo haga, además de que si la aplicación originalmente no pide elevación de privilegios es porque parece estar hecha con el fin de funcionar bajo un token estándar.

Cambié nuevamente el modo de compatibilidad a como estaba presentando el problema, y llamé a la mejor herramienta que me podía ayudar en ese momento, me refiero a Process Monitor de Sysinternals.

El proceso es el mismo de siempre, ejecutarlo, limpiar el primer log que genera, ponerlo a correr nuevamente y ejeacutar la aplicación hasta recibir el mensaje de error.

El siguiente paso es buscar qué puede darnos Process Monitor, de nuevo, como siempre, la recomendación es hacerlo de abajo hacia arriba y utilizando primero palabras que estén relacionadas con el problema, para este caso por supuesto, la primera sería: Config.tmp

Para activar el filtro de búsqueda, basta con ir al menú Edit y seleccionar Find, ejecutarlo desde la barra de comandos de Procmon o bien presionar CTRL + F

Para mi fortuna, bastó con los primeros y únicos resultados para encontrar tal vez la clave del problema:

Si vamos más a fondo, Windows está utilizando la función CreateFile para tratar de crear el archivo Config.tmp en la ruta: C:\Program Files (x86)\DLTCAD2010 DEMO\, pero como resultado está obteniendo un ACCESS DENIED; esto significa que la ruta existe, que se intenta hacer la operación pero que no se consiguen los permisos necesarios sobre la ubicación en este caso para escribir y que el archivo quede.

Lo interesante está en que en Windows XP, la aplicación funciona perfectamente, y si hago lo mismo con Process Monitor, veré que el trabajo con el archivo Config.tmp se comporta diferente:

Como ven, es exactamente la misma operación, pero esta vez con un resultado de SUCCESS, lo que difiere de que tuvo los permisos necesarios para escribir.

Esto es apenas lógico y es donde está la raíz del problema, los permisos NTFS cambian completamente junto con todo el esquema de seguridad como había comentado antes, la aplicación en Windows XP, tiene todos los privilegios para escribir sobre cualquier ruta porque la cuenta predeterminada es de Administrador. En Windows 7 por otro lado, aunque la cuenta esté dentro del grupo de administradores en modo de aprobación, desde que esté el Control de Cuentas de Usuario (UAC) activo, todo lo que se corra se hará bajo el mismo token que el Explorer.exe (Proceso padre), es decir, como si se estuviera corriendo sobre un usuario limitado.

Al yo elevar los permisos en la ejecución dentro de Windows 7, le está diciendo al proceso que cambie de token de usuario estándar a usuario administrador, por lo que los permisos pasarán hacer idénticos a como si se estuviera ejecutando en Windows XP, por eso sigue sin problemas.

La solución

Como el problema estaba en los permisos, es decir, acceso denegado para escribir en la carpeta DLTCAD2010 DEMO, tenía que revisar cómo estaban establecidos de forma predeterminada para el usuario actual, para esto, basta con ir al directorio implicado, hacer clic derecho, Propiedades, ir a la pestaña de Seguridad y hacer clic en el botón Editar:

En la edición de Seguridad sobre los permisos NTFS en Vista y en 7, se puede ver cada usuario implicado en los directorios o unidades que hayamos seleccionado, así como cada permiso que tienen sobre los objetos.

En este caso, me situé sobre mi usuario WinGuy del grupo Users (Usuarios) y esto fue lo que me mostró Windows:

Como ven, el permiso de Escritura (Write) no estaba seleccionado para Permitir (Allow), lo que quiere decir que mis usuarios estándar, no pueden crear nada en este directorio (DLTCAD2010 DEMO).

Hay una diferencia notable con respecto a los Administradores de la máquina:

Todos los permisos están habilitados, incluyendo los de escribir, ¡Aquí la clave de todo!
Esto resolvía el por qué elevando los privilegios que pasa de estar entre los Usuarios a los Administradores, la aplicación estaba funcionando bien.

Para finalizar entonces, sólo tuve que asignar el permiso de escritura sobre mi usuario y aplicar todos los cambios con sólo seleccionar el grupo de Users (Usuarios) y después habilitar Write (Escritura):

Por último y para confirmar la teoría, ejecuté la aplicación sin elevar los privilegios (Haciendo doble clic sobre el acceso directo) y .. ¡Aplicación funcionando!

Como hemos visto, no todos los problemas son culpa de Windows =)
Espero pueda ser de utilidad, sea por como en mi caso, aprender algo nuevo o bien porque tengan un problema similar con esta aplicación como es el caso que se planteó en los Foros y de donde surgió todo esto.

Saludos,

Checho

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

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

¡Hola a todos!

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

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

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

¿Qué hace el archivo de autorespuesta realmente?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

PsGetSid WinGuy2

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

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

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

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

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

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

Redirección de Perfil de Usuario manualmente

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

Método Online

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

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

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

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

En la consola de comandos, ejecutamos:

Net User Administrator /Active:Yes

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

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

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

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

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

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

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

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

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

Net User Administrator /Active:No

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

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

Método Offline

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

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

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

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

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

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

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

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

Saludos,

Checho

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

Checho — Tue, 25 Oct 2011 09:57:00 GMT

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

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

Método 2: Redirección manual de carpetas desde Windows

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

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

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

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

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

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

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

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

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

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

Creación de carpeta:

Copia de archivos:

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

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

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

Inside Folder Redirection (Part II)

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

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

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

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

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

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

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

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

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

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

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

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

Modificando los valores manualmente en el Registro

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

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

En el Editor de Registro navegamos hasta las siguientes ubicaciones:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders

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

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

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

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

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

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders

Aquí hacemos exáctamente la misma modificación, para mi caso de C:\Users\scalderon\Pictures a E:\Users\scalderon\pictures

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

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

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

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

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

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

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

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

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

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

Saludos,

Checho

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

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

Hola a todos,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Inside Folder Redirection…

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Saludos,

Checho

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

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

Hola a todos,

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

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

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

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

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

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

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

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

¿Qué necesitamos?

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

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

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

“Montando” la imagen…

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

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

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

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

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

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

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

Dism /Mount-Wim /WimFile:C:\7\Sources\install.wim /Index:1 /MountDir:C:\Mount

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

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

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

Sobre Registry Hives

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

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

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

La mayoría de los Hives están en el directorio %SystemDrive%\System32\Config, normalmente C:\Windows\System32\Config

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

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

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

Identificando la clave de Registro a modificar con Sysinternals

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer

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

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

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

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

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

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

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

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

Reg Load HKLM\Temp <RutaHive>

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

El comando para este artículo quedaría:

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

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

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

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

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

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer,

Se modificaría el registro para que quedara:

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

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

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

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

Desmontando Imagen…

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

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

En la Consola de comandos debemos ejecutar:

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

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

En mi caso el comando quedaría:

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

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

Preparando y probando…

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

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

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

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

Saludos,

Checho

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

Checho — Mon, 10 Oct 2011 12:11:00 GMT

¡Hola!

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

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

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

El problema

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

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

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

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

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

La causa

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

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

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

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

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

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

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

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

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

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

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

La primera operación que referencio está abriendo en la clave de Registro ProfileList una subclave que hace referencia a un SID (Identificador único) en:
HKLM\Software\Microsoft\Windows NT\CurrentVersion

La clave completa es:
HKLM\Software\Microsoft\Windows NT\CurrentVersion\ProfileList\S-1-5-21-817817061-500146855-1629396408-1003

*Nota: Recordemos que HKLM hace referencia a HKEY_LOCAL_MACHINE.

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

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

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

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

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

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

C:\Users\TEMP.WIN-07Q5QALI9TH.008

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

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

Esta fue mi sorpresa cuando decidí ver su contenido:

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

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

¿Por qué dos cuentas con el mismo SID?

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

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

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

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

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

Mi carpeta no se estaba creando cuando cargaba Windows.

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

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

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

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

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

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

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

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

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

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

La esperada Solución

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

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

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

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\S-1-5-21-817817061-500146855-1629396408-1003

*Nota: El SID pueden saberlo viendo algun proceso con Process Monitor en la pestaña Seguridad, aunque también pueden ir hasta la ubicación HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\

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

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

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

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

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

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

¡Problema solucionado!

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

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

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

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

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

Saludos,

Checho

El error: “No se tiene acceso al servicio de Windows Installer…”; Process Monitor, WinDiff y su solución.

Checho — Sat, 03 Sep 2011 20:19:00 GMT

¡Hola nuevamente!

Quisiera contar como un Off-topic que estoy muy contento con las últimas máquinas virtuales con las que he tratado de trabajar porque me han dado la oportunidad de darme un poco más de aprendizaje que he tratado de compartir aquí.

A continuación detallaré otro problema que no es demasiado común pero suele pasarle a varias personas, como siempre seguiré la línea de: El problema, la causa y su solución.

*Nota: Para los que tengan el inconveniente y no deseen ver el desarrollo de todo el artículo para solventarlo pueden ir directamente a “La solución” en la última parte del artículo y seguir los pasos.

El problema

El error empezó cuando estaba tratando de instalar un paquete .MSI (Windows Installer) del Cliente de Windows Intune en una de las máquinas para que fuera reconocido por la Consola de administración (Espero pronto tratar algunos temas de estos).

Cuando le di doble clic para iniciar la instalación, obtenía este mensaje de error:

“No se tiene acceso al servicio de Windows Installer. Esto puede suceder si Windows Installer no está correctamente instalado. Póngase en contacto con el personal de soporte técnico para obtener ayuda”.

En Inglés, el mensaje sería similar al siguiente:

“The Windows Installer Service could not be accessed. This can occur if the Windows Installer is not correctly installed. Contact your support personnel for assistance”.

*Nota: El mensaje de error puede variar con algun código de error incluido, pero suelen referirse a lo mismo.

No tenía idea a qué se podría deber este problema porque ni en física ni en virtual acostumbro a instalar aplicaciones de mantenimiento que suelen ser las primeras causantes de estos inconvenientes pero como había utilizado tanto la máquina en los anteriores contenidos, probáblemente “algo” había hecho. Aunque algo había visto del problema en los Foros, quería aprovechar la oportunidad para tratar de investigarlo y solucionarlo, por supuesto, había que hacer uso de la única herramienta que puede dar una completa visión de lo que esté pasando: Process Monitor de Sysinternals.

La causa

Procedí entonces a reproducir el mensaje de error mientras tenía Procmon activo, así cualquier actividad que sucediera mientras me entregaba el mensaje la podría rastrear.

Después de reproducirlo, paré Process Monitor y empecé a buscar algo que me ayudara a identificar la causa del problema pero tuve una gran mala suerte y es que no aparecía nada relacionado con operaciones faltantes o que tuvieran acceso denegado como normalmente lo hace. Lo segundo fue entonces comparar el error y el primer pantallazo que debía salir en un equipo funcional pero de nuevo, nada anormal y de hecho, todas las operaciones relacionadas con Windows Installer las estaban cumpliendo los dos equipos con resultados satisfactorios.

Antes de seguir con Process Monitor, pensé que podría entonces estar el problema relacionado con el servicio propio de Windows Installer, así que abrí la Consola de Servicios en el PC que presentaba el error, pero al buscar Windows Installer me sorprendí con que el Servicio no estaba:

Revisé en uno de los equipos funcionales y en efecto, el Servicio debía estar disponible:

El Servicio probáblemente entonces no estaba registrado (No sabía cómo se le había perdido), aquí el hecho que al intentar instalar algun paquete no pudiera acceder a éste. Debía encontrar era como volverlo a su funcionalidad.

Volví a Process Monitor y pensé que quizá al correr el paquete en el equipo que corría correctamente, Process Monitor podría darme un poco más de información o por lo menos alguna pista útil.

Empecé parte de la instalación, abrí Procmon y busqué esta vez por el nombre interno del servicio (msiserver) y esta vez, el primer resultado fue la pista contundente:

Windows estaba haciendo uso de la función RegOpenKey para abrir la clave:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\services\msiserver

Después de esto empezaba a realizar consultas a varios de sus valores, unos con buen resultado y otros no tanto, pero como era en el equipo funcional era totalmente normal. Por último cerraba completamente la clave que había abierto (msiserver).

Bajo esta clave están alojados todos los Servicios de Windows, como éste de Windows Installer está establecido a manual, probáblemente estas operaciones incluían la inicialización y su respectivo trabajo, el problema era que bajo la Consola de servicios del equipo con el error no aparecía el Servicio, al no aparecer no podía hacer la consulta, al no poder hacer la consulta no podía proceder con la instalación y era cuando da el molesto mensaje.

Ahora, como estos son claves y valores de Registro, debía ver qué sucedía en el equipo con el problema, procedí entonces a abrir el Editor de Registro, navegué esta la clave y me encontré con esto:

Habían algunos valores pero en ninguna parte hacía referencia al Servicio de Windows Installer (msiserver), abrí la misma clave en el equipo funcional y esta fue la grata sorpresa:

A parte del valor ImagePath que referencia la ruta del Servicio, era obvio que en el equipo que presentaba el problema hacían falta varios valores más, por ahí podría estar el problema.

Comparando con WinDiff

Leyendo el fantástico libro de Sysinternals Administrator’s Reference de Mark Russinovich y Aaaron Margosis; entre uno de los problemas que precísamente había documentado aquí hace ya algun tiempo sugerían utilizar WinDiff cuando se tratara de hacer comparación de archivos.

WinDiff, es una herramienta incluida en el SDK de Windows, entre todos los tipos de archivo plano que permite comparar, se encuentran los de Registros de Windows.

Aproveché esta gran característica, además de que tenía WinDiff instalado, así que exporté las dos claves de Registro, tanto del equipo funcional como del no funcional, abrí WinDiff fui al menú File y seleccioné Compare files…

Lo siguiente es abrir los dos ficheros a comparar y en unos segundos, WinDiff entregará un resultado preciso de la diferencia entre lo que hayamos puesto a comparar. Para este caso, el resultado fue el siguiente:

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

Normalmente, WinDiff diferencia el contenido de los dos archivos asignándoles un color, por lo general Rojo y Amarillo, o bien Rojo y negro, entre otros.

Cuando sólo aparece un sólo color, y el signo de <! , indica que cada una de esas lineas difiere del archivo contra el que se está comparando

Para este caso, ya podía estar seguro de que hacía falta los valores: ImagePath, ObjectName, Start, Type, ServiceSidType y RequiredPrivileges.

Esto por supuesto, abría de nuevo la esperanza de solucionar el problema.

La solución

Ya sabía la causa, y como en la mayoría de las ocasiones, probáblemente el volver a importar estos valores o bien a crearlos me podría solventar el problema.

Lo que hice sin embargo, fue exportar toda la clave de:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\msiserver

A continuación, la pasé al equipo que presentaba los problemas, la ejecuté, la importé y como el error persistía, procedí a reiniciar el equipo.

Después del reinicio, intenté ejecutar el paquete de instalación y ¡Problema solucionado! Bastaba con reiniciar para que el Servicio se volviera a registrar e hiciera el trabajo que le correspondía al momento de su llamado.

La razón por la que detallara tan rápido la solución es que aproveché este inconveniente también para automatizar el proceso.

Para las personas que vean este artículo entonces y tengan este mismo problema, les dejo dos alternativas:

Solución automática: Presentando FixMSI

FixMSI, es una pequeña aplicación que he desarrollado utilizando la API de Windows, utiliza las función RegKeyCreateKeyEx para crear el valor de msiserver en la ubicación correspondiente y luego hace uso de la función RegSetValueEx para establecer todos los valores correspondientes y que requiere el Servicio de Windows Installer para funcionar.

Por último, FixMSI reinicia el equipo para que todos los cambios surtan efecto y que cualquier paquete (.MSI) se pueda instalar sin obtener el error.

Este proceso es totalmente transparente para el que ejecute FixMSI, sólo se verá la pantalla de confirmación y la de posterior aviso de reinicio:

*Nota: FixMSI incluye un manifiesto para solicitar la elevación de permisos si está activo el Control de Cuentas de Usuario (UAC).

Pueden descargar FixMSI desde aquí:

Solución manual: Importando Registro

El método anterior es el que personalmente recomiendo porque como ven, es sólo aceptar el mensaje y la aplicación hará el resto de una forma rápida y segura.

Si no llega a funcionar, pueden bajar e importar el archivo de Registro original del Servicio de Windows Installer desde aquí:

Después de esto, reinician manualmente y deberían poder realizar las instalaciones sin problemas.

Espero que esto les pueda servir de ayuda.

Los que prueben FixMSI, les agradecería que me entregaran el feedback comentando en este post para saber si efectivamente les solucionó este problema.

¡Muchas gracias!

Saludos,

Checho

El controlador de Process Monitor que causaba un remitente Pantallazo Azul; Windows PE, Autoruns y su solución.

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

Hola a todos,

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

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

El problema

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

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

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

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

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

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

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

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

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

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

La posible causa

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

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

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

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

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

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

¿A qué se debía?

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

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

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

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

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

La solución

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

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

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

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

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

Construyendo el medio Windows PE + Autoruns

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

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

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

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

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

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

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

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

La carpeta ISO debería verse así:

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

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

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

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

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

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

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

Para mi caso, el comando sería:

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

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

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

Volviendo al caso…

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Saludos,

Checho

Establecer inicio automático de cuenta de usuario (Autologon) en Windows 7

Checho — Wed, 31 Aug 2011 06:45:00 GMT

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:
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\AutoAdminLogon

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:
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\DefaultUserName

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:
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon

*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_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon]
"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

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

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

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

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

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

Explorando Windows…

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Explorando las Políticas…

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

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

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

Configuraciones de usuario\Plantillas administrativas\Escritorio\Active Desktop

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

En el Editor de Registro navegamos hasta la siguiente clave:

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

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

El nombre de la clave debe ser System

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

El nombre que le debemos indicar es: Wallpaper

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

Debe verse similar a la siguiente captura:

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

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

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

El resultado final debe ser similar al siguiente:

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

Reg unload HKLM\Default

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

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

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

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

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

Navegamos hasta la clave:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies

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

La clave debe llamarse igualmente System.

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

Realizamos el paso nuevamente y llamamos a la nueva clave WallpaperStyle

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

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

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

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

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

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

Saludos,

Checho

[Tip] Agregar información de soporte y logo personalizado en las Propiedades del Sistema en Windows 7

Checho — Mon, 15 Aug 2011 11:45:00 GMT

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 120x120 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 HKLM\Software\Microsoft\Windows\CurrentVersion\OEMInformation 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_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\OEMInformation
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

El archivo (.pps) de Office 2007 y 2010 que no mostraba campos dentro de las Propiedades en Windows 7, Process Monitor y su solución.

Checho — Thu, 07 Jul 2011 12:28:00 GMT

Hola a todos,

Hace unos días, en los espectaculares Foros de Microsoft TechNet, específicamente en el Foro de Windows 7 , un usuario abrió un hilo con un aparente problema que resultó siendo (Por lo menos para mí) un caso sumamente interesante a pesar de que no representaba un fallo en el funcionamiento de Windows como suele suceder normalmente pero que, como con casi todos entrega una gran cantidad de conocimiento al intentar resolverlo.

A continuación, quiero compartirles como siempre en varios items (El problema, la causa y la posible solución) todo este caso con el fin de ver qué tanto nos puede ayudar Sysinternals cuando todo lo demás parece haberse agotado.

El problema

El inconveniente se presenta cuando trabajamos con Office 2007 u Office 2010, específicamente cuando guardamos una presentación de PowerPoint en formato .pps (Para Office 97 y 2003). Cuando queremos acceder a las Propiedades del archivo, pestaña Detalles veremos que no se puede agregar o editar campos adicionales como el Título y el Asunto entre otros, sólo nos permite visualizar unas propiedades estándar del mismo:

¿Cuál es el problema? Que si este mismo archivo se guarda con el formato predeterminado para Office 2007 y 2010 (.ppsx) podremos ver todos los campos que especifican los detalles del archivo en cuestión y además se podrán editar:

Esto solo pasa (Y estaba pasando) con este tipo de extensión (.pps) que es la que maneja predeterminadamente PowerPoint 2003 pero que utilizan las versiones superiores para mantener esta misma compatibilidad con versiones inferiores.

Sin embargo, no pasa lo mismo con las demás extensiones que maneja PowerPoint. Esto por supuesto para muchas personas les puede parecer algo a lo que no haya que prestar mucha atención porque quizás ni lo utilicen pero para el usuario en cuestión y para una gran cantidad de personas que hacen uso de estas características puede llegar a convertirse en algo muy importante porque no hay razón (Aparente por lo menos) para que no siga comportándose igual.

La causa

En este tipo de casos, cuando no es un error que uno pueda investigar pero que tiene un punto de comparación, resulta mejor tratar de entender cómo se comporta Windows cuando cuando no hay nada “extraño”. Para el caso, tenía que entender qué es lo que estaba ocurriendo cuando se quería visualizar los Detalles de la presentación en las Propiedades del archivo con formato de Office 2007 y 2010, es decir con extensión (.ppsx) que era cuando presentaba todos los campos correctamente.

Después de esto, como comenté antes, debía revisar este mismo proceso abriendo el archivo con extensión (.pps) que corresponde a Office 97 y 2003 y ver cuál era la diferencia para intentar llegar a la causa.

Para intentar entender esto por supuesto, no hay otra herramienta que nos pueda ayudar mejor que la que se debe utilizar cuando todo lo demás está perdido, Process Monitor de Sysinternals.

Lo que hice fue correr Process Monitor sin aplicar ningun filtro puesto que no sabía qué proceso sería el correcto a seguir (el de PowerPoint o Explorer); después abrí las Propiedades del archivo con el formato (.ppsx) de Office 2007 y 2010 haciendo clic derecho sobre el mismo, Propiedades y pestaña Detalles. Por último abrí nuevamente Process Monitor y terminé el monitoreo con CTRL + E o bien en el menú File, Capture Events…

Como tampoco sabía por dónde empezar a buscar (Casi siempre es así), resulta una buena práctica iniciar desde abajo hacia arriba que es donde muestra los últimos eventos y que realmente son los importantes, sin embargo también me ha resultado muy útil hacer en primera búsquedas que contengan palabras relacionadas con el problema.

En este caso como estaba accediendo a los Detalles y observando los campos que más interesaban como el título, lo que hice fue abrir el cuadro de búsqueda de Process Monitor presionando CTRL + F (También se puede en el menú Edit, opción Find), a continuación le indiqué el parámetro de búsqueda que fue “Title” (Es conveniente poner los nombres en Inglés) e indicándole que la dirección fuera hacia arriba seleccionando “Up” debajo de “Direction” y finalmente clic en el botón Find Next:

El resultado fue bastante satisfactorio, pues Process Monitor me arrojó una serie de eventos en donde estaba la clave de lo que buscaba:

Lo que hice fue tratar de entender lo que ocurría en esta serie de eventos de arriba hacia abajo para determinar la causa, a continuación lo detallo un poco algunos de los resultados más importantes:

Internamente, Windows o cualquier aplicación desarrollada que utilice su API para trabajar con el Registro utiliza una serie de Funciones predefinidas para hacer sus operaciones; es primordial que siempre que se abra el Registro, igualmente se cierre para finalizar el proceso que se acabó de hacer.

En este caso, Windows está utilizando la función RegOpenKey para abrir la clave asociada a la extensión .ppsx de Office 2007 y 2010 (HKCR\SystemFileAssociations\.ppsx), como resultado fue SUCCESS (Exitoso), utiliza la función RegQueryKey para poder consultar las respectivas claves (Ver el primer y segundo evento de la captura), como también entrega resultado de SUCCESS (Exitoso) indica que la clave principal está creada pero además puede hacer uso de sus subclaves que también se encuentran.

Debemos notar que todo esto lo está haciendo bajo la rama de Registro de HKCR (HKEY_CLASSES_ROOT) que es donde Windows consulta para la asociación de todo tipo de archivos y extensiones globalmente. Normalmente además siempre tiene mayor prioridad lo que esté en HKEY_CURRENT_USER (HKCU) que es por usuario pero para este caso al intentar abrir la respectiva clave (HKCU\Software\Classes\SystemFileAssociations\.ppsx) el resultado fue NAME NOT FOUND que indica que la clave no está creada o no se encuentra, volvió a consultar en la que estaba en HKCR para proceder a las operaciones posteriores.

Ahora, después de saber que debía utilizar las claves bajo la rama de HKCR, vemos que Windows utilizó la función de RegQueryValue para hacer la consulta de un Valor de Registro, específicamente el de FullDetails con un resultado de SUCCESS (HKCR\SystemFileAssociations\.ppsx\FullDetails).

Aquí es donde me paré a observar qué tenía este Valor que es el que había consultado, sobre todo por el nombre que hacía referencia a todos los Detalles, para esto hice clic derecho sobre la clave y seleccioné Jump To para que Process Monitor me llevara directamente al valor en el Registro de Windows:

Al entrar a editar el Valor que era una Cadena, me encontré con otro resultado bastante satisfactorio:

Básicamente estaba haciendo llamado a unas especies de clases que contenían sus propios métodos: System.PropGroup.Description que me mostraba el nodo de Descripción en la pestaña Detalles dentro de las Propiedades del archivo, System.Title y System.Subject entre otros que me mostraban todos los campos que normalmente podía ver y editar.

*Nota: Para comprobarlo, se puede quitar alguno de estos y al abrir nuevamente las Propiedades del archivo .ppsx ya no se visualizará el que se haya removido del valor de registro.

En resumen entonces, había podido descubrir y aprender que al abrir las Propiedades del archivo .ppsx Windows abría la clave HKEY_CLASSES_ROOT\SystemFileAssociations y utilizaba el valor de FullDetails para mostrar todos los campos correspondientes en las propiedades dentro la pestaña de Detalles.

Con esto ya tenía una base de cómo funcionaba con el formato de Office 2007 y 2010, lo que quedaba era revisar cuál era el comportamiento con el formato para Office 97 y 2003 (.pps).

Lo que hice entonces fue guardar el log actual del Process Monitor para comparar, limpiarlo presionando las teclas CTRL + X, activar otra vez el monitoreo preisonando CTRL + E y reproduciendo el “problema” que era ir a las propiedades, pestaña Detalles pero del archivo con formato (.pps) que era el que no mostraba todo.

Volví nuevamente al Process Monitor, detuve el monitoreo y ¡Empecé a buscar!

Desafortunadamente, en este no era tan sencillo buscar porque por ejemplo el campo Título no aparecía por lo que el log me arrojaría que no encontraba resultados con esto, afortunadamente teniendo en cuenta el anterior log que había capturado busqué por el mismo valor que representaba todos los detalles, es decir: FullDetails para saber qué resultados obtenía, y encontré esto:

Básicamente, el valor de FullDetails lo estaba obteniendo de la clave HKEY_CLASSES_ROOT\* con un resultado exitoso (SUCCESS), decidí entonces ir de nuevo hasta el valor desde Process Monitor y consultar qué había en su interior:

Si detallamos, los métodos que trae esta clave hacen referencia a los que se muestran en las propiedades del archivo como el Nombre para mostrar, el tipo de archivo, el nombre del equipo, etc.

Como la consulta no la hacía en la extensión específica de (.pps) deduje entonces que el (*) de la rama de Registro se refería a los atributos predeterminados que mostraba para todos los archivos en su pestaña de Detalles por lo que si nuestro archivo lo estaba tomando de aquí se refería a que no existía en los Valores de su extensión.

Ya creía saber porque no aparecían todos los detalles al igual que en el formato de 2007 y 2010, lo que no sabía era por qué razón no se comportaba igual que en el equivalente en su extensión superior, por lo que seguí buscando y finalmente encontré lo que estaba buscando:

Como ven, en esta traza me mostraba que también estaba intentando abrir la clave de HKCR\SystemFileAssociations\.pps pero el resultado era NAME NOT FOUND lo que indicaba que la clave no existía, si no existía tampoco iba a poder consultar el Valor de FullDetails por lo que obviamente no se mostraría todo en la pestaña Detalles de las Propiedades del archivo en cuestión así que tendría que buscar en otra clave diferente.

*Nota: Recordemos que HKCR son las siglas abreviadas que utiliza Process Monitor para referirse a la rama de registro de HKEY_CLASSES_ROOT, así mismo con las demás ramas.

Pensé que si Windows consultaba la clave, podría crearse y lograr emular el mismo comportamiento que con los archivos con formato de Office 2007 y 2010.

Como no sabía qué valores y claves debía tener, exporté la clave de la extensión (.ppsx) desde el Registro de Windows y posteriormente modifiqué la extensión de .ppsx a .pps para que cuando se volvier a importar creara esta clave tal cual estaba la de (.ppsx):

Al ejecutar la clave de Registro y asegurarme de que quedara creada, volví a abrir las Propiedades del archivo (.pps) en la pestaña Detalles vi que aparentemente había funcionado ya que podía ver todo lo que faltaba:

En un primer vistazo, pensé que el problema se podría dar por solucionado con esta clave de registro creada, para mi mala fortuna, a parte de que no mostraba lo que contenían los atributos, tampoco dejaba editarlos, es decir, sólo podía visualizar los nombres de todos los campos que se deberían poder modificar más no lo podía hacer. El problema continuaba aunque ya tenía un primer avance y era que definitivamente debía existir esta clave para que se pudieran visualizar los detalles completos, ahora tenía que encontrar cómo los podría ver y modificar.

El haber creado y probado esta clave me aseguraba de que la característica de edición no se encontraba aquí por lo que tuve que volver a Process Monitor y ver qué más había en común en las llamadas que se hacían.

Investigando un poco más en la traza para ambas extensiones encontré otra llamada que se completaba a una clave de registro cerca de los eventos ya mencionados:

En el archivo con extensión (.ppsx) de Office 2007 y 2010:

En el archivo con extensión (.pps) con compabilitdad para Office 97 y 2003:

Ambos estaban utilizando la clave de su extensión ubicada en la raíz de la rama de HKEY_CLASSES_ROOT, como el resultado era SUCCESS (Exitoso) me indicaba que de “algo” estaban haciendo uso, para saber de qué, abrí las dos claves de registro, las exporté a un archivo .REG y pude comparar un poco las diferencias (A parte de su extensión como tal puesto que esta vez si existían en el Registro):

Archivo de Registro para la extensión (.ppsx):

Archivo de Registro para la extensión (.pps):

Como ven, a parte de la extensión y del número para el SlideShow que le correspondía a cada uno (12 para Office 2010 y 8 para Office 2003) las diferencias eran menores pero al parecer bastante notorias puesto que la extensión (.ppsx) tenía algunos valores y Claves adicionales en la raíz y en ShellEx que no tenía la clave de registro de la extensión (.pps).

La esperada Solución o Workaround

Algunas veces, hay que probar y arriesgarse a dañar para poder aprender o lograr salir de este tipo de inconvenientes, decidí modificar la clave de la extensión (.pps) para que tuviera el mismo comportamiento que la que funcionaba (Extensión .ppsx), para esto agregué entonces las claves y valores que le hacían falta para que quedara idéntica.

A continuación entonces, detallo el proceso detallado para dejar el comportamiento de los formatos (.pps) iguales a los de los formatos (.ppsx) y que se puedan ver y editar los Detalles en las propiedades:

*Nota: Antes que nada, aconsejo hacer respaldo de las claves de registro que se vayan a modificar para tener cómo volverlas a su estado original por si hay problemas, además en primera hacerlo en un ambiente controlado.

1. Creamos la Clave de registro para que los detalles aparezcan completos en el formato de (.pps), para esto descargamos el siguiente fichero de registro, se debe descomprimir e importar asegurándonos que finalice correctamente:

*Descargar el archivo CreatePPSAssociation

2. A continuación modificamos la clave de Registro ubicada en la raíz de la rama de HKEY_CLASSES_ROOT\.pps, para asemejarlo al de la extensión (.ppsx) ubicada en HKEY_CLASSES_ROOT\.ppsx. Les dejo también la descarga del Fichero de registro que se debe descomprimir y ejecutar, luego asegurarse de que haya importado correctamente:

*Descargar el archivo ppsModificado

3. Reiniciamos o Cerramos sesión en el sistema para que los cambios efectuados en ShellEx se puedan visualizar y se puedan editar los campos en la pestaña de Detalles.

*Nota: Si no se reinicia o se cierra sesión, seguiremos viendo los detalles faltantes pero no se podrán modificar todavía, es primordial que se haga el tercer punto.

4. Accedemos a las propiedades del archivo con formato (.pps), pestaña Detalles y veremos que ya se comporta tal cual lo hace con los formatos posteriores (.ppsx), es decir, ya se puede ver todo bien y finalmente editar:

Espero que si hay alguien que desee que se le comporte así le ayude este artículo, para las demás el mensaje que quiero dar es que veamos todo lo que se puede aprender con un problema que parece no tener mucha importancia y cuánta ayuda nos brinda el fantástico Process Monitor.

*Nota final: Ignoro si el comportamiento es normal por temas de compatibilidad o seguridad pero es algo que en cuanto pueda, trataré de investigar ya que mis pocos conocimientos hasta ahora no me dan para entenderlo.

¡Cualquier comentario o corrección es bienvenido!

Saludos,

Checho

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

Checho — Sat, 18 Jun 2011 14:25:00 GMT

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

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:

“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: HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.lnk\UserChoice

Equipo Funcional:

Equipo NO Funcional:

Como ven, en el Equipo funcional trata de abrir la clave de registro HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.lnk\UserChoice, 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:

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:

- En el Registro de Windows, navegar hasta la clave:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.lnk

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

- 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?

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_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.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

*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_USER\Demo]

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_USER\Demo]

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_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.lnk\UserChoice]

[-HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.exe\UserChoice]

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:

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

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:

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

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:

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:

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:

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_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.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_USERS\S-1-5-21-1231788061-2787996694-3405420119-1006\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.lnk

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:

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:\Users\Administrador\Desktop” donde “Administrador” es el nombre de usuario de la cuenta que iniciaron sesión y ENTER:

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:\Windows\Regedit.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 Administrador\Demo –p demopass –h –I C:\Windows\Regedit.exe

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

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

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_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts

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