martes, 18 de junio de 2013

Problemas con OWA después de instalar Exchange Server 2010 SP2

Después de que instalamos SP2 de Exchange Server 2010 en algunos sites-AD, nos encontramos con el siguiente problema: cuando un usuario que estaba en un site-AD con servidores CAS que aún tenian SP1 intentaba conectarse a través de un servidor con SP2 (tanto desde Internet como internamente), el OWA mostraba la página web con algunos faltantes (Figura 1). Pero si entrábamos directamente al CAS del mismo site al que el usuario pertenece, entonces no teniamos problemas.
 
Figura 1
 
 
Entonces seleccionamos uno de los objetos faltantes y vimos sus propiedades (Figura 2). Allí verificamos que en nuestro server CAS con nombre CASEX10 el objeto que no se mostraba se esperaba encontrar en el directorio virtual /owa/14.1.287.0/themes/resources.

Figura 2
 
 
Ese directorio era diferente en SP1 y en SP2 (Figura 3), pues en el equipo con SP2 faltaban los subdirectorios "scripts" y "themes". Dentro de "themes\resources" estaban los archivos que no se mostraban correctamente.

Figura 3
 
En el Event Viewer (Figura 4) encontramos un evento relacionado con nuestro problema. 
 

 
Figura 4

Una vez copiados estos dos directorios al servidor que tiene SP2, el accesso al OWA se restauró (Figura 5). No fue necesario reiniciar el equipo, el IIS o ningún servicio.

Figura 5
 
 

viernes, 7 de junio de 2013

Preparación de Forest y Dominio para Windows Server 2012

Con cada versión de Windows Server que queremos utilizar como Domain Controller, debemos actualizar el Schema de AD. Aunque Windows Server 2012 no es la excepción, trae sin embargo muchos cambios. 

Si queremos configurar el primer equipo Windows Server 2012 como DC en nuestro forest, la actualización del Schema y el Dominio se puede hacer de forma automática (Siempre que tengamos los permisos necesarios), tal como lo detallamos en otro articulo de este blog. Si nuestro AD es pequeño esa puede ser una buena opción, pero si tenemos una gran instalación con roles de administración separados, seguramente querramos tener un poco más de control sobre lo que está pasando en nuestro forest.
 
Ejecutar Adprep  es aún una opción válida, pero el comportamiento y la forma de ejecución han cambiado un poco con respecto a las versiones anteriores.
 
Antes: existían dos versiones de Adprep (Adprep.exe y Adprep32.exe), una para cada arquitectura.
Ahora: solo existe una versión Adprep.exe, que se ejecuta exclusivamente en equipos de 64bits Windows Server 2008 o superiores. Si por ejemplo lo ejecutamos en un Windows Server 2003 R2 x64, nos da un error (Figura 1).
 

  
Figura 1
 
Antes: debía ejecutarse el upgrade de Forest en el DC que tenía el rol de Schema Master.
Ahora: se puede ejecutar remotamente.
 
Antes: el upgrade de Dominio debía ejecutarse en el DC que tenía el rol de Infraestructure Master del Dominio.
Ahora: se puede ejecutar remotamente.
 
Antes: se utilizaba DCPromo para promover un Server a DC.
Ahora: DCPromo está desenfatizado, solo se acepta con un archivo de respuesta. El método preferido es con PowerShell, y también puede utilizarse Server Manager (Si el server no está instalado como Server Core).
 
Si la infraestructura de DC está completamente en 2003, debemos tener en cuenta cuatro cosas:
 
a) Debe especificarse con qué cuenta de usuario (y dominio) Adprep va a realizar la operación, para que pueda comprobar la membresía a los grupos a los que pertenece (Error code: 0x534 Error message: No mapping between account names and security IDs was done).
b) Como ejecutaremos remotamente el comando, debemos asegurarnos de que el firewall no se interponga entre el DC 2003 con el FSMO que queremos contactar y el equipo desde donde ejecutamos ADPrep.exe (Error code: 0x6ba Error message: The RPC server is unavailable).
c) El nivel funcional del Dominio debe ser al menos Windows Server 2003 o la ejecución de la actualización del Dominio fallará (Adprep detected that the domain is not in native mode).
d) Además de que el Dominio y el Forest estén actualizados, para agregar un DC Windows Server 2012 a nuestro Active Direrectory, el nivel funcional del Forest debe ser al menos Windows Server 2003 (The forest functional level is Windows 2000. To install a Windows Server 2012 domain or domain controller, the forest functional level must be Windows 2003 or higher).
 
Con todos estos detalles y nuevos comportamientos tenidos en consideración, podemos ejecutar la actualización de nuestro Forest (Figura 2).
 
Adprep.exe /ForestPrep /Forest "NombreDelForest" /User "NombreDelUsuario" /UserDomain "DominioAlQuePerteneceElUsuario" /Password *
 
 
 
Figura 2
 
Una vez finalizada correctamente la actualización (Figura 3), podemos usar Adsiedit para comprobar que las modificaciones se realizaron con éxito (Figuras 4 y 5).
 
 
 
Figura 3 
 
 
Figura 4
 
 
 
Figura 5
 
 
Finalmente, para poder agregar un DC con Windows Server 2012 a uno de nuestros Dominios, debemos actualizar el Dominio (Figura 6).
 
Adprep.exe /DomainPrep /Domain "NombreDelDominio"  /User "NombreDelUsuario" /UserDomain "DominioAlQuePerteneceElUsuario" /Password *
 
 
 
Figura 6

Opcionalmente (y recomendado) podemos actualizar los objetos de políticas (GPO) del dominio (Figura 7).

 Adprep.exe /DomainPrep /GpPrep /Domain "NombreDelDominio"  /User "NombreDelUsuario" /UserDomain "DominioAlQuePerteneceElUsuario" /Password *
 
 
 
 
Figura 7
 
Si con Adprep no especificamos Forest o Domain, se utilizarán las opciones de donde se encuentre el equipo desde donde ejecutamos el comando, por lo que son útiles cuando la operación es realizada remotamente o en un equipo que no está unido al Active Directory.  
 
Para poder agregar RODC a nuestro ambiente, debemos preparar el Forest, y para eso debemos ejecutar la opción RODC con una cuenta Enterprise Administrator.
 
Adprep.exe /RODCPrep /Forest "NombreDelDominio"  /User "NombreDelUsuario" /UserDomain "DominioAlQuePerteneceElUsuario" /Password *
 
 
Si ya tenemos nuestro ambiente con RODC de Windows Server 2008 o Windows Server 2008R2, no es necesario ejecutar la preparación para RODC con Windows Server 2012, pero si es necesario si teníamos un Active Directory con DC de versiones previas.
 


lunes, 3 de junio de 2013

Lab Tip Nro 1

Cuando queremos configurar un equipo en nuestro ambiente de pruebas, es habitual que le asignemos los mínimos recursos necesarios, ya sea para colocar varios equipos en nuestro host de virtualización o porque utilicemos equipos obsoletos. Esto tiene la desventaja de que cada vez que queremos realizar una simple acción en el equipo, la tarea nos consume mucho tiempo por su falta de respuesta. 
 
Para los host con Windows Server 2012 podemos realizar la configuración inicial del equipo con SCONFIG (Figura 1). Éste es parte del sistema operativo y está disponible tanto en Server Core como en una instalación Full del sistema operativo.
 
 
Figura 1
 
La herramienta se presenta como un menú en modo texto donde podemos realizar las configuraciones básicas del equipo: Nombre, Dominio, Administrador local, Configuración de Red, Acceso Remoto, etc.
 
Por ejemplo, podemos habilitar RDP con NLA con solo pulsar "7", "E" y "1" en el menú de texto (Figura 2), lo cual resulta mucho más rápido que realizar la configuración con las herramientas gráficas.
 

Figura 2

Para Windows Server 2008R2 también está disponible, pero no está incluida por default en la instalación Full (Figura 3), solo se incluye en la instalación como Server Core y en Microsoft Hyper-V Server 2008R2.
 
Figura 3
 
Desde luego que de estos sistemas podemos copiar los archivos sconfig.cmd y Scregedit.wsf (Del directorio %windir%\System32) y los archivos  sconfig.vbs y WUA_SearchDownloadInstall.vbs (Del directorio %windir%\System32\en-US) a una instalación full y utilizar Sconfig sin problemas (Figura 4).
 
Figura 4
.