jueves, 24 de marzo de 2011

Planificar el Despliegue de OCS 2007 R2

ocs2007r2-logo-productHola de nuevo, hace un año más o menos participé en un proyecto de despliegue de OCS 2007 R2, este proyecto inicialmente fue diseñado por consultores de Microsoft los cuales nos hicieron entrega de una documentación muy completa. La verdad es que cuando revisamos la documentación nos sorprendió el nivel de detalle de la misma, ciertamente era un buen trabajo y nos preguntábamos la cantidad de tiempo que podía llevar realizar dicha documentación. Cierto tiempo después me enviaron a un WorkShop de OCS R2 en Microsoft, estos cursos son impartidos por los propios técnicos de Microsoft expertos en el tema y allí descubrí una herramienta que me hizo entender el por qué del nivel de detalle de la documentación que había visto antes, esta herramienta se llama Planning Tool for Microsoft Office Communications Server 2007 R2 .

Con esta herramienta se puede realizar una planificación muy completa del despliegue de OCS, nos indica desde que máquinas necesitamos, cuales son los puertos a nivel de Firewall que necesitamos abrir, cual es el orden de instalación de roles en el despliegue y también nos permite acceder a la documentación oficial de Microsoft en el Technet. La herramienta nos hace un pequeño cuestionario en el que nos pregunta que roles queremos desplegar, cuantos usuarios tenemos en nuestra organización, si vamos a utilizar Enterprise Voice y en caso afirmativo cuantas llamadas por hora aproximadamente realizan los usuarios, en conclusión, pide información sobre el entorno en cuestión que queremos desplegar.

SNAGHTML31c513

image

image

Una vez contestadas todas las preguntas sobre el entorno, la herramienta saca una un informe detallado con la arquitectura a desplegar y las características de las máquinas con los puertos requeridos tal y como se ve en las imágenes que hay a continuación:

imageimage

La herramienta muestra tanto los pasos de planificación como el orden de los pasos del despliegue y si pinchamos cada uno de los enlaces nos lleva a la documentación de ese paso en el Technet.

image

image

La herramienta también puede exportar a Visio la topología generada o a Excel el listado de las características de servidor y los puertos necesarios. Este tipo de herramientas son muy prácticas y la verdad es que yo las hecho de menos para otros productos como Exchange o Active Directory. Espero que os sea de utilidad y como siempre espero vuestros comentarios.

lunes, 21 de marzo de 2011

SID History en Relaciones de Confianza de Bosque

active-directory

Hola a todos, mientras termino la segunda parte del artículo de Storage Server quería compartir con vosotros un problema que hemos padecido hace poco. Actualmente estamos inmersos en una migración de dominios “eterna”, el motivo por el cual esta migración de dominios es “eterna” es simplemente porque desde mi opinión personal el proyecto está mal definido desde el principio y se han pasado demasiadas cosas por alto. Pero esto es otra guerra y no hay tiempo para contarla ahora Risa, a lo que voy es a que para poder realizar la migración inicialmente se ha tenido que establecer una relación de confianza y ejecutar cierta parametrización para que esto funcione.

En concreto se definió una relación de confianza Externa y se deshabilitó el SID Filtering como para cualquier otra migración. Para aquellos que no estéis familiarizados con esto, deciros que el filtrado de SID se encuentra habilitados en todas las relaciones de confianza que se establecen entre dominios, el filtrado de SID garantiza que el uso incorrecto del atributo SID History en las entidades de seguridad (incluida inetOrgPerson) en el bosque de confianza no supone una amenaza para la integridad del bosque que confía. El atributo SID History se utiliza en las migraciones entre dominios para que los usuarios migrados puedan acceder a recursos del dominio de origen sin tener que establecer nuevos permisos en el recurso.

Para poder visualizar este atributo necesitamos registrar una librería llamada acctinfo.dll y se encuentra en Account Lockout and Management tools que es descargable desde esta web:

http://www.microsoft.com/downloads/en/details.aspx?FamilyId=7AF2E69C-91F3-4E63-8629-B999ADDE0B9E&displaylang=en

Registramos la dll utilizando el comando regsvr32 acctinfo.dll, y una vez hecho esto aparecerá una pestaña nueva dentro de las propiedades del usuario llamada Additional Account Info y allí tenemos el botón SID History donde podemos ver este atributo del usuario en cuestión.

image

image

Como en las relaciones de confianza Externas no funcionan las autenticaciones Kerberos, tuvimos que reconfigurar varios servicios para que autenticaran por NTLM, esto nos provocó un error en varios de estos servicios, los servidores agotaban el numero de threads NTLM disponibles y dejaban de ver el dominio. Como no tenemos todos los usuarios migrados, para poder configurar la autenticación Kerberos en estos servicios teníamos que cambiar la relación de confianza a una relación de Bosque así que nos pusimos manos a la obra. Eliminamos la relación de confianza Externa y creamos una nueva relación de confianza de Bosque, como hacemos para todas las relaciones de confianza entre las que tenemos una migración, deshabilitamos el SID Filtering con el siguiente comando:

Netdom trust dominio1.origen /domain:dominio2.destino /quarantine:No /userD:UserAdminDom1 /passwordD:*

Una vez hecho esto, cuando el lunes llegaron los usuarios empezamos a encontrar incidencias de acceso denegado a ciertos recursos, comprobábamos que el atributo de SID History estaba en los usuarios pero no entendíamos por qué no se enviaba este SID para acceder al recurso del dominio origen. Después de varios intentos de resolver el problema, abrimos caso con Microsoft y todos andábamos un poco perdidos, hacíamos pruebas pero ninguno entendíamos por qué no se enviaba este atributo para acceder a los recursos del dominio Origen. A los días de tener el caso abierto, Microsoft nos hizo llegar el siguiente Link:

http://technet.microsoft.com/en-us/library/cc755321(WS.10).aspx

Este link, recoge un dato que desconocíamos, cuando se establece una relación de confianza de Bosque, no basta con deshabilitar el SID Filtering, también tenemos que especificar explícitamente que se envíe el SID History entre el dominio origen y el dominio de destino, esta operación no la realizamos en las relaciones de confianza de Externas por lo que entendimos que tampoco se debía realizar en la de Bosque, para indicar explícitamente que se envíe el SID History entre los dominios usamos el siguiente comando:

Netdom trust Dominio1.origen /domain:dominio2.destino /enablesidhistory:Yes /userD:UserAdminDom1 /passwordD:*

Una vez hecho esto se solucionó el problema y los usuarios pudieron trabajar sin ningún tipo de problema. Así que ya sabéis, si estáis inmersos en una migración y necesitáis una relación de confianza de Bosque, no basta con deshabilitar el SID Filtering, también tenéis que indicar que el atributo SID History se ha de intercambiar entre dominios. Espero que os sea de utilidad.

martes, 15 de marzo de 2011

Como Ofrecer Disco Compartido a Nuestro Cluster de Laboratorio (1/2)

clip_image001Hace meses que no aparecía por aquí, muchos me preguntan si lo he dejado, si ya no escribo más, pero la verdad es que el problema que he tenido ha sido falta de tiempo y como éste es algo que no me sobra mucho últimamente, si me permitís, voy a ir directo al grano.

La cuestión está, en que hace poco se me planteó un problema de cara a ciertos laboratorios que montábamos para realizar prácticas o pruebas de cluster. Desde que empecé a utilizar VMWare para crear maquetas y laboratorios podía probar prácticamente de todo, el problema que me encontraba en el cluster era el almacenamiento compartido, ¿cómo podía ofrecer disco compartido a las máquinas virtuales?, como siempre, acudí a Google y allí encontré varios procedimientos de cómo hacer que un disco *.vmdk fuese accesible para dos máquinas virtuales, llamarme torpe si queréis, pero no conseguí que funcionase nunca. No sé si es porque no encontré el artículo adecuado o porque nunca vi lo suficientemente abajo como para que funcionase.

Al tiempo, mi amigo Emilio, me presentó OpenFiler; desde la propia página te puedes bajar una máquina virtual y empezar a ofrecer discos iSCSI a las máquinas virtuales con Sistema Windows Server 2003, descargas el iSCSI Initiator para el servidor y todo listo. Mi sorpresa llega cuando intentamos montar por el mismo procedimiento un cluster en 2008, lanzamos el test de validación del cluster y parece ser que OpenFiler no soporta SCSI-3 Persistent Reservation y esto es necesario para montar el cluster en 2008. A partir de ahí comenzamos a investigar buscando alternativas, Emilio ya me había hablado de Windows Storage Server 2003 pero no sabíamos ni como funcionaba ni como se montaba, al tirar del hilo encontré varios Links, el que me aclaró cómo montar Storage Server es el siguiente:

http://blogs.technet.com/b/josebda/archive/2010/09/27/windows-storage-server-2008-r2-and-the-microsoft-iscsi-software-target-3-3-are-available-on-msdn-technet-here-s-how-to-install-them.aspx

Este Link es el Blog de José Barreto y explica que contiene la ISO de Windows Storage Server 2008 R2 y que necesitas para montarlo, en primer lugar decir que Windows Storage Server 2008 R2 es descargable desde la Web del Technet y se monta sobre un Windows Server 2008 R2 tal y como muestra José en la imagen siguiente:

image

También recordar que hay una versión para la descarga en el Technet que es Windows Storage Server 2008 R2 Embedded que directamente monta el SO con todos los componentes instalados, si quieres montarlo desde cero la cuestión es la siguiente, coges un Windows Server 2008 R2 y a partir de ahí instalas lo que trae la imagen descargada del Technet de Windows Storage Server 2008 R2, a continuación voy a detallar como instalarlo y como crear un disco compartido que se usará de QUORUM para nuestro cluster. Tal y como indica la imagen extraemos el contenido de la ISO descargada del Technet, ésta contiene el fichero WSS2008R2+iSCSITarget33.exe, cuando lo lanzamos, descomprime el fichero Windows_Storage_Server_2008_R2.iso y el fichero iSCSI_Software_Target_33.iso, insertamos la primera ISO en nuestro servidor 2008 R2 y lanzamos la instalación como se ve a continuación:

  • Cuando montamos la ISO, accedemos a las carpetas que vemos en la imagen siguiente

image

  • Accedemos a la carpeta Windows Storage Server 2008 R2, y ejecutamos Windows6.1-KB982050-x64-EnterpriseBranding.MSU (Branding for the Enterprise Edition of Storage Server).
  • A continuación ejecutamos el fichero Windows6.1-KB976833-x64-SIS.msu (Single Instance Storage component) y el fichero Windows6.1-KB976836-x64-OOBE.msu (Out-Of-the-Box-Experience for Storage Server).
  • Una vez instalado hay que reiniciar el servidor, en ese momento veremos que ya ha cambiado el logotipo del mismo a Storage Server 2008 R2 como se ve en la imagen siguiente:

image

  • Una vez instalado lo anterior, tenemos que ejecutar las actualizaciones de sistema, se encuentran dentro de la carpeta OS Updates, son unas 54 actualizaciones y para ejecutarlas todas yo he creado un fichero llamado Actualizaciones.bat, este fichero contiene una llamada a todos los ficheros de la carpeta con los atributos /quiet y /norestart, esto instalará todas las actualizaciones que sean aplicables. Una vez finalizada la actualización se debe reiniciar el sistema.

image

Con esto habremos finalizado la instalación de Windows Storage Server 2008 R2 y ya tendremos nuestro NAS, ahora tenemos que instalar el Software de Target iSCSI que nos permitirá generar nuestra SAN iSCSI para ofrecer los discos para nuestro cluster. Insertamos la ISO iSCSI_Software_Target_33.iso, y accedemos a la página de inicio que trae el CD.

  • La página de inicio contiene un aparatado denominado Install the Software, allí ejecutamos la opción iSCSI Software Target (X64) para lanzar la instalación.

image

Una vez finalizada la instalación ya tendremos disponible el iSCSI software Target dentro de las herramientas administrativas y ya podremos ofrecer discos iSCSI a los servidores, lo único que quedaría es configurar los Targets y los discos VHD. Por internet hay diferentes Blogs con muchas recomendaciones, yo he anotado varios puntos que creo que son interesantes. Antes de empezar me gustaría indicar que no soy experto en almacenamiento por lo que las opiniones que voy a transmitir lo he obtenido gracias a búsquedas en páginas, documentación especifica de almacenamiento y mi propia experiencia, si alguien considera que hay algún dato incorrecto me gustaría que me lo notificara lo antes posible para corregirlo.

Para el tráfico de red iSCSI, utilizaremos un segmento de red Ethernet (VLAN) exclusivo e independiente de los segmentos de red utilizados para el tráfico de red normal. Es deseable utilizar adaptadores de red exclusivos para iSCSI, tanto en las máquinas físicas como en las máquinas virtuales.

Por norma general se suele crear un target para cada servidor al que queremos ofrecer disco, hay algunas excepciones como las que detallo a continuación.

  • Hay que tener en cuenta que cada Target tiene su propia cola de peticiones, por lo que si buscamos presentar varios discos a un servidor, una best practice sería crear un Target para cada disco. Esto haría que las colas de peticiones para cada disco fuesen de forma independiente y obtendríamos un mejor rendimiento.
  • Cuando vamos a crear un cluster como es el ejemplo de este artículo, necesitamos que varios servidores vean los mismos discos para que el cluster pueda funcionar, en ese caso asociaremos varios iniciadores iSCSI al Target para que nuestro cluster pueda manejar los discos. Esto sería una opción ya que el enfoque clásico de crear un Target para cada servidor y allí asignar los mismos discos también sería valido.

De cara a utilizar Microsoft iSCSI Software Target debemos saber lo siguiente, los Discos Virtuales que usa el software de Target toman forma de ficheros VHD, similares a los Discos Virtuales de Hyper-V, Virtual Server y Virtual PC, aunque con alguna peculiaridad. Sólo podremos crear Discos Virtuales de tamaño fijo y posteriormente podremos extender y realizar Snapshot de los mismos.

Debemos recordar que los equipos clientes de nuestro Storage, denominados iniciadores iSCSI (iSCSI initiators), pueden identificarse en el Target utilizando cuatro métodos diferentes:

  • iQN (iSCSI Qualified Name). Es el método preferido y el método por defecto para identificar a un iniciador iSCSI. En el caso de utilizar el software Microsoft iSCSI Initiator, se trata de una cadena que contiene el nombre DNS del equipo prefijado del siguiente texto "iqn.1991-05.com.microsoft:".
  • Nombre DNS.
  • Dirección IP.
  • Dirección MAC.

Bien, hasta aquí hemos realizado la instalación de nuestro software de Target, en la segunda parte del articulo que colgare en los próximos días explicaré como configurar este software para ofrecer los discos a nuestro cluster de laboratorio.