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

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:

Blender1

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

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:

Blender2

En principio, cuando Windows hacía uso de la API con la función CreateFile para generar el directorio de C:Program FilesBlenderPortable 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:WindowsMediaWindows 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:

Blender3

Cuando el proceso BlenderPortable.exe estaba tratando de crear el directorio C:Program FilesBlenderPortable 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:

Blender4

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

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:

post1

¿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 ProgramaWindows AIKToolsUSMT<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 USMTx86, 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:USMTx86 C:USMT

image

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

image

*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

image

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

image

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

image

*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

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:

ShellFolder1

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:

ShellFolder2

Windows estaba intentando hacer una consulta a la clave HKEY_CLASSES_ROOTFolderShellNewIconPath 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:WindowsSystem32Shell32.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:

Working

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

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

Workone

Sistema NO funcional:

Badone

Data”, era la misma ruta en ambos, pero como ven, en el primero hacía referencia correctamente a la ruta, es decir a %SystemRoot%System32Shell32.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:

image

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%system32shell32.dll,3

Another

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!

image

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

IE9_h_c

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:

image

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

image

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:

image

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:

image

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

image

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:

image

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:

IE2

La operación que Windows hace es utilizar la función de RegCreateKey para crear la clave de ClearableLisData en la ruta: HKEY_CURRENT_USERSoftwareMicrosoftInternet 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:

image

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

image

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

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 EquipoPlantillas AdministrativasComponentes de WindowsInternet ExplorerVista 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:

image

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:

image

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:

image

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:

image

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_MACHINESOFTWAREPoliciesMicrosoftInternet ExplorerBrowserEmulation

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_MACHINESOFTWAREPoliciesMicrosoftInternet ExplorerBrowserEmulationPolicyList

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:

image

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_MACHINESOFTWAREPoliciesMicrosoft

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

image

La llamamos Internet Explorer

image

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

image

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

image

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:

image

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

image

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

image

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