Poco a poco Microsoft Teams se va incorporando como herramienta de Comunicaciones Unificadas en las compañías, por lo que, para los administradores de IT nos empieza a ser necesario tratar de automatizar los despliegues del cliente Teams a los usuarios. Voy a mostraros algunos escenarios muy comunes que se os pueden presentar:

• • • Usuarios locales: usuarios que están conectados en la red local y tienen acceso “directo” a los servidores de la compañía
    • Usuarios remotos: conectados vía VPN, DirectAccess o equipos inscritos en  Azure AD y manejados vía Intune

Prefiero diferenciar ambos escenarios, básicamente porque si el usuario está en la red local el origen del instalador estará en algún servidor de ficheros local, por lo que ahí el ancho de banda no será problema. Pero si el usuario está fuera de la red, aunque esté conectado por VPN o DirectAccess, si le damos como origen del instalado en un servidor de la red local,  estamos consumiendo recursos de red de forma ineficiente. Pensad que tenemos 100 usuarios itinerantes, los cuales, en su proceso de inicio de sesión lanzamos un Script o GPO que tenga como origen del instalador en la red local … estaremos consumiendo de forma “brutal” el ancho de banda de la compañía en un proceso 100% evitable.

Aquí os muestro la infografía sobre la cual se basa este artículo, tendremos usuarios conectados directamente en la red local donde tenemos algunos de los servidores de la empresa y otros que son usuarios conectados vía VPN o simplemente inician sesión en sus equipos registrados en Azure AD.

Seguramente muchos de los que estáis implicados en proyectos de Teams se os ha encomendado el migrar los ficheros compartidos, esos ficheros que históricamente nos hemos preocupado de mantener en nuestros servidores On-Premises. A priori suena a complejo y tedioso, pero ya veréis que puede ser todo lo contrario.

Antes de nada, tenemos que tener en cuenta algunas cosas, sobre todo del funcionamiento de Teams en cuanto a los canales, pestañas de ficheros, etc… algo que os había comentado en este artículo: Microsoft Teams, conceptos y tecnología (Parte I). El máximo problema es la gestión de los permisos, puesto que en Teams todo el que tiene acceso a un equipo tiene acceso a toda la información.  En Teams por definición, todos los usuarios tienen acceso a todo lo que se haya subido al equipo y en cualquier canal y, MSFT no recomienda tocar los permisos de las carpetas de la biblioteca “Documentos Compartidos” o “Shared Documents” porque esto podría corromper el equipo. Pero, también es cierto que podemos crearnos dentro de la colección del sitio de cada Teams nuevas bibliotecas, las cuales podemos ajustarle los permisos a nuestro parecer y que esté visible en una ficha de Teams. De momento, por lo menos, nos asegurará el que tengamos equipos creados y los usuarios puedan tener acceso a información de forma segregada con los diferentes permisos establecidos en las nuevas bibliotecas que podemos crearnos …

Ya tenemos una de las funcionalidades, aunque simple, muy cómoda para los que utilizamos día a día Teams, la posibilidad de compartir pantalla desde una sesión de Chat. Es muy sencillo de utilizar, simplemente iniciamos una conversación de chat con algún usuario y en la parte superior derecha hasta la fecha teníamos las opciones de vídeo y audio, pues ahora tenemos disponible (de forma general) la opción de compartir pantalla ….

Siguiendo con la adopción de Teams en las empresas, es posible que os empecéis a encontrar con situaciones donde tenéis o queréis limitar el espacio de almacenamiento que utilizará cada Teams creado. Como sabéis, cada Teams creado “por detrás” hace muchas cosas y una de ellas es la creación de una colección de Sitios. Por lo que, si queremos aplicar cuotas de almacenamiento a Teams, debemos aplicarlos a su colección de sitios. Antes de nada, aquí os dejo una infografía de los límites de almacenamiento para SharePoint y servicios que utilizan dicho almacenamiento: OneDrive For Business y Teams …