Checho's Blog

Talking about Windows Internals, Deployment and Troubleshooting.

Artículos recientes

News and Awards

Follow me on Twitter and LinkedIn

@secalderonr

View Sergio Calderon's profile on LinkedIn

Recomendados

Tags

Community

Email Notifications

Archives

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:\EMED\Root\List -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:\EMED\Root

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:\EMED\Root\List, 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 Configuration\Policies\Administrative Templates\Windows Components\Microsoft 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_USER\SOFTWARE\Classes\Local Settings\Software\Microsoft\Windows\CurrentVersion\AppContainer\Storage\
microsoft.microsoftedge_8wekyb3d8bbwe\MicrosoftEdge\NeedIE

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/Usuario\Plantillas Administrativas\Componentes de Windows\Microsoft 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_MACHINE\SOFTWARE\Policies\Microsoft\MicrosoftEdge\Main\EnterpriseMode

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:\Users\Andy\AppData\Local\Packages\Microsoft.MicrosoftEdge_8wekyb3d8bbwe\AC

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:\10\sources\install.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:\Paquetes\Base_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: Recovery\Customizations.

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:\10\boot\etfsboot.com#pEF,e,bC:\10\efi\microsoft\boot\efisys.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: azuread\nombre

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 WINSIDE\sercal 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:

HKLM\SOFTWARE\Wow6432Node\Microsoft\Office\Word\Addins\Sprint.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_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\URL\Prefixes

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_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\URL\DefaultPrefix

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

[How to] Monitorear Windows con Process Monitor en el inicio y cierre de sesión

La mayoría de los casos que suelo exponer en este blog, muestro cómo utilicé alguna característica de Process Monitor para encontrar pistas, causas o incluso la solución. Una de las características que más he utilizado en casos donde el problema se reproduce al inicio de sesión, o antes, es la de Boot Logging que me permite monitorear Windows incluso después de reiniciar el equipo.

Sin embargo, no siempre es práctico tener tantos datos cuando se está buscando algo muy concreto pero que se reproduce en un escenario de cierre o inicio de sesión. En este post mostraré cómo aprovechar PsExec y Process Monitor para cubrir este escenario sin necesidad de habilitar Boot Logging.

*Nota: Si lo que se quieres es monitorear controladores u otro tipo de cosas que suceden antes del inicio de sesión, la única opción es Boot Loggging.

Caso real de ejemplo:

Ahora, consideremos un problema que ha tenido cierta frecuencia en los foros de Microsoft; básicamente iniciamos sesión en Windows y nos encontramos con un mensaje de error como este:

2015-04-05_21-27-00

Como casi siempre pasa, después de aceptar el mensaje, no sucede nada más. El Administrador de tareas –si estamos de suerte- para este caso mostraría algo así:

2015-04-05_21-29-56

Deshabilitarlo serviría para evitar el mensaje, pero estaría actuando directamente sobre el proceso real de wscript.exe y no sobre la causa raíz. Obviamente NO iríamos por el camino fácil. =)

Como dije al inicio, el camino directo sería usar Boot Logging; aun así podemos combinar Process Monitor y PsExec para hacer algo más productivo:

Requerimientos

1. Descargar Process Monitor desde aquí:
https://technet.microsoft.com/es-es/sysinternals/bb896645

Descomprimir el archivo .ZIP.

2. Descargar PsExec desde aquí:
https://technet.microsoft.com/es-es/sysinternals/bb897553

Descomprimir el archivo .ZIP.

3. Copiar y pegar Procmon.exe y PsExec.exe al directorio raíz C:\

2015-04-05_21-42-22

Combinando Procmon y PsExec

Hacemos clic derecho en el botón de Inicio y luego en Símbolo del sistema (administrador):

2015-04-05_21-46-25

Aceptamos la ventana del UAC y una vez en la consola, ejecutamos en orden:

cd C:\

Esto nos ubicará en el directorio raíz C:\

2015-04-05_21-50-11

Una vez en la raíz, podremos ejecutar sin problemas Procmon y PsExec. Para que Proccess Monitor siga ejecutándose incluso después del cierre de sesión, ejecutamos:

PsExec –s –d C:\Procmon.exe /AccepEula /Quiet /BackingFile C:\Log.pml

2015-04-05_21-54-00

*Nota: PsExec me permite ejecutar procesos remotamente, pero además utilizar el usuario con súper poderes SYSTEM con la bandera –s; –d es para que PsExec se cierre sin esperar a que Procmon.exe lo haga y lo demás es para aceptar el EULA, que no muestre mensajes y que todo se vaya guardando en el archivo Log.pml ubicado en la misma unidad.

Utilizando Process Explorer de Sysinternals se puede verificar que Process Monitor está en ejecución, bajo la sesión 0 perteneciente a los servicios y con el usuario de SYSTEM:

2015-04-05_21-59-36

Procedemos a cerrar sesión, iniciar nuevamente, esperar a que el mensaje extraño vuelva a salir y hacemos lo siguiente:

Clic derecho otra vez en el botón de Inicio, Símbolo del sistema (administrador):

2015-04-05_21-46-25

En el símbolo del sistema, ejecutamos:

cd C:\

2015-04-05_21-50-11

Finalmente, ejecutamos lo siguiente para terminar el monitoreo:

PsExec –s –d C:\Procmon.exe /AcceptEula /Terminate

2015-04-05_22-03-38

Si todo sale bien, el log nos habrá quedado guardado en la raíz del disco local C:

2015-04-05_22-05-55

Lo único que queda es abrir el log y y empezar a jugar con Process Monitor para descubrir qué causa el mensaje de error.

Por ejemplo y para este caso, lo primero sería referenciar detalles sobre el proceso que lanza el wscript.exe; esto es fácil presionando las teclas CTRL + T para abrir el árbol de procesos y ubicar la ocurrencia que buscamos de wscript:

2015-04-05_22-09-02

Tal como ven, el proceso padre fue Explorer.exe, con su respectivo PID 2384.

Ya que es el Explorer.exe, indica que probablemente se ejecutó algún archivo al momento de iniciar sesión, no necesariamente que el proceso haya sido alterado.

Una buena práctica es siempre ver qué se está lanzando en ubicaciones tan comunes como la carpeta de Inicio que ha existido durante tanto tiempo y que le dice a Windows todo lo que debe ejecutar automáticamente.

Para que Process Monitor nos muestre las operaciones de lectura que hace solo en este directorio, podemos filtrar diciendo que excluya todos los PID diferentes al 2384 –en este caso-, que el resultado sea SUCCESS, la ruta contenga \Startup\ y la categoría sea Read:

2015-04-05_22-15-03

Noten que en la mayoría excluí lo que no quería, con el resultado que deseaba.

El resultado sería más o menos así:

2015-04-05_22-19-09

Gracias a que lo que dejaría Process Monitor sería muy conciso, identificar un archivo extraño como un acceso directo se podría hacer sin mayor dificultad.

*Nota: No me enfoqué en los filtros de Process Monitor, porque el objetivo era mostrar cómo ejecutarlo al cerrar e iniciar sesión; sin embargo intentaré crear otros artículos donde detalle más el tema.

Espero sea de utilidad.

Saludos.

Checho

Convertir un medio de Windows 10 PRO build 10041 a Enterprise utilizando DISM

Hace unos días, y después de casi dos meses, se liberó finalmente la compilación 10041 de Windows 10 de manera oficial. Lamentablemente, sólo se encuentran disponibles los bits de la edición PRO y no los de Enterprise. Como siempre, han salido muchos caminos para tenerlos a partir del medio de PRO; hoy quiero mostrarles el que en mi concepto es el más fácil y limpio de todos.

*Nota: Es muy probable que este post tenga validez solo para este caso, pues a futuro seguramente continuarán liberando la ISO de Enterprise aparte.

Requerimientos

1. Debemos tener instalado el ADK en un equipo. Aunque no lo he probado, no creo que haya problema en tener el de Windows 8.1, pero recomiendo hacerlo de una vez con el ADK para Windows 10 que se encuentra disponible aquí:
Download the Windows ADK for Windows 10 Technical Preview

En el momento de instalación, basta con seleccionar Deployment Tools para tener lo que necesitamos en el artículo:

2015-03-27_10-19-58

2. Descargar el medio de instalación de Windows 10 Technical Preview, build 10041. Lo pueden bajar desde sitio oficial de Microsoft:
http://windows.microsoft.com/en-us/windows/preview-iso-update-1503

Todo el procedimiento siguiente lo haré desde un equipo que ya tiene instalado Windows 10.

Actualizando PRO a Enterprise

Lo primero que debemos hacer es montar la imagen .ISO para extraer los archivos de instalación y poder manipularlos. Para esto, procedemos con estos pasos:

1. Hacemos clic derecho sobre la imagen ISO descargada y seleccionamos Montar:

2015-03-27_10-34-42

2. Una vez montado en la unidad virtual, identificamos la letra que Windows le asignó:

2015-03-27_10-35-54

En mi caso como ven, le asignó la letra G:\

3. Hacemos clic derecho en el botón de Inicio –8/8.1/10- y seleccionamos Símbolo del sistema (Administrador):

2015-03-27_10-38-28

4. Desde el símbolo del sistema, ejecutamos:

mkdir C:\10041

2015-03-27_10-40-35

Esto nos creará una carpeta llamada 10041 en la raíz del disco duro.

5. Luego ejecutamos:

xcopy <UnidadWin>\*.* /s/e/f C:\10041\

Donde <UnidadWin> corresponde a la letra asignada por Windows al medio en el momento de montar la imagen ISO. En mi caso, que es la G, el comando sería:

xcopy G:\*.* /s/e/f C:\10041\

2015-03-27_10-42-56

Todos los archivos de instalación se copiarán a la carpeta 10041 creada previamente. Es posible que tarde varios minutos, dependiendo de la velocidad de lectura y escritura de nuestro disco.

6. Clic en el botón de Inicio, buscamos Deployment and Imaging Tools Environment, clic derecho y Ejecutar como administrador (Run as administrator):

2015-03-27_10-51-57

*Nota: En Windows 8.1 obviamente la interfaz es diferente, pero el nombre y procedimiento es el mismo.

7. Desde la consola, ejecutamos:

mkdir C:\Montar

2015-03-27_18-02-45

Luego:

Dism /Mount-Image /ImageFile:C:\10041\sources\install.wim /index:1 /MountDir:C:\Montar

2015-03-27_11-18-59

Ahora, aquí es donde está el secreto de todo; desde la consola pueden ejecutar:

Dism /Image:C:\Montar /Get-TargetEditions

Este comando me dice a qué ediciones puede ser actualizada la edición actual. Esto es lo que mostrará:

2015-03-27_11-28-11

Como ven, a parte de Professional con Windows Media Center y Education –Ni idea-, puede ser actualizada a Enterprise. ¡Justo la que necesitamos!

8. Procedemos entonces a ejecutar:

Dism /Image:C:\Montar /Set-Edition:Enterprise

2015-03-27_11-33-08

9. Si no hay errores, procedemos a desmontar nuestra imagen ejecutando:

Dism /Unmoun-Wim /MountDir:C:\Montar /Commit

2015-03-27_11-37-00

10. Debido a que el medio es de PRO, el serial que lee para la activación obviamente no le funciona a Enterprise. Dicho esto, es necesario cambiar el serial que lee el asistente de instalación; para esto, vamos hasta la ruta: C:\10041\sources y hacemos doble clic en el archivo pid.txt. Este es el contenido:

2015-03-27_17-30-05

Borramos el serial que tiene como contenido la variable de value y lo remplazamos por este:

PBHCJ-Q2NYD-2PX34-T2TD6-233PK

Nos debe quedar así:

2015-03-27_17-31-56

*Nota: Estoy utilizando el mismo serial de Enterprise que tenía la build 9926.

11. Nuestro último paso, es crear la imagen ISO que servirá para instalar Windows 10 tanto en equipos EFI como en basados en BIOS ejecutando:

Oscdimg -bootdata:2#p0,e,bC:\10041\boot\etfsboot.com#pEF,e,bC:\10041\efi\microsoft\boot\efisys.bin -u1 -udfver102 C:\10041 C:\10041\Win10_10041_ENT.iso

2015-03-27_11-44-06

En la carpeta C:\10041 nos debe haber creado la imagen .ISO de instalación:

2015-03-27_11-45-21

¡Eso es todo! Solo queda instalar y comprobar que efectivamente es Enterprise:

2015-03-27_18-08-04

Espero sea de utilidad.

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

Saludos.

Checho

El estado de “Cannot connect to virtual machine configuration storage” en Hyper-V al intentar abrir una VM, Process Monitor y su solución

Desde ya hace varios años utilizo VMWare o Hyper-V como gestores de máquinas virtuales; normalmente varío por un tiempo dependiendo de qué quiero hacer, ya que cada uno tiene características notables. Actualmente tengo Windows 10 Enterprise Preview 9926 instalado en mi equipo principal, y debido a que VMWare 11 tiene unos problemas de compatibilidad con estas compilaciones, estoy utilizando Hyper-V.

Como tengo las máquinas virtuales en un disco externo USB, es normal que lo quite algunas veces para llevármelo, pero generalmente lo vuelvo a conectar y no tengo problema para iniciar mis entornos virtualizados. El siguiente post nace de un error después desconectar y reconectar el disco duro e intentar iniciar mis equipos virtuales. Como siempre, intentaré detallarlo un poco para aprender en el camino:

El error

El disco extraíble lo quité porque debía hacer unos procedimientos a un disco ajeno al mío, y no quería llegar a confundirme con tantas particiones. Windows asigna las letras de unidad dinámicamente, siguiendo un orden alfabético, pero entregando de acuerdo a la disponibilidad de letras de unidad.

Después de terminar con el disco ajeno y volver a conectar mi disco, tuve que decirle a Windows 10 desde el Administrador de Discos que asignara letra a las particiones, pero después de abrir Hyper-V, me encontré con esto:

2015-02-22_10-23-22

El estado de todas las máquinas era Saved-Critical, no podía ver detalles como memoria, CPU asignada y además, el estatus que recibía de cada una decía:

“Cannot connect to virtual machine configuration storage”.

Al darle doble clic a mi primera VM llamada DC-MED, pude abrir la ventana de conexión, pero con el mismo mensaje de configuration storage en la parte inferior:

2015-02-22_10-21-42

Al intentar iniciar la máquina, con esperanzas de que arrancara, recibí otro mensaje más que no me permitía continuar:

2015-02-22_10-20-42

The application encountered an error while attempting to change the state of DC-MED

DC-MED failed to restore virtual machine state.”

Hyper-V no me permitía hacer ninguna otra operación como reiniciar, apagar, volver a un punto anterior, etc, así que estaba completamente confundido.

La causa

Lo primero que hice fue correr Process Monitor, reproducir el mensaje y sobre el resultado, buscar qué referencias existían a el nombre para mostrar de DC-MED; esto fue lo primero –y lo único- que encontré:

2015-02-22_12-09-07

Si hacen clic en la captura y la ven al detalle, se está ejecutando el proceso de VMConnect.exe con una línea de comandos que identifica el nombre del host, nombre para mostrar de la máquina virtual, el GUID y el conteo de instancias que se están corriendo.

El resultado de esta operación se muestra como satisfactorio, así que no había problemas con lo que necesitaba Hyper-V para lanzar las máquinas virtuales. ¿Qué faltaba entonces?

Recordé que siempre que dejo alguna máquina virtual prendida y ejecutándose, sin importar el reinicio o apagado del equipo, están disponibles al entrar a la consola de administración de Hyper-V. Esto me llevaba a pensar que debía existir algún proceso recién se inicia sesión; la forma de averiguarlo, era habilitando la característica de Boot Logging incluida en Process Monitor.

Después de habilitarla, reiniciar la máquina y correr Process Monitor para guardar el log recopilado por el controlador, busqué las operaciones que existieran sobre el GUID correspondiente a mi virtual DC-MED y esto fue lo que encontré:

2015-02-22_18-56-59

Básicamente, el proceso vmms.exe, correspondiente a Virtual Machine Management Service, estaba abriendo un archivo con nombre BD2D3238-2536-4131-9376-383B8959D52A.vmcx, ubicado en la ruta:
C:\ProgramData\Microsoft\Windows\Hyper-V\Virtual Machines Cache\

Noten que la disposición era para abrir el archivo, pero el acceso deseado (Desired Access), contenía requerimientos para leer, listar, escribir, agregar, entre otros… Esto quiere decir que leía algo del archivo para poder inicializar las máquinas virtuales y, al llamarse la carpeta caché, podía indicar que utilizaba esta información contenida en el archivo para arrancar más rápido los equipos. Técnicamente además, la extensión .vmcx hace referencia a archivos de configuración para cada VM, así que naturalmente estaban todos .vmcx de las virtuales creadas en ese mismo directorio.

Procedí entonces a realizar una copia de ese archivo en mi escritorio y a abrirlo con el bloc de notas de Windows. No es mucho lo que pudiera leer, pero solo necesité de la siguiente porción de texto contenida:

2015-02-22_10-30-54

El archivo tenía en sus datos el directorio donde efectivamente se encontraba el disco duro virtual de mi virtual (2K12R2-AD.vhdx), y además la letra de unidad desde donde había podido acceder por última vez; en mi caso, referenciaba a la letra E:\.

Al verificar en mi Explorador de Archivos, me di cuenta del pequeño problema:

2015-02-22_10-37-36

La letra de unidad que me había asignado Windows la última vez que conecté mi disco externo, había sido la F y no la E que buscaba el archivo de configuración ubicado en la carpeta Caché de las máquinas virtuales. ¡Ahí estaba el problema! Hyper-V tenía en su memoria una ubicación diferente de cada disco virtual y al no encontrarla, se quejaba y le era imposible inicializar los equipos nuevamente.

La solución

Aunque no lo hice, se supone que cambiando la letra de unidad en el archivo de configuración a la F y reiniciando, el problema se habría corregido, puesto que encontraría todos los recursos necesarios; sin embargo, tendría que modificar cada .vmcx y no lo consideraba muy práctico.

La forma más fácil para solventar el tema, era volviendo a asignar la letra E a la partición que contenía los discos virtuales; para hacer esto de forma gráfica, hay que seguir estos pasos:

1. Hacer clic derecho en el botón de Inicio y seleccionar Administrador de Discos:

2015-02-23_7-38-01

2. En la consola de Administración de discos, hacer clic derecho sobre la partición o disco que se desea modificar y seleccionar Cambiar rutas y letra de unidad:

2015-02-23_7-39-52

3. En la ventana para cambiar la letra y ruta, clic en el botón Cambiar, y en Asignar la siguiente letra de unidad, poner la que debe corresponder; para mi caso, tenía que ser la letra E. Clic en Aceptar (OK):

2015-02-23_7-42-10

Windows advertirá sobre el peligro de cambiar la letra para programas que ya la estén referenciando y la necesidad de reiniciar:

2015-02-23_7-45-27

2015-02-23_7-47-32

Al aceptar ambos mensajes, veremos el cambio en el Administrador de Discos:

2015-02-23_7-48-16

4. Reiniciar el equipo.

Cuando hice los pasos anteriores y ejecuté Hyper-V después del reinicio, mis máquinas estaban de vuelta y listas para utilizar:

2015-02-23_7-54-48

¡Problema solucionado!

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

Saludos.

Checho

Crear imagen maestra de Windows 8.1 manualmente

Hace ya un par de años aproximadamente, escribí un artículo donde describí cómo crear una imagen maestra de Windows 8, pero teniendo presente además un perfil predeterminado. Debido a que el tema de la imagen maestra por ese artículo y algunos otros que tuve con Windows 7, y gran cantidad de dudas que muy amablemente me han hecho llegar, he decidido escribir este post donde me enfocaré única y exclusivamente al proceso de la imagen maestra, sin tener en cuenta otros aspectos.

El artículo estará enfocado a Windows 8.1, y trataré de detallarlo lo que más pueda, con el fin de aclarar dudas y sea fácil de seguir; como dato adicional, utilizaré nombres y rutas específicas, que pueden cambiar a preferencia si se sienten cómodos.

Requerimientos:

1) Necesitamos DOS máquinas que pueden ser físicas o virtuales. los nombres que utilizaré para diferenciarlas durante todo este post, será: WIN811 y WINP2; a continuación detallaré para qué es necesario cada una:

WIN811: Esta máquina –virtual o física-, tendrá instalado Windows con todo lo que deseen integrar en la imagen maestra; es decir, actualizaciones descargadas y aplicaciones como Office, por ejemplo (Ver captura después del párrafo). Del equipo WIN811, es donde se hará el proceso de resellado y captura de imagen. Como dije anteriormente, cada quien puede tener nombre diferente, pues yo solo lo hago para que puedan diferenciar.

2015-01-24_12-52-18

WINP2: En esta máquina –virtual o física-, es donde se instalará la última versión oficial del ADK (Ver: “Instalación del ADK”), para generar el Windows PE que se utilizará con el fin de capturar la imagen maestra en WIN811, y se creará después la imagen .ISO de instalación.

Deben descargar en el equipo WINP2 el paquete de instalación del ADK desde la web oficial de Microsoft: http://www.microsoft.com/es-ES/download/details.aspx?id=39982

*Nota: Personalmente, recomiendo que los equipos sean virtuales, puesto que se pueden recuperar más fácil si hay algún error y la imagen será mucho más limpia y neutra. El equipo donde se vaya a instalar el ADK es más viable que sea físico, pues sólo se utilizará para hacer las operaciones correspondientes para crear la imagen.

2) Los archivos de instalación que vienen en el medio o imagen .ISO de Windows 8.1. Técnicamente, en caso de que no los tengan, se podría utilizar los que trae un medio de evaluación disponible en TechNet para descargar:
http://www.microsoft.com/en-us/evalcenter/evaluate-windows-8-1-enterprise

3) En el equipo WINP2, crear una carpeta en la unidad C:\ llamada: W81. Allí debemos copiar los archivos de instalación del medio descargado o adquirido en el paso anterior; para esto, insertamos el DVD o montamos la imagen .ISO y posteriormente copiamos desde la consola todos los archivos. (Ver: “Copiando archivos de instalación”).

4) Mucha paciencia: Cada proceso puede tardar un buen rato, todo depende de los recursos que tengan las máquinas donde estemos trabajando.

Instalación del ADK (WINP2):

En el equipo WINP2 donde se descargó el ADK, ejecutar el adksetup.exe, y navegar en las páginas del asistente hasta llegar a Seleccione las características que desea incluir en la instalación; allí debemos escoger lo siguiente:

- Herramientas de implementación.
- Entorno de preinstalación de Windows (Windows PE).
- Herramienta de migración de estado de usuario (USMT) – Opcional.

2015-01-24_14-58-50

Clic en el botón Instalar para iniciar la instalación de los componentes.

Copiando archivos de instalación (WINP2):

Cuando hayamos insertado el medio de instalación, o montado la imagen .ISO de Windows 8.1 en el equipo WINP2, hacemos clic derecho en el botón de Inicio y seleccionamos: Símbolo del sistema (administrador).

En la consola, identificamos primero la unidad donde están los archivos, y ejecutamos:

xcopy <UnidadWin>\*.* /s/e/f C:\W81

Donde <UnidadWin> corresponde a la unidad en la que están los archivos de instalación; por ejemplo, si es la D, el comando sería:

xcopy D:\*.* /s/e/f C:\W81

2015-01-24_15-40-35

La carpeta debería verse así:

2015-01-24_21-51-22

Habilitando cuenta de administrador integrado (WIN811)

Es recomendable resellar el equipo con la cuenta de administrador integrado y eliminando todas las otras cuentas existentes; de esta forma, la imagen quedará limpia de cuentas innecesarias.

En WIN811, clic derecho en el botón de Inicio y Símbolo del sistema (administrador).

En la consola, ejecutamos:

Net User Administrador /Active:Yes

2015-01-25_9-35-28

Cerramos sesión con ese usuario e iniciamos sesión con el Administrador integrado.

Nuevamente, clic derecho en el botón de Inicio y Símbolo del sistema (administrador).

No es obligatorio, pero considero necesario eliminar todas las demás cuentas locales para que en cada instalación solo exista la que el usuario cree y así la imagen esté lo más limpia posible.

Pueden eliminar las cuentas desde el Panel de Control, pero si quieren hacerlo rápido, basta con saber el nombre de las que existen y proceder a quitarlas desde la consola. Por ejemplo, para mi caso que tengo una cuenta llamada Checho y otra Andy, los comandos serían:

Net User Checho /DELETE

2015-01-25_9-55-22

Net User Andy /DELETE

2015-01-25_9-55-50

Dejamos la sesión de Administrador activa para las próximas operaciones en WIN811.

Creando entorno de preinstalación (Windows PE) – WINP2

En el equipo WINP2, es decir, en donde se instaló el ADK, buscamos desde la Pantalla de Inicio Entorno de herramientas de implementación y creación de imágenes, clic derecho y Ejecutar como administrador:

2015-01-24_16-06-12

Desde la consola, vamos a crear un Windows PE de acuerdo a nuestra arquitectura:

Si van a capturar un equipo de 32 bits, ejecutan:

copype x86 C:\WinPE

2015-01-24_22-02-30

Si van a capturar un equipo de 64 bits, ejecutan:

copype AMD64 C:\WinPE64

2015-01-24_22-09-02

Para este artículo, yo voy a capturar un equipo de 64 bits, así que me aplica el segundo comando.

Después de copiar todo, deben tener una carpeta llamada WinPE o WinPE64 según sea el caso en la raíz del disco local:

2015-01-24_22-10-12

*Nota: En lo que resta del artículo, trabajaré refiriéndome a WinPE64 porque fue el que creé, así que ahí tendrás que modificar en caso de que hayan creado el de 32 bits.

Generar imagen ISO

Abrimos nuevamente el Entorno de herramientas de implementación y creación de imágenes –si es que habíamos cerrado la consola- y ejecutamos:

MakeWinPEMedia /ISO <DirWPE> C:\WinPE64.iso

Donde <DirWPE> se refiere al directorio del Windows PE creado; en mi caso, como fue el de 64 bits, sería:

MakeWinPEMedia /ISO C:\WinPE64 C:\WinPE64.iso

2015-01-24_22-18-33

Nos debe quedar una imagen creada llamada: WinPE64.iso en la raíz del disco:

2015-01-24_22-23-17

Esa es la imagen que utilizaremos para cargar el equipo WIN811, así que la debemos grabar en algún medio DVD/USB si es que estamos sobre equipos físicos, o pasarla en imagen .ISO en caso de que estemos trabajando sobre máquinas virtuales.

Resellando equipo – WIN811

En el equipo WIN811, que es donde está instalado Windows, Office, las actualizaciones y todo lo que deseamos tener en la imagen maestra, vamos a proceder a resellar con el fin de limpiar todas las asociaciones propias de hardware, el SID y dejar listo para capturar. Para resellar el equipo, hacemos lo siguiente:

1. Cerramos todas las aplicaciones que estén corriendo.

2. Clic derecho en el botón de Inicio y seleccionamos Símbolo del sistema (administrador).

3. En la consola, ejecutamos:

cd sysprep

sysprep /OOBE /Generalize /Shutdown

2015-01-25_10-00-17

El proceso de resellado iniciará y debemos dejar el equipo tranquilo hasta que termine y se apague automáticamente:

2015-01-25_10-05-00

*Nota: Si por alguna razón cerramos, o el Sysprep falla, es poco probable que se pueda arreglar el problema, así que normalmente hay que restaurar el equipo a un estado antes de correr el resellado.

Capturando el equipo – WIN811

Una vez apagado el equipo, debemos iniciarlo pero desde el DVD o USB con el Windows PE creado en los pasos anteriores desde el WINP2. Si estamos en máquinas físicas, hay que insertar el medio (DVD o USB), iniciar el menú de arranque de acuerdo al modelo, o bien entrar en la BIOS y escoger cuál debe ser el primer dispositivo en iniciar.

Para Hyper-V

Si estamos en máquinas virtuales, específicamente en Hyper-V, podemos simplemente cargar el equipo WIN811 con la imagen ISO que creamos en el WINP. En Hyper-V, basta con ir al menú Medio > Unidad DVD > Insertar disco…

2015-01-26_14-32-08

En la ventana de abrir, escogemos el Windows PE (WINPE64.iso) copiado de WINP2 y aceptamos:

2015-01-26_14-34-31

Luego, clic en el menú Archivo > Configuraciones.

Nos paramos en Firmware y nos aseguramos que esté arrancando desde DVD:

2015-01-26_14-36-15

Al iniciar el equipo, nos debe pedir presionar tecla para arrancar desde el medio –si fue con el DVD- y estaremos frente a una consola dentro del ambiente de preinstalación:

2015-01-26_14-38-39

Antes de capturar, es necesario identificar con exactitud qué letra tiene la partición de Windows, pues no siempre mantiene la C. Para esto, ejecutamos:

Diskpart

List volume

Esto nos listará todas las particiones y su detalle, para que cada uno referencie el volumen donde está instalado Windows:

2015-01-26_14-41-40

Tal cual ven en la imagen, el volumen , con letra C en mi caso, es la partición donde sé que está instalado el sistema operativo. Con esto, solo ejecutamos Exit para salir.

2015-01-26_14-46-25

*Nota: Tengan presente que la letra de unidad puede variar en cada caso, así que la deben identificar antes de continuar.

Para finalmente capturar la imagen, ejecutamos:

Dism /Capture-Image /ImageFile:<UnidadDes>:\install.wim /CaptureDir:<UnidadOr>:\ /Name:"Windows 8.1 PRO + Office" /Description:"Windows 8.1 PRO + Office"

Donde <UnidadDes> corresponde a la partición, ruta de red o destino que va a tener nuestra imagen capturada y <UnidadOr> es la letra de la unidad que vamos a capturar. Por ejemplo, en mi caso que la quiero guardar en la misma unidad C del WIN811 y que es esa misma unidad la que voy a capturar, el comando sería:

Dism /Capture-Image /ImageFile:C:\install.wim /CaptureDir:C:\ /Name:"Windows 8.1 PRO + Office" /Description:"Windows 8.1 PRO + Office"

2015-01-26_14-55-25

*Nota: Todo se escribe en una sola línea.

Cuando llegue al 100%, cerramos la consola y dejamos que el equipo –en mi caso WIN811- se reinicie completamente, ingresando de nuevos los datos del primer arranque ocasionados por haber resellado el equipo. Una vez iniciada la sesión, debe estar nuestra imagen capturada con el nombre de install.wim:

2015-01-26_15-22-49

Generando imagen ISO – WINP2

Desde el equipo WIN811, copiamos la imagen capturada (install.wim) al equipo WINP2 y luego la remplazamos por la del medio original en C:\W81\Sources\

2015-01-26_15-36-05

En la carpeta C:\W81\Sources, nos debe quedar entonces el install.wim recién capturado.

Para crear la imagen .ISO, buscamos Entorno de herramientas de implementación y creación de imágenes, clic derecho y Ejecutar como administrador:

 2015-01-24_16-06-12

Desde la consola, ejecutamos en una sola línea:

Oscdimg -bootdata:2#p0,e,bC:\W81\boot\Etfsboot.com#pEF,e,bC:\W81\efi\microsoft\boot\Efisys.bin -u1 -udfver102 C:\W81 C:\Win81PRO_with_Office.iso

2015-01-26_15-50-48

*Nota: Recomiendo hacer clic en la imagen para verla en tamaño real y escribir bien todo.

Lo anterior nos creará una imagen .ISO lista para instalarse en equipos con Legacy BIOS y con UEFI BIOS:

2015-01-26_15-56-28

Probando instalación – Cualquier equipo

Naturalmente, el paso final es grabar la imagen .ISO en un DVD o preparar un dispositivo USB para hacer la instalación y ver que no haya errores durante el despliegue:

2015-01-26_16-07-00

Traté de que este post estuviera lo más detallado posible, así que espero sea de utilidad.

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

Saludos.

Checho

El mensaje de «Error al cargar la secuencia de comandos D:\bin.doc» al iniciar sesión, Process Monitor y su solución

El caso que pasaré a describir, ha sido uno de los más duros que he logrado resolver, y me gustaría compartirlo aquí, porque es uno de los que empieza a tener mucha frecuencia en los foros de soporte de Microsoft. Como suelo hacerlo, mostraré el problema, la posible causa según toda la investigación hecha y su solución.

El problema

Todo nació en un hilo de los foros de Windows 7 en Microsoft Community; aunque era el mismo problema, la solución resultó ser bastante diferente.

Básicamente, cada que el usuario iniciaba sesión en su Windows 7, el siguiente mensaje de error aparecía:

2015-01-18_13-25-59

«Error al cargar la secuencia de comandos “D:\bin.doc“ El dispositivo no está listo

Inglés: «Loading script “D:\bin.doc” failed (The device is not ready.)»

Después de hacer clic en el botón Aceptar, el mensaje desaparecía y no habían más comportamientos extraños en el sistema operativo, por lo menos hasta el siguiente reinicio o cierre de sesión.

El problema solo afectaba a ese usuario en particular, y se volvía bastante molesto tener que aceptar el mismo mensaje cada que iniciaba sesión.

La causa

La recomendación que doy siempre en este tipo de casos, es identificar todo lo que esté iniciando con el usuario, debido a que es muy común que aplicaciones dejen basura en el sistema y Windows intente arrancar algo mientras el usuario ingresa.

Para poder ver esto y a causa de que el Administrador de Tareas de Windows sirve poco o nada, le pido al usuario que utilice Autoruns de SysInternals para poder gestionar correctamente lo que verdaderamente está arrancando. Como no es muy normal que un usuario que pide ayuda sepa utilizar este tipo de herramientas, hago que cargue el log, lo guarde y después de lo envíe.

Volviendo al caso y una vez obtenido el log de Autoruns, pensé que iba a encontrar alguna entrada en amarillo en la pestaña de Logon o de Scheduled Tasks que tuviera algún nombre extraño y buscara el archivo bin.doc, pero no fue así.

Era muy extraño que Autoruns no hubiese podido identificar la entrada, pero como no encontré nada, procedí a pedirle el log de Process Monitor, utilizando la característica de Boot logging; de esta forma, podría monitorear lo que sucedía en Windows mientras el usuario iniciaba sesión, así que necesariamente tendría que ver algún rastro de ese mensaje.

*Nota: Boot Logging, como lo he mostrado en otras entradas, permite decirle a Process Monitor que ubique su controlador antes que cualquier otro cuando está prendiendo el equipo, así que puede recolectar todo lo que sucede en el proceso de encendido de Windows y ver cosas que sólo ocurren mientras se ingresa desde la pantalla de inicio de sesión. Para activar esta característica, hay que ir al menú Options > Enable Boot Logging.

Cuando tuve el log de Process Monitor, busqué inmediatamente por el “bin.doc” y en toda la traza que recolectó, encontré solo tres entradas al respecto:

2015-01-20_20-53-12

Básicamente, el proceso de Explorer.exe de Windows, estaba creando, o más bien instanciando el proceso de wcript.exe y después, en la segunda entrada, iniciaba Windows iniciaba ese proceso directamente.

Al entrar en las propiedades del primer evento que muestra la captura haciendo doble clic en la entrada desde Process Monitor, me encontraba con que el Explorer.exe además de iniciar el proceso wscript.exe, le mandaba unos parámetros específicos donde incluía ejecutar el archivo: bin.doc.

2015-01-20_20-58-28

Los parámetros, como lo ven en la captura, eran:

“C:\Windows\System32\wscript.exe” /e:VBScript.Encode D:\bin.doc

La primera parte llamaba el proceso de wscript.exe y luego intentaba ejecutar el script. Debido a que ese archivo no existía en el equipo del usuario afectado, la ejecución fallaba y Windows mostraba el mensaje de error de Windows Script Host.

Si ejecutaba esa línea en cualquier equipo, recibía un mensaje muy similar al del error:

2015-01-20_21-09-15

Con eso pude comprobar que era la creación y ejecución de ese proceso con la línea extraña la que generaba el mensaje de error; sin embargo, esto no me decía la razón por la cual el proceso de Explorer.exe resultaba llamando a wscript.exe y menos aún, por qué le enviaba ese parámetro.

Después de darle vuelta un par de días, decidí mirar en detalle todos los eventos que ocurrían antes de que se instanciara el proceso de wscript.exe, y luego de varias líneas, encontré algo de lo que no me había percatado anteriormente:

2015-01-20_21-13-29

Como ven en la captura –si hacen clic en ella para el tamaño real-, Windows estaba leyendo un curioso archivo llamado Start.lnk, ubicado en la ruta:

C:\Users\Ure\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\

Lo interesante aquí, es que todo lo que se encuentre en la carpeta Startup, se ejecutará automáticamente en cada inicio de sesión y el nombre del archivo no parecía muy normal.

Decidí entonces pedirle al usuario que me navegara hasta esa ruta y me enviara el archivo sin eliminarlo y al ingresar a sus propiedades –debido a que era un acceso directo-, me encontré con una grata sorpresa:

2015-01-20_21-19-13

El acceso directo, ubicado en esa carpeta, estaba lanzando la ejecución del proceso wscript.exe, con sus respectivos parámetros.

Ahora, ¿Por qué Process Monitor identificaba a Explorer.exe como el proceso que llamaba a wscript.exe para hacer la ejecución? Pues bien, Explorer.exe es el primer proceso que carga al iniciar sesión y es el proceso padre que ejecuta todo lo que esté en los respectivos directorios; debido a que Start.lnk era un archivo dentro de una carpeta predestinada para lanzarse en cada inicio, era Explorer.exe el responsable de esta ejecución.

Ya sabía dónde estaba ubicado el archivo responsable, por qué iniciaba con el usuario y por qué se ligaba a un proceso del sistema operativo. Mi último paso, era solucionarlo.

La solución

Para solventar el problema, bastó lo siguiente:

Primero que todo, le pedí al usuario navegar hasta la ruta:

C:\Usuarios\Ure\AppData\Roaming\Microsoft\Windows\Menú inicio\Programas\Inicio

*Nota: Si tienen el mismo problema, la ruta será igual, pero variará el nombre de usuario.

Segundo, que hiciera clic derecho sobre el archivo de Start.lnk y Eliminar.

*Nota: Es probable que no siempre tenga el mismo nombre, pero casi siempre será un acceso directo.

Tercero, le pedí reiniciar el sistema y después de esto, el mensaje de error se había ido.

Notas finales

La razón por la que Autoruns no muestra este tipo de entradas, es porque las considera como de Windows al llamar ejecutables conocidos y este tipo de entradas están ocultas de forma predeterminada en Autoruns. Basta ir al menú Options > Filter Options y quitar la selección sobre: Hide Microsoft entries y Hide Windows entries.

2015-01-20_22-03-51

Por otro lado, me di cuenta después que el archivo se habría podido identificar desde Process Explorer, accediendo a las propiedades del Windows Script Host mientras estuviera en ejecución:

2015-01-20_21-59-11

Espero haber sido de utilidad.

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

Saludos.

Checho

Mostrar todos los usuarios disponibles antes de iniciar sesión en Windows 8/8.1

Uno de los cambios pequeños que tuvo el comportamiento de inicio de sesión en Windows 8/8.1, es que siempre intentará arrancar con el último usuario que estuvo activo en el sistema; aunque puede ser útil si solo tenemos un usuario, no es tan entretenido si es un equipo compartido en el que cada determinado tiempo un nuevo usuario requiere iniciar sesión.

La pregunta del cómo decirle a Windows que muestre todos los usuarios antes de iniciar sesión, tiene cierta frecuencia en los foros oficiales de Microsoft Community así que después de indagar un poco al respecto, decidí documentar el procedimiento paso a paso para que en cada inicio de sesión se deba escoger el usuario y el sistema operativo no lo haga de forma automática.

El objetivo del post, es ver el inicio así:

2015-01-07_11-33-12

Como ven, la idea es siempre poder escoger el usuario antes de ingresar las credenciales.

Cada vez que Windows inicia, o se va a la pantalla de inicio de sesión cerrando o bloqueando sesión, el sistema operativo busca el estado de un valor llamado Enabled en la clave:
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\LogonUI\UserSwitch

Process Monitor puede dar fe de ello:

2015-01-07_11-21-41

Si el valor Enabled está habilitado, es decir, tiene uno como contenido, Windows siempre mostrará todos los usuarios antes de iniciar sesión, pero normalmente este valor está en cero, o sea deshabilitado:

2015-01-07_11-29-03

Normalmente bastaría con habilitarlo y listo, pero en este caso, aunque le pongamos el contenido de de uno, se volverá a cambiar a cero en cada inicio de sesión. ¡Ahí el problema!

Si bien se podrían editar los permisos para prohibirle al usuario SYSTEM, que es responsable, se generarían problemas después para que Windows entienda otros cambios que se deben hacer sobre la clave de registro.

Lo que haremos a continuación, será automatizar el cambio del contenido de la clave, así en cada inicio de sesión tendrá el comportamiento esperado.

Automatizando el cambio de clave en Registro

Lo primero que haremos, será abrir un blog de notas en limpio y escribir el siguiente comando:

REG ADD HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\LogonUI\UserSwitch /v Enabled /t REG_DWORD /d 1 /f

Todo es una sola línea:

2015-01-07_11-41-39

Lo que hace el comando es básicamente escribir uno en el valor Enabled.

A continuación, clic en Archivo > Guardar como y lo ponemos en una ubicación donde podamos escribir como en el Escritorio. El nombre será: EnaUsr.bat

2015-01-07_11-45-20

Después de esto, movemos el archivo manualmente al disco local C:\

Debería quedar entonces en C:\EnaUsr.bat

2015-01-07_11-48-32

Ese archivo siempre pondrá el contenido de uno sobre el valor cada que se llame; ahora necesitamos una forma de poder llamarlo siempre y que funcione sin mayor inconveniente. La forma más fácil para hacer esto, es a través de una Tarea Programada.

Antes que nada, es necesario que en el Registro de Windows, el cambio de contenido a uno esté por lo menos la primera vez antes de proceder al Programador de Tareas, así que hacemos clic derecho sobre EnaUsr.bat y seleccionamos Ejecutar como administrador:

2015-01-07_12-28-24

Para verificar, abrimos el Registro de Windows desde la Pantalla de Inicio (Regedit.exe) y navegamos hasta:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\LogonUI\UserSwitch

El valor de Enabled, debe estar en uno:

2015-01-07_12-30-46

Hecho esto, procedemos a crear la tarea:

Creando la Tarea Programada

Desde la Pantalla de Inicio, escribimos Programar tareas y lo ejecutamos:

2015-01-07_11-55-08

En la ventana de Programar tareas, clic en Crear tarea en el panel derecho:

2015-01-07_11-56-33

En la pestaña de General, escribimos un nombre, por ejemplo: Mostrar usuarios y luego una descripción que explique el propósito de esta tarea:

2015-01-07_12-00-29

Después, en la parte inferior de la misma pestaña, cambiamos a Windows 8.1 el Configurar para:

2015-01-07_12-03-03

Como necesitamos que esta tarea se ejecute independiente del usuario que inicie sesión, es necesario decirle al Programador de Tareas que siempre utilice el usuario de SYSTEM; para esto, hacemos clic en el botón Cambiar usuario o grupo en la misma pestaña de General, copiamos SYSTEM y clic en Aceptar:

2015-01-07_12-08-37

La pestaña de General debería verse así:

2015-01-07_12-10-34

Pasamos a la pestaña de Desencadenadores y clic en el botón Nuevo:

2015-01-07_12-13-44

Al lado de Iniciar la tarea, escogemos Al iniciar la sesión y clic en Aceptar:

2015-01-07_12-17-14

Pasamos a la pestaña de Acciones y hacemos clic en el botón Nueva:

2015-01-07_12-19-03

En la ventana de Nueva acción, dejamos la opción de Iniciar un programa que está de forma predeterminada, hacemos clic en el botón Examinar, buscamos nuestro archivo por lotes ubicado en C:\EnaUsr.bat y clic en Aceptar:

2015-01-07_12-20-41

¡Todo listo! De vuelta en la ventana de Crear tarea, hacemos clic en Aceptar para terminar y cerrar.

En la ventana de Programador de tareas, al pararnos en el nodo de Biblioteca del Programador de tareas, deberíamos poder ver nuestra tarea creada en el panel central:

2015-01-07_12-23-58

Cerramos el Programador de tareas y habremos terminado. Lo único que queda, es reiniciar el equipo por lo menos dos veces y ver que en efecto, siempre debamos escoger nuestro usuario de la lista disponible sin importar con quién iniciemos y reiniciemos:

2015-01-07_12-34-53

Espero haber sido claro y que sea de utilidad.

Saludos.

Checho

Gestionar aplicaciones de inicio automático en Windows utilizando Autoruns

En el mes pasado de diciembre, escribí un post donde detallé un poco cómo podríamos identificar cambios en el Registro de Windows al aplicar directivas de grupo haciendo uso de Process Monitor; hoy, siguiendo ese camino, quiero documentar otro caso práctico útil, pero esta vez usando la herramienta de Autoruns, también de Windows Sysinternals.

Introducción a Autoruns

Autoruns, otra de las grandes herramientas de Sysinternals, nos permite administrar todo lo que en verdad está iniciando de forma automática con Windows; esto incluye las aplicaciones que arrancan asociadas al usuario, controladores, servicios, tareas programadas, extensiones del Explorador de archivos, entre varias otras.

Así se vería Autoruns después de iniciado:

2014-12-23_20-02-12

Básicamente, Autoruns se compone de una barra de menús, una de comandos para tareas comunes como la de búsqueda o la de actualización, unas pestañas que indican los tipos de inicio que puede detectar y finalmente un cuadro central donde muestra todo el contenido agrupado en varias columnas para describir adecuadamente cada entrada.

Ahora, ¿Por qué no utilizar MSCONFIG (Windows 7), o el Administrador de Tareas (Windows 8 y posteriores)? Pues bien, haciendo una comparación con el Administrador de Tareas, esto es lo que se vería en mi equipo por ejemplo:

2015-01-02_19-37-28

Según Windows, en mi usuario sólo están iniciando cuatro aplicaciones, todas habilitadas.

Si utilizo Autoruns y me voy a la pestaña de Logon, que corresponde al inicio de cada usuario, podré ver lo que realmente está iniciando:

2015-01-02_19-40-10

Como ven, no solo tengo más entradas, sino el detalle de cada una, así que puedo ver fácilmente la ubicación que tiene en el Registro de Windows, el editor, la ruta física y el tiempo que se está tardando en iniciar cada entrada. Por supuesto, puedo saber si está o no habilitada mirando el cuadro de selección que está a la izquierda.

Personalmente, encuentro Autoruns muy importante para tres cosas:

1. Acelerar el arranque de Windows: Al desactivar o eliminar las entradas identificadas (ver la siguiente parte del post), enfatizando en la pestaña de Logon, podremos mejorar notablemente el tiempo en que tarda el sistema operativo para estar funcional en nuestro usuario.

2. Identificar y quitar Malware: Gracias a que Autoruns tiene la capacidad de identificar muchísimas rutas donde una aplicación, archivo o script puede ubicarse para iniciar con Windows, podremos fácilmente llegar a reconocer software malicioso que esté actuando en nuestro equipo; además, Autoruns incluye una característica de verificación para saber si las firmas digitales son legítimas, tal cual lo hace Process Explorer.

3. Solucionar problemas críticos de Windows al iniciar: Como lo he mostrado en otros artículos, como el del constante pantallazo azul causado por un bug en el controlador de Windows, Autoruns se puede ejecutar desde un Entorno de Preinstalación (Windows PE) y evitar que los controladores, programas o archivos inicien en el sistema, sin tener que entrar a Windows.

Identificando y desactivando/eliminando entradas

Primero que todo, existen tres colores que predominan en las entradas que muestra Autoruns:

1. Color blanco: Corresponden a entradas que existen en el sistema, que pueden estar ejecutándose al inicio (depende si están habilitadas) y que además tienen una firma digital verificada. Por ejemplo:

2015-01-02_20-00-26

2. Color rosa: Estas entradas muestran programas, controladores, scripts o cualquier otra cosa que Autoruns identifica, que existe en Windows, puede estar habilitada o no, pero que la firma digital no se puede comprobar. Ejemplo:

image

3. Color amarillo: Toda entrada que esté en amarillo, quiere decir que está habilitada para iniciar en cada arranque de Windows, pero que el sistema operativo no encuentra su ubicación física; estas son los tipos de entradas que causan mensajes extraños que aparecen al iniciar sesión. Ejemplo:

2015-01-02_20-12-38

En mi experiencia usando Autoruns, cuando estoy buscando respuestas utilizándolo, las entradas amarillas son las que primero presto atención. Por ejemplo, los mensajes extraños que aparecen, muchas veces causados por Crapware o Malware.

Finalmente, podemos desactivar o eliminar completamente el arranque de alguna aplicación con Windows desde Autoruns:

Para desactivar, simplemente entramos a Autoruns, vamos a la pestaña en la que identifiquemos la entrada, por ejemplo la de Logon y limpiar el cuadro de selección a la izquierda; debe quedar vacío:

2015-01-02_20-19-26

Por el otro lado, si lo que deseamos es eliminar la entrada por completo, basta con hacer clic derecho sobre la entrada y seleccionar Delete:

2015-01-02_20-22-43

Opcionalmente, se puede seleccionar la entrada y presionar Ctrl+D y luego aceptar el mensaje que aparece:

2015-01-02_20-25-02

Las dos pestañas que más nos sirven para solucionar problemas en el arranque, sobre todo con mensajes raros o software malicioso, son las pestañas de Logon y de Scheduled Tasks.

Como la mayoría de las veces los problemas lo causan aplicaciones de terceros, es buena idea esconder todas las entradas correspondientes a Microsoft y a Windows; para esto, vamos al menú Options y luego Filter Options…

2015-01-02_20-33-22

Seleccionamos: Hide Microsoft entries y Hide Windows entries y hacemos clic en Rescan para que Autoruns actualice:

2015-01-02_20-34-49

De esta forma, sólo veremos entradas que correspondan a terceros y seguramente será mucho más fácil identificar las entradas con el problema.

Esto es solo una pequeñísima parte de lo que es Autoruns, incluso tiene un capítulo entero en su libro oficial; pero, sin duda alguna estas tareas básicas resultan muy productivas.

Espero sea de utilidad y les deseo a todos un feliz año.

Saludos.

Checho

Identificar cambios en el Registro al aplicar una Directiva de Grupo en Windows utilizando Process Monitor

Desde que empecé a resolver problemas de Windows utilizando algunas herramientas de Sysinternals, he querido dedicar escritos únicamente al uso adecuado de ellas, pero explicarlas técnicamente no es tan sencillo, pues las mejores requieren fundamentos de Windows Internals para interpretar de la mejor forma sus resultados. Sin embargo, encuentro útil explicar un poco cómo usarlas con algunos casos prácticos, como el que pasaré a detallar en este post.

Si trabajan, o han trabajado con el mundo de las Directivas de Grupo, seguramente alguna vez les ha tocado indagado en la web qué clave y valores de Registro se crean para que Windows reconozca alguna directiva; incluso también para forzar configuraciones en ediciones de Windows que no se pueden unir a un dominio de forma predeterminada. La pregunta que probablemente les surge es: ¿De qué forma puedo aprender a buscar estos cambios en el Registro? Aquí la respuesta más fácil es, por supuesto, Process Monitor.

Introducción a Process Monitor

Process Monitor es una de las mejores herramientas entre las gratuitas y de pago, para monitorear TODO lo que sucede en Windows mientras estás funcionando con el sistema operativo; incluso lo que sucede antes de que se inicie sesión en el equipo. Con Process Monitor, es posible saber qué operaciones se están llevando a cabo, enfocado principalmente a sistema de archivos y Registro de Windows.

Al ejecutar Process Monitor, veremos de inmediato cientos de eventos suceder por debajo:

2014-12-03_13-19-13

A parte de los eventos, como lo ven en la captura, Process Monitor indica principalmente el proceso que está llevando a cabo la tarea, la operación que se está realizando, la ruta donde se está haciendo y lo más importante, el resultado obtenido.

En la barra de herramientas, debajo de todos los menús, verán el icono de Filtros, señalado también en la captura anterior; esta es una configuración fundamental cada que estemos buscando resultados en Process Monitor:

2014-12-03_15-33-35

En la ventana de Filtros, podremos escoger entre diferentes tipos como: Categoría, Operación, Ruta, Resultado, Usuario, etc; indicarle la condición que se compone de unas palabras claves como “es”, “contiene”, etc con un cuadro de texto para personalizar palabras claves o procesos (dependiendo del filtro) y finalmente decirle si queremos incluir o excluir ese filtro en los resultados de Process Monitor:

2014-12-03_15-42-06

Cada que personalicemos un filtro, hacemos clic en el botón Add para que se incluya en el resultado de Process Monitor y creemos más si queremos. Se pueden crear tantos filtros como deseemos; la clave está en lograr un resultado preciso y productivo.

Con esta mínima introducción, pasaré a mostrarles de qué forma podemos aprovechar estos filtros para reconocer las claves y valores de registros creados cada que se implementa una directiva de grupo.

Identificando claves y valores con Process Monitor

Como seguramente es bien sabido por ustedes, las directivas de grupo se aplican en el sistema operativo cuando se reinicia el equipo, o se fuerzan utilizando gpupdate; es en esos momentos cuando Windows es notificado del cambio y crea las respectivas claves y valores de Registro para que la configuración sea distinta.

*Nota: La mayoría de las directivas de grupo no son más que una clave y uno o más valores de registro, pero no siempre es así pues hay configuraciones más complejas que otras.

La forma más fácil para descubrir los cambios con Process Monitor, es habilitando la respectiva plantilla y monitorear el equipo cliente mientras se está haciendo la actualización con el gpupdate. Vamos a seguirlo en un ejemplo práctico:

1. Lo primero, es configurar la respectiva directiva de grupo desde el controlador de dominio, o bien localmente si se aplica como directiva local. Para este ejemplo, utilizaré una de las directivas que más generó interés con la salida de Windows 8.1 y es la posibilidad de ingresar directamente en el escritorio de Windows en vez de la Pantalla de Inicio.

La directiva está ubicada en:

User Configuration\Policies\Administrative Templates\Start Menu and Taskbar

Se llama específicamente: Go to the desktop instead of Start when signing in.

2014-12-03_8-07-54

*Nota: Obviamente no tiene que ser esa para que funcione el procedimiento.

2. A continuación, en el equipo cliente, hacemos clic derecho sobre el botón de Inicio (si estamos en Windows 8.1) y seleccionamos Símbolo del sistema (Administrador). Dejamos la consola abierta.

3. Procedemos a lanzar Process Monitor, presionamos CTRL + X cuando cargue para limpiar la primera traza y lo dejamos corriendo.

4. Ejecutamos desde la consola: gpupdate /force

2014-12-03_21-16-24

5. Volvemos a Process Monitor y hacemos clic en el icono de la lupa para detener el monitoreo. Nos debe aparecer una cruz roja sobre ella:

2014-12-03_21-18-40

6. En Process Monitor, con toda la información lista, hacemos clic en el icono de Filtro que mostré anteriormente, o vamos al menú Filter > Filter.

7. Esta es la parte más importante, pues aplicaremos los filtros para que toda esa tonelada de información se nos minimice al punto de identificar rápidamente lo que necesitamos.

Aplicando filtros

Debido a que son varios filtros y cada uno tiene su intención, los describiré uno por uno:

1. En el primer filtro le diremos a Process Monitor que nos muestre por categoría de escritura, operación que incluye crear claves y valores de registro; no nos interesan operaciones de lectura o consulta.

Para esto, escogemos en la primera selección Category, luego indicamos is en la segunda, seleccionamos Write en la tercera y finalmente clic en el botón de Add:

2014-12-03_21-35-56

Se darán cuenta que empieza a reducirse la cantidad de eventos mostrados, pero aún así faltan muchísimos, ¡Pero faltan más filtros!

2. En el segundo filtro, Process Monitor nos mostrará, los eventos de la categoría Write, que correspondan solo a la operación de RegSetValue, que representa la creación de valores de registro.

Para esto, escogemos en la primera Operation, luego is en la segunda, RegSetValue en la tercera y finalmente clic en Add:

2014-12-03_21-42-39

3. En nuestro tercer filtro, Process Monitor sabrá que las operaciones de escritura, correspondientes solo a creación de valores de registro, deberán mostrarse solo en lo que corresponda a HKEY_CURRENT_USER, es decir, al usuario que está autenticado.

Para esto, escogemos en la primera Path, luego begins with, escribimos HKCU en la tercera y clic en el botón Add:

2014-12-03_21-46-32

*Nota: Este tercer filtro tendrá sentido, solo si la directiva de grupo se creó debajo de User Configuration; de lo contrario, habrá que crear el mismo pero en vez de HKCU, indicar HKLM para especificar que la configuración es por máquina y no usuario.

4. Para el cuarto filtro, crearemos uno muy similar al anterior, pero esta vez indicaremos que nos filtre sólo la creación de valores para el usuario en claves de registro que contengan la palabra: Policies.

Para esto, escogemos nuevamente Path en la primera, luego contains en la segunda, para la tercera escribimos Policies y clic en Add:

2014-12-03_21-51-43

5. En el quinto filtro, le diremos que el proceso responsable para todas estas operaciones, debe ser únicamente svchost.exe.

Para lo anterior, escogemos en la primera Process Name, la segunda volvemos al is, seleccionamos svchost.exe en la lista de la tercera y clic en Add:

2014-12-03_21-59-38

Hasta este punto, deberíamos tener los filtros así:

2014-12-03_22-01-18

Hacemos clic en el botón Apply y después OK.

Sin embargo, hay un Filtro más que no sobra ponerlo y es excluir todo lo que se haga sobre HKLM, sin importar que el proceso corresponda a svchost.exe o sea una operación de RegSetValue.

Para esto, volvemos a la ventana de Filtros (CTRL + L), escogemos en la primera Path, en la segunda begins with, escribimos HKLM para la tercera, cambiamos el Include por el Exclude para la cuarta selección y clic en Add:

2014-12-03_22-04-02

Muy seguramente los eventos ya los podrán ver en una sola pantalla, sin ni siquiera deslizar la barra de desplazamiento hacia abajo, así que sería relativamente fácil identificar, por descarte, cuál es el valor que se crea al aplicar la directiva, puesto que suelen tener nombres representativos a la configuración.

Sin embargo, una forma en que podríamos quitar varios más, es decirle a Process Monitor que sólo muestre lo que se escribe en la sub-clave de Policies, excluyendo todo lo demás, así pertenezcan al proceso y se escriban sobre HKCU (En este caso).

Para esto, volvemos a los Filtros (CTRL + L), escogemos Path en la primera, contains para la segunda, escribimos Group Policy en la tercera, seleccionamos Exclude en la cuarta y clic en el botón Add nuevamente:

2014-12-03_22-14-05

Clic en Apply y OK.

Si todo esto salió bien, deberían tener un número muy reducido de resultados, tanto que a primera vista sabrían qué es lo que están buscando. Por ejemplo, en mi caso solo obtuve dos:

2014-12-03_22-17-01

Lo que sigue es simplemente deducir basados en el nombre de valor o valores. Por ejemplo, para mi caso que estaba aplicando una configuración que permitía ir al escritorio directamente al iniciar sesión y no pasar por la Pantalla de Inicio, el segundo valor con el nombre de GotoDesktopOnSignIn seguramente es más relevante que el primero:

2014-12-03_22-17-012

Ahora bien, ¿Qué pasa si quiero monitorear otras directivas? ¿Debo realizar otra vez todos los filtros? La respuesta es: ¡No!

Process Monitor es capaz de guardar los filtros, incluso después de cerrado; sin embargo, no es necesario cerrarlo y abrirlo para poder monitorear otra vez, basta con presionar las teclas CTRL + X o ir al menú Edit > Clear Display y proceder a actualizar las directivas desde una consola con gpupdate /force para ver los resultados en acción al terminar:

2014-12-03_22-35-07

*Nota: En la captura anterior, como pueden ver, tengo resultados de diferentes directivas.

Es importante denotar que debemos construir cuidadosamente los filtros dependiendo si es para User Configuration o Computer Configuration. En el primero, como dije anteriormente, corresponde a HKCU, pero en caso de ser el segundo, lo tendríamos que cambiar y adecuar a HKLM.

Sobra decir además que si se quiere llevar esas configuraciones a otro equipo, basta con entrar al Registro y exportar esas claves.

Espero con el tiempo y a medida coja más y más práctica con Process Monitor y otras herramientas de Sysinternals, traerles artículos similares.

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

Saludos.

Checho

El “Error en el Servicio de perfil de usuario al iniciar sesión…”, Windows PE, y su solución

Como ha sido costumbre desde años atrás, cada que me enfrento a un problema que resulta ser de lo más extraño, pero logro solucionarlo, me gusta documentarlo aquí para futuras personas que en algún punto lo tengan y resulten en el blog.

El problema

Hace unos días, un amigo vino a mi con un problema que había visto en algunas ocasiones de forma indirecta en los foros, pero nunca tuve la oportunidad de sentarme a investigarlo. Cuando intentaba iniciar sesión con el usuario local, aparecía el siguiente mensaje:

image

“Error en el servicio Servicio de perfil de usuario al iniciar sesión. No se puede cargar el perfil de usuario.”

*Nota: Es Windows 7 como lo ven, pero el mensaje no varía en versiones posteriores y la solución seguramente tampoco.

Después de dar Aceptar, aparecía Windows cerrando sesión y de nuevo estaba en la pantalla de inicio de sesión.

Como era un PC personal, no habían más cuentas de usuario creadas, ni el administrador integrado habilitado, así que no había mucho más para hacer en primera instancia.

La causa y su solución

La única manera que tenía de poder hacer más que aceptar un botón en vano, era encontrar la forma de poder realizar más tareas desde el escritorio del logon; así que procedí a utilizar un Entorno de Preinstalación para cargar desde él y remplazar el proceso sethc.exe con el de cmd.exe. De esta forma, podría ejecutar la consola de comandos desde la pantalla de inicio de sesión.

No entraré en detalle sobre cómo hacer este cambio, pues en un artículo pasado explico cómo hacerlo para cambiar la contraseña de Windows a la fuerza o crear nuevos usuarios:
http://geeks.ms/blogs/checho/archive/2013/09/07/cambiar-contrase-241-a-olvidada-para-recuperar-el-inicio-de-sesi-243-n-en-windows-8-8-1.aspx

*Nota: En TechNet Wiki, creé un artículo mostrando cómo generar el Windows PE de un forma más sencilla:
http://social.technet.microsoft.com/wiki/contents/articles/28497.how-to-crear-un-entorno-de-preinstalacion-de-windows-windows-pe-es-es.aspx

Después de crear el Windows PE, iniciar el equipo desde allí, hacer el cambio en el registro, iniciar Windows normalmente y presionar cinco veces la tecla SHIFT para lanzar la consola, ejecuté la consola de Servicios (Services.msc) y revisé el estado del servicio de perfil de usuario, pero no había problema alguno:

image

Incluso lo reinicié, pero aunque se completaba la operación, el mensaje continuaba saliendo.

Después de esto y pensarlo por un buen rato, recordé que cada perfil que va a iniciar en el sistema operativo, debe consultar una serie de recursos en su carpeta de Usuarios, incluyendo la disponibilidad de la ruta donde reside todo.

En la consola, ejecuté Regedit.exe para abrir el Editor de Registro y navegué hasta la clave:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList

En esta clave, se encuentran unas sub-claves correspondientes a todos los usuarios que están interactuando con el sistema operativo incluyendo cuentas como la de SYSTEM y NetworkService. Cada uno de los usuarios está representado por su identificador único o SID.

Las terminadas en 18, 19 y 20 siempre estarán; de ahí siguen las que pertenecen a usuarios locales que incluso son más grandes.

Para mi gran fortuna, aquí encontré la causa real del problema y la clave principal para la solución:

image

Explicando un poco mejor la imagen: El SID de cada usuario es único e irrepetible, pues con esto Windows lo identifica para muchísimas tareas. Cuando se duplica un SID, normalmente el sistema operativo intenta crear un usuario temporal para iniciar utilizando el mismo identificador y a la otra clave le asigna un .bak al final.

Como ven en la imagen, la clave que tenía extensión .bak se estaba refiriendo a la ubicación real del usuario, es decir, de Mery. El valor que guarda la ruta es ProfileImagePath.

La otra clave por el contrario, estaba referenciando una ubicación de usuario temporal y ni siquiera tenía todos los valores necesarios creados:

image

Como esta era la clave sin extensión, era la que el usuario Mery estaba utilizando, así que nunca iba a encontrar los recursos necesarios para iniciar sesión y ahí es donde salí el extraño error referenciando al servicio.

La solución entonces fue muy sencilla, debía eliminar la clave que NO tenía la extensión .bak; es decir, la que referenciaba al usuario TEMP y renombrar la otra clave con el mismo SID para quitarle la extensión .bak.

Después de esto, cerré el Editor de Registro, el CMD y reinicié el equipo. Una vez reiniciado, pude acceder al usuario sin ningún problema.

Espero que esto pueda ser de utilidad a los que se encuentren con el problema.

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

Saludos.

Checho

Mitigando problemas en compatibilidad de aplicaciones con ACT: El Shim de CorrectFilePaths

Como ya lo he mencionado en buena cantidad de artículos anteriores, una de las principales causas por la que una compañía detiene la migración a un nuevo sistema operativo es la compatibilidad de aplicaciones. Generalmente, las empresas tienen una dependencia fuerte por una cantidad pequeña de soluciones que fueron desarrolladas a medida y realizan procesos demasiado importantes como para prescindir de ellas.

Microsoft dispone, desde los tiempos de Windows Vista, de una cantidad de herramientas gratuitas para ayudar a mitigar la gran cantidad de problemas de compatibilidad existentes. Lamentablemente, en LATAM son poco conocidas estas herramientas, así que muchas veces las organizaciones optan por permanecer en una versión x de Windows.

Una de las mejores herramientas, es el Application Compatibility Toolkit (ACT); solución que entre muchas cosas más, nos permite crear Shims o arreglos que interceptan el llamado que hace la aplicación a Windows por algún recurso, y modifica el comportamiento para entregar lo que el software estaba buscando. En otros artículos he documentado el proceso para crear estos arreglos con problemas específicos como Canal+ Yomvi u Oracle 10g, pero hoy empezaré a concentrarme específicamente en la manipulación de los arreglos más comunes a utilizar.

Dicho esto, en este post hablaré lo que más pueda sobre el arreglo de CorrectFilePaths.

Escenario

Supongamos que tenemos una aplicación que intentará escribir unos archivos y te notifica:

image

Sin embargo, después de aceptar proceder, sucede un típico error inesperado y confuso:

image

Por supuesto, esta es solo una aplicación que escribí, así que solo muestra un mensaje y su error, pero en aplicaciones de línea de negocio, suele ocurrir algo similar en diferentes facetas, como durante la instalación, su ejecución o en algún módulo. Aún así, en esencia es el mismo problema: No poder crear o abrir archivos en determinado directorio de Windows.

Volviendo a este caso ficticio, mi aplicación está intentado crear el archivo DemoFile.txt pero recibe un error poco descriptivo, y que no sirve para nada. Es trabajo de la persona empezar a lidiar con este problema.

El shim de CorrectFilePaths

Este arreglo, que hace parte de los cientos disponibles en ACT, permite básicamente modificar una ruta existente de archivos y re direccionarla a otra ubicación sin tener que manipular el código de la aplicación de ninguna forma. Así pues, se mantiene la integridad sobre la aplicación, pero se manipula el comportamiento de los archivos que se escriben.

Predeterminadamente, el arreglo contiene varias correcciones predeterminadas; es decir, diferentes rutas que son direccionadas a otra ubicación una vez se aplica, pero además permite agregar nuevas rutas personalizadas así que es bastante flexible.

Consideremos la siguiente ilustración como el comportamiento predeterminado que debería existir entre la aplicación y Windows en este caso:

clip_image001[9]

*Nota: Aquí no estoy detallando dónde escribe la aplicación, porque aunque es importante, el comportamiento general es el mismo.

Ahora, en la siguiente gráfica muestro cuál es el cambio cuando intercede el arreglo (shim):

clip_image001[11]

Como ven, la aplicación pasa a tener un contacto indirecto y no directo con el sistema operativo cuando realiza esta operación. Aquí no se toca código ni nada por el estilo, solo se direcciona a las mismas funciones en un lugar diferente.

*Nota: Si quieren saber un poco más a fondo sobre los Shims, pueden ver este post.

¿Cómo utilizar CorrectFilePaths?

Para poder aplicar esta, o cualquier otra corrección, es necesario instalar el Application Compatibility Toolkit (ACT), que hace parte del ADK disponible desde el sitio Microsoft:
http://www.microsoft.com/en-US/download/details.aspx?id=39982

Una vez descargado, basta con ejecutar el adksetup.exe y en el asistente seleccionar ACT:

image

De nuevo en el escenario, lo primero que hay que identificar, es dónde está intentando escribir la aplicación que provoca el error. Para esto, no hay otra herramienta mejor que Process Monitor de Sysinternals.

Identificar este tipo de rutas es relativamente sencillo, basta con abrir ProcMon antes de la ejecución de la aplicación, reproducir el problema, presionar las teclas CTRL + F para abrir el cuadro de búsqueda y referenciar el archivo en cuestión; en este caso: DemoFile.txt.

image

El resultado para esta clase de problemas, sobre todo con aplicaciones hechas a la medida y con cierta antigüedad, es Acceso Denegado (ACCESS DENIED):

image

La razón de este tipo de resultados, es por los niveles de integridad que existen desde Windows Vista. No entraré en detalle, porque ese tema requiere un artículo completo.

El problema aquí es que el archivo DemoFile.txt está intentando escribir en un directorio protegido por Windows y que un usuario estándar no tiene privilegios, así que esto requeriría elevación, es decir, ser administrador. Como no queremos eso, procedemos a implementar la corrección de CorrectFilePaths para que la aplicación crea que sigue escribiendo en la raíz del disco, pero realmente escriba en un directorio por usuario.

Implementando el shim

Desde el equipo donde está instalado ACT, buscamos en la Pantalla de Inicio el Compatibility Administrator de acuerdo a la arquitectura de la aplicación y lo ejecutamos:

image

*Nota: Esta consola requiere ejecutarse como administrador, así que pedirá elevación.

Así luce la consola de administración del ACT:

image

Hacemos clic en el botón Fix de la barra de comandos, o bien clic derecho sobre la base de datos predeterminada, Create New > Application Fix:

image

En la página de Program Information, rellenamos los datos correspondientes a la aplicación y clic en Next:

image

En la página de Compatibility Modes, dejamos sin seleccionar nada –no sirven- y clic en Next:

image

En la página de Compatibility Fixes, buscamos CorrectFilePaths, lo seleccionamos y hacemos clic en Parameters para personalizarlo a nuestra medida:

image

En la ventana de Options for CorrectFilePaths es donde sale la magia; aquí personalizamos para cada nuevo shim sus respectivas opciones en línea de comandos.

Para el arreglo de CorrectFilePaths, debemos seguir el patrón descrito en las primeras imágenes:

<RutaOriginal>;<NuevaRuta>

Donde <RutaOriginal> es la ubicación en la que la aplicación intenta escribir de forma predeterminada, y <NuevaRuta> es la nueva ubicación por usuario donde queremos que siga escribiendo después de aplicar el arreglo.

Si tenemos en cuenta mi aplicación de ejemplo, trata de escribir en C:\ según mostró Process Monitor; si yo quiero que escriba en Documentos, el comando quedaría así:

%SYSTEMDRIVE%;%USERPROFILE%\Documents\

image

Es muy recomendable utilizar variables de entorno como mostré en el comando anterior, aunque no estrictamente necesario porque también podría haberse referido así:

C:\;C:\Users\Checho\Documents\

Sin embargo, esto quedaría asociado al usuario “Checho” y a letras de unidades específicas. Grave error.

*Nota: El punto y coma (;) es de vital importancia, y debe ir todo pegado.

Como dato adicional, podríamos cambiar incluso el nombre del archivo a escribir; solo es cuestión de referenciar el nombre original y el nuevo nombre, así:

image

Primero se especifica DemoFile.txt (original) y luego el nuevo nombre, para mi caso: File.txt.

Al hacer clic en OK, la página de Compatibility Fixes debería verse así:

image

Ya referenciado el arreglo, clic en Next.

*Nota: Con el botón Test Run… podemos probar si el arreglo va a funcionar antes de ser aplicado.

En la página de Matching Information, podemos dejar las opciones predeterminadas y clic en Finish para terminar:

image

De vuelta en la consola principal, hacemos clic en el botón Save y le asignamos un nombre a la base de datos creada:

image

Después, indicamos la ruta donde se guardará la base de datos:

image

*Nota: Lo ideal es que se guarde en una ruta compartida si es que se planea implementar masivamente después.

Para terminar, clic derecho en la base de datos y seleccionamos Install:

image

Aceptamos el cuadro de confirmación sobre la instalación:

image

Comprobando resultados

Si todo sale bien, la corrección debería hacer que la aplicación funcione, por supuesto, si este era el único error:

image

Si volvemos a monitorear con Process Monitor, la aplicación nunca se dará cuenta de lo sucedido:

image

Una aplicación puede tener múltiples arreglos para mitigar diferentes problemas; este es uno de los más comunes y como ven, funciona muy bien.

Por supuesto, no es necesario tener el ACT instalado en todas las máquinas donde se quiera implementar, basta con lanzar un script local o remoto que llame al proceso sdbinst.exe con el parámetro –q y el directorio del arreglo para que se instale.

Por ejemplo, si este arreglo lo fuese a instalar en un equipo, y lo tuviese en el directorio C:\, ejecutaría:

sdbinst.exe –q C:\FileExampleShim.sdb

image

Claro está, lo ideal, como dije antes, es que el Shim esté en una ruta de red si se quiere hacer una distribución masiva y centralizada.

Conforme mi conocimiento lo permita, documentaré otros arreglos y temas más complejos de ACT aquí en el blog. Empecé por uno de los que consideré puede ser más útil.

Como nota final, el ACT está disponible desde versiones anteriores.

Espero sea de utilidad.

Saludos.

Checho

Más artículos Página siguiente >