Microsoft Lync Server
Header

Windows.jpg

Microsoft ha dado por finalizado el desarrollo de Windows Server 2012, puesto que ya es RTM como anuncian en el blog oficial:

Today is the RTM for Windows Server 2012 R2!

As noted in my earlier post about the availability dates for the 2012 R2 wave, we are counting the days until our partners and customers can start using these products. Today I am proud to announce a big milestone: Windows Server 2012 R2 has been released to manufacturing!
This means that we are handing the software over to our hardware partners for them to complete their final system validations; this is the final step before putting the next generation of Windows Server in your hands.
While every release milestone provides ample reason to celebrate (and trust me, there’s going to be a party here in Redmond), we are all particularly excited this time around because we’ve delivered so much in such a short amount of time. The amazing new features in this release cover virtualization, storage, networking, management, access, information protection, and much more.
By any measure, this is a lot more than just one year’s worth of innovation since the release of Windows Server 2012!
As many readers have noticed, this release is being handled a bit differently than in years past. With previous releases, shortly after the RTM Microsoft provided access to software through our MSDN and TechNet subscriptions.  Because this release was built and delivered at a much faster pace than past products, and because we want to ensure that you get the very highest quality product, we made the decision to complete the final validation phases prior to distributing the release.  It is enormously important to all of us here that you have the best possible experience using R2 to build your private and hybrid cloud infrastructure.
We are all incredibly proud of this release and, on behalf of the Windows Server engineering team, we are honored to share this release with you.  The opportunity to deliver such a wide range of powerful, interoperable R2 products is a powerful example of the Common Engineering Criteria that I’ve written about before.
Also of note: The next update to Windows Intune will be available at the time of GA, and we are also on track to deliver System Center 2012 R2.
Thank you to everyone who provided feedback during the preview process – we could not have done it without you!
I can’t wait to share even more on October 18! In the meantime, keep an eye on this blog and Twitter for updates.
Readying Windows 8.1 for release
We’ve hit an important milestone for Windows and for Microsoft—just 10 months after delivering on a bold, generational change in computing with Windows 8, our team is proud to share that we have started releasing Windows 8.1 and Windows RT 8.1 to our hardware partners. In many ways, this marks a new day at Microsoft, reflecting a number of rapid release firsts. Thanks, in part, to customer feedback and an unparalleled level of collaboration across product teams, Windows 8.1 is a significant update. We have delivered in a very short time an update to the OS that will bring an even greater unified experience for our customers. As we consider the code we just handed off, and the new intuitive and fluid computing experience it provides – anytime, anywhere, across all devices – we’re confident we made the right bet in continuing our visionand following through on our commitment to rapid innovation and responsive engineering.
In the past, the release to manufacturing (RTM) milestone traditionally meant that the software was ready for broader customer use. However, it’s clear that times have changed, with shifts to greater mobility and touch as well as the blurring of work and personal lives. As such, we’ve had to evolve the way we develop and the time in which we deliver to meet customers with the experience they need, want and expect. We’ve had to work closer to our hardware partners than ever before. Reaching this milestone is about optimizing the overall experience for our customers. Our hardware partners are in a position to prepare the wide array of innovative devices our customers can expect later this fall – just in time for the holidays. Over the next several months we’ll see beautiful, powerful devices, from the smallest tablets to the most lightweight notebooks to versatile 2-in-1s, as well as industry devicesdesigned for business.
While our partners are preparing these exciting new devices we will continue to work closely with them as we put the finishing touches on Windows 8.1 to ensure a quality experience at general availability on October 18th. This is the date when Windows 8.1 will be broadly available for commercial customers with or without volume licensing agreements, our broad partner ecosystem, subscribers to MSDN and TechNet, as well as consumers.
On behalf of the Windows engineering team, we want to thank you for joining us on this journey. So many people rely on Windows in so many ways, and so we thank you for your participation in previewing the product, for your feedback, for your contributions and for your support. You have helped us make Windows 8.1 great for everyone!
We are super excited to see Windows 8.1 help deliver the next generation of devices and a one-of-a-kind experience that’s in sync with the way you live – at home, at work, and on the go.
Ahora toca esperar un poquito pero no creo que falte mucho tiempo para tenerlo disponible en MSDN!!!

​​MSFT_6.PNGMSFT_5.PNGMSFT_4.PNGMSFT_3.PNGMSFT_2.PNGAlimenta la Experiencia.PNGMSFT.png

 

​​Web de recursos y formación para profesionales de IT para Lync Server y Lync Services ….

LyncServer_para_profesionales_de_IT.pngEspero que ose sean de utilidad!!!

Uno de los problemas con los que nos solemos encontrar a la hora de ofertar una solución de Microsoft, es su licenciamiento. Como todos sabemos Microsoft ​tiene un complejo sistema de licenciamiento en casi todos sus productos, pero si bien es cierto que tenemos muchas vías de formación comprender el sistema de licenciamiento. Aquí os dejo una URL (pulsar encima de las imágenes) para que podáis aclarar el tipo de licencia que necesitáis:

Licencias_MSFT_URL_1.png
 
Licencias_MSFT_URL_2.png
Desde luego se necesitan herramientas de este estilo, porque a veces hasta para el mas experto se vuelve complicado el conocer exactamente cuales son las CAL que debemos adquirir. En su momento había subido un artículo sobre el licenciamiento de Lync (Licenciamiento Lync Server 2013), pero si alguien se anima a hacer algo parecido para otros productos sería perfecto
Licenciamiento Lync 2013.jpg
 
Espero que os sea de utilidad!!!

Continuando con este artículo que había publicado hace unos meses (¿Qué certificados necesitamos para Lync?), aquí os dejo una tabla resumen de la utilización de un certificado wildcard (para asegurar un dominio y todos sus subdominios de primer nivel) y SAN (Nombres alternativos del sujeto que permiten proteger varios hostnames con un único certificado SSL)

Certificado_Comodin_Compatibilidad.jpg 
Me sigo encontrando con muchas preguntas sobre los certificados, si cual debo comprar, que nombres debe tener, si sirve un certificado SAN o debe ser un certificado wildcard, etc… En una implementación de Lync Server podemos utilizar certificados privados, públicos o ambos. Yo siempre recomiendo ambos, lo que nos permitirá ahorrarnos un dinero importante. Veamos un escenario con certificados públicos y privados, los certificados privados los utilizaremos para la configuración de todos los servicios internos y que no tendrán acceso directo con usuarios externos:
  • Front-END
    • Nombres de dominio
    • FQDN del Pool
    • FQDN de cada servidor
    • Servicios Web (URLs: meet, dialin, admin, etc…)
  • EDGE
    • FQDN del servidor (certificado interno)
    • FQDN del Pool (certificado interno)
  • Director
    • FQDN del Pool
    • FQDN de cada servidor
    • Servicios Web (URLs: meet, dialin, admin, etc…)
  • WAC
    • URL de los servicios Web del WAC
Y para los servidores que si estarán expuestos a internet, debemos tener certificados públicos si queremos evitar enviar a los usuarios que se conectan a Lync el certificado raíz de nuestra CA y para federarnos con sistemas de mensajería pública (Skype, XMPP). Por lo que si la federación  no la vamos a implementar con sistemas de mensajería pública, podemos utilizar sin problema alguno los certificados emitidos por nuestros servidores. Puesto que si queremos federarnos con otras empresas con Lync, únicamente debemos enviarle nuestro certificado raíz y no tendremos problemas para conectar ambas implementaciones de Lync vía federación. Pero si queremos olvidarnos de enviar el certificado raíz y además, queremos federarnos con cualquier sistema de mensajería pública (compatible) entonces si necesitamos certificados emitidos por una entidad pública.
Los servidores o vía Firewall que debemos exponer directamente son el EDGE y un reverse-proxy para publicar los servicios web de Lync (meet.dominio.com, dialin.dominio.com, lyncdiscover.dominio.com, lync.dominio.com). Yo recomiendo siempre adquirir dos certificados, uno para el EDGE del tipo SAN con los tres nombres obligatorios que debe tene el EDGE:
  • Servicio de Acceso: sip..dominio.com
  • Servicio de Conferencia: webconf.dominio.com
  • Servicio de A/V: av.dominio.com
El resto de registros DNS que deben encontrar el EDGE con del tipo SRV:
_sip._tls.dominio.com   SRV service location:
          priority       = 1
          weight         = 100
          port           = 443
          svr hostname   = sip.dominio.com
_sipfederationtls._tcp.dominio.com       SRV service location:
          priority       = 0
          weight         = 0
          port           = 5061
          svr hostname   = sip.dominio.com
 
_xmpp-server._tcp.dominio.com    SRV service location:
          priority       = 1
          weight         = 100
          port           = 5269
          svr hostname   = sip.dominio.com
Como vemos el FQDN del SVR HOSTNAME siempre es el mismo SIP.DOMINIO.COM (cada uno puede configurarlo como considere), de tal forma que el nombre del certificado SAN emitido para el EDGE será suficiente. De esta forma podemos federarnos con sistemas de mensajería pública o la autoconfiguración del cliente Lync sin necesidad de adquirir ningún otro certificado. Muchos proveedores de certificados, ya nos ofrecen packs específicos para Comunicaciones Unificadas, por ejemplo DigiCert, que nos ofrece un certificado SAN con 4 nombres por xxx €
Certificado_Comodin_Compatibilidad_1.jpg 
 Yo utilizo DigiCert por su rapidez (en menos de 15 minutos tengo los certificados disponibles),  la flexibilidad y soporte técnico. Pero vamos, existen infinidad de proveedores para adquirir vuestros certificados.
Por último debemos adquirir otro certificado (pero también podemos añadir el nombre wildcard en el certificado SAN) del tipo wildcard para publicar vía reverse-proxy (TMG, F5, KEMP) los distintos servicios Web de Lync (Conferencias, ABS, etc..), Exchange (Contactos de Exchange, Histórico de conversaciones, Presencia en función nuestra disponibilidad del calendario, etc..) y WAC (para poder publicar nuestras presentaciones de PowerPoint). Además, si adquirimos un certificado wildcard podemos publicar todos los servicios web que sean subdominios del dominio principal de primer nivel. Por ejemplo, si tenemos que publicar SharePoint, Exchange (OWA), Página Web con HTTPS, etc.. podemos hacerlo con el mismo certificado:
  • intranet.dominio.com
  • mail.dominio.com
  • blog.dominio.com
  • aplicacion.dominio.com
Comentaros también que como sabéis ahora el SharePoint, Exchange y Lync utilizan las Office Web Apps para mostrar en web los distintos documentos de Office. Por lo que si preparamos el servidor de WAC podemos utilizar el certificado wilcard (*.dominio.com) para publicar el servidor con el FQDN office.dominio.com para todos los servicios.
De esta forma, el cliente habrá invertido en un certificado que podrá reutilizar para cualquier otro servicio web que requiera cifrado.  Como los servicios expuestos a internet para Lync solo serían el EDGE y los servicios web del Front-END o Director pero mediante un reverse-proxy , solo debéis adquirir un certificado por servicio no por servidor. Si tenéis un pool de servidor EDGE, todos deben tener el mismo certificado externo porque todos gestionarán el mismo dominio, y para los servidores Front-END o Director será el reverse-proxy quien debe tener el certificado. Si tenemos un reverse-proxy en alta disponibilidad, es lo mismo que el EDGE, el mismo certificado debe estar instalado en todos los servidores o appliance de reverse-proxy.
Como os había comentado, los certificados para los servidores que no tengan acceso directo a internet, podéis (desde mi punto de vista debéis) utilizar los certificados de vuestra entidad certificadora interna (Windows Server 2012, Instalación de una CA). Por defecto todos los equipos del dominio tendrán el certificado raíz de vuestra CA como CA de confianza, por lo que no tendréis problemas de confianza en los certificado emitidos para vuestros servidores.
Como resumen, con un certificado SAN con tres nombres para el EDGE y un certificado wildcard para la publicación de servicios web cubriréis toda la implementación de Lync y más servicios.
Espero haber podido aclarar un poco más el tema de los certificado para Lync. Por último os dejo aquí un pequeño resumen de la compatibilidad de los certificados wildcard para nuestra implementación de Lync y la integración con Exchange en cuanto a la Mensajería Unificada:
Certificado_Comodin_Compatibilidad_2.jpg 
Aquís os dejo algunos artículos publicamos con anterioridad que vienen a cuento de este artículo y os podrían ser de utilidad:
 
Espero que os sea de utilidad!!!