Rollback Forest/Domain functional level o como volver atrás el nivel funcional de tu Dominio o Foresta

Si elevaste el nivel funcional de tu dominio y tenias aplicaciones legacy que no son compatibles… bueno, no hay solución…

Sería un post muy corto, y triste, si eso aún fuese cierto.

Por suerte para nuestras aplicaciones legacy, con la introducción de Windows Server 2008 también se incluyó la capacidad de hacer rollback a nuestro nivel funcional ya sea tanto de nuestro dominio como de nuestra foresta.

Para poder realizar este cambio deberá realizar los siguientes pasos:

 

1. Si tienes alguna version inferior a Windows Powershell 3.0 deberás importar el módulo de AD (o abrir directamente el acceso directo de Active Directory Powershell):

Import-Module –Name ActiveDirectory

2a. Verificar el nivel actual del Forest

Get-ADForest | ft Name,ForestMode –Autosize

2b. Verificar el nivel actual del Dominio

Get-ADDomainMode | ft Name,DomainMode – Autosize

3a. Cambiar el nivel funcional del Forest

Set-ADForest –Identity “MiForesta.com” –ForestMode Windows2008Forest

 

3b. Cambiar el nivel funcional del Dominio

Set-ADDomain –Identity “MiDominio.com” –ForestMode Windows 2008Domain

 

4. Verificar el nivel actual del dominio o de la foresta utilizando el punto 2a o el 2b dependiendo del caso.

 

Importante: Aún el soporte oficial de Microsoft estipula que solo se puede elevar el nivel funcional de un dominio o foresta productiva, por lo que el procedimiento descrito solo debe ser usado en ambientes de laboratorio o bajo un caso de soporte de Microsoft en donde se haya evaluado el impacto de realizar este rollback.

Anuncios

Elevando el nivel funcional de tu dominio? lee esto antes de comenzar

Elevar el nivel funcional de un dominio es un proceso simple de realizar que no debiese requerir mayor planeamiento que evaluar el impacto de las aplicaciones legacy que pudiesen requerir un nivel funcional inferior.

Sin embargo a veces esto no es del todo cierto… Si vamos a elevar nuestro nivel funcional desde Windows Server 2003 a Windows server 2008/2008R2/2012/2012R2 debemos considerar que la contraseña del servicio KRBTGT (Key distribution service center account) será reseteado.

Si bien esto generalmente no tiene mayor impacto (incluso es parte de nuestro procedimiento de recuperación de desastres) sobre las aplicaciones, hay situaciones en las que las aplicaciones que consumen nuestro dominio de ActiveDirectory no pueden autenticar a los clientes conectados (Hello Exchange!!).

Debido a esto debemos tener la siguiente precaución al elevar el nivel funcional de nuestro dominio:

 

1. Luego de elevar el nivel funcional, debemos conectarnos a nuestro servidor de Active Directory de Windows Server 2003 en busca de los eventos EventID 14 KDCEVENT_NO_KEY_INTERSECTION_AS (Microsoft-Windows-Kerberos-Key-Distribution-Center) y EventID 10 KDCEVENT_KRBTGT_PASSWORD_CHANGE_FAILED (Microsoft-Windows-Kerberos-Key-Distribution-Center).

2. Si no vemos estos eventos logueados luego de unos minutos (asegurense que hay usuarios iniciando sesión o utilizando Exchange…), debemos realizar nuestras pruebas para asegurarnos de que esta todo bien.

 

3. Si vemos estos eventos… mala suerte en el trabajo, buena suerte en el amor (o algo así), debemos resolver nuestro problema de autenticación de usuarios simplemente reiniciando el servicio de KDC en todos nuestros controladores de dominio.

 

¿Como?

  • Opción 1: Debemos ir a la consola de servicios (Services.msc) y reiniciar el servicio Kerberos Key Distribution Service.
  • Opción 2: Utilizar una consola de comandos (CMD) con permisos administrativos y ejecutar la linea “SC \\ComputerName Stop kdc” (en donde ComputerName es nuestro controlador de dominio) y luego “SC \\ComputerName Start kdc”.
  • Opción 3: Utilizar Powershell “Get-Service KDC –ComputerName Computer | Restart-Service” (en donde Computer es nuestro controlador de dominio).
  • Opción 4: Utilizar Powershell y hacer el cambio masivo en todos los controladores. Personalmente no recomiendo esta opción ya que podría dejar usuario sin servicio durante el reinicio de los servicios (valga la redundancia). Siempre es mejor realizar el proceso de manera manual. Pero sin son Vikingos y no le temen a nada, esta sería la forma de hacerlo:
    • Abrir un Windows Powershell con permisos administrativos
    • $DC=Get-ADDomainController
    • Get-Service KDC –ComputerName $DC | Restart-Service

Happy updates!!

Problema emergente en el login de usuarios de Exchange al instalar KB3002657

El día de ayer nos informaron de un problema emergiendo en los usuarios de Exchange, luego de que se instale la actualizacion KB3002657 en controladores de dominio de Windows 2003.

Esta actualización incluye un parche para NETLOGON.dll que resuelve una vulnerabilidad en Windows que permite realizar spoofing desde un atacante que utilice un equipo que es parte del dominio de Windows.

Al instalar esta actualización en servidores de Windows Server 2003 (y se han reportado problemas tambien en algunos servidores 2008 y 2012) los requests de autenticación fallan con eventos logueados de tipo Event ID 4625 en la fuente Microsoft-Windows-Security-Auditing.

En el caso de los usuarios de Exchange, los que utilicen el servidor afectado para el inicio de sesión no podrán hacerlo, ya sea por OWA o a través de Outlook.

Al apuntar a otro servidor no afectado por el problema, los usuarios podrán iniciar sesión.

 

Si aún no lo han instalado, deberán esperar a que se libere una version 2 de la actualización.

Si ya lo instalaron y presentan problemas de autenticación, es necesario que se comuniquen con la atención de soporte de Microsoft para obtener un parche temporal que resuelve el problema generado. En el caso de los clientes con soporte premier (http://premier.microsoft.com) deberán escalar con su TAM para una resolución más rápida.

Por el momento no se recomienda la desinstalación de la actualización ya que podría generar problemas de seguridad debido al tipo de ataque que soluciona en una primera instancia. Si no cuenta con la posibilidad de crear casos de soporte y no ha actualizado todos sus servidores, es recomendado que aisle los servidores afectado en orden de asegurar el login de sus clientes hasta la salida de la actualización oficial que corrija este problema.

Cambio de Hora en Chile – Nueva zona horaria –03:00

En Chile acabamos de pasar de una zona horaria Santiago –04:00 a Santiago –03:00 en orden de eliminar los cambios generados por el horario de verano (que atrasaba o adelantaba en una hora para el ahorro energético).

Si bien hemos pasado por muchos periodos de reacondicionamiento de la fecha en la que realiza el cambio de hora, es la primera vez que nos cambiamos de huso horario, al parecer, de manera definitiva. La razon de esto es que el Gobierno de Chile a definido que el ahorro energético se ha vuelto marginal y por otro lado, los sistemas se han vuelto cada vez más complejos en cuanto a su requerimiento de “perfeccion horaria”, por lo que estos cambios, generan impacto negativo en muchos negocios.

 

El cambio de hora y zona horaria, si bien no debiese impactar mayormente las aplicaciones ya que estamos en la misma hora que la definida en el huso horario –03:00, si tiene factores estéticos y de funcionalidad entre sistemas que piensan que nuestro huso horario es –04:00 y otras que piensan que es –03:00.

Debido a esto, les resumo la situación de Exchange y Outlook:

 

________________________________________________________________

ACTUALIZACION

Ya fue liberado el Rollup Update nro 9 para Exchange 2010 con Service Pack 3 que incluye, entre otras cosas, la actualizacion para la zona horaria de Chile y Mexico.

Pueden descargar el RU9 desde el siguiente Link: https://support.microsoft.com/en-us/kb/3030085 

Importante 1: Si los servidores de Exchange tienen  Spanish Chile en sus Regional Settings (configuración regional) el RU9 no se instalará correctamente. Es necesario cambiarlo a English United States para que no tengan problemas.

Importante 2: Al instalar la actualización es posible que las agendas tengan problemas con la hora de la cita. Para esto deberán seguir el instructivo de corrección detallado en: https://support.microsoft.com/en-us/kb/3048372 

________________________________________________________________

 

 

Windows Server y Desktop: Información detallada en http://support2.microsoft.com/gp/cp_dst/es-cl. Lo único que deben hacer los usuarios es instalar el hotfix http://support.microsoft.com/en-us/kb/3039024/es-cl disponible para todas las plataformas actuales de Windows Server y Windows Desktop (Si, XP tambien está incluido 🙂 )

 

Microsoft Exchange Server 2010/2013: Se está liberando una nueva actualizacion acumulativa (la nro 8) para Exchange 2013 que ya incluye el cambio en la zona horaria de Santiago. Esperen una próxima actualización acerca del rollup update para Exchange 2010.

 

Clientes Outlook: Los clientes Outlook utilizan la llave de registro de Windows asociada al TimeZone para leer su información de zona horaria, por lo que en este caso si ya está instalado el update no deben realizar ningún paso posterior.

 

Clientes OWA: Los clientes de OWA verán aún en Exchange la información de zona horaria en –04:00 en vez de –03:00, sin embargo el servidor utiliza la informacion del registro para actualizar la informacion de la agenda, por lo que es posible que haya una disparidad entre dos usuarios con calendario compartido, pero si todos los servidores (incluyendo los extranjeros) están actualizados, se debiese ver la hora correctamente.

Adicionalmente al crear un nuevo usuario, la primera vez que ingrese a OWA y le sea preguntado su zona horaria, verán Santiago –04:00.

 

Clientes ActiveSync: El mismo síntoma que los usuarios de OWA, aunque menos notorio, ya que activesync no permite ver calendarios compartidos.

 

Clientes POP e IMAP: No se verán impactados por el problema.

 

En el caso de otras aplicaciones, no hay información aún al respecto, pero nos encantaría oír sus comentarios. Así que sientanse libres de comentar y trataré de responder lo antes posible.

 

Happy updates!!

Conexión de teléfonos IP hecho simple con LYNC (4 de 4)

Bien, para terminar esta serie de configuraciones solo nos queda validar a nivel de Lync que todo esta trabajando correctamente.

Si no han completado los otros pasos, los pueden revisar en:

https://caguileran.wordpress.com/2011/07/20/publicacin-de-opciones-dhcp-hecho-simple-con-lync-1-de-4/

https://caguileran.wordpress.com/2011/08/08/conexin-de-telfonos-ip-hecho-simple-con-lync-2-de-4/

https://caguileran.wordpress.com/2011/08/19/conexin-de-telfonos-ip-hecho-simple-con-lync-3-de-4/

 

Las recomendaciones

Opción NTP

Si bien los telefonos de Lync, no requieren mandatoriamente que configuremos la opción de NTP, es super recomendado para poder acelerar el login de estos telefonos que le proveamos de esta opcion. Para hacer esto y pensando en que ya quedaron “peritos” en la configuración de DHCP simplemente deben ir a “Scope Options” – clic derecho y elegir la opción “Configure Options”, buscar la opción 4 y colocar el nombre del servidor (teniendo cuidado de apretar en “resolve”) o directamente la IP y aceptar la nueva entrada (dando clic en OK)

image

 

Configurar a Lync para que entregue las opciones faltantes (recomendado para sucursales)

Muchas veces los DHCP los provee la central pero en las sucursales no hay quien provea de estas opciones, por lo que un reemplazo a esto es que el servidor de Lync en la sucursal provea de las opciones DHCP necesarias para que el teléfono se registre.

Set-CSRegistrarConfiguration –Identity SERVER -EnableDHCPServer $true

En este caso, si bien aún necesitamos un servidor DHCP que provea de IPs, no es necesario que este servidor cuente con todas las opciones de LYNC, siendo solo necesaria la Opción 120 que es la que apunta al servidor de Lync front end.

 

 

La prueba

En estos momentos, si hemos seguido al pie de la letra la guía, ya podríamos probar el buen funcionamiento de nuestra configuración.

Para esto volvemos a abrir una consola CMD y buscamos nuevamente la aplicación DHCPUtil.exe, pero esta vez utilizamos solo el switch –EmulateClient

image

 

El resultado debería ser satisfactorio para nuestra infraestructura y nuestro orgullo (No lo ejecuten desde el mismo servidor DHCP, ejecútenlo desde el servidor de Lync por ejemplo).

image

 

Con esta última prueba ya pueden estar seguros que sus teléfonos correrán como avión y podrán hacer llamadas sin problemas.

 

Saludos y ya nos veremos en otras configuraciones!!!!!!!

Categorías:Uncategorized

Conexión de teléfonos IP hecho simple con LYNC (3 de 4)

Ya he recibido mucha presión para continuar con el documento Risa así que me veo forzado a publicar la parte 3 de 4 jajajaja.

Si no han visto las otras dos partes les recomiendo que les echen un vistazo:

https://caguileran.wordpress.com/2011/07/20/publicacin-de-opciones-dhcp-hecho-simple-con-lync-1-de-4/

https://caguileran.wordpress.com/2011/08/08/conexin-de-telfonos-ip-hecho-simple-con-lync-2-de-4/

En este post lo que haremos será obtener las opciones de DHCP que debemos configurar y probar desde Lync si tenemos todo configurado correctamente emulando la conexión de un teléfono al servicio.

En el caso de la configuración de DHCP es normal que nos sintamos aproblemados ya que las configuraciones, si bien parecen correctas, no nos permiten que los equipos se conecten. Esto es por que las configuraciones deben ser entregadas en hexadecimal, lo que obviamente complejiza la tarea.

 

Configuración sobre DHCP en Windows 2008

Esta es la configuración más simple ya que tenemos un montón de herramientas listas para hacerlo. Una de las ventajas de tener nuestros sistemas actualizados es que siempre se diseñan soluciones para las últimas versiones.

1. En el servidor Windows 2008 que cuenta con el rol de DHCP se debe copiar el instalador de

VC++ 2008 x64 (vcredist_x64.exe) que se encuentra dentro del cd de Lync.

image

2. Adicionalmente se debe copiar los archivos DHCPUtil.exe y DHCPConfigScript.bat en el servidor de DHCP. Estos dos archivos están ubicados en “C:\Program Files\Common Files\Microsoft Lync Server 2010”.

image

3. Una vez copiados, vamos a una CMD ejecutada con permisos administrativos y ejecutamos la línea (obviamente abierta la consola vamos hasta el directorio en donde dejamos la herramienta DHCPUtil.exe):

DHCPUtil -SipServer <Pool FQDN> -WebServer <Web Components FQDN>

En donde:

SIPServer: Es el FQDN del servidor de Front End. En caso de la versión estándar es el nombre del servidor, en el caso de una versión empresa es el nombre del pool.

WebServer: Es el FQDN del servicio web. En caso de la versión estándar es el nombre del servidor, en el caso de una versión empresa es el nombre del sitio web asociado al balanceador por hardware.

En mi caso seria algo como esto:

DHCPUtil -SipServer adocs.ocsdemo.com –WebServer adocs.ocsdemo.com

El resultado será algo como esto:

image

 

4. Teniendo la información lista y en hexadecimal, tal y como la necesitamos, podemos reutilizar la línea de comandos y le agregamos un switch más para cargar directamente todas las opciones (no es necesario hacer el paso anterior en 2008 pero nos sirve tener los resultados escritos para las otras opciones):

DHCPUtil -SipServer adocs.ocsdemo.com -WebServer adocs.ocsdemo.com –RunConfigScript

 

Y el resultado será el siguiente:

image

 

Lo que hace este switch es tomar los resultados de la primera línea y aplicarlos al servicio DHCP inmediatamente.

Si vamos al servidor, podremos ver que ya tenemos las opciones DHCP configuradas.

image

 

Configuración sobre DHCP en Windows 2003

En este caso no podremos cargar automáticamente los resultados por lo que tendremos que seguir los pasos de la guía anterior desde el 1 al 4 hasta tener la información en hexadecimal.

Option 120:
000561646F6373076F637364656D6F03636F6D00

Vendor Class Identifier: MS-UC-Client
Option 43 (for vendor=MS-UC-Client):
        sub-option 1 <UC Identifier>: 4D532D55432D436C69656E74
        sub-option 2 <URL Scheme>: 6874747073
        sub-option 3 <Web Server FQDN>: 61646F63732E6F637364656D6F2E636F6D
        sub-option 4 <Port>: 343433
        sub-option 5 <Relative Path for Cert Prov>: 2F4365727450726F762F43657274
50726F766973696F6E696E67536572766963652E737663

 

1. Con la información de más arriba, vamos a nuestro servidor de DHCP y debemos agregar manualmente estas opciones. Para esto necesitamos abrir la MMC de DHCP.

2. Una vez abierta debemos ir a “IPv4” – Clic derecho y elegir “Define Vendor Classes…

image

3. Ir a Add y agregar la primer descripción del vendor (MSUCClient) de la siguiente forma

4D532D55432D436C69656E74 (la traducción de esta línea es MS-UC-Client) y dan clic en OK y cierran la ventana.

image

4. Debemos ir a “IPv4” – Clic derecho y elegir “Set Predefined Options…

image

5. En Options Class… elegimos la que recien creamos “MSUCClient” y damos clic en Add

image

6. En Name colocar UCIdentifier, En Data Type “Binary”, En Description “UC Identifier

image

7. Hacer lo mismo para todas las opciones:

Name Data Type Code Description
UCIdentifier Binary 1 UC Identifier
URLScheme Binary 2 URL Scheme
WebServerFqdn Binary 3 Web Server FQDN
WebServerPort Binary 4 Web Server Port
CertProvRelPath Binary 5 Cert Prov Relative Path

8. Una vez hecho esto, nos queda la opción 120 para terminar. Para esto debemos ir de nuevo a “Set Predefined Options” pero ahora dejamos todo igual y simplemente damos clic en “ADD".

image

9. Ahora configuramos la opción como:

Name Data Type Code Description
UCSipServer Binary 120 Sip Server Fqdn

image

10. Una vez terminado tenemos que poblarlas. Para esto debe ir al scope que conectan los teléfonos, dar clic derecho en Scope Options y elegir Configure Options…

image

11. Ir al Tab Advanced, en vendor Class elegir “MSUCClient”. Aparecerán las opciones que creamos recién y en donde con la información que obtuvimos más arriba debemos poblar (aquí se pillaran con la info traducida por el lado ASCII). Recuerden que deben poblar y tickear las 5 opciones!!!!

image

12. Ahora vamos al tab General y buscamos la opción 120 y la cargamos igual que las otras.

image

13. Detenemos e iniciamos el servicio de DHCP para forzar el reciclado de las reglas y ya estamos listos con la configuración para DHCP en Windows 2003!!!!!!.

 

Configuración de DHCP para Cisco

 

En este caso no reinventaré la rueda ya que Elan generó un excelente post con todos los pasos para la publicación (incluso algunos que no conocía) de las opciones sobre los switches Cisco.

http://www.shudnow.net/2011/05/02/configuring-lync-dhcp-using-cisco-dhcp-servers-vlan-and-pin-auth/ 

 

Espero que les sirva de mucho esta guía y espero como siempre sus buenos comentarios.

La última parte simplemente es la prueba de que esto funcionó y adicionalmente una recomendación de agregar a las opciones DHCP el servidor NTP para acelerar el login de los equipos.

Categorías:Lync Server Etiquetas: , ,

Conexión de teléfonos IP hecho simple con LYNC (2 de 4)

Continuando con nuestra configuración, ya pasamos por lo más rápido, que es crear el registro NTP necesario en nuestro DNS para que los teléfonos puedan actualizar la hora. Si no lo leyeron, se los recomiendo como inicio (además hay un resumen de que queremos lograr):

https://caguileran.wordpress.com/2011/07/20/publicacin-de-opciones-dhcp-hecho-simple-con-lync-1-de-4/ 

Para los modelos de teléfono Polycom CX600/CX500/CX3000 (CX700 si permite escribir usuario y clave) y Aastra 6725ip/6721ip necesitaríamos un desgaste muy alto para poder escribir nuestro usuario y clave para poder validar el equipo con nuestro numero (debido a que no tienen teclado alfanumérico que nos simplifique la vida). Debido a esto debemos revisar 3 importantes cosas en nuestra infraestructura de Lync:

1. Habilitar el uso de PIN (o NIP en español) para los dispositivos:

Activar:

Set-CsWebServiceConfiguration -Identity Global -UsePinAuth $true

Chequear:

Get-CsWebServiceConfiguration | Select Identity,UsePinAuth

El resultado debería ser el siguiente:

image

 

2. Revisar la configuración dela página de servicio de conferencias de Lync: En esta página nuestros usuarios pueden administrar la configuracion de conferencias a través de lync y adicionalmente pueden resetear su NIP.

a. Ir al topology builder y confirmar que el sitio web esta publicado, sino publicarlo bajo un nombre descriptivo (normalmente dialin.dominio.com):

image

 

3. Verificar que los usuarios conozcan su clave de conferencias.

a. Ingresar al sitio publicado (en este ejemplo https://dialin.ocsdemo.com)

image

b. Hacer Sign-In con las credenciales de dominio

image

c. Si es un nuevo usuario debe configurar un NIP

image

image

 

 

NOTA IMPORTANTE: Si se dan cuenta en “Phone Extension” se puede ver que el usuario cuenta con un numero de telefono y un numero de anexo. Normalmente si vamos a utilizar la configuración manual en el teléfono, lo más recomendable es que se configure una extension en las propiedades de los usuarios, para evitar que tengan que estar validandose con su numero completo.

Para lograr esto simplemente deben ir a las propiedades del usuario y configurar su Line URI como:

tel:+5621234567;ext=4567  (en donde “tel” es el numero completo y “EXT” es la extensión del usuario)

Debería verse así:

image

 

Esto termina la parte 2 de nuestra guía para publicar teléfonos IP en Lync. Debido a los comentarios me apresurare en terminar la siguiente parte que es la configuración DHCP para Windows 2003, 2008 y switches.

 

saludos

Categorías:Lync Server Etiquetas: ,