Personalizar la barra de tareas de Windows 10 con directivas de grupo

El pasado mes de mayo escribí un artículo sobre una característica bastante llamativa en Windows 10, versión 1511, que, expandiendo lo que ya se podía en Windows 8.1 Update, permitía crear un diseño parcial del menú de inicio para todos los usuarios, utilizando Directivas de grupo.

Windows 10, versión 1607, agregó otra funcionalidad más a estas características para anclar una serie de accesos predeterminados en la barra a través de Directivas de grupo y así ayudar a los administradores de infraestructura a estandarizar fácilmente las personalizaciones de usuario. En este artículo explicaré cómo podemos realizar estas personalizaciones.

Requerimientos

1. Controladores de dominio con los ADMX actualizados a Windows 10, versión 1607

2. Equipo con Windows 10, versión 1607, que sirva de referencia

3. Equipos con Windows 10 Enterprise o Education, versión 1607, en donde se implemente la directiva de grupo

Nota: esta característica no está disponible en ediciones Home y Pro.

Paso 1: configurar la barra de tareas

Estos pasos se deben realizar en el equipo de referencia, que puede estar o no unido al dominio de la empresa. Lo más importante es que si vamos a referenciar aplicaciones no integradas en Windows, estas deben instalarse también en los equipos en donde se va a desplegar la directiva.

Lo primero que hay que hacer, después de instalar las aplicaciones, si es que se requiere agregar un acceso directo, es anclar todos los accesos directos que vamos a predeterminar en los demás equipos. Basta con buscar la aplicación en el menú de inicio, hacer clic derecho y luego clic izquierdo en Anclar a la barra de tareas.

image

Para este artículo, yo anclé el Internet Explorer, Notepad++, Conexión a acceso remoto y el Símbolo del sistema.

image

Paso 2: crear y guardar el XML

El siguiente paso es crear o personalizar el XML. Microsoft provee una muestra en su documentación, así solo debemos dedicarnos a encontrar el Desktop Application Link Path adecuado para cada aplicación anclada; se utilizan dos rutas:

  • %APPDATA%\Microsoft\Windows\Start Menu\Programs
  • %ALLUSERSPROFILE%\Microsoft\Windows\Start Menu\Programs

Nota: las aplicaciones de interfaz moderna también se pueden anclar y relacionar en el XML que se crea, pero no las mostraré en el ejemplo, puesto que casi no se ve en la vida real; de hecho, las empresas tienden a bloquear estas aplicaciones.

Los accesos directos pueden estar en una u otra, por lo que toca buscarlo manualmente carpeta por carpeta. Por ejemplo, el acceso al Notepad++ está en:

%ALLUSERSPROFILE%\Microsoft\Windows\Start Menu\Programs\Notepad++\Notepad++.lnk

image

El Internet Explorer, por poner otro ejemplo, está en la ruta:

%APPDATA%\Microsoft\Windows\Start Menu\Programs\Accessories\Internet Explorer.lnk

image

Ambas rutan deben estar dentro de la etiqueta <taskbar:DesktopApp DesktopApplicationLinkPath=/> del XML, así:


<?xml version=”1.0″ encoding=”utf-8″?>
<LayoutModificationTemplate
    xmlns=”
http://schemas.microsoft.com/Start/2014/LayoutModification”
    xmlns:defaultlayout=”http://schemas.microsoft.com/Start/2014/FullDefaultLayout”
    xmlns:start=”http://schemas.microsoft.com/Start/2014/StartLayout”
    xmlns:taskbar=”http://schemas.microsoft.com/Start/2014/TaskbarLayout”
    Version=”1″>
  <CustomTaskbarLayoutCollection>
    <defaultlayout:TaskbarLayout>
      <taskbar:TaskbarPinList>
        <taskbar:DesktopApp DesktopApplicationLinkPath=”%APPDATA%\Microsoft\Windows\Start Menu\Programs\Accessories\Internet Explorer.lnk”/>
        <taskbar:DesktopApp DesktopApplicationLinkPath=”%ALLUSERSPROFILE%\Microsoft\Windows\Start Menu\Programs\Notepad++\Notepad++.lnk”/>
        <taskbar:DesktopApp DesktopApplicationLinkPath=”%ALLUSERSPROFILE%\Microsoft\Windows\Start Menu\Programs\Accessories\Remote Desktop Connection.lnk”/>
        <taskbar:DesktopApp DesktopApplicationLinkPath=”%APPDATA%\Microsoft\Windows\Start Menu\Programs\System Tools\Command Prompt.lnk”/>
       
      </taskbar:TaskbarPinList>
    </defaultlayout:TaskbarLayout>
</CustomTaskbarLayoutCollection>
</LayoutModificationTemplate>


image

Nota: la base de este XML está tomada de la documentación de Microsoft.

Después de agregar las entradas correspondientes a cada acceso directo anclado, debemos guardar el XML con cualquier nombre descriptivo y ubicaro en una ruta de red, en la que pueda acceder el controlador de dominio que creará la directiva. Para este caso, yo la ubiqué en \\DC\Resources y lo llamé TaskBarLayout1.xml.

image

Paso 3: crear y desplegar la directiva

En el controlador de dominio, después de actualizar los ADMX, creamos o editamos la GPO destinada para personalizar la barra de tareas en los equipos con Windows 10, versión 1607, y realizamos lo siguiente:

1. User Configuration > Policies > Administrative Templates > Start Menu and Taskbar

2. Doble clic en la plantilla de Start Layout

image

3. Habilitamos la directiva y escribimos debajo de Start Layout File la ruta del XML

image

4. Clic en Apply y OK para terminar

Paso 4: probar la directiva de grupo

Si todo sale bien, cuando unamos un nuevo equipo al dominio o simplemente  reiniciemos para forzar directivas de grupo, la barra de tareas debe aparecer con todos los nuevos accesos a la derecha.

Así está la barra de tareas sin aplicar la directiva:

image

Así se ve después de aplicada:

image

Parece increíble que una característica así se haya tardado tanto en llegar, ¿no creen?

Espero sea de utilidad.

Saludos,

—Checho

Explorando el «Registry Redirector» en Windows

Antes de empezar

Si no estoy mal, este es el primer artículo en el que escribiré sobre una característica interna del sistema operativo; así que pido disculpas de antemano por cualquier equivocación que tenga y por si el código que aquí expondré no es el más profesional. Dicho esto, ¡empecemos!

Windows de 32 bit en Windows de 64 bit (WOW64)

Debido a que el trabajo de «Registry Redirector» hace parte de WOW64 , es necesario dar una introducción, mas no voy a profundizar porque de esto no se trata el artículo y, a decir verdad, no tengo aún el conocimiento para exponerlo.

«Windows 32 –bit On Windows 64-bit (WOW64)» es una capa de emulación que permite ejecutar aplicaciones basadas en 32 bits en un sistema operativo de 64 bits sin que la aplicación lo llegue a percibir. WOW64 tiene una colección de DLLs en modo usuario (existe modo usuario y modo kernel) que interceptan llamadas desde y hacia un proceso de 32 bits y hace la respectiva traducción para que todo funcione en el ambiente de 64 bits.

Registry Redirector

Lo primero que hay que decir es que este es que el mecanismo que voy a pasar a describir no es nuevo, pues existe desde Windows Vista, pero aún tiene influencia en problemas relacionados a la compatibilidad de aplicaciones.

El trabajo del «Registry Redirector» es aislar las aplicaciones de 32 y de 64 bits de ciertas partes del registro con diferentes nodos  para almacenar la información. Básicamente, intercepta la llamada que hace la aplicación, sea de 32 o de 64 bits, a su respectiva ubicación lógica y la dirige a una ubicación física. Este proceso es completamente transparente para la aplicación (y para nosotros), así que las aplicaciones de 32 bits, por ejemplo, pueden seguir accediendo a sus datos como si estuvieran en un sistema base de 32 bits. Esto es para que puedan correr y convivir sin problemas.

Las subclaves que son dirigidas se guardan en la subclave de Wow6432Node; por ejemplo, todo lo que una aplicación de 32 bits intente escribir en HKEY_LOCAL_MACHINE\Software es dirigido a la subclave HKEY_LOCAL_MACHINE\Wow6432Node.

Nota: de aquí en adelante utilizaré las siglas de HKLM y HKCU para poder referirme a las claves de HKEY_LOCAL_MACHINE y HKEY_CURRENT_USER, respectivamente.

¿Cómo lo vemos en acción?

Para poder ver y entender este mecanismo, decidí escribir, con mi pobre conocimiento en C, una aplicación propuesta por la documentación oficial de Microsoft y mostrarla en este artículo, con la ayuda adicional de Process Monitor.

La aplicación

La aplicación que escribí se llama DemoApp.exe y lo que hace es tratar de abrir la subclave WinSide, ubicada en la subclave HKEY_LOCAL_MACHINE\Software. Si la subclave existe, consulta el contenido del valor predeterminado, Default, y lo muestra en consola; si no, la aplicación crea la subclave de WinSide , escribe el contenido del valor predeterminado y procede a mostrarlo en consola. 

Nota: en cada subclave que se crea siempre existe el valor de Default, que puede o no tener un contenido.

A continuación, muestro una imagen en donde trato de ilustrar las operaciones que hace la aplicación.

SNAGHTML1cd7165

La imagen anterior, aunque resume el comportamiento general de la aplicación, es fiel a la gráfica cuando el ejectuable es de la misma arquitectura que el sistema operativo instalado; sin embargo, cuando la aplicación es de 32 bit y se ejecuta en un sistema de 64, el Registry Redirector actuará sobre la subclave de HKLM\WinSide y la ubicación física cambiará, así:

SNAGHTML36a031

Esta dirección al nodo físico, como ya lo dije, es completamente transparente para la aplicación, así que el desarrollador no tiene que preocuparse realmente por este mecanismo.

El código (para los interesados)

Importante: insisto en que soy un programador novato de C, así que seguramente encontrarán errores o mejoras prácticas en mi código. ¡Cualquier aporte es bienvenido!

Lo primero que hice fue crear una serie de macros para remplazar el mensaje según esté compilada la aplicación; es decir, si ejecuto la versión compilada a 64 bits, el mensaje será «64-bit app on WINx64», de lo contrario, «32-bit app on WINx64».

#ifdef _M_AMD64

#define MSG L”64-bit app on WINx64.\n”

#else

#define MSG L”32-bit app on WINx64.\n”

#endif

Luego creé una función llamada showValue que utiliza la función RegGetValue de la API de Windows para consultar el contenido del valor Default y luego mostrarlo. La función personalizada quedó así:

/*This function receives some variables to show a registry value’s –
content, but only REG_SZ is working by now.*/
void showValue(HKEY openKeyResult, LPCWSTR regValueName, DWORD flags)
{
    //Buffer that receives the value’s data.
    WCHAR valuesData[255];
    PVOID pValuesData = valuesData; //A.K.A. pvData
    DWORD sizeOfBuffer = sizeof(valuesData); //A.K.A. pcbData
    DWORD typeOfData;

    LONG getValue = RegGetValue(openKeyResult, NULL, regValueName,
                                flags, &typeOfData, pValuesData,  &sizeOfBuffer);

    if (getValue != ERROR_SUCCESS)
    {
        wprintf(L”Error getting the value. Code: %li\n”, getValue);
    }
    else
    {
        switch (typeOfData)
        {
        case REG_SZ:
            wprintf(L”Value’s data: %s\n”, (PWCHAR)pValuesData);
            break;

        default:
            wprintf(L”No other types are allowed.\n”);
            break;
        }
    }

}

Nota: RegGetValue está documentada en la página oficial de MSDN:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms724868(v=vs.85).aspx

La función recibe una variable openKeyResult, que es el handle a la subclave abiera previamente con RegOpenkeyEx (en wmain la utilizo); regValueName, que es el nombre del valor a consultar y flags, que me indica el tipo de datos que voy a utilizar.

Finalmente está el código de la función principal wmain. Aquí lo que hice fue declarar las variables necesarias para usar la función RegCreateKeyEx que abre o crea la subclave, luego las que requiere RegSetValueEx para escribir el contenido del valor Default y las de RegGetValue para consultar e imprimir el contenido del valor Default.

La siguiente porción de código se puede resumir así en esta secuencia:

¿Existe la subclave HKEY_LOCAL_MACHINE\Software\WinSide?

  • : consultar e imprimir el contenido del valor Default.
  • No: crear la subclave WinSide, escribir el contenido del valor Default e imprimirlo.

Así se ve todo esto usando C y la API de Windows:

int wmain()
{

    void showValue(HKEY openKeyResult, LPCWSTR regValueName, DWORD flags);
   

    //RegCreateKeyEx
    HKEY hKey = HKEY_LOCAL_MACHINE;
    LPCWSTR subKey = L”Software\\WinSide”;
    DWORD reserved = 0;
    LPWSTR classTypeOfKey = NULL;
    DWORD options = REG_OPTION_NON_VOLATILE;
    REGSAM samDesired = KEY_READ | KEY_WRITE;
    LPSECURITY_ATTRIBUTES securityAttributes = NULL;
    //Handle to the opened or created key.
    HKEY openKeyResult;
    DWORD disposition;

    //RegSetValueEx
    LPCWSTR valueName = NULL; //To set the default value’s content.
    DWORD typeOfData = REG_SZ;
    const BYTE *pData = (const BYTE*)MSG;
    DWORD size = sizeof(MSG);

    //RegGetValue
    LPCWSTR valueNameDefault = NULL; //To get the default value’s data.

    //Restrict the data type of value queried.
    DWORD flags = RRF_RT_ANY;
       

    LONG createKey = RegCreateKeyEx(hKey, subKey, reserved, classTypeOfKey,
                                    options, samDesired, securityAttributes,
                                    &openKeyResult, &disposition);

    if (createKey != ERROR_SUCCESS)
    {
        wprintf(L”Error opening or creating the key. Code: %li\n”, createKey);

    }
    else
    {
        LONG setValue;
       
        switch (disposition)
        {
        case REG_CREATED_NEW_KEY:

            //Let’s create the value!
            setValue = RegSetValueEx(openKeyResult, valueName, reserved,
                typeOfData, pData, size);

            if (setValue != ERROR_SUCCESS)
            {
                wprintf(L”Registry value could not be set.\n”);
            }
            else
            {
                wprintf(L”Registry value set.\n”);
            }

            //Let’s query it!
            showValue(openKeyResult, valueNameDefault, flags);
            break;

        case REG_OPENED_EXISTING_KEY:

            //Let’s query the value!
            showValue(openKeyResult, valueNameDefault, flags);
            break;

        }

        //Closing the key.
        RegCloseKey(openKeyResult);

       
    }

    return 0;

}

Lo más interesante de todo esto es que en las variables hKey y subKey estoy apuntando HKLM como clave y Software\WinSide como subclave, así que en teoría siempre debería escribir ahí; sin embargo, el Registry Redirector se encargará de dirigir la escritura a la ubicación física de acuerdo a la arquitectura del proceso, es decir, HKLM\Software\WinSide para x64 y WKLM\Software\Wow6432Node\WinSide para x86.

El resultado

Afortunadamente, Visual Studio me permite cambiar la arquitectura en la que la aplicación compila sin mucho esfuerzo, así que puedo mostrar el resultado fácilmente.

image

Ejecución de la aplicación a 32 bits en Windows de 64 bits

Cuando lanzo DemoApp.exe compilada a 32 bits, recibo este mensaje:

image

Como lo mencioné en la gráfica de la aplicación y en el código, estoy consultando el contenido del valor Default y mostrándolo. Si analizamos la traza con Process Monitor, veremos lo que ocurrió:

SNAGHTMLb91b44

Primero se muestra la operación de RegCreateKey, la cual intenta abrir la clave y si no existe, la crea; luego RegSetValue para crear el contenido del valor Default y finalmente RegQueryValue, operación que remplaza al RegGetValue en el código que expuse anteriormente para obtener el contenido del valor Default y poder imprimirlo después. Noten que todas las operaciones se hacen sobre la ruta HKLM\Software\WOW6432Node\WinSide, puesto que el proceso es de 32 bits.

Al ingresar a las propiedades de la entrada RegCreateKey, pestaña de Stack, puedo ver todas las ocurrencias de las DLLs, encargadas de interceptar las llamadas y realizar la traducción:

image

La aplicación cree que escribe en la ubicación física nativa, pero en cada operación que haga siempre será dirigida a WOW6432Node\WinSide.

Nota: existe una excepción en donde una aplicación puede leer y escribir en la subclave nativa, así el mecanismo del Registry Redirector esté funcionando; solo es necesario ingresar en la máscara de acceso, samDesired, el derecho de acceso KEY_WOW64_64KEY para usarla luego con RegCreateKeyEx, así:

REGSAM samDesired = KEY_READ | KEY_WRITE | KEY_WOW64_64KEY;

Si al ejecutar la aplicación los descriptores de seguridad (los que me dicen si puedo) no me lo deniega, la aplicación escribirá en HKLM\Software, sin hacer dirección a Wow6432Node.

Nota: no tengo idea de cómo se puede establecer esto en desarrollos con .Net, pero me imagino que existe la forma.

Ejecución de la aplicación a 64 bits en Windows de 64 bits

Esto es lo que pasa cuando lanzo la aplicación, compilada a 64 bits, en Windows de la misma arquitectura:

image

Observen que el mensaje ahora es «64-bit app on WINx64», pero es la misma aplicación.

Así se ve en Process Monitor:

image

Al estar la aplicación a 64 bits, no es necesario que actúe la capa de emulación de WOW64, por ende, el mecanismo del Registry Redirector tampoco se activa y la aplicación escribe en la ubicación nativa: HKLM\Software\WinSide.

Lo mismo a nivel de Stack, la comunicación es directa:

image

Eso es todo lo que tengo para escribir sobre el Registry Redirector. Agradezco mucho cualquier corrección, pues me ayudarán a aprender.

Espero escribir próximamente sobre Registry Reflection para ampliar un poco más WOW64.

Saludos,

—Checho

Interpretar las principales operaciones de registro con Process Monitor: RegOpenKey y RegCloseKey

Si alguna vez llegan a utilizan Process Monitor mientras diagnostican un problema o siguen algún comportamiento de Windows, se darán cuenta de que, sin duda alguna, es una herramienta indispensable  para trabajar. Aunque la herramienta no se ve tan compleja después de ejecutarla, el reto más grande pasa por saber interpretar correctamente los resultados de cada traza y resolver el problema. De la necesidad propia de comprenderla nació esta entrada de blog.

Unas de las operaciones más útiles en Process Monitor son las de registro de Windows, puesto que nos permite saber, a ciencia cierta, qué pasó exactamente mientras alguna operación se estaba ejecutando. Sin embargo, no es tan intuitivo ver nombres como RegOpenKey, RegCreateKey o RegSetValue, así que hoy quiero desglosar un poco estas tres operaciones comunes y mostrar cómo se pueden interpretar desde la consola de Process Monitor.

A continuación, describiré un poco qué hace cada operación y luego mostraré cómo se puede leer desde Process Monitor cuando hagamos algún diagnóstico.

Nota: no entraré en detalles demasiado técnicos, no por falta de interés, sino porque me falta el conocimiento para poder hacerlo.

RegOpenKey

La forma más sencilla que encontré para entender esta operación fue trabajar con la función de la API de Windows, RegOpenKeyEx, ya que los resultados que suministra Process Monitor están basados en ella.

La función de RegOpenKeyEx se utiliza, básicamente, para abrir una clave de registro, con el fin de realizar alguna operación adicional con las subclaves, valores de registro o bien crear alguna subclave nueva.

Consideremos la siguiente subclave: HKEY_CURRENT_USER\WinSide.

HKEY_CURRENT_USER o su abreviación, HKCU, es una de las 6 claves raíces que tiene el Registro de Windows, así que siempre va a estar presente y no se puede eliminar. WinSide, por el contrario, es una subclave que puede o no existir dentro de HKCU y se puede modificar.

Para poder comprobar con una aplicación creada en C o C++ que la subclave de WinSide existe, podemos declarar las siguientes variables:

LONG openKey;
HKEY key = HKEY_CURRENT_USER;
LPCWSTR subKey = L”WinSide”;
DWORD options = 0;
REGSAM samDesired = KEY_READ | KEY_WRITE;
HKEY handleKeyResult;
PHKEY phKey = &handleKeyResult;

openKey es la variable necesaria para recibir el tipo de valor retornado por RegOpenKeyEx; en la variable key tenemos el handle a una clave raíz abierta, HKCU; en subKey indicamos la subclave que deseamos abrir; options contiene la opción que aplica al abrir la clave, pero no es relevante con esta función; samDesired especifica los derechos de acceso deseados sobre la subclave que vamos a abrir, en este caso de lectura (KEY_READ) y escritura (KEY_WRITE); y phKey es un apuntador a un tipo de valor HKEY que recibirá otro handle, en caso de que la subclave abra correctamente.

La llamada a la función quedaría así:

openKey = RegOpenKeyEx(key, subKey, options, samDesired, phKey);

La línea anterior intentará abrir la subclave de HKCU\WinSide y asignará el código de error a la variable openKey declarada ateriormente.

Ahora supongamos que haremos una operación desde la aplicación para intentar abrir la subclave de WinSide, pero la validación sobre error será básica, por ejemplo:

if (openKey != ERROR_SUCCESS)//Si no abre la clave

wprintf(L”No pude abrir la subclave %s. Código: %li\n”, subKey, openKey);

else //Si la clave abre.
{
wprintf(L”La clave %s fue abierta.\n”, subKey);

//Cerrar handle para la clave
 RegCloseKey(*phKey);
}

En la validación anterior estoy validando si (if) openKey es diferente a ERROR_SUCCESS, es decir, cualquier otro mensaje inválido. En caso de que esto pase, mostraré un mensaje que me indica el código de error retornado por el manejador de errores de Windows. Si el valor retornado por la función es ERROR_SUCCESS, el programa se va para el else, así que muestro el mensaje satisfactorio y luego proceso a cerrar el handle de la clave con la función RegCloseKey.

Si yo ejecuto el programa sin crear la subclave de WinSide, el resultado se vería así:

image

Hasta aquí he mostrado la cara desde el desarrollo, así que sería relativamente fácil identificar qué está sucediendo y a qué hace referencia el número dos en el código. Sin embargo, la idea de esta entrada es aprender a interpretar lo que está sucediendo desde Process Monitor, pues casi siempre no tendremos acceso al código. Veamos cómo podríamos utilizar Process Monitor para deducir casi todo lo que he mostrado en código.

Primero, es necesario establecer algunos filtros en Process Monitor para que solo muestre los resultados de la aplicación RegApp.exe cuando está haciendo operaciones de registro, incluir lo que contenga WinSide y excluir todo lo demás. Después de configurar los filtros, basta con reproducir el resultado en consola que mostré antes mientras monitoreo con Process Monitor y empezar a analizar el resultado:

image

Interpretemos cada columna:

Process Name: RegApp.exe es el nombre de proceso que se está ejecutando y que está realizando la operación descrita en la tercera columna. Esto siempre es importante, puesto que sabemos de primera mano quién está tratando de realizar manipulaciones en el registro.

PID: cada que sea crea un proceso en Windows se le asigna un identificador de proceso con el que el sistema operativo sigue trabajando hasta que se termina el proceso. En cada nueva ejecución se crea un nuevo Identificador de proceso (PID).

Operation: como vemos en la captura de pantalla, la operación que está realizando la aplicación es la de RegOpenKey, es decir, tal cual lo vimos con la función de la API, está tratando de abrir una subclave de registro. Cada que veamos esta operación podemos tener la certeza de que la aplicación solo está tratando de abrir la subclave de registro y no creándola; opción que sí tiene la operación de RegCreateKeyEx, que veremos después. La subclave sobre la que está trabajando se muestra en la siguiente columna.

Path: esta es una de las columnas más importantes, puesto que me indica en qué ruta exacta, en este caso de registro, se está desarrollando la operación descrita anteriormente. En el caso de la captura anterior y de la aplicación que mostré, la ruta es HKCU\WinSide; como pueden recordar, HKCU es la abreviatura de HKEY_CURRENT_USER, así mismo lo hace con las demás claves raíces.

Result: de esta columna depende, la mayoría de las veces, seguir analizando la entrada o pasar a una próxima. Lo que vemos aquí es el resultado de la operación que la aplicación intentó hacer. El texto que muestra es el código de error devuelto por Windows, pero un poco más abreviado, y será de gran importancia de acuerdo al código que se reciba. Algunos de los más comunes son: SUCCESS, ACCESS DENIED, PATH NOT FOUND, NAME NOT FOUND, etc.

Para el caso de la captura anterior, el resultado arrojado es NAME NOT FOUND, el cual indica que la subclave de registro no existe en la ruta que está buscando.

Detail: aquí podemos ver información adicional de la operación específica que está realizando la aplicación; en el caso de las operaciones de registro, podemos ver la máscara de acceso que solicitó la aplicación. Si nos devolvemos un poco a la primera porción de código, yo declaré una variable llamada samDesired en la que pedí los derechos de acceso KEY_READ y KEY_WRITE, es decir, de escritura. En Process Monitor se ve como Desired Access: Read/Write.

Con la máscara de acceso podemos saber qué quiere hacer la aplicación con la subclave, por ejemplo, poder leer y escribir nuevo contenido, pero es el descriptor de seguridad el que tiene la última palabra sobre lo que en verdad puede hacer en la subclave. Es un tema complejo de seguridad en el que no entraré por falta de conocimiento.

La idea es ir leyendo los resultados de izquierda a derecha para poder entenderlos correctamente. Si resumimos todo, podemos decir que el proceso RegApp.exe, que tiene un identificador de proceso 3956, está intentando abrir la subclave de registro de HKCU\WinSide, pero no la encontró, lo cual indica que no está creada. Los derechos de acceso que había solicitado la aplicación era de escritura y de lectura.

Si queremos ver todo estos detalles un poco más agrupados, podemos hacer doble clic sobre la entrada o clic derecho y seleccionar Properties. Incluso podemos comparar con las declaraciones que hice en el código para que veamos qué tanto detalle puedo extraer con Process Monitor.

image

¿Qué pasa si la subclave de WinSide existe? Ejecutando la aplicación, el resultado sería este:

SNAGHTML20c388f

Del lado de Process Monitor, podremos ver un poco más de detalles:

SNAGHTML20f8e90

No tiene caso volver a describir cada columna, así que me concentraré en la lectura. La primera operación dentro de las tres que están resaltadas en la captura es la de RegOpenKey, que intenta abrir la subclave HKCU\WinSide y esta vez, a diferencia de lo que mostré, el resultado es SUCCESS, quiere decir que la subclave estaba creada en el registro de Windows. La máscara de acceso sigue conteniendo escritura y lectura (Read/Write), por ende, podrá crear otras subclaves o valores, a menos que el descriptor de seguridad de la subclave no lo permita.

El resultado de SUCCESS es equivalente a cero y en el código entraría en el else:

else //Si la clave abre.
    {
        wprintf(L”La clave %s fue abierta.\n”, subKey);

        //Cerrar la clave.
        RegCloseKey(*phKey);

    }

Después de esto hay una operación llamada RegSetInfoKey que ignoraremos por ahora; luego aparece la operación de RegCloseKey, la cual está encargada de cerrar el handle abierto cuando el trabajo con la subclave está terminado. La operación de RegCloseKey no tiene mayor ciencia, mas voy a tocar unos detalles que encontré interesantes cuando escribía esto.

RegCloseKey

El trabajo de la función RegCloseKey, como ya lo mencioné, es el de cerrar el handle abierto que obtuvimos con RegOpenKeyEx. El código para cerrarlo en la aplicación Si en el código no cerramos manualmente el handle, Windows lo hará eventualmente, pues va cerrando todo lo que esté abierto antes de hacerlo con la clave raíz de HKEY_CURRENT_USER.

Lo anterior se puede comprobar quitando del código la llamada a RegCloseKey; después de ejecutado y analizado con Process Monitor, se puede ver que el handle se cierra más adelante:

SNAGHTML221c921

Lo ideal es que esto esté gestionado desde el código de la aplicación y no dejarle la tarea a Windows. Desde Process Monitor sería muy complicado saber si desde el código el handle se cerró después de la operación en registro, pero si es así, generalmente estará la operación de RegCloseKey justo después de terminadas las otras tareas con la subclave de registro.

En la próxima entrada referente a esto, me enfocaré en interpretar la operación de RegCreateKey y luego en RegSetValue. La función de RegCloseKey la seguiré mostrando, pero no con detalles.

Traté de acertar lo más que pude, pero igual podría haberme equivocado en algunos aspectos, puesto que es un tema muy ligado a Windows Internals. ¡Comentarios bienvenidos!

Saludos,

—Checho

Establecer un diseño parcial del menú de inicio en Windows 10 a través de Directivas de grupo

Hace ya algunos años, en los tiempos de Windows 8.1, escribí una entrada en donde mostré una de las nuevas características que tenía el sistema operativo: diseño del menú de inicio, que se utilizaba para establecer una pantalla de inicio corporativa, con grupos e iconos obligatorios y que no se podían modificar por parte del usuario.  Windows 10, a partir de la versión 1511, continuó con esta funcionalidad, pero ahora es posible configurar dos tipos de diseño: completo y parcial.

A continuación pasaré a describir un poco la diferencia y explicar, paso a paso, cómo se puede implementar en una organización.

Diseño completo y parcial en Windows 10

El diseño completo del Menú de inicio es exactamente igual al que tenía Windows 10; es decir, desde otro equipo con la misma arquitectura (32 o 64 bits) se exporta el XML utilizando PowerShell y se aplica a través de una GPO, impidiendo que los usuarios, una vez se les aplique la directiva, puedan realizar modificaciones sobre los grupos o iconos anclados. El diseño parcial del Menú de inicio, nuevo en Windows 10 1511, permite crear grupos obligatorios, mas deja que el usuario modifique como quiera el resto del menú de inicio agregando nuevos grupos, por ejemplo.

Requerimientos

1. Entorno de dominio con los ADMX actualizados para Windows  10.

2. Dos equipos con Windows 10, versión 1511, y que al menos uno esté unido al dominio.

3. Ruta compartida disponible para trabajar con el XML.

Generar el archivo XML con el diseño del Menú de inicio

En el primer equipo, debemos personalizar manualmente los grupos que deseemos establecer como obligatorios para los usuarios; por ejemplo, yo creé un grupo de «Trabajo» y otro de «Soporte» en donde anclé todas las aplicaciones necesarias, además cambié los tamaños acorde a como quería.

image

Una vez personalizado el Menú de inicio, ejecutamos PowerShell con privilegios elevados.

image

El cmdlet que se debe utilizar es Export-StartLayout, que se encarga de exportar la descripción del menú de inicio actual en formato .xml. La sintaxis es muy fácil:

Export-StartLayout –Path <ruta><nombre.>.xml

Por ejemplo, para guardar el XML en el disco local y llamar al archivo «Inicio.xml», se ejecutaría:

Export-StartLayout –Path C:\Inicio.xml

image

Copiamos el archivo .xml al servidor en donde vamos a aplicar la directiva de grupo. Una vez copiado, editamos el archivo y agregamos la siguiente línea en el elemento <DefaultLayoutOverride>:

LayoutCustomizationRestrictionType=”OnlySpecifiedGroups”

Debería verse así:

image

 <DefaultLayoutOverride LayoutCustomizationRestrictionType=”OnlySpecifiedGroups”>

Guardamos el archivo en el directorio compartido creado en los requerimientos.

image

Implementar directiva de grupo

En el controlador de dominio, abrimos la GPO destinada para esta directiva y navegamos hasta:

User Configuration\Policies\Administrative Templates\Start Menu and Taskbar

Doble clic sobre la plantilla «Start Layout».

image

En la plantilla de «Start Layout», seleccionamos Enabled  y luego, debajo de Start Layout File, digitamos la ruta completa de red al archivo .xml:

image

Clic en OK al terminar para aplicar la directiva.

Probar la configuración del Menú de inicio

Para que el diseño parcial del Menú de inicio surta efecto es necesario reiniciar la máquina. Una vez hecho esto, debemos ver el Menú tal cual como se configuró en la primera máquina:

image

Noten los iconos que tienen los dos grupos obligatorios que establecí, creados para indicarle al usuario que no se pueden modificar de ninguna manera.

El otro aspecto importante es que, al ser un diseño parcial, se pueden crear otros grupos a gusto del usuario y que no interfieren para nada con los obligatorios:

image

Estos grupos personalizables no tienen el icono del candado para indicarle al usuario que tiene completa libertad.

Espero sea de utilidad.

Saludos,

—Checho

Review: Stellar Phoenix Windows Data Recovery en Windows 10

Hace un par de semanas fui contactado por la empresa Stellar, invitándome a realizar una revisión de uno de sus productos más importantes, Stellar Phoenix Windows Data Recovery. No es algo que haga normalmente en mi blog, pero quise retribuir el tiempo que se tomaron en contactarme y accedí a realizar la revisión para después publicarla.

Windows Data Recovery es una herramienta enfocada en Windows que permite realizar algunas tareas críticas de recuperación, incluyendo imágenes, documentos, unidades, correos electrónicos y hasta la posibilidad de crear una imagen del disco, entre otras cosas. Toda una suite útil cuando se pierde información crítica en distintos escenarios.

A continuación, haré una descripción de algunas de las características más interesantes del producto que probé en Windows 10, entre otros detalles particulares que encontré mientras probé el producto.

Lo primero que llamó mi atención es que, a pesar de estar en la última compilación de Windows 10, el producto lo reconoce como Windows 8:

image

La razón por la que una aplicación puede devolver la versión 6.2, es decir, Windows 8, es porque no tiene un manifiesto para Windows 8.1 o Windows 10; debido a esto, la función GetVersionEx que está utilizando para comprobar qué versión de sistema operativo es siempre devolverá 6.2. En una futura entrada espero hablar con algo más de detalle sobre esto.

Una vez hecha la instalación del producto, tienes una venta compuesta de pestañas en donde puedes iniciar el proceso de recuperación de acuerdo a la necesidad.

image

Recuperación de unidad

Esta es una de las características que más se usan en esta aplicación, puesto que nos permite hacer recuperación general de archivos en una unidad, sea disco o memoria USB. Cuando se hace clic sobre el botón de Recuperación de unidad, la aplicación despliega una tabla con todas las unidades disponibles y, una vez se escoge alguna, podemos hacer una recuperación rápida o completa, según nuestra necesidad.

image 

Si el problema es que acabaste de eliminar todo lo que tenías en la unidad, la recuperación rápida es perfecta, puesto que no tarda demasiado y es bastante eficaz:

image

Esta opción no es tan buena si, además de eliminar los archivos, le diste formato al disco o unidad de almacenamiento; para ese caso, es mejor utilizar la Recuperación avanzada o Recuperación de archivos RAW, en donde puedes indicar en qué tipo de extensiones estás interesado.

La recuperación de archivos avanzada tardará más, pues hace un análisis exhaustivo al dispositivo y depende mucho del tamaño y velocidad para terminar rápido.

image

Nota: Lamentablemente en mi caso, después de formatear la USB, no pude recuperar las fotos con las recuperaciones avanzadas. Sin embargo, la herramienta provee una opción para buscar explícitamente fotos de las diferentes unidades: Recuperación de fotos.

Recuperación de volúmenes perdidos

Debajo de Recuperación de unidad hay una opción adicional: Recuperación de volúmenes perdidos; esta característica permite indicar un disco duro y buscar por particiones que se hayan eliminado por alguna razón, así como la información que contenía.

image

Recuperación de fotos

La búsqueda también es en los sectores, pero se enfoca en los formatos de imágenes más comunes, o que se le especifique antes de iniciar el escaneo.

image

image

Para el caso de formateo de unidad, esta es la opción perfecta para recuperar imágenes que estuviesen en el dispositivo:

image

Para recuperar una o varias imágenes, basta con seleccionarlas y hacer clic en el botón inferior derecho de Recuperar. Aparecerá una ventana en donde podemos escoger entre un servidor FTP o una ruta local para guardar las fotos borradas, además de comprimirlo en archivo ZIP como opción adicional.

image

SNAGHTML59b95b4

Ciertamente me gustó mucho está opción, pues la recuperación de fotos es lo que suele afectar más a un usuario final cuando tiene un accidente con alguna unidad o dispositivo.

Recuperación de correo electrónico

Cuando quise probar esta opción, que básicamente sirve para recuperar correos que sean borrados desde un PST local de Outlook, tenía mucha expectativa, pero me encontré con la sorpresa de que solo recibe archivos PST y no OST. El principal problema de esto es que las cuentas de Exchange, Outlook y Gmail utilizan archivos OST en Outlook 2013 y posteriores, así que esta opción de recuperación no serviría en lo absoluto.

Ahora, si se tiene PST, basta con indicar la ubicación física y la herramienta iniciará el escaneo de correos eliminados:

image

 

 

 

 

 

 

 

 

 

Esperemos que Stellar pueda evolucionar esta característica y se adapte a los OST.

Opciones avanzadas

En la pestaña de Opciones avanzadas hay dos características que me parecieron interesantes: Crear imagen y Estado del disco. Pasaré a describir un poco cada una.

Crear imagen

Aquí puedo generar una imagen .IMG, perfecta para recuperar información desde ella usando el mismo Windows Data Recoveryo hacer análisis forense desde una distribución de Linux, por ejemplo. Basta con indicar la partición o disco y hacer clic en Iniciar Creación de Imagen:

image

Después de esto basta indicar un directorio donde se vaya a almacenar la imagen y dejar que la herramienta haga su trabajo.

image

El proceso de creación de la imagen es bastante largo y aburrido:

image

La herramienta evita crear la imagen en el mismo disco que se creó, característica bastante inteligente.

Estado del disco

Esta opción permite realizar un escaneo completo de sectores del disco para determinar si hay algunos dañados y puedas empezar a crear un plan de acción. Como en las otras opciones, basta con seleccionar el disco y darle al botón de Recupero base:

image

Conclusiones

Siempre es muy importante tener respaldada la información, sobre todo si es crítica, pero además tener alguna solución que sea fácil de utilizar para poder recuperar lo que más podamos en casos de daño o pérdida accidental. Windows Data Recovery es una buena opción, no es muy pesada y corre sin mayores contratiempos aún en las últimas compilaciones de Windows 10, además de hacer bien el trabajo de recuperación.

Lo único que no me gustó de la herramienta es que tiene una interfaz fea y en ocasiones difícil de manejar; por ejemplo, los cuadros de selección de disco no se pueden expandir, así que cuesta ver con comodidad toda la información presentada.

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