Implementar el Modo Empresa para dirigir los sitios de Microsoft Edge a Internet Explorer en Windows 10

Hace unos días escribí un post respecto a la nueva característica de Microsoft Edge, en donde documenté algunos argumentos sobre lo que personalmente creo, es un bug. Dos de las tres formas disponibles para que funcione la característica tienen problemas, pero finalmente pude utilizar la tercera para que se implemente sin inconvenientes, así que decidí crear este nuevo post.

La característica de Modo Empresa o Enterprise Mode en inglés, tiene como objetivo emular IE7 e IE8 dentro de IE11 cuando se trabaja con Internet Explorer, pero además de dirigir las páginas a que se abran con Internet Explorer cuando se implementa para Microsoft Edge. En otras palabras, nosotros creamos una cantidad de sitios que Edge leerá y los dirigirá a IE una vez el usuario intente abrirlos.

A continuación, pasaré a describir paso a paso cómo podemos implementar esta sencilla solución en nuestra organización.

Requerimientos

1. Tener un entorno de dominio.

2. Tener actualizadas las Plantillas Administrativas (ADMX) para Windows 10 en uno de los controladores de dominio. La siguiente KB de Microsoft explica cómo:
https://support.microsoft.com/en-us/kb/3087759

2. Servidor 2012 R2 de preferencia, unido al dominio y en el que se vaya a instalar y configurar el IIS.

3. Crear en el servidor los directorios EMED en la partición de Windows, adentro una llamada Root, y dentro de esta creamos otra llamada List:

image

Si quieren automatizar el proceso, pueden ejecutar desde una ventana de PowerShell con privilegios elevados lo siguiente:

New-Item C:EMEDRootList -Type Directory

image

*Nota: Terminará siendo el mismo resultado. Las carpetas no tienen que llamarse de la misma forma; yo utilizaré estos nombres de referencia para el resto del post.

4. Descargar e instalar en el servidor la herramienta de Enterprise Mode Site List Manager. La descargan desde aquí: http://www.microsoft.com/en-us/download/details.aspx?id=42501

5. Equipo técnico con Windows 10 unido al dominio, donde se hará la prueba.

Creando y configurando sitio IIS

En el servidor destinado para IIS, abrimos el Server Manager, clic en el panel izquierdo de Dashboard y luego en Add roles and features:

image

En la página de Before you begin, clic en Next:

image

En Select installation type, dejamos la selección predeterminada y clic en Next:

image

En la página de Select destination server, nos aseguramos de estar en nuestro servidor local y clic en Next:

image

En la página de Select server roles, escogemos Web Server (IIS) y en el cuadro adicional, clic en el botón de Add Features:

image

Clic en Next cuatro (4) veces más para llegar a la página de Confirm installation selections.

En la página de Confirm installation selections, clic en el botón Install:

image

Una vez terminada la instalación, clic en el botón Close.

Hasta aquí ya tenemos nuestro servidor web, lo que sigue es crear nuestra página para alojar el XML con las páginas que Edge abrirá con Internet Explorer.

Abrimos la ventana de Ejecutar (Windows + R) y lanzamos: InetMgr.exe

image

En la ventana de Internet Information Services (IIS) Manager, expandimos el nombre de nuestro servidor, clic derecho en el nodo de Sites y seleccionamos Ad Website…

image

En la ventana de Add Website, llenamos los siguientes datos:

Site name: EMEdge

Physical path: C:EMEDRoot

Host name: Nombre completo de nuestro servidor, en mi caso: srv-dc1-vmw.winside.co

Después de esto, clic en el botón OK para crear el sitio:

image

*Nota: Tener en cuenta que el puerto especificado debe estar habilitado en el firewall.

Nuestro sitio estará creado y listo para usarse:

image

Creando y agregando lista de compatibilidad al IIS

Nuestro siguiente paso será crear nuestra lista de compatibilidad, configurada para que Microsoft Edge la entienda y administre correctamente los sitios que debe ejecutar con IE.

En el mismo, ejecutamos el Enterprise Mode Site List Manager instalado desde los requerimientos desde el escritorio o Inicio.

En la ventana del Site List Manager, hacemos clic en el botón Add:

image

En la ventana de Add new website, escribimos la dirección de la página, una descripción si queremos, nos aseguramos de tener seleccionado Open in IE y clic en Save:

image

*Nota: En la parte de Launch in, podemos aprovechar para establecer diferentes modos de compatibilidad en Internet Explorer; por ejemplo, escoger que emule IE8 o algún modo de documentación inferior. En mi caso yo solo quiero que se abra con IE, así que puse el Default Mode.

Repetimos el mismo procedimiento hasta que hayamos agregado todos los sitios a la lista:

image

Hacemos clic en el menú File y luego Save to XML:

image

Navegamos hasta C:EMEDRootList, asignamos el nombre de Sites.xml y clic en Save:

image

Para verificar que todo haya quedado bien, debemos acceder al sitio IIS agregando la ruta para el XML que sería: /List/Sites.xml. En mi caso quedaría:

http://srv-dc1-vmw.winside.co/List/Sites.xml

Recordemos que el nombre se lo dimos al momento de crear el sitio. Debemos ver entonces todo el XML que leerá nuestros equipos clientes:

image

*Nota: Recordemos que el nombre será diferente para cada uno; si el XML no se ve correctamente, deben verificar que la dirección esté correcta.

Cuando el sitio esté comprobado, copiamos la dirección completa para los siguientes pasos y cerramos el IIS Manager.

Creando la directiva de grupo

Nuestro último paso consiste en crear la directiva de grupo que forzará a que Microsoft Edge lea el XML creado previamente, para abrir esos sitios con Internet Explorer.

En mi dominio de laboratorio, tengo una OU creada explícitamente para los equipos con 10; de esta forma puedo probar las directivas sin afectar a los otros equipos:

image

En algún controlador de dominio, o desde un equipo donde podamos acceder al Group Policy Management, creamos una nueva GPO para Microsoft Edge; en mi caso la llamaré Enterprise Mode for Edge y la enlazaré a la OU de WIN10_Computers:

image

Editamos la directiva de grupo y navegamos hasta:

Computer ConfigurationPoliciesAdministrative TemplatesWindows ComponentsMicrosoft Edge

*Nota: Recuerden que deben actualizar las Plantillas Administrativas (ADMX) si no están en Windows Server 2016.

En el panel derecho, hacemos doble clic sobre la plantilla: Allows you to configure the Enterprise Site List

image

En la ventana de la plantilla, seleccionamos Enabled y en la parte inferior, en el cuadro de texto debajo de Type the location (URL) of your Enterprise Mode IE website list, ingresamos la URL creada y copiada en los pasos anteriores. En mi caso, quedaría así:

image

Hacemos clic en el botón OK para terminar.

*Nota: Recordemos que la URL no será la misma para ustedes, pues todo depende del nombre del servidor y dominio.

¡Todo listo! Nuestros siguientes pasos son finalmente en el equipo cliente con Windows 10.

Probando la directiva en Windows 10

En nuestro equipo Windows 10, cerramos Microsoft Edge y procedemos a actualizar las directivas de grupo ejecutando: gpupdate /force

image

Acto seguido, procedemos a abrir Microsoft Edge, digitamos alguno de los sitios que debe leer de la directiva y, si todo sale bien, deberá mostrar un mensaje de advertencia y ejecutar Internet Explorer con el mismo sitio.

image

Esto mismo pasará con todos los sitios que se hayan agregado al XML.

Probablemente se pregunten: ¿Qué pasa si el equipo está por fuera de la red y no puede acceder al XML? Pues bien, cada que Microsoft Edge puede leer el XML correctamente mientras accede a los diferentes sitios, crea un caché local, del que aún no puedo evidenciar, pero además una lista con los sitios que están en el XML y se han abierto por lo menos una vez en la sub-clave:

HKEY_CURRENT_USERSOFTWAREClassesLocal SettingsSoftwareMicrosoftWindowsCurrentVersionAppContainerStorage
microsoft.microsoftedge_8wekyb3d8bbweMicrosoftEdgeNeedIE

image

El valor en uno (1), abre automáticamente Internet Explorer, mientras que en cero (0) solo muestra el mensaje en Edge pero no ejecuta IE 11. Cabe aclarar que si uno crea la entrada manualmente no funciona, por lo que hay algo más que sucede internamente cuando toma la lista desde el XML; lamentablemente no he logrado encontrar más detalles.

*Nota: Si logro encontrar más, crearé un post específicamente de esto en un futuro.

En este orden de ideas, Edge seguirá abriendo los sitios con IE que ya haya creado en el Registro; cuando vuelva a tomar la directiva y el usuario ingrese a otro sitio agregado, el navegador escribirá la entrada en el Registro para la próxima vez que acceda con el caché.

Espero haya sido de utilidad.

PD: No olviden seguirme en Twitter: www.twitter.com/secalderonr

Saludos.

Checho

[¿Bug o no?] La lista empresarial no reconocida por Microsoft Edge en Windows 10, ProcMon, ProcExp y su solución

En Windows 8.1 Update, Internet Explorer 11 introdujo una nueva característica llamada: Modo Empresa, que básicamente permite emular gran parte de Internet Explorer 8 con el fin de que las aplicaciones antiguas, que solo funcionaban en esta versión del navegador, se pudieran utilizar en IE11 y de esta forma se facilitara la migración de sistema operativo. Debido a la buena acogida y realimentación que ha tenido la característica, se integró otro modo de emulación para Internet Explorer 7 y Modos de Documentación adicionales que por supuesto ampliaba más la compatibilidad hacia atrás. Pueden ver un poco más sobre esta característica en el artículo que escribí para el blog de Tulpep

Windows 10, a parte de seguir soportando Internet Explorer 11, tiene un foco específico en su nuevo navegador llamado Microsoft Edge, desarrollado desde cero y muy enfocado al consumidor soportando los últimos estándares, mucho más rápido que otros navegadores del mercado y sobre todo fácil de utilizar:

2015-08-12_17-57-59

En el lado empresarial, Edge tiene una cantidad de Directivas de Grupo, y una de las características más interesantes es que la herramienta de Microsoft para crear la lista empresarial del Modo Empresa se ha actualizado, con el fin de indicarle a Microsoft Edge qué sitios debe abrir obligatoriamente con Internet Explorer, así se ejecuten desde el nuevo navegador. Es una característica muy prometedora, pero lamentablemente no me logró funcionar como debía, así que en vez de mostrarles cómo configurarla, resulté escribiendo este post exponer lo que hasta ahora no sé si se puede catalogar como bug o no.

*Nota: Una vez esté completamente seguro que la característica se puede configurar sin necesidad de hacer lo que expondré a continuación, intentaré sacar el tiempo para escribir un artículo paso a paso concentrándome solo en eso y no en el problema como en esta ocasión.

El problema

Básicamente, existe ahora una directiva de grupo para Microsoft Edge llamada: Permite configurar la lista de sitios empresariales; utiliza un XML creado con la herramienta de Enterprise Mode Site List Manager para generar una lista de sitios que Edge debe obligatoriamente abrir con Internet Explorer.

2015-08-12_18-08-00

La directiva está ubicada en:
Configuración de Equipo/UsuarioPlantillas AdministrativasComponentes de WindowsMicrosoft Edge.

Yo, con toda la expectativa, descargué la actualización de la herramienta Enterprise Mode Site List Manager desde el sitio de Microsoft y agregué el sitio de la empresa en que trabajo (tulpep.com) para probar la característica; lo único diferente a lo que se hacía en Internet Explorer, es que ahora se marca una casilla de Open in IE para que Edge sepa que debe pasárselo a su antecesor. Así se ve:

2015-08-12_18-16-52

Luego de esto, guardé el XML como Sitios.xml y lo guardé en C:Sitios. En la directiva debía especificar esta ruta:

image

Lo siguiente era solo actualizar las directivas (GPUPDATE), abrir Edge e ingresar el sitio para que hiciera la redirección, pero desafortunadamente nada pasó y el navegador abrió la página común y corriente:

image

Aquí empecé a preguntarme: ¿Qué pasó? ¿Por qué no abrió con IE? ¿Qué hice mal? Procedí entonces a crear otra vez el XML, actualizar la directiva a incluso reiniciar Windows, pero ningún resultado positivo. Pude también escalar el tema a un primer contacto del equipo de Microsoft Edge, pero sin solución y por ese lado todavía estoy esperando si llego a instancias más altas.

Como no quería permanecer de brazos cruzados, decidí ir un poco más allá y tratar de diagnosticar el problema yo mismo.

La causa

Para saber porqué la lista empresarial no estaba funcionando con Edge, debía tratar de entender un poco más qué estaba sucediendo por debajo, y para eso no hay otro camino más fructífero que recurrir a las herramientas de Sysinternals.

Lo que hice fue cerrar Edge, ejecutar Process Monitor, limpiar la primera traza con CTRL + X, lanzar Edge, entrar a Tulpep.com y después de que no sucediera el comportamiento esperado volví a Process Monitor para detenerlo y empezar a analizar los resultados.

Como no sabía realmente por dónde empezar, recurrí al camino más lógico y era ver qué estaba sucediendo con el archivo Sitios.xml. Esto fue lo primero que encontré:

image

Edge estaba consultando el contenido de un valor llamado SiteList y que estaba ubicado en la sub-clave:
HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftMicrosoftEdgeMainEnterpriseMode

Esta sub-clave en realidad no es nueva, pues a diferencia del nombre (MicrosoftEdge), es exactamente la misma que utiliza Internet Explorer al activar el Modo Empresa. Ese valor de registro contiene la ruta al XML que debe utilizar el navegador para leer los sitios y su respectiva configuración; en otras palabras, es el reflejo de la directiva que se creó.

Para este caso, el resultado era SUCCESS, así que podía acceder a la ruta del XML:

image

Con esto pude asegurarme que la directiva se estaba creando correctamente y el navegador sí buscaba el XML… ¿por qué no usaba la configuración entonces?

Seguí buscando en Process Monitor por los resultados que arrojara el XML, pero obviando ya las operaciones sobre la sub-clave de registro mencionada, pues estaba correcta. Para mi fortuna, encontré lo que sería la clave de todo esto:

image

Como ven, el proceso de Microsoft Edge estaba tratando de realizar una operación a nivel de sistema de archivos (CreateFile) con el XML, pero el resultado era ACCESS DENIED; es decir, por alguna razón el navegador no estaba pudiendo acceder libremente al archivo.

Debido a que la operación CreateFile en Process Monitor no siempre refleja el nombre, es decir, crear un archivo, era necesario ver un poco más de detalles para entender qué intentaba hacer así que procedí a hacer doble clic en el evento para ver las propiedades:

image

La disposición era de Open, así que Edge estaba intentando abrir el archivo y recibía un acceso denegado. ¿Por qué?

Obviamente, lo primero que pensé es que mi usuario no tenía permisos NTFS para acceder al archivo, así que fui a las propiedades de la carpeta Sites que había creado y agregué explícitamente mi usuario con todo el control:

image

Lo siguiente era cerrar Edge, volverlo a ejecutar e intentarlo otra vez. Con toda la esperanza lo hice, pero desafortunadamente el navegador seguía abriendo la página en vez de enviarla a Internet Explorer.

Volví entonces a reiniciar Process Monitor y reproducir el comportamiento para saber qué resultados obtenía; para mi mala fortuna, aún era ACCESS DENIED:

image

Este fue el momento más confuso para mi, pues no podía entender cómo dándole permisos explícitos al usuario aún recibía el acceso denegado… entonces recordé algo que Windows integró desde los tiempos de Vista: ¡Los niveles de integridad!

Un nivel de integridad hace parte del mecanismo de integridad que tiene el sistema operativo, y se asigna a procesos de aplicaciones o a objetos (como archivos, carpetas, etc) para representar su confianza. Desde Windows Vista, han existido 6 niveles de integridad: Untrusted, Low, Medium, High y System; siendo Untrusted el más bajo y por supuesto System el más alto de todos.

*Nota: Normalmente interactuamos solo con: Low, Medium, High y System.

Básicamente, un proceso no podría llegar a leer o modificar un objeto que tenga un nivel de integridad superior. El caso más concreto lo tiene Internet Explorer cuando Windows tiene activado el UAC y el Modo Protegido no se ha bajado; de esta forma, el navegador siempre está ejecutándose con nivel de integridad Low, así que nunca podrá por sí solo ejecutar o guardar archivos maliciosos en directorios protegidos de Windows, sino en sus propios directorios temporales.

Es importante tener en cuenta que un proceso podría escribir sobre un objeto que tenga nivel de integridad igual o menor que él; es decir, System puede escribir en todos, pero Medium solo podría sobreponerse a un objeto que tenga el mismo nivel o que esté en Low.

Este mecanismo de seguridad no es fácilmente administrable y es el sistema operativo el que se encarga de la gestión.

*Nota: Trataré, cuando mis conocimientos me lo permitan, de escribir un post completo para explorar los mecanismos de integridad en Windows con ejemplos prácticos.

Volviendo al caso, yo supuse que Microsoft Edge estaba corriendo con un nivel de integridad Low y eso explicaría por qué no podía leer desde un directorio de Windows o de usuario que tiene Medium. Para asegurarme, ejecuté Process Explorer, habilité la columna de Integrity Level y procedí a abrir Edge para investigar para encontrarme con esto:

image

Tal como ven en la captura, el nivel de integridad (el último dato de la derecha), era nada más y nada menos que AppContainer. En principio no entendía mucho, pero después de un poco de búsqueda, encontré que las aplicaciones de interfaz moderna corren todas con este nivel de integridad especial y, al parecer, es un poco más bajo que Low.

El explorador de archivos ejecuta por su parte con un nivel de integridad Medium:

image

A pesar de que es una característica, parece que Microsoft Edge no sabe cómo lidiar con su propio dilema de seguridad, pues a diferencia de IE, no es posible desactivar el modo protegido para que el nivel de integridad sea Medium también.

En un principio pensé que estableciendo manualmente el nivel de integridad tanto de la carpeta como del archivo  Low podría hacerlo funcionar, pero al parecer debe ser explícitamente a AppContainer para que sea equivalente.

La solución

Yo no quería rendirme así, tan cerca del objetivo. Después de pensar por un buen rato, me di cuenta que naturalmente Microsoft Edge requería escribir en al menos un directorio del sistema operativo, así que esa carpeta muy seguramente tenía el mismo nivel de integridad y por ende podría leer todos los archivos que residieran ahí sin problemas.

Para encontrar el directorio, volví a Process Monitor y empecé a buscar por lo más básico que pensé, y era alguna carpeta que se llamara Temp, obviamente a nivel de sistema de archivos y que el proceso fuera MicrosoftEdge.exe. Esto fue lo que encontré:

image

Existía un directorio llamado Temp ubicado en:
C:UsersAndyAppDataLocalPackagesMicrosoft.MicrosoftEdge_8wekyb3d8bbweAC

Supe que este era el indicado, puesto que en las propiedades el Acceso Deseado (Desired Access) era Generic Read/Write, Delete, además de Create como Disposition y todo había tenido un resultado de SUCCESS. En otras palabras, Microsoft Edge tenía total libertad de leer, escribir y eliminar archivos en ese directorio.

Para ver que mi teoría era cierta, hice lo siguiente:

1. Copié el archivo Sitios.xml que le indicaba los sitios a Edge que debía mandar para que se abrieran con Internet Explorer en la ruta ya mencionada:

image

2. Acto seguido, actualicé la directiva de grupo para que apuntara al XML en la nueva ruta:

image

3. Actualicé nuevamente las directivas locales ejecutando: gpudate /force

image

4. Por último, cerré completamente Edge.

Para mi gran fortuna, cuando abrí nuevamente Edge y le introduje el sitio Tulpep.com, el milagro sucedió:

image

¡La característica esta funcionando como debía ser! Todos los sitios que estaban en el XML se abrían de forma automática con IE cuando se lanzaban desde Microsoft Edge.

Desafortunadamente con rutas de red no logré hacerlo funcionar, así que por ahora la única forma es tener el XML local en un directorio que Microsoft Edge pueda utilizar libremente.

Las preguntas para todos los que se tomen el trabajo de leer esto: ¿Qué opinan? ¿Creen que sea un bug?

¡Comentarios bienvenidos!

*Nota: Si en algún momento tengo respuesta oficial por parte de Microsoft, actualizaré la entrada para hacérselos saber.

Checho

Aplicar un Paquete de Aprovisionamiento a una imagen de Windows 10 offline utilizando DISM

Hace unos días mostré cómo podíamos crear y aplicar un Paquete de Aprovisionamiento a un equipo con Windows 10, de esta forma podríamos configurar un dispositivo fácilmente y sin necesidad de realizar instalación en limpio. También mencioné que existían diferentes formas de implementar estos paquetes, así que hoy quiero mostrar una manera un poco más técnica utilizando la herramienta DISM incluida en el ADK.

Para aplicar Paquetes de Aprovisionamiento con DISM, es necesario acceder a la imagen sin conexión; es decir, desde un Windows PE, o bien montando el .WIM en un directorio para después trabajar con él. El paquete se aplicará después de realizar la instalación del sistema operativo.

Requerimientos

1. Equipo técnico donde se vaya a realizar el procedimiento.

*Nota: Para este post, utilizaré un equipo técnico con Windows 10.

2. Crear una carpeta en la raíz ‘C’ llamada 10. Es decir: C:10.

3. Copiar los archivos de instalación de Windows desde el medio físico o virtual a la carpeta.

4. Crear una carpeta en la raíz ‘C’ llamada Montar. Es decir: C:Montar.

5. Descargar e instalar las herramientas de implementación incluidas en el ADK desde aquí:
Download the Windows ADK for Windows 10

6. Crear un paquete de aprovisionamiento sin cifrarlo. Para crearlo, ver este artículo:
http://geeks.ms/blogs/checho/archive/2015/08/03/compilar-y-aplicar-un-paquete-de-aprovisionamiento-a-un-equipo-con-windows-10-utilizando-windows-icd.aspx

7. Copiar el Paquete de Aprovisionamiento a una carpeta llamada Paquetes en ‘C’. Es decir, C:Paquetes

6. Equipo de referencia donde se vaya a probar la instalación y el paquete aplicado.

Montando la imagen de Windows 10

En el equipo técnico, clic en la pantalla o menú de inicio, buscamos PowerShell, clic derecho y Ejecutar como administrador:

2015-08-10_14-46-36

En la consola de PowerShell, ejecutamos la siguiente línea para montar la imagen:

Mount-WindowsImage -ImagePath "C:10sourcesinstall.wim" -Index 1 -Path "C:Montar"

2015-08-10_14-49-37

Implementando el Paquete de Aprovisionamiento

Con la imagen montada, ya podemos aplicar libremente uno o más Paquetes de Aprovisionamiento creados con Windows ICD.

Para este caso, utilizaré uno muy similar al que mostré en el primer artículo sobre Windows ICD. La diferencia es que no estará cifrado y no implementará ninguna directiva. Como mencioné en los requerimientos, es necesario copiar el paquete a la carpeta C:Paquetes.

2015-08-10_15-18-50

Para agregar el paquete a la imagen, ejecutamos desde PowerShell:

Dism /Image:C:Montar /Add-ProvisioningPackage /PackagePath:C:PaquetesBase_Configurations.ppkg

2015-08-10_15-22-04

*Nota: El resultado de DISM debe ser que el comando se completó satisfactoriamente.

Como dato curioso, observemos algunas de las cosas que pasan al ejecutar el comando:

2015-08-10_15-47-21

Como ven, lo primero que sucede en la carpeta donde está montada la imagen, es que DISM valida la existencia de una carpeta llamada Recovery, pero al no encontrarla (NAME NOT FOUND), la crea. Después de esto, hace lo propio con la carpeta Customizations que debe estar dentro de la carpeta Recovery; finalmente, copia el paquete de aprovisionamiento dentro de la carpeta Customizations. La ruta completa es: RecoveryCustomizations.

De acuerdo a la documentación oficial de Microsoft, todos los paquetes que estén en esta carpeta se ejecutará después del primer arranque de Windows, conocido como OOBE. En ese orden de ideas, así este paquete esté agregado desde la imagen, muy seguramente se aplicará ya cuando el sistema operativo esté instalado e iniciando por primera vez.

Tal cual dije antes, se pueden aplicar más de un paquete de aprovisionamiento a una imagen, aunque debe hacerse uno por uno.

Desmontando y guardando

Una vez hayamos agregado los Paquetes de Aprovisionamiento, ejecutamos:

Dismount-WindowsImage –Path “C:Montar” –Save

2015-08-10_16-10-30

Después de completado el comando, cerramos la consola de PowerShell.

Creando la imagen ISO

Desde el menú o pantalla de inicio, buscamos Deployment and Imaging Tools Environment, clic derecho y Ejecutar como administrador:

2015-08-10_16-14-29

Desde la consola, ejecutamos lo siguiente para crear una imagen ISO que nos sirva tanto en equipos con BIOS UEFI, como en Legacy BIOS:

Oscdimg -bootdata:2#p0,e,bC:10bootetfsboot.com#pEF,e,bC:10efimicrosoftbootefisys.bin -u1 -udfver102 C:10 C:Win10_with_packages.iso

2015-08-10_16-18-15

*Nota: Les recomiendo que copien y peguen el comando para evitar errores. Recuerden que está basado en los directorios que especifiqué en los requerimientos; si tienen otros, deben modificar el comando para que funcione.

Tendremos finalmente nuestra imagen creada:

2015-08-10_16-19-38

Instalando y probando

La instalación de Windows se hace común y corriente. Si todo sale bien, después de pedir las configuración rápida, se le debe indicar un usuario y luego iniciará con todos los cambios aplicados con el paquete de aprovisionamiento:

Nombre y unión al dominio:

2015-08-10_16-42-39

Usuario de soporte creado:

2015-08-10_16-43-01

¡Terminamos! Así como lo expliqué en el primer artículo sobre los Paquetes de Aprovisionamiento, estas configuraciones pueden ir más allá e integrar directivas MDM, así como controladores, actualizaciones y aplicaciones.

Espero sea de utilidad.

Saludos.

Checho

Iniciar sesión en Windows 10 utilizando credenciales de Azure Active Directory

Windows 10 llegó con una serie de características que cubren varios escenarios, desde la experiencia de usuario, hasta fuertes e interesantes mecanismos de seguridad. Como era de esperarse, con todo este cuento de la nube, el sistema operativo no se podía quedar atrás y ahora nos permite unirnos a Azure Active Directory; esto nos permite utilizar nuestras credenciales de Azure (Intune, Office 365) para iniciar sesión en el sistema operativo.

Entre las ventajas de unir los equipos a Azure Active Directory (AD), está la posibilidad de sincronizar configuración de Windows, fondos de pantalla, entre otras cosas; acceder a recursos en la nube y lo más significativo para el IT Pro: administrar equipos desde la nube utilizando soluciones MDM (como Windows Intune) en vez de utilizar Directivas de Grupo. Naturalmente, no existen tantas directivas, pero es bastante eficiente.

Debido a que Azure Active Directory es todo un tema aparte así que no entraré en detalle, pero sí mostraré a continuación cómo podemos unir nuestro Windows 10 y aprovechar esta nueva característica.

Requerimientos

1. Cuenta de Microsoft Azure.

2. Crear un directorio, junto con uno o más usuarios en Azure Active Directory.

3. Equipo con Windows 10 PRO / Enterprise.

*Nota: Pueden ver más información sobre los Directorios de Microsoft Azure aquí:
https://msdn.microsoft.com/es-es/library/azure/jj573650.aspx

Habilitando la unión de dispositivos a Azure AD

Lo primero que debemos hacer es permitir que los dispositivos se puedan unir a Azure AD. Para esto, ingresamos con una cuenta administrativa al portal de Microsoft Azure, vamos al nodo de Azure Active Directory, escogemos nuestro directorio y hacemos clic en el nodo de Configurar:

2015-08-04_20-09-56

*Nota: Obviamente el nombre del directorio será diferente.

En la parte inferior de Dispositivos, hacemos clic en el botón de TODO al lado de: Los usuarios pueden unir dispositivos a Azure AD.

2015-08-04_18-48-17

Para conservar los cambios, en la parte inferior se nos habilitará el botón de Guardar:

2015-08-04_20-17-04

Eso es todo lo que hay adicional dentro de Azure, lo siguiente va por cuenta de Windows 10.

Uniendo Windows 10 a Azure AD

Iniciamos sesión en nuestro Windows 10 que deseamos conectar a Azure AD, hacemos clic en el botón de Inicio y abrimos Configuración:

2015-08-04_20-21-12

En la aplicación de Configuración, clic en el nodo de Sistema:

2015-08-04_20-23-46

En Sistema, clic en Acerca de y en el panel derecho, clic en el botón Unirse a Azure AD:

2015-08-04_20-25-02

En la página de Unirse a Azure AD, clic en el botón Continuar:

2015-08-04_20-28-40

En la página de Vamos a iniciar su sesión, ingresamos nuestras credenciales de Azure AD (Office 365/Intune) y clic en Iniciar sesión:

2015-08-04_20-30-48

Una vez Windows 10 reconozca la autenticación, aparecerá una ventana en donde debemos simplemente confirmar haciendo clic en Unirse:

2015-08-04_20-32-27

Si todo sale bien, veremos la página de Todo finalizado donde solo debemos hacer clic en Finalizar:

2015-08-04_20-33-40

En Acerca de, debemos ver ahora nuestra organización conectada:

2015-08-04_20-34-42

Nuestro siguiente paso, al igual que en una unión al dominio, es reiniciar el equipo o para el caso de Azure AD que es más flexible, solo cerrar sesión.

En la pantalla de inicio de sesión veremos ahora el “Otro usuario”; al hacer clic ahí, nos pedirá nuestra cuenta corporativa o de educación. Debemos ingresar nuestras credenciales de Azure AD e iniciar sesión:

2015-08-04_20-38-14

Windows procederá a crear una cuenta local asociada a Azure AD y nos mostrará el asistente de siempre:

2015-08-04_20-40-31

Es muy probable que veamos una página azul donde Windows nos pida configurar un PIN alternativo para iniciar sesión no solo en Windows, sino en todos los servicios de la organización. La recomendación es crearlo, pero si no están interesados, basta con hacer clic en el botón Crear PIN y luego cerrar el asistente para que se habilite el botón de Omitir por ahora:

2015-08-04_20-42-28

Ya en Windows, podemos verificar rápidamente que en efecto estamos en Azure AD ejecutando desde un símbolo del sistema: whoami.

Noten que nos indica: azureadnombre

2015-08-04_20-45-42

¡Eso es todo! Aunque la parte realmente interesante está cuando nos conectamos a una red de trabajo para ser administrados utilizando MDM, dejaré eso para otro artículo.

Espero sea de utilidad.

Saludos.

Checho

Compilar y aplicar un Paquete de Aprovisionamiento a un equipo con Windows 10 utilizando Windows ICD

Finalmente llegó Windows 10 y con él, como es natural, varios problemas, características y en este caso, nuevas herramientas. Tengo entre mis planes escribir un poco sobre algunos aspectos de la experiencia de usuario, pero al ser tan familiar y sencillo de utilizar, deseo empezar por hablar de temas muy interesantes para el ámbito empresarial.

Hasta Windows 8.1, si nosotros queríamos desplegar y automatizar configuraciones específicas, debíamos utilizar un archivo de respuesta (Unattend.xml) creado con el System Image Manager (SIM); el proceso sin embargo no era tan sencillo, puesto que requería hacer varias cosas para que pudiera funcionar.

Con la liberación del nuevo ADK para Windows 10, existe una nueva herramienta llamada: Windows Imaging And Configuration Designer (Windows ICD); básicamente, podemos crear imágenes de Windows o paquetes de aprovisionamiento que nos permitirá agregar personalizaciones, características opcionales, paquetes de idioma, aplicaciones, actualizaciones de sistema operativo y controladores a todas las ediciones de Windows 10, incluyendo Mobile e IoT.

Los Paquetes de Aprovisionamiento, o Provisioing Packages en inglés, se pueden agregar a una imagen sin conexión de Windows, agregar durante la fase de OOBE, por NFC (en el caso de los Windows Phone) o simplemente correrlos en tiempo de ejecución. Por supuesto, esto solo funciona para Windows 10, y la idea principal detrás de todo esto, es que una organización pueda preparar un equipo con todo lo que se necesita sin necesidad de instalar nuevamente Windows y de una forma completamente automatizada.

Windows ICD es muy sencillo de utilizar y tiene múltiples escenarios que espero cubrir en este blog poco a poco; hoy me concentraré en el más sencillo de todos: crear un paquete de aprovisionamiento por primera vez y aplicarlo a una imagen de Windows en tiempo de ejecución.

Requerimientos

1. Descargar el ADK para Windows 10 desde aquí:
https://msdn.microsoft.com/en-us/windows/hardware/dn913721.aspx

2. Ejecutar el ADK e instalar el Windows Imaging And Configuration Designer:

2015-08-03_11-16-10

*Nota: Se seleccionará automáticamente las demás herramientas necesarias.

3. Disponer de un equipo con Windows 10 para aplicar el paquete de aprovisionamiento.

*Nota: Para entornos de prueba, se puede instalar Windows 10 sin activarlo. Se puede bajar desde el sitio oficial: https://www.microsoft.com/es-es/software-download/windows10

Creando y compilando el paquete de aprovisionamiento

Después de instalado, buscamos desde el menú o pantalla de inicio (según sistema operativo) el Windows Imaging And Configuration Designer, clic derecho y Ejecutar como administrador:

2015-08-03_11-21-50

Así luce el Windows ICD:

2015-07-30_14-05-10

Para empezar, hacemos clic en New provisioning package y se abrirá una pequeña ventana donde tendremos que indicar el nombre, además de una descripción opcional. En mi caso, como quiero crear un paquete básico de configuración, le puse el nombre de Base_configurations:

2015-08-03_11-27-12

Hacemos clic en el botón Next.

En la página de Choose which settings to view and configure, podemos escoger a qué tipo de edición le crearemos el paquete de aprovisionamiento. Para este caso, como solo nos enfocaremos a las ediciones de escritorio, seleccionamos Common to all Windows desktop editions y clic en Next:

2015-08-03_11-31-11

En la página de Import a provisioning package (optional), clic en Finish:

2015-08-03_11-41-26

Este será nuestro entorno de trabajo para configurar el paquete:

2015-08-03_11-44-13

Aunque la imagen trata de explicarlo, tenemos tres columnas: una izquierda en donde podemos buscar los activos o configuraciones, una central en la que escogemos qué deseamos agregar y finalmente una derecha donde realizamos las personalizaciones.

Como son muchas las personalizaciones y activos, iré cubriendo las más populares en los próximos artículos.

Volviendo al artículo, lo que vamos a automatizar es:

1. Nombre de equipo.
2. Unión al dominio.
3. Creación de cuenta local.
4. Desactivar las actualizaciones automáticas.

Para el nombre de equipo, vamos hasta:
Runtime settings > Accounts > ComputerAccount > ComputerName

En el panel central, donde está el cuadro de texto en blanco al lado de ComputerName, digitamos el nombre del equipo que deseamos establecer; lo interesante de esta característica es que podemos utilizar la variable %SERIAL% o %RAND:x% para no repetir.

En mi caso, yo pondré: CLT-W10-%RAND:5%

2015-08-03_13-57-56

Para la unión al dominio, vamos hasta:
Runtime settings > Accounts > ComputerAccount

En el panel central, debemos especificar Account, DomainName y Password. Como los nombres lo indican, es la cuenta con permisos de unión al dominio, el nombre del dominio y la contraseña de esa cuenta. En mi caso, para el dominio WinSide.co, utilicé la cuenta WINSIDEsercal y se ve así:

2015-08-03_13-58-35

Noten que ComputerName también se hubiese podido configurar desde ahí.

Para la creación de la cuenta local:
Runtime settings > Accounts > Users

En el panel central, al lado de UserName, escribimos el nombre de usuario local que deseamos crear, por ejemplo: SupportUser y clic en el botón Add.

2015-08-03_12-55-46

Una vez agregado, veremos en el panel izquierdo unas alertas rojas en las configuraciones, agregando además otros nodos debajo de Users:

2015-08-03_12-57-18

Allí hacemos clic sobre el nodo de UserName: <NombreEscrito>, y en el panel central personalizamos Password para agregar contraseña y seleccionamos Administrators en UserGroup:

2015-08-03_12-59-34

Para desactivar las actualizaciones:
Runtime settings > Policies > Update > AllowAutoUpdate

En el panel central, indicamos el número cinco (5) al lado de AllowAutoUpdate:

2015-08-03_14-08-27

Al terminar, podremos ver todas las propiedades que se agregaron en el panel derecho:

2015-08-03_14-10-37

¡Todo listo! Aquí agregamos muy pocas, pero como ven, hay muchísimas personalizaciones que se podrán lograr desde un paquete de aprovisionamiento.

Para compilar, vamos al menú superior de Export y seleccionamos Provisioning package:

2015-08-03_13-11-09

En la primera ventana de Build, escogemos IT Admin debajo de Owner y clic en Next:

2015-08-03_13-12-08

En la página de Select security details for provisioning package, podemos dejar que el paquete esté cifrado, ya que contiene información confidencial, agregar una firma digital si tenemos y clic en Next:

2015-08-03_13-14-29

*Nota: En mi caso yo dejé el paquete cifrado, pero no es necesario.

En la página de Select where to save the provisioning package, dejamos la ruta predeterminada y clic en Next:

2015-08-03_13-17-37

En la página de Build the provisioning package, revisamos todo por última vez y hacemos clic en el botón de Build:

2015-08-03_13-19-09

En la página de All done! navegamos hasta el directorio en el que se guardó el paquete de aprovisionamiento y clic en Finish:

2015-08-03_13-20-31

Así luce nuestro Paquete de Aprovisionamiento, junto con los demás archivos creados:

2015-08-03_13-21-55

Aunque el único que necesitamos es el paquete de aprovisionamiento, que tiene extensión .ppkg, los demás archivos como el XML se pueden utilizar en otros escenarios.

Probando y verificando el paquete de aprovisionamiento

Ya en la parte más fácil, tengo un equipo con Windows 10 PRO que tiene un nombre genérico y no está unido al dominio:

2015-08-03_13-26-44

Nuestro siguiente paso es copiar manualmente el paquete de aprovisionamiento creado al equipo y ejecutarlo haciendo doble clic.

Lo primero que nos debe pedir es elevación de privilegios:

2015-08-03_13-30-22

Después de aceptar y solo en caso de que lo hayamos cifrado, nos pedirá la contraseña que nos entregó en el asistente de compilación:

2015-08-03_13-31-40

Por último, debido a que no agregamos certificado digital, nos pedirá confirmación, además de darnos algunos detalles generales de lo que hará el paquete:

2015-08-03_14-12-18

Hacemos clic en el botón de Sí, agregarlo y esperamos hasta que el paquete haga la tarea, para después reiniciar:

2015-08-03_13-34-35

2015-08-03_13-34-43

Lo primero que deben notar al reiniciar, si es que agregaron las propiedades de dominio, es que el equipo podrá iniciar ahora desde una cuenta corporativa:

2015-08-03_14-15-01

Al iniciar sesión, podremos ver en las propiedades del sistema el cambio de nombre y toda la información del dominio:

2015-08-03_14-16-32

Al abrir un símbolo del sistema y consultar por SupportUser, este es el resultado:

2015-08-03_14-34-11

El usuario se creó y se agregó al grupo de administradores.

De igual forma, al conectarnos a internet y entrar a buscar actualizaciones, veremos que están desactivadas:

2015-08-03_14-30-39

*Nota: Si antes de aplicar el paquete de aprovisionamiento ya había actualizaciones pendientes para descargar, será necesario instalarlas.

Información adicional: Quitar un paquete de aprovisionamiento

No todas las configuraciones que aplica un paquete de aprovisionamiento se pueden quitar; sin embargo, es posible devolver a un estado de configurado algunas directivas aplicadas.

Para quitar un paquete de aprovisionamiento:

1. Clic en Inicio y Configuraciones.

2. Clic en Cuentas.

3. Clic en Acceso al trabajo.

4. Clic en la parte inferior: Agregar o quitar un paquete para el trabajo o colegio.

2015-08-03_14-44-34

5. En la página de Paquetes de aprovisionamiento, podremos seleccionar el que hayamos aplicado y darle al botón Quitar:

2015-08-03_14-45-06 

Las directivas tomarán algunos minutos para quitarse.

¡Eso es todo! Conforme vaya aprendiendo, iré documentado aquí cosas aun más interesantes que se pueden hacer con los paquetes de aprovisionamiento.

Espero sea de utilidad.

Saludos.

Checho

Realizar un inventario de aplicaciones instaladas utilizando Application Compatibility Toolkit (ACT)

Hasta el día de hoy, todas las entradas que he hecho en este blog sobre ACT, muestran cómo aplicar determinado shim para solucionar algún problema de aplicaciones como la corrección de rutas o mentira sobre versión; sin embargo, ese no es el único propósito de ACT, así que deseo dedicar este artículo para mostrar algo muy útil en una organización: realizar inventario de aplicaciones instaladas de una forma fácil y rápida.

Requerimientos

1. Descargar el ADK para Windows 8.1 Update desde aquí:
http://www.microsoft.com/en-us/download/details.aspx?id=39982

Ver “Instalando ADK” abajo para las instrucciones de instalación.

*Nota: La descarga solo baja un pequeño cliente que sirve para bajar el contenido completo o instalarlo desde la web. Recomiendo bajar todo antes de instalar.

2. Servidor 2012 R2 que puede ser o no dedicado y que esté unido al dominio de la organización.

*Nota: No es estrictamente necesario que sea Server 2012 R2, pues el ADK funciona desde 2008, incluso en equipos cliente también.

2.1. Crear una carpeta en cualquier unidad llamada: ACTLogs.

3. Equipos cliente que estén unidos al dominio para tomar el inventario.

4. [Opcional] Descargar e instalar SQL Server 2012 Management Studio Express desde aquí:
https://www.microsoft.com/en-US/download/details.aspx?id=29062

Instalando ADK

Cuando descarguemos todo el contenido, pasamos los archivos de instalación al servidor destinado para el ACT, hacemos doble clic sobre el adksetup.exe y procedemos con los siguientes pasos:

1. En la página de Specify Location, escogemos la ruta donde deseamos instalar el ACT, preferiblemente en la que está predeterminada y clic en Next:

2015-06-19_10-45-29

2. En la página Join the Customer Experience Improvement Program (CEIP), escoger si deseamos unirnos al programa y clic en Next:

2015-06-19_10-47-12

3. En la página de License Agreement, clic en Accept:

2015-06-19_10-49-01

4. En la página Select the features you want to install, seleccionamos: Application Compatibility Toolkit (ACT) y, en caso de no tener una base de datos implementada, SQL Server 2012 Express. Luego hacemos clic en Install:

2015-06-19_10-56-48

*Nota: La base de datos se utiliza para guardar el inventario recolectado por el Application Compatibility Manager (ACM), incluido en el ACT.

5. En la última página del asistente, clic en el botón Close para terminar.

Instalando y Configurando ACM

En el Windows Server, buscamos Application Compatibility Manager, clic derecho y Ejecutar como administrador:

2015-06-19_14-25-53

En la página de Welcome to the ACT configuration wizard, clic en Next:

2015-06-19_14-35-47

En la página de Do you want to use this computer to run an ACT Log Processing Service?, dejamos la selección de Yes para que el servicio se instale en el mismo equipo y clic en el botón Next:

2015-06-19_14-36-52

En la página de Configure your ACT Database Settings, escogemos (local)Settings y luego en el botón de Connect para realizar la conexión a la base de datos:

2015-06-19_14-39-29

Una vez detectada, le ponemos el nombre de ACT a la base de datos y clic en Next:

2015-06-19_14-42-04

En la página de Configure Your ACT Database Settings, clic en el botón Next para iniciar la configuración automática:

2015-06-19_14-43-36

En la página de Configure Your Log File Location, hacemos clic en el botón Browse para seleccionar la carpeta ACTLogs creada en el requerimiento 2.1 y clic en Next:

2015-06-19_14-45-44

En la página de Configure Your ACT Log Processing Service Account, dejamos la selección de Local System y clic en Next:

2015-06-19_14-47-29

En la página Congratulations, clic en Finish para terminar:

2015-06-19_14-48-51

Configurando el Data Collection Package

En la consola de Microsoft Application Compatibility Manager, clic en el menú File y seleccionamos New:

2015-06-19_14-58-26

En la ventana de Create a data-collection package, clic en el botón de Invetory collection package para crear el paquete que se encargará de recolectar el inventario de aplicaciones en nuestros equipos:

2015-06-19_15-00-09

En la página de Set up your inventory package, le damos un nombre a nuestro paquete y una etiqueta para diferenciarlo; después de esto, clic en el botón Create:

2015-06-19_15-26-08

Posteriormente, escogemos una ruta donde queramos guardar el MSI que vamos a distribuir:

2015-06-19_15-29-59

Clic en Finish para terminar.

Cerramos la consola del ACM.

Modificando permisos en ACTLogs

Antes de desplegar el paquete que hará el inventario, es necesario modificar unos permisos de seguridad sobre la carpeta ACTLogs creada en los requerimientos. Para esto, seguimos estos pasos:

1. Navegamos hasta la carpeta ACTLogs, clic derecho y Properties:

2015-06-21_16-50-14

2. Vamos a la pestaña de Sharing y luego Advanced sharing:

2015-06-21_16-52-52

3. Clic en el botón Permissions:

2015-06-21_16-53-52

4. Clic en el botón Add, escogemos Domain Computers, aceptamos y luego asignamos permisos para cambiar:

2015-06-21_16-54-54

5. Clic en OK dos veces y luego pasamos a la pestaña de Security.

6. Clic en el botón Edit:

2015-06-21_16-56-51

7. Clic nuevamente en el botón de Add, buscamos Domain Computers, clic en OK y luego asignamos permisos de escritura:

2015-06-21_16-58-04

8. Clic en OK y luego en Close para terminar.

Distribuyendo y probando

Nuestro último paso es lograr ejecutar el .MSI que nos creó el ACM en todos los equipos donde deseamos tener inventario de aplicaciones; lo podemos hacer a través de la red con alguna solución como directiva de grupo o bien manualmente en cada equipo.

El cliente reporta perfectamente tanto para equipos cliente, como para equipos servidor. Por ejemplo, estas son las aplicaciones que tengo instaladas en el equipos destinado para ACT:

2015-06-21_17-12-14

Basta con ejecutar el ACT_Inventory.msi creado con una cuenta que tenga privilegios administrativos y lo único que veremos será un pequeño progreso.

Al abrir nuevamente la consola del ACM, vamos a la pestaña inferior izquierda de Analyze y en la pestaña de Windows 8.1 veremos información previa de lo que se recolectó:

2015-06-21_17-22-07

Al hacer clic en el nodo de Applications, podremos ver todas las mismas aplicaciones pero en el inventario hecho por el cliente ACT_Inventory que creamos:

2015-06-21_17-25-32

El inventario hecho en equipos Server 2012 R2 se verán en el mismo nodo de Windows 8.1. Si nos pasamos a la pestaña de Computers en el panel izquierdo, podremos ver de todas formas de qué sistema operativo proviene:

2015-06-21_17-27-22

Como mencioné antes, otra forma de realizar este despliegue sería como un Script de arranque a través de Directiva de Grupo:

2015-06-21_17-31-16

Como recomendación, es más productivo desplegarlo con alguna solución como SCCM.

En la lista de equipos, se puede ver cada equipo en particular haciendo doble clic; todos los datos estarán disponibles:

2015-06-21_17-46-06

Naturalmente, entre más equipos se reporten, más grande será el inventario en ACM:

2015-06-21_17-49-23

Desde ACM podemos además hacer doble clic sobre una sola aplicación y ver en cuántos equipos está instalada, o qué versiones son las que existen:

2015-06-21_17-52-10

2015-06-21_17-53-13

Intentará en un futuro artículo hablar sobre el otro tipo de paquete, y operaciones adicionales que se puede hacer desde el Application Compatibility Manager.

Espero sea de utilidad.

No olviden seguirme en Twitter: www.twitter.com/secalderonr

Saludos.

Checho

El mensaje: “Microsoft Word/Excel dejó de funcionar” en Office 2013, ProcDump, Windbg, Process Monitor y su solución

El problema más grande de comprar un equipo con Windows preinstalado, es decir, que sea OEM, es que normalmente tiene toda la basura que te puedas imaginar instalada. Casi siempre tiene antivirus de terceros, aplicaciones del fabricante que no sirven para nada y otra tanta cantidad de cosas que afectan el rendimiento del sistema operativo desde el primer momento.

Sumado a lo anterior, está la cantidad de basura adicional que ofrecen algunas instalaciones de productos como impresoras, agregando una cantidad de complementos inútiles en Windows.

La parte positiva de todo eso, por lo menos para los que nos emocionamos con problemas extraños, es que se puede llegar a aprender mucho con cualquier inconveniente causado por la combinación de tanta instalación. A continuación paso a describir un caso muy interesante, que puede ser además de ayuda para los que experimenten algo similar. 

El problema

Básicamente, se había comprado la licencia personal de Office 365 a un equipo OEM, que obviamente tenía antivirus, software de impresora y otra cantidad interminable de aplicaciones de terceros; poco tiempo después de instalado Office, siempre que intentaban abrir un archivo de Word o Excel, Windows respondía con estos mensajes:

2015-06-10_11-00-51

<<Microsoft Word dejó de funcionar>>

2015-06-10_11-04-36

<<Microsoft Excel dejó de funcionar>>

No importa si se abría con privilegios estándar o administrador, un documento ya hecho o en blanco, siempre había crash antes de empezar a editar. Ahora, existían dos cosas curiosas:

1. Si se ejecutaba Word, la pantalla de bienvenida funcionaba sin ningún problema:

2015-06-10_18-06-10

Al hacer clic en Documento en blanco, se reproducía el problema. Lo mismo pasaba en Excel, solo funcionaba hasta la pantalla de bienvenida.

2. El crash solo se reproducía en Word y Excel; PowerPoint por otra parte, funcionaba perfectamente, sin importar de qué forma se abriera.

Antes de yo entrar a revisar el problema, habían intentado reinstalar y reparar el Office, pero sin resultado positivo.

La causa

Lo más trágico de un crash en Windows, sea de aplicación o de sistema operativo, es que la información que brinda no sirve absolutamente para nada en la mayoría de ocasiones. En el caso de este mensaje, el “dejó de funcionar” es el mismo para cualquier aplicación que se detenga y no se pueda recuperar.

Primero que todo, se me ocurrió que seguramente había alguna extensión proveniente de otra aplicación integrada en Office, y me acordé que hace muy poco Autoruns de Sysinternals agregó una nueva pestaña enfocada precisamente para revelar qué complementos tiene instalado la suite.

Descargué Autoruns, lo ejecuté como administrador en el equipo y, en efecto, había algunos complementos cargando con Office:

2015-06-10_22-35-50

Deshabilité los tres complementos, reinicié Word con mucha expectativa, pero para mi mala fortuna, el problema continuaba. Nada más para hacer por el lado de Autoruns, pues rara vez se le escapa algo a las herramientas de Sysinternals.

Aunque no sé nada sobre depuración de volcados de memoria, es decir, archivos .DMP, un análisis elemental puede ser de mucha ayuda como en el caso de pantallazos azules. Lo que hice entonces fue descargar ProcDump de Sysinternals, copiarlo en la carpeta de System32 para ejecutarlo desde cualquier procedí a hacer lo siguiente:

1. Creé la carpeta C:Dump para almacenar cualquier volcado de memoria.

2. Desde un símbolo del sistema con privilegios elevados, ejecuté:

procdump -e -w -ma winword.exe -accepteula C:Dump

2015-06-10_17-21-50

La función de ProcDump es monitorear un proceso y escribir un volcado de memoria cuando el proceso exceda los parámetros indicados, o cuando hay alguna excepción que genere un crash. Esto es mucho más útil que hacerlo desde el Administrador de tareas, puesto que lo hace en el instante adecuado y de forma automática.

El parámetro de –e, sirve para escribir un volcado de memoria cuando el proceso tenga una excepción no controlada, –w espera a que el proceso se ejecute y –ma escribe un volcado de memoria completo. Después de esto, especifiqué el proceso que deseaba monitorear y dónde quería guardar el volcado de memoria.

Una vez hecho esto, ejecuté Windbg en mi propio equipo y abrí el volcado de memoria creado desde la opción File > Open Crash Dump:

2015-06-10_22-45-32

Ya en la consola de Windbg, hice la operación más básica, ejecutar: !analyze –v

2015-06-10_22-25-00

Tal cual como lo haría con un análisis de pantalla azul, después del amplio reporte que entrega Windbg, me concentré en lo que contenía el STACK_TEXT, que es básicamente lo que había en memoria al momento del crash.

Lo ideal es descartar las entradas que se refieran a módulos de Windows y analizar las demás. En este caso, me encontré con dos muy interesantes:

2015-06-10_17-49-31

Ambas entradas tenían un mismo módulo llamado SprintIntegration. Para obtener más información, ejecuté desde la consola: lm vm SprintIntegration y obtuve esto:

2015-06-10_17-50-09

Era una DLL llamada SprintIntegration.dll, perteneciente a una empresa con el nombre de ABBYY y con nombre de producto: ABBYY FineReader. Ya había una interesante pista, ¿cómo sabía de qué forma estaba interactuando esto con Office? Seguramente desde el Windbg hubiese podido obtener muchos más detalles, pero a falta de conocimiento, decidí ejecutar Process Monitor y seguir el rastro desde la ejecución de Word, hasta el crash.

Con todo el log de Process Monitor a la mano, realicé un primer filtro para que sólo me mostrara actividad que tuviese el proceso de Winword.exe perteneciente a Microsoft Word:

2015-06-10_16-34-55

Hecho esto, abrí el cuadro de búsqueda (CTRL + F) y busqué por entradas que tuviesen referencia al nombre de producto ABBYY FineReader; el primer resultado arrojó una luz sobre lo que pasaba:

2015-06-10_17-42-18

Tal como ven en la captura (clic para verla en tamaño real), Word estaba consultando a un valor llamado FriendlyName, en la sub-clave:

HKLMSOFTWAREWow6432NodeMicrosoftOfficeWordAddinsSprint.WordIntegration.9

Lo primero que llamó mi atención, es que estaba sobre la sub-clave de Addins y Autoruns no me había mostrado nada relacionado a Sprint.WordIntegration, cosa que me extrañaba bastante, porque al parecer esto era en realidad una extensión más de Office.

Cuando vi en las propiedades de la entrada en Process Monitor, pude ver finalmente la relación con el módulo de ABBYY:

2015-06-10_23-37-13

Así se veía todo el contenido de la sub-clave Sprint.WordIntegration.9 en el Registro:

2015-06-10_23-41-06

En la misma sub-clave de Office además, noté que cada producto tenía su apartado de Addins, y cuando expandí los de Excel y PowerPoint, encontré algo particular:

2015-06-10_17-48-33

Tanto la sub-clave de Addins para Word, como la de Excel tenían la clave de Sprint, pero PowerPoint no; esto era un claro indicador del porqué ahí no había crash y en los otros dos productos sí.

La prueba final era proceder a eliminar la sub-clave para que el producto no la pudiera encontrar al abrirse:

2015-06-10_18-00-04

Después de esto, abrí solo Word que es donde le había quitado ese complemento y no hubo ningún tipo de crash.

La solución

Encontrado y probado la causa, mi siguiente paso era ver de qué forma podía implementar una solución. Eliminar ambos complementos solucionaría el problema tanto en Word como en Excel, pero decidí buscar otro camino directamente desde la aplicación.

En Programas y Características, identifiqué la versión que tenía instalado Windows de ABBYY:

2015-06-10_17-46-58

Tal como ven, era la 9.01.513.58212; abrí la aplicación en cuestión, fui al menú de Ayuda y como pensaba, existía la opción para buscar actualizaciones:

2015-06-10_18-03-25

Para mi grata sorpresa, se abrió una página web indicándome que en efecto, había una actualización para la versión 9.0, pero lo más interesante era uno de los detalles sobre esta:

2015-06-10_18-02-42

Esta aplicación corregía la integración con Office 2010 y 2013, así que probablemente el desarrollador ya tenía identificado el problema que estaba causando.

Descargué la actualización y procedí a instalarla. La versión cambió ligeramente:

2015-06-10_18-24-09

Volví finalmente a abrir Word y como supuse, ya no había crash, así que podía utilizar libremente Word y Excel:

2015-06-10_18-05-14

Obviamente, eliminar la sub-clave Sprint.WordIntegration.9 en los Addins de Word y Excel hubiese solucionado el problema sin necesidad de actualizar el cliente, pero actualizar era más sano y soportado.

¡Espero sea de utilidad!

No olviden seguirme en Twitter: www.twitter.com/secalderonr

Saludos.

Checho

Crear y configurar una partición de recuperación en Windows 8.1

Hace ya un buen tiempo, escribí sobre una característica interesante de recuperación para Windows 8/8.1 llamada: Refresh. Básicamente, me permitía realizar una instalación de Windows, volviendo a un punto que yo especificara con perfil y archivos. Primero mostré cómo creaba y luego cómo se podía establecer una imagen creada en un equipo en otro PC.

Refresh funciona muy bien y por lo general es el primer camino, pero hay ocasiones en las que por diferentes razones quieres volver a restaurar el equipo sin conservar nada, tal cual se hacía con las particiones de recuperación entregadas por los OEM en Windows 7. Bajo esta necesidad, es que existen la característica de Reset, que permite hacer reinstalación del sistema operativo partiendo de una imagen sin conservar nada.

Recordemos que Windows 8/8.1 me permite escoger cuál de las dos quiero ejecutar, Una restauración sin afectar los archivos (Refresh), o quitar todo y reinstalar Windows (Reset):

2015-06-05_12-17-36

En los artículos mencionados al principio mostré y expliqué cómo configurar Refresh, ¿pero qué pasa con Reset? Normalmente ya existe una partición de recuperación, pero me lleva el equipo a un punto donde el OEM me lo entregó y quizá quiera reinstalar, pero que se haga sobre una imagen que contenga las aplicaciones ya instaladas.

En el resto del post explicaré cómo podemos capturar una imagen a partir del sistema que tenemos instalado y configurar un punto de Reset.

Requerimientos

1. Crear un Entorno de Preinstalación (Windows PE):

Para no hacer demasiado largo el post, tengo creado un artículo en TechNet Wiki donde explico paso a paso cómo podemos hacer esto:
http://social.technet.microsoft.com/wiki/contents/articles/28497.how-to-crear-un-entorno-de-preinstalacion-de-windows-windows-pe-es-es.aspx 

2. Respaldar el código de producto de Windows:

Para hacer esto, descargamos y ejecutamos la aplicación ProduKey de Nirsoft y la ejecutamos para obtener nuestro código de activación:

2015-06-05_11-37-39

Capturando la imagen maestra

Una vez hayamos creado el Windows PE siguiendo el primer paso de los requerimientos, debemos grabarlo en un DVD o USB e iniciar nuestro equipo con Windows 8.1 desde él. Al iniciar, tendremos la consola del Windows PE:

2015-06-05_12-41-58

Lo que haremos será capturar la instalación actual para volverla un .WIM y poder utilizarla como imagen de recuperación.

Antes que nada, verificamos que la partición asignada dentro del Windows PE para nuestra instalación es la C; para esto, ejecutamos:

Dir C:

Debería ver en el resultado las carpetas de instalación como Program Files, Windows, etc:

2015-06-05_12-45-56

*Nota: Si esto no pasa, debemos utilizar Dir para ver el contenido de otras unidades como E, D, F, etc. En alguna de ellas, exceptuando la X que pertenece al Windows PE, quedarán la partición del sistema operativo. Generalmente se mantiene en C.

Luego de verificar la partición, procedemos a capturar ejecutando:

Dism /Capture-Image /CaptureDir:C: /ImageFile:C:install.wim /Name:¨Windows 8.1 Pro" /NoRpFix

2015-06-05_12-58-50

*Nota: Todo es una sola línea.

El tiempo que demore creando la imagen, dependerá de la velocidad y escritura del disco local.

Cuando llegue al 100 %, reiniciamos el equipo y dejamos que ingrese a Windows nuevamente. Al reiniciar, debe haberse creado un archivo llamado install.wim en la raíz del la unidad C:

2015-06-05_13-15-37

Ahora, es muy importante saber el peso de la imagen, pues de eso dependerá el tamaño para la partición de recuperación. En mi caso, la imagen pesa 11.1GB:

2015-06-05_13-17-35

Configurando partición de recuperación

En Windows 8.1, hacemos clic derecho sobre el botón de Inicio y seleccionamos: Administrador de discos:

2015-06-05_13-36-28

En la consola de Administración de discos, seleccionamos en la parte inferior el disco que deseamos reducir, hacemos clic derecho y seleccionamos Reducir volumen:

2015-06-05_13-43-02

En la ventana de Reducir, indicamos el espacio que deseamos reducir, teniendo en cuenta el espacio disponible para reducción. En este caso, tomé un poco menos de 13GB indicado en MB:

2015-06-05_13-48-38

El espacio sin asignar se verá inmediatamente en el administrador de discos. Hacemos clic derecho sobre este espacio sin asignar y seleccionamos Nuevo volumen simple:

2015-06-05_13-50-45

En el Asistente para nuevo volumen simple, hacemos clic en el botón Siguiente dos veces, hasta llegar a la página de Asignar letra de unidad o ruta de acceso. Allí asignamos la letra R y clic en Siguiente nuevamente:

2015-06-05_13-57-19

En la página de Formatear la partición, asignamos como etiqueta de volumen: Recovery y clic en Siguiente:

2015-06-05_13-58-18

En la página de Finalización del asistente para nuevo volumen simple, clic en Finalizar.

Lo que haremos ahora será ir a la nueva partición de Recovery desde el Explorador de archivos, crear una carpeta llamada Imagen y ahí pegar el archivo install.wim desde la unidad C que capturamos en los pasos anteriores.

Esto lo podemos automatizar ejecutando desde un símbolo del sistema con privilegios elevados:

mkdir R:Imagen

xcopy C:install.wim R:Imagen

2015-06-05_14-04-46

*Nota: Obviamente esto lo podemos hacer manualmente.

Cuando hayamos copiado el archivo, hacemos clic derecho sobre el botón de Inicio y seleccionamos Símbolo del sistema (administrador):

2015-06-05_13-24-49

En el símbolo del sistema, ejecutamos:

Reagentc /Setosimage /Path R:Imagen /Target C:Windows /Index 1

2015-06-05_14-13-12

Ya todo está listo, pero para que nos quede más estético, debemos marcar la partición como de recuperación y ocultarla para evitar que se borre. Para esto, desde la misma consola ejecutamos:

Diskpart

List disk

Esto nos listará todos los discos que tengamos conectados:

2015-06-05_14-18-14

En mi caso, solo tengo un disco, así que obviamente la partición está incluida en ese disco. Esto podría variar en cada uno de ustedes, pero recomiendo que se utilice un espacio en el mismo disco donde está instalado el sistema operativo.

Una vez identificado el disco, lo debemos seleccionara y proceder a marcarla como recuperación, quitarle la unidad y esconderla. Para mi caso, ejecutamos:

Select disk 0

List disk

Tendremos ahora la lista de particiones del equipo:

2015-06-05_15-18-42

Seleccionamos la partición correspondiente a la unidad de recuperación. En este caso, como sería la 5, el comando quedaría:

Select partition 5

Posteriormente, quitamos la letra de unidad asignada, le cambiamos el tipo y la ocultamos ejecutando:

Remove

set id=de94bba4-06d1-4d40-a16a-bfd50179d6ac

gpt attributes=0x8000000000000001

2015-06-05_18-37-44

Importante:

Si la BIOS no es UEFI, los comandos aquí deben ser así:

set id=27
remove

Hecho esto, en la consola de Administración de discos debe verse la partición sin letra y sin posibilidad de modificarla al darle clic derecho:

2015-06-05_18-41-22

¡Todo listo! Ahora cada que necesitemos reinstalar Windows, sin guardar nada y volviendo al punto donde capturamos la imagen, hacemos lo siguiente:

1. Presionamos las teclas Windows + I para abrir el panel derecho y clic en Cambiar configuración de PC:

2015-06-05_20-02-27

2. En la aplicación de Configuración de PC, clic en Actualizar y recuperar y luego en Recuperación.

3. En el panel derecho, hacemos clic en el botón Comenzar, debajo de Quitar todo y reinstalar Windows:

2015-06-05_20-03-59

4. En la página de Restablecer PC, clic en Siguiente:

2015-06-05_20-09-19

5. En la página de ¿Quieres limpiar completamente la unidad? clic en Quitar solo mis archivos:

2015-06-05_20-10-10

6. En la página de Listos para restablecer tu PC, clic en el botón Restablecer:

2015-06-05_20-11-15

El equipo se reiniciará y comenzará a restablecer usando la imagen establecida:

2015-06-05_20-13-00

Como dato adicional, este proceso seguirá funcionando para volver de Windows 10 a Windows 8.1, siguiendo un procedimiento para restablecer muy similar al enumerado.

Espero sea de utilidad.

No olviden seguirme en Twitter: www.twitter.com/secalderonr

Saludos.

Checho

El navegador que se abría solo al iniciar sesión, la extraña página que no dejaba navegar, Process Monitor y su solución

El problema que estoy por describir ya se había publicado hace un buen rato en un hilo de Microsoft Community, aunque sin una respuesta certera. Esta vez pude enfrentarme directamente al problema y afortunadamente pude encontrar una solución, así que no dudé en documentarlo para escribir este post.

El problema

Cada que el usuario iniciaba sesión, por reinicio o cierre de sesión, se abría Internet Explorer mostrando una curiosa página similar a esta:

2015-05-17_22-05-16

Al cerrar la página la ventana no volvía a aparecer, pero Internet Explorer tampoco permitía navegar a otra página diferente, puesto que siempre abría el extraño enlace y le enviaba como parámetro la página a la que se intentaba navegar.

Así se veía intentando ingresar a la web de Sysinternals:

Malware1

De esta forma, aunque se podían abrir los enlaces posteriormente, siempre se debía pasar por la página de login.lataminternet.com.

La causa

Lo primero que intenté para solucionar el problema fue abrir Autoruns y buscar entradas que pudiese ver sospechosas y que tal vez referenciaran a esa extraña web, o por lo menos dieran pistas del porqué Internet Explorer se ejecutaba al iniciar sesión. Lamentablemente, encontré solo algunas entradas de programas inútiles que si bien inhabilité, no me solucionaron el problema del navegador.

Lo que procedí a hacer fue ejecutar Process Monitor, posteriormente iniciar el navegador e intentar ir a algún sitio como el de Sysinternals para rastrear todo lo que estaba ocurriendo en Windows y pasar a diagnosticar.

Una vez abierto el log, abrí el menú de filtros (Filter > Filter) y creé uno para que solo se incluyera en el resultado las entradas que en su detalle (Detail) tuviesen lataminternet.com:

2015-05-17_22-29-45

Por fortuna para mi, fueron pocas entradas para analizar:

2015-05-17_22-33-01

La primera y la última entrada hacían referencia a la sub-clave de TypedURLs, que es donde al parecer Internet Explorer guarda el historial de todas las páginas que se han digitado completamente en la barra de direcciones. Muy similar a RunMRU de la ventaja de Ejecutar que tiene la lista de comandos lanzados.

Descartado eso, me quedaba la clave:

HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionURLPrefixes

Desde Process Monitor, hice clic derecho y seleccioné Jump To para ir al Registro y allí me encontré con una interesante sorpresa:

11263697_10152928299007476_1556594887_n

La clave predeterminada y la de www tenían como contenido la URL completa del sitio que se abría cada vez que intentaba navegar con Internet Explorer o iniciaba sesión.

En un equipo funcional, los valores deberían verse así:

2015-05-17_22-41-23

En la otra sub-clave de registro debajo de URL, llamada DefaultPrefix estaba también referenciado el sitio:

2015-05-17_22-47-59

Todo empezaba a tener bastante sentido, pues a parte del nombre Prefijos en español de la sub-clave, no se estaba abriendo solo el protocolo (http, por ejemplo), sino toda la página de login.lataminternet.com.

*Nota: Interesante además ver que lo que anteponga como contenido en cada uno de estos valores, lo va a lanzar el navegador, ¿no lo creen?

La solución

Lo que hice para solucionar el problema, fue lo siguiente:

1. Navegar hasta la sub-clave:

HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionURLDefaultPrefix

2. Allí hice doble clic sobre el valor predeterminado y lo dejé sin contenido:

2015-05-17_22-51-00

2. Después de esto, me pasé en la misma clave de URL a la sub-clave de Prefixes.

3. Quité el contenido del valor predeterminado y cambié el de www a solo http://

2015-05-17_22-52-49

4. Reinicié el equipo.

Después del reinicio, Internet Explorer no abrió más y ahora podía navegar sin problema alguno:

2015-05-17_22-55-33

Espero sea de utilidad.

PD: No olviden seguirme en Twitter: www.twitter.com/secalderonr

Saludos.

Checho

La aplicación que daba Acceso Denegado con el proceso elevado, UAC, Process Explorer, ResHacker y su solución

Una de las cosas que hacemos en Tulpep, empresa donde actualmente trabajo, cuando solucionamos un problema de alguna aplicación que requiere muchos pasos manuales, es ofrecer una solución alternativa en la que creamos un instalador y automatizamos los procesos con el objetivo de que sea más fácil para el cliente. Estos procesos suelen hacerse con Inno Setup, a no ser que sea un desarrollo propio.

Hace unos días terminé un instalador que debía entregar a un cliente y por supuesto, debía probar el funcionamiento en un laboratorio. Una de las Fuentes que tenía referenciado en el script de Inno Setup, era un .BAT que iba a correr después de terminada la instalación:

2015-04-18_19-20-58

El archivo en cuestión, utilizaba Robocopy para copiar unos archivos necesarios de la carpeta fuente de instalación, a la de otro programa que se enviaba a instalar desde el asistente:

2015-04-18_19-32-02

Hasta aquí nada raro, de hecho la instalación funcionaba muy bien desde el Inno Setup que previamente había lanzado como administrador.

El problema

Una vez probado todo, procedí a compilar el instalador y a probar desde él toda la instalación. Sabía que debía tener privilegios administrativos para las tareas que iba a ejecutar, pero solo con darle doble clic al Setup.exe que había creado, Windows me pedía elevación de privilegios:

2015-04-18_19-39-05

Con eso creí que era suficiente, ya que si el instalador pedía elevación, todo lo que ejecutara debía obtener el mismo token administrativo y proceder a realizar operaciones.

Sin embargo, al llegar al momento en que se lanzaba el BAT, recibí un mensaje de acceso denegado:

2015-04-18_19-52-32

Ahí se quedaba en un bucle infinito tratando de escribir y no pasaba. ¿Por qué?

La causa

Normalmente un proceso siempre adquiere el token o privilegios otorgados por su proceso padre; además de sus niveles de integridad. Si este ejecutable me pedía elevación, yo suponía que debía estar con los privilegios elevados pero, la única forma de comprobarlo iba a ser con Process Explorer de Sysinternals.

Lo que hice fue ejecutar Proccess Explorer, habilitar la columna de Integirty Levels y dejarlo en segundo plano mientras lanzaba la aplicación haciendo doble clic y aceptando el mensaje del UAC. Esto fue lo que encontré al dejar el instalador abierto y ver en Procexp:

2015-04-18_20-12-48

El árbol que muestra Process Explorer, ubica el proceso padre mucho más alineado a la izquierda que el hijo. En este caso, el proceso padre era Setup.exe, luego Setup.tmp y abajo de él, pero en el mismo nivel, estaban otros Setup y finalmente el cmd.exe que a su vez llamaba al Robocopy.exe.

A parte de que se creaban dos instancias: Setup.exe y Setup.tmp; el nivel de integridad que tenía heredado cmd y Robocopy era Medium (ver gráfica), cuando en realidad debería ser High como el que estaba arriba de cmd.exe. Todo esto quiere decir que cmd.exe estaba heredando el token del primer Setup.exe, así que siempre iba a ejecutarse con privilegios estándar y NO elevados.

La ventana del UAC que me pedía consentimiento elevaba la segunda instancia del Setup.exe, pero esto no servía de nada, ya que siempre los demás ejecutables o archivos por lotes que llamaba iban a seguir ejecutándose sin permisos administrativos. El resultado de todo esto: ¡Acceso Denegado!

Ahora, ¿Qué pasaba al tomarme el trabajo de darle clic derecho sobre el Setup.exe y seleccionar Ejecutar como administrador? Esto muestra Process Explorer:

2015-04-18_21-10-33

Básicamente, no había otra instancia del .EXE y .TMP. Las únicas dos instancias que existían estaban con el nivel de integridad en High (Alto); o sea que todo lo que el proceso llamara se iba a ejecutar con privilegios administrativos. Por ejemplo, el Robocopy:

2015-04-18_21-14-20

En pocas palabras, para que todo se ejecutara e instalara correctamente, necesitaba que la aplicación obtuviera el token administrativo desde su proceso padre.

¿Por qué una instancia quedaba elevada al hacer doble clic? No sé responder eso, pero lo que sí sabía en ese momento es que el instalador no estaba pidiendo elevación de privilegios administrativos. ¿Por qué me salía el primer mensaje pidiendo elevación? No sé, probablemente el UAC estaba

En este punto, una de las personas que más admiro, Ricardo Polo, me dio la pista clave: El archivo manifiesto de UAC que estaba en el instalador. No entraré en detalle porque me falta mucho conocimiento para escribir bastante al respecto, pero básicamente es un XML donde entre otras cosas, se le pide a Windows con qué nivel de privilegios debe ser ejecutada la aplicación. Existen tres, los máximos privilegios que el usuario le pueda otorgar, como se invoque (que se traduce básicamente a estándar) y pedir administrador. Técnicamente, se reconocen como: highestAvailable, asInvoker y requiereAdministrator.

Intentaré describir en otro post cómo lo hice, pero en esencia utilicé Strings de Sysinternals para ver los binarios del instalador y de ese resultado buscar el manifiesto. Este fue el resultado al verlo en un TXT:

2015-04-18_21-35-09

Debido a que el manifiesto que Inno Setup integraba a la aplicación pedía asInvoker, siempre se iba a ejecutar con privilegios estándar si se lanzaba con doble clic. El reto consistía en modificar ese manifiesto para que pidiera privilegios administrativos al ejecutarse.

La solución

Para poder modificar el manifiesto sobre el ejecutable, descargué Resource Hacker y procedí a hacer lo siguiente:

1. Lancé Resource Hacker haciendo clic derecho y Ejecutar como administrador.

2. Abrí el instalador desde ResHacker haciendo clic en File > Open.

2015-04-18_21-42-59

3. Expandí el nodo 24 > 1 y clic en 1033 para ver el string que tenía. Estos números pueden variar:

2015-04-18_21-44-53

4. Cambié el level por requiereAdministrator y clic en el botón Compile Script.

2015-04-18_21-52-38

5. Hice clic en el menú File > Save as…

2015-04-18_21-56-53

6. Le puse un nombre descriptivo con la extensión .EXE y lo guardé:

2015-04-18_21-58-34

7. Cerré Resource Hacker.

Finalmente, fui hasta la ruta del instalador y el nuevo instalador ahora tenía el escudo de UAC que identifica el requerimiento de privilegios para ejecutarse:

2015-04-18_22-00-08

Al ejecutarlo, aparecía el UAC y después de aceptar se elevaba el privilegio como debía ser:

2015-04-18_22-01-04

Este mismo procedimiento se le puede aplicar a cualquier instalador que deseen modificarle el manifiesto, si es que lo tiene.

Espero sea de utilidad.

PD: No olviden seguirme en Twitter: www.twitter.com/secalderonr

Checho