Microsoft Lync Server
Header

Author Archives: Santiago Buitrago

Skype For Business para Windows Phone ya está disponible

julio 16th, 2015 | Posted by Santiago Buitrago in skype for business - (0 Comments)

Algo que ya estábamos esperando desde hace tiempo, pues ya ha llegado: Descarga Skype For Business Mobile

 wp_ss_20150707_0002.pngwp_ss_20150707_0019.png

 
Skype Empresarial, anteriormente conocido como Lync 2013, para Windows Phone extiende el poder de Lync y Skype Empresarial a los dispositivos móviles: voz y video inalámbricos, presencia enriquecida, mensajería instantánea, reuniones y características de llamada desde una sola interfaz fácil de utilizar.
 
Características principales:
 
• Vea contenido compartido en su dispositivo móvil durante la reunión
• Inicie chats grupales (con mensajería instantánea o con video) e invite a otros participantes.
• Inicie reuniones de Skype Empresarial o únase a ellas para comunicarse con los demás y trabajar conjuntamente en grandes ideas.
• Controle las reuniones (siléncielas o quite a asistentes)
• Desvíe las llamadas a otro número de teléfono o a otro contacto.
• Retome las conversaciones en el punto exacto donde las dejó.
• Únase a una reunión de Skype Empresarial (y disfrútela) aunque no tenga ninguna cuenta de Skype Empresarial.
• Hemos mejorado la seguridad con el certificado de Skype Empresarial y la autenticación pasiva.
 
Disponible para Windows Phone 8, 8.1 o superior (yo lo estoy probando en Windows Phone 10 Preview), para Android e iOS aun tenemos que espserar un poco más.
 
Aquí os dejo algunas capturas  de Skype For Business para móvil (de mi móvil):
 
wp_ss_20150707_0004.pngwp_ss_20150707_0005.png

wp_ss_20150707_0006.pngwp_ss_20150707_0007.png

wp_ss_20150707_0008.pngwp_ss_20150707_0009.png

wp_ss_20150707_0010.pngwp_ss_20150707_0011.png

wp_ss_20150707_0012.pngwp_ss_20150707_0013.png

wp_ss_20150707_0014.pngwp_ss_20150707_0015.png

wp_ss_20150707_0017.pngwp_ss_20150707_0018.png

Como veis le han dado una vuelta al estilo y alguna novedad como lo de saber quien te ha agregado y eso sí, funciona perfecto con las conversaciones perdidas y las que puedes retomar, cosa que antes …

 
Ya sabéis, si tenéis Windows Phone 8 o superior ya podéis descargarla y probarla!!! 

Skype for Business 2015 Protocol Workloads Poster

julio 16th, 2015 | Posted by Santiago Buitrago in skype for business - (0 Comments)

Aquí tenéis una versión de las cargas de trabajo de Skype For Business 2015: Skype_for_Business_2015_Protocol_Workloads.vsdx (http://www.microsoft.com/en-us/download/confirmation.aspx?id=46448)

Skype_for_Business_2015_Protocol_Workloads_EVOICE.jpg

 

Skype_for_Business_2015_Protocol_Workloads_APP_SHARING.jpg

Skype_for_Business_2015_Protocol_Workloads_AVCONF.jpg

Skype_for_Business_2015_Protocol_Workloads_Certificados.jpg

Skype_for_Business_2015_Protocol_Workloads_CMS.jpg

Skype_for_Business_2015_Protocol_Workloads_DNS.jpg

Skype_for_Business_2015_Protocol_Workloads_IMPresencia.jpg

Ahora tocar revisarlos con mucho interés!!

 

 

 

Sitio Oficial de Skype For Business para dejar tu Feedback

julio 16th, 2015 | Posted by Santiago Buitrago in skype for business - (0 Comments)

Ya tenemos un sitio oficial para los usuarios de Skype For Business podamos dejar nuestro feedback sobre la herramienta, además de aportar IDEAS sobre mejoras del producto (http://www.skypefeedback.com/):

skypefeedback.PNG

Ahora toca votar y subir nuestras IDEAS de que cosas queremos para Skype For Business, algo que si la gente de MSFT se toma en serio (entiendo que si, será muy beneficioso para todos!!

He publicado varios artículos sobre los certificados que necesitamos para nuestra implementación de Lync o Skype For Business … (pulsar en la imagen para verla a tamaño real):

Certificados Lync-Skype_Final.jpg

Voy a tratar de enforcar de forma más directa las necesidades de certificados para Lync / Skype For Business y que tipo de certificados podemos implementar. En un artículo anterior (¿Qué certificados necesitamos para Lync?), había hecho un resumen de los requisitos en cuanto a certificados a implementar en Lync. Ahora lo único que quiero es "volver" a comentar que tipo de certificados necesitamos y de que entidades de certificación podemos solicitar los certificados y sean válidos para nuestra implementación.

Vamos a empezar por aclarar los PROS y CONTRAS sobre la utilización de certificados emitidos por una Entidad de Certificación Privada o Pública, voy a tratar de resumirlo (y mucho) en el siguiente cuadro:

Certificados Lync-Skype_Final_1.jpg

Veamos por cada tipo de Entidad Certificadora los datos del cuadro anterior:
 
Entidad Certificadora Privada: PROS
  1. Ahorro Económico: claramente, porque el coste de los certifidados seria de 0€, puesto que implementariamos una Entidad de Certificación Privada en uno de los servidores que tengamos en el dominio ( a ser posible no en ningún servidor de Lync ni Controlador de Dominio). Los certificados son 100% válidos para nuestra implementación
  2. Flexibilidad: desde luego que sí, podemos porque podemos emitir los certifidados que queramos y cuando queramos, cambiarlos en cualquier momento y todo a coste 0. Si cambiamos o añadimos dominios SIP en nuestra Topología de Lync/Skype4B lo haríamos sin problema alguno
  3. Federaciones: Se pueden utilizar sin problema alguno, pero siempre y cuando enviemos nuestro certificado raíz a la empresa con la que nos queremos federar para que lo instale en su EDGE. Esto es para que vea el EDGE con el que nos queremos federar como válido los certificados que le presenta nuestro propio EDGE.
Entidad Certificadora Pública: PROS
  1. Certificado válido en el 99,99%: si implementamos un certificado público en los servicios que publicamos hacia internet (EDGE, Servicios Web de los Front-END) de los servicios de Lync/Skype4B, los equipos (Linux, Windows, MAC, etc..) ya tienen los certificados raíz e intermedios de las Entidades Públicas más extendidas (DigiCert, VeriSign, GeoTrust, etc..). Por lo que si configuramos un certificado público de algunas de estas compañías (y otras muchas), siempre veremos el certificado cómo válido puesto que nuestro equipo ya tiene estos certificados raíz e intermedios indicados. Aquí puntualizo que si utilizamos el certificado emitido por nosotros e instalamos el certificado raíz en el contenedor de certificados local  del equipos también lo veremos como válido, pero claro, nosotros no lo podemos publicar en el resto de equipos del mundo como bien comprenderéis. Lo que quiero decir, que el funcionamiento del certificado privado es igual que el público, pero con un certificado de una CA privada tenemos que instalar el certificado de forma manual para que se vea como válido. Dicho esto, los certificados raíz de las entidades de certificación Públicos los podemos ver  desde el almacén de certificados del equipo local (desde una consola de certificados del equipo). Certificados Lync-Skype_1.jpg
  2. Federaciones: es válido para federarse con cualquier implementación de Lync/Skype4B y también con los servicios de IM Públicos (Skype (versión de consumo), Skype Online, Google, etc.), por la misma razón que en el punto 1, porque se utiliza un certificado público que´el resto de servicios de los proveedores lo ven como válido. ¿Se podría utilizar con certificados privados? SI, pero .. sería inviable enviarle a Microsoft  nuestro certificado raiz para lo instale en sus servidores, no solo por el elevado número de peticiones de empresas para enviarles su certificado raíz, sino por todos los problemas de seguridad que esto podría presentar, vamos, INVIABLE (pero no técnicamente).  Además, lo suyo es que el certificado sea público y así sea validado directamente por los servicios del proveedor y se vea como válido (y otras miles de razones, pero por simplificar) 
Entidad Certificadora Privada: CONTRA
  1. Federaciones con sistemas de IM Públicas: Esto es lo comentado en el punto nº2 de los PROS de los certificados públicos, como los proveedores no tienen instalado nuestro certificado raíz, no verán a nuestro servidor como de confianza puesto que verán errores de intercambio de certificados porque no es de confianza para el.
  2. Instalación del certificado raíz: Esto no es que sea un problema, pero si es bastante engorroso hacerlo si tenemos cientos de equipos a los que tenemos que instalar el certificado raíz y están fuera del dominio. Todos los equipos que están en el dominio ya no tienen problema, se les instala de forma automática el certificado raíz. Por ejemplo, si tenemos dispositivos móviles y queremos que se conecten a Lync/Skype4B y están dentro de la red (resolución DNS interna) tendrán que instalarse el certificado raíz en el dispositivo. Tenemos varias "soluciones" para esto:
    1. Formar a los usuarios para que tengan conocimiento de como instalar el certificado raíz en su dispositivo
    2. Configurar un segundo Reverse-Proxy desde dentro de la red y ahí tener un certificado público para que los usuarios se conecten a los servicios web vía Reverse-Proxy (hay que modificar los registros DNS si los dispositivos siguen utilizando los DNS internos). Esto es una "solución" alternativa a no tener que instalar el certificado raíz en cientos dispositivos móviles. Los registros que debemos modificar serían el lyncdiscoverinternal y el FQDN del servicio web externo que hayamos configurado en la topología, la IP que debe tener es la IP "externa" del Reverse-Proxy, y claramente ahí tengamos un certificado público (sino no servirá de nada). Pero antes de hacer este cambio, revisar este artículo: ¿Qué registros DNS necesitamos para la configuración automática del cliente Lync 2010 y 2013?.
    3. Disponer de una herramienta de gestión de dispositivos móviles que permita de forma remota instalar el certificado
  3. Mantenimiento de la CA: Esto no tengo claro que se pueda ver como un CONTRA, pero bueno siempre  tendremos que mantenerlo y actualizar las CRL u OCSP (esto no, pero bueno tiene que estar activo). Siempre tenemos que estar atentos a la renovación de la clave del certificado raíz, publicar las CRL, etc… siempre es algo a tener en cuenta y que si lo instalamos en local debemos tener cuidado con ello. Ver este vídeo que había publicado en su momento y fijaros en la parte de la configuración de las extensiones, es MUY IMPORTANTE y que los administradores no lo suelen tener en cuenta: Windows Server 2012, Instalación de una CA

 Entidad Certificadora Pública: CONTRA
  1. Ahorro de Costes: claramente no, los certificados públicos tienen un coste y en ocasiones importante
  2. Flexibilidad: Esto va ligado al ahorro de costes, podemos hacer lo que queramos con el certifidado (tener uno simple, uno SAN, uno Wildcard, uno Wilcard y SAN a la vez, etc..) pero siempre que hagamos algún cambio … toca pasar por caja. Esto con una Entidad Privada de Certificación no ocurre, cambiamos la veces que queramos, solicitamos los certificamos que necesitemos, revocamos los actuales cuando deseemos, etc..
Analizados los PROS y CONTRAS de los tipos de Entidades de Certificación, la pregunta es: ¿Qué tipo de certificados y entidad certificadora necesito/puedo implementar para nuestra topología de Lync/Skype4B? Yo lo tengo claro, una mezcla de ambos, certificados PRIVADOS para los servicios internos y PÚBLICOS para los servicios externos:
Certificados Lync-Skype_2.jpg
De esta forma para los usuarios que se conectan desde dentro de la red o más bien corporativos, como ya tienen el certificado raíz en sus equipos  se podrán conectar a todos los servicios sin problema. Y para los usuarios que se conecten desde fuera de la red lo harán vía EDGE y Reverse-Proxy, que será en donde tengamos los certificados públicos (con todo lo que ello conlleva). Así tenemos lo mejor de los dos escenarios, flexibibilidad y una gestión de costes equilibrada.
 
Ahora podría surgir otra duda: ¿Certificados SAN o Wildcard para los servicios públicos? Pues aquí, yo lo tengo claro, certificados SAN para el EDGE y WildCard para el Reverse-Proxy y os explico el porque (darle una vuelta a este artículo que había publicado en su momento: Certificados SAN o Wildcard para nuestra implementación de Lync Server):
  • SAN: Porque es el escenario más común cuando tenemos varias direcciones IP Públicas disponibles para los servicios de Lync/Skype4B, se tienen varios FQDN asociados a los distintos servicios y necesitamos un certificado que tenga los nombres que tenemos configurados.
  • WildCard: NO es obligatorio que sea wilcard y también podemos tener uno SAN, pero si tenéis varios servicios a publicar con los FQDN como subdominio (mail.dominio.com, office, dominio, lyncweb.dominio.com, etc…) lo suyo es tener uno wildcard porque con un certificado con el sujeto *.dominio.com podemos publicar todos los subdominios que se quieran y no tenemos que un certificado SAN (límite de 100 nombres (no todos, pero tomarlo como dato)) con varios nombres. Además, si tenemos varios dominios SIP podemos tener un certifidado WildCard con varios dominios (*.dominio.com, *.dominio2.com, etc..), lo que faciilta que con mismo Reverse-Proxy, una sola IP Pública podamos publicar los mismos servicios pero con subdominios diferentes.
 En estos dos escenarios este artículo puede seros de mucha utilidad: Cómo publicar todos los servicios de Lync, Exchange y WAC únicamente con una IP Pública. Por último también tenemos que nombrar a los certificados SIMPLES, certificados con un solo nombre. Estos son viables para el EDGE, habría que configurar el mismo nombre para todos los servicios y misma dirección IP:
SRV-LYNC00-2014-03-25-07-39-40-1.png
Aquí el "problema" es que los servicios no tendrán el puerto estandard (443/TCP), tenéis que cambiarlo y esto es posible que os pueda causar algún problema cuando estáis en un red fuera de la corporativa y tengan algún tipo de filtrado de puertos de salida, pero de lo contrario es un escenario 100% válido. 
 
Dicho todo esto y por resumir, aquí os dejo mis conclusiones sobre los certificados y entidades certificadoras a utilizar:
  • Utilizar certificados de vuestra CA privada en todos los servicios internos (EDGE (Interno), Front-END, Mediation Server, Chat Persistente, Director, Office Web App, Exchange (EWS))
  • Utilizar certificados de entidades de certificación públicas en los servicios externos de la topología (EDGE, Reverse-Proxy)
  • Certificado SAN (públicos) para el EDGE y WildCard para el Reverse-Proxy

Y ahora que debemos tener en cuenta cuando solicitemos un certificado para nuestra topología:

  • El nombre que tenga el certificado debe coincidir con el nombre del servicio configurado en la topología. Si es un certficado SAN, pues tendrá todos los nombres que sean necesarios.
  • Los certificados asociados a los Front-END, se solicitan desde el asistente y ya se encarga el de solicitar los nombres que necesita (igualmente, antes de completar la solicitud revisarlos). Revisar  estdos dos vídeos, que os ayudarán a entender como se solicitan e instalan los certficados en los Front-END y EDGE: Asignar Certificados a un Front-END de Lync Server 2013, Asignar Certificados a un EDGE de Lync Server 2013

De sobra es sabido, que para que se vean como certificados válidos para un sistema, se deben cumplir los siguientes requisitos:

  • El nombre del certificado debe corresponderse con los servicios publicados
  • Debe estar en fecha (no caducado)
  • Los equipos que se conecten a los servicios de Lync/Skype4B deben tener el certificado raíz instalado en su almacén local de certificados (si el certificado es privado y están fuera del dominio debe instalarse de forma manual)
  • Si utilizáis dispositivos móviles pensar cual es vuestro mejor escenario, eso ya depende de cada  cliente (número de dispositivos móviles, administración, etc..).
Por último, aquí os dejo algunos artículos anteriores sobre certificados y que creo que os pueden servir de ayuda:

Cada día los certificados están más presentes en cualquier tecnología, para los que no os habéis metido de lleno a conocer el funcionamiento de los certificados, deberíais empezar cuanto antes. Como véis en Lync/Skype4B es vital conocer bien que es un certificado y como implementarlo, sino no funcionará absolutamente nada. Mirad este esquema de tráfico entre los servidores de Lync/Skype4B (es un poco antiguo, pero para que tengáis una referencia nos sirve):

Certificados Lync-Skype_3.jpg

Como todo en la vida, si se tiene conocimiento todo es más sencillo y veréis como la tecnología funciona y funciona muy bien, sino terminaréis desquiciados porque no os funcionará nada o crereéis que todos son problemas. La evolución de Lync a Skype (Migración paso a paso de Lync Server 2013 Standard a Skype For Business 2015 Standard, Migración paso a paso de Lync Server 2013 Enterprise a Skype For Business 2015 Enterprise) no ha cambiado nada con respecto a los certificados, se solicitan y se necesitan de la misma forma.

No sé si os he aclarado algo más el tema de los certificados o lo he complicado más, pero espero que sea lo primero!!!o sé si os he aclarado algo más el tema de los certificados o lo he complicado más, pero espero que sea lo primero!!!

Skype for Business Server 2015, SEFAUtil

julio 16th, 2015 | Posted by Santiago Buitrago in Skype For Business Server - (0 Comments)

Microsoft ha liberado la versión de SEFAUtil para Skype for Business Server 2015​, aquí tenéis el enlace de descarga: http://www.microsoft.com/en-us/download/details.aspx?id=47704

SEFAUtil_Skype_For_Business.png
Skype for Business Server 2015, SEFAUtil permite a los administradores configurar la delegación de llamadas, redirecciones, llamadas de equipos, revisar la configuración del ruteo de llamadas de un usuario, etc… todo ello vía línea de comandos. Eso sí, debemos cumplir previamente con los siguientes requisitos:
 
Supported Operating System
Windows Server 2012, Windows Server 2012 R2
 
For more infomration about system requirements for the SEFAUtil.exe, pleae refer to the following TechNet articles:
Veamos un ejemplo rápido de como revisar la configuración de un usuario, para ello simplemente ejecutaremos el siguiente comando: SEFAUtil.exe /server:<fqdn_servidor> direccion_sip_usuario
SEFAUtil_Skype_For_Business_1.png
 
Esta utilidad ya la tenemos desde la versión de Lync 2010 y 2013, con algunas cosas interesantes como la Capturar Llamada (que al final en Lync .. yo personalmente no le veo excesiva utilidad):

Como habéis visto en la primera captura de pantalla, si ejecutáis el SEFAUtil sin modificadores os mostrará la ayuda y los modificadores disponibles:

   /server: Lync Server FQDN, required if auto-discovery is not enabled
   /adddelegate: add delegate on-behalf of the user
   /removedelegate: removes delegate on behalf of the user
   /simulringdelegates: Sets user's call handling rules to ring delegates endpoi
nts simultaneously
   /delayringdelegates: Sets number of seconds Boss' endpoints ring before ringi
ng delegates
   /fwdtodelegates: Sets user's call handling rules to forward calls to delegate
s
   /disabledelegation: Disables delegate ringing for the user
   /setfwddestination: Sets the user's forward immediate or forward-no-answer de
stination
   /enablefwdimmediate: Sets user's call handling rules to immediately forward a
ll calls to Fwd Destination
   /enablefwdnoanswer: Sets user's call handling rules to forward unanswered cal
ls to Fwd destination
   /callanswerwaittime: Sets the number of seconds to wait for user to pick up t
he call
   /disablefwdimmediate: Disables forward immediate
   /disablefwdnoanswer: Disables forward-no-answer
   /setsimulringdestination: Sets the user's Simul Ring destination
   /enablesimulring: Sets user's call handling rules to Simul ring calls to Simu
l Ring Destination
   /disablesimulring: Disables Simul Ring
   /enablegrouppickup: Enables Group pickup
   /disablegrouppickup: Disables Group pickup
   /addteammember: add team member on-behalf of the user
   /removeteammember: removes team member on behalf of the user
   /simulringteam: Sets user's call handling rules to ring team member endpoints
 simultaneously
   /delayringteam: Sets number of seconds user's endpoints ring before ringing t
eam members
   /disableteamcall: Disables team ringing for the user
   No switches: Displays the call forwarding settings of the user.
Como podéis apreciar podemos a  nivel de administración configurar las opciones de los usuarios a nivel de gestión de llamadas, algo muy potente el poder hacerlo de forma centralitada, veamos un ejemplo sencillo:
 
Habilitar la llamada simultánea a un usuario: para ello utilizaremos el comando SEFAUtil con los siguientes modificadores: SEFAUtil.exe /setsimulringdestination:<Phone number of destination> /enablesimulring [/server:<Lync Server FQDN>] <SIP URI of user>
 
Antes de ejecutar el comando, veamos como el usuario no tiene ninguna redirección de llamadas configurada, para ello podemos verlo vía cliente Skype:
SEFAUtil_Skype_For_Business_2.png
O también podemos comprobarlo desde SEFAUtil: SEFAUtil.exe /server:<fqdn_servidor> direccion_sip_usuario
SEFAUtil_Skype_For_Business_1 - copia.png
Ahora desde el servidor ejecutaremos SEFAUtil.exe /setsimulringdestination:<Phone number of destination> /enablesimulring [/server:<Lync Server FQDN>] <SIP URI of user>
SEFAUtil_Skype_For_Business_3.png

Y automáticamente el usuario ya tiene la configuración en su cliente Skype For Business:

SEFAUtil_Skype_For_Business_4.png
Como podéis apreciar es muy sencillo y potente, ahora os toca probarlo a vosotros. El único problema que le veo, es que el usuario puede modificar la configuración desde el cliente de Skype For Business y esto ya no me gusta. Entiendo que si son configuraciones que le damos desde el servidor a nivel de administración deberían ser permanente, pero no es así. También es cierto que el usuario pueda necesitar en algún momomento modificarlo y sino puede … vamos un lío.
 
Espero que os sea de utilidad!!