Microsoft Lync Server

Lync: Línea Privada (Private Line)

abril 2nd, 2013 | Posted by Santiago Buitrago in Lync Server - (0 Comments)

Vamos ver un concepto no muy utilizado en el día a día, pero sí demandado por los directores de las compañías como es la Línea Privada. Esto no es más que una segunda línea e independiente de la línea principal del usuario, con la ventaja de que no estará visible ni en los directorios telefónicos ni en las listas de contactos. Además tiene las siguientes particularidades que debemos tener en cuenta:

Las líneas privadas se crean desde PowerShell: Set-CsUser –Identity usuario –PrivateLine “Tel:+111222333”

Solo se puede tener una línea privada por usuario
Es únicamente para uso exclusivo de recepción de llamadas, no se pueden realizar llamadas con este número, siempre mostrará el número de la línea principal
Las llamadas al número privado siempre suenan, hacen caso omiso al estado "No Molestar"
El usuario que tiene una línea privada solo tiene un buzón de correo, dirección de correo y de sip
La línea privada se almacena en el Directorio Activo en el atributo msRTCSIP-PrivateLine del usuario
Si el usuario puede desviar las llamadas recibidas a la línea privada cuando recibe la llamada, si tiene configurado el desvío de llamadas solo afecta a la línea principal

Ahora que ya tenemos claros algunos conceptos de las Líneas Privadas vamos a configurar un usuario para que tenga Línea Privada, para ello únicamente debemos ejecutar el cmdlet anterior con el número de teléfono asignado

Si queremos ver el número de la línea privada que tienen asignada los usuarios debemos ejecutar este cmdlet: Get-CsUser | format-table -property displayname,privateline

Además, como os había comentado este número se almacena en el Directorio Activo en el atributo msRTCSIP-PrivateLine del usuario, si vamos a la pestaña de Atributos de las propiedades del usuario debemos encontrar el número +5550 asignado anteriormente

Si queremos que nos muestre el número de la línea privada de un usuario en concreto, podemos hacerlo desde PowerShell con el siguiente script:

$user = Get-CsUser usuario

$user.PrivateLine

Podemos ejecutarlo desde el Windows PowerShell ISE (debéis sustituir mi usuario por el que queráis buscar) o crear un .PS1 para posteriormente ejecutarlo desde PowerShell. Para ello copiamos las siguientes líneas en un fichero de texto y lo guardamos con extensión .PS1

$user = Get-CsUser
$user.PrivateLine

Para posteriormente desde una consola de PowerShell de administración de Lync Server lo podáis ejecutar

También tenemos la posibilidad de personalizar el tono que escucharemos cuando recibamos una llamada por la línea privada, para ello desde el propio cliente vamos a Opciones – Tonos de llamada y sonidos – Mi línea privada

Si ahora alguien nos llama a nuestra línea privada vamos a identificarla por que veremos el texto de Llamada privada en la ventana de recepción de la llamada

En una llamada al número principal se muestra de la siguiente forma

Si queréis ampliar la información sobre las líneas privadas aquí tenéis la URL de MSFT: http://technet.microsoft.com/es-es/library/gg412728.aspx

Espero que os sea de utilidad!!!

Line, Lync, Private

Estacionamiento de Llamadas o Call Park en Lync

abril 2nd, 2013 | Posted by Santiago Buitrago in Lync Server - (0 Comments)

El servicio de Estacionamiento de Llamadas, nos permite utilizar un grupo de extensiones «virtuales» para que retengan una llamada recibida, de tal forma que podemos rescatar esa llamada pulsando el número de extensión con la que se ha «estacionado»:

Imaginemos que un usuario A recibe una llamada de un usuario B desde la cuenta de Lync de un usuario C. El usuario A tiene una conversación confidencial con el usuario B y necesita disponer de un espacio aislado para continuar con la conversación, y a su vez no quiere colgar la llamada porque luego le resultaría complicado volver a contactar con el usuario B. Como la llamada es confidencial, no queremos que el usuario C tenga la conversión en su Lync sino que queremos hacerlo desde nuestra sesión o teléfono. Además, nos encontramos solos en la ubicación del usuario C, por lo que transferir la llamada sería viable pero correríamos el riesgo de perderla. Por lo que podemos estacionar la llamada, el usuario B estará en «espera» y nosotros podemos recuperarla marcando en nuestro Lync o teléfono la extensión que nos muestra en pantalla el Lync en el momento de estacionar la llamada. De esta forma, no tenemos la llamada en abierto durante el tiempo que nos movemos de ubicación, no tenemos que colgarla ni tenemos que transferirla y parecer «gacelas» corriendo hasta nuestra ubicación de destino en busca de contestar la llamada. El proceso es my sencillo, pero a lo mejor he líado algo la explicación, así que voy explicaros como configuramos este servicio y una demostración de su utilización.

Primero voy a configurar el intervalo de extensiones que utilizaremos para estacionar las llamadas, debemos tener en cuenta que el intervalo debe ser lo suficientemente amplio para estacionar las llamadas que utilizarán este servicio. Para ello podemos hacerlo mediante PowerShell o el Panel de Control de Lync Server, nosotros vamos a configurarlo de ambas formas. Para poder configurar este servicio necesitamos ser miembros de los siguientes grupos:

RTCUniversalServerAdmins
CsVoiceAdministrator
CsServerAdministrator
CsAdministrator

Panel de Control de Lync: Características de Voz

Como vemos únicamente debemos cubrir los siguiente datos y asigarlo a nuestro pool o servidor

PowerShell, New-CSCallParkOrbit

Sintaxis: New-CsCallParkOrbit

New-CsCallParkOrbit -Identity «Nombre» -NumberRangeStart ext_inicio -NumberRangeEnd ext_fin -CallParkService ApplicationServer:FQDN

Ejemplo

New-CsCallParkOrbit -Identity «Asir Park Pool» -NumberRangeStart 5585 -NumberRangeEnd 5590 -CallParkService ApplicationServer:pool.asirsl.com

Ahora ya tenemos configurado nuestras extensiones de «estancionamiento de llamadas», podemos configurar otras opciones como son:

– EnableMusicOnHold: se habilita o deshabilita la música en espera

– OnTimeoutURI: configurar el destino de reserva que se va a usar cuando se agota el tiempo de una llamada estacionada

– MaxCallPickupAttempts: que determina el número de veces que una llamada estacionada llama al teléfono de destino antes de reenviar la llamada al URI de reserva

– CallPickupTimeoutThreshold: que determina la cantidad de tiempo que transcurre desde que una llamada se aparca hasta que vuelve a llamar al teléfono que recibió la llamada

Estas opciones por defecto son las siguientes:

Microsoft recomienda configurar la opción OnTimeoutURI para el destino de reserva que se usará cuando el tiempo de espera de una llamada estacionada se agote y deje de sonar

Si queremos crear una nueva confguración específica del sitio debemos hacerlo con el cmdlet New-CsCpsConfiguration , queremos modificar estas opciones debemos hacerlo mediante el cmdlet Set–CsCpsConfiguration

Sintaxis: New-CsCpsConfiguration

New-CsCpsConfiguration -Identity <XdsIdentity> [-CallPickupTimeoutThreshold <TimeSpan>] [-Confirm [<SwitchParameter>]] [-EnableMusicOnHold <$true | $false>] [-Force <SwitchParameter>] [-InMemory <SwitchParameter>] [-MaxCallPickupAttempts <Int32>] [-OnTimeoutURI <String>] [-WhatIf [<SwitchParameter>]] [<CommonParameters>]

Ejemplo (para conocer el nombre del Site utilizaremos el siguiente cmdlet: Get-CsSite)

New-CsCpsConfiguration -Identity site:»Asir Lync» -CallPickupTimeoutThreshold 00:01:00 -EnableMusicOnHold $true -MaxCallPickupAttempts 1 -OnTimeoutURI sip:callparkdemo@asirsl.com

Si queremos modificar alguna opción utilizaremos Set-CsCpsConfiguration

Sintaxis: Set-CsCpsConfiguration

Set-CsCpsConfiguration [-Identity <XdsIdentity>] [-CallPickupTimeoutThreshold <TimeSpan>] [-Confirm [<SwitchParameter>]] [-EnableMusicOnHold <$true | $false>] [-Force <SwitchParameter>]
[-MaxCallPickupAttempts <Int32>] [-OnTimeoutURI <String>] [-WhatIf [<SwitchParameter>]] [<CommonParameters>]

Ejemplo
Set-CsCpsConfiguration -Identity Global -MaxCallPickupAttempts 5

Una vez configuradas las diferentes opciones debemos ejecutar el siguiente cmdlet para habilitar el «estacionamiento de llamadas» en la Directiva de Voz aplicada a lo usuarios, puesto que por defecto está deshabilitado: Set-CsVoicePolicy con la opción EnableCallPark. Primero debemos identificar nuestra Directiva de Voz y habilitar el «Estacionamiento de Llamadas»: Get-CsVoicePolicy

Get-CsVoicePolicy

Ahora debemos ejecutar el cmdlet con la opción EnableCallPark y tendremos habilitado el Estacionamiento de Llamadas en la Directiva de Voz:

Set-CsVoicePolicy -Identity Tag:Nombre -EnableCallPark $true

Estos cambios podemos hacerlo mediante el Panel de Control de Lync: Enrutamiento de Voz – Directivas de Voz

Algo importante es que las extensiones virtuales de estacionamiento de llamadas no deben estar normalizadas.

Espero que os sea de utilidad!!!

Call Park, Lync

Deshabilitar un usuario en el Directorio Activo y en Lync

abril 2nd, 2013 | Posted by Santiago Buitrago in Lync Server - (0 Comments)

En más de una ocasión os habréis encontrado con la situación de tener que deshabilitar un usuario en el Directorio Activo que tiene cuenta de Lync. Sin embargo esto no evita que el usuario pueda iniciar sesión en Lync durante un periodo máximo de 6 meses, y siempre en función de otros factores. Esto puede llegar a ser un problema muy importante para las organizaciones, puesto que el usuario podría estar realizando llamadas a la PSTN sin control o incluso hablar con gente de la organización y poder sacar información de la empresa sin que nadie de cuenta de ello.

Todo esto viene dado porque el usuario si en algún momento inicia sesión con el cliente Lync en un equipo fuera de la organización, y marca la casilla de "Guardar mi contraseña"

el servidor de Lync creará automáticamente un certificado para el usuario. Además, este certificado se publicará en la base de datos RTC con la clave privada y se almacenará en el equipo local del usuario:

Utilizar el certificado digital es algo que nos permite iniciar sesión más rapidamente y más beneficios en cuanto a la seguridad, pero el problema es que no tiene en cuenta si el usuario está o no deshabilitado en el Directorio Activo. El certificado tiene una duración de 180 días, de ahí que en función de cuando el usuario haya habilitado la opción de guardar contraseña y el tiempo que haya pasado hasta que lo hemos deshabilitado en el Directorio Activo tendrá tiempo suficiente para utilizar los siguientes servicios:

IM
Conferencias
Llamadas de Voz

Desde PowerShell podemos ver los certificados que tiene cada usuario, para ello debemos utilizar el siguiente cmdlet: Get-CsClientCertificate sip:direccion_sip

Como vemos en cada equipo que hayamos iniciado sesión y hemos activado la opción de "Guardar mi contraseña" nos ha crea un certificado de usuario como hemos visto en la captura anterior. Por lo tanto el usuario podrá iniciar sesión en Lync hasta que expire su certificado. También podemos revocar los certificados del usuario, pero para que el usuario ya no pueda iniciar sesión en Lync se tienen que dar las siguientes condiciones:

Equipos del dominio

Que expire el ticket de Kerberos (10 horas)

Usuarios Externos

Reinicio de los servidores de Lync
El usuario cierre e inicie sesión
El certificado haya caducado

*Esto es siempre que queramos que sea de forma inmediata cuando hayamos revocado el certificado, son tiempos que debemos tener en cuenta

Para revocar el certificado disponemos del siguiente cmdlet: Revoke-CsClientCertificate

Sintaxis
Revoke-CsClientCertificate [-Confirm [<SwitchParameter>]] [-Force <SwitchParameter>] -Identity <UserIdParameter> [-WhatIf [<SwitchParameter>]] [<CommonParameters>]

Sinopsis
Los certificados de cliente permiten a los usuarios estar autenticados cuando inician sesión en Lync Server. Estos certificados son particularmente útiles en el caso de teléfonos y otros dispositivos que ejecutan Lync Mobile donde resulta complicado escribir el nombre de usuario o la contraseña. Revoke-CsClientCertificate permite a los administradores revocar certificados de cliente que se han emitido a un usuario. Este cmdlet se presentó en Lync Server 2010.

Descripción
Los certificados de cliente proporcionan una alternativa para autenticar a los usuarios con Lync Server. En lugar de proporcionar nombre de usuario y contraseña, los usuarios presentarán al sistema un certificado X.509. (Este certificado debe tener un nombre de sujeto o un nombre alternativo de sujeto que identifica al usuario). Para autenticarse, los usuarios solo deben escribir un número de identificación personal (PIN). Para un usuario de teléfono móvil, escribir un número de PIN suele ser más fácil que escribir un nombre de usuario o contraseña alfanuméricos.En cualquier momento, los administradores pueden revocar certificados de cliente emitidos a un usuario mediante el cmdlet Revoke-CsClientCertificate.

Revoke-CsClientCertificate revoca todos los certificados de cliente emitidos desde el servidor al usuario en cuestión.

Revoke-CsClientCertificate no elimina los certificados del dispositivo cliente; los certificados solo se eliminan del servidor. Sin embargo, es suficiente para evitar que un cliente use certificados con fines de autenticación: si no se puede encontrar un certificado en el servidor, sedenegará la solicitud de autenticación.

Ejemplo

Revoke-CsClientCertificate -Identity sip:sbuitrago@asirsl.com

Para evitar este "problema" y no llevarnos sorpresas a la hora de estar deshabilitar un usuario en el Directorio Activo debemos deshaiblitar el usuario en Lync, bien vía PowerShell o Panel de Control vía Web:

PowerShell

Disable-CsUser sip:direccion_sip

Panel de Control

Espero que os sea de ayuda y tengáis claro el proceso para deshabilitar un usuario en el AD y también en Lync

Active Directory, Lync

¿Qué certificados necesitamos para Lync?

abril 2nd, 2013 | Posted by Santiago Buitrago in Lync Server - (1 Comments)

En la fase de planificación de nuestra infraestructura, siempre hay un punto que hace referencia a los certificados que debemos adquirir. Debemos tener muchas cosas en cuenta, pero una básica son que servicios vamos a publicar y con que nombre. Todos sabéis que el nombre del certificado debe coincidir con el nombre del servicio a publicar, sino no funcinarán correctamente o directamente no funcionarán los distintos servicios. Seguro que en alguna ocasión habéis visto esta alerta en vuestro navegador.

En este caso el único problema que tenemos es que el servidor tiene asignado un certificado con un nombre diferente al que nosotros hemos tratado de conectarnos a través de nuestro navegador, y nos avisa de que podemos estar visitando un sitio diferente al que realmente queremos. O bien que estamos utilizando un certificado privado (emitido por nuestra CA en Windows) y no tenemos el certificado raiz instalado en nuestro equipo. Esto no quiere decir que el certificado no esté realizando su función que es la de cifrar el tráfico, pero el nombre que tiene no concuerda con el nombre de la URL que estamos visitando. De ahi que no es solo una cuestión puramente de seguridad, sino también de confianza. Si tenemos un servicio público al que se tienen que conectar nuestros clientes y les aparece esta advertencia, desde luego nuestra imagen como empresa quedaría por lo menos en entredicho. Además a día de hoy un certificado simple tiene un coste inferior a 80€ / año, por lo que no es una cuestión económica el no tener un certificado público.

Comentado esto, vamos a centrarnos en que debemos tener en cuenta a la hora de adquirir un certificado para nuestras implementaciones de Lync. Básicamente yo recomiendo siempre dos certificados: SAN y WILDCARD. Estos certificados serían para servicios diferentes, el certificado SAN para nuestros servidores EDGE y el Wildcard para nuestros Front-END y sus servicios Web. Como todos sabemos los nombres de los servicios que estamos publicando en el EDGE suelen ser los siguientes:

WEBCONF.ASIRSL.COM

AV.ASIRLAB.COM

SIP.ASIRLAB.COM

EDGE.ASIRSL.COM (opcional)

Esto son los nombres que debería tener nuestro certificado SAN (Subjet Alternate Name), de manera que podamos instalarlo en nuestros servidores EDGE y contengan el nombre de todos los servicios que vamos a publicar y en un solo certificado. Siempre estoy hablando de los certificados asignados a las interfaces externas, por lo que son certificados de una entidad certificadora pública (Verisign, Digicert, Thawte). Con esto tendríamos nuestro servidores/es EDGE correctamente configurados en cuanto al certificado se refiere, siempre y cuando los nombres de los certificados se correspondan con los nombres de los servicios (lo doy por hecho).

Ahora vamos a ver los certificados que necesitamos para el resto de servicios y que no pasan por el EDGE, sino por el Front-END o Director. En estos roles publicamos los distintos servicios con los siguientes nombres "por defecto":

lyncdiscover.asirlab.com

lync.asirlab.com o pool.asirlab.com (opcional según el nombre que hayamos configurado)

dialin.asirlab.com

meet.asirlab.com

Estos servicios se suelen publicar a través de un ISA Server, TMG o similar como reverse proxy, y es a ese servidor a cual le tenemos que instalar el certificado externo que adquiramos. El certificado que yo recomiendo siempre es un WILDCARD, porque os permitirá posteriormente utilizarlo para publicar más servicios que los de Lync, por ejemplo: OWA, SharePoint, CRM, WAC y cualquier otra URL del mismo dominio con el siguiente FQDN: loquesea.asirlab.com. De esta forma podéis aprovechar el certificado para publicar más servicios que exclusivamente los de Lync. Y si por ejemplo hoy publicais el meet.asirlab.com únicamente y dentro de 6 meses queréis tener disponible el dialin.asirlab.com o lyncdiscover.asirslab.com ya no tendréis que adquirir más certificados, de cualquier otra forma si. Aqui también podemos disponer de un certificado SAN, pero el coste del certificado con los 3 nombres obligatorios para el EDGE más los dos del Front-END tendrá un sobre coste superior a tener un WildCard y un SAN. Además de que para cada servicio completamente diferenciado es recomendable tener distintos certificados, pero eso ya es otro tema.

Ahora bien, si nuestra infraestructura cuenta con un TMG para publicar las distinas URL, yo recomiendo que el certificado que se instale a los servidores sea de vuestra Entidad Certificadora Privada, puesto que os permite solicitar tantos certificados como queráis sin tener que preocuparos por el coste. Si os olvidáis de algún nombre en la fase piloto, solo tenéis que volver a solicitarlo y no tendréis problema de costes económicos. Tened en cuenta que el TMG presentará en el certificado público al exterior pero hacia los servidores internos se conectará con el certificado interno, y que además el TMG al estar en el dominio ya tiene el certificado raiz de confianza instalado y no tendréis problemas con la publicación de cualquier servicio Web de Lync. Con el certificado Wildcard (*.asirlab.com) podéis publicar con el mismo listener de TMG más servicios como he comentado anteriormente. Esto también es aplicable al EDGE, en su interfaces interna puede tener tener un certificado de nuestra CA Privada y funciona sin problema.

Esto siempre y cuando tengáis un solo dominio SIP, si tenéis varios dominios SIP y queréis tener certificados públicos, el certificado debe contener todos los nombres FQDN de todos los dominios. Como he comentado yo recomiendo hacerlo de esta forma, es de las más económicas, permite la reutilización del certificado para otras publicaciones y nos permite publicar distintos servicios de Lync que inicialmente no lo habíamos hecho sin coste adicional. Todo esto tiene sus matices, pero es cuestión de tener claro que servicios vamos a publicar, que nombres tendrán esos servicios y como se van a publicar al exterior.

Si además implementamos los servicios de UM de Exchange, el certificado que debemos utilizar es también uno de nuestra Entidad Certificadora. Como nuestros servidores de Lync forman parte del dominio, no tendrán problemas con la validación del certificado que ambos se están presentando para la autenticación de servicios. El certificado del servidor Exchange para el ROL de UM debe tener como nombre común el nombre FQDN del servidor sino, no funcionará

Y por último para la integración del OWA con Lync, es más de lo mismo pero teniendo en cuenta algo muy sencillo. Cuando creemos nuestras aplicación de confianza el nombre debe ser el mismo que el nombre común que hemos configurado en el certificado asignado en Exchange para la integración con Lync

Sino es asi podréis encontraros de que todo está correctamente instalado, configurado y publicado pero … error!!! (esta captura representa uno de los posibles errores)

Como véis es muy sencillo, pero es cuestión de tener claras nuestras necesidades y el resto es aplicar el conocimiento que ya tenéis sobre Lync y Certificados. Si no queremos utilizar certificados públicos podemos hacer exactamente lo mismo con nuestra CA Privada, pero al resto de usuarios que no tengan las máquinas en nuestro dominio debemos pasarles nuestro Certificado Raiz para que lo instalen en el contenedor adecuado de sus equipos

Pero si queréis federar vuestro Lync con Microsoft, Google, etc.. debéis disponer de certificados públicos en vuestro EDGE. Si queréis federaros con otras compañias y no tenéis certificados públicos únicamente debéis "intercambiar" vuestras CA.

Aqui os muestro varias capturas de pantalla sobre un certificado WildCard conectándome a distintas URLs y otro SAN:

WildCard: nos conectamos a https://soporte.asirsl.com

WildCard: nos conectamos a https://meet.asirsl.com

SAN: Certificado de un EDGE con los nombres de los distintos servicios publicados

Para terminar este artículo comentaros los servicios que utilizan los distintos clientes de Lync:

Cliente Lync: EDGE

Lync Mobile: Front-END o Director Publicando las distintas URL via TMG u otro proxy

Lync Web APP: Front-END o Director Publicando las distintas URL via TMG y otro proxy

Precios de Certificados

WildCard	SAN

Aqui os dejos algunos interesantes:

Error de certificado cuando usamos Thawte

Windows Server 2012, Instalación de una CA

Creación de CSR para Lync de forma sencilla

Espero que os sea de utilidad!!!

Certificados, Lync

Microsoft Lync Server 2010, Herramienta de planeación

abril 2nd, 2013 | Posted by Santiago Buitrago in Lync Server - (0 Comments)

Una vez que hemos descargado la herramienta de Planeación de Lync 2010, empezamos con la planeación y vemos que nos irá solicitando la información necesaria para implementar nuestra infraestructura de LYnc. Además, nos generará los visio correspondientes con las topologías, etc… y por último podremos exportar la topología para importarla en nuestro Lync!!!

Primero vamos a empezar por iniciar la planeación, para ello pulsamos en comenzar una vez hemos abierto la herramienta de planeación

Paso 1: elegimos si queremos tener conferencias de audio y video en la empresa

Paso 2: elegimos si queremos tener conferencias telefónicas

Paso 3: elegimos si queremos tener conferencias web

Paso 4: elegimos si queremos tener telefonia empresarial y así poder reemplazar las PBX u otros sistemas de telefonía

Paso 5: elegimos si queremos utilizar la UM de Exchange, beneficiándose de los buzones de voz por usuario, Operadores Automáticos, etc…

Paso 6: elegimos si queremos gestionar las comunicaciones en tiempo real tratando de gestionar el ancho de banda de la WAN

Paso 7: elegimos si queremos implementar la supervisión: registro de sesiones de CU, métricas de calidad, etc..

Paso 8: elegimos si queremos implementa el Archivado: registrar las conversaciones IM y conferencias de datos

Paso 9: elegimos si queremos implementar la federación con empresas externas o con proveedores de IM externos (MSN, Yahoo, Skype, GTalk, AOL). También podemos necesitar habilitar la federación con OCS 2007 o R2, pero en mi caso no todos serían instalaciones de Lync 2010 o 2013

Paso 10: elegimos si queremos disponer de un sistema tolerante a fallas

Hemos finalizado con las preguntas básicas que nos debemos hacer ante cualqeruier implementación, ahora comenzará a diseñar la configuración de los Sitios, Usuarios, Dominios SIP, etc.. para comenzar pulsamos en Diseñar Sitios
Paso 11: debemos configurar la implentación que queremos tener, nombre del sitio, cantidad de usuarios, etc..

Paso 12: escribimos el nombre del dominio SIP que vamos a implentar

Paso 13: elegimos si queremos o no virtualizar el entorno (es importante tenerlo claro, porque luego las capacidades de usuarios cambia radicalmente)

Paso 14: debemos "estimar" la posible utilización simultanea de las Conferencias, yo lo he dejado por defecto

Paso 15: la cantidad de usuarios que tendrán habilitado la Voz Empresarial, yo he elegido todos porque la idea es sustituir la PBX. Además debemos estimar la utilización de la Voz Empresarial por parte de la organización
Paso 16: debemos tener claro este paso, puesto que de aqui dependerá toda la parte de voz. Puesto que debemos dimensionar correctamente las conexiones de datos, etc… pero aqui solo elegimos el tipo de Infraestructura de VOZ. Yo he elegido un Troncal SIP (Direct SIP para Lync), ahora debemos tener un ISTP para poder utilizar esta implementación (yo apuesto por INTROUTE, un excelente proveedor certificado por Microsft para Lync). En cuanto al tipo de línea lo que tenemos es un T1 o un E1, pero aqui en España utilizaremos líneas de datos en un CPD de 5MBits nos dará una capacidad de 50 llamadas simultáneas (siendo una línea dedicada para Voz y con el Códec G7911). Las líneas E1 no suelen ser utilizadas en Europa para datos como tal, pero aqui os dejo sus descripciones tanto de las E1 como de las T1:

En Europa, existen cinco tipos de líneas que se distinguen según sus velocidades:

E0 (64 Kbps)
E1 = 32 líneas E0 (2 Mbps)
E1 = 128 líneas E0 (8 Mbps)
E3 = 16 líneas E1 (34 Mbps)
E4 = 64 líneas E1 (140 Mbps)

En Estados Unidos, el concepto es el siguiente:

T1 (1,544 Mbps)
T2 = 4 líneas T1 (6 Mbps)
T3 = 28 líneas T1 (45 Mbps)
T4 = 168 líneas T1 (275 Mbps)

Paso 17: configuramos que habilitaremos la UM de Exchange para todos los usuarios y la cantidad de mensajes de Voz en sus buzones al día. Aqui os dejo un artículo que había hecho en su momento explicando el impacto de habilitar la UM en Exchange con Lync: Impacto de habilitar la Mensajería Unificada de Exchange a los usuarios de Lync

Paso 18: especificaremos si tendremos servidores EDGE y cuantos usuarios externos tendrán nuestra organización. Además si vamos a tener Directore(s) y balanceadores hardware con múltiples IPs Públicas

Paso 19: especificaremos que servidores vamos a virtualizar

Paso 20: especificaremos si queremos separar el rol de Mediation Server en servidores independientes de los Front-END, que seria lo suyo si tenemos la carga de trabajo en la parte de Voz como hemos dimensionado anteriormente

Paso 21: configuraremos las oficinas remotas de las que consta la empresa, cuantos usuarios tendrá cada oficina y si queremos utilizar el desvio de medios

Ya hemos finalizado la planeación de Lync, por lo que ahora debemos pulsar en Dibujar para ver gráficamente la infraestructura que hemos ido configurando

Lo primero que nos presenta es un dibujo de la topologia, si vamos haciendo click sobre los distintos elementos nos mostrará gráficamente la infraestructura

Pulsando en el SITIO Central nos muestra la topología configurada, como vemos tenemos distintas pestañas que iremos revisando y en donde veremos los datos configurados (datos simulados de IPs, etc..)

Topología del Sitio
Diagrama de Red Perimetral

Información de la administración de la red perimetral, nos muestra las direcciones IP y nombres de la red perimetral

Información de la administración de la red perimetral, los certificados que vamos a necesitar por cada servicio

Información de la administración de la red perimetral, nos muestra la configuración de direcciones IP (origen – destino) y puerto (origen – destino). Esto debemos tenerlo muy en cuenta a la hora de configurar nuestros Firewalls. Aqui os dejo algunos artículo que había escrito en relación a este apartado:

Edge Lync: Configuración de Red (Parte I)

Edge Lync: Configuración de Red (Parte II)

Edge Lync: Configuración de Red (Parte III)

Registros DNS que debemos crear tanto en interno como externo, registros Tipo A y SRV, súper importante tenerlo correctamente configurado

Una vez que hemos configurado toda infraestructura podemos exportar la confguración en Visio y Excel, además podemos guardar la Topología para posteriormente importarla en nuestro Lync

Disponemos de bastante información cuando nos muestra la topología, en los paneles de la parte derecha desde donde podemos ver la información que hemos ido configurando con el asistente:

Información del Sitio

Información de Hardware

Configuración Virtual

Roles de Servidor

Una vez guardada la planeación podemos recuperarla en cualquier momento para seguir trabajando sobre ella, tratando de modificarla según vuestras necesidades. También comentaros que yo he exportado los mapas de red a Visio y la verdad … me lo ha hecho bastante mal. Pero no sé si porque en el equipo en donde tenía la herramienta instalada (una MV) no tenía el Visio instalado, pero cuando lo he abierto en el equipo fisico con Visio … pues la verdad se había desmontado un poco.

Espero que os sea de utilidad!!

Lync, Planeacion

Lync: Línea Privada (Private Line)

Estacionamiento de Llamadas o Call Park en Lync

Deshabilitar un usuario en el Directorio Activo y en Lync

¿Qué certificados necesitamos para Lync?

Microsoft Lync Server 2010, Herramienta de planeación

Santiago Buitrago

Entradas recientes

Comentarios recientes

Archivos

Categorías

Únete y comparte tu conocimiento

Sígueme en Twitter