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

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

Crear y capturar imagen maestra de Windows 8.1 con System Center Configuration Manager 2012 R2

En el pasado mes de julio, escribí por primera vez un artículo donde referencié a System Center Configuration Manager, explicando cómo realizar una implementación básica de Windows 8.1 y prometí escribir un poco más de lo que iría aprendiendo con esta formidable solución.

Aunque lo ideal es unir SCCM con MDT y mostrarles escenarios, quiero tocar primero algunos básicos utilizando Configuration Manager; es por esto que en este artículo explicaré cómo podemos instalar y generar nuestra propia imagen maestra de Windows 8.1, haciendo uso de una secuencia de tareas que está incluida de forma predeterminada.

Requerimientos

1. Naturalmente, tener un escenario implementado de System Center Configuration Manager 2012 R2. Personalmente, me apoyé en este artículo.

2. Copiar los archivos de instalación de Windows 8.1 en una ruta compartida. Para este artículo, los copié en una carpeta compartida llamada 81 en mi servidor de Config Manager.

3. Crear una ruta compartida donde se guarden todas las aplicaciones a desplegar.

4. Crear una carpeta compartida por cada aplicación que se vaya a instalar, copiando los archivos de instalación allí.

*Nota: En el primer post que referencié, indiqué cómo se podía desplegar un .MSI; esta vez lo haré con un .EXE. Utilizaré WinRAR como referencia.

Agregando aplicación

En la consola de administración de System Center Configuration Manager (SCCM), pasamos al nodo inferior de Software Library, expandimos la carpeta de Applications Management en la parte superior, clic derecho en Applications y seleccionamos Create Application:

image

En la página de General, seleccionamos Manually specify the application information y clic en el botón Next:

image

En la página de General Information, solo digitamos el nombre de la aplicación y clic en Next:

image

En la página de Application Catalog, clic en Next:

image

En la página de Deployment Types, clic en el botón Add:

image

Se volverá a abrir un asistente y página similar a la primera; seleccionamos Manually specify the deployment type information y clic en Next:

image

En la página de General Information, indicamos nuevamente nombre y clic en Next:

image

En la página de Content, es necesario indicar la ruta compartida donde está el archivo de instalación en el cuadro de texto seguido de Content Location, y en el cuadro de Install program, especificamos el nombre del ejecutable, seguido de la bandera que permita una instalación automatizada (Por ejemplo: WinRAR /S en mi caso):

image

En la página de Detection Method, es necesario decirle a Configuration Manager cómo darse cuenta si la aplicación ya está instalada en un dispositivo; para esto, hacemos clic en el botón Add Clause…

image

En la ventana de Detection Rule, indicamos como Type que sea File (archivo), la ruta completa donde normalmente quedaría la aplicación instalada en Path y el nombre del ejecutable en File or folder name:

image

*Nota: Marcamos “This file or folder is associated with a 32-bit application on 64-bit system”, solo si estamos referenciando una aplicación de 32 bits, que se vayan a instalar en equipos de 64 bits.

Clic en OK para volver a la página de Detection Method y clic en Next.

En la página de User Experience, escogemos Install for system para que se aprovisione a todos los usuarios y Whether or not a user is logged on. Clic en Next:

image

De aquí en adelante, hacemos clic en Next hasta y terminar y Close. Debemos estar de vuelta en la página de Deployment Types, pero esta vez con la aplicación listada:

image

Clic en Next hasta terminar y Close.

Clic derecho en la aplicación y seleccionamos Distribute Content:

image

En la página de General, dejamos la configuración predeterminada y clic en Next:

image

En la página de Content, clic en Next:

image

En la página de Content Destination, clic en el botón Add, luego Distribution Point, seleccionamos el punto de distribución y clic en OK:

image

Clic en el botón OK.

En la página de Summary, clic en Next.

En la página de Completion, clic en Close.

Agregando sistema operativo

En la consola de SCCM, expandimos la carpeta de Operating System Images, clic derecho en la raíz o en la carpeta que tengamos creada y seleccionamos Add Operating System Image:

image

En la página de Data Source, indicams la ruta compartida donde copiamos nuestros archivos de instalación de Windows 8.1, específicamente el archivo install.wim y clic en Next:

image

*Nota: Lo importante de referenciar aquí es el .wim.

En la página de General, indicamos un nombre y opcionalmente versión y descripción; luego hacemos clic en Next:

image

En la página de Summary, clic en Next. En la página de Completion, clic en Close.

Sobre nuestro sistema operativo agregado, hacemos clic derecho y seleccionamos Distribute Content:

image

En la página de General, clic en Next.

En la página de Content Destination, hacemos clic en el botón Add y luego Distribution Point:

image

Seleccionamos nuestro punto de distribución y clic en OK:

image

De nuevo en la página de Content Destination, clic en Next.

En la página de Summary, clic en Next.

En la página de Completion, clic en Close.

Creando y desplegando Secuencia de Tareas

Pasamos al nodo de Task Sequences, hacemos clic derecho sobre la raíz o carpeta que tengamos creada y seleccionamos Create Task Sequence:

image

En la página de Create New Task Sequence, seleccionamos la segunda opción: Build and capture a reference operating system imagen y clic en Next.

image

En la página de Task Sequence Information, especificamos el nombre para la Secuencia de Tareas, luego hacemos clic en el botón Browse al lado de Boot Image para indicar una imagen de arranque y clic en Next:

image

En la página de Install Windows, clic en el botón Browse al lado de Image Package, indicamos la imagen de instalación que agregamos anteriormente y clic en Next:

image

En la página de Configure Network, indicamos los datos del dominio al que lo deseamos agregar y clic en Next:

D1

*Nota: Utilizando MDT, no sería necesario unirlo al dominio porque se va a realizar una captura, pero en SCCM es necesario, pues de lo contrario no se podrá comunicar con el punto de distribución y habrá un error en la secuencia de tareas mientras instala las aplicaciones.

En la página de Install Configuration Manager client, hacemos clic en Next:

image

En la página de Include Updates, indicamos la opción según nuestra preferencia y clic en Next:

image

En la página de Install Applications, clic en el icono del sol, escogemos nuestra aplicación del repositorio y clic en Next:

image

En la página de System Preparation, clic en Next:

image

En la página de Image Properties, escribimos los datos correspondientes al que está creando la Secuencia de Tareas y clic en Next:

image

En la página de Capture Image, debemos especificar primero la ruta compartida donde queremos guardar la imagen .WIM, incluyendo el nombre y extensión de la misma; así como la cuenta que tiene permisos para escribir en el repositorio:

image

*Nota: Hay que tener cuidado aquí, pues de estos datos depende que la imagen quede capturada. En mi caso, le puse REF1.wim, pero pueden llamarla como quieran, desde que mantengan la extensión.

En la página de Summary, clic en Next.

En la página de Completion, clic en Close.

Luego de esto, clic derecho sobre la Secuencia de Tareas creada y seleccionamos Deploy:

image

En la página de General, indicamos All unknown computers como Collection y clic en Next:

image

En la página de Deployment Settings, debajo de Make available to the following, nos asegurarmos que sea Configuration Manager client, media and PXE y clic en Next:

image

Clic en Next para el resto de las páginas hasta llegar a Completion y clic en Close.

Instalando y capturando

Nuestro último paso, es finalmente arrancar una máquina virtual o física para que inicie por red y podamos iniciar el asistente de instalación.

image

En la primera ventana, hacemos clic en Next:

image

*Nota: Aquí nos pedirá contraseña o no, de acuerdo a como lo hayamos configurado al momento de instalar SCCM.

En la página de Select a Task Sequence to run, escogemos la que recién creamos y Next:

image

Si todo sale bien, el proceso de instalación iniciará:

image

image

image

image

image

*Nota: Es normal que hayan un par de reinicios durante este proceso.

Al final de todo el proceso, la máquina cliente se reiniciará y arrancará en el OOBE, pero en nuestro recurso compartido quedará la imagen maestra lista para importar nuevamente:

image

¡Eso es todo! Relativamente sencillo, aunque MDT es quien realmente agrega valor a estos procedimientos dentro de SCCM, así que pronto lo veremos.

Espero sea de utilidad.

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

Saludos.

Checho

El constante pantallazo azul causado por athwbx.sys, Windows PE, Autoruns, DISM y su solución

El caso que pasaré a describir, es uno de los que personalmente más trabajo me ha costado solucionar, pero también en el que más combinación de herramientas he utilizado; por estas razones, quiero compartirlo para otros que a lo mejor se vean en el mismo escenario que yo, y no sepan cómo proceder. Como siempre, lo dividiré en problema, causa y solución.

El problema y su causa

Hace unos días recibí un equipo que tenía un problema bastante preocupante; cada vez que se reiniciaba, justo antes de iniciar sesión, daba un escalofriante pantallazo azul:

10644238_344446339052034_2954703526335869854_o

No importa cuántas veces reiniciara, siempre recibía el BSOD. Por otro lado, no tenía puntos de restauración funcionales el equipo, así que no había cómo devolverlo a un estado donde todo estuviese corriendo bien.

Como el equipo ya llevaba un buen tiempo desde que se instaló, opté por ser práctico e instalar nuevamente el sistema operativo desde cero, pues consideré que perdería más tiempo si me ponía a indagar en el problema. El verdadero dilema empezó cuando terminé de instalar, pues mientras estaba actualizando Windows nuevamente explotó el pantallazo azul, pero la primera vez pude ingresar otra vez a Windows.

Lo primero que hice, fue extraer el Minidump ubicado en C:\Windows\Minidump y lo abrí en otro equipo con Windbg para realizar un análisis.

Ejecutando !Analyze –v en Windbg, me arrojó este resultado en el stack:

BSOD1

Como ven, había incluso múltiples repetisiones del athwbx, correspondiente a athwbx.sys:

BSOD2

El controlador, creado en Octubre del 2013, pertenecía a Qualcomm Atheros Wireless Network Adapter, o en palabras más humanas, al controlador inalámbrico del equipo:

Dr7

Lo más normal en este tipo de casos, es simplemente buscar en la página web del fabricante una versión del controlador más actual, así que bajé uno de Toshiba, que era la marca del portátil y procedí a actualizar… lamentablemente, apenas Windows utilizaba el controlador de alguna forma, volvía a estallar el BSOD.

Lo que hice entonces fue desinstalar todo el controlador, y dejar que Windows lo reconociera desde su propia base de datos, y en efecto, se instaló uno que parecía más actual:

Dvr01

Para mi mala fortuna, no solo volvió a dar el pantallazo azul, sino que se quedó idefinidamente estallando en cada reinicio, ¡otra vez!

Tenía mucho sentido que diera el pantallazo apenas en el logon, pues ahí es donde el sistema operativo carga servicios y controladores; ¿Pero, cómo detener el inicio del controlador en cuestión, cuando ni siquiera tengo acceso a Windows?

Como he mostrado en otros artículos enfocados a implementación, utilizando el ADK es posible generar un Windows PE; pequeño sistema operativo Windows que carga en memoria RAM, con algunas funciones limitadas, pero que al ser sistema operativo, tiene ventajas notables como las de ejecutar algunos tipos de aplicaciones. Autoruns de Sysinternals, es una de ellas y desde Autoruns se puede ver todo lo que inicie en Windows, para todos los usuarios y empezar a deshabilitar según sea necesario.

Lo que hice entonces fue crear un Windows PE desde otro equipo, preparé una USB y arranqué el equipo desde allí. Una vez iniciado, busqué la unidad del PE y ejecuté Autoruns desde allí para luego ir al menú File > Analyze Offline System. Aquí símplemente indiqué la unidad que contenía la instalación de Windows y la ruta de ProgramData para referenciar a todos los perfiles:

image

Al hacer clic en OK, Autoruns cargó nuevamente todos los datos, pero esta vez del sistema local. Con esto, bastaba ir ahora a la pestaña de Drivers, buscar el correspondiente al controlador inalámbrico, es decir, athwbx.sys y deshabilitar la entrada:

image

*Nota: Técnicamente, se podría hacer esto mismo cargando el Hive de System en el Registro de Windows, pero es un procedimiento un poco más complejo.

Cerré Autoruns, la consola del Windows PE y al reiniciar, ya estaba nuevamente en Windows, con el controlador deshabilitado:

Dr1

Ya sabía que no podía habilitarlo ni usar la WiFi, porque volvería a causar el BSOD, así que conecté el equipo por cable y procedí a buscar nuevamente actualizaciones de Windows.

Revisando los resultados, me encontré con una en particular muy interesante:

Dvr02

Era justamente una actualización al controlador inalámbrico que me estaba causando el pantallazo, con fecha de este mes, lo que sugería que corregía el problema que estaba causando en Windows.

Lamentablemente, al intentar instalarlo, Windows internamente debía manipular el controlador anterior, así que volví a recibir una vez más el dichoso pantallazo azul. Intenté desinstalando previamente el controlador desde el administrador de dispositivos, pero si hacía eso, Windows Update no me ofrecía la actualización y si lo dejaba, me regalaba un BSOD al intentar desplegarlo.

Como podrán imaginarse, estaba bastante atascado, pues aunque estaba casi seguro que esa actualización solucionaba el problema, Windows no me la iba a dejar fácil para actualizar… ¿Qué podía hacer, entonces?

La solución

Tal cual he expuesto en más de un caso, las técnicas y herramientas de implementación pueden llegar a ayudar en muchos casos para solución de problemas en Windows. Estaba claro que no podría instalar el controlador online, así que lo único que me quedaba era hacerlo offline, y para esto necesitaría acudir al argumento de /Add-Driver de DISM.

Básicamente, tendría que montar una imagen de Windows 8.1 con DISM, inyectarle el controlador manual, guardar la imagen, preparar la instalación en un .ISO o USB y proceder a instalar Windows nuevamente. Esto no lo podía hacer en la instalación que ya tenía, porque el parámetro de /Add-Driver solo funciona sobre imágenes offline.

Lo primero que tenía que hacer, era encontrar el controlador que ofrecía Windows Update, pues seguramente ese era el unico que solucionaría el problema, así que procedí a utilizar un servicio muy interesante en la página de Windows Update, y es poder consultar sobre un catálogo de controladores la descarga. Como ya tenía el nombre, bastaba con realizar lo siguiente:

1. Navegar hasta la página: http://catalog.update.microsoft.com/v7/site/Home.aspx

2. Instalar el complemento que pide la página.

3. Buscar por el nombre específico del driver, tal cual aparece en Windows Update:

Qualcomm Atheros AR9002WB-1NG Wireless Network Adapter

4. Hacer clic en el botón Agregar.

5. Clic en el enlace de Ver cesta en la parte superior.

6. Clic en el botón Descargar:

image

Después de esto, procedí a inyectarlo con DISM a la imagen de instalación de Windows para que una vez instalado, ya estuviese el controlador actualizado y que no generaba BSOD.

*Nota: Como inyectar controladores requiere un procedimiento, escribí un artículo aparte donde pueden ver el paso a paso:

Inyectar controladores a una imagen offline de Windows 8.1 utilizando DISM.

Después de instalado, el Wi-Fi estaba funcionando y para mi gran fortuna, ¡el problema se había ido! Recordemos que no bastaba con instalar nuevamente Windows.

Al revisar el controlador, pude verificar que se había instalado con Windows por la fecha de creación:

Solved

Solo restaba configurar nuevamente Windows para que se pudiera continuar trabajando con el equipo.

Espero sea de utilidad para los que presenten un problema similar.

PD: No olviden que pueden consultar con la comunidad por sus problema con Windows en los foros de Windows 8.1 de Microsoft Community.

Saludos.

Checho

Inyectar controladores a una imagen offline de Windows 8.1 utilizando DISM

Hace un tiempo, por petición de alguien que me había escrito, creé un artículo donde mostraba paso a paso cómo podíamos generar una imagen de Windows 8.1, integrando la cantidad de actualizaciones deseadas; hoy, gracias a que me he dado cuenta de lo valioso que puede ser en casos de solución de problemas, mostraré cómo pueden hacer lo mismo, pero esta vez inyectando controladores específicos a una imagen para que estén disponibles una vez instalado Windows, si el hardware tiene el dispositivo necesario.

Requerimientos

1. Claramente, necesitamos los archivos de instalación de Windows 8.1, o por lo menos la imagen .WIM, para cuando se vaya a utilizar alguna solución como MDT.

2. Los archivos de instalación para el respectivo controlador; no el ejecutable (.exe), sino lo que utiliza ese ejecutable, es decir, el archivo .INF y .SYS.

*Nota: Microsoft tiene disponible una web en donde se pueden descargar todos los controladores que uno encuentra en Windows Update:
http://catalog.update.microsoft.com/v7/site/Home.aspx

3. Tener instalado el ADK para Windows 8.1 Update. El paquete de instalación lo pueden descargar desde el sitio oficial de Microsoft:
http://www.microsoft.com/en-us/download/details.aspx?id=39982

4. Crear las siguientes 4 carpetas en C:

C:\81

C:\Mount

C:\Drivers

*Nota: Los nombres no son obligatorios, pero yo utilizaré estos durante el resto del post.

Copiando archivos de instalación

Si tenemos un medio .ISO o DVD con los archivos de instalación, es necesario copiar todo el contenido a la carpeta 81, para esto, hacemos clic derecho sobre el botón de Inicio, seleccionamos Símbolo del sistema (Administrador) y allí ejecutamos:

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

Donde <UnidadWin> corresponde a la letra asignada por Windows para nuestro medio después de montarlo o insertarlo; para mi caso, teniendo la letra H, el comando sería:

xcopy H:\*.* /s/e/f C:\81\

image

El proceso tardará unos minutos.

Preparando controladores

Como mencioné en los requerimientos y por lógica, es necesario tener los archivos de instalación para los controladores, pero no pueden ser extensiones de ejecutables, sólo .INF.

Si conocen específcamente lo que están buscando, la página del catálogo de Windows Update es un lugar ideal, pues me descarga un .cab que luego se puede descomprimir. Desde la página de cada fabricante también se pueden bajar, para luego buscar manualmente los archivos de instalación cuando se descompriman, trabajo que es un poco más complejo.

En mi caso, utilizaré dos controladores bajados del catálogo; uno de Wireless y otro de la tarjeta gráfica:

image

Repito, lo importante es tener el archivo .INF, acompañado del .sys.

Si descargaron desde el catálogo de Windows Update:

Al descargar desde el catálogo como dije, sea baja un .cab dentro de una carpeta:

image

Para descomprimir, hacemos lo siguiente:

1. Renombramos el archivo a algo sencillo, por ejemplo: drv1.sys

image

2. Copiamos el .cab a la unidad raíz de Windows (C:\).

3. Abrimos un símbolo del sistema con privilegios elevados y ejecutamos:

expand C:\drv1.cab –F:* C:\Drivers\

image

Hacemos esto con cada nuevo controlador, cambiando por supuesto el nombre del .cab.

4. Verificamos que los archivos de instalación hayan quedado:

image

*Nota: Es normal que aparezcan muchos otros archivos o incluso .inf, pero siempre habrá uno principal, acompañado por su .sys. El de NVIDIA, por ejemplo, es el de nv_dispwu.inf:

image

Cuando tengamos los archivos listos dentro de la carpeta C:\Drives, podemos proceder a montar la imagen para inyectarlos.

Paso 1: Montar la imagen

En el equipo técnico donde se instaló el ADK y copiamos la imagen, digitamos en la pantalla de inicio: Deployment and Imaging Tools Environment, clic derecho y Ejecutar como administrador:

image

En la consola, procedemos a montar nuestra imagen, en este caso de Windows 8.1 PRO:

Dism /Mount-Image /ImageFile:C:\81\sources\install.wim /Index:1 /MountDir:C:\Mount

image

Paso 2: Inyectar los controladores

Desde la misma consola del Deployment and Imaging Tools Environment, procedemos a inyectar los controladores a la imagen que está montada; puede ser uno a la vez o todos los que haya en una misma carpeta. Pasaré a mostrar ambas opciones, para que el artículo sea más completo:

Para un solo controlador:

Si queremos inyectar un solo controlador, por ejemplo, en mi caso con el de Wireless, ejecutamos:

Dism /Image:C:\Mount /Add-Driver /Driver:C:\Drivers\athwbx.inf

image

El resultado nos debe dar como: The driver package was successfully installed.

*Nota: Después del parámetro de /Driver, es básicamente indicar dónde está nuestro .inf, así que variará para cada uno de ustedes el nombre del archivo.

Para instalar múltiples controladores:

Si lo que deseamos es inyectar todos los controladores disponibles en una carpeta, debemos ejecutar:

Dism /Image:C:\Mount /Add-Driver /Driver:C:\Drivers /Recurse

image

Como ven, DISM es lo suficientemente inteligente para detectar todos los controladores que hayan y de ser posible, realizar la instalación.

Siempre podremos verificar que se hayan instalado ejecutando:

Dism /Image:C:\Mount /Get-Drivers

image

Paso 3: Guardar y desmontar la imagen

Cuando terminemos de inyectar los controladores y estemos satisfechos, procedemos a ejecutar:

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

image

Paso 4: Creando la imagen .ISO

Por último, es necesario volver a generar la imagen .ISO de instalación, si es que deseamos utilizar algún medio porque para una USB el proceso es diferente.

Para la ISO, desde la misma consola del Deployment and Imaging Tools Environment, ejecutamos:

oscdimg –bootdata:2#p0,e,bC:\81\boot\Etfsboot.com#pEF,e,bC:\81\efi\microsoft\boot\Efisys.bin –u1 –udfver102 C:\81\ C:\Win81_plus_drivers.iso

image

*Nota 1: Se ejcuta todo en una sola línea.

*Nota 2: El comando permite que la imagen se pueda intalar en un equipo que esté basado en BIOS o en UEFI.

¡Todo listo! Basta con proceder a instalar Windows y el controlador se implementará también.

Espero sea de utilidad.

Saludos.

Checho

Cambiar el método de entrada para el teclado para Windows 8.1 utilizando MDT 2013

Una de las primeras personalizaciones que hacemos al instalar Windows, dejando a un lado la forma en que se despliegue, es configurar el o los métodos de entrada que necesitamos, de acuerdo a la región en donde estemos y los idiomas que manejamos. Esto es fácilmente personalizable desde el Panel de Control > Reloj, idioma y región > Agregar idioma:

image

*Nota: Para una guía completa sobre cómo hacerlo, vean este artículo que escribí hace tiempo en la web de Fermu.com.

Aunque como ven, es mucho más fácil y flexible que en Windows 7 la forma en que se personaliza, es una gran idea automatizar y estandarizar esto en todos los equipos que se implementen de manera masiva, así que se vuelve buena práctica incluir esto en un archivo de respuesta o mejor aún, en las Reglas dentro de MDT.

Automatizar esta configuración no es complejo, pero requiere tener en cuenta algunos detalles; por este motivo, dedicaré este artículo unicamente a explicar el proceso para cambiar el método de entrada en el teclado durante la instalación de Windows 8.1 utilizando Microsoft Deployment Toolkit (MDT).

*Nota: Aquí no explicaré el paso a paso para crear un Deployment Share o agregar sus componentes, pues eso ya está documentado en este post, y aún aplica para 8.1 y MDT 2013.

Obteniendo el formato de la ubicación para el teclado

Lo primero que debemos hacer, antes de ir meter la mano en MDT, es obtener el formato de la ubicación para el teclado que deseamos predeterminar; sin bien esto no es de importancia y además es gráfico – Español (España), por ejemplo-, en una implementación es necesario pensar en términos de cómo lo reconoce el sistema operativo.

Sobre el formato de ubicación

Si monitoreamos un poco con Process Monitor, veremos que cada que agregamos un nuevo idioma en Windows 8/8.1, el sistema operativo modifica el valor Languages en la clave:

HKEY_CURRENT_USER\Control Panel\International\User Profile

Allí, escribe el contenido de valor como texto indicando la ubicación para nuestro teclado, por ejemplo: es-ES. Como en el Panel de Control puede haber varios, el valor también contiene toda la cadena necesaria:

image

Como ven en la captura, el valor tiene es-ES, es-419 y en-GB, correspondientes a España, América Latina y el Reino Unido respectivamente.

Ahora, como subclave de User Profile, Windows crea una clave para cada distribución, y ahí genera dos valores que referencian el formato de ubicación que se está agregando:

image

El primera valor siempre será el nombre del formato en hexadecimal, y el segundo le indica al caché de Windows qué nombre informal debe mostrar en el Panel de Control. Para Español (América Latina), sería así:

image

El valor 580A:0000080A es la forma hexadecimal para referirse a en-419, que a su vez especifica Español (América Latina). El valor CachedLanguageName, tiene como contenido en su cadena Winlangdb.dll, de donde saca el texto a mostrar. Es fácil de comprobar abriendo la DLL con Resource Hacker y explorando su String Table en el nodo 2055:

image

El cache se consulta se consulta por usuario en unas subclaves que varían en nombre ubicadas en: HKEY_CURRENT_USER\Software\Classes\Local Settings\MuiCache

Claramente, los valores de cada sublcave de User Profile van a ser diferente, pues así el sistema operativo reconoce qué formato se está agregando.

En este orden de ideas, basta con agregar un formato en un equipo online y consultar estas claves para saber su nombre en texto y/o hexadecimal; sabiendo esto, estaremos seguros de agregar el nombre exacto al MDT para predeterminal el que deseemos durante nuestra implementación.

*Nota: Por supuesto, también se puede ir a consultar en Google, pero quizá el tiempo sea más largo y los resultados más confusos.

Para la siguiente parte del artículo, tomaré como referencia el formato de Español (América Latina), es decir, 580A:0000080A como hexadecimal, o en-419 como texto.

Personalizando CustomSettings.ini y BootStrap.ini para agregar formato de ubicación

Recordemos que CustomSettings.ini y BootStrap.ini son dos archivos de configuración que utiliza el asistente de implementación de MDT, con el objetivo de mantener todas las personalizaciones y configuraciones, además de controlar el proceso de instalación. En otras palabras, aquí podemos automatizar y predeterminar todo lo que se puede hacer mientras Windows se instala en el equipo.

En nuestro servidor MDT, hacemos clic derecho sobre el Deployment Share que hayamos creado y seleccionamos Properties:

image

En la ventana de Properties, nos pasamos a la pestaña de Rules, donde veremos todo lo que está configurado para CustomSettings.ini y el acceso al BootStrap.ini:

image

Aquí debemos indiciar y personalizar  5 propiedades:
SkipLocaleSelection, KeyboardLocale, UserLocale, SkipTimeZone y TimeZoneName.

SkpLocaleSelection y SkipTimeZone nos permitirán ocultar la ventana en la que indicamos estas personalizaciones durante el asistente de instalación; KeyBoardLocale y UserLocale es donde le decimos a Windows qué formato de ubicación predeterminará. TimeZoneName recibe como valor el nombre de la zona donde nos econtremos con su formato global.

Las dos primeras propiedades basta con asignarles el valor de YES para que estén listas:

SkipLocaleSelection=YES
SkipTimeZone=YES

image

KeyBoardLocale y UserLocale reciben como valor el formato en texto o hexadecimal que previamente consultamos para nuestra ubicación del teclado. Ambos pueden ser en texto, en hexadecimal o variado.

Para mi caso, Español (América Latina), sería:

KeyboardLocale=580A:0000080A
UserLocale=es-419

image

Como dije antes, KeyboardLocale podría tener es-419 y UserLocale 580A:0000080A. No es necesario que los dos estén con un mismo tipo de valor, más sí sería lo adecuado para evitar confusiones. Como el texto es lo más natural para nosotros, podría ser:

KeyboardLocale=es-419
UserLocale=es-419

Por último, a TimeZoneName le asignaré lo que corresponde a formato de Bogotá, Lima, Quito, es decir:

TimeZoneName=SA Pacific Standard Time

Todo quedaría así:

image

Una vez hecho esto, clic en el botón de la parte inferior derecha Edit Bootstrap.ini:

image

Aquí debemos agregar también KeyboardLocale para que funcione correctamente después de instalado Windows. Lo pondré en formato hexadecimal para demostrar que puede variarse con respecto al valor de tipo texto es-419:

image

Clic luego en File > Save para que el Bootstrap.ini quede guardado con los cambios.

En la ventana de Properties, clic en Apply y luego OK para terminar.

*Nota: Para recordar, si van a agregar un formato que no sea Español (América Latina), el valor tipo texto y hexadecimal será diferente, así que es necesario verificarlo desde Windows como lo mostré al principio antes de configurar los archivos de configuración en MDT.

Actualizando recurso compartido

Por último, clic derecho en nuestro Deployment Share y seleccionamos Update Deployment Share:

image

En la ventana de Update Deployment Share Wizard, dejamos la opción predeterminada y clic en el botón Next:

image

En la ventana de Summary, clic en Next.

En la ventana de Confirmation, clic en Finish.

Probando instalación

Lo siguiente es montar la imagen LiteTouch a nuestro WDS, conectar un equipo cliente e iniciar la instalación desde MDT.

Lo primero que deben notar, es que no les aparecerá la ventana donde se solicita idioma, método de entrada y región, pues se obvio utilizando las propiedades de Skip.

Al terminar la instalación, en el Panel de Control > Reloj, idioma y región > Agregar idioma debería aparecer el formato que se indicó como predeterminado, sin importar qué idioma tenga el sistema operativo:

image

Muchas gracias a Severo Alonso, que me escribió consultando sobre este proceso y me dio una gran idea para publicar un nuevo post.

Espero les sea de utilidad.

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

Implementación básica de Windows 8.1 Update utilizando System Center Configuration Manager 2012 R2

Hasta el día de hoy, me había prometido no escribir sobre temas de System Center en este blog por tres razones básicas:

1) System Center, representado por todos sus “sabores”, es todo un mundo aparte, tanto que podría separarse completamente de lo que es Windows Client.

2) Por el motivo anterior, no cuento con conocimientos de la Suite, específicamente de System Center Configuration Manager (SCCM), y la idea de este blog siempre ha sido poder compartir lo que sé y lo que he ido aprendiendo.

3) Adopté como filosofía intentar crear contenido sobre recursos que sean gratuitos para que todos los interesados los puedan seguir.

Sin embargo, en estos años que estuve visitando varias empresas en mi país Colombia, con temas de implementación, me encontré con que muchas adoptan SCCM para hacer sus despliegues; y, aunque MDT es muy poderosa, está hecha para que cuando se combine con System Center Configuration Manager, se cree una solución de implementación completamente robusta y flexible.

Dicho esto, tengo como propósito empezar a investigar, aprender y documentar aquí algunos procesos que se pueden llevar a cabo combinando las dos soluciones, pero todo enfocado a la implementación de Windows; no tocaré ni documentaré por ahora temas específicos de System Center Configuration Manager, más allá de los necesarios para que los procedimientos funcionen.

Hoy empezaré con lo elemental, y es la forma de cómo realizar una implementación básica de Windows 8.1 Update utilizando solamente System Center Configuration Manager (SCCM).

*Nota: En los próximos artículos, mostraré cómo integrar SCCM con MDT y lo que esto puede brindar a la compañía.

Requerimientos

- Un ambiente con System Center Configuration Manager (SCCM) implementado. Esto representa mínimamente dos servidores y un entorno de dominio.

*Nota: Para los que apenas van a implementar SCCM, tal vez este no sea el post ideal; sin embargo, yo me apoyé en este artículo de SCCMENTOR y este de TechNet UK.

Como experiencia personal, debo agregar que para implementar sistemas operativos, es necesario recordar crear un Boundary, en mi caso de tipo Active Directory Site:

image

*Nota: Sin el Boundary, recibirán un error al correr el Windows PE que no dejará iniciar el procedimiento de implementación.

- Crear una carpeta en la raíz del disco C:\ llamada 81, copiar todos los archivos de instalación de Windows o una imagen .WIM personalizada y compartir la carpeta para que se pueda acceder a través de la red. La carpeta quedaría entonces C:\81.

Para mi caso, que la tengo en el servidor llamado SRVCM, la ruta completa sería: \\SRVCM\81

- Un paquete de instalación .MSI para cualquier aplicación. En mi caso, utilizaré la de 7zip para ilustrar la forma en que se agrega una aplicación básica a la implementación.

La aplicación debe estar en un recurso compartido también.

*Nota: System Center Configuration Manager soporta muchos tipos de aplicaciones para desplegar, así que no es necesario que sea .MSI; sin embargo, desplegar un .EXE por ejemplo, tiene un procedimiento un poco más complejo, por eso no lo incluyo aquí.

Agregando y distribuyendo sistema operativo

En el servidor donde está instalado el SCCM, abrimos el System Center Manager Console, clic en el nodo inferior izquierdo de Software Library, expandimos la carpeta de Operating Systems, clic derecho en Operating System Images y seleccionamos Add Operating System Image:

image

En la ventana de Data Source, hacemos clic en el botón Browse y navegamos manualmente hasta la ruta de red donde pusimos nuestros archivos de instalación de Windows 8.1, y allí abrimos la carpeta Sources y seleccionamos install.wim. Para mi caso, la ruta completa sería \\SRVCM\81\Sources\install.wim

image

*Nota: Si solo copiamos el archivo .WIM de una imagen maestra, entonces no habría que buscar carpeta de sources; solo seleccionar el recurso y la imagen.

Hacemos clic en Next.

En la página de General, indicamos nombre y versión del sistema operativo a desplegar, y clic en el botón Next:

image

En la página de Summary, clic en Next.

En la página de Completion, clic en el botón Close.

Windows debería listarse en el panel central:

image

Hacemos clic derecho sobre el sistema operativo agregado, y en el menú contextual, seleccionamos Distribute Content:

image

En la página de General del asistente, dejamos la selección predeterminada y clic en Next.

image

En la página de Content Destination, clic en el botón Add y seleccionamos Distribution Point:

image

En la ventana de Add Distributions Points, seleccionamos nuestro servidor de distribución en la lista que nos aparezca (puede haber uno o más) y clic en el botón OK:

image

De regreso en la página de Content Destination, con el servidor ya listado en la parte central, hacemos clic en el botón Next:

image

En la página de Summary, clic en Next.

En la página de Completion, revisamos que haya quedado el Distribution Point listado, que todo esté en verde, y clic en Close:

image

Agregando y distribuyendo aplicación

Expandimos la carpeta de Application Management, clic derecho en Applications y seleccionamos Create Application:

image

En la página de General en el asistente, clic en el botón Browse, navegamos hasta la ruta compartida de nuestro .MSI (en mi caso la del 7zip), seleccionamos el paquete y clic en el botón OK.

Para mi caso, con 7zip, ubicado en la ruta \\SRVCM\7zip\7z920-x64.msi, quedaría así:

image

Clic en el botón Next.

Es posible que les aparezca una ventana similar a la siguiente que advierte sobre el editor desconocido; hacer clic en Yes si confían:

image

En la página de Import Information, clic en el botón Next.

En la página de General Information, solo debemos (si queremos) llenar algunos campos correspondientes a la información de la aplicación.

Lo interesante aquí, es que System Center Configuration Manger creará el comando para que el despliegue sea desatendido, cosa que en MDT debíamos especificar siempre de forma manual.

En Install behavior, seleccionamos Install for system y finalmente clic en Next:

image

En la página de Summary, clic en Next.

Después de unos segundos, estaré en la página de Completion. Aquí revisamos que todo esté en verd y clic en Close para terminar.

Como en el sistema operativo, hacemos clic derecho sobre la aplicación que está listada en el la parte central de Applications y seleccionamos Distribute Content:

image

En la página de General, clic en Next:

image

En la página de Content, clic en Next.

En la página de Content Destination, hacemos también clic en el botón Add, luego Distribution Point, seleccionamos el servidor de distribución y clic en OK:

image

Nuevamente en la página de Content Destination, con el servidor de distribución seleccionado y agregado, clic en Next:

image

En la página de Summary, clic en Next.

En la página de Completion, revisar que todo esté en verde y clic en Close.

Creando y desplegando Secuencia de Tareas

Finalmente, como en MDT, necesitamos una Secuencia de Tareas que administre todo el proceso de implementación.

Para crearla, expandimos nuevamente el nodo de Operating Systems, clic derecho en Task Sequence y en Create Task Sequence:

image

En la página de Create New Task Sequence, dejamos la selección de Install an existing image package y clic en Next:

image

En la ventana de Task Sequence Information, le ponemos un nombre a nuestra Secuencia de Tareas, una descripción, y hacemos clic en el botón Browse para escoger la imagen de arranque. Predeterminadamente nos aparecerá una para 32 y otra para 64 bits, pues son instaladas al desplegar el ADK mientras se implementa SCCM.

Escogemos la que necesitemos de acuerdo a la arquitectura a desplegar, y clic en Next:

image

En la página de Install Windows, hacemos clic en el botón de Browse al lado de Image package y seleccionamos nuestra imagen de instalación; aparecerán todas las que antes se agregaron al nodo de Operating System Images.

Luego decidimos qué edición instalar (si tiene varias), si queremos que habilite BitLocker y cómo queremos generar la contraseña de administrador para luego hacer clic en Next:

image

En la página de Configure Network, le indicamos unión al grupo de hogar o al dominio y clic en el botón Next:

image

En la página de Install Configuration Manager, dejamos la opción predeterminada y clic en el botón Next:

image

En la página de State Migration, quitamos la selección de los tres tipos de captura (no estamos haciendo migración) y clic en Next:

image

En la página de Include Updates, dejamos la selección y clic en Next:

image

En la página de Install Applications, clic en el icono del Sol para agregar una nueva aplicación del repositorio de paquetes que tenemos:

image

Seleccionamos la aplicación (en mi caso 7-Zip), clic en OK, y en la página de Install Aplications, clic en Next.

En la página de Summary, clic en Next.

En la página de Completion, verificar que todo esté en verde y clic en Close para terminar.

Nuestra Secuencia de Tareas se debe ver ahora creada:

image

Nuestro último paso, es publicar la Secuencia de Tareas para que cada equipo que se conecte a la red pueda descargar e instalar el sistema operativo. Para esto:

Hacemos clic derecho en la Secuencia de Tareas recién creada y seleccionamos Deploy:

image

En la ventana de General en el asistente, hacemos clic en el botón Browse al lado de Collection y escogemos: All Unknown Computers y clic en Next:

image

En la página de Deployment Settings, seleccionamos Configuration Manager clients, media and PXE debajo de Make available to the following y clic en Next:

image

En el resto de páginas, dejamos los valores predeterminados y hacemos clic en Next hasta llegar a la página de Completion; aquí revisamos que todo esté en verde y clic en Close:

image

Ejecutando y probando instalación

Finalmente, conectamos nuestro equipo cliente, nos aseguramos de que esté en el mismo segmento de red y hacemos el arranque por red para que detecte el PXE e inicie el Windows PE que envía Configuration Manager.

Si estamos por UEFI, vamos a tener una respuesta parecida a la siguiente captura una vez inicie por red:

image

*Nota: System Center Configuration Manager (SCCM) utiliza el Servicio de WDS para realizar las instalaciones por red.

Al presionar una tecla, Configuration Manager iniciará la descarga del Windows PE para mostrar el asistente:

image

En la primera ventana del asistente, nos debe pedir contraseña de acuerdo a si se lo indicamos o no durante la creación del Task Sequence:

image

Aquí bastará con hacer clic en Next.

En la página de Select task sequence to run, escogemos la Secuencia de Tareas que creamos y clic en el botón Next para iniciar:

image

Lo siguiente será dejar que Configuration Manager haga todo el resto del trabajo, muy similar a lo que pasa después de pasar el Lite Touch Installation (LTI) en MDT:

image

image

*Nota: El tiempo de instalación dependerá de los recursos de red y de lo que se esté implementando.

Al terminar, e iniciar sesión por primera vez, deberíamos tener listo nuestro Windows 8.1 con las aplicaciones que hayamos desplegado:

image

En los próximos posts, veremos cómo podemos integrar Configuration Manager con MDT y sacar más provecho de esta gran solución.

Espero sea de utilidad.

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

Saludos.

Checho

Más artículos Página siguiente >