Una de las novedades de Windows Server 2012 R2, en combinación con clientes Windows 8.1 es “Work Folders”, algo en general poco conocido, así que he decidido hacer una demostración simple en ambiente de pruebas de la configuración y el funcionamiento
Primero debemos explicar qué es “Work Folders”. Esta funcionalidad permite tener un servidor de archivos donde se almacenan en forma centralizada, datos que pueden ser accedidos desde cualquier máquina del Dominio, e inclusive desde máquinas que no forman parte del Dominio, no lo he podido probar pero Microsoft se refiere también a otros tipos de dispositivos, e inclusive aunque tampoco lo haré acá, para simplificar y poder comprender el proceso, publicar el acceso externo a Internet
Resumiendo: acceso desde cualquier máquina o dispositivo a un almacenamiento centralizado de datos, sin importar la ubicación del usuario o dispositivo
La infraestructura necesaria para la prueba son cuatro máquinas, que son las mismas que vengo usando en todas las demostraciones:
- Un Controlador de Dominio (dc1.ad.guillermod.com.ar)
- Un Servidor Miembro (srv1.ad.guillermod.com.ar
- Dos clientes (cl1 y cl2.ad.guillermod.com.ar)
Recordar que los servidores deben ser Windows Server 2012 R2, y los clientes Windows 8.1, no funciona con versiones anteriores
Para que se pueda comprender la instalación y el funcionamiento haré una simplificación como es no tener implementada una infraestructura de clave pública, que complicaría bastante el desarrollo. Más adelante veremos cómo lo hacemos, aunque es importante tener en cuenta que si vamos a permitir el acceso externo es importante hacerlo con seguridad
Lo primer que he hecho es crear en el Dominio una Unidad Organizativa (“Work Folders OU”), donde he creado dos usuarios (“User Uno” = u1, y “User Dos” = u2) los cuales han sido incluidos en un grupo Global que he creado y llamado “WorkFolders-Group”
En SRV1 comenzaré con la instalación de la funcionalidad que se hace como siempre, y creo que todos los que lean esto saben cómo agregar un Rol) solamente muestro las capturas específicas del mismo. Es un “Role Service” de “File and Storage Services”, y por supuesto agregando los componentes requeridos
Una vez finalizada la instalación (next, next, next, … Close) ya podemos ir a “Server Manager” y en “File and Storage Services” ver que tenemos disponible la funcionalidad. Comenzaremos, como muestran las pantallas creando un nuevo “Sync Share”, que así se llama
Seleccionamos dónde colocaremos la carpeta de almacenamiento
Que si no existe nos preguntará si la crea
Podemos seleccionar si se crearán con el alias del usuario (u1), o con una dirección de tipo correo (u1@ad.guillermod.com.ar) siendo necesaria esta última en el caso de ambiente de múltiples Dominio, y que pueden resultar en colisión de nombres, que no es nuestro caso
Preguntará por el nombre del “Sync Share”, podemos dejar ahora el que sugiere
Y ahora podemos seleccionar a qué grupo le daremos acceso; de todas formas aunque se a un grupo, creará una carpeta diferente para cada usuario
Si se fijan he desmarcado la opción “Disable inherited permissions and grant users exclusive access to their files” (Deshabilitar la herencia de permisos y otorgarle a los usuarios acceso exclusivo a sus archivos)
Esto me dará un poco de trabajo más adelante pues tendré que modificar manualmente los permisos, pero me permite como administrador tener acceso a los datos
Lo que he podido investivar sobre cifrado de la carpeta me ha resultado confuso y basado en versiones beta del producto por lo cual no voy a modificar el valor por omisión, no cifrar. La poca documentación que he visto habla de una clave “Enterprise” no relacionada con EFS
La segunda opción, marcada por omisión, es exigir que el cliente use un protector de pantalla que necesite contraseña
Revisamos y confirmamos
Observen que además que nos muestra lo creado, en la parte inferior indica qué usuarios tienen acceso
Ahora nos toca el “trabajo extra” por no haber marcado la opción de los permisos que vimos antes, así que nos toca hacer los cambios manualmente
Deshabilitamos la herencia de permisos, copiando los heredados
Debemos modificar los permisos del grupo “WorkFolders-Group” dándoles para que pueden modificar
Y eliminar los dos permisos, que quedaron de la herencia, de “Users”
Finalmente quedarán así
Para no tener que hacer la configuración en cada máquina, y que cada usuario deba hacerlo, lo haremos por Directivas de Grupo (GPO), así que vamos al Controlador de Dominio (DC1), y crearemos la directiva correspondiente
Se podría enlazar la GPO directamente a la Unidad Organizativa con los usuarios, o inclusive, aún haciéndola a nivel del Dominio filtrándola al grupo en cuestión, aunque no lo haré para mantener la demostración lo más simple posible
Le damos un nombre adecuado
Y la editamos para hacer la configuración necesaria
Debemos configurar: “User Configuration / Policies / Administrative Templates / Windows Components / Work Folders / Specify Work Foders Settings”. Donde debemos habilitar la opción, incluir la dirección (HTTP o HTTPS) del servidor de almacenamiento, y muy conveniente marcando “Force automatic setup” así no le pregunta nada al usuario
En condiciones de un ambiente productivo, y sobre todo si se va a dar acceso remoto, es importante que la dirección no sea HTTP sino HTTPS, pero requeriría la implementación de la infraestructura de clave pública que comenté al principio de la nota no haré para no complicar esta demostración
El tema de no tener la infraestructura de clave pública (Autoridad Certificadora, etc.) y como el cliente por omisión exige que la conexión sea con HTTPS, debemos hacer un cambio en el registro de los clientes (CL1 y CL2) consistente en agregar una entrada en el registro de cada máquina
Por rapidez he creado un archivo BAT, que he copiado en cada cliente, que debemos ejecutar como administrador, y que agrega la clave. Por si no se ve claro indico el contenido del BAT (va todo en una única línea)
reg add HKLM\SOFTWARE\Microsoft\Windows\
CurrentVersion\WorkFolders /v
/AllowUnsecureConnection /t REG_DWORD /d 1
Podemos revisar con REGEDIT.EXE que la clave se creó correctamente
Ahora comencemos a probar 🙂
Inicio sesión en CL1 con la cuenta U1, y observo que tengo creada la carpeta “Work Folders”
Creamos un documento cualquiera (Document1.txt)
Si ahora, con el mismo usuario (U1), iniciamos sesión en CL2, veremos que podemos acceder al archivo creado en CL1. E inclusive si creamos otro archivo (Document2.txt) este debería copiarse a la carpeta central, y además al otro equipo
Por omisión, la documentación informa que los cambios se detectan cada 5 minutos (alguna dice 10) pero para no esperar trato de forzar la replicación
Y si vamos a CL1 veremos que se ha replicado
Si vamos a SRV1, podemos observar, gracias a los cambios que hemos hecho en los permisos, que podemos ver ambas carpetas, y su contenido
Para poder demostrar el acceso desde otro equipo no perteneciente al Dominio, simulando por ejemplo alguien que traiga su propio dispositivo portable (notebook) saco a CL2 del Dominio, y la paso a grupo de trabajo (WORKGROUP)
Al estar fuera del Dominio, como es lógico no se la aplica la directiva de grupo (GPO) creada, así que la configuración la debe hacer el usuario en forma manual, desde Panel de Control / Work Folders
Acá debemos cambiar, en lugar del correo del usuario, el URL del servidor central
Como estamos en una máquina fuera del Dominio, y por lo tanto con un usuario local, no del Dominio, debemos ingresar las credenciales de alguien que tenga los privilegios de acceso
Nos preguntará por la ubicación donde guardará la réplica local
Y para poder seguir adelante, nos solicitará que aceptemos las condiciones que puede imponer un administrador
Aparece el UAC. Sí, debemos contar con la autorización de un administrador local
Ya casi …
Y se abrirán automáticamente dos ventanas. La primera con los documentos correspondientes
Y la segunda con información de la sincronización
Me ha parecido interesante el tema que un usuario pueda acceder a un repositorio personal de datos centralizado, sin importar si es desde la red, o desde su propio equipo
Lamentablemente no puedo probar usando otro tipo de dispositivos que no sean “máquinas normales” pues estoy haciendo todo esto con máquinas virtuales (VMware Workstation)
Lo que está atrás de todo esto es el tema BYOD (Bring your own device)
Otro punto muy importante a tener en cuenta antes de implementarlo en ambiente productivo, y sobre todo si la idea es publicarlo para poder accederlo desde Internet (Reverse-proxy), es implementar la correspondiente infraestructura de clave pública (PKI)
Si alguien desea profundizar más en el tema, le recomiendo el siguiente enlace
Deploying Work Folders : http://technet.microsoft.com/en-us/library/dn528861.aspx
Trackbacks
[…] Windows Server. En castellano. […]