Mes: enero 2011

¡Hola!

En el que para mi es un formidable espacio de aprendizaje los Foros de TechNet y Answers (MSDN también por supuesto!) constantemente se producen y se siguen problemas en Windows y en general todos los productos que se vuelven muy interesantes por lo complejos y muy satisfactorios al encontrar entre todos una solución porque no sólo el que crea el hilo aprende sino que todos los que tratamos de ayudar también lo hacemos.

Hay un problema que se ha estado presentando con bastante frecuencia últimamente, y es que al intentar abrir una carpeta ubicada en cualquier directorio obtienen el siguiente mensaje de error:

“Este archivo no tiene ningun programa asociado para ejecutar esta acción. Por favor instale el programa o si lo tiene cree una asociación en el panel de control de programas predeterminados”

El problema como el planteado en el artículo pasado pasa por la asociación de archivos que tiene Windows. Este mensaje es muy similar cuando se pierde la asociación de extensiones de algún ejecutable (.exe, msi) o incluso cualquier otro tipo de archivo que reconozca el sistema operativo.

Puntualmente aquí el problema sólo se presenta abriendo carpetas y no ejecutando algun otro tipo de archivo.

Afortunadamente para mí logré reproducir el problema en un equipo y digo “afortunadamente” porque estos problemas se presentan por lo general porque Windows hace la búsqueda en el registro por la asociación de la extensión o tipo de archivo pero cuando falta o está corrupta obviamente debe informarlo.

Para saber qué está pasando entonces procedí a llamar al mejor recurso que se puede tener con estos inconvenientes, de nuevo Process Monitor!

Recordemos que esta Herramienta de Sysinternals nos ayuda a monitorear todo lo que está pasando a nivel de I/0 en disco, red, registro entre muchas otras y que por supuesto nos dan una gran mano.

Lo que hice (Todavía bastante novato con Sysinternals!) fue hacer un trace en la máquina que tenía el problema abriendo la carpeta y en una máquina donde todo estaba funcionando muy bien, posteriormente guardar el Log y empezar a comparar todas las operaciones que se estaban haciendo para saber cuál era la que invocaba la asociación a las carpetas.

 

Lo primero que encontré es que se hacían unas llamadas a HKCRDirectory y a varias claves internas pero los resultados tanto en el equipo con el problema (Captura derecha) como el que procedía correctamente (Captura izquierda) eran muy similares.

Seguí buscando minusiosamente descartando operaciones que podía filtrar fuera del problema hasta que encontré otra referencia a HKCRFolder (HKEY_CLASSES_ROOTFolder) y de nuevo a varias claves dentro de esta carpeta, así que de nuevo comparé los resultados de los dos equipos:

Mirando cada línea encontré que la mayoría de los resultados eran de nuevo similares exceptuando uno: HKCRFolderShellOpenCommand

En el Equipo que estaba funcionando entregaba un resultado de SUCCESS:

Pero, en el Equipo que presentaba el error tenía como resultado NAME NOT FOUND:

Cabe aclarar que el resultado NAME NOT FOUND no siempre se refiere a un problema puesto que Windows puede intentar realizar consultas en un registro “padre” y al no tener resultados, pasa a realizar la consulta en un registro “hijo”.

Aquí por supuesto no pasaba esto ya que claramente en la máquina funcional estaba teniendo un resultado de exitoso pero en la otra no podía hacer referencia a la clave.

Decidí entonces ir hasta la llave del registro, desde Process Monitor, para esto basta con hacer clic derecho sobre la llave y seleccionar Jump to…

Como era de esperarse, en el equipo que entregaba un resultado satisfactorio la clave existía y funcionaba:

Al hacer este mismo proceso en el Equipo no funcional encontré que la clave no existía:

La solución…

Windows para el caso de abrir una carpeta, entre muchas operaciones referencia a esta clave para establecer la asociación con Windows Explorer y además para que la ventana sea mostrada en el directorio donde se está ejecutando.

Actualización:

Para solucionar el problema tenemos dos opciones:

Descargar FixAss®, una pequeña aplicación que desarrollé para reparar automáticamente la asociación de Carpetas y Directorios. Para esto descargan el archivo, descomprimen el ejecutable y lo ejecutan para recibir el cuadro de confirmación de la tarea, al cerrar el cuadro pueden revisar nuevamente la apertura de carpetas.

Lo pueden bajar desde aquí:

Descargar FixAss®

Solución manual:
Si el problema persiste pueden haber otras claves corruptas o perdidas dentro de HKCRFolder o HKCRDirectory.

Para este caso la solución más inmediata sería exportar estas claves desde un equipo funcional y posteriormente importarlas en el equipo que tiene los problemas.

También pueden hacer si desean ustedes mismos el Trace con el Process Monitor!

Para los que puedan ver este artículo buscando solución y la anterior no la proporcionó, les dejo el enlace a mi Skydrive con las dos llaves de Registro (Folder y Directory) para que las descarguen, descompriman y ejecuten para solucionar el problema:

Espero les pueda servir y de nuevo los invito a que se den un pasón por los Foros de Microsoft TechNet y Microsoft Answers.

Saludos,

-Checho-

Hola!

Bueno, sinceramente no esperaba poder escribir este artículo puesto que pensé que no podría llegar a la solución =)

¡El dilema!

Windows 7 incluye una función que puede ser de mucha utilidad, y se trata de las Herramientas para administrar la asociación que tienen las extensiones de los programas instalados con la respectiva aplicación, básicamente para ayudarnos a decidir qué aplicaciónes utilizar a la hora de abrir algunos tipos de archivos, por ejemplo decidir que todos nuestros archivos de audio con extensión .MP3 se abran con otra aplicación diferente a Media Player.

Para acceder a los Programas Predeterminados, basta con hacer clic en el menú Inicio y seleccionar Programas Predeterminados (Default Programs):

Desde aquí podremos establecer los Programas predeterminados sea estableciendo la asociación por aplicación o por extensión entre otras herramientas para personalizar la forma en que actúa la reproducción automática entre otros:

No profundizaré en lo que se hará puesto que no es la intención del Post, pero era necesario porque desde aquí empezó lo que llamé Mi dilema.

Explorando un poco las posibilidades para arreglar la asociación de archivos desde aquí y no tener que ir al registro puesto que es un problema bastante común en los Foros de Answers tenía abierto Live Meeting, Microsoft Lync y Adobe Reader X.

Al estar estableciendo la aplicación inesperadamente el icono que se visualiza en la barra de tareas para estas tres aplicaciones cambió, ahora la visualización parecía como si hubiera perdido esa asociación (La que estaba tratando de ver cómo arreglar!):

Lo primero que hice fue por supuesto tratar de restablecer la asociación haciendo clic derecho sobre el PDF y dentro de las Propiedades clic en el botón Cambiar, y de nuevo seleccioné Adobe Reader x (De hecho ya estaba) pero el “problema” persistía.

Procedí entonces a reasociar la extensión y los iconos creando la llave de registro pero de nuevo no funcionó.

Lo extraño de todo es que las tres aplicaciones (Adobe, Lync y Live Meeting) abrían perfectamente con el programa que administrara esas extensiones, pero el icono no cambiaba, lo que me llevó a pensar que el problema estaba en la asociación del icono como tal al tipo de archivo y no de extensión al programa predeterminado.

Mientras intentaba diferentes métodos me di cuenta de que si yo Anclaba el icono a la barra de tareas y después lo Desanclaba el icono se visualizaba bien, pero al volverle a dar clic derecho de nuevo cambiaba!

Dentro de la desesperación por ver estos iconos que no correspondían, fui hasta una de las carpetas que contenían los archivos propios de la aplicación a buscar posibles respuestas.

En la de Adobe encontré el ejecutable (AcrodRd32.exe), así que lo ejecuté y también se visualizaba mal, sin embargo al hacer clic derecho sobre este y Crear un acceso directo que predeterminadamente lo lleva al Escritorio sorprendentemente al abrir cualquier PDF el icono ahora se veía como debía (Vaya cosa!).

Hasta ahí creí que todo se había solucionado, pero al quitar el acceso directo del escritorio de nuevo el icono se veía mal en la barra de tareas.

Pensé entonces que podía deberse a la Caché de los iconos (Alguna vez me pasó algo similar por este causante en Windows XP) así que fui hasta la carpeta que pertenecía a mi usuario (C:UsersChechoAppDataLocal) y borré el archivo de base de datos que contiene el caché de los iconos IconCache.db

Con la esperanza de que esto hubiera podido funcionar reinicié el sistema pero al entrar todo seguía igual.

En este punto ya se me habían acabado las ideas para encontrar la solución al problema, obviando la restauración del sistema y la reinstalación de la aplicación que en realidad no me dirían el por qué y sólo lo arreglarían (Se hubiera perdido la gracia!).

Procedí entonces a pedir ayuda, y planteé el inconveniente en los Foros de WinTecnico que dirige Daniel Martín (MVP Windows Expert).

Por supuesto Daniel me ayudó, y además me entregó la pista que en últimas me llevó a la solución y es que en el Registro de Windows dentro de HKCR.pdf era donde normalmente tomaba el valor para definir el icono predeterminado de la aplicación, pero casi siempre Windows lo toma del Caché que tiene por rendimiento.

El icono lo busca dentro de los componentes que tiene el acceso directo la aplicación, pero además en Windows Installer por ejemplo esta ruta cambiaba y era un poco más difícil de encontrar.

De igual forma volvimos al Caché de iconos (No estaba tan perdido), así que por recomendación de nuevo de Daniel traté de forzar la actualización de este caché cambiando la arquitectura de colores a 16 bits y volviéndolo a 32.

Pero… sin ningún resultado positivo =)

Pensé entonces que para aprovechar y empezar a darle la cara a Sysinternals podría hacer un Trace de lo que pasaba “por debajo” mientras abría alguna de las aplicaciones, así que me fui por la que ya estaba explorando Adobe Reader X.

Para esto llamaría a Process Monitor

¡La gran ayuda de Process Monitor!

Realmente recurrí a esto por última opción, puesto que aunque es el próximo reto, entender y trabajar estas herramientas creo que puede ser algo complejo acostumbrarse.

Explorando un poco los resultados de lo que pasaba en el Registro ví que efectivamente hacía consultas y trabajo con las claves que habían en HKCR.pdf en otras como HKCUSoftwareClasses y HKCRAcroExch.Document.7

Lamentablemente no ví nada muy extraño pero pensé ¿Y si lo comparo con otro equipo que tenga la versión de Adobe Reader, Sistema Operativo y Arquitectura?

Comparé estos resultados con mi Equipo pero la verdad no variaban en casi nada, exceptuando algunas llaves más repartidas durante el Trace que se hacía.

Process Monitor me entrega entre sus miles de funciones la posibilidad de seguir directamente la entrada en el Registro de Windows y ver lo que contiene.

Para esto basta con hacer clic derecho sobre la llave que se desee seguir y seleccionar Jumpt to…

Por esto, mi segundo paso aquí fue Abrir algunas de estas entradas (Empezando por la que debía provenir el icono asociado) y compararlas con el Equipo donde todo se estaba visualizando bien.

En la primera no encontré mayor diferencia, sólo que no estaba creada la carpeta con el nombre del ejecutable “AcrodRd32.exe” en el equipo que se visualizaba mal (Una pequeña esperanza?) así que procedí a crearla y asegurarme de que en los dos estuviera exactamente igual:

La entrada en sí era: HKEY_CLASSES_ROOT.pdf

A pesar de todo, al reiniciar el equipo nuevamente todo seguía viéndose mal…

¿Y la solución?

La segunda entrada y finalmente LA QUE ME CONDUJO A LA SOLUCIÓN fue seguir el registro de HKEY_CLASSES_ROOTAcroExch.Document.7 en ambos equipos que contenía además una serie de carpetas dentro:

*Nota: Lo primero que traté de detallar era si había algun tipo de diferencias de nuevo en esta y las otras claves (Incluyendo sus rutas) en los dos equipos, el del problema y el del que me basaría para la solución.

Lamentablemente sin cambios.

Desconozco la función de esta estas entradas, pero me llamó mucho la atención la clave de DefaultIcon ya que según recordé de la ayuda de Daniel este determinaba la famosa ruta del icono que se visualizaría finalmente.

Abrí la clave y para mi sorpresa me encontré algo bastante interesante:

Como ven el String creado predeterminadamente “Default” entregaba una ruta que al final se refería a un archivo con extensión .ico (De icono!!):

C:WindowsInstaller{AC76BA86-7AD7-1033-7B44-AA0000000001}PDFFile_8.ico,0

Lo primero que me acordé es sobre el tipo de instalador (Windows Installer!) y al parecer ya me iba acercando, lo presentía! 😛

Seguí entonces la ruta en los dos Equipos esperando todavía encontrar algo de qué pegarme y que pudiera ser la gran diferencia, para mi sopresa en esta carpeta oculta están todos los iconos que maneja Adobe para los tipos de archivos pero incluyendo (Lo noté de casualidad) el que se ve en la barra de tareas:

En los dos equipos (Para mi desfortuna) estaban todos exactamente iguales por lo menos en nombres e iconos que se hacían referencia dentro del Registro de Windows, pero (Para mi fortuna!) sí había una diferencia no tan notable:

En el Equipo en que se estaba visualizando mal, al ver la propiedad de cada icono encontré que su aplicación asociada y predeterminada para abrir era Microsoft Paint:

Por el contrario, en las mismas propiedades que tenía el Equipo que se visualizaba correctamente el Equipo estaba predeterminadamente el Visor de imágenes de Windows:

¡Aquí tenía que estar el problema!

En efecto, lo que hice fue darle al botón Cambiar en el Equipo que estaba predeterminadamente Paint y cambiarlo de nuevo al que debía tener que era el Visor de imágenes de Windows (Windows Photo Viewer)

Al aplicar y aceptar me lancé a la prueba (Quizás la que sería la final) y decidí abrir otra vez un documento en PDF y me encontré con la mejor sorpesa de la noche:

¡Así es! Todo se había arreglado y ahora el icono había vuelto a su visualización original, y no solo este sino que el de Lync y Office Live Meeting también retornaron al que les correspondía predeterminadamente!

Y así, gracias a molestar tanto, a Daniel Martín y al increible Process Monitor de Sysinternals descubrí qué estaba pasando y arreglé el problema que aunque mínimo me entregó buenas enseñanzas (Que siempre es lo que considero importa) y muchas ganas de explorar más a fondo Sysinternals.

Para finalizar, desconozco y quedo en deuda la razón por la que situando el acceso directo en el escritorio los iconos se visualizaban bien (Si alguien tiene la respuesta lo invito a compartirla para todos!), aunque considero que quizás al estar el acceso directo, la aplicación o el documento estaba buscando directamente en esa ruta.

Para tener en cuenta a la hora de tener problemas:

Foros Microsoft TechNet en Español

Foros Microsoft Answers en Español

WinTecnico – Daniel Martín

Windows Sysinternals – Mark Russinovich

Gracias por tomarsen el tiempo de leer y por supuesto espero si a alguien le pasa lo mismo pueda llegarle a servir!

Saludos,

-Checho-

¡Hola!

Antes que nada, quiero agradecer y desear un gran Feliz Año a todas las personas que se toman el trabajo y el tiempo que recorrer un poco este Blog durante todo este tiempo!

El año pasado inicié una serie de artículos para introducirnos a lo que es la Configuración Avanzada de Microsoft Deployment Toolkit comenzando por Roles y Equipos y en el que además mostré cómo se debe realizar la configuración de la Base de datos para trabajar con MDT, pueden ver el artículo (Por si no lo han visto) desde Este enlace.

Después de algunos días de descanso de fin de año, quiero traerles la segunda parte donde tocaremos Make and Model (Lo podemos llamar Marca y Modelo) que guarda un proceso muy relacionado con el anterior pero que cubre otros escenarios quizás más grandes a nivel de implementación masiva de Windows 7.

En ocasiones una compañía puede adquirir una gran cantidad de Equipos nuevos sea porque los van a cambiar o porque se están dotando, por lo general pueden ser de varios fabricantes (HP, Lenovo, Dell) y por supuesto pueden traer diferentes características en RAM, Procesador y en Disco dependiendo para el área en que se vaya a entregar.

Lo normal sería realizar la implementación como lo hemos estado haciendo utilizando MDT para entregar distintos tipos de imágenes con aplicaciones y configuraciones pero gracias a la Base de datos y más específicamente al nodo de Make and Model ahora podremos pensar en realizar un filtro mucho más específico basándonos en otros parámetros de la máquina.

Por ejemplo podríamos pensar en instalar Windows 7 Professional en los equipos Dell Inspiron 1440 del departamento de ventas y Windows 7 Enterprise a los equipos HP G42 para el Departamento de mercadeo sólo creando dos nodos especificando lo que hará para cada uno dentro del MDT y la herramienta hará el resto =)

¿Cómo lo hago?

Primero, por supuesto debemos saber en verdad cuál es la Marca y el Modelo exacto del o de los equipos en los que vamos a desplegar Windows 7. Esto lo podemos realizar con el comando wmic dentro de una consola de comandos, si el equipo tiene sistema operativo debemos ejecutar la consola con privilegios elevados (Clic derecho, ejecutar como administrador) y ejecutamos:

wmic 
Nos encontraremos en el directorio  wmic:rootcli>

Ejecutamos computersystem get manufacturer para obtener la Marca (Make).

Ejecutamos computersystem get model para obtener el Modelo (Model)

¿Y si no tengo Sistema Operativo?

Para este caso tendríamos que buscar una forma de acceder remotamente al equipo y que podamos realizar “consultas” en este, por suerte Windows Vista y Windows 7 incluyen un Entorno de preinstalación (Windows PE) que contienen las Opciones de recuperación del sistema como la Reparación de inicio y una Consola de comandos!

Reiniciamos el equipo con un Medio de Windows 7, una vez seleccionado el idioma en la primera pantalla de instalación, donde empezamos la instalación (Instalar Windows) hacemos clic en el enlace de Reparar tu equipo.

Seguimos el asistente para iniciar las Opciones de recuperación del sistema, allí seleccionamos Consola de comandos (Command Prompt)

Una vez en la Consola de comandos, de nuevo ejecutamos los comandos:

wmic
computersystem get manufacturer

 

 

 

 

computersystem get model

*Importante:

El resultado de Manufacturer y Model variará dependiendo del equipo en que se esté ejecutando, por ejemplo si es un “clon” entregará el modelo de la Board y Fabricante que tiene, si es un Equipo virtual entregará las especificaciones propias para este (Como en las capturas anterior), si es un Equipo Dell, HP u otro entregará las especificaciones requeridas según el equipo y su fabricante (Por ejemplo Inspiron 1440 de Dell).

Para MDT, todas funcionarán, y para este artículo lo haré con el ejemplo de VMware.

Ya tenemos la marca del fabricante y el modelo buscado, aquí es donde se pasará a MDT!

Configurando el nodo de Make and Model en MDT

En el Equipo donde tengamos instalado Microsoft Deployment Toolkit (MDT) abrimos el Deployment Workbench haciendo clic en Inicio, Todos los programas, Microsoft Deployment Toolkit, Deployment Workbench.

*Nota: Para la siguiente configuración es necesario tener la Base de datos correctamente en MDT, si no la tienen pueden ver cómo configurarla aquí.

Expandimos el nodo de Configuración avanzada, Base de datos (Database) y hacemos clic derecho sobre Make and Model y seleccionamos New

Se abrirá la ventana de Propiedades, muy similar a la que ya habíamos visto en Computers en el artículo anterior.

Lo más importante estará en la pestaña de Identidad, aquí por obligación debemos especificarle Make and Model, para este artículo si tomara los de la máquina virtual sería:

Make: VMware, Inc.
Model: VMware Virtual Platform

Aquí como en todos los nodos podremos especificar en la pestaña Detalles (Details) todo lo que contrendrá el archivo CustomSettings.ini para automatizar la instalación y además agregar otras configuraciones adicionales, además de Aplicaciones y Administradores.

Lo más importante es que para evitar esto, podemos combinar los Roles que hemos creado agregándolos desde el nodo de Roles, así podremos tener uno específico para nuestro Modelo:

*Nota: La configuración de Roles está especificada en la primera entrega de esta seríe de artículos.

Una vez terminada la configuración de las propiedades podremos ver en la consola central del Nodo de Make and Model, la nueva “tarea” creada:

Nuestra última tarea será agregar nuestras Aplicaciones, Paquetes y Controladores que se podrán referenciar en las Secuencias de tareas generadas.

Si deseamos en la pestaña de Detalles dentro del Rol que hayamos creado para Make and Model especificamos el ID de la Secuencia de tareas en el componente TaskSequenceID, el ID de la Secuencia de tareas se ve en las Propiedades de la misma.

Después podemos cambiar el SkipTaskSequence en la misma pestaña para que no aparezca en el Asistente de implementación.

Actualizando Deployment Share

Como siempre, para cada cambio que hagamos debemos actualizar nuestro Deployment Share para que se genere o actualice la imagen de Windows PE con la que correremos nuestros equipos o que se puede agregar al Servidor WDS para la instalación por red.

Para esto, dentro del Deployment Workbench hacemos clic sobre el Deployment Share y seleccionamos Update Deployment Share

En el Asistente para actualizar el Recurso compartido seleccionamos la opción según lo que queramos (Actualizar o regenerar la imagen) y hacemos clic en Siguiente:

En la ventana de Summary hacemos clic en Siguiente para realizar el proceso.

En la ventana de Confirmación clic en Finalizar para terminar el asistente.

Instalando Windows 7

Como siempre, una vez actualizado el Deployment Share, vamos a la ubicación donde están las imágenes de presinstalación (DeploymentShareBoot) y grabamos la imagen .ISO en un DVD o USB para arrancar las máquinas.

Si se tiene un entorno de WDS, simplemente se debe agregar la imagen al nodo de Boot Images para que los equipos conectados en red se conecten al Deployment Share una vez hagan el arranque por red.

Una vez iniciados los Equipos nos queda ver la instalación y especificar lo que no hayamos automatizado, si todo sale bien, cuando los Modelos de los equipos indicados en el nodo de Make and Model se conecten y hagan la instalación deberán terminar con toda la configuración indicada por el MDT:

Espero les sea de mucha utilidad.

¡Comentarios bienvenidos!

Saludos,

-Checho-