En éste artículo no se explica como instalar Lync Server 2013, sino como mover el rol de Administración Central de Lync Server 2010 a Lync Server 2013 y como poder eliminar nuestro viejo front end de Lync Server 2010.

Lo primero y preferiblemente en un servidor dedicado como frontal de Lync, instala Windows 2012 Server en su versión Standard… también es posible sobre W2K8R2SP1, añade los requisitos Windows para Lync, en la forma de características del OS e instala Lync Server 2013.

Tras la instalación observamos que nuestro nuevo servidor se ha unido a la topología de Lync 2010, pero aun hay que mover el servidor de administración central que reside en Lync Server 2010 al servidor front-end 2013 si queremos como es lógico, quitar el servidor Lync Server 2010 heredado. A partir de aquí éste documento indica los pasos a seguir para migrar el servidor de administración central a Lync Server 2013.

Preparación de los servidores Front-End Lync 2013 antes de mover el Servidor de Administración Central.

A continuación, trato de detallar los pasos a seguir para preparar los servidores de Front-End, antes de mover el servidor de administración central de Lync Server 2010 a Lync Server 2013.

Para preparar un pool de servidor/es Front-End.
Para preparar el pool de servidores Front-End habrá que iniciar sesión, con un usuario con permisos administrativos y de sysadmin de base de datos SQL, en el equipo donde esté instalado como miembro del grupo RTCUniversalServerAdmins la consola de PowerShell de administración de Lync Server. Una vez dentro, se ejecutará una consola de PowerShell de administración de Lync Server. Cuando la ventana aparezca y cargue los comandos, se escribirá el siguiente comando:

Install-CsDatabase -CentralManagementDatabase -SQLServerFQDN -SQLInstanceName

Una vez ejecutado, habrá que comprobar que el estado del servicio Lync Server Front-End esté Iniciado.

Mover el servidor de administración central de Lync Server 2010 a Lync Server 2013

A continuación se detallan los pasos a seguir para realizar el movimiento del servidor de administración central de Lync Server 2010 a Lync Server 2013.
En el servidor Lync Server 2013, que será el nuevo servidor de administración central, habrá que iniciar sesión con un usuario con privilegios de administración y de administración de base de datos SQL. Dentro del servidor, la consola de PowerShell de administración de Lync Server estará instalada como miembro del grupo RTCUniversalServerAdmins. Una vez se haya logado dentro del equipo, habrá que abrir una consola de PowerShell de administración de Lync Server. En ella escriba el siguiente comando:

Enable-CSTopology

Es importante que el comando se ejecute correctamente, ya que en caso contrario, se producirá un error en la migración que puede dejar la topología sin ningún almacén de administración central. Si el comando no se ejecuta correctamente, solucione el problema evitando que el comando se complete antes de continuar.

Ahora, habrá que acceder al servidor Front-End o al pool de servidores Front-End y en un PowerShell de administración de Lync Server, habrá que escribir el siguiente comando:

Move-CSManagementserver

En la consola, se mostrarán los servidores, almacenes de archivos, almacenes de bases de datos y puntos de conexión de servicio del estado actual y el estado propuesto. Se leerá la información cuidadosamente para confirmar que el origen sea nuestro antiguo y todavía activo servidor de Lync Server 2010 y el destino el nuevo servidor con Lync Server 2013. Una vez se compruebe que todo es correcto, se escribirá ‘S’ para continuar o, en caso de que haya algún error, ‘N’ para detener la migración.

Una vez finalizada la migración, se revisarán si hay advertencias o errores que se hayan generado al ejecutar el comando move-CsManagementServer, con la intención de resolverlo lo antes posible para poder continuar con el proceso. Hecho esto, en el servidor Lync Server 2013, se abrirá el asistente para la implementación de Lync Server. Una vez abierto. Habrá que pulsar sobre “instalar o actualizar el sistema Lync Server”- Instalar o desinstalar componentes de Lync Server. Después, se hará clic en siguiente, entonces, se abrirá una pantalla de resumen. Una vez leído y revisado, se hará clic en el botón Finalizar para terminar.

El siguiente paso será ir al servidor Lync Server 2010 y abrir el asistente para la implementación de Lync Server. Hecho esto. Habrá que ir, como en la vez anterior, a Instalar o actualizar Lync Server, que se puede encontrar en el mismo sitio. Instalar o desinstalar componentes de Lync Server. Hecho esto, se pulsará en siguiente para continuar. Entonces, aparecerá una página de resumen, se revisará que todo esté correcto y para terminar, se hará clic sobre el botón Finalizar.
Para confirmar que se está efectuando la replicación con el nuevo almacén de administración central, en una consola de Powershell de administración de Lync Server, escriba:

Get-CSManagementStoreReplicationStatus

Es muy posible, que la replicación necesite bastante tiempo para actualizar todas las réplicas.

Quitar archivos de Lync Server 2010 del almacén de administración central después del movimiento.

Antes de realizar este paso. La replicación tiene que haber finalizado por completo y estar estable. Ya que si quita los archivos antes de completar la replicación, se interrumpirá el proceso de replicación y el servidor de administración central migrado quedará en un estado desconocido. Para comprobar y confirmar el estado de la replicación, en una consola de PowerShell de administración de Lync escribir el comando Get-CSManagementStoreReplicationStatus.

Una vez haya finalizado el movimiento del almacén de administración central, habrá que quitar los archivos del servidor Lync Server 2010. Para ello, habrá que seguir los siguientes pasos.

Se accederá al servidor Lync Server 2010 y se iniciará sesión con un usuario con permisos de administración de base de datos SQL Server. Se abrirá una consola de Powershell de administración de Lync Server y se ejecutará el siguiente comando:

Donde el <FQDN of SQL Server> es el servidor Back-End de Lync Server 2010 en una implementación de Enterprise Edition o el FQDN del servidor Standard Edition. Quedaría de la siguiente manera:

Uninstall-CsDatabase –CentralManagementDatabase –SQLServerFQDN Servidor – InstanceName Lync2010

Una vez replicados los cambios, podremos apagar nuestro viejo front end de Lync Server 2010.

Para aquellos que estemos en fase de migración de nuestros DC y DA, es muy recomendable elevar los niveles funcionales del bosque y dominio a un modo nativo, con independencia de los sistemas que corran en nuestro dominio si lo pensamos hacer a modo nativo 2012. En el caso de Windows Server 2012 requiere un nivel funcional de bosque de Windows Server 2003. Es decir, que para poder agregar un controlador de dominio que ejecuta Windows Server 2012 en un bosque de Active Directory ya existente, el nivel funcional del bosque debe ser Windows Server 2003 o superior. Esto significa que los controladores de dominio que ejecutan Windows Server 2008 R2, Windows Server 2008 o Windows Server 2003 pueden funcionar en el mismo bosque, pero los controladores de dominio que ejecutan Windows 2000 Server no son compatibles y bloquearán la instalación de un controlador de dominio que ejecute Windows Server 2012 y si el bosque contiene controladores de dominio que ejecutan Windows Server 2003 o posterior, pero el nivel funcional de dicho bosque sigue siendo Windows 2000, la instalación se bloqueará igualmente.

El nuevo nivel funcional de dominio de Windows Server 2012 permite un nueva característica: la compatibilidad de KDC con notificaciones, autenticación compuesta y protección de Kerberos La directiva de plantillas administrativas KDC tiene dos configuraciones (proporcionar siempre notificaciones y error de solicitudes de autenticación sin blindar) que requieren el nivel funcional de dominio de Windows Server 2012.

El nivel funcional del bosque de Windows Server 2012 no proporciona características nuevas, pero asegura que todo dominio nuevo creado en el bosque funcione automáticamente en el nivel funcional de dominio de Windows Server 2012. El nivel funcional del dominio Windows Server 2012 no proporciona otras características nuevas además de la compatibilidad de KDC con notificaciones, autenticación compuesta y protección de Kerberos. No obstante, garantiza que cualquier controlador de dominio que se encuentre en el dominio ejecute Windows Server 2012.

Después de establecer el nivel funcional del bosque en un determinado valor, no se puede revertir o bajar el nivel funcional del bosque, salvo en las siguientes excepciones: cuando eleve el nivel funcional del bosque a Windows Server 2012, puede bajarlo a Windows Server 2008 R2. Si la papelera de reciclaje de Active Directory no está habilitada, también puede bajar el nivel funcional del bosque de Windows Server 2012 a Windows Server 2008 R2 o Windows Server 2008 o de Windows Server 2008 R2 de vuelta a Windows Server 2008. Si el nivel funcional del bosque está establecido en Windows Server 2008 R2, no puede revertirse, por ejemplo, a Windows Server 2003.

Después de establecer el nivel funcional del dominio en un determinado valor, no se puede revertir o bajar el nivel funcional del dominio, salvo en las siguientes excepciones: cuando eleve el nivel funcional del dominio a Windows Server 2008 R2 o Windows Server 2012 y si el nivel funcional del bosque es Windows Server 2008 o inferior, tiene la opción de revertir el nivel funcional del dominio a Windows Server 2008 o Windows Server 2008 R2. Solo se puede bajar el nivel funcional del dominio de Windows Server 2012 a Windows Server 2008 R2 o Windows Server 2008, o de Windows Server 2008 R2 a Windows Server 2008. Si el nivel funcional del dominio está establecido en Windows Server 2008 R2, no puede revertirse, por ejemplo, a Windows Server 2003.

Más allá de los niveles funcionales, un controlador de dominio que ejecuta Windows Server 2012 proporciona características adicionales que no están disponibles en un controlador de dominio que ejecuta una versión anterior de Windows Server. Por ejemplo, un controlador de dominio que ejecuta Windows Server 2012 puede usarse para la clonación del controlador de dominio virtual, mientras que un controlador de dominio que ejecuta una versión anterior de Windows Server no puede hacerlo. Pero la clonación de controladores de dominio virtuales y las medidas de seguridad de controladores de dominio virtuales en Windows Server 2012 no tienen ningún requisito de nivel funcional.

Los Eventos 5004 y 5014 en entornos de replica DFSR, son eventos típicos de falta de comunicación con otro miembro DFSR.

Si nuestra topología de red NO emplea IPV6, es muy recomendable desmarcar de las tarjetas de red, todo lo alusivo a TCPIPV6

http://social.technet.microsoft.com/Forums/windowsserver/en-US/d27bd902-034e-4230-9516-0ede42308193/event-5014-dfsr-error1726

Pero también es muy necesario deshabilitarlo del registro mediante la creación/modificación de las siguientes claves de registro;

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

Value =DisableTaskOffload
Type = DWORD
Data = 1

Value =EnableTCPChimney
Type = DWORD
Data = 0

Value =EnableTCPA
Type = DWORD
Data = 0

Value =EnableRSS
Type = DWORD
Data = 0

Disable TCPIPV6
http://support.microsoft.com/kb/929852

KEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters
DisabledComponents to change the DisabledComponents entry – 0xffffffff

Finalmente desde línea de comandos ejecutemos los siguientes comandos netsh;

netsh int tcp set global RSS=Disabled
netsh int tcp set global chimney=Disabled
netsh int tcp set global autotuninglevel=Disabled
netsh int tcp set global congestionprovider=None
netsh int ip set global taskoffload=Disabled
netsh int tcp set global timestamps=Disabled
netsh int tcp show global

Cuando Migramos nuestra infraestructura o instalamos un Domain Controller, por defecto se replica el recurso “sysvol” con FRS, pero como es sabido a partir de ADDS 2008, sysvol tiene su replicación como DFRS, con muchas ventajas. Como decía, por defecto la replica de sysvol es mediante FRS, si queremos migrar la réplica a DFSR, tenemos que realizar unos pasos más para poder migrar este tipo de replicación a DFSR, estos pasos los tenemos que realizar por cada dominio de nuestro Forest, es decir que si tenemos mas de un dominio, tenemos que repetir estos pasos de migración en cada dominio que terminemos de migrar a 2008R2 ó 2012, los pasos son;

Prerrequisitos de Migración

1. Verificar que la replicación de AD es correcta en todos los Domain Controllers de la infraestructura.

2. Realizar el proceso de Domain Functional Level a “Windows Server 2008″ , “Windows Server 2008 R2″ ó «Windows Server 2012», según la versión que estemos implementando.

3. Verificar que el directorio SYSVOL existe en todos los Domain Controllers y el mismo esta replicando mediante FRS.

4. Backup del directorio SYSVOL.

5. Chequear que el servicio “DFS Replication Service” este instalado y corriendo con la configuración en “Automático”, dicho servicio este corriendo en todos los Domain Controllers del dominio.

Tipos de estados en el proceso de migración

Global Migration State – A complete process

Local Migration State – Process on each DC to achieve the Global Migration State

Estados Estables / Estados Globales de Migración

STATE 0 START
STATE 1 PREPARED
STATE 2 REDIRECTED
STATE 3 ELIMINATED

Estados de Transición / Estados Locales de Migración

STATE 4 Preparing
STATE 5 Waiting for initial sync to complete
STATE 6 Redirecting STATE 7 Eliminating
STATE 8 Undo redirecting
STATE 9 Undo preparing

Migracion: 0-4-5-1-6-2-7-3
Vuelta atras: 2-8-1-9-0

Cuando el estado de migración pasa a estar en estado 3, ya no hay posibilidad de volver atrás ni revertir la situación a un estado anterior, con lo cual, correr el comando que para a un estado “3″ tenemos que estar seguros que queremos para nuestra infraestructura, utilizar DFSR para replicación de nuestro SYSVOL.

Comandos de Migración

1. DfsrMig /CreateGlobalObjects

Este comando crear los “global Object” o configuración en Active Directory, para comenzar a utilizar DFSR como servicio de Replicación.

2. DfsrMig /SetGlobalState

Bajo este comando, se agrega al mismo el tipo de estado al que se quiere pasar según siguientes líneas:

0 (‘START’ state)
1 (‘PREPARED’ state)
2 (‘REDIRECTED’ state)
3 (‘ELIMINATED’ state)

3. DfsrMig /GetGlobalState

Nos detalla en qué estado Global está el proceso de migración, esta información es recibida desde nuestro Active Directory, con lo que es importante tener los conceptos de replicación presentes.

4. DfsrMig /GetMigrationState

Nos detalla en qué estado de Migración están todos los Domain Controllers, detallando cada uno y el estado del mismo, esta información es recibida desde nuestro Active Directory, con lo que es importante tener los conceptos de replicación presentes.

A continuación, los resultados y los comandos que tenemos que ir ejecutando serían estos;

Iniciar la migracion:
DFSRMig /CreateGlobalObjects
Create the ReplicationGroup, Content object, ContentSet, and Topology objects

msDFSR-GlobalSettings object under System
msDFSR-ReplicationGroup object under “msDFSR-GlobalSettings”
msDFSR-Content under
msDFSR-ReplicationGroup
msDFSR-ContentSet object under
msDFSR-Content objecte
msDFSR-Topology object under
msDFSR-ReplicationGroup object Sets GlobalState to 0

Preparar estado:

DfsrMig /SetGlobalState 1

The DFS Replication service creates the SYSVOL_DFSR folder

ROBOCOPY copies the contents of SYSVOLdomain to the location SYSVOL_DFSRdomain

Local Active Directory Objects are created. These are ‘Member’, ‘LocalSettings’, ‘Subscriber’, and ‘Subscription The migration local state is set to 5 (MIG_STATE_LOCAL_WAITING_FOR_SYNC) When DFS Replication completes Initial Sync, the Local State is set to 1 (’PREPARED’). Confirm that all domain controllers are in the ‘PREPARED’ state DfsrMig /GetMigrationState

Pasar a estado de “Redirección”

DfsrMig /SetGlobalState 2

The goal of this state is to move the live SYSVOL share from the old SYSVOL folder that NTFRS is replicating to the new SYSVOL folder that the DFS Replication service is replicating. From this point onwards, SYSVOL replication will depend on DFS Replication service Change the SYSVOL patyh in the registry to point to the new location Verify that DFS Replication global migration state is set to ‘REDIRECTED’ DfsrMig /GetGlobalState Confirm that all domain controllers are in ‘REDIRECTED’ state DfsrMig /GetMigrationState

Pasar a estado de “Eliminación”

DfsrMig /SetGlobalState 3

The goal of this state is to delete the NTFRS SYSVOL replica set and delete the old SYSVOL folder Deletes the NTFRS SYSVOL Active Directory configuration objects named ‘Subscriptions’ and ‘Settings’ Verify that the DFS Replication global migration state is set to eliminated DfsrMig /GetGlobalState

Una vez finalizado este proceso de migración, cuyo tiempo depende la cantidad de Domain Controllers que tengamos en nuestra infraestructura y la latencia de los mismos, podemos verificarlo desde nuestro Active Directory. CN=Topology,CN=Domain System Volume,CN=DFSR-GlobalSettings,CN=System,DC=Root1,DC=es,DC=inet donde tendremos que ver, el listado de todos nuestros Domain Controllers los cuales ya estarán usando DFSR como replicación de SYSVOL.

ODX – Windows Offloaded Data Transfer

El gran salvador en la transferencia de datos, podríamos decir que es un concepto derivado de la API de VAAI de Vmware y que llega a Windows Server 2012 muy mejorado, su propósito es evitar que un intermediario, en este caso el servidor, haga funciones de buffering para los datos que se transfieren entre dos equipos externos.  Si configuramos bien ODX, conseguiremos aligerar mucho el movimiento de datos y aliviar la carga en los equipos tanto si hablamos de servidores físicos como virtuales.

ALOJAMIENTO ORIGEN -> SERVIDOR -> ALOJAMIENTO DESTINO

La implementación de ODX permite que el servidor en lugar de intermediar en el flujo de datos y tener que manejar un buffer de información sólo actúa para facilitar «las coordenadas de origen y destino» pero el flujo de datos real se realiza entre las dos fuentes implicadas siempre que soporten esta tecnología.

Para usar ODX, el entorno tanto de almacenamiento como de software deben cumplir una serie de requisitos de hardware y software, el siguiente enlace es bastante didáctico; http://technet.microsoft.com/es-es/library/jj200627.aspx

Centrémonos en el software, que es más nuestro, sistema operativo, W2K12 y W8, ojo con los antivirus y si además somos fanáticos de la seguridad, incompatible con el cifrado en unidades BitLocker y si además has querido probar el nuevo sistema de archivos resistente a errores ReFS, olvídate y de FAT mejor ni hablamos, por que no se admiten ninguno de los dos, tendrem0s que formatear a 64KB en NTFS, lo mejor para alojar máquinas virtuales con extensión vhd ó vhdx para hyper-v en W2K12.

Hyper-V en Windows Server 2012 trae una nueva funcionalidad denominada SHARED NOTHING LIVE MIGRATION, esto significa que las máquinas físicas no deben compartir nada más que una conexión de red en donde las máquinas virtuales a migrar, se mueven en vivo de un chasis a otro con todo con las aplicaciones y sesiones que están ejecutando al momento de la migración.

Antes de Windows Server 2012 para hacer una migración de VMs entre chasis se necesitaba tener un almacenamiento compartido entre los varios servidores físicos, ahora sólo se necesita tener una red entre las «n» máquinas físicas con Windows Server 2012 y las VMs se migran en vivo -por la red- al almacenamiento local, del volumen local 1 al volumen local 2. Importante tener en la cabina el firmware para ODX.

Si además nuestro almacenamiento cuenta con TRIM, que es la manera en que la cabina libera el espacio (en la cabina) cuando borras ficheros en el filesystem tendremos una solución global para la transferencia de datos.

Es decir, borras ficheros, y el OS le informa amablemente a la cabina, que ese espacio lo puede liberar (en la cabina) y seguir jugando cómodamente al thin provisioning reasignando el espacio disponible (en la cabina) de un volumen a otro de los que presenta por arriba a los diferentes hosts que consumen volúmenes de ella.

Se me ocurre advertir, que el proceso de borrado se puede quedar a medias. Para paliar el problema tenemos dos opciones, deshabilitar el TRIM en el OS, con lo que el proceso descrito arriba no se llevaría a cabo y nuestro flamante Windows 2012 se comportaría como un Windows Server anterior. El comando desde un Power Shell es:

fsutil behavior set disabledeletenotify 1 

Pero mejor que deshabilitar TRIM y ODX, en mi post anterior, Roll-up de Hyper-V sobre W2K12 explico los varios fix ó parches relacionados con todo esto del TRIM el ODX, los backups y los CSVs.

Fundamentalmente se consigue que Windows dialogue con la cabina para que la carga que debería hacer en front-end se encargue de hacerla automáticamente la cabina en back-end y así evitar el round-trip time de negociación entre Windows y la cabina.  De esta manera los puertos de front-end quedan libres para el resto de servidores lo que permite mantener buenos tiempos de respuesta siempre que los niveles de utilización de caché estén a niveles normales.

Slide útil de ODX en almacenamiento 3PAR de HP;

En entornos de hyper-v bajo Windows 2012, con y sin CSV, existen algunas revisiones fundamentales de roll-up.

Por ejemplo al realizar Live Migration, en ocasiones se pueden producir un bugcheck D1 DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1), la recomendación de Microsoft para resolver el problema, pasa por instalar el roll-up KB2855336, publicado en julio de 2013, fijaos que destaco en rojo roll-up, por que el problema surge al instalar la versión original del KB2855336, y ahora tras aparecer el problema se ha vuelto a generar el paquete y se ha sacado un fix nuevo con el paquete corregido. Aquí os adjunto varios KBs imprescindibles, junto con las notas técnicas y el acceso a la descarga del roll-up;

1.- KB2855336

Éste KB, incluye otros dos KBs (2862073 y 2866029) 0x000000 D1″ Stop error when you perform a live migration of a virtual machine on a Windows Server 2012-based cluster;

http://support.microsoft.com/kb/2866029/en-us

The issue is fixed in the reoffered update rollup 2855336;

http://support.microsoft.com/kb/2855336/

2.- KB2870270

Éste roll-up hotfix reemplaza al KB2848344.

El problema que resuelve este fix viene de hace unos meses en los que se detectó en cluster w2k12 con CSV event Id  con 5120 STATUS_IO_TIMEOUT y uno de los workaround era deshabilitar TRIM y ODX

El propósito de este hotfix es la corrección para TRIM y ODX. Con esta revisión del roll-up, ya no es necesario desactivar TRIM o ODX

Muchos sistemas de almacenamiento ofrecen la posibilidad de habilitar ODX, para que desde los host de Windows 2012 podamos hacer Live Migration, la VM se copia por intercambio de token, con SHARED NOTHING LIVE MIGRATION, esto significa que las máquinas físicas no deben compartir nada más que una conexión de red en donde las máquinas virtuales a migrar, se mueven en vivo de un chasis a otro con todo con las aplicaciones y sesiones que están ejecutando al momento de la migración. Con ODX las VMs se migran en vivo -por la red- al almacenamiento local, del volumen local 1 al volumen local 2, siempre y cuando la cabina, tenga el firmware para ODX y si ese es el caso;

Update that improves cloud service provider resiliency in Windows Server 2012;

http://support.microsoft.com/kb/2870270

3.- KB2869923

Hyper-V, Clustering y DPM de HP. Este fix es crítico para cualquier implementación de clústeres de Hyper-V que está siendo respaldada por el software de backup de HP, DPM (Data Protector Manager)
Durante el proceso de copia de seguridad de un volumen CSV puede hacer que se detengan algunos recursos;

http://support.microsoft.com/kb/2869923

Éste es otro fix crítico, que si bien no es tan nuevo, como los dos anteriores, es un alto generador de llamada CSS y debe ser conocido e implementado.
No se puede acceder a un recurso que está alojada en un equipo con Windows 8 o Windows Server 2012 con CSV

http://support.microsoft.com/kb/2838043