Checho's Blog

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

2012-02-03T12:20:00Z

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

2012-02-02T13:41:00Z

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.

2012-01-26T10:45:00Z

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

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

2012-01-17T15:24:00Z

Hola a todos,

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

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

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

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

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

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

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

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

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

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

¿Qué necesitamos?

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

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

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

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

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

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

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

¡Empecemos!

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

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

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

Normalmente, sería el de x86.

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

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

xcopy V:\USMT\x86 C:\USMT

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

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

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

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

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

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

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

Recuperando perfil y archivos de usuario

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

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

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

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

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

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

En mi caso, el comando sería:

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

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

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

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

Espero les pueda ser de utilidad.

Saludos,

Checho

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

2012-01-05T17:35:00Z

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

2012-01-04T15:09:00Z

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

2011-12-28T20:15:00Z

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.

2011-12-18T22:38:00Z

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

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

2011-12-04T22:09:00Z

¡Hola a todos!

Ya hemos tocado en cuatro artículos anteriores (sin incluir los de solución de problemas) gran parte de lo que componen los Perfiles de usuario en Windows 7. Sin embargo, se siguen presentando nuevos requerimientos y por supuesto, Windows también entrega diferentes métodos para poder suplirlos en su mayoría.

Uno de los requerimientos o necesidades más importantes al tocar el tema de los perfiles en las diferentes organizaciones es determinar qué se hará con el perfil, ¿Se guardará, o no? ¿Se hará localmente, o no? ¿Se moverá todo el perfil?

Cada organización responde a estas preguntas de acuerdo a cómo desee que quede su infraestructura, la mayoría optan por manejar particionamiento en el equipo y redirigir cada nuevo perfil de usuario creado allí, así, no habrá peligro de perderse aún después de un formateo completo del sistema operativo.

Existe, a pesar de todo, un procedimiento adicional llamado Roaming Profiles (Perfiles Móviles), acorde a la nueva forma de ver el concepto de escritorio por parte de Microsoft llamado Escritorio flexible. Básicamente, Roaming Profiles (Perfiles móviles) nos permitirá centralizar todos los perfiles deseados en un solo repositorio central, dándole la posibilidad a cada usuario del Directorio Activo de iniciar sesión en cualquier máquina y disponer tanto de su propio perfil, como de todos sus documentos y configuraciones adicionales.

Lo que haremos en este artículo será configurar los Perfiles Móviles (Roaming Profiles) para Windows 7.

¿Qué necesitamos?

- Una infraestructura de Directorio Activo montada en Server 2008 R2.

- Una carpeta compartida donde se almacenarán los perfiles (En el artículo mostraré lo que se debe tener en cuenta a la hora de compartir el recurso).

*Nota: Esta característica es soportada desde Server 2003 y XP pero nos enfocaremos sólo a lo que concierne Windows 7 y 2008 R2.

- Equipo( S ) Windows 7 conectados al dominio y en la misma red.

Creando el recurso compartido

Antes de configurar los Perfiles Móviles, debemos tener un directorio donde se alojarán todos, para este caso, yo creé una carpeta en el Servidor dentro de la unidad raíz C:\ con el nombre de “Perfiles”, por lo que quedaría como C:\Perfiles.

*Nota: El nombre de la carpeta lo especifico para seguir el artículo, por supuesto, cada uno de ustedes puede crearla en otra ubicación y con otro nombre.

Después de crear la carpeta, hay que configurar los permisos para que cada usuario que inicie sesión en el dominio y se le especifique el Perfil Móvil, pueda escribir en esta carpeta todos sus archivos correspondientes de usuario.

Para esto, hacemos clic derecho sobre la carpeta, seleccionamos Propiedades, en la ventana de Propiedades, vamos a la pestaña de Compartir (Sharing), clic en el botón Opciones avanzadas (Advanced Sharing), seleccionamos la casilla de “Compartir esta carpeta” (Share this folder), cambiamos el nombre compartido si deseamos y clic en el botón de Permisos (Permissions):

En la ventana de Seleccionar Usuarios, Equipos, Cuentas de Servicio, o Grupos, clic en el botón Agregar (Add) digitamos o buscamos los Usuarios Autenticados (Authenticated Users) y clic en el botón Aceptar (OK):

En la Ventana de Permisos, seleccionamos Usuarios Autenticados (Authenticated Users) y le asignamos el Control total seleccionando la casilla de la parte inferior, Aplicamos y Aceptamos:

*Nota: Estamos seleccionando los Usuarios Autenticados, porque aquí estarán sólo los que vayan iniciando sesión en el Dominio, así además podremos asegurarnos de que cada usuario que inicie sesión, tendrá su propia propiedad sobre su carpeta correspondiente de Perfil.

Clic en Aceptar en la ventana de Opciones avanzadas y en la de Propiedades de la carpeta compartida. Debemos por supuesto, tener la referencia de la carpeta que acabamos de compartir, en mi caso quedó \\SWATLAB\Perfiles

*Nota: En la ventana de Propiedades, pestaña Compartir (Sharing) se puede ver la ruta de red las veces que deseen.

Preparando el usuario

Con la carpeta compartida ya creada, en el Servidor de Dominio, abrimos la consola de Usuarios y Equipos del Directorio Activo, ubicamos el usuario que deseamos que tenga el Perfil móvil, clic derecho, Propiedades y vamos a la pestaña de Profile (Perfil).

En la pestaña de Profile (Perfil), tendremos dos nodos correspondientes a Perfil de usuario y Carpeta de hogar; el primer nodo, debemos ubicarnos en la caja de texto de Ruta de Perfil (Profile Path) y aquí debemos pegar o copiar exactamente la ruta compartida de red, pero, adicional a esto, para que cada usuario quede con un nombre de carpeta que se refiera por el nombre de dominio, agregamos la variable de entorno %USERNAME% al final de la ruta de red, así el Directorio activo sabrá a qué usuario se refiere y le creará su respectiva carpeta.

En mi caso, la ruta completa sería \\SWATLAB\Perfiles\%USERNAME%

Aplicamos y aceptamos en la ventana de Propiedades del usuario correspondiente.

*Nota: La ruta, para cada uno de ustedes segúramente variará, es importante escribirla bien porque de lo contrario, habrán problemas con el inicio de sesión del Perfil.

Esto es todo lo que tenemos que hacer, el siguiente paso será asegurarnos de que en verdad nuestro perfil ahora es móvil y no tuvo ningun problema para configurarse.

Probando nuestros Perfiles Móviles

Para este artículo, configuré en una máquina el perfil de mi usuario scalderon (Sergio Calderon), básicamente, con algunos archivos en el escritorio, y personalizaciones adicionales del menú de inicio, fondo de pantalla, imagen para mostrar y tema:

Como el usuario ya había iniciado sesión en el Equipo antes de configurarse el Roaming Profile (Perfil Móvil), se debe Cerrar completamente la sesión y volver a ingresar para que en el Servidor se creen las carpetas y archivos correspondientes del perfil que incluyen toda su información y personalizaciones – Tal cual una carpeta de perfil local-

*Nota: La carpeta correspondiente se crea en el primer inicio de sesión después de configurarse el Perfil Móvil (Roaming Profile), por esto el cierre de sesión; además, la finalización del nombre de la carpeta con “.V2” es porque Windows Server reconoce entre los perfiles que se creen para Windows XP y Server 2003, y los que se creen para Windows Vista, 7, Server 2008 y 2008 R2 , es decir “.V2”. La razón es porque tanto los archivos como las carpetas de usuario cambiaron de gran forma entre estas versiones de Windows no sólo en su contenido y número sino también en su ubicación.

Una vez iniciados sesión después de configurado el Perfil en el DA (Directorio Activo), procedemos a crear o guardar información, y realizar las personalizaciones que se deseen tal cual trabaja normalmente cada usuario en su equipo y perfil. Una vez cerrada la sesión por primera vez después de configurarse el Perfil Móvil (Roaming Profile) y por cada inicio de aquí en adelante, se copiarán todos los archivos a la carpeta de usuario destinada en el Servidor:

El hacerlo en cada cierre de sesión (Que incluye al apagarse y al reiniciarse por supuesto), garantiza que toda la información y cambios generados durante el tiempo de trabajo se guarden y así, el usuario podrá tenerlos en el próximo inicio de sesión, no solo en el equipo donde se creó todo, sino en cualquier nuevo equipo que esté en la misma red y que se haga con la cuenta de dominio.

Por ejemplo, para este artículo, inicié sesión en otro Equipo con Windows 7 x64 y además Internet Explorer 9 (Nótese que el anterior estaba en IE8) y este fue el resultado:

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

Un poco más de información…

Existe, por supuesto, el caso de que el usuario no esté en la red interna y haya hecho una serie de modificaciones al tema de Windows por ejemplo, y agregado algunos archivos nuevos:

Pero, como no se encuentra en la misma red, el perfil no se guardará al cerrar sesión ya que no hay comunicación con el Servidor donde está el almacenamiento, incluso Windows mismo nos advertirá:

En este caso, Windows seguirá trabajando con la configuración e información más actual que tenga en el Servidor de almacenamiento, actualizando así el perfil local que haya en la máquina conectada al dominio, sin embargo, cuando la máquina en la que se hizo la configuración por fuera de la red se vuelva a conectar al dominio con la cuenta implicada, al primer cierre de sesión, se actualizará nuevamente el perfil de red con toda información y configuración que se haya creado tanto en los equipos locales en los que se haya iniciado sesión, como con la que trajo la máquina que estaba por fuera.

En este orden de ideas, la próxima vez que se inicie sesión en la red de dominio, habrá un solo perfil con todas las configuraciones combinadas:

Con esto, nunca habrá preocupación por la cantidad de perfiles asociados a una misma cuenta, sólo la tranquilidad de mantener siempre una =)

*Importante: Dado que Windows divide en versión 1 y versión 2 el Perfil si se creó en Versiones anteriores como XP o Server 2003, sería la unica forma en la que serán dos perfiles diferentes, uno que se maneje en las máquinas de XP y 2003 y otras en las de versiones posteriores de Windows.

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

Saludos,

Checho

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

2011-11-17T14:31:00Z

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)

2011-11-07T10:05:00Z

¡Hola a todos!

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

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

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

¿Qué hace el archivo de autorespuesta realmente?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

PsGetSid WinGuy2

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

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

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

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

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

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

Redirección de Perfil de Usuario manualmente

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

Método Online

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

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

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

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

En la consola de comandos, ejecutamos:

Net User Administrator /Active:Yes

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

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

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

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

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

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

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

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

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

Net User Administrator /Active:No

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

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

Método Offline

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

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

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

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

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

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

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

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

Saludos,

Checho

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

2011-11-04T15:03:00Z

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

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

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

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

¿Qué necesitamos?

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

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

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

Configurando Archivo de autorespuesta

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

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

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

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

¡Empecemos!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Construyendo Imagen…

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

El comando para construir la imagen es:

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

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

En mi caso, sería:

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

Sobre asignación de particiones

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

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

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

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

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

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

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

Saludos,

Checho

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

2011-10-25T09:57:00Z

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)

2011-10-19T13:38:00Z

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

2011-10-11T19:57:00Z

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.

2011-10-10T12:11:00Z

¡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

[Tip] Ejecutando Sysinternals Tools desde cualquier parte en Windows.

2011-09-20T10:40:00Z

Básicamente, las Suite de herramientas de Sysinternals Tools permiten tanto a los Administradores de sistema, como a los desarrolladores y a los apasionados por la tecnología en general enfocándonos a Windows hacer diagnostico y solución de problemas (Si nos referimos a IT), además de Administración y debug de las aplicaciones que se desarrollen (Si nos referimos a Developers).

Personalmente, hay tres de estas herramientas que me han ayudado muchísimo a entender conceptos core de Windows solucionando problemas, me refiero a Process Explorer, Process Monitor y Autoruns. Por tanto, me gusta tenerlas siempre a la mano sea en dispositivos, o bien en sistemas virtuales o físicos.

El pequeño “problema” es que aunque son de Microsoft, las herramientas actúan de forma portable (No requieren instalación) por lo que normalmente se pueden descomprimir en alguna carpeta del directorio que deseemos y ejecutarlas desde ahí, enlazánolas por ejemplo desde la barra de tareas o el escritorio, o bien usando la búsqueda de Windows.

Esto está bien, pero no siempre se vuelve completamente productivo porque la carpeta fácilmente puede desaparecer y siempre tendría que recurrir a la misma manera de ejecución.

Es aquí donde entran las famosas Variables de entorno.

Las Variables de Entorno básicamente especifican rutas de búsqueda para archivos, aplicaciones, directorios temporales, entre otros, en otras palabras almacenan datos que el sistema y las aplicaciones pueden utilizar, por ejemplo: %SYSTEMDRIVE% se refiere a la ubicación donde está instalado el sistema operativo, en la mayoría de los casos C:\Windows

La ventaja como ven, es que lo que además de que puedo referirme a la variable para encontrar la ubicación sin importer donde esté por ejemplo, es que puedo ejecutar su contenido también desde diferentes lugares dentro de Windows.

Existen unas variables de Entorno que se refieren específicamente a rutas del sistema, por ejemplo cuando ejecutamos Notepad, Calculadora, Regedit y cualquier otra herramienta desde la Consola de comandos, El menu de inicio o desde una aplicación, Windows está buscando internamente su contenido dentro de la variable de entorno Path en la ubicación C:\Windows ó C:\Windows\System32 por ejemplo.

Algunas personas acostumbran a poner las herramientas que requieren de Sysinternals en C:\Windows\System32, así pueden ejecutarlas desde cualquier parte, pero resulta un poco más provechoso si enlazamos toda la Suite entera en un solo directorio para que tenga el mismo resultado sin necesidad de entrar en directorios protegidos del sistema.

Estableciendo una Variable de entorno para Sysinternals Suite

1. Lo primero que debemos hacer es descargar toda la Suite de herramientas de Sysinternals, o bien las herramientas que deseemos, desde www.sysinternals.com y más precísamente para la Suite desde aquí: http://download.sysinternals.com/Files/SysinternalsSuite.zip

2. Descomprimimos la carpeta para que nos quede la de SysinternalsSuite y la renombramos si nos parece más cómodo o bien símplemente dejamos el nombre predeterminado que en últimas no sera de mucha importancia.

3. Para asegurarnos de que nadie más pueda modificar el contenido ni la carpeta de la Suite, la ubicamos en el directorio C:\Archivos de programa\, la ruta completa, por ejemplo sería: C:\Archivos de programa\SysinternalsSuite

4. Ya está la ruta, ahora, para referenciarla hacemos clic en Inicio, clic derecho sobre Equipo, Propiedades y en la ventana de Propiedades del sistema abrimos Configuraciones avanzadas del sistema.

En la ventana de Propiedades del sistema, pestaña Avanzado, debajo del nodo de Inicio y recuperación veremos el botón de Variables de entorno:

5. En la ventana de Variables de Entorno, buscamos debajo de Variables del Systema, la variable Path y hacemos clic en el botón Editar (Edit):

6. Por último, en la ventana de Editar Variable del Sistema, nos ubicamos en la última disponible, para agregar otro directorio empezamos con un signo de punto y coma ( ; ) y después la ubicación a la que deseamos hacer referencia, por ejemplo C:\Archivos de programa\SysinternalsSuite

*Nota: Podemos hacer referencia incluso con otra variable de entorno, por ejemplo, en vez de decir C:\ nos referimos a %SystemDrive%, quedaría: ;%SystemDrive%\Program Files\SysinternalsSuite\

Después de hacer clic en el botón Aceptar (OK), podremos lanzar cualquiera de las herramientas desde los diferentes métodos en Windows, por ejemplo : Menú de inicio, Consola de comandos, Ventana de Ejecutar, Cuadro de búsqueda del Explorador de Windows, etc:

*Nota: Debemos referirnos al nombre del proceso, por ejemplo si es Process Explorer, sería: procexp

¡Eso es todo! Espero les pueda ser de utilidad.

Saludos,

Checho

Windows Live y Windows 8, mejor juntos: Sync PC Settings

2011-09-14T20:29:00Z

¡Hola!

Es magnífico poder escribir nuevamente por aquí y con buenas noticias.

El día de ayer 13 de Septiembre de 2011 Microsoft en su gran evento BUILD hizo pública la primera versión de Windows 8 en una fase denominada Pre-Beta, el nombre actual con el que se referencia es Windows Developer Preview.

Como es de saberse, esta fase Pre-Beta representa un primer avance de lo que se pretende mostrar ahora enfocado al estilo METRO tocando un poco más la nube además pero, en realidad esta compilación es todavía muy jóven puesto que no ha llegado ni siquiera hasta Beta. Esto quiere decir que de aquí a la gran GA (Disponibilidad general) probablemente hayan demasiados cambios con respect a lo que vemos hoy en día.

Para todos los que deseen, pueden realizar la descarga de este Windows Developer Preview que se encuentra en las dos arquitecturas más conocidas (x86 y x64) desde la página oficial de Microsoft: http://msdn.microsoft.com/en-us/windows/apps/br229516

Sin embargo, el propósito de este post no es sólo entregar la noticia (Que para esta hora, medio planeta la debe saber) sino permitirme escribir sobre una de las características que más me ha llamado la atención hasta ahora, se llama Sync PC Settings.

Una de las primeras diferencias al instalar Windows 8 (Developer Preview) es que a parte de preguntar por el nombre del equipo y una nueva forma de configurar las demás opciones rápidamente es que ahora pedirá un correo electrónico como opción predeterminada para iniciar por primera vez sesión:

Después de darle al botón Siguiente (Next) procederá a preguntarnos las credenciales correspondientes de nuestro Windows Live ID, es tal como si estuviéramos iniciando session en nuestra bandeja de entrada:

*Nota: Si no se dispone de internet o de una cuenta, o tal vez símplemente no se quiere asociar una cuenta de Live ID (Hay varias razones por las que no se podría querer), el asistente brinda una forma de crear la cuenta local, sin embargo no la detallaré aquí por no se el propósito del post.

Lo interesante de todo esto es que a partir de que iniciemos sesión, siempre podremos hacerlo con nuestras propias credenciales por lo que no sera explícitamente necesario disponer de cuentas locales, todo lo que necesito ahora es disponer de mi Live ID =)

Una de las ventajas que entrega esto es por supuesto la seguridad de nuestra contraseña, la posibilidad de iniciar automáticamente sesión en todos los sitios de Microsoft en que se pueda (prácticamente todos!) y lo más interesante, hacer uso de Sync PC Settings.

Sync PC Settings lo podemos asemejar con una característica que ya disponemos a nivel de directorio active con Windows Server y Windows 7 y es los Perfiles rodantes o Roaming Profiles pero esto se va por internet.

Básicamente cada que iniciemos sesión en un equipo que esté corriendo Windows 8 (Por lo menos esta versión de Developer Preview) con la cuenta de Windows Live ID, automáticamente sincronizará varias configuraciones y personalizaciones que haya hecho en equipos previamente. Si es la primera vez, guardará las que se hagan para un próximo inicio de sesión.

Esto es configurable por supuesto, basta con ir al la página de Inicio presionando la tecla Windows o bien hacienda clic en el botón Start, seleccionar Control Panel (Panel de control) y buscar el tab de Sync PC Settings y podremos ver lo que nos seguirá con nuestro perfil:

En pocas palabras, podremos disponer en cada inicio de sesión de lo siguiente:

- Fondos de pantalla que hayamos establecido

- Fondos de pantalla de inicio de sesión (Lock Screen, Nuevo en Win8)

- Personalización de los colores de la barra de tareas y sonidos.

- Configuración de algunas aplicaciones

- Configuración y personalización de nuestro navegador

- Imágenes de usuario, configuración de Grupo de Hogar, y hasta personalizaciones en las opciones de carpeta de Windows.

- Entre otros pocos.

Todos son completamente personalizables desde esta página, por lo que podremos desactivar algunos o todos al tiempo desde Sync settings on this PC.

¿Cómo funciona?

Como la opción está predeterminada, lo único que tenemos que empezar a realizar son las configuraciones que normalmente hacemos a nuestro perfil de usuario (Fondos de pantalla, de aplicaciones, etc) en un equipo, cuando iniciemos sesión en otro con las mismas credenciales (incluso podemos estar con la sesión iniciada en dos equipos al tiempo y habrá sincronización) a los pocos minutos (Dependiendo de la conexión de internet) podremos visualizar todos los cambios.

Para ilustrar un poco más, para este artículo inicié sesión en un primer equipo con una cuenta de Windows Live ID (@windowslive.com) , lo siguiente fue personalizar el Lock Screen, el fondo de pantalla, el color de la barra de tareas a negro y finalmente cambiar las opciones de carpeta para que mostraran los archivos protegidos por el sistema:

PC 1: Windows 8 Test

Lock Screen:

Desktop settings:

PC 2: Windows 8 Test 2

En el otro PC, basta con iniciar sesión si es que no se ha hecho o bien esperar unos cuantos segundos para la magina!

Inicio de sesión:

Desktop:

Lock Screen:

En imágenes puede costar creerlo, pero los invite a que lo prueben ustedes mismos y vean la velocidad de actualización, incluso con las dos cuentas en la sesión simultánea.

*Nota: Es muy importante no dejar abiertas las sesiones porque puede traer peligro a la integridad de la cuenta de Live ID asociada si entran a las configuraciones dentro de Hotmail.

Como ven, hay varias características aún en esta primera fase que pudieron haber notado adicionales como la apariencia, lo del Lock Screen (Trataré de verlo pronto), Hyper-V entre muchas otras.

Los invite a que estén pendientes al evento de BUILD que se celebra hasta el próximo 16 de Septiembre donde podrán ver de primera mano todos los cambios destinados a Desarrolladores sobre todo pero que incluyen por supuesto varias de las propuestas como esta que propone Windows 8.

*Off topic: ¿Tienes Twitter? Ahora he creado una cuenta donde estaré compartiendo lo que más pueda y les agradezco a los que me quieran seguir. Para hacerlo, basta con seguir el siguiente enlace: Checho on Twitter

*Nota: Muchas de estas funcionalidades y de hecho la apariencia pueden variar de aquí hasta la versión final que sea liberada, por lo que este artículo está soportado por ahora sólo en esta Preview, cualquier cambio que se de sobre el mismo lo estaré informando en futuros post que espero escribir.

Saludos,

Checho

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

2011-09-03T20:19:00Z

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

2011-08-31T08:25:00Z

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