Checho's Blog

El mensaje de error al intentar predeterminar un programa sobre los archivos en Windows 8, Process Monitor y su solución

2013-05-16T22:05:00Z

Uno de los cambios más sutiles, pero de gran trascendencia en Windows 8, es la asociación neutral que ahora tienen los archivos; es decir, la mayoría no tiene una predeterminada como sucedía en todas las versiones anteriores. Esto ayuda a que no se den fallos en asociación errónea de los archivos (Problema muy común en Windows 7), y que el usuario la pueda asignar fácilmente cada que abra por primera vez los diferentes tipos de archivos.

La forma en que se asocian los diferentes programas a las extensiones no ha cambiado, y aunque hay incluso otras maneras de hacerlo en Windows 8 (Utilizando PowerShell, por ejemplo), las más comunes suelen ser: Ir a las propiedades del archivo haciendo clic derecho, Propiedades, y haciendo clic en el botón Cambiar, o bien haciendo clic derecho sobre el archivo, seleccionar Abrir con y darle a “Seleccionar programa predeterminado” si los que están en la lista no nos sirven. En últimas, todas las formas resultan creando la subclave de UserChoice en el registro y el respectivo valor de ProgId para referenciar la aplicación.

El problema

En este caso, que surgió desde un hilo abierto en los Foros de Windows de Microsoft Community, lo que sucedía es que el usuario estaba intentando realizar cambios en el Programa Predeterminado de diferentes archivos, pero al hacer clic derecho, Abrir con, y Escoger programa predeterminado, estaba obteniendo un extraño mensaje de error similar al siguiente:

Inglés:

“This fiel does not have a program associated with it for performing this action. Please install a program or, if one is already installed, create an association in the Default Programas control panel.”

Español:

“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.”

No importaba con qué tipo de archivo intentara hacer el cambio, siempre obtenía el mismo mensaje de error, que sólo permitía aceptar para cerrar.

La causa

Como diferentes alternativas, que iban entre crear un nuevo usuario, hasta probar diferentes modos de abrir el archivo no funcionaban, había que recurrir a la herramienta por excelencia, es decir: Process Monitor de Sysinternals nuevamente.

Como el problema le sucedía en cualquier usuario, se podía concluir que era un evento que afectaba a toda la máquina, y no estaba asociado a una cuenta, por lo que todo lo relacionado a HKEY_CURRENT_USER (HKCU) se podía obviar, y además se manejaba desde el proceso de Explorer.exe, pues no estaba ligado tampoco a una extensión. Esto permitía hacer un filtro más preciso dentro de la traza de Process Monitor, pero para saber con ciencia cierta dónde podía estar el problema, era necesario comparar el comportamiento con un equipo funcional.

Suele ser una gran técnica, pues basta básicamente con correr Process Monitor en el equipo para reproducir el problema, y en un equipo que se pueda abrir la ventana que lanza la opción de Escoger un programa predeterminado y comparar línea por línea. Claro está, existen herramientas muy buenas para esto, como Kdiff3 pero igual requiere tiempo para analizar los resultados en ambos lados.

Después de un buen par de horas, finalmente encontré algo muy interesante dentro de la Traza que me envió el usuario con el inconveniente:

Como ven, el proceso de Explorer.exe, utilizando la operación de RegOpenKey, que hace parte de la API de Win32 para abrir claves de Registro, intentaba abrir la clave de OpenWithSetDefaultOn, ubicada en: HKEY_CLASSES_ROOT\Unknown\shell\Open, pero obtenía el resultado de NAME NOT FOUND; es decir, la clave no existía.

Esta operación era la importante, porque al momento de compararla con un equipo funcional, el resultado era completamente diferente:

La operación no solo era exitosa (SUCCESS), sino que además hacía consultas sobre ella (RegQueryKey), mientras que en la de arriba, la cerraba al no encontrarla. Además de todo esto, HKEY_CLASSES_ROOT se encarga de administrar todas las asociaciones que Windows requiere y utiliza, o las que no están en su equivalente de HKEY_CURRENT_USER.

Efectivamente, cuando en mi máquina funcional eliminé la clave de OpenWithSetDefaultOn, pude reproducir exactamente el mismo mensaje de error, realizando la misma operación.

La solución

Afortunadamente, la solución para este tipo de problemas con asociaciones, como en casi todos los problemas que el registro está involucrado, pasan por restablecer la clave, importándola desde un equipo funcional, y de preferencia, en limpio (Esto evita que la clave o valores ya se hayan modificado, y varíen de los predeterminados).

Para este caso en cuestión, si es que alguna vez llegan aquí porque lo están enfrentando, el procedimiento sería así:

Descargar el archivo Unknown desde aquí:

Descomprimir y ejecutar el archivo Unknown.reg que des comprime. Se deben asegurar que el mensaje de importación correcta aparezca después de la ventana de advertencia por importar claves de registro:

Una vez hecho esto, deberían poder acceder sin problemas a la selección de programas predeterminados desde el clic derecho como siempre:

Espero sea de utilidad.

Saludos,

Checho

El mensaje de Log file de VMware al iniciar Visual Studio 2012 en Windows 8, Process Monitor y su solución

2013-05-11T21:17:00Z

Como siempre he dicho en anteriores artículos relacionados, escribir sobre alguna solución de un problema en Windows, es de lo que más me gusta hacer aquí, pues afrontar algo así, es la mayor fuente de conocimiento que uno puede tener.

Uno de los tipos de problemas más frecuentes con respecto a aplicaciones en Windows, suelen ser los misteriosos mensajes de error, que en algunas veces dicen mucho, pero otras veces, puede ser una excepción no controlada, y por ende, el mensaje no dirá nada. Gran parte de estos errores se pueden subsanar, pues muchos son causados por operaciones incorrectas que hace la aplicación sobre la actual versión del sistema operativo, o bien como en este caso específico, hay problemas de permisos.

Para fortuna de nosotros, Microsoft tiene una cantidad de herramientas y soluciones gratuitas que nos ayudarán a dar una luz a nuestro problema; entre las que más destaco, están: Sysinternals Suite y Application Compatibility Toolkit, incluida en el ADK de Windows 8. Lo más interesante, es que aunque lo ideal siempre es el conocimiento, no es extricatmente necesario tener un grado muy alto para que estas herramientas nos puedan ayudar.

El problema

Regularmente al instalar Windows, vario entre VMware Workstation y Hyper-V, pero también instalo siempre Visual Studio, que hoy por hoy está en versión 2012. VMware tiene unos componentes adicionales para Visual Studio que se pueden agregar mientras se instala la plataforma.

Lo extraño de todo esto, es que después de instalar Visual Studio y VMware con sus respectivos componentes, cada que intentaba abrir la plataforma de desarrollo, estaba recibiendo este mensaje de error:

“An error has ocurred while trying to access the log file. Logging may not function properly.”

Cuando hacía clic en el botón OK (Aceptar), Visual Studio seguía su camino sin ningún problema, pero se empezaba a volver bastante molesto tener que aceptar el mensaje cada vez que se ejecutara la suite de desarrollo.

La causa

Claramente, el complemento de VMware para Visual Studio no podía leer o escribir el archivo de log, lo que no era posible saber, era cuál archivo específico se estaba refiriendo y en qué ruta se encontraba. Para estos casos, donde hay un mensaje de error sin mucho detalle, la mejor herramienta que podemos utilizar es Process Monitor de Sysinternals.

Como Process Monitor detecta todo evento que está sucediendo en el sistema, es normal que no sepamos en estos casos por dónde empezar con millones de resultados en la traza. Para este problema, utilicé una de las características de Process Monitor que permite filtrar por categoría y resultado. Para esto, basta con ir al menú de Tools y seleccionar Count Ocurrences:

Despues de esto, Seleccionar Result dentro del menú desplegable para asegurarnos que son los resultados los que se nos mostrarán y después darle al botón de Count.

Los resultados que yo tuve, se veían así:

Una de las principales causales para este tipo de errores, suelen ser los inconvenientes con permisos NTFS en el sistema operativo, así que el resultado de ACCESS DENIED es bastante útil. Lo que yo hice, fue darle doble clic para que Process Monitor inmediatamente hiciera el filtro por todos los resultados en los que haya recibido como respuesta ACCESS DENIED.

Aunque hubo varios resultados, uno en específico fue el que me llamó la atención:

Como pueden ver en la captura, el nombre del proceso era devenv.exe, perteneciente a Visual Studio, lo que me decía que ocurría este evento mientras estaba en ejecución; lo otro, es que según Path, era un .log el que se estaba tratando de crear (Utilizando la operación de CreateFile), dentro de una carpeta temporal del usuario, pero más interesante aún, es que pertenecía a VMware. El nombre en cuestión era: vmware-vsid-1.log. Para estar más seguro, desde Process Monitor, hice clic derecho a la ruta y seleccioné Jumpt to, que permite navegar hasta el directorio automáticamente, y esto fue lo que vi:

El archivo sí estaba creado dentro del directorio, lo que indicaba que el problema quizá no estaba en su primera creación, sino más bien en la sobreescritura que hacía al iniciar Visual Studio. Para asegurarme de esto, hice clic derecho en el archivo, fui a Propiedades y finalmente a la pestaña de Seguridad para ver cómo estaban los permisos, y esto me encontré:

Windows me indicaba que no tenía permisos de lectura. Si mi usuario (Checho) no podía siquiera leer el contenido, no iba a poder hacer ningún tipo de escritura u operación básica sobre el archivo.

La solución

Ya sabiendo el problema, podía intentar dos cosas, darle los permisos al archivo para que el proceso de Visual Studio pudiera escribir en él, o como era un log, simplemente eliminarlo y esperar a ver qué sucedía al momento de crearse.

Opté por la segunda y lo quité, para posteriormente ejecutar Visual Studio y para mi fortuna, ¡No más mensaje molesto de error!

Al volver a resisar los permisos, todo había cambiado:

Uno más, gracias a Process Monitor.

Saludos,

Checho

Perfil de Usuario Obligatorio en Windows 8

2013-04-28T16:00:00Z

Cada que iniciamos sesión por primera vez en Windows, el sistema crea un perfil de usuario asociado que contiene toda su configuración en el archivo ntuser.dat, ubicado en C:\Users\NombrePerfil, y que a la vez hace el mapeo a la respectiva clave de registro de HKEY_CURRENT_USER, donde Windows guarda y consulta las configuraciones y preferencias de usuario.
Como se habrán dado cuenta, este perfil siempre tiene una configuración particular, es decir, mismo fondo de pantalla, mismas personalizaciones en el Explorador, cursor, accesos directos, etc. Esta es la plantilla predeterminada que entrega Microsoft con el sistema operativo, y el sistema toma esta plantilla del mismo archivo ntuser.dat, pero del perfil predeterminado, ubicado en C:\Users\Default. En este orden de ideas, cada primer inicio de sesión, el sistema genera una copia de ese archivo y lo almacena en la carpeta correspondiente al perfil que está iniciando. Los inicios posteriores solo carga el archivo nuevamente desde su propio directorio.

Existen diferentes tipos de perfiles; los que más conocemos son: Perfiles locales, Perfiles de dominio y los famosos Perfiles rodantes. Todos se basan en el mismo concepto básico que expliqué arriba, pero varían en ubicación, autenticación e interacción. Windows 8 introdujo además una variante para el Perfil local y el de Dominio, y es la posibilidad de iniciar sesión con una cuenta de Microsoft y poder sincronizar configuraciones utilizando la nube entre los distintos equipos en los que se inicie sesión con la cuenta. Algo similar a los Perfiles rodantes, pero sin una ubicación central para guardar el contenido del perfil, y no se mueven los archivos con el perfil, aunque se podría utilizar la aplicación local de Skydrive para suplir esta necesidad.

Aunque cada uno de estos perfiles tiene mucho de qué hablar, hoy nos concentraremos en aprender de un tipo de perfil que se puede utilizar desde los tiempos XP, pero que ahora tiene una forma mucho más fácil de implementarse, y puede ser realmente útil. Se trata del Perfil de Usuario Obligatorio o Mandatory User Profile como se le conoce en inglés.

Windows reconoce que tiene un Perfil Obligatorio cuando el archivo del perfil termina en .man y no en .dat, por ejemplo: ntuser.man. La diferencia con un Perfil Local, es que con un Perfil Obligatorio, el usuario que inicie sesión, podrá realizar cambios en configuraciones, e incluso crear archivos en el Escritorio y en otras ubicaciones del sistema, pero Windows no los guardará al cerrar sesión. La próxima vez que se inicie sesión, Windows descargará de nuevo la copia limpia del perfil que previamente se configuró. Como el Perfil Obligatorio también está basado en la copia original de ntuser.dat del Perfil Predeterminado de Windows, podemos tomar ventaja, personalizarlo para que se adapte a nuestras necesidades, y finalmente convertir la copia en un Perfil Obligatorio.

Para crear y configurar nuestro Perfil Obligatorio, haremos lo siguiente en este post:

- Crear y configurar una cuenta de usuario estándar.
- Crear nuestro perfil de usuario predeterminado.
- Crear Perfil de Usuario Obligatorio.
- Asignar el Perfil de Usuario Obligatorio al Estándar.
- Configurar el Autologon del Usuario Obligatorio.

Crear y configurar una cuenta de usuario estándar

Como es necesario darle unos parámetros personalizados a la cuenta estándar, debemos crearla desde la Consola de Administración, en el nodo de Usuarios y Grupos Locales. Para abrir la consola, podemos ir desde Windows 8 al Panel de Control > Sistema y Seguridad > Plantillas Administrativas > Consola de Administración. También podemos presionas las teclas Windows + R para abrir la ventana de Ejecutar y digitar: compmgmt.msc

Expandimos el nodo de Usuarios y Grupos Locales, clic derecho sobre Usuarios y seleccionamos Nuevo Usuario.

En la ventana de Nuevo Usuario, rellenamos los datos correspondientes con respecto al nombre y contraseña que deseamos, pero además debemos asegurarnos de quitar la selección de “El usuario debe cambiar la contraseña en el primer inicio de sesión”, y seleccionamos: “El usuario no puede cambiar la contraseña”, como también “La contraseña nunca expira”. Después le damos al botón Crear y Cerrar.

Crear nuestro perfil de usuario predeterminado

Este es uno de los escenarios donde crear un perfil predeterminado y personalizado, es de las mejores opciones. Como mencioné en la introducción inicial, Windows predeterminadamente instancia copias del ntuser.dat del Default User para las nuevas sesiones que se hagan en los respectivos equipos. Lo que haremos será utilizar el equipo técnico donde se esté creando el Perfil Obligatorio para personalizarlo a nuestra medida, crearle un XML que copie el perfil y resellarlo para que haga la tarea.

Personalizando el perfil

Debemos personalizar todo nuestro ambiente a como desearíamos que el Usuario Obligatorio lo tenga. Básicamente, es necesario que personifiquemos nuestra Pantalla de Inicio, incluyendo la ubicación de las baldozas, nombre a los grupos, colores y demás. A parte de esto, el fondo de pantalla para el Escritorio, configuración de carpetas, colores en la barra de tareas y ventanas, y accesos directos. Entre muchas otras cosas…

Para este artículo, yo personifiqué algunas cosas notables dentro del Escritorio, y de la Pantalla de Inicio:

Creando archivo de Auto-Respuesta

El archivo de Auto-Respuesta, nos servirá para indicarle a Windows que debe copiar todas las configuraciones del perfil actual, al perfil predeterminado del sistema operativo, es decir, remplazar el ntuser.dat de la carpeta Default.

Fundamentalmente, el XML debe tener la propiedad de CopyProfile en True, para ambas arquitecturas:

<CopyProfile>true</CopyProfile>

Recordemos que el archivo se genera con el Administrador de Imágenes de Windows (SIM), incluido en el ADK para Windows 8.
Como el objetivo de este post no es profundizar en una imagen maestra con el perfil predeterminado a nuestro gusto, pueden descargar el XML que funcione en ambas arquitecturas (x86 y x64) desde aquí:

Archivo de Auto-Respuesta. AutoUnattend.xml

Pueden descargar el archivo desde Skydrive también:

*Nota 1: No olviden descomprimir primero, pues está en .ZIP.

*Nota 2: Si quieren ver más información sobre esto, pueden ver este post.

Debemos pegar el archivo en la raíz de la carpeta: C:\Windows\System32\Sysprep.

Resellando

Posteriormente, debemos ejecutar nuevamente el Símbolo del Sistema con privilegios elevados, es decir, buscar CMD desde la Pantalla de Inicio, clic derecho y Ejecutar como administrador.

Navegamos (Utilizando ‘cd’) hasta la ruta C:\Windows\System32\Sysprep y corremos:

Sysprep /oobe /generalize /reboot /unattend:AutoUnattend.xml

*Nota: El proceso de resellado limpia todas las configuraciones de Hardware, el SID de usuario, la activación y otras configuraciones básicas, como nombre de equipo y demás.

Cuando reinicie el equipo, arrancará el proceso de OOBE, que consiste en la última fase de instalación, donde se le vuelve a preguntar al usuario por los términos de licencia, nombre de equipo, configuración general y cuenta de usuario. Tendremos que indicarle toda esta información, incluyendo la creación de otra cuenta de usuario, para estar nuevamente en Windows.

Al llegar aquí, es necesario habilitar la cuenta integrada de Administrador en Windows 8. Para esto, iniciamos sesión con alguna cuenta que tenga privilegios administratrivos, y desde la Pantalla de Inicio, buscamos CMD y sobre el resultado hacemos clic derecho y Ejecutar como administrador en la parte inferior.

En el Símbolo del sistema, ejecutamos: Net User Administrador /Active:Yes

*Nota: Si tenemos el sistema operativo en inglés, como es el caso de la captura anterior, es necesario cambiar “Administrador” por su equivalente en inglés, es decir: “Administrator”.

Cerramos sesión e iniciamos desde la cuenta de Administrador integrado.

Crear Perfil de Usuario Obligatorio

Desde el Administrador integrado, buscamos ubicados en la Pantalla de Inicio por: “perfil de usuario” (Sin las comillas), seleccionamos el panel de Configuraciones (Settings) y ejecutamos “Configurar propiedades del perfil de usuario avanzadas”:

Nos debe aparecer la ventana de Perfil de Usuario, con todas las cuentas disponibles, incluyendo la de Default Profile:

Seleccionamos el Default Profile (Perfil Predeterminado), y clic en el botón Copiar a…

En la ventana de Copiar a… indicamos como ruta C:\Users, especificando además el nombre que deseamos para nuestro perfil predeterminado, con terminación en .v2, que le dice a Windows que es un perfil de Windows 7 o superiores. Para este caso, utilicé como nombre: “Obligatorio.v2”. Luego hacemos clic en el botón de Cambiar, debajo de Usuarios permitidos y establecemos a Todos (Everyone):

Clic en Aceptar (OK) dos veces para cerrar el cuadro de Copiar a… y Perfil de Usuario.

Aquí viene el paso más importante, en primera instancia, debemos habilitar los Archivos ocultos y Protegidos por el Sistema desde las Opciones de Carpeta:

Después vamos a la carpeta recién creada para el Perfil Obligatorio dentro de C:\Users, que en este caso es C:\Users\Obligatorio.v2, y renombramos el archivo ntuser.dat a ntuser.man

Asignar Perfil de Usuario Obligatorio al Estándar

En este paso, solo debemos asignar el Perfil de Usuario Obligatorio recién creado al perfil local que se generó desde el principio.

Presionamos las teclas Windows + R para abrir la ventana de Ejecutar y corremos: compmgmt.msc. Se abrirá la Consola de Administración.

Expandimos el nodo de Usuarios y Grupos Locales, Usuarios, hacemos clic derecho en el usuario local que creamos en el primera paso (Para este caso, Compartido) y clic en Propiedades:

Nos pasamos a la ventana de Perfil, y en el campo de texto al lado de Ruta de perfil, le debemos indicar la ubicación exacta de nuestro Perfil Obligatorio, pero sin incluir el “.v2” que tiene al final. Por ejemplo, para este artículo, sería: C:\Users\Obligatorio

Clic en Aplicar y Aceptar para terminar.

Con esto, el perfil predeterminado que contiene las personalizaciones que le hicimos al sistema operativo estará asociado al perfil que creamos, y que no hemos iniciado por primera vez. Lo último es solo asegurarnos que Windows siempre inicie desde este perfil y habremos terminado.

Configurar el Autologon del Usuario Obligatorio

Para hacer que Windows inicie siempre con el Perfil Obligatorio, es necesario crear tres valores de Registro:
AutoAdminLogon, DefaultDomainName, DefaultUserName, y DefaultPassword.

Para hacerlo, debemos navegar hasta la clave de registro:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon

Hacemos clic derecho en la parte en blanco donde se ubican los respectivos valores de la clave, seleccionar Nuevo (New) > Valor de Cadena (String Value), ingresarle el nombre y el contenido:

Todos son Valores de Cadena (String Value), y deberían tener el siguiente contenido:

Valor	Contenido
AutoAdminLogon	1
DefaultDomainName	<NombreEquipo>
DefaultUserName	<NombreObligatorio>
DefaultPassword	<ContraseñaObligatorio>

Donde <NombreEquipo> es como está identificado el PC, en caso de que estemos en un Grupo de Trabajo, o bien el Dominio, si estamos bajo un Directorio Activo; <NombreObligatorio> es como se llama el Perfil Obligatorio, que en este caso es Compartido, <ContraseñaObligatorio> es la respectiva contraseña del Perfil Obligatorio.

Los valores deberían verse así:

Opción alternativa

Sysinternals Suite, ofrece una herramienta muy útil para configurar el Autologon desarrollada por el gran Mark Russinovich. Se llama Autologon y basta con ejecutarla con privilegios elevados, indicarle los datos y hacer clic en el botón Enable para que empiece a funcionar:

La herramienta la pueden descargar desde el sitio oficial de Sysinternals:
http://technet.microsoft.com/en-us/sysinternals/bb963905

¡Todo listo! Solo tendremos que reiniciar y automáticamente iniciará siempre desde el Perfil Obligatorio, permitiendo al usuario compartido que lo esté utilizando realizar diferentes cambios, según se hayan permitido desde la creación de la cuenta y/o por políticas de grupo y una vez cierre sesión, Windows no guardará nada y volverá a cargar el perfil predeterminado al volver a iniciar o reiniciar.

Así quedaría el Perfil de Usuario Obligatorio (Mandatory User Profile) en mi caso después de iniciar:

*Nota: Desconozco por qué razón el Usuario Obligatorio sólo tiene Internet Explorer y la Tienda como aplicaciones de Interfaz Moderna instaladas; además de esto, después del primer reinicio, es necesario hacer que IE sea el navegador predeterminado para que se pueda usar la versión de Interfaz Moderna.

Saludos,

Checho

Implementación básica de BitLocker y BitLocker To Go para Windows 8 PRO/Enterprise en la Empresa.

2013-04-20T14:44:00Z

Hace algunos meses atrás, cuando Windows 8 alcanzó su etapa de Consumer Preview (Beta), estuvimos Explorando lo que venía de nuevo con respecto a BitLocker y BitLocker To Go; incluso también su unión con Windows To Go para brindar la posibilidad de cifrar el dispositivo y mejorar su protección. Sin embargo, estos artículos estuvieron más enfocados a las mejoras en su característica como tal, no en su despliegue.

Gracias a que BitLocker pasó a ser una característica de PRO y no de Enterprise, como lo era hasta el maravilloso Windows 7, muchas empresas seguro empezarán a implementar BitLocker como medida de seguridad para sus equipos y discos extraibles. Lo que veremos en este post, será la forma de implementar a través de Políticas de Grupo fácilmente tanto BitLocker, como BitLocker To Go en los equipos de la compañía.

*Nota: La implementación de BitLocker puede ser mucho más productiva y gestionable haciendo uso de la consola de MBAM, incluida en el paquete de MDOP y que reciéntemente se actualizó a su versión 2.0.

Requerimientos

- Servidor Windows 2008 R2 con las Plantillas Administrativas de Windows 8 y Windows Server 2012 instaladas, o bien, Windows Server 2012 preferiblemente. Además de esto, tener instalado y configurado un Controlador de Dominio.

*Nota: Pueden descargar un período de prueba de 190 días de Windows Server 2012 desde aquí: http://technet.microsoft.com/en-us/evalcenter/hh670538.aspx

*Nota 2: Este artículo está basado en Windows Server 2012, pero el procedimiento en general es el mismo para versiones anteriores, obviando algunas plantillas.

- Equipos Windows 8 unidos al dominio.

- Una carpeta compartida. Para este caso, creé una llamada Backups ubicada dentro de la carpeta C:\BitLocker.

Configurando las Políticas de Grupo

Desde nuestro Servidor, debemos configurar una serie de poíticas que le indicarán a los clientes conectados al dominio cómo debe comportarse BitLocker y BitLocker To Go.

Debemos acceder entonces desde el Servidor a la Consola de Group Policy Management, expandimos el nodo de Domains, luego hacemos clic derecho sobre el nodo de nuestro Dominio (En este caso: chechosblog.com), y seleccionamos: Create a GPO in this domain, and Link it here…

En la ventana de New GPO, le ingresamos un nombre descriptivo, para saber las políticas que se aplicarán y configurarán aquí. En este caso, yo lo llamé: BitLocker Policies. Después de darle el nombre, simplemente aceptamos para que se vea reflejada debajo del nodo de nuestro dominio.

*Nota: Este procedimiento no es extrictamente necesario, pues se pueden editar las políticas predeterminadas del dominio, pero no es quizá una muy buena práctica.

Hacemos clic derecho sobre la GPO que creamos, y seleccionamos Edit, para que se abra la Consola de Administración de Políticas de Grupo:

Debemos navegar hasta: Computer Configuration\Policies\Administrative Templates\Windows Components\BitLocker Drive Encryption.

Como ya hemos hablado antes, BitLocker tiene una seguridad tan alta, que la única forma hasta ahora de recuperar el acceso al disco en caso de pérdida u olvido de contraseña, es dando formato, e incluso así, la información queda totalmente imposible de recuperar. Por esta razón, la primera plantilla que debemos configurar, es la que le indique a BitLocker que a parte de la contraseña especificada por el usuario, y la clave de recuperación que se genera, se guarde una copia de la última en el Directorio Activo.
Para esto, hacemos doble clic en Operating System Drives, y doble clic en la plantilla: Choose how BitLocker-protected operating system drives can be recovered.

Debemos habilitar la plantilla (Enabled), seleccionar la ficha de Save BitLocker recovery information to AD DS for operating system drives para que al cifrar el dispositivo la clave de recuperación se guarde con el objeto asociado y por último, seleccionar Do not enable BitLocker until recovery information is stored to AD DS for operating system drives, que nos asegurará siempre tener el respaldo de la clave y la contraseña de recuperación antes de que BitLocker empiece a funcionar:

Para los equipos que tienen TPM, pueden empezar a “jugar” con las respectivas plantillas referentes al chip para asegurar otros métodos de autenticación y protección; sin embargo, gran mayoría de los equipos que están en las empresas, no tienen TPM, por esta razón, es necesario asegurar que BitLocker pueda cifrar el disco del sistema operativo utilizando otro método de autenticación.

Abrimos la plantilla de Require additional authentication at startup, la habilitamos (Enabled), y nos asegurarmos de seleccionar Allow BitLocker without a compatible TPM (Requires a password or a startup key on a USB flash drive). De esta forma, y aprovechando una pequeña mejora en Windows 8, el usuario podrá utilizar solo una contraseña para autenticarse al prender el equipo.

Lo siguiente, es asegurarnos que los usuarios estándar no puedan cambiar la contraseña de cifrado, pues predeterminadamente les es posible hacerlo. Doble clic entonces sobre la plantilla de Disallow standard users from changing the PIN or password, y la habilitamos:

Hasta aquí, estamos asegurando que todas las máquinas se puedan cifrar con BitLocker, y que por supuesto, el respaldo de la clave de recuperación quede en el Directorio Activo asociado al equipo. Ahora, para los equipos propios con Windows 8, tomando ventaja de la característica de cifrar solo el espacio utilizado, forzaremos a que esto pase en todos los equipos, y de esta forma reduciremos notablemente el tiempo que se toma BitLocker.

Doble clic en la plantilla de Enforce drive encryption type on operating system drives, la habilitamos (Enabled) y seleccionamos Used Space Only encryption, debajo de Select the encryption type.

Ya está lista la partición del sistema operativo, ahora debemos configurar lo que concierne a BitLocker To Go. Debemos pasar entonces al nodo de Removable Data Drives, y empezar a configurar sus respectivas plantillas.

La primera, como en la de sistemas operativos, es: Choose how BitLocker-protected removable drives can be recovered. La abrimos, habilitamos (Enabled) y seleccionamos las misma opciones que cuando configuramos las unidades de sistema operativo en los primeros pasos:

Una vez hecho esto, aprovechamos una política propia para los dispositivos extraibles, y es la posibilidad de prohibir la escritura de archivos hasta que no estén cifrados con BitLocker. Doble clic sobre la plantilla Deny write access to removable dirves not protected by BitLocker. La habilitamos (Enabled), la dejamos predeterminada y aceptamos.

Por último, como en las plantillas para sistema operativo, abrimos Enforce drive encryption type on removable data drives, habilitamos (Enabled), y seleccionamos Used Space Only encryption.

Todo está listo, y ya sabemos que las claves de recuperación se almacenarán con el objeto en el Directorio Activo; a pesar de esto, podemos darle otro repositorio adicional al usuario en una respectiva ruta de red para que guarde sus claves de recuperación, una vez cifre la unidad.

Nos ubicamos en la raíz de BitLocker Drive Encryption, doble clic sobre la plantilla Choose default folder for recovery password, la habilitamos (Enabled), y le indicamos la ruta de red (Por ejemplo \\DC\Backups\ en este post):

¡Terminamos! BitLocker y BitLocker To Go están listos para ser utilizandos. =)

Comprobando resultados

Empezaré con BitLocker To Go, pues es el que tiene la plantilla propia que obliga a cada usuario a cifrar su dispositivo antes de poder escribir en él.

Cada que se conecte un nuevo dispositivo, BitLocker mostrará el siguiente mensaje avisándole al usuario que debe cifrar antes de poder copiar:

*Nota: Se podrá copiar lo que haya en el dispositivo hacia el equipo host, más no al revés hasta que se habilite BitLocker.

Cuando se acepta cifrar el dispositivo, el asistente solicitará la clave personalizada por el usuario:

*Nota: Es posible utilizar una Smart Card, e incluso, forzar diferentes modelos de seguridad en la clave de usuario desde las políticas de grupo, con la plantilla de Configure use of passwords for removable data drives.

Cuando se le pida al usuario guardar la clave de recuperación, predeterminadamente tendrá disponible la carpeta compartida que creamos:

Y finalmente, iniciar el cifrado:

Para el sistema operativo…

En el caso de la partición correspondiente al sistema operativo, no podemos tener la misma suerte (Al menos por políticas), de que no se pueda escribir nada más antes de proceder a cifrarlo, por lo que se debe hacer manual, o bien, haciendo uso de características como el Pre-Aprovisionamiento de BitLocker en Windows 8 para desplegarlo con MDT (Trataré de cubrir este despliegue en un futuro artículo).

Si lo iniciamos, predeterminadamente pedirá la contraseña personalizada por el usuario:

Lo siguiente, al igual que en USB, será guardar la clave de recuperación nuevamente en la ruta de red, y finalmente solicitará correr el BitLocker System Check, herramienta que se encargará de verificar que no haya ningún problema para cifrar la unidad, por lo que se debe reiniciar:

Al reiniciar el sistema operativo, pedirá inmediatamente autenticación con la contraseña establecida para BitLocker, antes de iniciar incluso el sistema operativo:

El cifrado real, sin embargo, iniciará en segundo plano una vez se inicie Windows:

¿Cómo recupero el acceso a unidad con las claves de recuperación guardadas?

Gracias a que desde el principio se contempla el guardado de la clave de recuperación en el Directorio Activo, no habrá inconveniente cuando a algun usuario se le pierda u olvide la contraseña, pues bastará saber el nombre del equipo para indicarle la clave de recuperación.

Sin embargo, hay que tener en cuenta que para poder ver estas claves, es necesario activar la característica de BitLocker Recovery Password Viewer desde el Server Manager para que se agregue una nueva pestaña a las propiedades de los nombres del equipo. Las características son BitLocker Drive Encryption Tools, y BitLocker Recovery Password Viewer, debajo del nodo principal de Remote Server Administration Tools:

Al tener instalado BitLocker Recovery Password Viewer, podemos ir a la Consola de Active Directory Users and Computers, o a la nueva Active Directory Administrative Center (Disponible en 2012). Para ambas, buscamos el nombre del equipo en el nodo de Computers; vamos a las Propiedades haciendo doble clic o clic derecho, Properties, y buscamos la pestaña de BitLocker Recovery, sea en la pestaña propia teniendo en cuenta la primera opción, o bien en la misma pestaña, pero debajo de la categoría de Extensions en la segunda opción:

*Nota: Debe utilizarse algún método propio de la empresa para proveer estas claves de recuperación, pues desde el Directorio Activo no se puede recuperar el acceso directamente a la máquina, sólo se le pueden indicar los dígitos al usuario. MBAM, incluido en MDOP, sí entrega la posibilidad de restablecer el acceso a la máquina de forma centralizada.

¡Comentarios bienvenidos!

Saludos,

Checho

Windows 8 Enterprise Sideloading (Parte 2/2): Despliegue de aplicaciones con MDT 2012 Update 1

2013-03-30T11:27:00Z

Hace poco compartí aquí en el blog, lo que llamé la primera parte de lo que se conoce como Enterprise Sideloading en Windows 8 de forma manual. Por supuesto, no es la única manera de desplegar aplicaciones de Windows 8 en un entorno empresarial, pues diferentes soluciones pueden cubrir este requerimiento.

Hoy nos concentraremos en el otro método para hacerlo de una forma gestionada, y claro está, que no implique costos adicionales, pues basta y sobra con herramientas gratuitas que Microsoft pone a disposición de todos. La solución no puede ser otra más que Microsoft Deployment Toolkit (MDT) 2012.

Lo que haremos, será agregar una aplicación con fines de prueba a nuestro recurso compartido en MDT, preparar las operaciones necesarias para que funcione, y realizar el despliegue a través de la red, junto con el sistema operativo, utilizando MDT y Windows Deployment Services (WDS).

¿Qué necesitamos?

- Windows Server 2012 instalado, que sea un Controlador de Dominio, que tenga instalado y configurado MDT 2012 Update 1 y Windows Deployment Services (WDS).

Pueden descargar e instalar un período de prueba de Windows Server 2012 desde aquí: http://technet.microsoft.com/es-ES/evalcenter/hh670538.aspx?wt.mc_id=TEC_108_1_5

Para instalar y configurar el rol de WDS, pueden seguir este artículo en TechNet Wiki que escribí hace un tiempo: http://social.technet.microsoft.com/wiki/contents/articles/15720.instalacion-y-configuracion-basica-de-windows-deployment-services-en-server-2012-es-es.aspx

- Archivos de instalación de Windows 8 Enterprise. Si no lo tienen, pueden descargar un período de prueba desde aquí: http://technet.microsoft.com/es-ES/evalcenter/hh699156.aspx?ocid=wc-bl-sprblog

*Nota: Es necesario hacer una instalación de Windows 8 Enterprise, que además se pueda unir a un dominio, de lo contrario, debe utilizarse una Clave de producto para instalación de prueba, que se adquiere a través del sitio de licenciamiento por volumen de Microsoft.

- Archivos de instalación de Windows 8 previamente desarrollada. Es decir, con extensión .APPX. Una aplicación completa, incluye su propia firma y certificado criptográfico, pero en un escenario de prueba, será necesario instalar un Certificado Auto-Firmado localmente. Este artículo explicará el procedimiento para hacerlo.

*Nota: Si aún no han desarrollado por primera vez una aplicación para Windows 8, pueden hacerlo siguiendo este tutorial de MSDN: http://msdn.microsoft.com/es-ES/library/windows/apps/hh986964.aspx

- Un Equipo de Referencia, que esté conectado a la misma red que el equipo técnico (Server 2012) para realizar la implementación.

Instalando y configurando nuestro recurso compartido de implementación

Lo primero que tenemos que hacer, es preparar nuestro Deployment Share desde la Consola de MDT. Esto incluye agregar sistema operativo, nuestras aplicaciones de escritorio, actualizaciones, controladores y generar nuestra Secuencia de Tarea que se encargará de administrar el proceso de implementación.

Para aprovechar los diferentes artículos en serie que he ido escribiendo, desde los primeros pasos, pueden seguir un post anterior para realizar este proceso paso a paso:
http://geeks.ms/blogs/checho/archive/2013/02/05/implementaci-243-n-b-225-sica-de-windows-8-con-mdt-2012-update-1-y-windows-deployment-services.aspx

*Nota: Este artículo sigue basado en el mismo Deployment Share y dominio creados, para mayor facilidad y comprensión, aunque las Sencuencias de Tareas y ciertos nombres pueden variar.

Una vez hecho lo anterior, ya todo debe estar listo para una implementación básica; sin embargo, procederé a ampliarlo agregando la aplicación de interfaz moderna y los respectivos cambios en la Secuencia de Tarea en los próximos pasos.

Agregando aplicación de Windows 8 a MDT

En el Equipo Server técnico, donde tenemos instalado y configurado el MDT, debemos copiar los archivos de instalación a un directorio de fácil acceso (Incluyendo el certificado, si se requiere). Para este artículo, copié los archivos a la unidad del sistema operativo (C:\).

*Nota: Para esta aplicación, y específicamente, para este post, utilizaré un certificado que se generó manualmente con fines de prueba. En un entorno empresarial, lo ideal sería que la aplicación esté firmada, o se distribuya el certificado desde una entidad certificadora para los equipos unidos a un dominio.

Abrimos el Deployment Workbench, expandimos nuestro Deployment Share, clic derecho en el nodo de Applications y seleccionamos New Application. Se abrirá el asistente para agregar una nueva aplicación:

En la página de Application Type, seleccionamos Application with source files y clic en el botón Next.

En la página de Details, rellenamos los campos necesarios para referenciar la aplicación, y clic en el botón Next.

En la página de Source, debemos especificar el directorio exacto de la carpeta que contiene los archivos de instalación de la aplicación de Windows 8 y clic en el botón Next.

*Nota: Es necesario asegurarnos que el .APPX, con todos los archivos necesarios para la instalación, se encuentren en ese directorio.

En la página de Destination, debemos dejar o modificar el nombre para referenciar nuestra aplicación de Windows 8 y clic en el botón Next.

En la página de Command Details, debemos indicarle exactamente el nombre de la aplicación de Windows 8, con su respectiva extensión .APPX. De esta forma, MDT la podrá identificar como una aplicación de interfaz moderna al momento de desplegarla. Este es el paso más importante. Para este artículo, mi aplicación se llama: Sample_1.0.0.2_AnyCPU_Debug.appx

Finalmente, en la página de Summary, clic en el botón Next, y en la página de Confirmation, clic én el botón Finish para terminar. La aplicación debería verse ahora en el nodo de Applications en nuestro Deployment Share:

Creando y configurando Secuencia de Tareas

En el artículo base que referencié desde el primer paso para preparar el recurso compartido, muestro cómo crear la Secuencia de Tareas que consumirá todo lo que se agregue dentro de los nodos del Deployment Share. Sin embargo, para fines prácticos, mostraré nuevamente a continuación el paso a paso para crear una nueva Secuencia de Tareas, junto con los pasos necesarios para la configuración requerida.

En nuestro Deployment Share, hacemos clic derecho sobre el nodo de Task Sequences, y clic en New Task Sequence. Se abrirá el asistente para generar una nueva Secuencia de Tareas.

En la página de General Settings, le indicamos un ID, ojalá siguiendo algún estándar, un nombre a la Secuencia de Tareas y su respectiva descripción. Hacemos clic en Next para continuar.

En la página de Select Template, escogemos Standard Client Task Sequence y clic en el botón Next.

En la página de Select OS, le indicamos la instalación de Windows 8 Enterprise y clic en el botón Next para continuar.

En la página de Specify Product Key, dejamos la selección predeterminada de Do not specify a product key at this time para que utilice el período de prueba y clic en el botón Next.

*Nota: Si nuestra empresa utiliza Claves de Activación Múltiple (MAK), aquí podemos especificar la segunda opción para hacer que Windows detecte y utilice la clave de producto desde el principio.

En la página de OS Settings, debemos escribir los datos de registro y la página de inicio que deseamos tenga de forma predeterminada Internet Explorer y clic en el botón Next.

En la página de Admin Password, le especificamos la contraseña para el Administrador integrado de Windows (Que es con el usuario que predeterminadamente inicia el asistente de instalación de MDT) y clic en el botón Next.

*Nota: Si no queremos asignar contraseña, basta con seleccionar: Do not specify an Administrator password at this time.

En la página de Summary, revisamos que todo esté bien y hacemos clic en el botón Next. En la página de Confirmation, clic en el botón Finish.
Ya tenemos nuestra Secuencia de Tareas, que debe verse ahora en el nodo de Task Sequences, dentro de nuestro Deployment Share.

Una de las características más interesantes de las Secuencias de Tareas, es que si vamos a sus propiedades (Clic derecho, Properties), veremos tres pestañas muy interesantes para consultar y modificar comportamientos de la Secuencia durante el proceso de implementación:

En la pestaña de General, se le puede modificar el nombre, la descripción, manejar versionamiento de la Secuencia de Tareas, indicar la plataforma en la que estará soportada, en incluso habilitarla o deshabilitarla del asistente de implementación.

En la última pestaña de OS Info, se puede editar el Archivo de Auto Respuesta que incluye cada Secuencia de Tareas al ser creada, por lo que se le podrían agregar muchas personalizaciones más, o remover las que ya existen.

Finalmente, en la pestaña de Task Sequence, se encuentran especificados paso por paso lo que hará la Secuencia de Tareas, dependiendo del escenario en que sea llamada; es decir, nueva instalación, actualización, remplazo, migración, etc. Estos pasos se pueden quitar, modificar o inclusive, agregar nuevos e irlos poniendo en el orden que deseemos, claro está, teniendo cuidado que no se vayan a afectar uno con el otro. El asistente lee y ejecuta los pasos de arriba hacia abajo. Los que están en gris, se encuentran deshabilitados, y los verdes, están listos para usarse. El aspecto predeterminado, es similar al siguiente:

Como indiqué al principio, como se trata de una implementación para fines de prueba, y en este caso no hay entidad certificadora en el Servidor que pueda entregar los certificados, es necesario agregar un paso adicional a la Secuencia de Tareas que se encargue de buscar e instalar el Certificado de la aplicación de Windows 8 en cada nuevo equipo. Recordemos que si manejan este escenario, la recomendación es poner el certificado en la misma carpeta que los archivos de instalación (Como predeterminadamente está).

Para instalar el Certificado, agregaremos una ejecución en el símbolo del sistema que utilice la herramienta de Certutil integrada en Windows para que lo instale en el Trusted Root Certification Authority.

Dentro de la pestaña de Task Sequence nos ubicamos en Install Applications, hacemos clic en el botón Add en la parte superior, vamos a General y seleccionamos Run Command Line.

Dependiendo de donde nos deje el Run Command Line, debemos utilizar los botones de Up y Down para que se ubique justo antes de Install Applications, así:

Hacemos clic en Run Command Line, y en Name, lo cambiamos por Install Appx Certificate. Ahora, debajo de Command Line, debemos ejecutar:

cmd /c certutil –addstore ROOT “<RutaCert>\<Certificado>.cer”

Donde <RutaCert> es la ubicación del certificado para la aplicación de Windows 8, y <Certificado>.cer es el nombre que tiene el respectivo certificado con su extensión. Para mi caso, todo lo llamé directamente del Nodo de Applications cuando se copiaron los archivos de instalación de la aplicación. Quedaría así:

cmd /c certutil -addstore ROOT \\DC\DeploymentShare\Applications\Sample Windows 8 Application\Sample_1.0.0.2_AnyCPU_Debug.cer

Al hacer clic en el botón Apply, debe tener un aspecto similar al siguiente:

*Nota: Si tenemos una entidad certificadora, no es necesario realizar el proceso anterior, y se puede pasar al siguiente paso directamente.

Actualizando recurso compartido y WDS

Esto es todo lo que debemos hacer. El siguiente paso, es hacer clic derecho en nuestro Deployment Share y seleccionar Update Deployment Share:

En la página de Options, dejamos la selección predeterminada para que se actualice lo que ya tenemos, y clic en el botón Next.

En la página de Summary, clic en el botón Next. En la página de Confirmation, clic en el botón Finish.

En el WDS, hacemos clic derecho en el nodo de Boot Images, y seleccionamos Add Boot Image…

En Image File, ubicamos el archivo LiteTouchPE que corresponda a nuestra arquitectura, y que normalmente debería estar en la carpeta DeploymentShare\Boot\ (Si se dejó el nombre predeterminado) y clic en el botón Next.

En la página de Image Metadata, clic en el botón Next. En la página de Summary, clic en el botón Next, y en la página de Task Progress, clic en el botón Finish.

¡Todo está listo! Ya podremos desplegar un equipo con Windows 8 Enterprise, y la respectiva aplicación moderna.

Instalando y probando

Iniciamos nuestro Equipo de Referencia desde la red para que detecte el WDS, y arranque desde el asistente de instalación del MDT:

Una vez conectados al MDT, basta con seguir el asistente básico de instalación para que inicie el despliegue. Como esto ya lo hemos visto en varios artículos, los pondré todos solo como referencia:

Es importantísimo unir el equipo al dominio durante el asistente, pues lo requieren las aplicaciones de Interfaz Moderna desplegadas manualmente:

En la página de Applications, veremos la aplicación de Windows 8 de la misma forma que las aplicaciones de escritorio que hayamos agregado a nuestro Deployment Share:

La instalación finalmente iniciará, y en menos de 20 minutos, habremos terminado:

*Nota: La instalación de Windows 8 con MDT rebajó notoriamente en tiempo, pero puede incrementar o decrementar, dependiendo del hardware donde se esté desplegando.

Una vez terminada la instalación, debemos verificar que el MDT no haya arrojado errores, y reiniciar el equipo. Al reiniciar, debemos iniciar sesión con cualquier usuario de dominio, y si todo salió bien, debemos tener disponible nuestra aplicación en la Pantalla de Inicio, o bien realizando la búsqueda por el respectivo nombre:

*Nota: Internamente, MDT utiliza el comando DISM.EXE /online /Add-ProvisionedAppxPackage, para que la aplicación quede disponible para cada nuevo usuario que inicie sesión en el equipo. Pueden verlo editando el Script ZTIApplications ubicado en la carpeta de Scripts.

Esto es todo. Espero les pueda servir de utilidad.

Saludos,

Checho

La aplicación “Canal+Yomvi” que no era compatible con Windows 8, ACT, los Shims y su solución

2013-03-17T14:05:00Z

Estas son de las entradas que más me gustan escribir, pues a parte de entregar una posible solución a diferentes usuarios que se estén enfrentando al iconveniente que aquí se muestra, es la mejor forma para aprender.

Como ha sucedido en diferentes artículos, el problema en este caso, es con respecto a algo que cada empresa en algún momento durante su migración a otro sistema operativo debe enfrentar: Compatibilidad de Aplicaciones.
Este problema en específico, nació de los maravillosos Foros de Microsoft TechNet en Español, y se presentaba con una aplicación comercial muy popular sobre todo en España llamada: Canal+Yomvi.

A continuación, describiré un poco más a fondo el problema, la causa encontrada y su solución o mitigación, para los que busquen cómo enfrentarlo mientras se actualiza la aplicación.

El problema

Canal+Yomvi, es una aplicación que desarrolló el Canal+, para que los usuarios puedan consumir sus servicios de TV desde diferentes dispositivos. Sin embargo, hasta este momento, si alguien descarga la aplicación desde un sistema Windows 8, muy probablemente se encontrará con el siguiente mensaje de error al lanzar el instalador:

“Unsupported operating system, major=6, version=2,2, sp=0.0, type=1”

No importa que la aplicación se ejecute con privilegios administrativos (Clic derecho, Ejecutar como administrador), o que como en la muchos casos, se le cambie el Modo de compatibilidad con Windows 7 o Windows XP desde sus propiedades, siempre se recibirá este mensaje, y por ende, no se puede proceder a la instalación.

*Nota: Este mensaje sale indiferente de la arquitectura del sistema operativo Windows 8 que se tenga instalado.

La causa

Aunque el mensaje apenas si permite aceptarlo para que se cierre la instalación, y no brinda una aparente clara ayuda, sí transmite de una forma muy precisa que la aplicación está validando la versión del sistema operativo en la que se intenta instalar. Normalmente, este tipo de problemas se mitigan cambiando el modo de compatibilidad, pues esto realiza una “Mentira sobre versión”, e intenta engañar las llamadas a la API que realiza la aplicación y hacerla creer que está sobre la plataforma que busca.

En este caso, sin embargo, no era suficiente. Como solo tiene un ejecutable para las tres versiones, probablemente esté comprobando la versión, pero de una forma errónea, ya la mayoría de estas aplicaciones, no buscan por característica, sino por un simple número. Por ejemplo, esta aplicación en su código puede estar encerrando el paso de “ser compatible o no”, indicando que si el sistema local es mayor a 5.1 (XP) y menor o igual a 6.1 (Win7), podrá instalarse, de lo contrario, no.

Hasta aquí, no sabía como forzar a Windows a que mintiera más allá de lo que podía con sus propios shims de compatibilidad, hasta que The App Compact Guy (Chris Jackson), muy amablemente me abrió una luz al final del camino acordándome de Application Compatibility Toolkit.

La solución

Application Compatibility Toolkit (ACT), provee varias herramientas destinada al diagnóstico y mitigación sobre compatibilidad de aplicaciones, tanto para Internet Explorer como para Windows. ACT solía venir como una descarga separada, pero desde la salida del Asessment And Deployment Kit (ADK), está incluído en su descarga para ser instalado con el mismo asistente.

Una de las herramientas más interesantes que están en el kit de ACT, es el Application Compatibility Administrator, pues una vez identificadas las posibles causas, nos permitirá generar unos Shims personalizados para cada aplicación, que se podrán instalar sobre Windows localmente para mitigar los problemas de compatibilidad, e incluso hacer distribución en un ambiente de implementación para todas las máquinas.

*Nota: Un Shim, es básicamente un fix que genera el Compatibility Administrator, que se encarga de interceptar las llamadas a la API que hace Windows utilizando diferentes módulos o DLLs y devolviéndoles diferentes módulos que engañan a la aplicación haciéndose pasar por los verdaderos. Esto con el fin de realizar múltiples correcciones, como las de mentira sobre versión. En próximos artículos, intentaré ampliar más claramente este concepto, junto con la forma de utilizar ACT y todas sus características.

Ahora bien, volviendo a este caso, decidí utilizar ACT para tratar de remediar el problema que estaba causando la aplicación.

Desde el Compatibility Administrator, ejecuté el asistente para el nuevo Fix, haciendo clic derecho en New Database, debajo de Custom Databases y Create New > Application Fix.

En la ventana del Asistente, me bastó con llenar algunos datos para identificar la aplicación, e indicarle el acceso al ejecutable con el que se están teniendo los problemas:

La primera ventana que aparece, es la de Application Modes, que son básicamente los que aparecen en la pestaña de Compatibilidad que integra Windows. Como en este caso no lo resolví así, hacer algo aquí sobra.

La ventana de Compatibility Fixes, es la más importante dentro de este asistente. Una vez identificado el posible problema, aquí se debe elegir – entre los cientos que hay- los fixes apropiados para mitigar el comportamiento anormal de la aplicación que estemos analizando. Para mi caso, sabía que el inconveniente lo estaba causando la validación explícita sobre versión que estaba haciendo la aplicación, y como en la web indicaba que hasta Windows 7 era compatible, el Fix indicado era Win7RTMVersionLie.

Sin embargo, al presionar el botón Test Run para probar que el Shim funcione antes de implementarlo, seguía recibiendo el mismo mensaje.

ACT predeterminadamente excluye algunos módulos que están en ubicaciones como System32, entre otras, y que suelen utilizar aplicaciones con código administrado, como las de VB. En este orden de ideas, algunos Shims requieren que se incluyan estos módulos para poderle mentir correctamente a la aplicación.

Lo que tuve que hacer para no exluir nada, fue seleccionar el Shim, hacer clic en el botón Parameters, y debajo de Module name, escribir “*”, y hacer clic en el botón Add para que se incluyeran todos:

Lo siguiente es solo hacer clic en el botón Next, y Finish.

Como ya sabía que mi Shim funcionaba, debía instalarlo localmente para que la aplicación se dejara instalar. Si se quiere hacer desde la Consola, basta con guardar el Shim haciendo clic en el botón de Save, asignarle un nombre y guardarlo tanto internamente, como físicamente en un directorio fácil de acceder:

Por último, clic derecho en la Base de datos creada y clic en Install para que el Shim quede localmente:

¡Todo listo! Una vez ejecuté el instalador de la aplicación de Canal+, el resultado fue bastante satisfactorio:

“Milagrosamente”, ahora Canal+Yomvi era compatible y gracias a esto, pude completar la instalación sin problemas.

Como ven, no siempre y en la gran mayoría de los casos, Windows es el que tiene la culpa.

[Opcional]: Descarga e instalación del Shim

Para los que tengan este problema, pueden descargar el Shime que generé para mitigarlo mientras Canal+ lanza una nueva actualización desde aquí:

Deben descomprimir el .ZIP, y ejecutar con privilegios elevados (Clic derecho, Ejecutar como administrador) el archivo InstallShim.

Deberán ver una ventana similar a la siguiente al instalarse:

Estoy estudiando lo más que puedo sobre ACT, así que espero como mencioné anteriormente, empezar a escribir artículos que cubran el tema pronto.

Espero sea de utilidad.

Saludos,

Checho

Windows 8 Enterprise Sideloading (Parte 1/2): Despliegue manual de aplicaciones.

2013-03-03T14:44:00Z

*Nota: Este artículo, aunque se trata como Parte 1, es independiente de la futura Parte 2, pues se explicarán dos métodos diferentes para un mismo fin.

Windows 8, introdujo un nuevo tipo de aplicaciones llamadas: Aplicaciones de la Tienda de Windows. Estas aplicaciones tienen un comportamiento muy diferente a las tradicionales de escritorio; por un lado, consumen toda la pantalla de Windows, integrando nuevas formas de interactuar con ellas, no tienen botones de minimizar, maximizar o cerrar y de hecho, pasan a estar en un estado de “Suspedido” cuando no están ejecutándose en primer plano.
Este nuevo tipo de aplicaciones tiene además nuevos diseños, se adaptan a diferentes tipos de dispositivos y utilizan “tiles” en vez de íconos para referenciarse en la Pantalla de Inicio.

Las Aplicaciones de la Tienda de Windows, o de Interfaz Moderna, como se le conocen, se les diferencia de una forma muy fácil dentro de la Pantalla de Inicio, pues se les puede integrar mensajes e información personalizada a mostrar para el usuario, sin necesidad de estar en ejecución. Tienen un aspecto similar al siguiente:

Su instalación (desinstalación) es muchísmo más fácil y rápida, lo que garantiza transparencia y confiabilidad en el rendimiento de Windows 8, aunque personalmente, no me parecen tan sencillas de hacer Troubleshooting cuando ocurren problemas. Técnicamente, las aplicaciones se instalan en un directorio escondido y protegido de Windows llamado WindowsApps, dentro de Archivos de Programa, es decir: C:\Program Files\WindowsApps. Este directorio no se puede cambiar de forma soportada, aunque estas aplicaciones tienen un peso considerablemente bajo.

*Nota: Pueden encontrar más información sobre cómo funcionan las aplicaciones de Windows 8, incluyendo especificaciones entre las diferentes apps en el Blog del MVP Alberto Escalona.

Hay dos métodos generales para adquirir e instalar las aplicaciones de Windows 8; el primero, es desde la nueva Tienda de Windows 8, embebida en el sistema operativo, donde los fabricantes o desarrolladores pueden publicar sus aplicaciones, y por supuesto, es el lugar en el que podrán encontrar. La cantidad de aplicaciones ahora depende mucho de la región donde se encuentren. La Tienda en Windows 8 se ve así:

El segundo método, es hacer un despliegue manual y local de las aplicaciones de Interfaz Moderna desarrolladas como LOB (Línea de Negocio). Tienen el mismo procedimiento de desarrollo que las que se pueden publicar en la Tienda, pero se instalan en los Equipos Windows 8 de una forma diferente. A esto se le conoce como Enterprise Sideloading, y la forma de hacerlo, lo veremos en el resto del artículo.

¿Requerimientos?

- Equipo con Windows 8 Enterprise, unido a un Controlador de Dominio, preferiblemente (Aunque no necesariamente) en Windows Server 2012. Si aún no tienen Windows 8 Enterprise, pueden descargar un período de prueba desde aquí: http://technet.microsoft.com/es-ES/evalcenter/hh699156.aspx?ocid=wc-bl-sprblog

Windows Server 2012 en su versión de prueba, lo pueden bajar desde aquí: http://technet.microsoft.com/es-ES/evalcenter/hh670538.aspx?wt.mc_id=TEC_108_1_5

*Nota: Debe ser Enterprise, y debe estar unido a un dominio. Si el equipo no está unido al dominio, o es Windows 8 PRO, debe activarse un tipo de clave denominada: Clave de producto para instalación de prueba, que se adquiere a través del sitio de licenciamiento por volumen de Microsoft.

*Nota: Si aún no han desarrollado por primera vez una aplicación para Windows 8, pueden hacerlo siguiendo este tutorial de MSDN: http://msdn.microsoft.com/es-ES/library/windows/apps/hh986964.aspx

Para este artículo, utilizaré una pequeña aplicación que desarrollé, incluyendo un Certificado generado por ella misma desde Visual Studio, y que contiene un simple título y texto para ilustrar:

*Nota: Para los que estén interesados en probar el Sideloading, pero no tengan tiempo (ni ganas) de desarrollar alguna aplicación de prueba, pueden descargar la que utilizaré en todo el artículo desde aquí:

Generando política en Controlador de Dominio

Para que Windows 8 pueda confiar en la instalación que se está realizando, es necesario habilitar la política de “Permitir que se instalen todas las aplicaciones de confianza” desde las directivas de grupo en el Servidor que cumpla el rol de Controlador de Dominio.

Para habilitarla, desde el Servidor que sea nuestro Controlador de Dominio, abrimos el Administrador de Políticas de Grupo, editamos la política predeterminada, o la que se cree para el grupo de Equipos Windows 8, y navegamos hasta:

Configuración de equipo\Políticas\Plantillas Administrativas\Componentes de Windows\Implementación de paquetes de aplicaciones.

Doble clic en ‘Permitir que se instalen todas las aplicaciones de confianza’, marcar Habilitado y aceptar todo para que se aplique la política:

Desde el Equipo cliente Windows 8, debemos actualizar las políticas de grupo, una vez se haya configurado en el Servidor. Para esto, basta con ejecutar en un símbolo del sistema con privilegios elevados el comando: gpupdate /force

Una vez hecho esto, Windows 8 tendrá la política activa, creando el valor de AllowAllTrustedApps:

Esto quiere decir que el valor de AllowAllTrustedApps activa la política localmente, así que los que deseen, pueden descargarlo e importarlo desde aquí:

Instalando Certificado

Para los que como en mi caso, tengan una aplicación completa, pero que no está firmada digitalmente con un certificado, y hayan tenido que crear uno al momento de compilar la aplicación, pueden seguir los siguientes pasos para instalarlo localmente:

En el Equipo Windows 8, vamos a los archivos de instalación de nuestra aplicación, y buscamos el certificado (Que tiene extensión .cer). Doble clic sobre el certificado de Seguridad, y en la ventana de Certificado, clic en el botón Install Certificate (Instalar Certificado):

En la página de bienvenida del asistente, seleccionar Local Machine y clic en el botón Next (Siguiente):

En la página de Certificate Store (Almacén de Certificado), seleccionar Place all certificate in the folowing store (Ubicar todos los certificados en el siguiente almacén) y seleccionar Trusted Root Certification Authorities:

En la página final del asistente, clic en el botón Finish (Finalizar) para terminar y que el certificado indique que fue instalado correctamente:

*Nota: Recordemos que el certificado hará que Windows confíe en la aplicación, y la política le permitirá a Windows instalar todas las aplicaciones en las que confíe.

¡Todo está listo! Hasta este punto, lo último que hay que hacer, es desplegar la aplicación de Windows 8.

*Nota: Una aplicación de Windows 8 predeterminadamente se instala por usuario, sin embargo, cuando se hace montaje de aplicaciones de interfaz moderna se puede decidir si se quiere instalar por usuario o por máquina (Para todos los usuarios). A continuación, explicaré cada uno.

Montar la aplicación por usuario

Para montar la aplicación por usuario, es necesario utilizar un par de comandos sencillos desde PowerShell, herramienta de scripting para IT Pros por excelencia. Para hacerlo:

1. Copiamos la carpeta con todos los archivos de instalación de nuestra aplicación de Interfaz Moderna al equipo Windows 8 Enterprise, en una ubicación fácil de referenciar, por ejemplo, en C:\, o bien podemos tenerla en una ruta de red.

2. Desde la Pantalla de Inicio, buscamos PowerShell, clic derecho y Ejecutar como Administrador. Nos abrirá la consola de PowerShell con privilegios elevados.

3. Desde PowerShell, ejecutamos los siguientes comandos en secuencia:

import-module appx

add-appxpackage <RutaAppx> –DependencyPath <RutaDependencyAppx>

Donde <RutaAppx> es la ubicación completa de nuestro paquete .appx generado desde Visual Studio, y <RutaDependencyAppx> es el directorio completo del paquete de dependencia que genera también Visual Studio dentro de los archivos de instalación de la aplicación, específicamente, en la carpeta Dependencies.

Para mi caso, que tengo la aplicación en C:\, el comando sería:

import-module appx

add-appxpackage C:\MyApp\ChechoBlog_1.0.0.1_AnyCPU_Debug_Test\ChechoBlog_1.0.0.1_AnyCPU_Debug.appx –DependencyPath C:\MyApp\ChechoBlog_1.0.0.1_AnyCPU_Debug_Test\Dependencies\Microsoft.WinJS.1.0.appx

Podremos ver nuestra aplicación desde la Pantalla de Inicio de Windows 8:

Este comando tendría que correrse en la sesión de cada usuario al que se le quiera instalar la aplicación.

Montar aplicación para todos los usuarios

En la mayoría de los casos, como se hace con las aplicaciones de escritorio, las empresas probablemente necesitarán desplegar la aplicación para todos los usuarios, y no hacerla dependiente solo de uno. Debemos proceder entonces a utilizar la herramienta de Administración y mantenimiento de imágenes de implementación (DISM), incluida en Windows y en el ADK para Windows 8.

*Nota: Esta herramienta tiene muchos otros usos, como actualizar, montar imágenes de Windows online/offline, agregar características, entre otras.

Para montar la aplicación de Windows 8 en todos los usuarios, debemos hacer lo siguiente:

1. Iniciar sesión en el Equipo Windows 8 con cualquier usuario de Dominio que tenga privilegios administrativos sobre la máquina (o sobre el dominio).

2. Copiamos la carpeta con todos los archivos de instalación de nuestra aplicación de Interfaz Moderna al equipo Windows 8 Enterprise, en una ubicación fácil de referenciar, por ejemplo, en C:\, o bien podemos tenerla en una ruta de red.

3. Desde la Pantalla de Inicio, digitar CMD, clic derecho sobre el resultado y “Ejecutar como administrador”

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

Dism /Online /Add-ProvisionedAppxPackage /PackagePath:<RutaAppx> /SkipLicense

Donde <RutaAppx> es la ubicación completa de nuestro paquete .appx generado desde Visual Studio.

Para este artículo, que tengo el paquete en C:\, el comando quedaría:

Dism /Online /Add-ProvisionedAppxPackage /PackagePath:C:\MyApp\ChechoBlog_1.0.0.1_AnyCPU_Debug_Test\
ChechoBlog_1.0.0.1_AnyCPU_Debug.appx /SkipLicense

5. Reiniciar el equipo.

Después de reiniciado el equipo, podremos ver nuestra aplicación funcionando en todos los usuarios, incluyendo el que la montó.

PowerShell o DISM, pueden ser utilizados también para Eliminar aplicaciones por usuario o para todos los usuarios.

En un próximo artículo (Parte 2) –No necesariamente el siguiente-, trataré de ejemplificar la forma de montar estas aplicaciones de una manera centralizada, utilizando Microsoft Deployment Toolkit (MDT) 2012.

Saludos,

Checho

Personalizar la Pantalla de Inicio y el Perfil predeterminado de Windows 8 con MDT 2012 Update 1.

2013-02-22T12:58:00Z

Hace unos días, estuvimos viendo el paso a paso en detalle de cómo podíamos Crear una imagen maestra con Pantalla de Inicio y Perfil personalizado de forma manual, es decir, utilizando sólo las herramientas incluidas en el ADK. El proceso –Aunque manual- era muy sencillo, consistía en activar el Administrador integrado, personalizar el perfil incluyendo escritorio y Pantalla de Inicio, resellar la imagen, capturarla, crear archivo de autorespuesta, crear la imagen .ISO y finalmente desplegarla en un equipo de referencia.

En el artículo de hoy, haremos exactamente lo mismo, pero de una forma más centralizada y ordenada haciendo uso de Microsoft Deployment Toolkit (MDT) 2012. Las fases se dividen en:

- Preparar el Deployment Share.
- Crear la Secuencia de Tareas para Resellar y Capturar la imagen.
- Personalizar el perfil a capturar.
- Resellar y Capturar la Imagen.
- Crear y personalizar la Secuencia de Tareas desde MDT.
- Implementar Windows 8 desde MDT.
- Verificar instalación.

Es importante tener en cuenta, que la idea de esto no es sólo aprender a capturar la imagen directamente desde MDT, sino además personalizar el perfil predeterminado a través de la Secuencia de Tareas antes de desplegar Windows.

Requerimientos

Necesitamos básicamente:

- Un equipo técnico que tenga de preferencia Windows Server 2008 R2 o 2012 con MDT y el ADK instalado.

- Un equipo de referencia con Windows 8 instalado, donde personalizaremos el perfil.

- Conexión de red entre las dos máquinas.

Preparar el Deployment Share

El procedimiento para preparar el Deployment Share, consiste básicamente en instalar el ADK y el MDT en el equipo técnico, además de configurarlo para que se pueda empezar a trabajar con todos sus componentes. Como esto requiere una serie de pasos, lo ideal es que se referencien del artículo pasado para la preparación del Deployment Share: http://geeks.ms/blogs/checho/archive/2013/02/05/implementaci-243-n-b-225-sica-de-windows-8-con-mdt-2012-update-1-y-windows-deployment-services.aspx

Exceptuando la instalación de Windows 8, la preparación del Deployment Share es exactamente la misma, y es en la que estará basada los siguientes pasos de este artículo.

Crear Secuencia de Tareas para Resellar y Capturar la Imagen

En el Equipo técnico donde está instalado MDT, desde la Pantalla de Inicio, abrimos Deployment Workbench. Una vez en la Consola, expandimos nuestro Deployment Share (Para este caso, Checho’s Blog), hacemos clic derecho en el nodo de Task Sequence y selecionamos New Task Sequence:

En el Asistente para la nueva Secuencia de Tareas, rellenamos los campos de la primera página General Settings con un ID que deseemos darle a la Secuencia de Tareas y su respectivo nombre. Para este caso, será el ID C1 y el nombre: Capture Windows 8 image. Clic en el botón de Next al terminar para continuar.

En la página de Select Template, seleccionamos entre la lista la de Sysprep and Capture y clic en el botón Next.

*Nota: Es primordial haber seleccionado Sysprep and Capture para que la captura y el resellado se puede hacer desde MDT.

En la página de Select OS, debemos escoger el sistema operativo que cumpla con las mismas características que el que se va a capturar. Esto es importante, porque de esta imagen, se creará el Windows PE, y si no corresponde al mismo sistema operativo, la operación muy probablemente fallará. Para este caso, por supuesto, seleccionaremos la que tengamos de Windows 8 Enterprise o PRO que hayamos configurado al crear y configurar el Deployment Share:

Clic en el botón Next.

En la página de Specify Product Key, dejamos la selección predeterminada de Do not specify a Product Key at this time y clic en el botón Next.

En la página de OS Settings, especificamos los datos de registro y clic en el botón Next.

En la página de Admin Password, especificamos una contraseña para el usuario que estamos capturando y clic en el botón Next.

Finalmente, en la página de Summary, clic en el botón Next para que se cree la Secuencia de Tareas y clic en el botón Finish para terminar. ¡Ya tenemos lista nuestra Task Sequence de captura!

Clic derecho en el Deployment Share (En este caso: Checho’s Blog) y clic en Update Deployment Share.

En el Asistente para actualizar el Deployment Share, dejamos la opción predeterminada para que actualice la actual imagen, y clic en el botón Next.

En la página de Summary, clic en el botón Next y en la página de Confirmation, clic en el botón Finish.

Personalizar el Perfil a capturar

En el Equipo de Referencia, debemos personalizar todo nuestro escritorio, pero más enfocado a Windows 8, la Pantalla de Inicio. Lo ideal es que cambiemos la interfaz de colores y diseños a la que nos gustaría fuese la corporativa, además de organizar los grupos y nombrarlos respectivamente.

*Nota: Es muy importante tener en cuenta, que los cambios se deben hacer desde la cuenta de Administrador integrado, que se activa ejecutando desde el Símbolo del sistema con privilegios elevados el siguiente comando:

Net User Administrator /Active:Yes

Si estamos en un equipo que tenga el sistema operativo en español, el comando sería:

Net User Administrador /Active:Yes

Para este post, yo hice unas de las personalizaciones básicas mencionadas anteriormente para ilustrar el proceso, al final me quedó así:

*Nota: Observen que hay una división de grupos, incluyendo nombres, diseños y colores de toda la Pantalla de Inicio. Además del usuario Administrator que será el que se copie al perfil predeterminado.

Aquí se puede incluir además instalar todas las aplicaciones del negocio, personalizar otras cosas más detalladas en el Registro, etc. En general, todo lo que deseamos tengan predeterminados cada usuario nuevo.

Resellar y Capturar la Imagen

Hay que asegurarnos de tener buena conexión local entre la máquina de referencia y la técnica, pues el siguiente paso, es conectarnos al recurso compartio, ejecutar la Secuencia de Tareas y dejar que MDT limpie y capture la imagen.

Desde el Equipo que personalizamos, es decir, el de Windows 8, abrimos una ventana de Ejecutar (Windows + R) y digitamos:

\$\Scripts">\$\Scripts">\$\Scripts">\\<NombreEquipoTécnico>\<NombreDeploymentShare>$\Scripts

Para este caso, que mi equipo técnico se llama DC, y el nombre del recurso compartido lo dejé como MDT lo predetermina, es decir: DeploymentShare$, el comando sería:

\\DC\DeploymentShare$\Scrtips

*Nota: Es probable que nos aparezca una ventana que solicita credenciales; en este caso, debemos indicarle las que tengan suficientes permisos administrativos para conectarse al equipo técnico.

En la carpeta de Scripts, navegamos hasta la parte inferior, debemos buscar el que se llama LiteTouch, pero como hay dos, es necesario ejecutar el primero de la lista:

Esto abrirá el asistente ya conocido de Microsoft Deployment Toolkit.

En la página de Task Sequence, seleccionamos la Secuencia de Tareas que creamos en el paso de Crear Secuencia de Tareas para Resellar y Capturar la imagen y clic en Next.

En la página de Capture Image, seleccionamos la primera opción de Capture an imagen of this reference computer y renombramos el archivo debajo de File name a install.wim

Clic en el botón Next para continuar.

*Nota: Vean que esto guardará la imagen capturada en la carpeta Captures de nuestro recurso compartido.

En la página de Credentials, indicamos el respectivo nombre de usuario, contraseña y dominio para conectarnos a nuestro recurso compartido y clic en el botón Next.

En la página de Ready, clic en el botón Begin para iniciar.

El Asistente de instalación empezará a realizar el resellado y la captura de la imagen automáticamente:

*Nota: Al iniciar la captura, podrían recibir el siguiente mensaje de error:

En caso de ser así, ver mi artículo anterior donde explico la causa y su respectiva solución: http://geeks.ms/blogs/checho/archive/2013/02/20/la-secuencia-de-tareas-que-no-quer-237-a-capturar-los-errores-0x80041002-0x8004005-de-mdt-el-log-de-ltiapply-y-su-soluci-243-n.aspx

Cuando finalice el asistente, en la ventana de Summary, clic en el botón Finish.

Crear y personalizar la Secuencia de Tareas desde MDT

Nuestro siguiente paso, se compone de agregar el sistema operativo recién capturado, y después crear la secuencia de tareas que hará su despliegue, indicando por supuesto, que se copie todo el perfil de usuario personalizado al predeterminado.

Agregar sistema operativo

En el Equipo técnico, abrimos el Deployment Workbench, expandimos el nodo de Deployment Shares y sobre el que estemos trabajo, clic derecho en el nodo de Operating Systems, y en Import Operating System:

Se abrirá el Asistente para importar un nuevo sistema operativo. En la página de OS Type, a diferencia de anteriores ocasiones, seleccionamos la segunda opción: “Custom image file”, para poder referenciar a nuestro install.wim capturado y hacemos clic en el botón Next.

En la página de Image, clic en el botón Browse y buscamos la ubicación de nuestro install.wim. Si seguimos todos los pasos anteriores, estará en la carpeta de Captures dentro de nuestro Deployment Share. Para mi caso, que dejé los nombres predeterminados, estaría en C:\DeploymentShare\Captures.

Clic en el botón Open y Next.

En la página de Setup, debemos seleccionar la primera opción si previamente ya habíamos agregado un sistema operativo completo (Lo que ya tendrían si siguieron el artículo anterior), o la segunda opción para agregar los archivos de instalación, en caso de que no hayan agregado previamente Windows 8. Para este caso, contaremos con que ya se agregó uno antes, por lo que será la primera y clic en Next.

En la página de Destination, le especificamos un nombre personalizado, o dejamos el predeterminado y clic en el botón Next.

En la página de Summary, clic en el botón Next para iniciar la copia y finalmente, en la página de Confirmation, clic en el botón Finish.

Crear Secuencia de Tareas

En el nodo de Task Sequences, clic derecho y seleccionamos New Task Sequence. Se abrirá el asistente para agregar una nueva Secuencia de Tareas.

*Nota: Esta será la que utilicemos para implementar nuestra imagen maestra ya capturada.

En la página de General Settings, indicamos un ID para la Secuencia de Tareas y un respectivo nombre para dar clic en el botón Next.

En la página de Select Template, escogemos Standard Client Task Sequence y clic en el botón Next.

En la página de Select OS, debemos seleccionar la imagen personalizada que agregamos (Probablemente tenga un nombre un poco extraño, que se compone del ID de la Secuencia de Tareas de captura) y clic en el botón Next.

En la página de Specify Product Key, dejamos la predeterminada y clic en el botón Next.

En la página de OS Settings, rellenamos los campos correspondiente al registro y clic en el botón Next.

En la página de Admin Password, especificamos una contraseña para nuestro administrador integrado y clic en el botón Next.

En la página de Summary, clic en Next. En la página de Confirmation, clic en el botón Finish.

Personalizando Secuencia de Tareas

Lo que sigue es básicamente personalizar el Archivo de Autorespuesta que está embebido en cada Secuencia de Tareas, e indicarle que deseamos copiar el diseño de nuestro perfil, al predeterminado de Windows.

Sobre el nodo de Task Sequences, en la parte derecha donde se encuentran nuestras Secuencias de Tareas, clic derecho en la que recién creamos y seleccionamos Properties:

En la pestaña de OS Info, clic en el botón Edit Unattend.xml. Se abrirá el System Image Manager con el Autorespuesta embebido.

*Nota: Es posible que se empiece a generar el archivo de catálogo para la imagen, por lo que debemos esperar algunos minutos con paciencia.

En el panel central, debajo de Answer File, veremos que ya hay una gran cantidad de componentes agregados. Debemos expandir el nodo de Specialize, seleccionar Microsoft-Windows-Shell-Setup_neutral y en el panel derecho de Properties, buscamos CopyProfile y lo cambiamos a True.

*Nota: Con esto, haremos que Windows en su proceso natural de implementación, copie todo el perfil que configuramos dentro del usuario Administrador integrado, al perfil predeterminado de Windows, es decir, remplazar todo lo de la carpeta \Default.

Podemos aprovechar, y personalizar otros aspectos dentro del Archivo de Autorespuesta (Como agregar usuarios). Al terminar, clic en el botón File y Save Answer File.

Cerramos el System Image Manager (SIM), y clic en el botón de OK dentro de las propiedades de la Secuencia de Tareas para terminar.

Actualizar Deployment Share

Estamos casi listos. Hacemos clic derecho en nuestro Deployment Share (Para este caso: Checho’s Blog) y seleccionamos Update Deployment Share.

En la página de Options en el Asistente para actualizar el Deployment Share, dejamos la opción predeterminada de Optimize the boot image updating process y clic en Next.

En la página de Summary, clic en Next. En la página de Confirmation, al terminar todo, clic en el botón Finish.

Implementar Windows 8 desde MDT

Lo ideal siempre que se esté usando MDT, es unirlo con WDS para que el proceso de administración lo tenga la Consola, y el de implementación el rol. Para instalar y configurar WDS en Server 2012, pueden ver el siguiente Wiki que escribí para el post anterior: http://social.technet.microsoft.com/wiki/contents/articles/15720.instalacion-y-configuracion-basica-de-windows-deployment-services-en-server-2012-es-es.aspx

Para este artículo, contaré con que están usando también WDS, e implementaremos Windows 8 con su ayuda.

En la Consola de WDS, expandimos nuestro Servidor, clic derecho en Boot Images, y selecionamos Add Boot Image:

En la página de Image File, debemos referenciar el archivo LiteTouchPE_<Arquitectura>.wim que se haya generado al actualizar el Deployment Share y que está ubicado en la carpeta \Boot de nuestro Deployment Share. Clic en el botón Next.

*Nota: <Arquitectura> hace referencia a x86 o x64. Es importante además tener en cuenta, que la ruta del .wim puede variar, dependiendo de cómo se haya llamado el Deployment Share al crearlo.

En la página de Image Metadata, podemos cambiar o dejar el nombre que hay y clic en el botón Next.

En la página de Summary, clic en el botón Next. Después de terminar el proceso, en la página de Task Progress, clic en el botón Finish para terminar.

Nuestro último paso, es utilizar un equipo de referencia (puede ser máquina virtual), conectarlo a la red de nuestro MDT y WDS, iniciar por red y seguir nuestro asistente de instalación de MDT. Como ya lo hemos visto en varias ocasiones, pondré la secuencia de pasos normales que se tendrían que ver, a menos que alguno los haya automatizado o cambiado:

*Nota: Clic en las imágenes para verlas en tamaño completo.

Tener presente en la página de Task Sequence, seleccionar la Secuencia de Tareas que se creó específicamente para esto agregando la imagen maestra ya capturada:

En los siguientes pasos, se especifica unión al dominio si se desea, respaldos, configuración regional, aplicaciones, y se inicia la instalación.

Verificar instalación

Cuando termine la instalación, basta con empezar a crear usuarios y veremos que cada uno de ellos copiará el perfil que personalizamos en nuestros primeros pasos. Inclusive, usuarios de dominio:

Espero les sea de utilidad.

Saludos,

Checho

La Secuencia de Tareas que no quería capturar, los errores 0x80041002/0x8004005 de MDT, el log de LTIApply y su solución.

2013-02-20T14:04:00Z

Como la mayoría de artículos referentes a soluciones de problemas, salen más que todo por necesidad, pues se vuelven recurrentes o difíciles de solventar. Por tanto, la solución debe ser compartida.

Este problema en específico, nació en un Step by Step de Windows 8 que estuve ejecutando aquí en la ciudad de Medellín en conjunto con el equipo de DPE de Microsoft Colombia (¡Vaya escenario para tener un fallo!). El laboratorio consistían en utilizar Microsoft Deployment Toolkit para capturar una imagen de referencia de Windows 8 y después desplegarla desde MDT y WDS. Para esto, estábamos creando una Secuencia de Tareas para capturar la imagen (En un artículo próximo detallaré el paso a paso), la ejecutábamos desde Windows 8 y la idea era esperar a que MDT resellara y capturara la imagen sin mucha ayuda.

El error

Una vez iniciaba la Secuencia de Tareas, recibíamos un mensaje poco claro – Como cosa rara- de MDT y nunca procedía a capturar. El mensaje era el siguiente:

“ZTI ERROR – Unhandled error returned by LTApply: Not found”

Normalmente, las primeras líneas, aunque muy confusas, suelen entregar la especificación del error. En este caso, hay tres detalles importantes: LTIApply, que referencia a un proceso y a un log, el código de error 0x8004005 y la acción que entregaba fallida: Apply Windows PE.

Lo primero que hice, fue proceder a crear de nuevo la Secuencia de Tareas, pues entre modificación y modificación, se puede dañar o corromper. Sin embargo, el problema seguía. Mi segundo intento fue crear un nuevo Deployment Share, e incluso seguir el problema con Process Monitor, pero nada funcionó.

La causa

Como Process Monitor tampoco me entregó nada claro, tenía que proceder a intentar seguir el error con ayuda directa de Microsoft Deployment Toolkit.

Aunque es casi lo último que hago, o hacemos (Cosa que no debería ser así), seguir los Logs de ejecución que lleva la aplicación, suele ser una buena práctica para encontrar el causante de este tipo de problemas.
Microsoft Deployment Toolkit (MDT), crea un log de errores en la carpeta MININT, que está ubicada en la unidad X: si se está utilizando un Windows PE, o en el directorio C:\ como en este caso. Sin embargo, este primer log es deseguimiento al asistente, por lo que una vez terminado el proceso, borra esta carpeta y deja todo el log de ejecución en la carpeta %WINDIR%\TEMP\DeploymentLogs.

El “problema”, es que se generan varios logs dentro de esta carpeta:

El más importante, suele ser el BDD, pero cuando allí no se encuentra mayor ayuda, es muy útil dejarse llevar por el instinto, y utilizar la poca documentación del problema que entrega el asistente y con eso encontrar la causa.

Para este caso, el mensaje de error hacía referencia a un comportamiento que no se pudo manejar, y que devolvió LTIApply, y como podemos ver, hay todo un log propio de esto.

Al abrir el log de LTIApply, y buscar un poco en los inicios de cada frase, me encontré con estas interesantes líneas:

Lo primero que decía era “Found bootable drive”, y especificaba la unidad “E”, asignada a la partición del sistema de forma predeterminada por MDT, puesto que es la que contiene los archivos de arranque de Windows. (Se conoce como partición reservada). Hasta ahí no había mucho de raro, sin embargo, en las líneas más abajo, encontré lo más importante:

“Available space on boot drive: 111300”, que indicaba el espacio disponible de la unidad reservada, y abajo de esta decía: “Boot file size: 231272.715820313”, que era el archivo de arranque que iba a utilizar MDT. La última línea entonces entregaba un mensaje muy lógico: “Not enough space for boot image on boot parttition…”. Quiere decir, que la unidad no tenía suficiente espacio para almacenar la imagen de arranque.

La Secuencia de Tareas que se encarga de Capturar y Resellar (Sysprep and Capture), predeterminadamente, cuando se ejecuta desde una ruta de red, guarda su propio Windows PE (LIteTouchPE_<Arquitectura>.wim) en la partición de arranque; esto para poder iniciar desde el Windows PE y trabajar sobre la partición del sistema sin peligro a interferencias. El problema aquí, es que esta partición no tenía suficiente espacio para almacenar el Windows PE generado desde el MDT, y es apenas normal, pues una instalación limpia de Windows, genera una partición de apenas 250MB.

La solución

Lo más fácil, es que si hay espacio disponible, desde el Administrador de Discos (Diskmgmt.msc), se expanda la partición reservada del sistema, y así darle espacio al Windows PE para que sea copiado sin problemas.

Sin embargo, como fue en mi caso, no había más espacio, así que debe procederse a otro workaround al respecto. Básicamente, eliminar la partición reservada, y hacer que la unidad C:\ sea la del sistema operativo, y a la vez, la partición activa que contenga los archivos de arranque de Windows. Para lograr esto, debemos hacer lo siguiente:

- En el Equipo de referencia (Windows 8), abrir el Símbolo del sistema con privilegios elevados (Desde la Pantalla de Inicio, digitar CMD, clic derecho, Ejecutar como administrador).

- Ejecutar: bcdboot C:\Windows /s C:

- Desde la ventana de Ejecutar (Windows + R), abrir el Administrador de Discos digitando: diskmgmt.msc

- Clic derecho sobre la unidad C:\ y seleccionar “Mark Partition as Active” (Marcar como Partición Activa):

*Nota: En el mensaje de advertencia, clic en el botón Aceptar.

- Reinciar el sistema operativo.

- Una vez se reinicie Windows, ir nuevamente al Administrador de Discos (Diskmgmt.msc), clic derecho en la partición reservada del sistema y seleccionar Eliminar Volumen (Delete Volume)

- Reiniciar el sistema operativo.

Una vez hecho esto, bastará con ir a ejecutar nuevamente la Secuencia de Tareas para capturar la imagen, y ahora el proceso iniciará y continuará sin problemas:

Saludos,

Checho

Implementación básica de Windows 8 con MDT 2012 Update 1 y Windows Deployment Services.

2013-02-05T13:14:00Z

Como lo mencioné en el anterior post, vamos empezando poco a poco a tratar temas relacionados con implementación de Windows, pues aunque aún es muy pronto para que la mayoría de las organizaciones desplieguen Windows 8, es muy probable que una gran cantidad se encuentren en proceso de adopción y de pruebas de concepto sobre las aplicaciones, funcionamiento y por supuesto, implementación.

El problema está, que no siempre conocemos las herramientas y procedimientos que Microsoft nos brinda para que nuestra experiencia con el despliegue de sistemas operativos sea lo más cómoda y transparente posible. Una de ellas, es gratuita y es una herramienta que aunque poco documentada, tiene una flexibilidad bastante grande que toda compañía puede aprovechar.

El artículo de hoy, iniciará una serie de contenidos que estaré creando aquí – Aunque no necesariamente seguidos-, en los que documentaré la mayor cantidad de escenarios y procedimientos que Microsoft Deployment Toolkit (MDT) tiene para ofrecer en entornos de implementación, junto con algunas variantes que abarquen otras soluciones como WDS y procedimientos con herramientas, como las del ADK.

En este primer artículo, haremos una implementación básica de Windows 8, utilizando Microsoft Deployment Toolkit para gestionar todos los componentes necesarios, y Windows Deployment Services para hacer el despliegue a través de la red.

¿Qué necesitamos?

- Un equipo técnico que tenga Windows 8 o Windows Server 2012 (Preferiblemente), que esté instalado el rol de Windows Deployment Services (Servidor), el ADK para Windows 8 y Microsoft Deployment Tolkit 2012 Update 1.

Si no tienen el ADK, pueden descargarlo desde aquí, y el Microsoft Deployment Toolkit, pueden bajarlo desde aquí.

- Un equipo de referencia, que esté en la misma red del equipo técnico, para realizar la prueba de despliegue.

*Nota: Todo este ambiente se puede crear en máquinas virtuales.

Creando y configurando nuestro primer Deployment Share

En el equipo técnico con Windows Server 2012, que tiene instalado la consola de MDT, desde la Pantalla de Inicio, ejecutamos el Deployment Workbench con privilegios administrativos (Clic derecho, Ejecutar como administrador en la parte inferior).

En la consola del Deployment Workbench, hacemos clic derecho sobre Deployment Shares, y seleccionamos New Deployment Share. Esto nos abrirá el asistente para la creación de un nuevo Deployment Share, que en términos básicos, es un recurso compartido de red donde estará todo lo que agreguemos para la instalación de Windows 8 (Actualizaciones, Sistemas operativos, etc):

En la página de Path, debemos indiciarle el directorio local donde se creará el recurso de red, obviamente debe disponer de un espacio en disco suficiente para alojar controladores, sistemas operativos y actualizaciones principalmente. Después de esto, hacemos clic en el botón Next.

En la página de Share, se le agregará al nombre de la carpeta el signo de pesos ($), para que este recurso de red esté oculto de forma predeterminada. Pueden modificarlo a su antojo, o dejar el nombre predeterminado y hacer clic en Next:

En Descriptive Name, debemos especificar el nombre del Deployment Share que se reflejará en la consola de MDT. Lo ideal es que sea un nombre que describa bien la compañía o el objetivo, pues se pueden crear varios Deployment Shares en una sola consola. Para este caso, yo especifiqué Checho’s Blog.

Clic en el botón Next.

En la página de Options, podemos seleccionar, o quitar la selección de diferentes tareas básicas que podemos hacer mientras se ejecuta el primer asistente de instalación. Para este artículo, dejaré casi todas las opciones predeterminadas, exceptuando la del Backup del equipo, la selección de cada uno dependerá de qué desea hacer, pues aquí podemos especificar un código de producto, capturar la imagen, respaldar, entre otras.

Clic en el botón Next.

En la página de Summary, hacemos clic en Next y en la página de Confirmation, clic en el botón Finish para terminar el asistente. Debajo de nuestro Deployment Share, se crearán las carpetas predeterminadas para empezar a agregar componentes:

*Nota: Toda esta configuración se puede hacer fácilmente con un Script de PowerShell que crea el asistente de creación para un nuevo Deployment Share. Basta con hacer clic en el botón View Script de la última página, personalizarlo y ejecutarlo.

Agregando componentes

Lo siguiente, es empezar a agregar uno por uno, Aplicaciones, Sistemas Operativos, Controladores y Actualizaciones. Además de crear la Secuencia de tareas que hará el despliegue. Es importante que la ventaja de MDT, es que aprovecha que Windows en general se compone de módulos independientes; con MDT podemos disponer de una imagen maestra, pero liviana, y desde aquí asegurar un estándar de aplicaciones, controladores y actualizaciones sin necesidad de tener que disponer una sola imagen muy pesada y que requiera un mantenimiento constante.

Con motivo de este post, agregaré una aplicación y algunas actualizaciones para ver el procedimiento. Ustedes pueden agregar los componentes que quieran, y la cantidad que deseen, además de personalizar su comportamiento, aunque en este artículo no lo detallaremos, pues se trata de los primeros pasos básicos.

Aplicaciones

Para agregar aplicaciones, hacemos clic derecho en el nodo de Applications y seleccionamos New Application. Se abrirá el asistente para agregar nueva aplicación.

*Nota: Podemos hacer clic en New Folder para crear una o varias carpetas internas y allí organizar adecuadamente nuestros componentes.

En la página de Application Type, dejamos la selección predeterminada de Application with source files y hacemos clic en el botón Next.

*Nota: Aquí se pueden agregar diferentes tipos de aplicaciones, por ejemplo, las que están ubicadas en recursos de red, o que son dependientes de otras aplicaciones para ejecutarse. El tipo de aplicación determinará la selección.

En la página de Details, rellenamos todos los campos, especialmente el de Application Name, para darle una descripción adecuada a nuestra aplicación y hacemos clic en el botón Next.

En la página de Source, especificamos el directorio donde está nuestro instalador haciendo clic en el botón Browse o indicando la ruta manualmente. Después de esto, clic en Next.

*Nota: La aplicación debe estar siempre guardada en una carpeta, el asistente no reconocerá el .EXE nativamente. Pueden además de esto, seleccionar ‘Move the files to the deployment share instead of copying them’ para que el asistente corte y pegue los archivos fuente de la aplicación dentro del recurso compartido.

En la página de Destination, podemos personalizar el nombre que aparecerá en el Deployment Workbench (Consola de MDT), o bien dejar el predeterminado que se compone de los datos escritos en la página de Details. Clic en Next.

En la página de Command Details, debajo de Command line, debemos referenciar el nombre del ejecutable, y la bandera o banderas que se requieran para una instalación silenciosa, después de que Windows se despliegue. Para este caso, que utilicé la aplicación de WinRAR, el comando sería: WinRAR.exe /S. Clic en Next para continuar.

*Nota: Si sólo se especifica el nombre del ejecutable, el usuario tendrá que dirigir el asistente de instalación para la respectiva aplicación después de que se instale el sistema operativo.

En la página de Summary, revisamos toda nuestra configuración, hacemos clic en el botón Next y finalmente clic en el botón Finish de la página Confirmation para terminar.

*Nota: Es el mismo procedimiento para cada nueva aplicación.

Sistemas Operativos

Para agregar un nuevo Sistema Operativo, hacemos clic derecho sobre el nodo de Operating Systems y clic en Import Operating System. Se abrirá el asistente para importar un nuevo sistema operativo:

En la página de OS Type, dejamos la selección predeterminada de Full set of source files y hacemos clic en el botón Next.

*Nota: En la selección básica, se agregan todos los archivos de instalación de Windows. Sin embargo, se puede agregar solo una imagen (.WIM) o bien, importarla desde el nodo de Windows Deployment Services.

En la página de Source, especificamos la unidad o directorio que contiene los archivos de instalación de Windows 8, en cualquier arquitectura y clic en el botón Next.

En la página de Destination, como en el proceso de agregar Aplicaciones, especificamos el nombre que deseamos se vea en el MDT, o bien podemos dejar el nombre predeterminado. Después de esto, hacemos clic en el botón Next.

*Nota: Recordemos que es posible descargar un período de prueba gratuito de Windows 8 Enterprise desde aquí: http://technet.microsoft.com/es-ES/evalcenter/hh699156.aspx?ocid=wc-bl-sprblog

En la página de Summary, hacemos clic en el botón Next para que inicie el proceso de copia y una vez termine, hacemos clic en el botón Finish de la página de Confirmation.

Controladores

El proceso para agregar controladores es más sencillo que los anteriores. Basta con hacer clic derecho en el nodo de Out-of-Box Drivers y seleccionar Import Drivers.

En la página de Specify Directory, buscamos la carpeta con todo el repositorio de controladores (Sin importar el fabricante) que deseamos agregar. Hacemos clic en Next para importar, clic en el botón Next de la página Summary y cuando termine el proceso, clic en el botón Finish de Confirmation para terminar.

Actualizaciones

Para agregar actualizaciones (.MSU o .cabs), hacemos clic derecho en el nodo de Packages y seleccionamos Import OS Packages. Se abrirá el asistente para agregar una nueva actualización:

*Nota: Si la actualización que vamos a agregar no tiene el formato soportado, el asistente no la reconocerá.

En la página de Specify Directory, seleccionamos la carpeta que contenga todas nuestras actualizaciones haciendo clic en el botón Browse para referenciarla y posteriormente, clic en el botón Next.

En la página de Summary hacemos clic en el botón Next y en la página de Confirmation, clic en el botón Finish para terminar.

Secuencias de Tareas

Lo último para agregar, que es de vital importancia además, es la Secuencia de Tareas. Una Secuencia de Tareas (Task Sequence), es básicamente un script que como el XML tradicional generado para el archivo de respuesta que ya conocemos, se encarga de manejar todo el asistente de instalación de Windows, adicionando las configuraciones adicionales que entrega el propio MDT. Hay Secuencias de Tareas para múltiples operaciones, como remplazo de equipo, migración, Sysprep y Captura, entre otras. Y es tan flexible como uno quiera, así que por supuesto, es totalmente automatizable.

Para agregar y editar una nueva Secuencia de Tareas, hacemos clic derecho en el nodo de Task Sequences, y seleccionamos New Task Sequence. Se abrirá el asistente para una nueva Secuencia de Tareas.

En la página de General Settings, especificados un identificador para la Secuencia de Tareas, además de un Nombre y una Descripción. Después de esto, clic en el botón Next.

*Nota: Es importante estandarizar los identificadores (IDs), pues se utilizan en diferentes procedimientos y escenarios más avanzados de MDT.

En la página de Select Template, dejamos la selección predeterminada de ‘Standard Client Task Sequence’ y hacemos clic en el botón Next.

*Nota: En esta página es donde podemos llegar a generar Secuencias de Tareas para diferentes procedimientos avanzados o personalizados. En futuros artículos, veremos otros escenarios.

En la página de Select OS, escogemos el sistema operativo que deseamos instalar, de acuerdo a los que hayamos agregado en pasos anteriores. Para este caso, por supuesto, será Windows 8 Enterprise. Hacemos clic luego en el botón Next.

En la página de Specify Product Key, dejamos la selección predeterminada y hacemos clic en el botón Next.

*Nota: Dependerá mucho del modelo de licenciamiento para escoger darle claves de producto MAK o de única activación.

En la página de OS Settings, personalizamos los campos de registro del Sistema Operativo y página de inicio de IE y hacemos clic en el botón Next.

En la página de Admi Password, digitamos una contraseña personalizada para la cuenta integrada de Administrador y clic en el botón Next.

*Nota: Aquí podemos dejar la contraseña en blanco con solo indicarle ‘Dot not specify an Administrator password at this time’.

En la página de Summary, clic en el botón Next y en la página de Confirmation, clic en el botón Finish para terminar.

Actualizando Deployment Share

Debemos proceder a crear el Windows PE (Entorno de Preinstalación de Windows) del MDT, para que cada que se inicie desde él en un nuevo equipo, esté listo para conectarse directamente al recurso de red y pueda ejecutar el asistente de instalación del MDT.

En el Deployment Share, hacemos clic derecho sobre nuestro Deployment Share creado (En este caso, Checho’s Blog) y seleccionamos Update Deployment Share:

En el Asistente para actualizar el Deployment Share, dejamos la selección predeterminada de “Optimize the boot image updating process”, y clic en el botón Next.

Esto creará el Windows PE personalizado para MDT, y lo ubicará en la carpeta Boot de nuestro recurso compartido.

*Nota: En algunos casos, será necesario darle a “Completely regenerate the boot images” para que se creen desde cero, pues la anterior siempre actualizará la que haya creada (La primera vez, por supuesto generará una nueva), para que el proceso dure mucho menos.

En la página de Summary, clic en el botón Next, y en la página de Confirmation, clic en el botón Finish.

Agregando imagen de preinstalación al WDS

El Windows PE que genera el MDT se puede grabar en una USB o DVD y cargarse en cualquier equipo para que se conecte por red local, pero como la idea es que sea un ambiente de producción básico para implementación, es mejor integrarlo con WDS para este trabajo.

Por supuesto, para el siguiente procedimiento, previamente se debe instalar y configurar la característica de Windows Deployment Services (WDS) en el Servidor 2012. Para los que no sepan hacerlo, he escrito un artículo en TechNet Wiki con el paso a paso hasta donde lo necesitamos en este post: http://social.technet.microsoft.com/wiki/contents/articles/15720.instalacion-y-configuracion-basica-de-windows-deployment-services-en-server-2012-es-es.aspx

*Nota: Como es un Wiki, pueden editarlo para agregar claridades, si desean.

Una vez instalado y configurado el WDS, abrimos la Consola, expandimos nuestro Servidor, hacemos clic derecho en el nodo de Boot Images y seleccionamos ‘Add Boot Image…’:

Se abrirá el asistente para agregar una nueva imagen. En la página de Image File, hacemos clic en el botón Browse y buscamos el directorio de nuestra imagen, dependiendo de la arquitectura que deseamos cargar. La imagen se encuentra en la carpeta Boot del DeploymentShare. Si se dejó el nombre predeterminado, sería:

<Unidad>\DeploymentShare\Boot\LiteTouchPE_<Arquitectura>.wim

Por ejemplo, para este artículo:

C:\DeploymentShare\Boot\LiteTouchPE_x64.wim

Hacemos clic en el botón Next para continuar.

En la página de Image Metadata, podemos dejar el nombre y descripción de la imagen predeterminados, y clic en el botón Next.

En la página de Summary, clic en el botón Next, esperamos a que se agregue la imagen y en la página de Task Progress, clic en el botón Finish.

Si todo salió bien, en el WDS se debe visualizar la imagen similar a la de la siguiente captura:

Desplegando Windows

Todo esto, para la gran prueba final. Lo que tenemos que hacer ahora, es iniciar el equipo de referencia donde se vaya a realizar la instalación desde la red, y si se conecta al WDS por PXE, nos pedirá presionar F12 y a continuación, arrancará el ambiente de preinstalación de MDT:

Si no se automatizó en el asistente de instalación, la primera pantalla que veremos, será una similar a esta:

*Nota: El fondo se puede personalizar al del ambiente corporativo. Está ubicado en la carpeta C:\Program Files\Microsoft Deployment Toolkit\Samples. Basta con remplazar el Background con otra imagen personalizada del mismo formato (.BMP), tamaño y peso. También se puede hacer directamente desde el Deployment Workbench, haciendo clic derecho en el Deployment Share creado (En mi caso, Checho’s Blog), Properties, pestaña Windows PE y referenciar la nueva imagen en Custom background image bitmap file:

Volviendo al asistente, cambiar el Keyboard Layout al método de entrada que deseen, por ejemplo Español, y clic en botón Run the Deployment Wizard to install a new Operating System para iniciar el asistente de instalación.

En la ventana de User Credentials, debemos autenticarnos con la cuenta local o de dominio que tenga permisos administrativos para instalación:

En la ventana de Task Sequence, seleccionamos la Secuencia de Tareas que hayamos creado para la instalación, y clic en el botón Next.

En la página de Computer Details, rellenamos los cambios para unirlo el equipo a un dominio, o bien a un grupo de hogar, y el nombre del equipo.

En la página de Move Data and Settings, es donde podríamos especificar una ubicación de red donde se guarde nuestro perfil y configuraciones, en el caso de una migración. En esta implementación básica, donde es un equipo en limpio, dejamos el valor predeterminado y clic en el botón Next.

En la página de User Data (Restore), dejar el valor predeterminado que está seleccionado y clic en el botón Next.

En la página de Locale and Time, personalizamos nuestra configuración regional y de teclado y clic en el botón Next.

En la página de Applications, seleccionamos la aplicación, o las aplicaciones que hayamos personalizado en el Deployment Workbench, y clic en el botón Next.

En la página de Ready, clic en el botón Begin para comenzar la instalación.

*Nota: Recordemos que el proceso anterior se puede automatizar completamente, hasta el punto de sólo presionar F12 y esperar a que se instale y configure. En artículos posteriores intentaré cubrir más en detalle.

La instalación de Windows 8 finalmente empezará, guiada por el asistente de MDT hasta el final, que nos irá indicando lo que se está haciendo dentro de la Secuencia de Tareas:

*Nota: El proceso de instalación puede tardar más o menos, dependiendo de los recursos físicos.

Una vez terminada la instalación, estaremos en nuestra Pantalla de Inicio con la cuenta de Administrador integrado – A menos que se haya pre-configurado una cuenta adicional en la Secuencia de tareas-, y con todas las aplicaciones –si fueron por máquina- instaladas.

En próximos artículos, trataré temas como el particionamiento del disco, edición de la Secuencia de tareas y Archivos de autorespuesta, automatizacíon, entre otros.

Saludos,

Checho

Crear imagen maestra de Windows 8 con Pantalla de Inicio y Perfil personalizado.

2013-01-17T18:17:00Z

Este, es el primer artículo en el que oficialmente tocaré temas acerca de la implementación de Windows 8 en entornos empresariales. Quiero empezar con algo con lo que cada responsable de implementación en las compañías suele requerir y querer aprender de primero, y es la creación y personalización de la imagen maestra.

Recordemos que cuando instalamos Windows desde el medio de instalación original, al crear un nuevo perfil, siempre tendremos unas personalizaciones predeterminadas, como el fondo y color azul, configuración del puntero del mouse, entre muchas otras. En entornos empresariales, es normal que cada compañía quiera darle un toque de personalización a las imágenes, por lo que siempre buscará un estándar en aspectos como fondos y aplicaciones corporativas, para que todos los usuarios, una vez inicien sesión, o obtengan de la misma forma.

En este artículo trataré de explicar – hasta donde mi capacidad me lo permite – de la forma más clara posible, el paso a paso para construir y desplegar una imagen maestra con un perfil predefinido por nosotros. Pero además, aprovechando la nueva Pantalla de Inicio de Windows 8, explicaré cómo podemos llegar a personalizar el primer aspecto visual en cuanto a iconos, diseños y colores que un usuario podría ver cuando se construye su perfil.

*Nota: Hay otros artículos viejos que muestran gran parte del mismo procedimiento, pero por lo anterior, y por la actualización en herramientas y algunas variaciones, consideré importante crear este post.

Requerimientos

- Antes que nada, los archivos de instalación de Windows 8. Si aún no lo tienen, pueden descargar y probar por 90 días la versión Enterprise desde aquí: http://technet.microsoft.com/es-eS/evalcenter/hh699156.aspx

- Equipo técnico donde se encuentre instalado el ADK para Windows 8. Si no lo tienen, pueden descargarlo desde aquí: http://www.microsoft.com/es-es/download/details.aspx?id=30652

- Opcional: Partición, memoria o disco extraible adicional para copiar la imagen maestra.

- Un equipo de referencia (Puede ser máquina virtual) donde se cree la imagen maestra, y posteriormente se implemente.

Creando nuestro perfil predeterminado y resellando la imagen

Lo primero que tenemos que hacer, es preparar el perfil con todas las configuraciones y personalizaciones que deseamos sean heredadas por cada nuevo perfil. Como primera recomendación, esto se debe hacer desde la cuenta integrada de Administrador, y no desde alguna otra cuenta; esto para evitar que se copien cuentas en cada instalación, y para que después de resellar el equipo, la cuenta de Administrador pase a estar en estado de desactivada nuevamente.

Como de hecho, de forma predeterminada esta cuenta no se encuentra activa, es necesario ejecutar el Símbolo del sistema con privilegios elevados (Clic derecho, Ejecutar como administrador) desde alguna cuenta del grupo de administradores, y ejecutar el siguiente comando:

Net User Administrador /Active:Yes

*Nota: Si tienen el equipo en Inglés, como es para mi caso, el comando variaría de “Administrador” a “Administrator”.

Basta con cerrar sesión desde la Pantalla de Inicio, e iniciar desde la cuenta de Administrador. Una vez hecho esto, eliminamos todas las otras cuentas desde Cuentas de Usuario y Seguridad Familiar en el Panel de Control.

La personalización del perfil se divide ahora en dos partes, todo lo que hagan desde el Escritorio tradicional (Fondos de pantalla, color a las ventanas, tamaño del cursor, opciones de carpeta, etc), y todo lo que se haga desde la nueva Pantalla de Inicio. Como el primero es más común, nos concentraremos en la Pantalla de Inicio.

Predeterminadamente, podrán ver una personalización de aplicaciones, diseños y colores similar a la siguiente:

Lo ideal, es que saquemos ventaja de la Pantalla de Inicio, y la personalicemos a como nos gustaría verla en nuestro entorno empresarial. Por ejemplo, quitando aplicaciones, creando grupos, cambiando el color y asignándole nombre a los diferentes grupos o categorías. Para mi caso, en pro del artículo, cambié varias cosas para notar la diferencia y ver cómo deseaba que mi perfil se reflejara en los futuros nuevos usuarios:

Al terminar todas las personalizaciones, debemos pasar a realizar el resellado del equipo con Sysprep, que básicamente, limpiará el estado de activación del equipo e información de hardware como el SID entre otras. Es un paso primordial a la hora de hacer captura de imagen, pues de lo contrario, nos podríamos a enfrentar con problemas como identificadores únicos duplicados, entre otros.

Desde la Pantalla de Inicio, buscamos CMD, clic derecho y “Ejecutar como administrador” (Podemos abrirlo también con privilegios utilizando la combinación de teclas CTRL + SHIFT + ENTER). Navegamos hasta la carpeta de Sysprep ubicada en System32 con el comando: cd C:\Windows\System32\Sysprep y una vez allí, con TODAS las demás aplicaciones y procesos cerrados, ejecutamos:

Sysprep /OOBE /Generalize /Shutdown

*Nota: El comando anterior, al utilizar /OOBE asegurará el inicio desde la última fase de configuración en la instalación, /Generalize limpiará la información de hardware, y /Shutdown apagará completamente el equipo. El proceso no se debe interrumpir.

Capturando la imagen maestra

Cuando el equipo de referencia donde hicimos el resellado se apague, debemos pasarnos al equipo técnico donde se encuentra instalado el ADK para Windows 8 (Ver requerimientos); desde éste, crearemos un Windows PE donde copiaremos la herramienta de DISM para posteriormente cargarlo en el equipo de referencia y capturar la imagen maestra.

*Nota: Un Windows PE, es un mini sistema operativo, que se carga en memoria RAM, pero que se puede personalizar bastante para entornos de implementación o soporte técnico. Se reconoce como el Entorno de Preinstalación, y lo vemos cuando realizamos las primeras configuraciones siguiendo el asistente predeterminado de Windows.

Para poder crear el Windows PE, debemos hacer uso de la consola de Deployment and Imaging Tools Environment que se instala con el ADK. Desde la Pantalla de Inicio, buscamos por “Deployment” y en el resultado, hacemos clic derecho y “Ejecutar como administrador”.

Desde la Consola, debemos ejecutar el siguiente comando:

Copype <Arquitectura> <DirectorioPE>\WinPE

Donde <Arquitectura> dependerá de si el sistema que vamos a capturar es 32 ó 64 bits. Para 32 bits, sería “x86”, y para 64 bits sería “AMD64”. <DirectorioPE>, es una ubicación en nuestro equipo donde vamos a guardar los archivos del Windows PE, en este caso, y como recomencación, utilicé el directorio “C:\”. Por ejemplo, para este artículo, que dispuse de una instalación de 64 bits, el comando completo sería:

Copype AMD64 C:\WinPE

El siguiente paso, es copiar el ejecutable de DISM.exe ubicado en C:\Program Files\Windows Kits\8.0\Assessment and Deployment Kit\Deployment Tools\<Arquitectura>\DISM\ al directorio del WinPE, es decir a C:\WinPE\Media

*Nota 1: <Arquitectura> se refiere a x86 ó AMD64, y si el ADK está instalado en un equipo de 64 bits, el directorio variaría en C:\Program Files (x86).

*Nota 2: Es de vital importancia copiar este ejecutable, pues sin él no podremos hacer la captura de la imagen maestra.

Después de esto, desde el Deployment and Imaging Tools Environment ejecutamos:

MakeWinPEMedia /ISO <DirectorioPE>\WinPE <DirISO>\WinPE.iso

Donde <DirectorioPE> es la ubicación de la carpeta WinPE, y <DirISO> es donde deseamos guardar la imagen .ISO del Windows PE. Para este artículo, que mi WinPE está en C:\, y la imagen ISO estaría en el mismo directorio, el comando completo quedaría:

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

Debemos grabar en un CD o USB la imagen .ISO y posteriormente, arrancar el equipo de referencia donde hicimos el resellado con Sysprep con ésta. Veremos que nuestro Windows PE consta solo de un símbolo del sistema ubicado en la unidad X:\, que es el directorio virtual del mini sistema operativo.

Para capturar la imagen, ejecutamos:

Dism /Capture-Image /ImageFile:D:\install.wim /CaptureDir:D:\ /Name:”Windows 8 Enterprise” /Description:”Windows 8 Enterprise with custom Profile”

*Nota: El proceso puede tardar varios minutos. Es importante tener en cuenta además que el directorio D:\ ahí es el C:\ del sistema operativo resellado, por eso es el directorio que se captura, y ahí mismo se está guardando.

Después de que termine, debemos copiar el archivo install.wim que estará ubicado en la raíz C:\ a nuestro equipo técnico. Lo podemos hacer desde el Windows PE si tenemos algún directorio de red o disco extraible conectado, utilizando el comando xcopy; de otro modo, podemos simplemente reiniciar el sistema operativo, dejar que pase todo el proceso de OOBE, configurar un usuario nuevamente, y desde éste, copiar el archivo utilizando el Explorador de Windows.

*Nota: Si se hace desde el Windows PE, el archivo estará ubicado en D:\install.wim

Para efectos de este artículo, yo copié el archivo install.wim que capturé en el directorio C:\ de mi equipo técnico.

Lo que sigue es copiar todos los archivos de instalación de Windows 8 (Ver requerimientos) en un directorio local dentro de nuestro equipo técnico. Para este artículo, y como recomendación, lo copié en C:\8.

*Nota: Pueden copiarlo en un directorio de preferencia, pero de ser posible, que sea fácil de acceder.

Debemos copiar y remplazar el archivo install.wim de nuestro equipo de referencia, en el directorio Sources de los archivos de instalación, puesto que allí viene el original de Windows 8. Es decir, para este artículo, por ejemplo, copiar el archivo install.wim ubicado en C:\ a C:\8\Sources

Generando Archivo de Autorespuesta

Hasta aquí, hemos resellado la imagen, la capturamos y la copiamos junto con los demás archivos de instalación de Windows en el equipo técnico. La imagen ya contiene el perfil personalizado desde la cuenta de Administrador, sin embargo, no se copiará al perfil Predeterminado de Windows 8, hasta que se lo especifiquemos, y así lo lleve a cabo durante el proceso de despliegue.

Para poder lograr esto, necesitamos del Archivo de Autorespuesta, que nos ayudará a decirle a Windows qué debe hacer y configurar durante la instalación. Lo que haremos será crear el XML con la herramienta incluida en el ADK llamada System Image Manager y allí le indicaremos todos los parámetros.

Desde el equipo técnico, donde se encuentra instalado el ADK, ejecutamos el System Image Manager con privilegios administrativos (Clic derecho, Ejecutar como administrador).

En la Consola del System Image Manager, hacemos clic derecho sobre la parte inferior izquierda, donde dice Windows Image, y seleccionamos Select Windows Image:

Aquí tendremos que ir hasta el directorio de Sources dentro de los archivos de instalación donde remplazamos el install.wim por el que capturamos:

Al darle clic en el botón Abrir, nos indicará que no se puede abrir un Archivo de catálogo porque no existe, y nos preguntará si deseamos crearlo, debemos darle clic al botón de Sí, y esperar hasta que se genere y agrege el Catálogo.

*Nota: Esto puede tardar varios minutos, paciencia.

En el panel central, debajo de Archivo de Autorespuesta (Answer File), hacemos clic derecho en Crear o abrir un archivo de autorespuesta (Create or open an answer file) y seleccionamos Nuevo archivo de autorespuesta (New Answer File):

Cuando se haya creado el catálogo y el archivo de Autorespuesta, veremos debajo del panel de Windows Image, dirá el nombre interno de nuestro imagen (Para este caso, Windows 8 Enterprise); debemos expandir el panel de Components y posteriormente, hacemos clic derecho en el nodo de Microsoft-Windows-Shell-Setup y seleccionamos Add settings to Pass 4 Specialize

*Nota: Dependiendo de nuestra arquitectura, debemos agregar el nodo en amd64 o en x86. Para menores problemas, podemos agregar y configurar ambos. =)

En el Panel Central, debajo de Answer File, veremos que el componente se agregó, y tiene un color azul claro, indicando que no se ha configurado. Hacemos clic en él, y en el panel superior derecho, veremos una serie de parámetros que podemos configurar.

Buscamos el parámetro de CopyProfile y seleccionamos True. Esto nos permitirá decirle a Windows, que debe copiar todo el diseño y personalizaciones desde la cuenta de Administrador que configuramos al perfil Predeterminado de Windows durante el proceso de instalación. Aquí podremos configurar otros parámetros si es que deseamos automatizar la instalación, por ejemplo, nombre de equipo, zona horaria, etc.

El siguiente componente agregar, es nuevo específicamente para Windows 8, se trata de VisualEffects y está como subnodo de Microsoft-Windows-Shell-Setup. Debemos expandir en el panel de Componentes, hacer clic derecho sobre VisualEffects y seleccionar Add Setting to Pass 7 oobeSystem

De nuevo, nos situamos en el panel central donde se agregó el componente en Answer File, y en el panel derecho de Propiedades, seleccionamos SystemDefaultBackgroundColor y lo personalizamos escribiendo un número del 0 al 24, que representan todas las combinaciones de Colores disponibles para la Pantalla de Inicio. La siguiente imagen les puede dar una guía:

*Fuente de la imagen: Microsoft TechNet.

Para este artículo, ya que me gusta el negro con azul, personalicé el componente con el número 2:

Esto es todo lo que necesitamos personalizar, el resto de los componentes que se agregaron debajo de Microsoft-Windows-Shell-Setup, los debemos eliminar, para que no interfieran en la funcionalidad del XML. Basta con darles clic derecho y Eliminar.

*Nota: Si desean aprovechar, y realizar una instalación completamente desatendida de Windows 8, pueden ver este artículo que escribí hace un tiempo en la web de Fermu para saber qué otros componentes se deben agregar y personalizar: http://www.fermu.com/es/articulos/windows/articulos-y-tutoriales/823-instalación-desatendida-de-windows-8

Finalmente, hacemos clic en el menú de File, y seleccionamos Save Answer File As

Lo debemos guardar en la raíz de la carpeta que contiene los archivos de instalación de Windows 8, es decir, para este artículo, en C:\8. Debe llamarse AutoUnattend

¡Todo listo! El Archivo de Autorespuesta se encargará de hacer el trabajo pesado, nuestro siguiente y último paso, es crear la imagen .ISO a partir de los archivos de instalación, y probar el despliegue para ver que todo haya salido bien.

Si lo desean, pueden descargar el Archivo de Autorespuesta creado para este artículo, que contiene las personalizaciones indicadas, más algunas otras para automatizar el proceso de instalación desde aquí:

*Nota: Deben descomprimir para obtener el XML. Si desean, también pueden agregarle personalizaciones a su antojo.

Creando imagen de instalación

Desde el Equipo técnico, ejecutamos nuevamente el Deployment and Imaging Tools Environment con privilegios elevados (Clic derecho, Ejecutar como administrador) y ejecutamos:

oscdimg –b<Dir8>\boot\Etfsboot.com –u2 –h <Dir8> <DirISO>\Win8.iso

Donde <Dir8> es la ubicación de los archivos de instalación de Windows 8 y <DirISO> donde deseamos guardar la imagen creada.

Para este artículo, que tengo los archivos de instalación en C:\8 y que deseo crear la imagen ISO también en el directorio C:\, el comando sería:

oscdimg –bC:\8\boot\Etfsboot.com –u2 –h C:\8 C:\Win8.iso

*Nota: El proceso puede tardar algunos minutos, dependiendo del equipo donde se esté realizando y el peso de la imagen.

¡Instalando y probando!

Nuestro último y gran paso, será finalmente grabar la imagen .ISO y probarla en una máquina virtual o física para ver que todo funcione.

Durante el proceso de instalación, veremos que al momento de seleccionar la imagen, habrán detalles personalizados, como la descripción de la imagen:

Al finalizar, después de crear nuestro primer usuario (Si no se automatizó eso desde el Archivo de Autorespuesta), nos daremos cuenta de que tanto el Escritorio, como la Pantalla de Inicio, están configurados de forma predeterminada como lo especificamos mientras creamos la imagen –y obra- maestra:

Espero les sea de utilidad.

Checho

El pequeño Bug de Windows 8 que lo hacía creer un Área de Trabajo de Windows To Go, Procmon, DiskPart y su solución.

2013-01-15T22:57:00Z

Como se darán cuenta por el título, no todos los artículos se pueden referenciar a algo meramente bueno, sin embargo, en el problema que posteriormente expondré, es donde personalmente tuve la oportunidad de aprender más, y de una forma más entretenida acerca de la maravillosa funcionalidad de Windows To Go, incluida en Windows 8.

*Nota: El siguiente post contiene las tres partes ya conocidas por ustedes, es decir, El Problema, La causa y su solución. A pesar de esto, como se trata de un Bug en Windows 8, apenas esté disponible el parche que oficialmente corrige el problema, actualizaré este artículo.

El Problema

Recordemos que en concepto general, Windows To Go es una nueva tecnología o característica integrada en Windows 8, soportada desde su edición Enterprise y que básicamente, permite realizar una instalación completa de Windows 8 en un dispositivo compatible USB o disco externo, lo que brinda la posibilidad de llevar el escritorio personalizado a cualquier equipo portátil, tablet o de escritorio que soporte Windows 7. Por su flexibilidad y buen rendimiento, Windows To Go se convierte en una de las funcionalidades más productivas y eficientes.

El problema sin embargo, aparece cuando Windows 8 no es capaz de distinguir correctamente que no se encuentra instalado en un dispositivo USB, sino en el disco duro local, y por tanto, se comporta como un Área de Trabajo de Windows To Go.
En otras palabras, después de instalar Windows 8 en cualquier disco local, y conectar un dispositivo USB cualquiera que cause el problema (En “La causa” explicaré más esto), el sistema operativo empieza a “creer” que es un Windows To Go, por tanto, empieza a comportarse como uno, por lo que lo que consideraríamos como los errores, serían básicamente los efectos normales de estar trabajando con un Windows To Go.

Por ejemplo, el más común, y con el que normalmente se está detectando este problema, es cuando se intenta ingresar a la Tienda de Windows 8; muy seguramente verán un mensaje similar a la siguiente captura:

Inglés: “Windows Store isn’t available on Windows To Go workspaces.”
Español: “La Tienda Windows no está disponible en áreas de trabajo Windows To Go”

Otros pueden detectar el problema al intentar hacer Refresh o Reset:

Pero a pesar de todo, esto no es lo más complicado del problema, y en ocasiones, no es lo que primero se detecta. Cuando se conecta el o los dispositivos causantes, pasa que al tratar de remover el dispositivo USB, Windows se “congela” como normalmente lo haría en un ambiente de Windows To Go, y muestra un mensaje como el siguiente al volver a insertar el dispositivo o disco externo:

Inglés: “Only remove if after your PC has shut down completely. Otherwise, your Windows To Go workspace might crash and you could lose data.”
Español: “Quítela únicamente después de apagar completamente su PC. De lo contrario, el área de trabajo Windows To Go podría bloquearse y podrían perderse los datos.”

Con este último comportamiento es donde en verdad se complican las cosas, puesto que a menos que se prenda el equipo sin el dispositivo, siempre se tendrá que dejar conectado como si fuera un Windows To Go, de lo contrario, Windows actuará como lo haría en un Área de Trabajo de WTG y se bloqueará, para posteriormente apagarse.

La causa

Para la primera parte del problema, es decir, los dos primeros mensajes, sabía en el momento que existe una política propia que se activa en un Área de Trabajo de Windows To Go, con el fin de bloquear la Tienda y características como Refresh y Reset. La pregunta era saber por qué se estaba creando en ese momento, sabiendo que la instalación estaba en un disco físico interno.

En ese momento que pude interactuar por primera vez con el problema, acudí a Process Monitor de Sysinternals. Específicamente, la opción de Enable Boot Logging; que me permite rastrear toda la actividad que hay en Windows desde que se cargan los controladores y servicios, hasta cuando el escritorio está completamente funcional. Por supuesto, debía hacerlo cuando se conectara por primera vez un dispositivo causante del problema al encender el equipo.

El resultado fue notablemente bueno, puesto que encontré la creación de un valor llamado PortableOperatingSystem generado por System, y que tenía un valor de “1”, que referencia siempre como “Activo”:

Como ven en la captura, está justo después de que Windows enumera los dispositivos que tiene reconocidos.

Modificando este valor a cero (0), o bien borrándolo completamente, tanto la Tienda, como Refresh y Reset quedan completamente funcionales de nuevo; algo similar a como si dentro de un Windows To Go, habilitáramos la política para que se dejen usar. Sin embargo, esto no corrige el problema físico con los dispositivos USB, por lo que Windows siempre se seguirá bloqueando tal cual fuese un Área de Trabajo de WTG al remover la USB.

¿Por qué sucede esto? Pues bien, aquí estuvo lo más interesante a manera personal cuando estaba explorando el problema, puesto que pude obtener ayuda directa el del Equipo de Windows To Go para lo que trataré de explicarles a continuación…

Para cada problema, probablemente exista alguna herramienta útil, y en este caso, para comprender la causa y las consecuencias, había que recurrir a DiskPart. Herramienta para manipulación de Discos, incluida desde Windows XP, pero con funciones nuevas y evolucionadas en las nuevas versiones.

Con DiskPart, basta con ejecutar algunas líneas de comandos para llegar a detalles muy concretos tanto de los discos, como de las particiones en el sistema operativo. Para este caso, hay que identificar cuántos discos se encuentran conectados, incluyendo cualquier USB, así sea un celular. Para esto, basta con utilizar List disk, que mostrará todos los discos, con un número asociado, posteriormente, Select disk # (Donde # Es el número asociado al disco) para trabajar sobre uno solo, y finalmente, “Unique disk”, para obtener el Identificador único que contiene cada disco.

*Nota: Como con cada usuario, Windows necesita saber cuál disco está enumerando y funcionando, por eso le asigna un Identificador único (Disk ID).

Dicho y hecho esto, es donde para este caso, y los que probablemente tengan las personas que vean este comportamiento, se podrá ver la causa real del problema:

Los que experimenten este problema, podrán ver, como en la captura anterior, que tendrán dos o más identificadores de disco con los mismos dígitos, esto quiere decir, que para Windows, son exactamente el mismo disco.
Un identificador siempre lo tendrá el Disco que contiene el sistema operativo, es decir, Disco 0, y el otro, podrá ser cualquier dispositivo USB que se encuentre conectado.

Cuando un disco o dispositivo es inicializado por primera vez, Windows asigna un ID utilizando un algoritmo aleatorio, por lo que es poco probable que se repita, pero para este problema, que suele hacerlo, se genera una colisión de identificadores, haciendo que Windows mismo se confunda entre si es o no un Área de Trabajo de Windows To Go. Para entender un poco más, resumiré y explicaré algunos aspectos internos de cómo es que Windows To Go sabe cuándo aparecer:

Como Windows To Go, no es más que una variación del funcionamiento normal de Windows 8 por estar en un dispositivo extraible, se divide en dos comportamientos diferentes para inicializarse una vez se aplica una imagen de Windows en una USB. Lo primero, es que para ser portable, el sistema operativo tiene que saber que está instalado en un disco extraible, y no en uno local, para esto, y la forma de identificar esto, es sabiendo que el identificador único de disco que se encuentra en el USB Store del sistema operativo, es el mismo que el que se encuentra instalado. Si el identificador fuese diferente, Windows normalmente tomaría eso como un dispositivo de almacenamiento. El otro factor, está en el hecho de que una vez sepa que está instalado en un dispositivo USB, debe crear el valor de Registro de PortableOperatingSystem, para que Windows bloquee Refresh, Reset, y la Tienda, además de pararse cuando no detecte el dispositivo conectado y funcionando.

Al haber colisión, Windows entiende que el disco local y el extraible son los mismos, por lo que debe trabajar como si estuviese en un área de trabajo de Windows To Go. Es por esto, que al quitar el dispositivo causante, que tiene el mismo ID del disco local, se congela completamente el sistema, porque así debería funcionar si estuviese en lo cierto. El identificador normalmente tendrá para este problema el número de 00000001, aunque puede variar como en la captura.

La solución

Como el problema consta de dos partes, la solución misma también debe ser así. Lo primero que tienen que hacer, es identificar mediante DiskPart, cuál es el dispositivo que tiene el mismo ID del disco local, posteriormente, se le debe cambiar manualmente el identificador, para que deje de existir la colisión.

Para mi caso, que el identificador repetido lo tenía el Disco 1, el procedimiento sería así:

Desde un Símbolo del sistema con privilegios elevados (Clic derecho, Ejecutar como administrador), ejecutar:

Diskpart

List disk

Select disk # (Donde # representa el número del disco extraible)

Unique disk id=00000000

Por ejemplo, para mi caso sería:

Select disk 1

Unique disk id=00000001

*Nota: El identificador puede ser 8 dígitos inventados, lo importante es que sea diferente del disco local. Inclusive, pueden utilizar el comando de Clean, para que el ID se convierta en 00000000, y después darle formato al dispositivo desde el Administrador de discos para que le asigne un nuevo ID.

Una vez el disco se le haya cambiado el ID, se podrá remover del equipo sin que se congele el sistema operativo.

*Nota: Es probable que nunca encuentren colisión de discos, por lo que pueden pasar directamente al paso que describo después.

El siguiente paso, consiste en eliminar el valor PortableOperatingSystem, de tal forma que se pueda acceder a la Tienda y utilizar características como Refresh y Reset. Para esto, pueden descargar el fichero NoWTG desde aquí:

Descomprimir, ejecutarlo, y después de que importe, el archivo de registro se encargará de eliminar el valor.

*Nota: Lo que hace el fichero, es navegar hasta la clave: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control y quitar el valor de PortableOperatingSystem. Lo pueden hacer manualmente, en caso de que no les funcione el archivo anterior.

Después de reiniciar el sistema, Windows debe funcionar nuevamente sin ningún tipo de contratiempos sobre Windows To Go.

*Importante: El Equipo de Windows me notificó que están trabajando en el parche que corregirá esta colisión, así que tan pronto pueda estar enterado de él, actualizaré el post con el enlace de descarga, o información apropiada.

Espero sea de utilidad, si alguien continúa con el problema, o quiere añadir algo, ¡Comentarios bienvenidos!

Checho

Instalación desatendida de Windows To Go.

2013-01-10T16:10:00Z

[Off topic]: Antes que nada, les deseo a todos los que se toman su valioso tiempo para pasar por este blog, un próspero y feliz año nuevo. ¡Ojalá nos sigan visitando! =)

Dicho esto, quiero ir directamente al grano con mi primer post en este 2013. Como había dicho en artículos anteriores, la idea es cubrir varios escenarios en torno a la que yo considero como mejor característica de Windows 8, y es por supuesto, Windows To Go.
En este caso, partiendo de un Área de Trabajo ya configurada con algún método explicado en otros artículos, utilizaremos un Archivo de Auto-Respuesta para indicar la instalación desatendida de Windows To Go en la fase de OOBE, que es donde normalmente inicia después de reconocer cada dispositivo.

Aprovisionando Windows To Go

Lo primero es por supuesto, aprovisionar el dispositivo con Windows To Go. Esto se le reconoce como crear un Área de Trabajo. Como ya cada método tiene su post a parte, se los indicaré para que sigan el que más cómodo les parezca:

1. Instalación automática con el Asistente incluido en Windows 8.

2. Instalación manual utilizando DISM.

3. Instalación manual utilizando PowerShell.

Creando y aplicando Archivo de Auto-Respuesta

Recordemos que un Archivo de Autorespuesta, es un XML que guarda una serie de instrucciones para automatizar procesos de instalación o configuración de Windows. Cuando creamos una instalación desatendida, sea manual, o a través de alguna herramienta como WDS, MDT, o SCCM, siempre estaremos utilizando uno de estos XML.
Incluso mientras estamos configurando Windows To Go usando alguno de los dos métodos manuales que existen, utilizamos también un Archivo de Autorespuesta para aplicar a la instalación las políticas de SAN, que nos permiten ocultar los discos duros locales cada vez que se inicia un dispositivo WTG en alguna máquina.

Teniendo esto en cuenta, la configuración que se requiere para que la parte final de la instalación y personalización de Windows To Go sea desatendida, se podría añadir al XML donde se define las políticas de SAN, pero para esta ocasión, lo haremos a parte, puesto no siempre se planea automatizar la instalación, y con esto, se puede decidir cuándo sí y cuándo no.

*Nota: Iremos viendo más detalles acerca de los archivos de Autorespuesta en futuros artículos dedicados a implementación.

Para generar el XML, es necesario instalar el Assessment and Deployment Kit for Windows 8 (ADK), que contiene todas las herramientas necesarias para el mantenimiento y preparación de las imágenes de Windows 8 e inferiores.
La herramienta específica que se debe utilizar, es el Windows System Image Manager (SIM), que me permite crear y editar Archivos de Autorespuesta. Sin embargo, como esta configuración es realmente sencilla, se puede utilizar para ambas arquitecturas y es fácil de personalizar, les pondré a continuación lo que básicamente debería tener.

Abrimos un Bloc de Notas y pegamos lo que está entre la separación de líneas:

<?xml version="1.0" encoding="utf-8"?>
<unattend xmlns="urn:schemas-microsoft-com:unattend">
    <settings pass="oobeSystem">
        <component name="Microsoft-Windows-Shell-Setup" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
            <OOBE>
                <HideEULAPage>true</HideEULAPage>
                <NetworkLocation>Work</NetworkLocation>
                <ProtectYourPC>1</ProtectYourPC>
            </OOBE>
        </component>
        <component name="Microsoft-Windows-International-Core" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
            <InputLocale>en-us</InputLocale>
            <SystemLocale>en-us</SystemLocale>
            <UILanguage>en-us</UILanguage>
            <UserLocale>en-us</UserLocale>
        </component>
        <component name="Microsoft-Windows-WinRE-RecoveryAgent" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
          <UninstallWindowsRE>true</UninstallWindowsRE>
        </component>
        <component name="Microsoft-Windows-Shell-Setup" processorArchitecture="x86" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
            <OOBE>
                <HideEULAPage>true</HideEULAPage>
                <NetworkLocation>Work</NetworkLocation>
                <ProtectYourPC>1</ProtectYourPC>
            </OOBE>
        </component>
        <component name="Microsoft-Windows-International-Core" processorArchitecture="x86" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
            <InputLocale>en-us</InputLocale>
            <SystemLocale>en-us</SystemLocale>
            <UILanguage>en-us</UILanguage>
            <UserLocale>en-us</UserLocale>
        </component>
        <component name="Microsoft-Windows-WinRE-RecoveryAgent" processorArchitecture="x86" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
            <UninstallWindowsRE>true</UninstallWindowsRE>
        </component>
    </settings>
</unattend>

La diferencia en cada uno, puede estar en la personalización específica. Lo que está subrayado, es lo que pueden cambiar de acuerdo a su configuración, por ejemplo, si desean que el teclado esté predeterminádamente en Español, podrían cambiar los parámetros de lenguaje de en-us a es-es.

Una vez terminen, se debe guardar el archivo como Unattend.xml

*Nota: Pueden bajar el XML que utilicé para este post desde aquí:

Después de esto, se debe copiar el archivo XML en el dispositivo de Windows To Go, para que lo reconozca durante la fase de configuración final. Si realizamos alguno de los procedimientos manuales para configurar Windows To Go, probablemente tenga el dispositivo una letra de unidad asignada en el equipo técnico, para el caso automático usando el asistente, es probable que esto no sea así.

En cualquier caso, si el dispositivo no tiene letra de unidad, debemos seguir el siguiente procedimiento para verlo en el Explorador de Windows:

Desde el Explorador de Windows (O de Archivos), clic derecho en Equipo y seleccionamos Administrar, de esta forma se abrirá la Consola de Administración:

En la Consola de Administración, hacemos clic en Administrador de Discos para ver todas las particiones y discos disponibles en nuestro sistema.

*Nota: Podemos entrar también hasta aquí abriendo una ventana de Ejecutar (Windows + R) y digitando: diskmgmt.msc

En el Administrador de Discos, buscamos el que pertenece a nuestro Windows To Go, la que seguramente no tendrá letra de unidad asignada, y, de acuerdo al procedimiento que hayan utilizado, podría tener la partición oculta.

Clic derecho sobre la partición, y seleccionamos Cambiar letra y ruta de acceso de unidad.

Hacemos clic en el botón Agregar y Le asignamos cualquier letra que esté disponible, y hacemos clic en Aceptar para que Windows reconozca el dispositivo desde el Explorador de Archivos.

Por último, debemos copiar el archivo Unattend.xml al directorio Windows\System32\Sysprep dentro del dispositivo de Windows To Go:

El hecho de que esté en ese directorio, hará que Windows lo lea y haga lo que el XML especifique cuando inicie en cada equipo. Con la configuración que señalé en este artículo, debería pedir solo nombre de equipo, la configuración a la conexión a internet y el nombre local de usuario.

Debemos desconectar el dispositivo y probarlo en nuestro equipo de referencia.

Cada que queramos automatizar ese proceso de instalación con Windows To Go, solo tendremos que hacer uso del Archivo de Autorespuesta.

Espero sea de utilidad.

Checho

Habilitar BitLocker en un Área de Trabajo de Windows To Go manualmente.

2012-12-10T17:46:00Z

Hemos descrito ya 3 de los 4 métodos posibles, y soportados, que hay para aprovisionar un Área de Trabajo de Windows To Go. Instalación manual utilizando el Símbolo del Sistema y DISM, Instalación manual con PowerShell y finalmente, la forma más fácil haciendo uso del Asistente integrado en Windows 8.

Sin embargo, hay varias cosas que aún nos faltan por ver entorno a lo que sigue después de aprovisionar nuestros dispositivos con Windows To Go. Como mencioné en el artículo anterior, trataré de ir cubriendo algunos de los que pueda mostrar bajo mi conocimiento.
Para este post de hoy, y siguiendo un órden quizá lógico, mostraré la forma de cómo después de aprovisionar el dispositivo, podemos sacar provecho del mejorado BitLocker para cifrarlo completamente, así, a parte de dar movilidad, estaremos garantizando seguridad contra uso inadecuado.

BitLocker para Windows To Go, también se puede aprovisionar de diferentes métodos, la forma más fácil, es mediante el asistente para crear un Área de Trabajo de Windows To Go embebido en Windows 8, pero en este artículo, detallaremos la forma manual, utilizando PowerShell, de llegar al mismo resultado. Es importante tener en cuenta, que también se puede usar la herramienta de línea de comandos Manage-bde para cifrar el disco.

*Nota: Este post se enfocará al proceso con PowerShell, en un futuro artículo, trataré de agregar el método con la herramienta de comandos de BitLocker (Manage-bde).
Para ver un poco más de información sobre BitLocker, pueden ver este artículo.

¡Empecemos!

Lo primero que tenemos que hacer, es aprovisionar el dispositivo con Windows To Go, pueden utilizar alguno de los métodos ya descritos y referenciados en artículos anteriores para esto. Después de esto, insertamos el dispositivo nuevamente en el Equipo técnico que tenga en preferencia, Windows 8 instalado y como comportamiento natural, veremos que seguramente, no asignará partición, por lo que la USB no se verá en el Explorador de Windows. Lo que haremos será asignarle primero una letra de unidad a la partición del sistema operativo en el Área de Trabajo de Windows To Go, para luego proceder a cifrarla.

*Nota: Recordemos que no se le asigna letra, porque durante el aprovisionamiento, se le configuró el NODEFAULTDRIVELETTER con valor de Verdadero ($TRUE, ó True).

Desde la Pantalla de Inicio (Windows 8), buscamos PowerShell, clic derecho y Ejecutar como administrador.

Antes que nada, es necesario saber qué ID de Disco tiene asignado el dispositivo USB con Windows To Go, y la cantidad de particiones que contiene. Para ver esta información, desde la Consola de PowerShell, ejecutamos: Get-Partition

Veremos los discos que Windows tiene referenciados, y algunos detalles de las particiones:

Para este caso, el disco que me interesa, es el que tiene como número “1”, pues por el tamaño, representa la USB con Windows To Go. Lo siguiente es determinar la partición correspondiente al sistema operativo, para este caso, la que está con número “2”.

*Nota: En algunos casos, de acuerdo a como se haya aprovisionado Windows To Go, podría no tener más de una partición, que podría ser la del sistema de archivos de arranque, y de Windows. En ese caso, es la que se referenciaría.

Teniendo el dato exacto del disco y la partición que vamos a utilizar, debemos ejecutar desde PowerShell el siguiente comando:

Set-Partition <DiskNumber> <PartitionNumber> –NewDriveLetter “W”

Donde <DiskNumber> representa el número del disco que tiene Windows To Go (Para este caso, el 1), y <PartitionNumber> es el número de la partición donde está instalado Windows To Go (Para este caso, el 2).

En este orden de ideas, teniendo en cuenta los datos de la primera captura, en mi caso, el comando sería:

Set-Partition 1 2 –NewDriveLetter “W”

*Nota: Es importante tener presente que la letra “W” puede ser cualquiera, y de hecho, debe variar si es que ya está asignada a algún otro dispositivo que esté conectado.

Para verificar que fue satisfactorio, basta con que no haya dado errores la consola de PowerShell, y que desde el Explorador de Windows vean la partición.
Lo siguiente será crearle una Contraseña de Recuperación (Recovery Key) al dispositivo, que se usa normalmente cuando por alguna razón, Windows detecta alguna manipulación al disco y lo bloquea hasta que se le de el número completo.

Para esto, ejecutamos:

Add-BitLockerKeyProtector W: –RecoveryPasswordProtector

*Nota: El número es el que se referencia debajo del paso 1, deben copiarlo desde PowerShell, y pegarlo en un archivo de texto plano dentro de un directorio de confianza. Para copiar, solo hay que seleccionarlo y hacer clic derecho.

Aprovechando las características propias de PowerShell, debemos crear una variable donde se almacene una contraseña para habilitar el trabajo con BitLocker cada que se conecte en un equipo, y luego ciframos el disco completo.

Para crear y guardar la contraseña personalizada en una variable, ejecutamos:

$pwd = ConvertTo-SecureString -String <password> -AsplainText –Force

Donde <password> es la contraseña personalizada que le indiquemos, Por ejemplo, para este post, mi contraseña será “Passw0rd”, por lo que el comando completo quedaría:

$pwd = ConvertTo-SecureString –String Passw0rd –AsPlainText –Force

Por último, para cifrar el dispositivo utilizando esta contraseña, ejecutamos:

Enable-BitLocker W: -PasswordProtector $pwd –UsedSpaceOnly

Los dos cmd-lets anteriores, quedarían así:

*Nota: El parámetro de –UsedSpaceOnly, habilita la nueva característica de BitLocker y BitLocker To Go en Windows 8, que permite cifrar sólo el espacio del disco que está siendo utilizado, por tanto, el tiempo en que se tome para cifrar, será muchísimo más bajo que en versiones anteriores.
Conforme se vaya guardando más información en Windows To Go, o en general en el dispositivo, BitLocker se encargará de ir cifrando dinámicamente el espacio adicional. Por supuesto, se puede cifrar de una vez todo el disco con tan solo obviar el parámetro de –UsedSpaceOnly al final.

Después de esto, aparecerá la ventana de BitLocker tradicional que nos mostrará el progreso general del cifrado:

El tiempo puede ser más o menos, de acuerdo a la velocidad de lectura del dispositivo.

Una vez terminado el proceso, se debe simplemente quitar el dispositivo del Equipo donde se preparó, y arrancar desde Windows To Go en algún otro equipo. Lo normal sería que antes de iniciar el sistema operativo, nos muestre la pantalla azul de BitLocker pidiéndonos la contraseña para dejar arrancar Windows.

Espero sea de utilidad.

Checho

Aprovisionar un Área de trabajo de Windows To Go utilizando PowerShell.

2012-12-07T15:41:00Z

Hola a todos,

Ya han sido dos largos meses, y un poco más, desde que escribí mi último artículo en el Blog anunciando y agradecimiento el reconocimiento de MVP. Antes que nada, quiero pedir disculpas por esa larga ausencia, pero debido a la gran cantidad de trabajo que se vino con el lanzamiento, el estudio, y algo de descanso, decidí parar un tiempo para escribir.

Ya estoy de vuelta, y aunque por ahora no con la misma recurrencia, empezaré a compartir con ustedes poco a poco, varios artículos en torno a Windows 8 de algunas experiencias y conocimientos que he ido adquiriendo hasta ahora con la interacción del producto.

Dicho esto, quiero tratar de dedicar los próximos artículos a diferentes escenarios y necesidades a Windows To Go.
Ya vimos que básicamente, Windows To Go (WTG), se trata de instalar Windows 8 Enterprise en un dispositivo USB compatible, que puede ser Memoria de almacenamiento, o bien, un Disco extraible. Las dos formas más comunes para aprovisionar un Windows To Go, es haciéndolo manualmente, o bien, a través del asistente incluido en Windows 8 Enterprise.

Sin embargo, hay una forma adicional de aprovisionar un Área de trabajo de Windows To Go, que incluso, puede ser más utilizada que las dos anteriores. Windows To Go puede ser aprovisionado utilizando el sorprendente PowerShell incluido en Windows. En lo que sigue de este artículo, mostraré el paso a paso para realizar crear nuestro Windows To Go con los parámetros propios de PowerShell.

Requerimientos

- Un Equipo técnico en lo posible, con Windows 8 instalado, desde donde se pueda ejecutar PowerShell y aprovisionar el dispositivo.

- Un medio, o los archivos de instalación de Windows 8 Enterprise. Si aún no disponen de él, pueden descargar una versión de evaluación desde el sitio oficial:
http://technet.microsoft.com/es-ES/evalcenter/hh699156.aspx?ocid=wc-bl-sprblog

- Un dispositivo, o disco duro USB 3.0 y con suficiente espacio para instalar Windows 8.

*Nota: Técnicamente, es posible aprovisionar un Windows To Go en un dispositivo USB 2.0, pero la velocidad de escritura será considerablemente más lenta, por lo que la experiencia no sería muy satisfactoria.

Preparando el dispositivo con PowerShell

En el Equipo técnico con Windows 8, desde la Pantalla de Inicio, digitar PowerShell y sobre el resultado de Windows PowerShell, clic derecho y seleccionar “Ejecutar como administrador” en la parte inferior.

*Nota: También se puede ejecutar como administrador con la combinación de teclas: CTRL + SHIFT + ENTER.

Insertar el dispositivo en el que se vaya a preparar Windows To Go, y desde PowerShell, ejecutar: Get-Disk

Esto nos mostrará los discos reconocidos por Windows:

Debemos verificar muy bien cuál es el número que corresponde a nuestro disco USB. Para este artículo, por ejemplo, es el número “1”, que tiene como nombre Kingston DT Ultimate USB Device.

Ejecutamos: Clear-Disk <NúmeroDisco> –RemoveData –Confirm:$False

Donde <NúmeroDisco> es el que hace referencial al disco USB que se desea dar formato para aprovisionar Windows To Go. Para mi caso, que el disco tiene como número el “1”, el comando sería:

Clear-Disk 1 -RemoveData –Confirm:$False

*Nota: –RemoveData limpiará completamente el disco, y –Confirm:$False, se evitará tener que confirmar la operación para que PowerShell haga la tarea solo.

Ejecutamos: Initialize-Disk <NúmeroDisco> –PartitionStyle MBR

Donde <NúmeroDisco> es el que hace referencial al disco USB que se desea dar formato para aprovisionar Windows To Go. Para mi caso, que el disco tiene como número el “1”, el comando sería:

Initialize-Disk 1 –PartitionStyle MBR

Hasta aquí, solo hemos limpiado el disco completamente, y lo hemos inicializado como MBR, el siguiente paso es crear la partición del sistema, y asignarle un espacio para que pueda guardar los archivos de arranque necesarios, para esto, ejecutamos:

$SystemPartition= New-Partition <NúmeroDisco> –Size (350MB) – IsActive

Donde <NúmeroDisco> pertenece al número que Windows le asignó al dispositivo, y como información adicional, estamos creando una variable $SystemPartition para poder hacer referencia siempre a la partición del sistema desde PowerShell.

Para este artículo, que el disco de la USB que es el número “1”, el comando completo sería:

$SystemPartition= New-Partition 1 –Size (350MB) –IsActive

Una vez creada la partición del sistema, se debe darle un formato en el que Windows pueda escribir, e instalarse. Para esto, ejecutamos:

Format-Volume –NewFileSystemLabel “System” –FileSystem FAT32 –Partition $SystemPartition

*Nota: Con el comando anterior, les pedirá una confirmación para ejecutar la acción, si quieren obviar esto como cuando se limpió el disco en el segundo paso, se debe agregar el mismo parámetro al final: –Confirm:$False

Después de esto, debemos crear y particionar el volumen donde se instalará Windows. Ejecutamos:

$OSPartition= New-Partition <NúmeroDisco> –UseMaximumSize

Donde <NúmeroDisco> corresponde al número del disco que Windows asignó cuando se conectó el dispositivo. Para mi caso, y como lo he utilizando durante todo el artículo, ya que el número de mi USB es el “1”, el comando completo quedaría así:

$OSPartition= New-Partition 1 –UseMaximumSize

*Nota: $OSPartition, representa de nuevo una variable de PowerShell que referenciará a la partición donde se instalará Windows, y el parámetro de –UseMaximumSize, nos ayudará a tomar todo el espacio disponible en el disco USB.

Formatiamos la partición para asignarle el sistema de archivos NTFS y poder instalar Windows allí (Podría ser FAT32 también), para esto, ejecutamos:

Format-Volume –NewFileSystemLabel “Windows” –FileSystem NTFS –Partition $OSPartition –Confirm:$False

Ahora le asignamos letras a ambas particiones (La del Sistema y la de Windows) para poderlas referenciar más adelante. Para esto, ejecutamos:

Set-Partition –InputObject $SystemPartition –NewDriveLetter “S”

Después, ejecutamos:

Set-Partition –InputObject $OSPartition –NewDriveLetter “W”

*Importante: Las letras “S” y “W” corresponden a dos que no se hayan asignado ya en nuestro sistema operativo; si alguna de nuestras particiones o unidades locales ya tiene alguna de estas dos, debemos cambiarlas por otras que no estén siendo usadas en los comandos anteriores.

Para poder reproducir el comportamiento natural de Windows To Go al conectarse a un equipo con un sistema operativo en línea (Desde Windows), e impedir que se le asigne letra de unidad al dispositivo, debemos ejecutar el siguiente comando:

Set-Partition –InputObject $OSpartition –NoDefaultDriveLetter $TRUE

*Nota: Este último parámetro prevalece aún después de formatear el dispositivo y querer usarlo como almacenamiento masivo, así que en ese caso, se debe volver a ejecutar el mism, pero con el $FALSE para que Windows le asigne letras de unidad normalmente.

Aprovisionando Windows To Go

Hasta este punto, el dispositivo ya está listo para recibir una instalación de Windows 8, en los siguientes pasos, lo aprovisionaremos desde el medio de Windows 8, y le agregaremos otras configuraciones adicionales para que pueda arrancar bien, y no tenga comunicación con los discos físicos locales.

Para instalar Windows 8 en el dispositivo, ejecutamos:

Dism /Apply-Image /ImageFile<Directorio8>\install.wim /Index:1 /ApplyDir:W:\

Donde <Directorio8> es la unidad correspondiente al medio que tiene los archivos de instalación de Windows 8, y la referencia a la imagen (.WIM). Por ejemplo, para este caso, que la unidad que tiene los archivos de instalación es la “D”, el comando sería:

Dism /Apply-Image /ImageFile:D:\Sources\install.wim /Index:1 /ApplyDir:W:\

*Nota 1: La letra “W”, corresponde a la unidad que asignamos para Windows utilizando PowerShell en los pasos anteriores, si se le dio otra letra diferente a la que muestra este post, se debe cambiar también en el comando de Dism.

*Nota 2: El procedimiento puede tardar o no, dependiendo del peso de la imagen, y en general, de la velocidad de escritura y lectura del dispositivo USB.

Para que Windows pueda arrancar correctamente en equipos con UEFI, BIOS y diferentes arquitecturas, es necesario copiar los archivos de arranque a la partición que hayamos definido como del Sistem (“System”). Ejecutamos entonces:

W:\Windows\System32\bcdboot W:\Windows /f ALL /s S:

*Nota: Las letras “W” y “S” pueden variar, de acuerdo a la partición que hayan asignado en los pasos de preparación para el dispositivo.

Finalmente, debemos aplicar la política de SAN a nuestro Windows To Go, para que cada vez que se inicie en un nuevo equipo, no se vean los discos locales predeterminadamente, y que además, estén en estado de Desactivados.

Para esto, básicamente utilizaremos un Archivo de autorespuesta (XML) que se aplicará, y Windows leerá en cada inicio.

Deben descargar el archivo SANPS.zip desde aquí:

Descomprimir el archivo para que tenga la extensión .XML, es decir: SANPS.xml.

Luego, copiar el archivo físico a la partición que corresponde a la de Windows en la raíz del dispositivo USB, en este caso la “W” y ejecutar el siguiente comando:

Dism.exe /Image:W:\ /Apply-Unattend:W:\SANPS.xml

¡Todo listo! El siguiente gran paso, es finalmente desconectar de forma segura el dispositivo del equipo donde se aprovisionó, e iniciar desde él en cualquier otro equipo que cumpla con los requisitos mínimos para correr Windows 7 y Windows 8 (Son los mismos).

*Nota: Recordemos que desde Windows 8, se puede iniciar fácilmente desde el Windows To Go con solo buscar el asistente para cambiar las opciones de arranque de Windows To Go desde la Pantalla de Inicio:

En equipos que tengan instalado Windows 7 o inferiores, se debe entrar a la BIOS, o utilizar los parámetros de arranque (Normalmente con la tecla F12) y seleccionar el boot desde el dispositivo USB correspondiente a Windows To Go (Donde se instaló).

Al iniciar, podremos verificar que todas las configuraciones se hayan aplicado, como por ejemplo, que no aparezcan las unidades y particiones locales, y sólo se vea la de Windows To Go, con su respectiva etiqueta:

*Nota: El tamaño de Windows, está representado por el del dispositivo USB y no del disco local, en este caso, 32 GB (29.4 GB visibles).

En los próximos artículos, exploraremos un poco más en Windows To Go, aprendiendo a cifrarlo con BitLocker manualmente, y agregando personalizaciones más avanzadas a la imagen que se despliega.

Saludos,

Checho

[Off topic]: MVP Windows Expert–Consumer

2012-10-01T16:19:18Z

¡Hola a todos!

Este es mi post 470, y la única diferencia con todos los anteriores, es que me quiero permitir un pequeño “Off topic”, para compartir con todos los que se toman el trabajo, y su tiempo para visitar, opinar, o referenciar este blog.

El día de hoy, exactamente a las 9:35 A.M, he recibido una gran e inesperada noticia por parte de Microsoft, se me ha otorgado el reconocimiento de Microsoft Most Valuable Professional (MVP) en la categoría de ‘Windows Expert-Consumer’.

Debo decir que es una noticia que me llena profundamente de alegría, y mucha motivación, pero la idea general de este post, es darles un MIL GRACIAS a todo lo que encierra este Blog, sin el contenido que he puesto aquí, y más aún, sin el apoyo de todas las personas que me visitan, esto no hubiera sido posible. Además de esto, tengo que expandir el agradecimiento a una gran cantidad de personas tanto de Microsoft como de no Microsoft, como Fernando Muñoz, Rodolfo Alvarez, Edwin Garzón, Sandra Marín, Martha Calderón, Mauricio Afanador, Ricardo Polo, Yohanna Ramirez, entre muchos otros. Estas personas me han colaborado y me han abierto muchas puertas de aprendizaje y oportunidades.

Además de esto, a Fernando García Loera y Daniela Ambrocio un agradecimiento especial por el interés en pertenecer al programa de MVP.

No me queda más que decirles que esto representa una nueva meta, lo aprovecharé al máximo para crecer mucho en conocimiento y escribir aquí una gran cantidad de artículos, así que estén pendientes =)

Saludos,

Sergio Calderon (Checho)

El error “80246008” de Windows Update en Windows 7, el Servicio de BITS que no aparecía, KDiff3 y su solución.

2012-09-26T10:10:00Z

Windows Update, o Actualizaciones Automáticas en español, es quizá, una de las características más importantes de un sistema operativo Windows, ya que desde aquí, es donde podemos conectarnos cada segundo martes del mes a descargar los nuevos parches y fixes de seguridad que provee Microsoft desde sus servidores; aunque también suelen salir actualizaciones más importantes denominadas ‘Fuera de banda’, que solucionan algún agujero detectado y que puede ser vital para la integridad del sistema operativo.

Hasta aquí todo perfecto, puesto que si mantenemos las actualizaciones activas, y las unimos con algunas buenas prácticas, podemos estar bien protegidos, el problema está cuando Windows Update no funciona correctamente.
Como con cada producto de Microsoft, hay diferentes códigos de error que suelen decir poco o nada, aunque definitivamente, dan una referencia en la gran mayoría de veces precisa hacia dónde puede estar el problema.

Windows Update tiene múltiples código de error que pueden surgir si hay inconvenientes buscando, o instalando actualizaciones, algunos muy bien documentados en las KB de Microsoft, algunos como el de este post, aunque populares e identificados con posibles causas, no lo están.

El problema

En los Foros de Microsoft TechNet, se ha vuelto muy popular un error en Windows Update en Windows 7 (Aunque no necesariamente ligado a esta versión), básicamente, se buscan y listan bien las actualizaciones, pero al momento de darle ‘Instalar ahora’, Windows Update presenta un error muy similar a la siguiente captura de pantalla:

El código de error que referencia es: “80246008”, y su mensaje suele ser: “Windows Update encontró un error desconocido”.

Si se le da al enlace de ‘Obtener ayuda con este error”, no es mucho lo que se pueda ver tampoco, sólo un código que referencia al error como: "WindowsUpdate_80246008" "WindowsUpdate_dt000" y algunos problemas relacionados, nada más.

No importa qué actualización se seleccione, siempre dará el mismo mensaje de error, y no se podrá instalar nada.

La causa

Si se busca por el código de error “80246008” en los sitios web de Microsoft, podremos encontrar una documentación en el sitio de Windows, y una KB que hace referencia al problema.

Ambas documentaciones hacen referencia a un Servicio llamado ‘Servicio de Trasnferencia Inteligente en Segundo Plano’ (Background Intelligent Transfer Service (BITS) debe estar presente y funcionando. En términos básicos, este servicio tiene como función de trasnferir en segundo plano archivos de descarga o carga entre el Cliente y el Servidor, además de proveer información sobre el progreso. En otras palabras, vemos este servicio cuando ponemos a instalar las actualizaciones y nos muestra tanto la información de la descarga que está haciendo, como el progreso general con la barra de color verde.

En este orden de ideas, es necesario tener el servicio corriendo, el problema está, en que con este código de error, lo más probable es que al buscar el Servicio, sea en inglés o en español (De acuerdo al idioma del sistema operativo), no lo encontraremos:

En resumen, Windows Update requiere tener el Servicio registrado y corriendo para poder hacer la trasnferencia, pero para este caso, el Servicio ni siquiera se encuentra visible en la Consola, por ende, tampoco está ejecutándose. Ese error suele presentar dos problemas, aunque bajo una misma raíz, es decir, el Servicio de Transferencia Inteligente en Segundo Plano (BITS).

La solución

La Consola de Servicios, presenta un lugar central donde se pueden visualizar todos los Servicios, su estado, sus dependencias, usuarios, y además, se pueden modificar para que inicie, se detenga, o se reinicie, entre otras cosas.

Sin embargo, cada Servicio que se visualiza allí, es porque está funcionando y registrado correctamente en una clave central del Registro para todo el equipo ubicada en:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services

Aquí aparecen con su nombre real, que se puede ver en las Propiedades del Servicio en la Consola; para este caso, el nombre es: BITS.

Los que tengan este error sin embargo, notarán que la clave del Servicio sí aparece en el Registro de Windows:

¿Por qué si está la clave, no se registra en la Consola de Servicios? Pues bien, la respuesta es, que el hecho de que la clave y algunos valores existan, no quiere decir que esté bien, es decir, pueden haber valores y claves faltantes, o corruptos que impidan el funcionamiento del servicio, incluso, puede estar tratando de utilizar su DLL correspondiente que esté dañada también.

La forma más eficiente para detectar daños en las claves de Registro, es comparar con un fichero de Registro que se extraiga de un equipo funcional (Que el Serivicio aparezca y esté funcionando). Hasta el SDK para Windows 7, la herramienta por excelencia para hacer esta comparación, se llamaba WinDiff, pero, ya se descontinuó en la última versión del SDK que funciona para Windows 8 y versiones anteriores, por lo tanto, para este problema, recurrí a una herramienta fantástica llamada: KDiff3, disponible gratuitamente aquí: http://sourceforge.net/projects/kdiff3/

En este caso entonces, exporté la clave de BITS tanto del equipo que no funcionaba, como de un equipo que estaba en perfectas condiciones, después, desde KDiff3, se deben abrrir ambos archivos y él hará el trabajo de comparar y mostrar diferencias, esto fue lo que encontré:

Como lo muestra la captura, comparé el .REG bueno (El de la izquierda), contra el del equipo no funcional (Derecha), y la diferencia con respecto a valores y claves faltantes era inmensa.

Como hay dos claves que no se pueden eliminar en este Servicio (A menos que se cambien los permisos), el primer paso fue simplemente importar el fichero de Registro correcto al equipo no funcional, reiniciar para que Windows registrara nuevamente el servicio, y este fue el resultado:

¡Problema solucionado! =)

Si tienen este mismo problema, pueden descargar el fichero de registro BITS desde aquí:

Este es el enlace directo: http://sdrv.ms/TrheG0

Deben descomprimirlo, importarlo, asegurarse que se completó satisfactoriamente, reiniciar el equipo, y poner a descargar e instalar actualizaciones nuevamente.

En caso de que tengan el mismo código de error, y no se les solucione con esto, les agradezco comenten aquí y tratamos de investigar el problema.

Saludos,

Checho

Exportar e Importar asociación de aplicaciones en Windows 8

2012-09-14T21:26:00Z

Hola a todos,

Ya hemos tocado aquí varias características notables del nuevo Windows 8, algunas enfocadas más a usuario final, y otras a Profesionales de tecnología. Sin embargo, a partir de ahora, empezaremos a ver algunas cosas interesantes con respecto a la implementación, solución de problemas, y cuando se pueda, un poco de Internals en todas las categorías.
El post de hoy está dedicado a un tema que, si bien no era de notarse mucho en versiones anteriores como Windows 7, estaba causando problemas bastante frecuentes, y se ha mejorado de una manera muy positiva en Windows 8.

Windows internamente, cada que instalamos una nueva aplicación, necesita saber qué tipo de extensiones de los archivos que podemos traer, o crear, se deben asociar con las que la aplicación registró, a esto se le llama: Asociación de aplicaciones.

*Nota: Existen varios tipos de asociaciones en Windows, como las de Los Directorios y Carpetas.

Ya hace un poco más de un año, publiqué aquí uno de los problemas más comunes que tenía Windows 7 con respecto a las asociaciones, y es que fácilmente referenciaba nuestros accesos directos con alguna otra aplicación; Windows 8 tomó nota de esto, y ahora, a pesar de que las instalaciones siguen asociando las diferentes extensiones de las aplicaciones, ya no se abre de forma predeterminada, es decir, sin importar qué software instalemos, siempre seremos nosotros los de la última decisión de cuál debe ser el que se quede con la extensión del archivo o aplicación, de hecho, al finalizar las nuevas instalaciones, Windows 8 nos notificará con un mensaje similar a este:

Esto es sin dunda la solución al problema en Windows 7, pero los usuarios se pueden cansar de estar asociando por cada aplicación, ya que esto era un trabajo que no se debía hacer en versiones anteriores; sin embargo, Windows 8 afortunadamente tiene una serie de asociaciones predeterminadas, por lo que al instalar, ya sabe con qué aplicación debe abrir diferentes tipos de extensiones como el .PDF o el .ZIP. En escenarios de implementación, o como en este caso, para nosotros como usuarios finales, podremos Exportar esta lista predeterminada de una instalación, y después Importarlas en otro equipo, para que cada nuevo usuario, ya sepa cómo debe abrir sus extensiones, incluso antes de que la determinada aplicación se le instale.

*Importante: Lo que haremos, es mucho más eficas cuando se hace Ingeniería de Imagen, es decir, cuando se trabaja sobre una imagen sin conexión (Offline), ya que nos aseguramos que se mantengan estos cambios para todos los usuarios, inclusive desde la instalación de Windows. En este post, trabajaremos sobre una imagen con conexión (Online).

¿Qué necesitamos?

- Un equipo donde instalemos todas las aplicaciones que normalmente asociamos a nuestras extensiones, donde configuraremos y exportaremos el archivo .XML que tendrá todas las asociaciones.

- Un equipo donde podamos Importar el archivo .XML con todas las asociaciones, para luego instalarle las aplicaciones y probar el funcionamiento en los nuevos usuarios.

*Nota: El proceso se puede hacer en un solo equipo, donde desde un usuario se configuran y se exporta el XML, y se importa en otro usuario diferente.

Estableciendo asociación de aplicaciones

Lo primero que debemos hacer, desde uno de los equipos, es instalar todas las aplicaciones que referenciar, y posteriormente asociarlas a las diferentes extensiones; como Windows 8 ya no lo hace de forma predeterminada, es necesario utilizar la ventana de Asociación de archivos o protocolos.

Para este artículo, me enfocaré con una sola extensión que será: .ZIP, y la aplicación que en mi caso quiero remplazar por el Explorador de Windows, será WinRAR.
Abrimos la Pantalla de Inicio y buscamos por Programas predeterminados, lo ejecutamos, y posteriormente hacemos clic en Asociar un tipo de archivo o protocolo con un determinado programa, buscamos la extensión (En este caso .ZIP) y finalmente, clic en el botón Cambiar programa para seleccionar el programa instalado:

*Nota: Debemos repetir este proceso para cada extensión, y asociar la aplicación que deseamos sea predeterminada en el próximo equipo.

Exportando asociación de archivos y aplicaciones

Una vez hayamos terminado los pasos anteriores para todas las aplicaciones, debemos proceder a exportar las respectivas asociaciones, para esto, utilizaremos la herramienta de DISM (Deployment Image Servicing and Management), que como lo hemos comentado en gran cantidad de artículos, funciona básicamente para hacer mantenimiento a nuestras imágenes offline y online, aunque ahora introdujo para Windows 8 nuevas funcionalidades como esta, y otras más potentes que remplazarán a ImageX.

Desde la Pantalla de Inicio, abrimos un Símbolo del sistema con privilegios elevados (Clic derecho, Ejecutar como administrador), y ejecutamos:

Dism /Online /Export-DefaultAppAssociations:<RutaXML>\MiNombre.xml

Donde <RutaXML> es el directorio en el que quiero guardar el archivo XML con toda la configuración respectiva de asociaciones, y “MiNombre.xml” es como deseo llamar al archivo, por su puesto con la extensión requerida por el comando.

Para este artículo, lo guardaré en la unidad “C:”, y lo llamaré: MyApps.xml, por lo que todo el comando sería:

Dism /Online /Export-DefaultAppAssociations:C:\MyApps.xml

Si abrimos el archivo con un editor de texto como el Bloc de Notas, podremos ver que al final aparecerá la asociación referenciando a las aplicaciones que hayamos indicado, por ejemplo, para el .ZIP:

Este archivo lo tenemos que pasar ahora al equipo donde predeterminaremos las diferentes extensiones para las mismas aplicaciones.

Importando asociación de archivos y aplicaciones

En el segundo equipo, copiamos el XML que creamos anteriormente en una ubicación sencilla de acceder (Por ejemplo, en una unidad), abrimos nuevamente el Símbolo del sistema con privilegios elevados y ejecutamos:

Dism /Online /Import-DefaultAppAssociations:<RutaXML>:\MiNombre.xml

Para este artículo, que ubiqué el archivo en la unidad C:\ nuevamente, y tiene el nombre de MyApps.xml, el comando sería:

Dism /Online /Import-DefaultAppAssociations:C:\MyApps.xml

Para verificar que efectivamente la asociación se cambió, podemos utilizar el comando:

Dism /Online /Get-DefaultAppAssociations

Todo está listo, bastará con instalar la aplicación (Como en este caso WinRAR) si es que no se ha hecho, crear el o los nuevos usuarios y veremos que Windows reconocerá inmediatamente que debe abrir los archivos especificados con las aplicaciones que se hayan establecido de forma predeterminada.

Opcional: ¿Por qué el usuario en el que se importan no reconoce las asocicaciones?

Si esto lo hicimos como en este post desde unas imágenes Online, es decir, desde un sistema operativo ya andando, nuestro primer usuario sólo servirá para predeterminar, pero no reconocerá necesariamente esta configuración a menos que la hagamos manualmente, y la razón, es que este archivo importado lo único que le dice a Windows es que cada que se inicie un nuevo usuario, se le asocie las extensiones con las aplicaciones, y aunque aplica para todos los usuarios, la configuración se hace en HKEY_CURRENT_USER, lo que indica que la configuración se va aplicando usuario por usuario.

Si utilizamos Process Monitor de Sysinternals por ejemplo, podremos ver este comportamiento claramente con la opción de Enable Boot Logging, bastará con reiniciar desde el usuario que se importó después de habilitar la característica de Process Monitor, y seguir a la extensión para saber qué claves crea, si fuéramos a enfocarnos en la de este post, es decir, .ZIP, veríamos entre otras cosas, esto:

La clave que está seleccionada, junto con la operación de RegSetValue que normalmente está más abajo, son las dos más importantes, la primera crea el valor de UserChoice en la clave: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.zip

La segunda operación, que en realidad se repetirá dos veces (NO se ve en la captura), es establecer dos valores, Hash y Progid, que se verán reflejados en el Registro de Windows, por supuesto:

Ambos cumplen la función de identificar las aplicaciones con las que nosotros decidimos que se iban a abrir las distintas extensiones, esta clave se crea también cuando establecemos la asociación en el primer paso de este artículo, y mientras UserChoice esté con vida, no se cambiará la asociación, a menos que cada uno lo haga manualmente.

Si UserChoice no existiera, como predeterminadamente sucede, Windows leería los valores que identifiquen a la, o a las aplicaciones con las que se puede abrir la extensión dentro de la clave de OpenWithProgid. Para el caso de las que ya Windows reconoce predeterminadamente, como .ZIP o .PDF, suele haber recién instalado un solo valor, específicamente: CompressedFolder, así que Windows busca dentro de HKEY_CLASSES_ROOT la clave que corresponda a ese valor y utiliza la aplicación.

Cuando se instala otra aplicación como WinRAR sin embargo, pasan a ser dos valores que trabajan como Variables de entorno, la primera para el Explorador, y la segunda para WinRAR:

*Nota: Internamente, la variable de WinRAR es: WinRAR.ZIP.

Como hay dos, ya Windows dejará que el usuario sea el que elija, una vez lo haga, es donde se crea la carpeta UserChoice y sus respectivos valores.

*Nota: Windows es supremamente inteligente con respecto a sus asociaciones, si los valores no se encuentran en su clave de HKCU, los buscará en HKEY_CLASSES_ROOT\.zip por ejemplo y los copiará nuevamente a HKCU; si no está en HKCR, utilizará los que encuentre dentro de HKCU, hasta que se quede sin los dos, y no pueda referenciar ninguna aplicación (Esto pasaría si eliminamos ambas claves):

Hay muchísimo más que contar, tanto en el escenario de implementación offline, como de su espléndido comportamiento a nivel del Registro de Windows, cosas que trataremos de ir viendo conforme vaya incrementando mis conocimientos, y escriba artículos específicos de implementación o de Internals.

Saludos,

Checho

Windows To Go (Parte 2/2): Configuración automática utilizando el Workspace Creator Tool.

2012-08-26T12:12:00Z

Hace apenas unos días, iniciamos esta serie de dos artículos acerca de Windows To Go, la primera parte, nos adentramos un poco sobre la introducción general de la característica, y aprendimos a realizar la Configuración manual del dispositivo; hoy veremos el paso a paso específico para preparar el Espacio de trabajo utilizando la herramienta embebida en Windows 8 Enterprise llamada: “Create a Windows To Go workspace” (pwcreator.exe).

Los requerimientos son básicamente los mismos especificados en el artículo anterior, es decir:

- Windows 8 Enterprise.

- Memoria USB 3.0 compatible con Windows To Go, o un dispositivo USB (Como un disco externo por ejemplo) de preferencia, también 3.0.

- Equipo técnico con Windows 8 Enterprise instalado donde se prepare el Área de trabajo.

- Equipo de referencia donde se pueda probar Windows To Go (Puede ser el mismo equipo técnico).

*Nota: Con el asistente, en caso de querer utilizar una USB, tiene que cumplir con los requerimientos de Windows To Go, de lo contrario, no permitirá ni siquiera iniciar y habría que probarla con la configuración manual.

Configurando Windows To Go con el Worskpace creator

Desde el Equipo técnico con Windows 8 Enterprise, ejecutamos el Workspace, para esto, abrimos la Pantalla de Inicio (Tecla Windows), y digitamos: pwcreator.exe y presionamos la tecla ENTER.

Nos saldrá la ventana de Create a Windows To Go Workspace, abajo tendremos referenciados todos los dispositivos USB que tengamos conectados al equipo, por supuesto, los que no funcionen, el asistente nos indicará con un mensaje inferior y no dejará avanzar:

Debemos seleccionar el disco extraible USB, o la memoria compatible con Windows To Go, y hacer clic en el botón Siguiente (Next).

En la página de Seleccionar una imagen de Windows 8 (Choose a Windows 8 image), es donde referenciaremos la carpeta que contenga los archivos de instalación de Windows 8, o bien, la unidad de DVD, sea física o virtual.
Para hacer esto, hacemos clic en el botón Agregar ubicación de búsqueda (Add search location), indicamos la locación, y después de un breve análisis, el asistente nos debe mostrar qué edición está disponible a instalar y en qué directorio se encuentra. Tengamos presente que nosotros podremos agregar varias ubicaciones de búsqueda:

Al finalizar, seleccionamos el nombre dependiendo a la ubicación que tenga la imagen que deseamos desplegar, y hacemos clic en el botón Siguiente (Next) para continuar.

*Nota: El asistente buscará entre todos las carpetas y subcarpetas de la ubicación especificada por el archivo de imagen install.wim (Mismo que se utiliza en el proceso manual y que contiene toda la instalación de Windows).

En la página de (Establecer una contraseña de BitLocker (Opcional)) “Set a BitLocker password (Optional)”, podremos habilitar nuestro dispositivo para que la unidad del sistema se encuentre totalmente cifrada al momento de la implementación, esto por supuesto, nos dejará agregar una protección impenetrable y adicional al dispositivo. Pueden ver más acerca de BitLocker en este artículo.

Es decisión de cada uno si habilita BitLocker o no, después de esto, hacemos clic en Siguiente (Next) para continuar.

En la página de Listos para crear tu área de trabajo de Windows To Go (Ready to Create your Windows To Go Workspace), nos aseguramos de tener todos los archivos importantes del dispositivo guardados puesto que se borrarán, y hacemos clic en el botón Crear (Create) para iniciar el proceso de creación del Área de trabajo de Windows To Go.

Iniciará entonces el proceso de creación de Windows To Go, donde primero prepará el dispositivo, luego aplicará la imagen, y por último establecerá la serie de políticas para esconder las unidades locales y el mismo dispositivo, además de habilitar BitLocker (Si así se dispuso en el asistente previo):

*Nota: Esto puede tardar más o menos minutos, dependiendo del tipo de dispositivo.

Finalmente, el asistente nos mostrará una última ventana donde pedirá si establecemos el inicio de una vez en el equipo desde Windows To Go, o bien, terminar sin establecerlo.

*Nota: Este modo de inicio se puede establecer sólo desde un Windows 8 Enterprise, en equipos con sistemas anteriores, hay que modificar manualmente los parámetros de arranque desde el firmware para referenciar la USB.

Si todo sale bien, lo primero que debemos ver al iniciar en un equipo, será la petición de BitLocker (Si se estableció):

Como verán, Windows To Go cargará con todas las configuraciones recomendadas que debería tener el Área de trabajo, quedará solo disfrutar =)

Espero sea de utilidad.

Saludos,

Checho

Windows To Go (Parte I/2): Configuración manual

2012-08-22T14:05:00Z

Esta seríe de dos artículos sobre Windows To Go, cubren quizá, el tema que más esperaba abordar desde la salida de Windows 8 en su versión Developer Preview, y es que esta es en mi opinión, la característica más fascinante que se integró en este nuevo sistema operativo.

Aunque el resultado es en esencia el mismo, Windows To Go tiene dos procesos básicos y diferentes para configurarse, el primero es el auto aprovisionamiento con una herramienta embebida en Windows 8 Enterprise llamada Windows To Go Worskpace Creator Tool (pwcreator.exe) y a través de un procedimiento bastante familiar, utilizando técnicas y herramientas de implementación. Hoy nos concentraremos en lo segundo, y es cómo configurar Windows To Go manualmente, pero teniendo en cuenta algunos conceptos e información importante.

*Nota 1: Aunque no están ligadas más que en la característica, la Parte 2 de Windows To Go, es donde exploraremos el procedimiento de configuración utilizando la herramienta.

*Nota 2: En realidad, habrán otras foras de aprovisionar un espacio de trabajo con Windows To Go, por ejemplo, desde System Center Configuration Manager 2012 SP1, pero no los cubriré en estos dos artículos.

¿Qué es Windows To Go?

Windows To Go, nos brinda la posibilidad de generar un espacio completo de trabajo de Windows 8 instalado en un dispositivo USB compatible, esto quiere decir, que podremos arrancar con nuestra USB desde cualquier equipo que cumpla los requerimientos necesarios (Procesadores con tecnología x86 ó x64), y tendremos Windows 8 completamente funcional, con la gran cantidad de características empresariales, tal cual otra estación de trabajo, por ejemplo DirectAccess, BranchCache, funciones de seguridad, etc. Cada que Windows To Go inicie en un nuevo equipo, reconocerá todos los controladores y dispositivos y los instalará, pero mantendrá un solo perfil y nombre de equipo, además de esto, después de la segunda vez que se inicie en una misma máquina, Windows To Go estará en la capacidad de reconocerlo, y arrancar mucho más rápido que recién configurado.

Windows To Go se puede cifrar utilizando BitLocker, por lo que cada que se inicie en un equipo, podremos tener un mecanimos de autenticación adicional, por otra parte, Windows To Go tiene una serie de políticas de grupo específicas para la característica, que me agregan o deshabilitan diferentes características.
Cuando se configura utilizando la herramienta de autoaprovisionamiento, Windows To Go no mostrará las particiones del equipo host en el que se arrancó, sólo la del sistema, que será la del propio dispositivo en cuestión, aunque este comportamiento se puede modificar.

Windows To Go, y la herramienta de Windows To Go Workspace Creator, están soportados sólo en la edición de Windows 8 Enterprise, que se adquiere a través de Software Assurance, aunque técnicamente, cualquier edición, exceptuando Windows RT, se puede volver un espacio de trabajo dentro de un dispositivo USB.

Pueden encontrar más información oficial en el sitio web de Microsoft TechNet:
http://technet.microsoft.com/en-us/library/hh831833

Configurando Windows To Go manualmente

En este post, como lo mencioné antes, detallaré el paso a paso para implementar Windows To Go en un dispositivo USB manualmente, aunque se deben utilizar varios comandos, no es algo complejo, pero no deja de tener detalles importantes que iré mencionando.

Los requerimientos…

- Windows 8 Enterprise en cualquier arquitectura (32 ó 64 bits). Actualmente, se puede descargar el RTM desde la página de Suscriptores MSDN y TechNet, o bien desde la de Licenciamiento por Volumen; si no tienen acceso a alguna de las anteriores, aún pueden probar Windows 8 Enterprise descargando la versión de evaluación por 90 días desde aquí: http://technet.microsoft.com/es-ES/evalcenter/hh699156.aspx?ocid=wc-bl-sprblog

*Nota: Técnicamente, a excepción de Windows RT, cualquier edición como Windows 8 ó Windows 8 Pro se puede volver un espacio de trabajo de Windows To Go, pero sólo utilizando Windows 8 Enterprise estará soportado por Microsoft.

- Dispositivo USB 3.0 certificado para Windows To Go con 32 GB de espacio. Actualmente, hay dos fabricantes que tienen esta certificación: Kingston DataTraveler Ultimate y Super Talent Express RC8.

*Nota: Técnicamente, se puede implementar Windows To Go en un dispositivo USB 2.0, incluso en alguno que tenga sólo 8GB, de hecho, en este post, utilizaré uno de estas características; el inconveniente está en que la velocidad de instalación y del primer arranque, pueden ser demasiado bajas y pobres, en algunos dispositivos incluso se cae el inicio de Windows To Go por primera vez por su lentitud en escritura y lectura. Un dispositivo USB 3.0 garantiza una experiencia muy similar a la que se vive en un host actualmente.

- Un equipo host que tenga puerto USB 2.0 o 3.0, en lo posible, que tenga instalado Windows Assessment and Deployment Kit (ADK) para el aprovisionamiento del Espacio de Trabajo de Windows To Go.

- El equipo debe estar certificado para correr Windows 7 o Windows 8.

*Nota: En realidad, Windows To Go es independiente del sistema operativo que esté instalado en el equipo host, pero como es un sistema completo, requiere también disponer de unas capacidades mínimas en hardware, por esto se plantea el anterior requerimiento. Entonces, si se tiene un gran equipo desperdiciado con Windows XP, se puede libremente arrancar Windows To Go.

- Un equipo donde se pueda iniciar desde Windows To Go. Puede ser incluso el mismo equipo host donde se configura.

Si desean ver más consideraciones generales sobre el Hardware, pueden ver el artículo oficial de TechNet: http://technet.microsoft.com/en-us/library/f82d1a0a-d8f7-4e8a-86a6-704166969a42#wtg_hardware

¡Manos a la obra!

Lo primero que haremos, para ganar agilidad en el proceso sobre todo, será copiar todos los archivos de instalación de Windows 8 a una carpeta local del sistema, ojalá que sea fácil de acceder, por ejemplo, para este artículo, yo copié los archivos a una carpeta llamada “8” en “C:”, es decir: C:\8.

*Nota 1: En todo el post me estaré referenciando a esta carpeta, cada uno debe remplazarla en sus comandos por la ubicación que le corresponda.

*Nota: La copia la pueden hacer manual desde el Explorador, o bien utilizando la herramienta de xcopy.

Conectamos el dispositivo USB en nuestro Equipo host, a continuación, ejecutamos una ventana del Símbolo del Sistema con privilegios elevados desde la Pantalla de Inicio, para esto, basta con buscar CMD, seleccionar Símbolo del Sistema, y presionar CTRL + SHIFT+ENTER para elevar los privilegios, o bien, haciendo clic derecho y seleccionando “Ejecutar como administrador” en la parte inferior.

La primer parte del proceso, consiste en utilizar la herramienta Diskpart embebida en Windows, para preparar el dispositivo, así podrá tener su propia partición activa para instalar el sistema operativo, junto con algunos otros parámetros. Ejecutamos las siguientes instrucciones en orden secuencial (Una tras otra):

- Diskpart

- List disk
Veremos una lista de todos los discos conectados a nuestro equipo, debemos fijarnos en el número que Windows le asignó a nuestro dispositivo USB y referenciarlo en el próximo comando.

- Select disk #
Donde # es el número que le corresponde al disco USB, para este caso por ejemplo, la USB era el “2”, así que mi comando sería: Select disk 2

- Clean

- Create Partition Primary

- Active

- Format fs=ntfs quick

- Assign

- Attributes volume set NoDefaultDriveLetter

- Exit

El proceso en la ventana del Símbolo del sistema, debe verse similar a la siguiente captura:

*Nota: Si alguna vez han preparado un dispositivo USB para instalar Windows Vista/7/8 desde ahí, verán que el proceso es muy similar, exceptuando el comando de Attributes volume set NoDefaultDriveLetter, éste se utiliza para que una vez el dispositivo con Windows To Go se conecte en otro equipo, no se pueda ver en el Explorador de Windows (O Explorador de Archivos en Win8), así se garantiza seguridad en la información que contiene.

Si instalamos el ADK como lo recomendé previamente, ejecutamos desde la Pantalla de Inicio el Deployment and Imaging Tools con privilegios elevados (CTRL + SHIFT + ENTER o Clic derecho, Ejecutar como administrador):

Si no instalaron el ADK, los siguientes comandos, los podrán correr desde el mismo Símbolo del Sistema que ejecutamos previamente para preparar el dispositivo.

*Nota: La razón por la que se puede hacer con las dos consolas, es que la herramienta de Dism está tanto en el ADK como embebida en Windows; personalmente recomiendo utilizar la que viene con el ADK.

El próximo paso será aplicar la imagen que está dentro de los archivos de instalación de Windows 8, y que contiene todo el sistema operativo en el dispositivo USB, aunque hasta Windows 7 lo normal era utilizar ImageX, lo haremos con DISM, la razón es que ImageX se estará descontinuando para los futuros procesos de implementación de Windows 8.

Ejecutamos:

Dism /Apply-Image /ImageFile:<DirWin>\Sources\install.wim /Index:1 /ApplyDir:<USB>

Donde <DirWin> es la ubicación de nuestros archivos de Windows 8 que copiamos en el primer caso, y <USB> es el dispositivo USB donde implementaremos la imagen. Para este artículo, mi ubicación es C:\8 y la letra de unidad es la L:\, por lo que el comando sería:

Dism /Apply-Image /ImageFile:C:\8\Sources\install.wim /Index:1 /ApplyDir:L:\

*Nota 1: El proceso tardará mucho o poco, dependiendo de la calidad del dispositivo.

*Nota 2: Si quieren utilizar ImageX, el comando sería por ejemplo:
ImageX /Apply C:\8\Sources\install.wim 1 L:\

El siguiente paso será copiar todos los archivos críticos de arranque a la partición del sistema, para crear además una nueva entrada en el BCD Store, esto ayudará a iniciar Windows To Go desde cualquier equipo.

Ejecutamos:

bcdboot.exe <USB>\Windows /F ALL /S <USB>

Donde <USB> corresponde a la letra del dispositivo que estamos configurando.
Para este post, como mi letra es la “L:”, el comando sería:

bcdboot.exe L:\Windows /F ALL /S L:

*Nota: Las banderas de /F y /S, son utilizadas en conjunto para identificar el tipo de Firmware en el que correrá el dispositivo, como deseamos asegurar que Windows To Go pueda iniciar tanto en UEFI como en BIOS, le agregamos el ALL

Con esto, nuestro dispositivo ya puede arrancar en cualquier otro PC y tendremos Windows To Go funcionando, pero.. si así lo hiciéramos, correríamos el riesgo de poder ver todas las particiones y discos del equipo host, incluso la que Windows reserva:

Eso por supuesto, no es una gran idea en materia de seguridad, y debido a esa razón, el Workspace Creator se encarga de utilizar una nueva política de Storage Area Network (SAN) para que todos los discos pasen a estar desactivados.
Como lo estamos haciendo manualmente, debemos acudir a un pequeño Archivo de Autorespuesta que establezca esta política mientras se está preparando el equipo en el primer inicio.

Abrimos un editor de texto como el Blog de Notas y pegamos exactamente lo que está dentro de las líneas horizontales:

<?xml version='1.0' encoding='utf-8' standalone='yes'?>
<unattend xmlns="urn:schemas-microsoft-com:unattend">
<settings pass="offlineServicing">
    <component
        xmlns:wcm=http://schemas.microsoft.com/WMIConfig/2002/State
        xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance
        language="neutral"
        name="Microsoft-Windows-PartitionManager"
        processorArchitecture="x86"
        publicKeyToken="31bf3856ad364e35"
        versionScope="nonSxS"
        >
      <SanPolicy>4</SanPolicy>
    </component>
    <component
        xmlns:wcm=http://schemas.microsoft.com/WMIConfig/2002/State
        xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance
        language="neutral"
        name="Microsoft-Windows-PartitionManager"
        processorArchitecture="amd64"
        publicKeyToken="31bf3856ad364e35"
        versionScope="nonSxS"
        >
      <SanPolicy>4</SanPolicy>
    </component>
</settings>
</unattend>

Lo guardamos como: SAM.xml y después lo situamos en la raíz del dispositivo USB donde implementamos Windows 8. Para mi caso, sería en L:\SAM.xml

*Nota 1: Noten el parámetro de <SanPolicy>, que es el que indica que sea “4” para que se pongan offline los discos, se encuentra dos veces, porque el archivo integra las dos arquitecturas posibles para ejecutar Windows To Go (x86 y x64).

*Nota 2: Si desean, pueden descargar el XML desde aquí:

Este es el enlace directo: http://sdrv.ms/P0whnz

Después de ubicar el archivo en el directorio raíz de la USB, desde un Símbolo del Sistema o una consola de Deployment and Imaging Tools con privilegios elevados (Abrimos de nuevo si las cerramos en los anteriores procedimientos), y ejecutamos:

Dism /Image:<USB> /Apply-Unattend:<USB>\SAM.xml

Donde <USB> es la letra que corresponde a nuestro dispositivo. Para este artículo, como mantenemos la “L:”, el comando sería:

Dism /Image:L:\ /Apply-Unattend:L:\SAM.xml

¡Todo listo! Removemos de forma segura el dispositivo USB, y finalmente, podemos probarlo en diferentes equipos, en el primero tendremos que configurar nuestro nombre de usuario y personalizaciones básicas, pero a partir del segundo, Windows To Go se encargará de reconocer los controladores, y dispositivos, e iniciará directamente con nuestro nombre de usuario.

Explorando Windows To Go

Después de dar los datos básicos al iniciar con el Espacio de Trabajo de Windows To Go, podremos comprobar que en efecto, todas las configuraciones previas funcionaron, por ejemplo, al entrar al Explorador de Archivos (A.K.A. Explorador de Windows), en la ventana de Equipo, debemos ver sólo la unidad correspondiente a nuestro sistema, es decir, la de la USB, sin importar dónde se corra:

Todos los demás discos y particiones, permanecerán siempre desactivados en los equipos host donde se inicie Windows To Go, para comprobarlo, basta con ir al Administrador de Discos y verlo con sus propios ojos:

Noten que sólo la unidad del sistema (USB), tiene asignada letra y está activa, las demás aparecerán sólo con su tamaño correspondiente. Si quisiéramos activarlas en equipos host confiables, bastaría con hacer clic derecho sobre el disco y seleccionar “En línea”:

Al iniciar en diferentes equipos, podremos también ver que el único cambio en las Propiedades del sistema, es el hardware que detecta (RAM, Procesador, Arquitectura, etc), de resto, mantendremos la información que le hayamos establecido en el primero de todos los equipos, por ejemplo:

Equipo 1:

Equipo 2:

Eso puede resolver algunas de las dudas que surgen de primero, pero por ejemplo, ¿Qué sucede si quitamos accidental o intencionalmente el dispositivo USB mientras está corriendo Windows To Go? Pues bien, el equipo dejará de funcionar, y empezará a contar 60 segundos exactos para que insertemos de nuevo nuestro dispositivo, si lo hacemos en el transcurso de tiempo establecido, funcionará instantáneamente otra vez y nos avisará del pequeño error que cometimos:

Si no insertamos el dispositivo en el período de tiempo, Windows To Go se apagará inmediatamente, lo que puede ocasionar pérdida de datos, daño en el Espacio de Trabajo de Windows To Go, o incluso un Pantallazo Azul indicando que no puede leer el dispositivo.

Mientras el dispositivo USB esté configurado con Windows To Go siguiendo todo este procedimiento, como le establecimos con Diskpart que no se podía ver cuando se conectara en equipos que estuvieran corriendo otro sistema operativo con la propiedad de “attributes volume set NoDefaultDriveLetter”, escucharemos que Windows reconoció el dispositivo, pero no lo podremos ver en el Explorador:

Sin embargo, si buscamos por el Administrador de Discos nuevamente, veremos que el dispositivo se reconoció, pero no tiene Letra de unidad asignada:

Esto no es todo en materia de seguridad, nosotros podremos utilizar la hasta ahora impenetrable característica de BitLocker para cifrar completamente el dispositivo desde el Espacio de Trabajo, así, cada que conectemos la USB en un equipo desde el que queramos iniciar, tendremos que proveer las credenciales de BitLlocker para poder continuar.

Algunas consideraciones

1. Windows To Go, no incluye Windows RE, que se refiere a las Opciones Avanzadas de Recuperación de Windows 8, aunque cuando se configura manualmente, debe establecerse esto también.

2. En Windows To Go, no funciona Refresh y Reset

3. En Windows To Go, predeterminadamente, no se pueden descargar aplicaciones de la Tienda (Windows Store), aunque se encuentra instalada, al intentar ingresar, nos mostrará el siguiente mensaje:

La razón de esto, es que algunas Aplicaciones de Windows 8 (A.K.A. Metro), pueden depender de ciertas características de Hardware, así que por política se desactiva en Espacios de Trabajo.

4. En Windows To Go, no se puede Hibernar de forma predeterminada, y la razón, es que los archivos de Hibernación funcionan de la mano con el hardware donde se está trabajando, para garantizar que WTG sea móvil, se desactiva esto por política.

*Nota: Es posible tanto descargar de la Tienda, como utilizar la Hibernación en un Espacio de Trabajo de Windows To Go, para esto debemos explorar las políticas que se han creado propias para esta característica, y habilitar estas funcionalidades y accesos.

Las políticas se encuentran en:

\\Configuración de equipo\Plantillas administrativas\Componentes de Windows\Sistema operativo portátil\

Para habilitar el acceso a la Tienda, se debe modificar la plantilla de “Permitir que la Tienda instale aplicaciones en el Área de trabajo de Windows To Go”, ubicada en:

\\Configuración de equipo\Plantillas administrativas\Componentes de Windows\Tienda\

Iremos tratando más a profundidad estos últimos temas en futuros artículos.

Espero les sea de utilidad, en un post más adelante, indicaré el paso a paso para configurar Windows To Go desde el Workspace Creator Tool.

Saludos,

Checho