Los anuncios que no dejaban navegar en IE, ProcExp, Autoruns y su solución

A pesar de haberme enfrentado a varios problemas en los últimos meses, no había tenido la oportunidad de documentar nuevamente alguno aquí en el blog. Hoy, aprovechando un pequeño Adware al que me enfrenté, quiero exponerles la solución, ya que he empezado a ver comportamientos similares. Como es costumbre, la entrada estará dividida en tres partes: el problema, la causa y su solución.

El problema

Cuando el usuario intentaba abrir cualquier página en internet o simplemente, en los casos que abría la pagina, hacer clic en algún enlace, se ejecutaban diferentes pestañas con propaganda, la mayoría haciendo referencia a una herramienta de reparación de Windows:

image

Como podrán imaginarse, esta era una falsa herramienta. Este comportamiento era además bastante molesto, pues no se podía navegar con tranquilidad.

La causa

Este tipo de Adware solía instalarse como un complemento del navegador para funcionar; por este motivo, utilicé Autoruns para ver todas las extensiones que cargaban con Internet Explorer, pero no encontré nada que pudiese ayudarme.

Si la ejecución de este software malicioso no estaba asociada a un complemento, definitivamente lo tenía que estar con algo ejecutándose en el sistema operativo. Así pues, procedí a ejecutar la herramienta por excelencia, Process Explorer.

Aunque Process Explorer me iba a dar todo el detalle de cada proceso, no iba a ser tan sencillo, puesto que este tipo de aplicaciones maliciosas se disfrazan en procesos confiables. Decidí entonces utilizar la característica de VirusTotal, función útil para enviar el hash de todo lo que se está ejecutando a la base de datos que maneja VirusTotal.com, y esta devuelve un resultado para saber si la entrada en cuestión ha sido ya puesta en lista negra.

Para habilitar el análisis de VirusTotal, fui al menú Options, VirusTotal.com y por último clic en CheckVirusTotal.com.

image

Una vez se habilita el análisis de VirusTotal, Process Explorer crea una columna adicional, VirusTotal, que muestra una comparación entre reportes de malware contra la base de datos que tienen las principales firmas de seguridad. En mi caso, pude detectar inmediatamente dos procesos muy sospechosos, y que tenían una buena cantidad de reportes como maliciosos:

image

Gracias a Process Explorer es posible hacer doble clic sobre el proceso y ver las propiedades para obtener muchos más detalles; por ejemplo, la firma digital, ubicación de instalación, línea de comandos, entre muchos otros.

image

Como pueden ver, el proceso estaba relacionado al programa HQ Video Pro 3.1, que además tenía su propia firma digital a nombre de Digit Network (Exreme White Limited). Debido a que el Autostart Location me indicaba que el Programador de tareas estaba ejecutando el proceso en cada inicio, decidí correr nuevamente Autoruns y ver la pestaña de Sheduled Tasks, y esto es lo que me encontré:

image

No solo se ejecutaban dos procesos, sino ocho relacionados al mismo programa.

La solución

Como había comprobado que HQ Video Pro 3.1 era malicioso y no habían más procesos sospechosos en Process Explorer, el camino más directo era proceder a eliminar HQ Video Pro del sistema operativo; para esto, fui hasta el Panel de control, lo identifiqué y procedí a eliminarlo:

image

Después de un par de clics, el programa se desinstaló correctamente.

image

Naturalmente, había que revisar después de un reinicio si Process Explorer detectaba otra vez la ejecución de este proceso, que Autoruns no tuviese más entradas en el Programador de tareas sospechosas y que no hubiesen quedado archivos relacionados a esta aplicación en Archivos de programa. Para mi fortuna, todo eso estuvo muy bien y el problema desapareció.

Saludos.

—Checho

Implementación básica de Work Folders para Windows 8.1 y Windows 10

Normalmente no acostumbro a publicar entradas referentes a Windows que se concentren más en el lado del servidor que del cliente; sin embargo, hay varias tecnologías, viejas y nuevas, que requieren bastante trabajo de cara al servidor para que el cliente pueda disfrutar de ellas.

Debido a que Windows 10 está trayendo tantas características interesantes, trataré de ir mostrando, conforme vaya aprendiendo, la implementación. Hoy, no obstante, quiero mostrar una característica que viene desde Server 2012 R2, relativamente simple de implementar y que puede llegar a ser muy útil: Work Folders.

Introducción a Work Folders

Work Folders es un rol que está disponible desde Windows Server 2012 R2, y que provee una forma consistente para que los usuarios puedan acceder a sus datos corporativos, independiente si es desde un computador personal o de trabajo, incluso a través de internet y desde dispositivo móvil.

Básicamente, con Work Folders podemos crear un repositorio central en el que los usuarios almacenen archivos corporativos y puedan acceder a ellos desde su equipo empresarial o, siguiendo el modelo de BYOD, desde su computador personal. Estos archivos pueden ser completamente controlados desde la organización utilizando directivas de seguridad; además, con Windows 10, se podrá activar Enterprise Data Protection (EDP) para cifrar el contenido y aprovechar todas las ventajas de esta otra característica.

La implementación de este rol, aunque puede llegar a ser compleja, se puede hacer de una forma básica para que los dispositivos puedan acceder a los datos desde que estén conectados la red empresarial. A continuación mostraré cómo podemos realizar un despliegue básico, para luego probar el acceso a los archivos desde un equipo con Windows 8.1 y otro con Windows 10.

Nota: Pueden obtener más información sobre Work Folders aquí: https://technet.microsoft.com/en-us/library/dn265974.aspx.

Requerimientos

Para implementar Work Folders necesitaremos:

  1. Ambiente de dominio
  2. Servidor con Windows Server 2012 R2 adicional y que esté unido al dominio
  3. Repositorio central en donde se vayan a almacenar los archivos
  4. 2 o más equipos con sistema operativo cliente. En este ambiente utilizaré uno con Windows 8.1 y otro con Windows 10, versión 1511

Implementando Work Folders

Las siguientes operaciones las haremos en el servidor adicional que tiene instalado Windows Server 2012 R2 (segundo requerimiento):

  1. En el Server Manager, clic en Add roles and features

    image

  2. En la página de Before you begin, si está habilitada, clic en Next
  3. En Installation type, dejamos la opción predeterminada y clic en Next

    image

  4. En la página de Server Selection, nos aseguramos de tener seleccionado el servidor destinado para Work Folders y clic en Next

    image

  5. En la página de Server Roles, expandimos el nodo de File and Storage Services, luego File and iSCSI Services y seleccionamos Work Folders

    image

    Cuando seleccionamos Work Folders, nos aparecerá una ventana adicional de Add features that are required for Work Folders?, allí simplemente hacemos clic en Add features

    image

  6. En la página de Features, clic en Next

    image
  7. En la página de Confirmation, clic en el botón Install para iniciar la instalación

    image

  8. Una vez terminado el proceso de instalación hacemos clic en Close

    image

Creando y configurando el Sync Share

Para que Work Folders pueda funcionar necesitamos un Sync Share, que puede verse básicamente como un repositorio central en donde estarán todas las carpetas, y en donde se administrará el acceso a diferentes grupos de Directorio Activo. Para configurar nuestro Sync Share, debemos seguir estos pasos:

  1. En el Server Manager, hacemos clic en el nuevo nodo de File and Storage Service

    image

  2. A continuación hacemos clic en Work Folders, y luego en el enlace de To create a Sync Share for Work Folders, start the new Sync Share Wizard

    image

  3. En la página de Before you begin, clic en el botón Next

    image
  4. En la página de Server and Path, seleccionamos Enter a local path y le indicamos el directorio en donde deseamos habilitar Work Folders

    image

  5. En la página de User Folder Structure, dejamos la selección de User alias y clic en Next

    image

    Nota: En el caso de que esta carpeta contenga otras subcarpetas, podemos seleccionar Sync only the following subfolder, aunque esto cobraría valor si Work Folders se estuviese implementando en la misma carpeta de Folder Redirection por ejemplo.

  6. En la página de Sync Share Name, escogemos un nombre, descripción (opcional) y clic en Next

    image

  7. En la página de Sync Access, clic en el botón Add…, buscamos el grupo de Directorio Activo al que deseamos otorgarle permisos para trabajar sobre Work Folders, clic en OK y luego en Next

    image

    Nota: Si deseamos, como administradores, tener acceso a las carpetas, debemos deshabilitar la opción de Disable inherited permissions and grant users exclusive access to their files.

  8. En la página de Device Policies, decidimos si queremos cifrar o no, además de aplicar las directivas de seguridad y clic en Next

    image

  9. En la página de Confirmation, hacemos clic en el botón Create para terminar

    image

  10. Si todo sale bien, nos debe mostrar la página de Results con las operaciones completadas. Clic en Close.

    image

 

Creando directivas de grupo

Aunque cada usuario puede configurar el acceso a Work Folders sin mayor problema, es preferible, al menos para los usuarios de dominio, hacerlo de forma controlada con las directivas de grupo y evitar problemas.

Las siguientes tareas deben hacerse en el Controlador de dominio (primer requerimiento):

  1. Abrir el Group Policy Management, navegar hasta la OU (Unidad organizacional) que se aplicará la directiva (o en la raíz para todo el dominio), clic derecho y luego Create a GPO in this domain, and Link it here…

    image
  2. Le indicamos un nombre de preferencia (en mi caso: Work Folders policies), y clic en OK

    image

  3. Clic derecho en la nueva GPO y luego Edit…

    image

  4. En el Editor de directivas de grupo, navegamos hasta: User Configuration\Policies\Administrative Templates\Windows Components\Work Folders

    image

  5. Hacemos doble clic sobre la carpeta Work Folders, y luego, Specify Work Folders settings

    image

  6. En la ventana de la plantilla Specify Work Folders settings, marcamos Enabled, escribimos como URL la ruta completa a nuestro servidor con el rol de Work Folders, marcamos Force automatic setup y clic en OK

    image

    Nota: Hay que tener en cuenta que la URL será diferente en cada escenario.

  7. Cerramos la plantilla de Specify Work Folders settings
  8. Navegamos ahora hasta Computer Configuration\Preferences\Windows Settings\Registry, y hacemos clic derecho en Registry y luego New Registry item

    SNAGHTML14d962d9

  9. Aquí lo que haremos será básicamente configurar un valor de registro para que Work Folders no nos solicite una URL segura (https) al momento de conectarnos, puesto que para eso necesitaríamos un certificado público. Los valores deben quedar así:
    1. Hive: HKEY_LOCAL_MACHINE
    2. Key Path: SOFTWARE\Microsoft\Windows\CurrentVersion\WorkFolders
    3. Value name: AllowUnsecureConnection
    4. Value type: REG_DWORD
    5. Value data: 1

    image

  10. Clic en OK y cerramos todo

Probando Work Folders

Windows 8.1

En este escenario utilizaré un equipo que no está unido al dominio (Traiga su propio dispositivo); debido a que no recibe directivas, no hay manera de que Work Folders se configure automáticamente, así que es necesario hacer algunos pasos para podernos conectar:

  1. Ejecutamos el CMD con privilegios elevados y ejecutamos:
    Reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WorkFolders /v AllowUnsecureConnection /t REG_DWORD /d 1

    image

  2. Desde la Pantalla de inicio, buscamos Work Folders y luego clic en Manage Work Folders

    image

  3. En la ventana de Work Folders, clic en el enlace de Set up Work Folders

    image

  4. En la página de Enter your work email address, clic en Enter a Work Folders URL instead

    image

  5. En la página de Enter a Work Folders URL, digitamos toda la dirección del servidor que configuramos previamente, y que es diferente en cada caso. Hacemos clic en Next después

    image

  6. Debido a que no estamos en el dominio, es necesario autenticarnos antes de continuar

    image

  7. En la página de Introducing Work Folders, podemos hacer clic en el botón Change para indicarle una ruta diferente a nuestros archivos sincronizados con Work Folders o bien clic en Next para terminar

    image

  8. En la página de Security policies, señalamos el cuadro de I accept these policies on my PC y clic en Setup Work Folders

    image

  9. Después de unos segundos, nuestro PC debe quedar listo para utilizar Work Folders. Clic en Close para terminar

    image

  10. Nuestro último paso es, por supuesto, pasar a crear o copiar nuestros archivos en la carpeta de Work Folders y comprobar la sincronización

    image
    Figura 1: Archivo guardado en Windows 8.1.

    image
    Figura 2: Archivo en el servidor de Work Folders.

 

Windows 10

Debido a que Windows 10 está en el dominio, la tarea se simplifica completamente. Lo único que debemos hacer es reiniciar, iniciar sesión con uno de los usuarios pertenecientes al grupo de Work Folders (Andy Clayton en mi caso) e inmediatamente tendremos la característica funcional desde nuestro Explorador de archivos, carpeta de Work Folders:

image

Nota: Si el equipo de Windows 8.1 está unido al dominio tampoco habrá que configurarlo.

Cambios de Work Folders en Windows 10

Si bien la característica es muy similar con Windows 8/8.1, hay algunas novedades con respecto a Windows 10 documentadas en TechNet, y que se resumen en:

  1. La sincronización es casi inmediata: En Windows 8.1 las actualizaciones de los archivos se hacían sin tardar mucho en el servidor, pero podría tardarse hasta 10 minutos en el cliente; Windows 10, si hay buena conexión, no esperará tanto para efectuar los cambios localmente.
  2. Integración con Enterprise Data Protection (EDP): EDP es una característica que, hasta la fecha, aún se encuentra en desarrollo, aunque ya se puede ir probando. Básicamente, EDP se encarga de cifrar archivos y permitir utilizar solo aplicaciones de confianza para tratar estos archivos, además de brindar borrado remoto desde System Center Configuration Manager o una plataforma MDM. Work Folders podrá cifrar los archivos utilizando EDP.
  3. Integración con Office 2013 y 2016: Si tenemos la suite instalada en nuestro equipo con Windows 10, podemos agregar fácilmente la carpeta de Work Folders como ubicación para Abrir y Guardar como:

    image

    Nota: Esta opción solo nos aparecerá si estamos en Windows 10.

Espero que esto sea de utilidad.

—Checho

Windows 10, versión 1511: Mensaje personalizado en la pantalla de recuperación de BitLocker

Requerimientos

  1. Entorno de dominio con ADMX actualizadas a Windows 10, versión 1511.
  2. Equipos cliente con Windows 10 PRO / Enterprise / Education, versión 1511.

Descripción

Una de las nuevas características incluidas en Windows 10, versión 1511, es la posibilidad de crear un mensaje y URL personalizado al momento de entrar en el ambiente de recuperación de BitLocker. En esta entrada explicaré cómo habilitarlo.

Creación e implementación de la directiva

En la GPO destinada para las directivas de BitLocker, hacemos clic derecho y seleccionamos Edit.

image

En la ventana de Group Policy Management Editor, navegamos hasta Computer Configuration > Policies > Administrative Templates > Windows Components > BitLocker Drive Encryption > Operating System Drives y hacemos doble clic en la plantilla de Configure pre-boot recovery message and URL.

image

En la ventana de Configure pre-boot recovery message and URL, seleccionamos Enabled para que la directiva se habilite y se pueda modificar, expandimos Select an option for the pre-boot recovery message y escogemos Use custom recovery message.

image

Lo que sigue es simplemente personalizar el mensaje que deseamos mostrarle a nuestros usuarios y hacemos clic en Apply y Ok.

image

Por último, procedemos a forzar la actualización de las directivas de grupo con gpupdate /force.

Comprobación de la directiva

Basta con reiniciar el equipo y entrar a la página de recuperación de BitLocker con la tecla ESC y veremos el mensaje personalizado:

image

Espero sea de utilidad para los que tienen implementado BitLocker sin MBAM.

Instalar aplicaciones MSI en Windows 10 versión 1511 utilizando un paquete de aprovisionamiento

En el primer post que escribí sobre Windows 10 hice referencia a la nueva herramienta de implementación llamada Imaging and Configuration Designer (ICD), que sirve para crear y compilar Paquetes de aprovisionamiento, para después desplegarlos en Windows 10.

Hoy voy a escribir sobre una nueva característica integrada en la versión 1086 del ADK para Windows 10, que consiste en crear un paquete de aprovisionamiento con uno o varios paquetes MSI, desplegarlo en un equipo con Windows 7 y quedar con todas las aplicaciones instaladas de forma automatizada.

Requerimientos

1. Descargar el último ADK para Windows 10 desde aquí:
http://go.microsoft.com/fwlink/p/?LinkId=526740 

2. Instalar la herramienta de Imaging And Configuration Designer (ICD)

image

Nota: Como recomendación, hacer la instalación en otro Windows 10.

3. Descargar los paquetes MSI de las aplicaciones a instalar.

Creando paquete de aprovisionamiento

En el equipo donde se instaló ADK, buscar desde el menú el Imaging and Configuration Desigener (ICD), clic derecho y Ejecutar como administrador.

image

En la ventana principal de ICD, hacemos clic en el botón de New provisioning package.

image

En la ventana de New project, asignamos un nombre cualquiera y clic en Next.

image

En la página de Choose which settings to view and configure, seleccionamos Common to all Windows desktop editions y clic en Next.

image

En la página de Import a provisioning package (optional), clic en Finish para terminar.

image

Una vez estemos en la ventana principal de nuestro paquete de aprovisionamiento, expandimos en la columna de la izquiera Runtime settings y seleccionamos ProvisioningCommands; expandimos DeviceContents y clic en CommandFiles.

image

En el panel central, hacemos clic en el botón Browse, cargamos el paquete MSI a instalar y hacemos clic en el botón de Add.

image

Debajo de CommandFiles nos debe aparecer el nombre del paquete agregado. Después seleccionamos CommandLine y le indicamos los parámetros de instalación; por ejemplo, para el 7Zip, que estoy agregando en la captura, el parámetro sería:

msiexec.exe /i 7z1514.msi /quiet

image

Nota: En teoría, uno debería poder instalar más de un paquete, pero el ICD solo permite especificar una sola línea de comandos hasta ahora. ¿Será bug? Trataré de averiguarlo…

Cuando terminemos, hacemos clic en el botón superior de Export y luego en Provisioning package.

image

En la página de Describe the provisioning package, cambiamos el Owner a IT Admin para priorizar, y luego clic en Next.

image

En la página de Select security settings for the provisioning package, dejamos todo como está y luego clic en Next.

image

En la página de Select where to save the provisioning package, dejamos la ubicación predeterminada y clic en Next.

image

En la página de Build the provisioning package, clic en el botón de Build para terminar.

image

Después de compilado, el asistente nos dará la ruta completa del Paquete de aprovisionamiento.

image

Recordemos que, aunque hay varios archivos en el directorio compilado, estamos interesados por el paquete con extensión .ppkg.

Instalando el Paquete de aprovisionamiento

Copiamos el paquete .PPKG creado a la máquina con Windows 10 y procedemos a ejecutarlo.

Después de aceptar el Control de cuentas de usuario (UAC), nos debe salir un mensaje similar al siguiente:

image

Hacemos clic en el botón «Sí, agregarlo» y, después de un momento, la aplicación quedará instalada y lista para usarse:

image

Nota: El tiempo de instalación dependerá mucho de la aplicación.

Espero sea de utilidad.

Atte.

Checho

[Tip]: Ejecutar el Liberador de espacio en disco de forma automatizada en Windows 10

Comentario personal

Lo sé, lo sé, he estado alejado del blog más tiempo de lo normal, pero estoy tratando de volver a retomar la actividad, pues me hace falta el aprendizaje que adquiero por aquí.

La entrada de blog

Hace algunos años, por los tiempos de Windows 8, escribí un artículo en el que enseñaba a eliminar la carpeta Windows.old, que se creaba tras realizar una actualización a Windows 8. Se habrán dado cuenta que el Liberador de espacio en disco es bastante fácil de utilizar, pero, después de todo, debe hacerse el proceso manual de seleccionar todo lo que se quiere eliminar. Así se ve la herramienta en Windows 10:

image

En Windows 10, además de eliminar archivos temporales, papelera de reciclaje, espacio usado en caché, etc., el Liberador de espacio en disco quita correctamente la compilación anterior, proceso que nos devuelve bastante almacenamiento de nuestro disco duro. Ahora, como es una tarea que debe hacerse con cierta frecuencia, he decidio buscar y compartir aquí la forma de automatizarla.

Parámetros soportados por Cleanmgr.exe

Aunque están excasamente documentados, el Liberador de espacio en disco, Cleanmgr.exe, tiene unos parámetros para guardar y cargar preferencias; basta con ejecutar:

Cleanmgr.exe /?

image

Los dos parámetros importantes para nosotros son: /SAGESET y /SAGERUN, que guardan y cargan una configuración, respectivamente. A continuación mostraré cómo debemos utilizarlos correctamente.

Guardando configuración de Cleanmgr.exe

En Windows 10 hacemos clic derecho sobre el menú de inicio y seleccionamos Símbolo del sistema (administrador).

image

En el Símbolo del sistema ejecutamos:

Cleanmgr.exe /SAGESET:5

Nota: El número «5» puede variar entre 0 y 65535, lo importante es utilizar el mismo después.

Se abrirá la ventana de Configuración de Liberador de espacio en disco. Aquí es donde debemos seleccionar todo lo que deseamos que se borre en cada ejecución de la herramienta:

image

Una vez terminemos de seleccionar nuestras configuraciones, hacemos clic en el botón Aceptar para que Windows almacene todo en el Registro.

Automatizando ejecución desde el Programador de tareas

Como la idea es que no tengamos que hacer nada manual, la mejor forma de ejecutar el Liberador de espacio en disco es a través del Programador de tareas.

Hacemos clic en el botón de Inicio, digitamos Programador de tareas y lo ejecutamos con privilegios administrativos.

image

En el Programador de tareas hacemos clic en Crear tarea básica, debajo de Acciones en el panel derecho y procedemos a nombrarla como queramos.

image

En la página de Desencadenador de tarea indicamos qué tan seguido debe ejecutarse la tarea y clic en Siguiente.

image

De acuerdo al período que hayan elegido en el desencadenador se les mostrará una ventana diferente al darle siguiente, por ejemplo, para Semanalmente se ve así:

image

Configuramos según nuestra necesidad y hacemos clic en Siguiente.

En la ventana de Acción seleccionamos Iniciar un programa y clic en Siguiente.

image

Finalmente, en la ventana de Iniciar un programa digitamos cleanmgr.exe en el cuadro de Programa o script, y /SAGERUN:5 en el cuadro de Agregar argumentos (opcional), para luego hacer clic en Siguiente.

image

Nota: Recordemos que el número en /SAGERUN debe ser el mismo puesto en /SAGESET, de lo contrario el Liberador de espacio en disco cargará diferentes configuraciones.

En la ventana de Resumen confirmamos que todo esté bien y hacemos clic en Finalizar.

image

¡Todo listo! El Liberador de espacio en disco se ejecutará de acuerdo al período que hayamos establecido, y no tendremos que preocuparnos por seleccionar qué deseamos limpiar.

Nota final: Para los que estén interesados, el Liberador de espacio en disco guarda las configuraciones en diferentes subclaves de registro, que están en:

HKLMSOFTWAREMicrosoftWindowsCurrentVersionExplorerVolumeCaches

En cada una de las opciones que se escogieron, guarda un valor llamado StageFlags# con el valor de 2, donde # equivale al número escogido en /SAGESET.

Espero sea de utilidad y vuelva pronto con más aportes.

Atte.

Checho

Realizar un In-Place Upgrade desde Windows 7/8.1 a Windows 10 con MDT 2013 Update 1

Después de un pequeño descanso, quiero retomar la actividad en el blog compartiendo una de las características más esperadas sobre MDT 2013 Update 1: La posibilidad de realizar un In-Place Upgrade a Windows 10.

Para entrar en contexto, el In-Place Upgrade, o Actualización en sitio, es la posibilidad de realizar una actualización a Windows 10 conservando archivos, configuraciones y aplicaciones. Lo más interesante, es que se puede realizar desde Windows 7, 8 y 8.1.

La última actualización de Microsoft Deployment Toolkit, a parte de tener soporte nativo para Windows 10, implementa una nueva secuencia de tareas para realizar esta actualización fácilmente y de forma automatizada. En este artículo explicaré paso a paso cómo podemos realizar esta actualización en nuestro entorno MDT.

Requerimientos

1. Obtener un medio de instalación de Windows 10. Pueden descargar los archivos de instalación utilizando la herramienta de creación de medios:
https://www.microsoft.com/en-us/software-download/windows10

*Nota: Si tienen licenciamiento por volumen, es mucho mejor.

2. Descargar el ADK para Windows 10 desde aquí:
http://download.microsoft.com/download/8/1/9/8197FEB9-FABE-48FD-A537-7D8709586715/adk/adksetup.exe

3. Descargar MDT 2013 Update 1 desde aquí:
http://www.microsoft.com/en-us/download/details.aspx?id=48595

4. Instalar y configurar tanto el ADK como el MDT en el servidor que se haya habilitado para esto. El proceso para sigue siendo el mismo que en versiones anteriores. En este artículo explico cómo hacerlo:
http://social.technet.microsoft.com/wiki/contents/articles/23886.instalacion-y-configuracion-basica-de-microsoft-deployment-toolkit-mdt-2013-es-es.aspx

*Nota 1: En el artículo de Wiki hago referencia a la versión anterior del ADK y MDT. Solo deben remplazarlas por las actuales y seguir el resto del proceso.

*Nota 2: De aquí en adelante daré por hecho que configuraron todo lo referente al MDT, pues ya está explicado tanto en el Wiki como en anteriores entradas en mi blog.

Workaround para algunos bugs de MDT

A pesar de que MDT 2013 Update 1 se lanzó dos veces, el producto tiene varios bugs su funcionamiento, así que es necesario arreglarlos después de haber creado el recurso compartido. A continuación, voy a enumerar lo que personalmente he hecho para que todo me funcione bien:

1. Agregar la ruta UNC en el Bootstrap.ini: Por alguna razón, el archivo Bootstrap.ini, encargado de ubicar el recurso compartido cuando se inicia el LiteTouchPE en un equipo a través de la red, no especifica la ruta UNC, así que los equipos nunca van a encontrar el Deployment Share:

image

Para corregirlo, hay que hacer clic derecho sobre el recurso compartido, ir a Properties, pestaña de Rules, clic en Edit Bootstrap.ini y agregar el UNC:

image

Después solo hay que guardar el archivo y cerrar la ventana de Properties.

2. Agregar permisos para Usuarios autenticados o usuario de servicio en las opciones compartidas: MDT crea el Deployment Share, lo comparte, pero agrega solo al CREATOR OWNER en los permisos de la carpeta compartida y eso representa un problema cuando se va a acceder a él a través de la red.

Es necesario entonces agregar el grupo de Authenticated Users, o un usuario de servicio específico y darle permisos de lectura:

image

3. Asignar permisos de seguridad al usuario de servicio y usuarios autenticados: Al igual que en lo anterior, la parte de permisos de seguridad se le asigna por el MDT solo a SYSTEM y a los Administradores locales. Es necesario agregar el usuario de servicio con el que estamos manipulando el MDT y darle control total:

image

Adicional a esto, los usuarios autenticados deben poder leer y ejecutar el contenido, si es que deseamos que la migración la pueda hacer cualquier usuario de forma independiente. Todo quedaría así:

image

Agregando sistema operativo

Ya con todo listo, el primer paso es insertar el medio de instalación de Windows 10, o copiar los archivos a una carpeta local y agregar el sistema operativo. Para esto, seguimos los siguientes pasos:

1. Expandimos nuestro recurso compartido en el MDT, clic derecho sobre Operating Systems y clic en Import Operating System.

image

2. En la página OS Type del asistente, seleccionamos Full set of source files y Next:

image

3. En la página de Source, hacemos clic en el botón Browse, indicamos la unidad o carpeta donde están los archivos de instalación y clic en Next:

image

4. En la página de Destination, indicamos un nombre en el cuadro de texto sin espacios que describa la imagen y clic en Next:

image

*Nota: También pueden dejar el nombre como está y debería funcionar.

5. En la página de Summary, clic en Next para iniciar. El proceso puede tardar unos minutos:

image

6. Cuando el asistente termine, clic en el botón Finish de la página Confirmation.

image

Creando y configurando Secuencia de Tareas

Nuestro siguiente paso, es crear la Secuencia de Tareas que se encargará de gestionar el proceso de actualización en las máquinas clientes. Para eso, procedemos con estos pasos:

1. Clic derecho en el nodo de Task Sequences y New Task Sequence:

image

2. En la página de General Settings, indicamos un ID, nombre y opcionalmente una descripción de nuestra secuencia de tareas y clic en Next:

image

3. Aquí es donde entra la magia… en la página de Select Template, debemos escoger la nueva plantilla llamada Standard Client Upgrade Task Sequence y clic en Next:

image

4. En la página de Select OS, escogemos la edición que hayamos agregado de Windows 10 y clic en Next:

image

5. En la página de Specify Product Key, dejamos la opción predeterminada y clic en Next:

image

6. En la página de OS Settings, indicamos información de la empresa y clic en Next:

image

7. En la página de Admin Password, decidimos si indicamos o no contraseña de administrador y clic en Next:

image

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

9. En la página de Confirmation, clic en Finish.

Actualizando recurso compartido

Por último –de cara al MDT-, hacemos clic derecho sobre nuestro recurso compartido y seleccionamos Update Deployment Share:

image

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

image

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

El proceso iniciará y MDT empezará a crear las imágenes de preinstalación:

image

En la página de Confirmation, clic en Finish para terminar.

Realizando actualización desde Windows 7/8/8.1

El paso final es proceder con el In-Place Upgrade, sea desde Windows 7, 8 u 8.1. Nos sirve la misma secuencia de tareas, desde que estemos actualizando la misma edición (PRO en este caso).

Para este post, tengo un equipo con Windows 7 Pro con sus respectivos usuarios, configuraciones y aplicaciones:

image

*Nota: Para escenarios PRO, y donde no se está usando medio por volumen, es primordial que el equipo esté activado.

Lo primero que debemos hacer, es ingresar a la carpeta de Scripts de nuestro recurso compartido; en mi caso sería: \SRVMDT1WinSide$Scripts

image

Una vez conectados al recurso, ejecutamos el BDD_Autorun.wsf para iniciar nuestro asistente:

image

En la ventana de Auto-Run Windows Deployment, clic en Aceptar:

image

Nuestro asistente de instalación empezará y nos llevará a la página de Task Sequence. Allí debemos seleccionar la secuencia creada en los pasos anteriores y clic en Next:

image

En la página de Credentials, ingresamos el usuario y contraseña adecuadas para interactuar con el recurso compartido y clic en el botón de Next:

image

*Nota: Lo ideal aquí es utilizar el usuario de servicio al que le dimos permisos completos sobre el recurso compartido.

En la página de Ready, clic en el botón Begin:

image

De aquí en adelante veremos la ventana del MDT que guiará todo el proceso de actualización:

image

La demora en el proceso dependerá mucho de las capacidades del equipo, red y qué tanto hay para migrar. Lo interesante es que ya no es necesario interactuar más, solo dejar que el MDT se encargue del trabajo.

*Nota: Habrá varios reinicios durante el proceso, pero no debemos preocuparnos a menos de tener un mensaje de error; en ese caso, MDT intentará hacer rollback al sistema base que estaba instalado.

Cuando todo termine, debemos estar nuevamente en la pantalla de inicio de sesión, pero esta vez desde Windows 10:

image

Al ingresar y después de aceptar el mensaje final del asistente de MDT, tendremos nuestro nuevo escritorio listo para trabajar:

image

Espero sea de utilidad.

Checho

Implementar el Modo Empresa para dirigir los sitios de Microsoft Edge a Internet Explorer en Windows 10

Hace unos días escribí un post respecto a la nueva característica de Microsoft Edge, en donde documenté algunos argumentos sobre lo que personalmente creo, es un bug. Dos de las tres formas disponibles para que funcione la característica tienen problemas, pero finalmente pude utilizar la tercera para que se implemente sin inconvenientes, así que decidí crear este nuevo post.

La característica de Modo Empresa o Enterprise Mode en inglés, tiene como objetivo emular IE7 e IE8 dentro de IE11 cuando se trabaja con Internet Explorer, pero además de dirigir las páginas a que se abran con Internet Explorer cuando se implementa para Microsoft Edge. En otras palabras, nosotros creamos una cantidad de sitios que Edge leerá y los dirigirá a IE una vez el usuario intente abrirlos.

A continuación, pasaré a describir paso a paso cómo podemos implementar esta sencilla solución en nuestra organización.

Requerimientos

1. Tener un entorno de dominio.

2. Tener actualizadas las Plantillas Administrativas (ADMX) para Windows 10 en uno de los controladores de dominio. La siguiente KB de Microsoft explica cómo:
https://support.microsoft.com/en-us/kb/3087759

2. Servidor 2012 R2 de preferencia, unido al dominio y en el que se vaya a instalar y configurar el IIS.

3. Crear en el servidor los directorios EMED en la partición de Windows, adentro una llamada Root, y dentro de esta creamos otra llamada List:

image

Si quieren automatizar el proceso, pueden ejecutar desde una ventana de PowerShell con privilegios elevados lo siguiente:

New-Item C:EMEDRootList -Type Directory

image

*Nota: Terminará siendo el mismo resultado. Las carpetas no tienen que llamarse de la misma forma; yo utilizaré estos nombres de referencia para el resto del post.

4. Descargar e instalar en el servidor la herramienta de Enterprise Mode Site List Manager. La descargan desde aquí: http://www.microsoft.com/en-us/download/details.aspx?id=42501

5. Equipo técnico con Windows 10 unido al dominio, donde se hará la prueba.

Creando y configurando sitio IIS

En el servidor destinado para IIS, abrimos el Server Manager, clic en el panel izquierdo de Dashboard y luego en Add roles and features:

image

En la página de Before you begin, clic en Next:

image

En Select installation type, dejamos la selección predeterminada y clic en Next:

image

En la página de Select destination server, nos aseguramos de estar en nuestro servidor local y clic en Next:

image

En la página de Select server roles, escogemos Web Server (IIS) y en el cuadro adicional, clic en el botón de Add Features:

image

Clic en Next cuatro (4) veces más para llegar a la página de Confirm installation selections.

En la página de Confirm installation selections, clic en el botón Install:

image

Una vez terminada la instalación, clic en el botón Close.

Hasta aquí ya tenemos nuestro servidor web, lo que sigue es crear nuestra página para alojar el XML con las páginas que Edge abrirá con Internet Explorer.

Abrimos la ventana de Ejecutar (Windows + R) y lanzamos: InetMgr.exe

image

En la ventana de Internet Information Services (IIS) Manager, expandimos el nombre de nuestro servidor, clic derecho en el nodo de Sites y seleccionamos Ad Website…

image

En la ventana de Add Website, llenamos los siguientes datos:

Site name: EMEdge

Physical path: C:EMEDRoot

Host name: Nombre completo de nuestro servidor, en mi caso: srv-dc1-vmw.winside.co

Después de esto, clic en el botón OK para crear el sitio:

image

*Nota: Tener en cuenta que el puerto especificado debe estar habilitado en el firewall.

Nuestro sitio estará creado y listo para usarse:

image

Creando y agregando lista de compatibilidad al IIS

Nuestro siguiente paso será crear nuestra lista de compatibilidad, configurada para que Microsoft Edge la entienda y administre correctamente los sitios que debe ejecutar con IE.

En el mismo, ejecutamos el Enterprise Mode Site List Manager instalado desde los requerimientos desde el escritorio o Inicio.

En la ventana del Site List Manager, hacemos clic en el botón Add:

image

En la ventana de Add new website, escribimos la dirección de la página, una descripción si queremos, nos aseguramos de tener seleccionado Open in IE y clic en Save:

image

*Nota: En la parte de Launch in, podemos aprovechar para establecer diferentes modos de compatibilidad en Internet Explorer; por ejemplo, escoger que emule IE8 o algún modo de documentación inferior. En mi caso yo solo quiero que se abra con IE, así que puse el Default Mode.

Repetimos el mismo procedimiento hasta que hayamos agregado todos los sitios a la lista:

image

Hacemos clic en el menú File y luego Save to XML:

image

Navegamos hasta C:EMEDRootList, asignamos el nombre de Sites.xml y clic en Save:

image

Para verificar que todo haya quedado bien, debemos acceder al sitio IIS agregando la ruta para el XML que sería: /List/Sites.xml. En mi caso quedaría:

http://srv-dc1-vmw.winside.co/List/Sites.xml

Recordemos que el nombre se lo dimos al momento de crear el sitio. Debemos ver entonces todo el XML que leerá nuestros equipos clientes:

image

*Nota: Recordemos que el nombre será diferente para cada uno; si el XML no se ve correctamente, deben verificar que la dirección esté correcta.

Cuando el sitio esté comprobado, copiamos la dirección completa para los siguientes pasos y cerramos el IIS Manager.

Creando la directiva de grupo

Nuestro último paso consiste en crear la directiva de grupo que forzará a que Microsoft Edge lea el XML creado previamente, para abrir esos sitios con Internet Explorer.

En mi dominio de laboratorio, tengo una OU creada explícitamente para los equipos con 10; de esta forma puedo probar las directivas sin afectar a los otros equipos:

image

En algún controlador de dominio, o desde un equipo donde podamos acceder al Group Policy Management, creamos una nueva GPO para Microsoft Edge; en mi caso la llamaré Enterprise Mode for Edge y la enlazaré a la OU de WIN10_Computers:

image

Editamos la directiva de grupo y navegamos hasta:

Computer ConfigurationPoliciesAdministrative TemplatesWindows ComponentsMicrosoft Edge

*Nota: Recuerden que deben actualizar las Plantillas Administrativas (ADMX) si no están en Windows Server 2016.

En el panel derecho, hacemos doble clic sobre la plantilla: Allows you to configure the Enterprise Site List

image

En la ventana de la plantilla, seleccionamos Enabled y en la parte inferior, en el cuadro de texto debajo de Type the location (URL) of your Enterprise Mode IE website list, ingresamos la URL creada y copiada en los pasos anteriores. En mi caso, quedaría así:

image

Hacemos clic en el botón OK para terminar.

*Nota: Recordemos que la URL no será la misma para ustedes, pues todo depende del nombre del servidor y dominio.

¡Todo listo! Nuestros siguientes pasos son finalmente en el equipo cliente con Windows 10.

Probando la directiva en Windows 10

En nuestro equipo Windows 10, cerramos Microsoft Edge y procedemos a actualizar las directivas de grupo ejecutando: gpupdate /force

image

Acto seguido, procedemos a abrir Microsoft Edge, digitamos alguno de los sitios que debe leer de la directiva y, si todo sale bien, deberá mostrar un mensaje de advertencia y ejecutar Internet Explorer con el mismo sitio.

image

Esto mismo pasará con todos los sitios que se hayan agregado al XML.

Probablemente se pregunten: ¿Qué pasa si el equipo está por fuera de la red y no puede acceder al XML? Pues bien, cada que Microsoft Edge puede leer el XML correctamente mientras accede a los diferentes sitios, crea un caché local, del que aún no puedo evidenciar, pero además una lista con los sitios que están en el XML y se han abierto por lo menos una vez en la sub-clave:

HKEY_CURRENT_USERSOFTWAREClassesLocal SettingsSoftwareMicrosoftWindowsCurrentVersionAppContainerStorage
microsoft.microsoftedge_8wekyb3d8bbweMicrosoftEdgeNeedIE

image

El valor en uno (1), abre automáticamente Internet Explorer, mientras que en cero (0) solo muestra el mensaje en Edge pero no ejecuta IE 11. Cabe aclarar que si uno crea la entrada manualmente no funciona, por lo que hay algo más que sucede internamente cuando toma la lista desde el XML; lamentablemente no he logrado encontrar más detalles.

*Nota: Si logro encontrar más, crearé un post específicamente de esto en un futuro.

En este orden de ideas, Edge seguirá abriendo los sitios con IE que ya haya creado en el Registro; cuando vuelva a tomar la directiva y el usuario ingrese a otro sitio agregado, el navegador escribirá la entrada en el Registro para la próxima vez que acceda con el caché.

Espero haya sido de utilidad.

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

Saludos.

Checho

[¿Bug o no?] La lista empresarial no reconocida por Microsoft Edge en Windows 10, ProcMon, ProcExp y su solución

En Windows 8.1 Update, Internet Explorer 11 introdujo una nueva característica llamada: Modo Empresa, que básicamente permite emular gran parte de Internet Explorer 8 con el fin de que las aplicaciones antiguas, que solo funcionaban en esta versión del navegador, se pudieran utilizar en IE11 y de esta forma se facilitara la migración de sistema operativo. Debido a la buena acogida y realimentación que ha tenido la característica, se integró otro modo de emulación para Internet Explorer 7 y Modos de Documentación adicionales que por supuesto ampliaba más la compatibilidad hacia atrás. Pueden ver un poco más sobre esta característica en el artículo que escribí para el blog de Tulpep

Windows 10, a parte de seguir soportando Internet Explorer 11, tiene un foco específico en su nuevo navegador llamado Microsoft Edge, desarrollado desde cero y muy enfocado al consumidor soportando los últimos estándares, mucho más rápido que otros navegadores del mercado y sobre todo fácil de utilizar:

2015-08-12_17-57-59

En el lado empresarial, Edge tiene una cantidad de Directivas de Grupo, y una de las características más interesantes es que la herramienta de Microsoft para crear la lista empresarial del Modo Empresa se ha actualizado, con el fin de indicarle a Microsoft Edge qué sitios debe abrir obligatoriamente con Internet Explorer, así se ejecuten desde el nuevo navegador. Es una característica muy prometedora, pero lamentablemente no me logró funcionar como debía, así que en vez de mostrarles cómo configurarla, resulté escribiendo este post exponer lo que hasta ahora no sé si se puede catalogar como bug o no.

*Nota: Una vez esté completamente seguro que la característica se puede configurar sin necesidad de hacer lo que expondré a continuación, intentaré sacar el tiempo para escribir un artículo paso a paso concentrándome solo en eso y no en el problema como en esta ocasión.

El problema

Básicamente, existe ahora una directiva de grupo para Microsoft Edge llamada: Permite configurar la lista de sitios empresariales; utiliza un XML creado con la herramienta de Enterprise Mode Site List Manager para generar una lista de sitios que Edge debe obligatoriamente abrir con Internet Explorer.

2015-08-12_18-08-00

La directiva está ubicada en:
Configuración de Equipo/UsuarioPlantillas AdministrativasComponentes de WindowsMicrosoft Edge.

Yo, con toda la expectativa, descargué la actualización de la herramienta Enterprise Mode Site List Manager desde el sitio de Microsoft y agregué el sitio de la empresa en que trabajo (tulpep.com) para probar la característica; lo único diferente a lo que se hacía en Internet Explorer, es que ahora se marca una casilla de Open in IE para que Edge sepa que debe pasárselo a su antecesor. Así se ve:

2015-08-12_18-16-52

Luego de esto, guardé el XML como Sitios.xml y lo guardé en C:Sitios. En la directiva debía especificar esta ruta:

image

Lo siguiente era solo actualizar las directivas (GPUPDATE), abrir Edge e ingresar el sitio para que hiciera la redirección, pero desafortunadamente nada pasó y el navegador abrió la página común y corriente:

image

Aquí empecé a preguntarme: ¿Qué pasó? ¿Por qué no abrió con IE? ¿Qué hice mal? Procedí entonces a crear otra vez el XML, actualizar la directiva a incluso reiniciar Windows, pero ningún resultado positivo. Pude también escalar el tema a un primer contacto del equipo de Microsoft Edge, pero sin solución y por ese lado todavía estoy esperando si llego a instancias más altas.

Como no quería permanecer de brazos cruzados, decidí ir un poco más allá y tratar de diagnosticar el problema yo mismo.

La causa

Para saber porqué la lista empresarial no estaba funcionando con Edge, debía tratar de entender un poco más qué estaba sucediendo por debajo, y para eso no hay otro camino más fructífero que recurrir a las herramientas de Sysinternals.

Lo que hice fue cerrar Edge, ejecutar Process Monitor, limpiar la primera traza con CTRL + X, lanzar Edge, entrar a Tulpep.com y después de que no sucediera el comportamiento esperado volví a Process Monitor para detenerlo y empezar a analizar los resultados.

Como no sabía realmente por dónde empezar, recurrí al camino más lógico y era ver qué estaba sucediendo con el archivo Sitios.xml. Esto fue lo primero que encontré:

image

Edge estaba consultando el contenido de un valor llamado SiteList y que estaba ubicado en la sub-clave:
HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftMicrosoftEdgeMainEnterpriseMode

Esta sub-clave en realidad no es nueva, pues a diferencia del nombre (MicrosoftEdge), es exactamente la misma que utiliza Internet Explorer al activar el Modo Empresa. Ese valor de registro contiene la ruta al XML que debe utilizar el navegador para leer los sitios y su respectiva configuración; en otras palabras, es el reflejo de la directiva que se creó.

Para este caso, el resultado era SUCCESS, así que podía acceder a la ruta del XML:

image

Con esto pude asegurarme que la directiva se estaba creando correctamente y el navegador sí buscaba el XML… ¿por qué no usaba la configuración entonces?

Seguí buscando en Process Monitor por los resultados que arrojara el XML, pero obviando ya las operaciones sobre la sub-clave de registro mencionada, pues estaba correcta. Para mi fortuna, encontré lo que sería la clave de todo esto:

image

Como ven, el proceso de Microsoft Edge estaba tratando de realizar una operación a nivel de sistema de archivos (CreateFile) con el XML, pero el resultado era ACCESS DENIED; es decir, por alguna razón el navegador no estaba pudiendo acceder libremente al archivo.

Debido a que la operación CreateFile en Process Monitor no siempre refleja el nombre, es decir, crear un archivo, era necesario ver un poco más de detalles para entender qué intentaba hacer así que procedí a hacer doble clic en el evento para ver las propiedades:

image

La disposición era de Open, así que Edge estaba intentando abrir el archivo y recibía un acceso denegado. ¿Por qué?

Obviamente, lo primero que pensé es que mi usuario no tenía permisos NTFS para acceder al archivo, así que fui a las propiedades de la carpeta Sites que había creado y agregué explícitamente mi usuario con todo el control:

image

Lo siguiente era cerrar Edge, volverlo a ejecutar e intentarlo otra vez. Con toda la esperanza lo hice, pero desafortunadamente el navegador seguía abriendo la página en vez de enviarla a Internet Explorer.

Volví entonces a reiniciar Process Monitor y reproducir el comportamiento para saber qué resultados obtenía; para mi mala fortuna, aún era ACCESS DENIED:

image

Este fue el momento más confuso para mi, pues no podía entender cómo dándole permisos explícitos al usuario aún recibía el acceso denegado… entonces recordé algo que Windows integró desde los tiempos de Vista: ¡Los niveles de integridad!

Un nivel de integridad hace parte del mecanismo de integridad que tiene el sistema operativo, y se asigna a procesos de aplicaciones o a objetos (como archivos, carpetas, etc) para representar su confianza. Desde Windows Vista, han existido 6 niveles de integridad: Untrusted, Low, Medium, High y System; siendo Untrusted el más bajo y por supuesto System el más alto de todos.

*Nota: Normalmente interactuamos solo con: Low, Medium, High y System.

Básicamente, un proceso no podría llegar a leer o modificar un objeto que tenga un nivel de integridad superior. El caso más concreto lo tiene Internet Explorer cuando Windows tiene activado el UAC y el Modo Protegido no se ha bajado; de esta forma, el navegador siempre está ejecutándose con nivel de integridad Low, así que nunca podrá por sí solo ejecutar o guardar archivos maliciosos en directorios protegidos de Windows, sino en sus propios directorios temporales.

Es importante tener en cuenta que un proceso podría escribir sobre un objeto que tenga nivel de integridad igual o menor que él; es decir, System puede escribir en todos, pero Medium solo podría sobreponerse a un objeto que tenga el mismo nivel o que esté en Low.

Este mecanismo de seguridad no es fácilmente administrable y es el sistema operativo el que se encarga de la gestión.

*Nota: Trataré, cuando mis conocimientos me lo permitan, de escribir un post completo para explorar los mecanismos de integridad en Windows con ejemplos prácticos.

Volviendo al caso, yo supuse que Microsoft Edge estaba corriendo con un nivel de integridad Low y eso explicaría por qué no podía leer desde un directorio de Windows o de usuario que tiene Medium. Para asegurarme, ejecuté Process Explorer, habilité la columna de Integrity Level y procedí a abrir Edge para investigar para encontrarme con esto:

image

Tal como ven en la captura, el nivel de integridad (el último dato de la derecha), era nada más y nada menos que AppContainer. En principio no entendía mucho, pero después de un poco de búsqueda, encontré que las aplicaciones de interfaz moderna corren todas con este nivel de integridad especial y, al parecer, es un poco más bajo que Low.

El explorador de archivos ejecuta por su parte con un nivel de integridad Medium:

image

A pesar de que es una característica, parece que Microsoft Edge no sabe cómo lidiar con su propio dilema de seguridad, pues a diferencia de IE, no es posible desactivar el modo protegido para que el nivel de integridad sea Medium también.

En un principio pensé que estableciendo manualmente el nivel de integridad tanto de la carpeta como del archivo  Low podría hacerlo funcionar, pero al parecer debe ser explícitamente a AppContainer para que sea equivalente.

La solución

Yo no quería rendirme así, tan cerca del objetivo. Después de pensar por un buen rato, me di cuenta que naturalmente Microsoft Edge requería escribir en al menos un directorio del sistema operativo, así que esa carpeta muy seguramente tenía el mismo nivel de integridad y por ende podría leer todos los archivos que residieran ahí sin problemas.

Para encontrar el directorio, volví a Process Monitor y empecé a buscar por lo más básico que pensé, y era alguna carpeta que se llamara Temp, obviamente a nivel de sistema de archivos y que el proceso fuera MicrosoftEdge.exe. Esto fue lo que encontré:

image

Existía un directorio llamado Temp ubicado en:
C:UsersAndyAppDataLocalPackagesMicrosoft.MicrosoftEdge_8wekyb3d8bbweAC

Supe que este era el indicado, puesto que en las propiedades el Acceso Deseado (Desired Access) era Generic Read/Write, Delete, además de Create como Disposition y todo había tenido un resultado de SUCCESS. En otras palabras, Microsoft Edge tenía total libertad de leer, escribir y eliminar archivos en ese directorio.

Para ver que mi teoría era cierta, hice lo siguiente:

1. Copié el archivo Sitios.xml que le indicaba los sitios a Edge que debía mandar para que se abrieran con Internet Explorer en la ruta ya mencionada:

image

2. Acto seguido, actualicé la directiva de grupo para que apuntara al XML en la nueva ruta:

image

3. Actualicé nuevamente las directivas locales ejecutando: gpudate /force

image

4. Por último, cerré completamente Edge.

Para mi gran fortuna, cuando abrí nuevamente Edge y le introduje el sitio Tulpep.com, el milagro sucedió:

image

¡La característica esta funcionando como debía ser! Todos los sitios que estaban en el XML se abrían de forma automática con IE cuando se lanzaban desde Microsoft Edge.

Desafortunadamente con rutas de red no logré hacerlo funcionar, así que por ahora la única forma es tener el XML local en un directorio que Microsoft Edge pueda utilizar libremente.

Las preguntas para todos los que se tomen el trabajo de leer esto: ¿Qué opinan? ¿Creen que sea un bug?

¡Comentarios bienvenidos!

*Nota: Si en algún momento tengo respuesta oficial por parte de Microsoft, actualizaré la entrada para hacérselos saber.

Checho

Aplicar un Paquete de Aprovisionamiento a una imagen de Windows 10 offline utilizando DISM

Hace unos días mostré cómo podíamos crear y aplicar un Paquete de Aprovisionamiento a un equipo con Windows 10, de esta forma podríamos configurar un dispositivo fácilmente y sin necesidad de realizar instalación en limpio. También mencioné que existían diferentes formas de implementar estos paquetes, así que hoy quiero mostrar una manera un poco más técnica utilizando la herramienta DISM incluida en el ADK.

Para aplicar Paquetes de Aprovisionamiento con DISM, es necesario acceder a la imagen sin conexión; es decir, desde un Windows PE, o bien montando el .WIM en un directorio para después trabajar con él. El paquete se aplicará después de realizar la instalación del sistema operativo.

Requerimientos

1. Equipo técnico donde se vaya a realizar el procedimiento.

*Nota: Para este post, utilizaré un equipo técnico con Windows 10.

2. Crear una carpeta en la raíz ‘C’ llamada 10. Es decir: C:10.

3. Copiar los archivos de instalación de Windows desde el medio físico o virtual a la carpeta.

4. Crear una carpeta en la raíz ‘C’ llamada Montar. Es decir: C:Montar.

5. Descargar e instalar las herramientas de implementación incluidas en el ADK desde aquí:
Download the Windows ADK for Windows 10

6. Crear un paquete de aprovisionamiento sin cifrarlo. Para crearlo, ver este artículo:
http://geeks.ms/blogs/checho/archive/2015/08/03/compilar-y-aplicar-un-paquete-de-aprovisionamiento-a-un-equipo-con-windows-10-utilizando-windows-icd.aspx

7. Copiar el Paquete de Aprovisionamiento a una carpeta llamada Paquetes en ‘C’. Es decir, C:Paquetes

6. Equipo de referencia donde se vaya a probar la instalación y el paquete aplicado.

Montando la imagen de Windows 10

En el equipo técnico, clic en la pantalla o menú de inicio, buscamos PowerShell, clic derecho y Ejecutar como administrador:

2015-08-10_14-46-36

En la consola de PowerShell, ejecutamos la siguiente línea para montar la imagen:

Mount-WindowsImage -ImagePath "C:10sourcesinstall.wim" -Index 1 -Path "C:Montar"

2015-08-10_14-49-37

Implementando el Paquete de Aprovisionamiento

Con la imagen montada, ya podemos aplicar libremente uno o más Paquetes de Aprovisionamiento creados con Windows ICD.

Para este caso, utilizaré uno muy similar al que mostré en el primer artículo sobre Windows ICD. La diferencia es que no estará cifrado y no implementará ninguna directiva. Como mencioné en los requerimientos, es necesario copiar el paquete a la carpeta C:Paquetes.

2015-08-10_15-18-50

Para agregar el paquete a la imagen, ejecutamos desde PowerShell:

Dism /Image:C:Montar /Add-ProvisioningPackage /PackagePath:C:PaquetesBase_Configurations.ppkg

2015-08-10_15-22-04

*Nota: El resultado de DISM debe ser que el comando se completó satisfactoriamente.

Como dato curioso, observemos algunas de las cosas que pasan al ejecutar el comando:

2015-08-10_15-47-21

Como ven, lo primero que sucede en la carpeta donde está montada la imagen, es que DISM valida la existencia de una carpeta llamada Recovery, pero al no encontrarla (NAME NOT FOUND), la crea. Después de esto, hace lo propio con la carpeta Customizations que debe estar dentro de la carpeta Recovery; finalmente, copia el paquete de aprovisionamiento dentro de la carpeta Customizations. La ruta completa es: RecoveryCustomizations.

De acuerdo a la documentación oficial de Microsoft, todos los paquetes que estén en esta carpeta se ejecutará después del primer arranque de Windows, conocido como OOBE. En ese orden de ideas, así este paquete esté agregado desde la imagen, muy seguramente se aplicará ya cuando el sistema operativo esté instalado e iniciando por primera vez.

Tal cual dije antes, se pueden aplicar más de un paquete de aprovisionamiento a una imagen, aunque debe hacerse uno por uno.

Desmontando y guardando

Una vez hayamos agregado los Paquetes de Aprovisionamiento, ejecutamos:

Dismount-WindowsImage –Path “C:Montar” –Save

2015-08-10_16-10-30

Después de completado el comando, cerramos la consola de PowerShell.

Creando la imagen ISO

Desde el menú o pantalla de inicio, buscamos Deployment and Imaging Tools Environment, clic derecho y Ejecutar como administrador:

2015-08-10_16-14-29

Desde la consola, ejecutamos lo siguiente para crear una imagen ISO que nos sirva tanto en equipos con BIOS UEFI, como en Legacy BIOS:

Oscdimg -bootdata:2#p0,e,bC:10bootetfsboot.com#pEF,e,bC:10efimicrosoftbootefisys.bin -u1 -udfver102 C:10 C:Win10_with_packages.iso

2015-08-10_16-18-15

*Nota: Les recomiendo que copien y peguen el comando para evitar errores. Recuerden que está basado en los directorios que especifiqué en los requerimientos; si tienen otros, deben modificar el comando para que funcione.

Tendremos finalmente nuestra imagen creada:

2015-08-10_16-19-38

Instalando y probando

La instalación de Windows se hace común y corriente. Si todo sale bien, después de pedir las configuración rápida, se le debe indicar un usuario y luego iniciará con todos los cambios aplicados con el paquete de aprovisionamiento:

Nombre y unión al dominio:

2015-08-10_16-42-39

Usuario de soporte creado:

2015-08-10_16-43-01

¡Terminamos! Así como lo expliqué en el primer artículo sobre los Paquetes de Aprovisionamiento, estas configuraciones pueden ir más allá e integrar directivas MDM, así como controladores, actualizaciones y aplicaciones.

Espero sea de utilidad.

Saludos.

Checho

Iniciar sesión en Windows 10 utilizando credenciales de Azure Active Directory

Windows 10 llegó con una serie de características que cubren varios escenarios, desde la experiencia de usuario, hasta fuertes e interesantes mecanismos de seguridad. Como era de esperarse, con todo este cuento de la nube, el sistema operativo no se podía quedar atrás y ahora nos permite unirnos a Azure Active Directory; esto nos permite utilizar nuestras credenciales de Azure (Intune, Office 365) para iniciar sesión en el sistema operativo.

Entre las ventajas de unir los equipos a Azure Active Directory (AD), está la posibilidad de sincronizar configuración de Windows, fondos de pantalla, entre otras cosas; acceder a recursos en la nube y lo más significativo para el IT Pro: administrar equipos desde la nube utilizando soluciones MDM (como Windows Intune) en vez de utilizar Directivas de Grupo. Naturalmente, no existen tantas directivas, pero es bastante eficiente.

Debido a que Azure Active Directory es todo un tema aparte así que no entraré en detalle, pero sí mostraré a continuación cómo podemos unir nuestro Windows 10 y aprovechar esta nueva característica.

Requerimientos

1. Cuenta de Microsoft Azure.

2. Crear un directorio, junto con uno o más usuarios en Azure Active Directory.

3. Equipo con Windows 10 PRO / Enterprise.

*Nota: Pueden ver más información sobre los Directorios de Microsoft Azure aquí:
https://msdn.microsoft.com/es-es/library/azure/jj573650.aspx

Habilitando la unión de dispositivos a Azure AD

Lo primero que debemos hacer es permitir que los dispositivos se puedan unir a Azure AD. Para esto, ingresamos con una cuenta administrativa al portal de Microsoft Azure, vamos al nodo de Azure Active Directory, escogemos nuestro directorio y hacemos clic en el nodo de Configurar:

2015-08-04_20-09-56

*Nota: Obviamente el nombre del directorio será diferente.

En la parte inferior de Dispositivos, hacemos clic en el botón de TODO al lado de: Los usuarios pueden unir dispositivos a Azure AD.

2015-08-04_18-48-17

Para conservar los cambios, en la parte inferior se nos habilitará el botón de Guardar:

2015-08-04_20-17-04

Eso es todo lo que hay adicional dentro de Azure, lo siguiente va por cuenta de Windows 10.

Uniendo Windows 10 a Azure AD

Iniciamos sesión en nuestro Windows 10 que deseamos conectar a Azure AD, hacemos clic en el botón de Inicio y abrimos Configuración:

2015-08-04_20-21-12

En la aplicación de Configuración, clic en el nodo de Sistema:

2015-08-04_20-23-46

En Sistema, clic en Acerca de y en el panel derecho, clic en el botón Unirse a Azure AD:

2015-08-04_20-25-02

En la página de Unirse a Azure AD, clic en el botón Continuar:

2015-08-04_20-28-40

En la página de Vamos a iniciar su sesión, ingresamos nuestras credenciales de Azure AD (Office 365/Intune) y clic en Iniciar sesión:

2015-08-04_20-30-48

Una vez Windows 10 reconozca la autenticación, aparecerá una ventana en donde debemos simplemente confirmar haciendo clic en Unirse:

2015-08-04_20-32-27

Si todo sale bien, veremos la página de Todo finalizado donde solo debemos hacer clic en Finalizar:

2015-08-04_20-33-40

En Acerca de, debemos ver ahora nuestra organización conectada:

2015-08-04_20-34-42

Nuestro siguiente paso, al igual que en una unión al dominio, es reiniciar el equipo o para el caso de Azure AD que es más flexible, solo cerrar sesión.

En la pantalla de inicio de sesión veremos ahora el “Otro usuario”; al hacer clic ahí, nos pedirá nuestra cuenta corporativa o de educación. Debemos ingresar nuestras credenciales de Azure AD e iniciar sesión:

2015-08-04_20-38-14

Windows procederá a crear una cuenta local asociada a Azure AD y nos mostrará el asistente de siempre:

2015-08-04_20-40-31

Es muy probable que veamos una página azul donde Windows nos pida configurar un PIN alternativo para iniciar sesión no solo en Windows, sino en todos los servicios de la organización. La recomendación es crearlo, pero si no están interesados, basta con hacer clic en el botón Crear PIN y luego cerrar el asistente para que se habilite el botón de Omitir por ahora:

2015-08-04_20-42-28

Ya en Windows, podemos verificar rápidamente que en efecto estamos en Azure AD ejecutando desde un símbolo del sistema: whoami.

Noten que nos indica: azureadnombre

2015-08-04_20-45-42

¡Eso es todo! Aunque la parte realmente interesante está cuando nos conectamos a una red de trabajo para ser administrados utilizando MDM, dejaré eso para otro artículo.

Espero sea de utilidad.

Saludos.

Checho