Como probablemente se darán cuenta todos los que se toman el trabajo de entrar y leer las entradas de este blog, este artículo es completamente diferente a todo lo que aquí he expuesto antes, pues esta vez no hablaré acerca de una característica de Windows 8, de alguna solución sobre un problema que enfrente o tema relacionado a su implementación. Lo que mostraré por primera vez, algo más orientado a Windows Internals, tocando código y API de Windows en C++.
La razón de este post, es que me estoy planteando seriamente el reto de entrar en el mundo de la API de Windows, y es debido a que como bien dicen expertos: “Para poder solucionar los problemas de Windows, debes saber cómo funciona el sistema operativo.” La mejor forma, es necesariamente saber sobre Windows Internals, y para esto, es importantísimo entender y manejar la API. Como existen demasiadas funciones, quise empezar por algo que fuera familiar, y algo más fácil de entender, las operaciones con el Registro de Windows.
La primera función con la que quiero empezar, se llama RegCreateKeyEx, y es básicamente la que nos permite, a través de la API de Win32, crear una clave específica en el Registro de Windows. El problema que tuve yo, fue que enfrentarme a crear por primera vez una aplicación de Win32 y manejar este tipo de funciones en C++, definitivamente me iba a resultar complejo, y la documentación de MSDN es muy precisa y de pocos ejemplos para poder empezar. Tuve que indagar en la web, y después de ires y venires con diferentes variaciones, pude comprender en términos generales la forma como se expresa la función en MSDN, y finalmente crear mi primera clave. El segundo problema, es que para poder aprender de una mejor forma, necesitaba además de practicar, poder tener documentarlo en alguna parte, y que se convierta en mi propia referencia a futuro, y es aquí donde aparece mi blog, ¿qué mejor lugar para hacerlo, si no es en mi propio espacio?
Lo que haré en este artículo, será mostrar el paso a paso para crear nuestra primera aplicación de Win32 como referencia, pero además, cómo utilizar la función RegCreateKeyEx de una forma correcta para generar una clave en el Registo de Windows, incluyendo diferentes algunas formas de interactuar con ella utilizando Process Monitor de Sysinternals.
Creando la primera App de Win32
Antes que utilizar cualquier función, es necesario por supuesto crear un nuevo proyecto; y para asegurarme que los que sigan este artículo les funcione, quise incluir esta primera parte de la creación básica de una Aplicación de Win32. Necesitaremos básicamente:
- Visual Studio, en cualquier versión, pues este tipo de proyectos se crea desde cero. Preferiblemente, aconsejaría estar bajo 2012 que es la última oficial. Pueden descargar la versión Express que es totalmente gratuita desde aquí:
http://www.microsoft.com/visualstudio/esn/downloads#d-2012-express
- Equipo técnico con Windows XP / Vista / 7 / 8 para realizar la prueba. Este post se enfocará sobre Windows 8.
Para crear y configurar nuestro proyecto:
1. Desde Visual Studio, hacemos clic en Archivo > Nuevo > Proyecto.
2. Seleccionamos Visual C++ dentro de las Plantillas, o bien dentro del nodo de Otros tipos de proyectos (Según como hayamos configurado Visual Studio), y escogemos Proyecto de Win32. Lo demás será indicar el nombre y el destino del proyecto:
3. En el Asistente para Aplicación de Win32 que aparece, hacemos clic en el botón de Siguiente (Next) y después seleccionamos ‘Aplicación de Windows’ debajo de Tipo de Aplicación y Proyecto Vacio, debajo de Opciones adicionales para darle clic en Finish.
4. Hasta aquí, lo único que veremos será nuestro Explorador de Soluciones sin nada agregado en el panel derecho. Para poder agregar el código fuente, hacemos clic en el menú de Proyecto > Agregar nuevo elemento, seleccionamos Archivo de C++, le ponemos un nombre (Puede ser el predeterminado) y clic en Agregar:
5. Una vez estemos en la plantilla en blanco de nuestro código fuente, podremos empezar a escribir nuestra aplicación de Win32. Lo primero, y más importante, es referenciar nuestro archivo de cabecera, y nuestro punto de entrada, que conocemos como función principal.
Para una aplicación de Win32, nuestro punto de entrada es <Windows.h>, que incluye a su vez otras cabeceras de Windows y la función principal, o punto de entrada se llama WinMain.
Llevando esto al código, para cada aplicación de Win32, tendríamos lo siguiente:
#include <Windows.h>
//Se declara método principal
int WINAPI WinMain(HINSTANCE hInstance,
HINSTANCE hPrevInstance,
LPSTR lpCmdLine,
int nCmdShow){
} //Cierra método principal.
*Nota: En toda aplicación de Win32, siempre existirá la cabecera de Windows.h y la función de WinMain.
Acerca de RegCreateKeyEx
La sintaxis de la función RegCreateKeyEx, requiere nueve entradas que se pueden especificar manualmente mientras se escribe, o bien, declararlas desde antes y enviarle las variables como muestra la documentación de MSDN. Las variables (Que no necesariamente requieren tener los mismos nombres) son:
HKEY hKey: Este es el apuntador a una clave de Registro abierta, y tiene unas predeterminadas, que en mi concepto, son las que deberíamos utilizar aquí siempre como punto de partida, que son:
HKEY_CLASSES_ROOT.
HKEY_CURRENT_CONFIG.
HKEY_CURRENT_USER.
HKEY_LOCAL_MACHINE.
HKEY_USERS.
*Nota: Como ven, los que maneja predeterminadamente son la mayoría de los Hives que tiene Windows.
LPCTSTR lpSubKey: Este es el nombre denuestra subclave que vamos a abrir o crear. Debe estar contemplada como una subclave de la clave que creamos con hKey. Por ejemplo, si especificamos que escribiríamos en HKEY_LOCAL_MACHINE\Software una subclave llamada MiPrograma, lpSubKey debería contener: “\\Software\\MiPrograma”.
DWORD Reserved: Este parámetro siempre debe ser 0.
LPTSTR lpClass: Es el tipo de clase definidio por el usuario, pero suele ser NULL.
DWORD dwOptions: Este parámetro tiene diferentes opciones:
REG_OPTION_BACKUP_RESTORE.
REG_OPTION_CREATE_LINK.
REG_OPTION_NON_VOLATILE
REG_OPTION_VOLATILE.
El parámetro predeterminado es REG_OPTION_NON_VOLATILE, que permite básicamente que la información se preserve en un archivo cuando se reinicie el sistema.
REGSAM samDesired: Aquí se especificará qué operación se permitirá realizar a la llave que se retorna, es decir, a la que se creó. Si se especifica 0, una aplicación podría obtener ACCESS DENIED cuando trate de escribir sobre ella, algo que puede ser demostrado fácilmente con Process Monitor:
Los parámetros ideales para esta variable, pueden ser escogidos entre una lista que recibe el tipo de dato para determinar los derechos de acceso. Los más comunes son:
KEY_ALL_ACCESS
KEY_READ
KEY_WRITE
KEY_QUERY_VALUE.
Pueden ver toda la lista aquí:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms724878(v=vs.85).aspx
LPSECURITY_ATTRIBUTES lpSecurityAtrtributes: Si se desea establecer los ACLs para la clave que se cree, se utilizarían los parámetros de este tipo de dato. Lo más fácil para empezar, es dejarlo como NULL, para que obtenga los descritpores de seguridad predeterminados.
PHKEY phkResult: Este no es más que un apuntador a la variable que se creó o se abrió. Basta con delclararlo sin entregarle contenido, pues lo recibirá después de la operación.
DWORD lpdwDisposition: Este es un apuntador a una variable que puede recibir los siguientes valores después de la operación:
REG_CREATED_NEW_KEY.
REG_OPENED_EXISTING_KEY.
El que reciba una u otra, dependerá de si la clave que intentemos crear esté creada, incompleta o no se haya creado. Si está creada o incompleta, se recibirá REG_OPENED_EXISTING_KEY, pero si no está creada, se recibirá REG_CREATED_NEW_KEY.
*Nota: Internamente, Windows recibe es el número que referencia a estos valores. Si se especifica como NULL, no habrá retorno de nada.
Cabe aclarar que la función en sí misma tiene un retorno; en caso de ser satisfactoria la operación, es decir, que se creó, devolverá: ERROR_SUCCESS, aunque por experiencia propia, se vuelve más cómodo trabajar con el valor que retorne lpdwDisposition.
Con lo anterior claro, o por lo menos explicado de la mejor forma que entendí, y pude, lo siguiente es finalmente pasar a personalizar los parámetros y valores para que generar nuestra clave:
Creando nuestra primera clave de Registro
Para proceder y ser prácticos en toda la teoría anterior, crearé una clave que se llame: MiClave, dentro de HKEY_CURRENT_USER\Checho’s Blog. Para no tener mayores inconvenientes con permisos ahora, y entre otras, porque todas las aplicaciones deberían escribir siempre allí; le pondré permisos para leer y escribir desde samDesired (KEY_READ | KEY_WRITE) y para poder corroborar, imprimiré un mensaje que me diga el resultado de la operación.
*Nota: Trataré lo del MessageBox al final del post.
Declarando las variables que introduje anteriormente, y con referencia a lo que quiero crear, el código quedaría así:
#include <Windows.h>
//Se declara método principal
int WINAPI WinMain(HINSTANCE hInstance,
HINSTANCE hPrevInstance,
LPSTR lpCmdLine,
int nCmdShow){
//Declaración de variables y sus parámetros:
HKEY hKey=HKEY_CURRENT_USER;
LPCTSTR lpSubKey=L"Checho's Blog\\MiClave";
DWORD Reserved=0;
LPTSTR lpClass=NULL;
DWORD dwOptions=REG_OPTION_NON_VOLATILE;
REGSAM samDesired=KEY_READ | KEY_WRITE;
LPSECURITY_ATTRIBUTES lpSecurityAttributes=NULL;
HKEY phkResult;
DWORD lpdwDisposition;
}//Cierra método principal.
*Nota: Hasta aquí, aún no hemos creado la clave, sólo se declararon las variables que utilizará la función de RegCreateKeyEx.
Ahora bien, en la función solo tendríamos que remplazar lo que pide con los valores en el orden adecuado, es decir:
*Nota: En la documentación oficial, phkResult, debe ser de tipo PHKEY para que la función lo acepte, pero como es necesario después cerrar la operación con RegCloseKey, y ésta solo acepta un tipo HKEY, fue necesario declararla como tal, y dentro del la función anteponer un ‘&’ para que se refiere a la misma dirección de memoria que tiene nuestro valor. Lo mismo sucede con lpdwDisposition, pues para operar su resultado después, requiere que sea mínimo DWORD. Si logro encontrar la razón, o la forma de cómo no tener que modificarlas para suplir estas dos necesidades, actualizaré el post.
Con todo lo anterior, ya nuestra clave se crea sin ningún problema, pero como dije antes, es bueno tener algún tipo de respuesta de parte de la aplicación para saber cuándo fue exitoso, o cuándo falló. Para esto, utilizaremos el resultado que devuelva lpdwDisposition, y el método de MessageBox para mostrar un mensaje al usuario.
Como podemos tener REG_CREATED_NEW_KEY o REG_OPENING_EXISTING_KEY en lpdwDisposition, jugaremos con una sentencia de ‘if’ para mostrar el mensaje correcto.
El código sería:
//Validamos si la clave se creó.
if (lpdwDisposition==REG_CREATED_NEW_KEY)
{
MessageBox(NULL,
L"La clave se creó desde cero.",
L"Mi primera Aplicación de Win32",
MB_ICONINFORMATION);
}
//Validamos si la clave sólo se abrió, pues ya estaba creada.
else if(lpdwDisposition==REG_OPENED_EXISTING_KEY)
{
MessageBox(NULL,
L"La clave se abrió, pero no se modificó.",
L"Mi primera Aplicación de Win32",
MB_ICONEXCLAMATION);
}
//Error que no esté contemplado.
else
{
MessageBox(NULL,
L"Error al crear o abrir la clave.",
L"Mi primera Aplicación de Win32",
MB_ICONERROR);
}
Estamos validando con if, tres opciones:
1. Si la clave se crea porque no existe.
2. Si no sucede lo primero, se valida que la clave ya exista.
3. Si no se da alguna de las anteriores, indicamos error.
Los tres mensajes se hacen con un MessageBox. Es muy sencillo de crear, le indicamos un valor NULL como primera parámetro, lo segundo es el texto que deseamos tenga, el tercer parámetro es el título del mensaje y el último, el icono y/o bonotes que puede mostrar. Más información acerca de la función de MessageBox:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms645505(v=vs.85).aspx
Finalmente, y como algo que siempre debe hacerse, cerramos la operación que hicimos sobre la sublcave de Registro con la función RegCloseKey, que solo recibe un parámetro, y es el apuntador que devuelve en este caso phkResult. La sintaxis sería:
RegCloseKey(phkResult);
Juntando todo lo anterior, el código completo sería:
#include <Windows.h>
//Se declara método principal
int WINAPI WinMain(HINSTANCE hInstance,
HINSTANCE hPrevInstance,
LPSTR lpCmdLine,
int nCmdShow){
//Declaración de variables y sus parámetros:
HKEY hKey=HKEY_CURRENT_USER;
LPCTSTR lpSubKey=L"Checho's Blog\\MiClave";
DWORD Reserved=0;
LPTSTR lpClass=NULL;
DWORD dwOptions=REG_OPTION_NON_VOLATILE;
REGSAM samDesired=KEY_READ | KEY_WRITE;
LPSECURITY_ATTRIBUTES lpSecurityAttributes=NULL;
HKEY phkResult;
DWORD lpdwDisposition;
//Declarando la función:
RegCreateKeyEx(hKey,
lpSubKey,
Reserved,
lpClass,
dwOptions,
samDesired,
lpSecurityAttributes,
&phkResult,
&lpdwDisposition);
//Validamos si la clave se creó.
if (lpdwDisposition==REG_CREATED_NEW_KEY)
{
MessageBox(NULL,
L"La clave se creó desde cero.",
L"Mi primera Aplicación de Win32",
MB_ICONINFORMATION);
}
//Validamos si la clave sólo se abrió, pues ya estaba creada.
else if(lpdwDisposition==REG_OPENED_EXISTING_KEY)
{
MessageBox(NULL,
L"La clave se abrió, pero no se modificó.",
L"Mi primera Aplicación de Win32",
MB_ICONEXCLAMATION);
}
//Error que no esté contemplado.
else
{
MessageBox(NULL,
L"Error al crear o abrir la clave.",
L"Mi primera Aplicación de Win32",
MB_ICONERROR);
}
RegCloseKey(phkResult);
}//Cierra método principal.
Cuando se cree, el mensaje indicado en MessageBox anterior debería ser similar al siguiente:
Cuando la clave ya exista, el mensaje debería ser similar al siguiente:
Si vemos con Process Monitor el resultado de los permisos resultantes en la subclave, teniendo en cuenta que le indiqué lectura y escritura, se vería así:
Las propiedades del resultado deben indicar claramente los permisos asignados:
*Dato curioso: La información actual sobre esta función (RegCreateKeyEx), indica que la DLL o el módulo que la contiene, es Advapi32.dll, pero al momento de confirmar esto, utilizando la pestaña de Stack que tiene Process Monitor, que permite ver operaciones a nivel de usuario y Kernel, el resultado es diferente:
Como ven, el módulo que ahora contiene esta y la gran mayoría de las principales funciones de la API de Windows, es: KernelBase.dll.
Según me confirmó muy amablemente Aaaron Margosis de Microsoft, existen todavía unos puntos de entrada en Advapi32.dll, pero redireccionan a KernelBase.dll, y que además esto sucede desde Windows 7.
Espero les sea de utilidad, y por supuesto, si hay algo en lo que puedan aportar, no duden en hacer su comentario.
*Nota: Es necesario tener un usuario en Geeks.ms para poder comentar en estos Blogs.
Saludos,
Checho
Conforme vamos instalando aplicaciones en nuestro sistema operativo, notaremos que algunas como Antivirus, Mensajería, Controladores, etc, se toman algunas ventajas, y se empiezan a ejecutar después de cada inicio de sesión. Esto en la mayoría de los casos empieza a ser un problema, cuando la velocidad de arranque de Windows se compromete por todos los procesos que debe iniciar previamente; pero además, cuando por una razón X o Y empiezan a generarse mensajes extraños sobre ejecuciones que el sistema operativo trata de realizar y que no encuentra. En el post de hoy, veremos un caso particular, pero un comportamiento común de este tipo de problemas.
El problema
El problema como en la mayoría de las ocasiones, surgió de una pregunta hecha en los Foros de Windows 8 de Microsoft TechNet. Cada que el usuario iniciaba sesión, estaba viendo dos mensajes relacionados con unos Scripts de Javascript que se intentaban ejecutar, pero que al parecer no estaban teniendo éxito:
El primero con nombre de 0216.js, estaba intentando ejecutarse desde:
C:\Users\Dania\AppData\Roaming\1400, y el segundo con nombre de 5e545.js, se estaba intentado ejecutar desde:
C:\Users\Dania\AppData\Roaming\Microsoft\Windows\StartMenu\Programs\Startup.
La causa
Windows predeterminadamente suele utilizar varias ubicaciones en Explorador y Registro donde ubica las referencias de lo que se inicia por cada usuario, o por todos los usuarios. Por ejemplo, una clave distintiva para este tipo de ejecuciones, es:
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
Aunque para equipos de 64 bits, se agrega también:
HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Run
Estas dos ubicaciones se pueden utilizar a través de las políticas de grupo para personalizar ejecuciones de proceso en un ambiente local o de dominio, por supuesto, también se pueden crear las entradas manualmente desde el Editor de Registro.
Hasta Windows 7, la herramienta de MSCONFIG, embebida en Windows, tenía una pestaña de Arranque donde podíamos ver gráficamente todas las entradas que estuvieran en estas claves; característica que pasó al mejorado Administrador de Tareas en Windows 8. No obstante, MSCONFIG sigue existiendo con las demás funcionalidades.
El problema es que si el proceso se encuentra en algún directorio diferente y no muy común, no nos servirá de nada el MSCONFIG o el Administrador de Tareas, pues les quedará imposible mostrarnos otras ubicaciones por su funcionalidad tan reducida.
Así lucen las ejecuciones normalmente desde el MSCONFIG o Administrador de Tareas:
Esta limitación aplicaba para el caso que estoy exponiendo, así que el Administrador de Tareas no ayudaba en lo absoluto para prevenir o eliminar la ejecución de estos Scripts.
En este punto es donde por enésima vez, entran a jugar un papel fundamental las herramientas de Sysinternals. Para el problema específico, le tocó el turno a Autoruns.
Autoruns y Autorunsc (Versión de línea de comandos), tiene funcionalidades del MSCONFIG avanzadas, desde donde podemos ver absolutamente TODO lo que está iniciando con Windows, desde Controladores, hasta DLLs, Tareas Programadas, extensiones al Explorador de Windows, al Internet Explorer, etc. Además de esto, Autoruns tiene otras características únicas, que nos pueden permitir comparar varios logs de inicio, ejecución desde un Windows PE para deshabilitar controladores que puedan estar previniendo la correcta ejecución de Windows, etc.
Autoruns tiene una pestaña llamada Logon, que es a la que el MSCONFIG y actualmente el Administrador de Tareas en su pestaña de Arranque se le asemejan.
Así se vería el resultado en el mismo sistema desde el que mostré la imagen anterior:
Como ven, Autoruns no solo muestra el proceso, su descripción y su estado, sino que además nos permite ver e interactuar con la ruta de ejecución, y ver muchas más entradas que están iniciando con Windows.
Volviendo al caso, y una vez hecho el análisis con Autoruns, nos encontramos con dos entradas muy particulares en la pestaña de Logon dentro de Autoruns:
Justamente los dos archivos a los que se referían los mensajes, uno iniciando en la carpeta de Startup directamente, otro en HKCU\Software\Microsoft\Windows\CurrentVersion\Run.
La solución
Lo ideal sería tratar de llegar un poco más al fondo, e incluso ver qué contenían los archivos; lamentablemente, los casos que se abren en el foro no suelen tener mucho seguimiento de parte del que los abre una vez se solucionan, y es apenas normal, pues por lo general van en busca de esto.
El primer y más importante paso, es deshabilitar y en su posible, eliminar la entrada que permita la llamada a estos archivos; esto se puede hacer directamente desde Autoruns, y para este caso, lo unico que tuvo que hacer la persona que abrió el hilo en el Foro, fue quitar la selección en la izquierda de la entrada y con esto Windows no volvería a llamarlo una vez prenda, a menos que otra aplicación o proceso específico las volviera a habilitar:
Desde Autoruns se puede eliminar completamente la entrada haciendo clic derecho y seleccionando Delete también.
Con esto, y gracias a Autoruns, el problema de los mensajes extraños quedó solucionado.
Anexo
Si en el caso anterior, o en cualquier otro similar, quisiéramos investigar un poco más como mencioné antes, desde Autoruns podríamos hacer clic derecho sobre la entrada y hacer clic en Jump to Entry:
Esto nos abriría la ubicación directa del archivo, sin necesidad de ejecutarlo, y así poder trabajar sobre el Script físico, pues Autoruns solo inhabilita la entrada.
Entre otras funciones, al hacer clic derecho podríamos ir a las Propiedades generales del archivo, hacer la búsqueda por la web, o más interesante, buscar el proceso en ejecución desde Process Explorer:
De esta forma, no solo podríamos explorar firmas digitales, y propiedades más específica sobre el proceso, sino que además podríamos desde Process Explorer ver el arbol de ejecución y saber qué proceso padre lo genera o lo mantiene.
Como ven entonces, no solo cada herrramienta de Sysinternals es muy útil y productiva por sí sola, sino que además las principales (Process Explorer, Process Monitor y Autoruns), pueden hacer un conjunto con mucho poder para analizar y remover Malware, o bien hacer un Troubleshooting completo, si el problema así lo requiere.
Saludos,
Checho
Hasta ahora, y volviendo al tema de implementación de Windows 8, he tratado diferentes maneras de hacer el despliegue, sean manuales o utilizando herramientas automatizadas como MDT y WDS. Una de las necesidades, independiente del modelo de despliegue, es la forma como se administrará la distribución de aplicaciones, pues se pueden dejar en una imagen maestra (Arriesgándonos a que el .WIM se vuelva muy pesado) o como sería lo ideal, instalarlas durante el mismo asistente de instalación gestionado por MDT.
Por otro lado, la necesidad del despliegue de aplicaciones a través de la organización no siempre va ligada a una instalación paralela del sistema operativo, pues en muchas ocasiones es necesario actualizar las aplicaciones que ya existen, o integrar nuevos paquetes sin comprometer Windows, datos y configuraciones actuales. Es aquí donde cobra mucho sentido tener una solución como System Center Configuration Manager (SCCM), pues de otro modo, lo normal es que se tengan que hacer las instalaciones manuales pasando máquina por máquina.
Sin embargo, lo que por lo general no sabemos, es que podemos sacar un buen provecho de Microsoft Deployment Toolkit (MDT), que es totalmente gratuito, para generar nuestra propia solución para el despliegue corporativo de aplicaciones a través de la red, sin requerir mucho esfuerzo. Lo que haremos en este artículo, será partir de un Deployment Share ya creado para agregar nuevas aplicaciones e instalarlas en un equipo con Windows 8 que accederá al MDT a través de la red.
Lo que necesitamos
- Los archivos de instalación de las diferentes aplicaciones que deseamos instalar. Para este post, yo utilizaré tres que considero básicas y hasta primordiales en cierto punto:
* Adobe Reader XI (El lector de Windows 8 sinceramente no sirve).
* WinRAR
* Skype
*Nota: Están referenciados los enlaces para los instaladores offline, por si desean seguir el artículo con las mismas aplicaciones.
- Un equipo técnico, preferiblemente Windows Server (2008, 2008 R2, 2012), que tenga instalado y configurado de forma básica Microsoft Deployment Toolkit (MDT).
- Un equipo de referencia, que esté en la misma red del equipo técnico, donde se puedan instalar las aplicaciones (Preferiblemente Windows 8).
Preparando el Deployment Share
Por supuesto, debemos tener un recurso compartido básico ya montado y configurado, donde podamos agregar aplicaciones, sistemas operativos y toda clase de componentes necesarios para implementar Windows a través de la red. Para evitar repetir algo que está escrito en otros post, pueden seguir el paso a paso y crear el primer Deployment Share siguiendo este artículo:
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: Para este artículo, no es necesario crear la Secuencia de Tareas que instale Windows, ni agregar componentes como actualizaciones o controladores (A menos que se quiera instalar todo dede una sola Secuencia de Tareas).
Agregando aplicaciones al Deployment Share
Una vez hayamos creado y configurado nuestro Deployment Share, debemos empezar a importar todas las aplicaciones corporativas que deseamos tener a disposición desde MDT. Para esto, debemos realizar los siguientes pasos:
- Expandimos nuestro Deployment Share, hacemos clic derecho en el nodo de Applications y seleccionamos New Folder:
Se abrirá el asistente para crear una nueva carpeta, aquí especificaremos el nombre y una descripción para la misma:
Hacemos clic en el botón Next dos veces y en Finish para terminar el asistente. Se creará una subcarpeta debajo de Applications. El objetivo de esto, es tener un poco de orden con respecto a la cantidad de aplicaciones que se vayan agregando.
- Hacemos clic derecho sobre la carpeta que creamos, y seleccionamos New Application. Se abrirá el asistente para agregar nueva aplicación:
- En la página de Application Type, dejamos la selección predeterminada de Application with source files y clic en Next:
- En la página de Details, rellenamos todos los campos correspondientes a nuestra aplicación y hacemos clic en el botón Next:
- En la página de Source, hacemos clic en el botón de Browse y seleccionamos el directorio donde guardamos el instalador correspondiente, y clic en Next:
*Nota: Es primordial que todos los instaladores se guarden dentro de una carpeta, pues el asistente no reconoce el instalador independiente.
- En la página de Destination, editamos o dejamos el nombre que deseamos aparezca la aplicación en el asistente y clic en Next:
- En la página de Command Details, es donde finalmente debemos especificar la línea de comandos que haga la instalación de preferencia, totalmente automatizada. Es decir, que no haya ningún tipo de interacción por parte del usuario para asegurar que se instale incluso con personalizaciones corporativas (Si la aplicación lo permite, como Office, o el mismo Adobe). Escribimos toda la línea debajo de Command Line. Por ejemplo, para Adobe Reader XI, utilizando el nombre predeterminado del instalador, sería:
AdbeRdr11003_en_us_.exe /sALL /rs
Clic en el botón Next para continuar.
*Nota: Cada instalador puede tener parámetros diferentes, por lo que es conveniente haber probado la instalación con las banderas que se requieran en algún equipo de pruebas. Si requieren encontrar referencias de instalaciones desatendidas para sus aplicaciones, pueden visitar la página de ITNinja: http://www.itninja.com/
En la página de Summary hacemos clic en Next, y finalmente en la página de Confirmation, clic en Finish para terminar.
Como mencioné antes, el proceso anterior se debe repetir con cada nueva aplicación y por supuesto, una por una indicarle el comando para la instalación silenciosa que se necesite. Para este artículo, que estoy utilizando además de Adobe, WinRAR 5.0 y Skype en su última versión 6.3, tendría que utilizar los siguientes comandos:
Para WinRAR x64 5.0: WinRAR.exe /S
Para Skype 6.3: msiexec /i SkypeSetup.msi /qr
*Nota: Los nombres del ejecutable pueden variar.
Al terminar de importar todas las aplicaciones, debemos verlas en la parte derecha de la carpeta que creamos debajo del nodo Applications:
Creando Secuencia de Tareas
Lo siguiente, como ya tenemos todas las aplicaciones, es crear nuestra Secuencia de Tareas que se encargará de desplegar todas las aplicaciones que se seleccionen en los clientes que se carguen. Para crear nuestra Secuencia de Tareas, realizamos los siguientes pasos:
- Expandimos nuestro Deployment Share, clic derecho Task Sequences, y seleccionamos New Task Sequence:
- En la página de General Settings, debemos indicar un ID para la Secuencia de Tareas, un nombre y una respectiva descripción:
Clic en el botón Next.
- En la página de Select Template, debemos seleccionar Custom Task Sequence en la lista desplegable y clic en 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.
Actualizando Deployment Share
Por último, hacemos clic derecho sobre nuestro Deployment Share, y seleccionamos Update Deployment Share:
En la ventana de Update Deployment Share Wizard, dejamos la selección predeterminada de Optimize the boot image updating process y clic en el botón Next:
En la página de Summary, clic en Next. En la página de Confirmation, clic en Finish.
¡Todo está listo! Nuestro último paso es conectar el equipo cliente y desplegar.
Desplegando aplicaciones
Desde el equipo de referencia (Cualquier equipo Windows), debemos conectarnos al MDT para poder ejecutar la Secuencia de Tareas.
Abrimos la ventana de Ejecutar (Windows + R) y digitamos:
Wscript.exe \\<Server>\<DeploymentShare>$\Scripts\BDD_Autorun.wsf
Donde \\<Server> es el nombre del Servidor que aloja el MDT, y <DeploymentShare> el nombre de nuestro recurso compartido. Para este artículo, el nombre del Servidor es DC y el recurso compartido se llama DeploymentShare, por lo que el comando sería:
Wscript.exe \\DC\DeploymentShare$\Scripts\BDD_Autorun.wsf
Nos debe aparecer la ventana de Auto-Run Windows Deployment:
Hacemos clic en el botón OK y debe cargar un Símbolo del sistema, seguido por el Asistente de MDT.
*Nota: Si el UAC nos pide consentimiento, hacemos clic en Aceptar para proceder.
En la página de Task Sequence, seleccionamos la Secuencia de Tareas recién creada para la instalación de aplicaciones y clic en Next:
En la página de Applications, expandimos la carpeta correspondiente a las aplicaciones importadas y seleccionamos las que deseemos instalar:
Clic en el botón Next.
En la página de Credentials, le indicamos credenciales administrativas para poder conectarnos al recurso compartido y clic en Next:
En la página de Ready, clic en Begin para iniciar la instalación.
Iniciará la instalación de cada una de las aplicaciones que se indicaron en el Asistente del MDT:
*Nota: Dependiendo de los parámetros que se hayan especificado en la línea de comandos al importar la aplicación, podremos ver o no interacción de la aplicación; lo ideal es que se especifique siempre la menor cantidad de interacción posible, para evitar que el usuario pueda interrumpir el proceso de instalación.
Al terminar, hacemos clic en el botón de Finish de la página Success para cerrar el asistente:
*Nota: Esta última ventana nos dirá si hubo errores o advertencias durante el proceso de instalación, al igual que se hace cuando implementamos Windows.
Nuestras aplicaciones ahora estarán disponibles desde el sistema operativo:
Espero sea de utilidad.
Saludos,
Checho
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
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
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í:
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
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
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
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
*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.
- 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
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
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
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
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
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
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
[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
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
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
¡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)
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
Más artículos
Página siguiente >