Quitar la marca de agua “El arranque seguro no está configurado correctamente” en Windows 8.1 manualmente

Hace solo algunos días que finalmente se lanzó Windows 8.1 como Disponibilidad General (17 de Octubre), y como era de esperarse, los problemas no tardaron en llegar a los diferentes Foros, empezando por supuesto, los de Microsoft Community. Aunque esto es perfectamente normal en cada lanzamiento, debido tantos escenarios donde se prueba el sistema operativo, también suelen verse determinados problemas que empiezan a ocurrirle a gran cantidad de las personas, problemas que eventualmente se pueden convertir en un bug, y después en alguna KB de Microsoft, acompañado de un fix oficial.

Sin embargo, hay que tener en cuenta que también sucede que es un cambio de característica en el sistema operativo y nos empieza a confundir mientras se liberan las palabras oficiales por parte de los equipos de producto. De cualquier forma, siempre sale algún workaround desde la comunidad.

Hoy quiero enfocarme a un problema que surgió desde el mismo día de lanzamiento y conforme van actualizando más usuarios a 8.1, se vuelve más común y claro está, empieza la insatisfacción por no tener una respuesta oficial de Microsoft.

[Actualización]

El día de ayer (28/10/2013), Microsoft finalmente ha liberado una KB donde se aborda este problema: http://support.microsoft.com/kb/2902864 

Esta KB incluye el Hotfix (actualización) encargado de quitar de una forma limpia la marca de agua en Windows 8.1/Server 2012 R2. La descarga a continuación:

Para Windows 8.1 de 32 bits:
http://www.microsoft.com/es-es/download/details.aspx?id=40878

Para Windows 8.1 de 64 bits:
http://www.microsoft.com/es-es/download/details.aspx?id=40879

Para Windows Server 2012 R2:
http://www.microsoft.com/es-es/download/details.aspx?id=40880

Dejo el artículo como referencia técnica, pero bastará con lo anterior para solucionar el problema.

*Importante:

La siguiente parte del artículo describirá una solución al problema poco ortodoxa, que implica manipular archivos importantes del sistema operativo y que por ende, puede ocasionar otros problemas si no se manipula con precausión. Este procedimiento además no representa una recomendación oficial de Microsoft (¡No hago parte de la compañía!), no está soportado y debe hacerse bajo su propio riesgo.

El problema

Después de una actualización a través de la tienda a Windows 8.1, o una implementación en limpio, sobre equipos actuales (menos de uno o dos años de comprados), algunos usuarios están viendo una marca de agua en la parte inferior derecha del escritorio similar a esta:

image

FileDownloadHandler

En inglés:SecureBoot isn’t configured correctly”.

En español:El Arranque seguro no está configurado correctamente”.

En la Marca de Agua, como pueden ver, también aparece la edición instalada del sistema operativo junto con el número de compilación, que en este caso es 9600.

La primera y la última son normales cuando la instalación corresponde a una versión de evaluación, o como en muchos casos, cuando el equipo no se encuentra activado; la solución pasa entonces por realizar el proceso de activación y después de un reinicio desaparece.

Ahora, el mensaje de Arranque Seguro es completamente nuevo, aunque desde Windows 8 se encontraba listo para mostrarse y el verdadero problema, es que toda la marca de agua está saliendo en equipos que incluso están correctamente licenciados.

La causa

En pocas palabras, la marca de agua se origina por causa de una característica introducida en Windows 8 llamada Arranque Seguro (Secure Boot). Se encuentra disponible solo en equipos que su firmware es basado en UEFI y se encarga básicamente de hacer una comprobación para evitar que código no autorizado se ejecute en el tiempo de arranque. Quiere decir que verifica el ROM del fabricante, sus aplicaciones UEFI y por supuesto el sistema operativo con una base de datos conocida por el firmware.

Como el Arranque Seguro tiene componente físico y lógico, es necesario que esté activado en la BIOS para poder funcionar; pero, a partir de Windows 8.1 (por lo que se está viendo), cuando el Arranque Seguro se encuentra deshabilitado desde la BIOS, una vez Windows se encuentre instalado, mostrará esta marca de agua indicando que no está configurado correctamente y, eso es independiente de si el equipo está o no activado.

Microsoft recientemente se pronunció al respecto a través del siguiente artículo de TechNet:
Secure Boot isn’t configured correctly watermark on the desktop

¿Cuál es la solución? A pesar de que el procedimiento varía dependiendo del modelo de equipo que cada uno tenga, es necesario entrar hasta la BIOS y proceder a habilitar nuevamente el Arranque Seguro para que Windows sea notificado y no muestre más la molesta marca de agua en el próximo reinicio.

*Nota: Ver los manuales de su fabricante para saber cómo activar el Arranque Seguro o Secure Boot si está en inglés.

El problema (Segunda parte)

Hay usuarios que indican el mismo problema, pero sucede que o no tienen ninguna configuración de Arranque Seguro (Secure Boot) disponible en la BIOS, o se encuentra completamente deshabilitada. Ahí es donde empieza la insatisfacción mencionada al comienzo de este artículo.

*Nota: Algunos pueden ver la opción deshabilitada porque tienen un tipo de BIOS mixta, y pueden tener el sistema operativo instalado en Legacy Mode.

La solución

Cuando no hay nada más para hacer, es necesario recurrir a procedimientos un poco más complejos, pero que representan una solución parcial o total.

El mensaje de la marca de agua reside principalmente en los archivos: shell32.dll.mui y basebrd.dll.mui.

En los archivos .mui se encuentran todos los recursos que el módulo utiliza en el respectivo idioma del sistema operativo, quiere decir que varía de acuerdo al idioma, también en su ubicación.

Shell32.dll.mui está en el directorio C:WindowsSystem32<Idioma>. Donde <Idioma> es la terminación de acuerdo al lenguaje para mostrar que tengamos, por ejemplo en-US para inglés, o es-ES para español.

Basebrd.dll.mui está en el directorio C:WindowsBrandingBasebrd<Idioma>. Donde <Idioma> es igualmente en-US o es-ES según el caso.

El procedimiento consiste en abrir manualmente estos dos archivos, quitar el texto correspondiente a la marca de agua y remplazarlos por el original para que Windows no tenga de dónde escribir la marca de agua en cada fondo de pantalla.

Requerimientos y recomendaciones

1. Utilizar una cuenta perteneciente al grupo de Administradores locales.

2. Descargar e instalar Resource Hacker. Link de la web oficial:
http://www.angusj.com/resourcehacker/reshack_setup.exe

3. Descargar PsExec de Sysinternals:
http://technet.microsoft.com/en-us/sysinternals/bb897553

Luego descomprimimos y copiamos psexec.exe al directorio C:WindowsSystem32

*Nota: Es muy importante asegurar el paso 3. Windows pedirá confirmación para copiar el archivo en System32.

4. Opcional: Crear un punto de restauración antes de proceder a manipular los archivos. Aquí un artículo con el paso a paso de Refresh (sigue igual en 8.1):
http://geeks.ms/blogs/checho/archive/2012/02/29/configurando-reset-y-refresh-en-windows-8-consumer-preview.aspx

5. Crear una carpeta en la unidad C: llamada Fuentes (C:Fuentes).

6. Realizar una copia de los archivos originales antes de manipuarlos.

Procedimiento

Si el equipo está en español:

Navegar hasta el directorio C:WindowsSystem32es-ES, copiar el archivo shell32.dll.mui a la carpeta C:Fuentes creada desde los requerimientos.

Navegar hasta el directorio C:WindowsBrandingBasebrdes-ES, copiar basebrd.dll.mui a la carpeta C:Fuentes creada desde los requerimientos.

Si el equipo está en inglés:

Navegar hasta el directorio C:WindowsSystem32en-US, copiar el archivo shell32.dll.mui a la carpeta C:Fuentes creada desde los requerimientos.

Navegar hasta el directorio C:WindowsBrandingBasebrden-US, copiar basebrd.dll.mui a la carpeta C:Fuentes creada desde los requerimientos.

Deberán terminar con los dos archivos copiados en la carpeta Fuentes, así:

image

Desde la Pantalla de Inicio, buscar Resource Hacker, clic derecho y Ejecutar como administrador:

image

*Nota: Clic en el botón del Control de Cuentas de Usuario para elevar los privilegios.

Clic en el menú File, seleccionar Open, navegar hasta C:Fuentes, indicar en la parte inferior All files (*.*) donde dice Tipo; seleccionar shell32.dll.mui y clic en el botón Abrir:

image

*Nota: Si no se indica como tipo All files (*.*), no se verán los dos archivos en la carepta.

Si el equipo está en español:

Expandir el nodo de String Table dentro de Resource Hacker, buscar la carpeta de 2070 y clic en 3082. En el panel derecho deben ver varios textos, incluidos el del Arranque Seguro:

P1

Si el equipo está en inglés:

Expandir el nodo de String Table dentro de Resource Hacker, buscar la carpeta de 2070 y clic en 1033. En el panel derecho deben ver varios textos, incluidos el de Secure Boot:

P2

Lo que haremos será indicar como vacío (“ “) las siguientes cadenas:

En español:

«%ws Build %ws»
«El Arranque seguro no está configurado correctamente”

En inglés:

«%ws Build %ws»
«SecureBoot isn’t configured correctly»

Debería verse así:

image

*Nota: Independiente del idioma, noten que es la primera y la última.

Una vez hecho esto, hacemos clic en el botón Compile Script en la parte superior:

image

Notarán que al copilar, el botón pasará a estar en gris nuevamente. Finalmente, clic en el menú File y Save (CTRL + S):

image

En la carpeta C:Fuentes, verán dos archivos similares, uno llamado shell32.dll.mui y shell32.dll_original.mui. El primero es el modificado y el segundo, es el archivo original de Windows. Aunque trabajaremos con el primero, es bueno dejar a salvo el otro también.

Clic en el menú File, luego Open, buscamos la carpeta C:Fuentes, indicamos All files (*.*) en el Tipo y abrimos esta vez el archivo basebrd.dll.mui

image

Si el equipo está en español:

Expandimos el String Table, luego el nodo 1 y clic en 3082. Veremos el texto correspondiente a las ediciones de Windows 8.1:

image

Si el equipo está en inglés:

Expandimos el String Table, luego el nodo 1 y clic en 1033. Veremos el texto correspondiente a las ediciones de Windows 8.1:

image

En las líneas 12 y 13, les aparecerá repetido el nombre de su edición instalada, así que probablemente, a diferencia de las capturas, vean Windows 8.1 o Windows 8.1 PRO.

La línea 12, como hicimos en shell32.dll.mui, la dejaremos como vacía (“ “), así:

image

Después de esto, clic en el botón Compile Script, y finalmente, clic en el menú File, Save

image

Cuando esté guardado, debemos ver una copia de basebrd.dll.mui también en la carpeta Fuentes. En total serán 4 archivos:

image

Tanto shell32.dll.mui como basebrd.dll.mui deben ser remplazados por los originales pero, para poder hacer esto, es necesario tomar posesión y garantizar permisos, ya que el propietario es TrustedInstaller.

La siguiente parte se puede hacer de forma gráfica, pero toma más pasos, así que lo haremos desde el Símbolo del Sistema con el fin de minimizar la probabilidad de error. Para esto:

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

image

En la consola ejecutamos (de acuerdo al idioma):

Si el equipo está en español:

takeown /f C:WindowsSystem32es-ESshell32.dll.mui

Luego:

takeown /f C:WindowsBrandingBasebrdes-ESbasebrd.dll.mui

image

Si el equipo está en inglés:

takeown /f C:WindowsSystem32en-USshell32.dll.mui

Luego:

takeown /f C:WindowsBrandingBasebrden-USbasebrd.dll.mui

image

*Nota: El usuario indicado por la consola varía para cada uno. Les debe decir que fue correcto.

Ejecutamos ahora cls para limpiar todo lo hecho y posteriormente (de acuerdo al idioma):

Si el equipo está en español:

icacls C:WindowsSystem32es-ESshell32.dll.mui /grant Administradores:F

Luego:

icacls C:WindowsBrandingBasebrdes-ESbasebrd.dll.mui /grant Administradores:F

image

Si el equipo está en inglés:

icacls C:WindowsSystem32en-USshell32.dll.mui /grant Administrators:F

Luego:

icacls C:WindowsBrandingBasebrden-USbasebrd.dll.mui /grant Administrators:F

image

Con todo lo anterior –para los que se pregunten-, hemos garantizado tanto la propiedad como los permisos totales sobre el archivo, de esta forma podremos remplazarlo por el que modificamos previamente.

Desde la misma consola y teniendo en cuenta que ene l paso 3 de los requerimientos copiamos el ejecutable de psexec.exe a la carpeta de System32, ejecutamos:

PsExec.exe –SID cmd.exe

Se debe abrir otro símbolo del sistema nuevo:

image

*Nota: El nuevo símbolo del sistema ahora tendrá privilegios de System, es decir, más podermosos que el mismo administrador.

*Importante: En este punto es donde es importante respaldar los archivos originales de shell32.dll.mui y basebrd.dll.mui.

Cerramos el Símbolo del Sistema desde donde se lanzó PsExec y en la nueva consola ejecutamos:

Si el equipo está en español:

DEL C:WindowsSystem32es-ESshell32.dll.mui

Luego:

DEL C:WindowsBrandingBasebrdes-ESbasebrd.dll.mui

image

Si el equipo está en inglés:

DEL C:WindowsSystem32en-USshell32.dll.mui

Luego:

DEL C:WindowsBrandingBasebrden-USbasebrd.dll.mui

image

Con la herramienta DEL lo que hicimos fue borrar los archivos originales de shell32.dll.mui y basebrd.dll.mui y nuestro último paso es finalmente copiar los dos archivos que modificamos en los primeros pasos  a esa misma ubicación, es decir, de la carpeta Fuentes, a la respectiva en System32 y Basebrd.

Si quieren aprovechar el símbolo del sistema para automatizar esto también, ejecutamos:

Si el equipo está en español:

copy C:Fuentesshell32.dll.mui C:WindowsSystem32es-ES

Luego:

copy C:Fuentes:basebrd.dll.mui C:WindowsBrandingBasebrdes-ES

image

Si el equipo está en inglés:

copy C:Fuentesshell32.dll.mui C:WindowsSystem32en-US

Luego:

copy C:Fuentes:basebrd.dll.mui C:WindowsBrandingBasebrden-US

image

Es muy probable que aún después de reiniciar Windows, continúen viendo la marca de agua correspondiente a la compilación y al mensaje de arranque seguro:

image

No hay por qué preocuparse, porque nos falta un paso primordial para reconstruir el caché y que desaparezca la marca por completo. Para esto, clic derecho en el botón de Inicio y nuevamente clic en Símbolo del sistema (administrador). En la consola ejecutamos:

mcbuilder

image

Notarán que tarda algunos segundos, tiempo que es completamente normal.

Reiniciamos el equipo otra vez y una vez hecho, nuestra marca de agua habrá desaparecido:

image

Hay una consecuencia que se debe tener en cuenta al borrar la marca de agua manualmente, y es que en las Propiedades del sistema no aparecerá la edición de Windows:

image

La razón es que Windows lee el texto también de shell32.dll.mui y al borrarlo, desaparece de ambas partes. Si pueden vivir con eso… =)

Espero les sea de utilidad.

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

Saludos,

Checho

Integrar Windows Server 2012 R2 y Windows 8.1 Enterprise en un mismo medio de instalación

El día de ayer, 17 de Octubre de 2013 se lanzó oficialmente Windows 8.1, que a diferencia del RTM liberado hace poco, la Disponibilidad General (GA) marcan los bits finales del producto. Hoy 18 de Octubre se empiezan a liberar los medios físicos para los que desean tener Windows 8.1 y vienen de versiones anteriores como Windows 7, Vista y XP.

Naturalmente, los que tengan acceso a Suscripción MSDN/TechNet o licenciamiento por volumen, ya pueden descargar la edición Enterprise y Datacenter de Windows 8.1 y Server 2012 R2 respectivamente. Por otro lado, Microsoft liberó una descarga gratuita con un período de prueba para ambas versiones, para que toda empresa o entusiasta que desee probar el producto antes de aquirirlo, lo pueda hacer. Más adelante pondré los enlaces.

*Nota: Recordemos que la actualización es totalmente gratuita para los que vienen de Windows 8 y Server 2012.

Ahora, en el mundo IT Pro, es normal que a parte de un método de implementación, tengamos algunos medios aparte para hacer la instalación de ámbos productos, como para un laboratorio, por ejemplo. Aprovechando que desde Windows Vista, tanto la versión Cliente como Servidor comparten un mismo Kernel, podemos jugar con eso y crear un medio de instalación desde donde podamos seleccionar qué versión instalar (Servidor o Cliente) y mantener una sola imagen con un peso considerablemente bajo.

En este artículo pasaré a explicar cómo podemos hacer esto con una serie de pasos utilizando DISM (incluido en el ADK), enfocándome en Windows 8.1 Enterprise y Windows Server 2012 R2, pero se puede conseguir lo mismo con 7, 8, Server 2008 R2 y Server 2012.

Requerimientos

– Un equipo técnico donde esté instalado el ADK para Windows 8.1. Si aún no lo tienen, pueden descargarlo desde aquí:
http://www.microsoft.com/en-us/download/confirmation.aspx?id=39982

– Medio de instalación de Windows 8.1 Enterprise de 32 bits (x86). Pueden descargar el período de prueba gratuito desde aquí:
http://technet.microsoft.com/es-ES/evalcenter/hh699156.aspx

– Medio de instalación de Windows Server 2012 R2. Pueden descargar un período de prueba gratuito desde aquí:
http://technet.microsoft.com/es-ES/evalcenter/dn205286.aspx

– Un equipo de referencia donde se pueda hacer el despliegue. Puede ser una máquina virtual.

*Nota: Para utilizar DISM, no es necesario tener el ADK instalado, pero sí para generar el medio de instalación posteriormente.

Copiando archivos de instalación a carpetas locales

Ya que es necesario interactuar con las imágenes (.WIM), debemos copiar los archivos de instalación de Windows 8.1 y Server 2012 R2 a un directorio local. Para este artículo, y con el objetivo de unificar los comandos y que sean más fáciles de seguir, crearemos dos carpetas en la unidad C: llamadas: 81 y R2.

Desde nuestro equipo técnico, ojalá con Windows 8/8.1, montamos las dos imágenes correspondientes a Windows 8.1 Enterprise y Server 2012 R2, desde la Pantalla de Inicio abrimos un Símbolo del Sistema con privilegios elevados (Clic derecho, Ejecutar como administrador) y ejecutamos:

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

xcopy <UnidadServ>*.* /s/e/f C:R2

Donde <UnidadWin> corresponde a la unidad virtual donde está montado el medio de Windows 8.1 Enterprise y <UnidadServ> a la unidad de Server 2012 R2.

Para mi caso, la unidad de Windows era la G: y la de Server H: así que los comandos serían:

xcopy G:*.* /s/e/f C:81

image

xcopy H:*.* /s/e/f C:R2

image

*Nota: El tiempo de copiado depende de la velocidad de escritura y lectura del disco local.

Exportando la versión de de Server a una sola imagen

El “truco” conciste básicamente en tener una imagen base, que debe ser de 32 o de 64 bits y exportar la instancia de la edición de Windows Server. Si queremos además agregar múltiples arquitecturas, la imagen base debe ser de 32 bits, para que soporte x86 y AMD64.

*Nota: Recordemos que una imagen de Windows puede contener múltiples ediciones del sistema operativo, puesto que entre todas comparten los mismos recursos necesarios para la instalación, es por esto que el peso no se hace demasiado grande.

Lo que haremos será exportar la imagen de Server 2012 desde su install.wim, a la imagen de Windows 8.1 Enterprise utilizando DISM. Antes de esto, es necesario reconocer el índice correspondiente a la edición que deseamos exportar, ya que una imagen de Server tiene ediciones Core y con GUI (Interfaz). Para esto, ejecutamos el siguiente comando desde un Símbolo del Sistema con privilegios elevados:

Dism /Get-ImageInfo /ImageFile:C:R2Sourcesinstall.wim

image

Noten que las ediciones que están en Consola terminan con la palabra CORE y según el resultado, las ediciones que manejan interfaz tienen como índice el 2 y el 4, dependiendo si vamos a instalar STANDARD o DATACENTER. Para este artículo utilizaré el índice de la edición DATACENTER (4), pero ya cada quién elegirá el deseado.

Ya teniendo presente el índice de la edición que vamos a exportar, ejecutamos:

Dism /Export-Image /SourceImageFile:C:R2Sourcesinstall.wim /SourceIndex:4
/DestinationImageFile:C:81Sourcesinstall.wim

image

La forma más fácil de verificar que todo salió bien, es utilizando Get-ImageInfo con la imagen de Windows 8.1, y deberíamos ver ya las dos imágenes de cada versión con su respectivo índice:

image

Editando o creando el archivo EI.cfg

El archivo de Configuración de Edición (ei.cfg), se utiliza para especificar la edición de Windows durante la instalación, es decir, gracias a este archivo es que el medio de instalación sabe qué edición debe mostrar, así tenga varias incluídas, como en el medio de Windows 8.

Hasta Windows 7, este archivo estaba presente en casi todos los medios de instalación (por no decir todos), pero en Windows 8 hacia adelante, solo se encuentra en los archivos de instalación de la edición Enterprise.

Lo que debemos hacer, es crearlo o editarlo dependiendo de las ediciones que estemos mezclando; para este artículo, que estamos trabajando con Enterprise, vamos al directorio C:81Sources, hacemos clic derecho sobre EI.cfg, seleccionamos Abrir con y utilizamos el Bloc de Notas. Debemos ver algo similar a esto en su contenido:

image

*Nota: Si al darle “Abrir con” no vemos el Bloc de Notas, hacemos clic en “Mostrar más opciones” par desplegar la lista completa.

Basta entonces con quitar la palabra “Enterprise” debajo del parámetro [EditionID], utilizado precisamente para indicar el Identificador (ID) de la Edición de Windows. Quedaría entonces así:

image

Después de esto, hacemos clic en el menú Archivo > Guardar. Esto guardará el cambio sobre el archivo que ya está ubicado en el directorio Sources.

*Importante: Para los que no lo estén haciendo con Enterprise, es decir, que estén utilizando una imagen de 8/8.1 PRO, deben pegar este contenido en el Bloc de Notas (Lo que hay después y antes de la línea):


[EditionID]

[Channel]
Retail

[VL]
0


Clic en el menú Archivo > Guardar como, cambiar el tipo de archivo a Todos los archivos (*.*), indicarle el nombre de: EI.CFG y ponerlo en el directorio C:81Sources

image

Creando la imagen de instalación

El último paso es crear otra vez la imagen (.ISO) para la instalación. Desde la Pantalla de Inicio, buscamos Deployment and Imaging Tools Environment, clic derecho y Ejecutar como administrador.

image

En el Símbolo del Sistema digitamos:

oscdimg –bC:81BootEtfsboot.com –u2 –h C:81 C:Win81R2.iso

image

*Nota 1: El nombre “Win81R2.iso” puede variar, desde que se respete la extensión .iso.

*Nota 2: Crear la imagen es necesario solo si se grabará en algún DVD, o si se desea tener como .ISO; en caso de que la idea sea desplegarlo desde una USB, basta con preparar el dispositivo y copiar todos los archivos de la carpeta C:81. Pueden ver un paso a paso de cómo prepar un dispositivo en este artículo que escribí hace un tiempo:
http://www.fermu.com/es/articulos/windows/articulos-y-tutoriales/831-preparar-dispositivo-usb-manualmente-para-instalaci%C3%B3n-de-windows-8

Probando la instalación

Si todo sale bien, el asistente de instalación debe ser el de Windows 8.1, pero después de darle clic al botón de Instalar ahora, nos debe aparecer la ventana de selección donde podremos escoger qué versión de Windows deseamos desplegar:

image

Espero sea de utilidad.

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

Saludos,

Checho

Configurando Acceso Asignado en Windows 8.1 a través de PowerShell

Hace unos días pude exponer aquí una de las características más interesantes con respecto a la actualización de Windows 8.1, conocida como Assigned Access o Acceso Asignado en español. Lo que hicimos fue crear una cuenta y establecerle el Acceso Asignado desde el asistente de Windows 8.1, pero como sé que cada vez hay más amantes de PowerShell, les gustará saber que utilizando unos nuevos cmdlets podrán configurar y personalizar también Acceso Asignado. En este artículo describiré el paso a paso.

Requerimientos

1. Windows 8.1 RT, Windows 8.1 PRO o Windows 8.1 Enterprise; todos en su actual estado de RTM ya que el Preview no tiene habilitado esta característica.

2. Una cuenta local y estándar. Acceso Asignado no se puede establecer sobre una cuenta administrativa o de dominio.

3. Windows PowerShell

*Importante: Como lo expliqué en “Creando usuario estándar” desde el anterior artículo, es primordial iniciar por primera vez con la cuenta estándar para que Windows pueda aprovisionar e instalar las aplicaciones de interfaz moderna.

*Nota: Toda la configuración debe hacerse desde una cuenta que pertenezca al grupo de administradores.

Acceso Asignado con PowerShell

Indentificando el nombre de la aplicación a establecer

Antes de proceder a configurar Acceso Asignado, es necesario saber qué aplicación de interfaz moderna vamos a establecer como predeterminada, pues Windows tienen una gran cantida preinstaladas, pero bien podría ser una aplicación desarrollada internamente, o descargada de la Tienda de Windows.

Una aplicación de Interfaz Moderna se puede identificar de dos formas: el nombre de la aplicación (AppName), o el Application User Model ID, que es básicamente el identificador único que tiene cada una. Lo ideal es utilizar el nombre, pero los navegadores por ejemplo, solo se les puede identificar por el AppUserModelID.

Suponiendo primero que vamos a indicarle una aplicación diferente a navegadores, la forma más fácil de encontrar todos los nombres disponibles, es haciendo una consulta con el cmdlet Get-AppxPackage y el nombre de usuario, por ejemplo, para mi usuario Kiosk el comando sería:

Get-AppxPackage –User Kiosk

AA1

*Nota: Vale aclarar que en la captura solo se muestran dos aplicaciones, pero la lista es bastante más larga.

Lo que tenemos que hacer es identificar el apartado de “Name” correspondiente a la aplicación que deseamos y posteriormente asociarla al usuario para el Acceso Asignado.

Si lo que deseamos es identificar la aplicación por el ID, podríamos hacer la consulta desde un Símbolo del Sistema con privilegios elevados ejecutando:

reg query HKEY_CURRENT_USERSoftwareClassesActivatableClasses
Package /s /f AppUserModelID | find "REG_SZ"

image

*Nota: Sin importar cuántos navegadores tenemos instalados, solo podremos ver el que esté predeterminado y tenga su versión de interfaz moderna. Pueden encontrar más información acerca de las consultas sobre el AppUserModelID aquí:

http://technet.microsoft.com/en-us/library/dn465331.aspx#BKMK_FindAUMID

Nosotros podemos ir manualmente hasta la clave:

HKEY_CURRENT_USERSoftwareClassesActivatableClassesPackage

Allí podemos expandir cada paquete y dentro de la sub-clave Server encontraremos todos los detalles de la aplicación en su primera sub-clave. Por ejemplo, para el navegador predeterminado:

image

Configurando desde PowerShell

En la cuenta administrativa, buscamos PowerShell desde la Pantalla de Inicio, clic derecho y Ejecutar como Administrador (Run as administrator):

image

Siguiendo con el ejemplo de las capturas, para establecer la primera aplicación con el atributo de –AppName, debemos utilizar el cmdlet Set-AssignedAccess (Nuevo en PowerShell para 8.1) de la siguiente forma:

Set-AssignedAccess -AppName Microsoft.BingFinance -UserName Kiosk

*Nota: Kiosk, como en el anterior comando, corresponde al usuario local estándar y Microsoft.BingFinance es el nombre de la aplicación.

image

Si es necesario el ID, con el AppUserModelId como cuando vamos a establecer un navegador para el Acceso Asignado, haríamos uso del mismo cmdlet Set-AssignedAccess pero con una pequeña variación que implica el AppUserModelId y usuario. Por ejemplo, si tenemos instalado Google Chrome y deseamos que esa sea la aplicación de Interfaz Moderna que se lance con Acceso Asignado, el comando sería:

Set-AssignedAccess -UserName Kiosk -AppUserModelId
'DefaultBrowser_NOPUBLISHERID!Chrome'

image

*Nota 1: Nuevamente, Kiosk corresponde a la cuenta estándar, así que varía.

*Nota 2: Pueden hacer clic en la imagen si desean verla de tamaño completo.

Para Internet Explorer, solo se debe cambiar el último nombre del ID por:

‘DefaultBrowser_NOPUBLISHERID!Microsoft.InternetExplorer.Default’

Si es el caso que no les gusta Internet Explorer o Google Chrome y son amantes de Firefox, pueden bajar la última liberación Beta llamada Firefox Aurora y como ya tiene su versión de Interfaz Moderna, el AppUserModelId sería:

‘DefaultBrowser_NOPUBLISHERID!1E05176855CC7D2F’

¡Todo listo! Para comprobar que Acceso Asignado haya quedado configurado correctamente, podemos seguir los pasos del artículo anterior para llegar hasta “Configurar una cuenta para Acceso Asignado” y ver que en efecto esté la aplicación indicada a través de PowerShell:

image

Así luciría la aplicación de Chrome en Interfaz Moderna con Acceso Asignado:

image

*Nota: ¿Bastante fea, no les parece?

Notas finales e importantes

1. Si se preguntan cómo salirse de un usuario que tiene Acceso Asignado, la forma soportada es presionando cinco (5) veces seguidas la tecla de Windows, así volverá a la pantalla de inicio de sesión y podrán reiniciar o cambiar al usuario administrador.

2. Si el navegador predeterminado para Acceso Asignado (como lo mostré en este artículo) es diferente a Internet Explorer, es necesario que previamente desde el usuario estándar se haya configurado para ser el predeterminado, pues de lo contrario la aplicación no iniciará y siempre habrá un cierre de sesión.

*Nota: Este segundo punto puede variar de aquí a la liberación general de Windows 8.1, y para no extender más este artículo, decidí no abordar el tema, pero lo estaré investigando un poco más a fondo para ver si se trata de un fallo o comportamiento natural.

3. Siempre que se quiera cambiar la aplicación para Acceso Asignado hay que cambiar al Administrador, realizar el procedimiento y reiniciar el equipo antes de iniciar con el usuario estándar.

Espero sea de utilidad.

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

Saludos,

Checho

La extraña ventana de Desktop.ini al iniciar sesión en Windows 8, Process Monitor y su solución

Con el caso que pasaré a exponer, quiero mostrar un poco la importancia de tener precaución al momento de realizar pruebas que impliquen algún cambio en el sistema operativo, sin pleno conocimiento de lo que hará. No siempre hay que creer todo lo que se lee, ni siquiera en páginas confiables, dará resultados positivos.

El problema

Al igual que muchos otros casos que he documentado a través de este espacio, este problema surgió de una consulta en los Foros de Microsoft Community destinados a Windows 8, lugar donde pueden encontrar respuestas a distintos inconvenientes relacionados con el sistema operativo.

El problema en cuestión, empezó después de que el usuario con el objetivo de buscar alguna infección de malware oculta, ejecutó el comando: Attrib –s –r –h /d / *.* sobre la raíz del sistema operativo, es decir, sobre C:, quiere decir que mostraría todas las extensiones ocultas y protegidas por el sistema y las cambiaría a visibles –incluyendo las que tenían atributos del sistema.- Después de reiniciar el equipo, y en cada arranque posterior, salía una extraña ventana en el Bloc de Notas con título “desktop” y con un contenido particular:

image

Texto: ”[.ShellClassInfo]
LocalizedResourceName=@%SystemRoot%system32shell32.dll,-21787”

*Nota: A algunas personas, en vez de una ventana pueden salir dos con el mismo cotenido.

No importa de qué forma reiniciara o apagara el equipo, siempre se ejecutaba la misma ventana y no volvía a aparecer después de cerrarla.

La causa

Me atrevería a decir que alrededor del 85% de los casos en que sale algún tipo de mensaje de error o ventana desconocida justo después de iniciar sesión, se debe a algún script o proceso que está arrancando con el usuario, tal cuál se configuran muchas aplicaciones de mensajería por ejemplo. Dicho esto, y teniendo en cuenta que la pestaña de Inicio en MSCONFIG (hasta Windows 7) o en el Administrador de Tareas (a partir de Windows 8) poco o nada sirven para identificar realmente qué es lo que se ejecuta al iniciar sesión, la herrramienta más pertinente suele ser AutoRuns, parte de la suite de Sysinternals.

Como AutoRuns puede identificar muchas más ubicaciones donde un Malware o proceso puede correr, además de aspectos como Tareas Programadas o extensiones en el Explorador de Windows (muy útil cuando hay crash), es poco probable que si un archivo con el nombre de desktop, o por lo menos un proceso que referenciara esa ubicación tenía establecido el inicio pudiera ocultarse; sin embargo, cuando pude tener el Log capturado por parte del usuario, me sorprendí muchísimo al ver que en la pestaña de Log on (o en cualquier otra) no hubiera referencia alguna del archivo:

image

¿Cómo podía identificar qué era, si niquiera sabía desde dónde se estaba ejecutando? Como AutoRuns no me dio la respuesta, tenía que intentar identificar el proceso padre que lanzaba el archivo, así que sin cerrar el mensaje al iniciar sesión, le pedí al usuario ejecutar Process Explorer – también de Sysinternals – y utilizar la característica de Find Window’s Process con el fin de seleccionar la ventana del Bloc de Notas y que mostrara el proceso asociado, y obtuve algo similar a esto:

image

Para mi sorpresa, el proceso que estaba lanzando el Bloc de Notas (notepad.exe) era explorer.exe, correspondiente al Explorador de Windows, lo que hacía el tema un poco más frustrante, pues normalmente desde Process Explorer se podría analizar la firma digital y verificar la validez del proceso, pero en este caso incluso eso lo mostró como Verificado:

image

Esto quería decir que muy probablemente no era Malware, pues era Windows el que estaba lanzando el proceso de notepad.exe para abrir el archivo y mostrar su contenido.

Con AutoRuns y Process Explorer descartados –cosa que suele pasar muy pocas veces-, el camino a tomar sería monitorear el sistema operativo al iniciar sesión para tratar de entender en qué momento se estaba abriendo o generando el archivo, dónde se encontraba y cómo se ejecutaba. Naturalmente, la herramienta por excelencia para responder eso se llama Process Monitor, – sí, de Sysinternals también- utilizando la característica de Enable Boot Loggin ubicada en el menú Options; de esta forma, Process Monitor sitúa su controlador (PROCMON.SYS) justo antes que todos los otros que inician con Windows y captura todo lo que se haga aún en el proceso de Winlogon:

image

Debido a que la traza capturada por Process Monitor es enorme, más aún cuando se utiliza el Boot Logging, es necesario jugar con los Filtros que se pueden establecer yendo al menú Filter > Filter o presionando las teclas CTRL + L. Como ya sabía (gracias a Procexp) que el proceso era notepad.exe (aunque eso podía ser algo lógico), establecí el filtro como Process Name > is > NOTEPAD.EXE, así sólo me mostraría la actividad hecha por el Bloc de Notas:

Pp1

*Nota: La traza se debía capturar hasta después de que saliera la ventana.

Lo siguiente era buscar por un nombre específico, y claro está, sería: desktop. Para mi gran fortuna, el primer resultado arrojó la respuesta que estaba buscando:

image

*Nota: Clic en la imagen para verla en tamaño real.

Según Process Monitor, Windows estaba abriendo un archivo llamado desktop.ini, ubicado en la carpeta de Startup en el directorio:
C:UsersNANDO19AppDataRoamingMicrosoftWindowsStart MenuPrograms

*Nota: El nombre “NANDO19” varía, pues es el nombre de usuario.

Navegando manualmente al directorio, encontraría el archivo referenciado y como esperaba, con el contenido exacto que mostraba al iniciar sesión, es decir, el archivo que se estaba ejecutando al arrancar.

La solución

Como el archivo siempre está en la misma ruta, la solución fue relativamente sencilla, y lo es para el que esté experimentando este mismo problema:

Desde el Explorador de Archivos, navegar hasta la ruta:

C:UsuariosNombreAppDataRoamingMicrosoftWindowsMenú de inicioProgramasInicio

Donde “Nombre” corresponde al usuario de cada uno, por ejemplo: Checho, NANDO19, etc.

Allí hacemos clic derecho sobre el archivo desktop.ini y seleccionamos Eliminar:

image

Reiniciamos el equipo y el problema debería estar solucionado.

Espero sea de utilidad.

*Nota: Espero dedicar un futuro artículo a la carpeta de Startup o Inicio, ya que presenta características únicas y muy interesantes.

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

Saludos,

Checho