Hacia la certificación

Han sido dos años de dimes y diretes, y parece que el horizonte de la certificación como MCSA está proximo (espero que en un par de semanas a lo sumo). La verdad es que cuando empiezas parece que hay un largo recorrido por delante y efectivamente así es. Pero cuando te pones en serio a trabajar sobre ello realmente no es tan complicado como puede parecer en un primer
momento.

La premisa básica para obterner la certificación a mi modo de ver es tener una amplia experiencia manejando los sistemas en los que quieres tener ese nivel de experto, esa experiencia yo me atrevería a decir que es un 60%-70% del aprobado, ya que esa es la cantidad de pregutnas que tendrás en el examen que con la experiencia y un poco de cabeza puedes contestar sin problemas. ¿Por que digo un poco de cabeza?, sencillo, muchos de nosotros que trabajamos o venimos de trabajar en PYMES o para ellas, manejamos infraestructuras pequeñas, de entre 2 y 10 servidores, y hasta unos 70-100 equipos clientes, con como mucho 5 delegaciones. Muchas de las cuestiones que se presentan en las certificaciones sobre todo para MCSA y MCSE se refieren a grandes corporaciones, en las que la infraestructura suele ser miles de equipos, decenas de servidores, y multiples "branch offices", pero al final la solución es la misma para 2 servidores que para 100, solo con un pelin de lógica se sabe la respuesta (y experiencia por supuesto).

Queda un 30-40% de respuestas para las que debes estudiar y debes estudiar duro, primero con los "Self-Paced" de Microsoft que son de muy alta calidad (olvidate de los MOC y de los cursos presenciales, me he gastado una fortuna y aun no conozco ningun curso presencial bueno). En segundo lugar utiliza test de prueba como los de Mesasure-Up o Testking (los de última generación) que simulan los examenes a la perfección sin hacer las trampas de copiar las preguntas literales del examen.

Mi próximo reto es el 70-620, o lo que es lo mismo "Configurando Windows Vista" el cual la verdad tengo muchas esperanzas ya que realmente el estudio al menos me está resultando extremadamente sencillo, ya que en el libro no hay prácticamente nada que no haya visto en mi día a día de uso del Vista desde hace casi un año, como digo el 70% del examen lo tengo del día a día, un 30% me falta de caracterisitcas que nunca he usado (y posiblemente ni yo ni mis clientes usen jamas) o cuestiones que Microsoft decide que se han de hacer de determinada manera por que ellos creen que esa es la mejor.

Bueno simplemente desearme suerte, y espero a vuelta de fin de semana añadir este examen al curriculum... el siguiente... la próxima semana.

Animaros y estudiar, cualquier pregunta o curiosidad que no viole el AUP del examen, estoy a vuestra disposición.

Saludos.

Sharepoint y Reporting Services

Hay un problema conocido en Office Sharepoint Server 2007 (sharepoint 3.0 no lo soporta) en integrar Reporting Services si además estás utilizando autenticación por formularios, por el que si el acceso a tu sitio lo realizas por cualquier URL que no sea la "Predeterminada" o "Default" da un error de Seguridad el servicio de Reporting Services en modo integrado.

Según MSDN simplemente lo único que debes hacer es que los Reportes del servicio de RS se haga por la URL predeterminada, pero claro si tu quieres tener diferentes URLs (como tiene el 90% de la gente) para permitir accesos desde la intranet o desde la extranet no es posible.

Bien obviando este inconveniente que espero que solucionen con el SP3 de SQL Server, hoy nos hemos encontrado con un problema en un cliente en el que al hacer el cambio, y poner la url como predeterminada el Reporting ha dejado de funcionar, no da el error de seguridad pero nos informa de que el servicio de Reporting Services no está instalado o bien configurado.

Ha sido una pequeña lucha, ya que además es una granja quien soporta este sharepoint con 1 Backend corriendo SQL Server, y (actualmente) un frontend soportando el acceso de los clientes. El problema se agravaba ya que este cambio lo habíamos realizado con anterioridad en otros entornos y había funcionado sin problemas, pero en este caso fallaba.

Una pequeña pensada sobre la evolución del sistema, nos llevo a ver que problemas sufrimos durante la implementación, y uno de los mayores problemas que hemos tenido siempre, ha sido con la resolución de nombres, de hecho durante la implementación hemos tenido que tirar del fichero HOSTS en multiples ocasiones (el cliente no nos dejaba tocar su DNS). Esto nos llevo a intentar hacer un ping a las URL de los frontend desde el mismo frontend para descubrir que no resolvía el nombre (si el XP que usabamos el cliente), inmediatamente tras resolver este problema, el sistema comenzo a funcionar perfectamente.

Previamente ya tuvimos algunos problemas sobre la "llegada" de los frontend hacía los servidores de SQL server justamente por la resolución de nombres.

Por ello, es extremadamente importante que cuando implementes una solución de Sharepoint (aunque sea sencilla) tengas claro que nombes de host utilizarás, interna y externamente y que tengas claro que los DNS van a resolver adecuadamente las IPs internas, externas, etc. Technet tiene documentación sobre la planificación de este aspecto muy detallada, te ahorrarás muchisimo trabajo.

Cualquier comentario es bienvenido.

Y essooooo... digo y otroooooo...70-

Bueno, ha sido duro, han sido pocas horas de sueño esta última semana, pero al final hemos pasado. El 70-291 ya está en mi bolsillo. Cuando empece a estudiar el "Self Paced" del 70-291 comence con muchisimo animo ya que era eminentemente un tema de redes que la verdad creo que me manejo bastente bien, DHCP, DNS, rutas, etc. Pero la verdad es que cuando te metes un poco en profundidad la cosa se complica, el apartado sobre todo de solución de problemas (throubleshot) es bastante complejo, ya que muchas operaciones que tu sueles hacer de una determinada maner, Microsoft decide que es mejor de otra manera (por ejemplo, yo no restauraría jamas un servidor DHCP como dice microsoft, también es cierto que no manejo redes de miles de computadoras).

Bueno mi recomendación es que te atrevas con este examen, con el apoyo del libro se simplifica, pero también es cierto que es interesante sobre todo que vayas con un poco de práctica en los apartados de IPSec y protocolos de encriptación, CHAP, EAP, etc. (aunque de estos a mi no me cayo ninguna, dios me van a echar por revelar información).

Si te animas, aquí me tienes para cualquier duda.

Exchange y antivirus para cliente (desktop pc)

Esta vez el problema ha sido de rápida solución, aunque es el típico problema que yo denominaría (al igual que hacía un profe mio de matemáticas) de idea feliz.
La cosa comenzó un Miercoles por la tarde, en que un amigo me pidio que le echara un ojo a su exchange ya que llevaba un par de días volviendose loco con el ya que había conseguido que levantara en varias ocasiones pero la mayor parte del tiempo estaba caido sin funcionar, y esto le estaba causando un gran trastorno en su cliente por que más de 50 personas estaban sin servicio de correo.
Puestos manos a la obra, diagnosticamos de manera rápida que el problema estaba en la propia máquina de Exchange, ya que los DNS, firewalls, sistemas anti-spam/antivirus frontales estaban operando correctamente, y sin embargo el servicio SMTP del Exchange no estaba levantado. Un siguiente vistazo también nos mostró de manera rápida que las bases de datos de Exchange (publica y de buzones) no estaban tampoco montadas, click con botón derecho montar, pero sin exito, por lo que nos vamos a ver que dice nuestro gran amigo el visor de sucesos.

La verdad es que esta vez el "Event Viewer" no daba gran información, pero si me llamo la atención un evento de la controladora SCSI que tiene la máquina en la que trabajamos (HP/Compaq con una SCSI y un RAID5 para almacenar datos) en que reportaba un disco fallando, un vistazo a la máquina física nos muestra que el disco 1 del RAID esta marcado como en fallo. Esto nos aclara un primer problema, el Exchange no es capaz de montar las bases de datos, ya que no es que estén corruptas (el RAID5 las preserva) sino que el tiempo que tarda de acceso a las bases de datos es gigantesco y Exchange se cansa de esperar. Por lo que tomamos la decisión de mover las bases de datos a una unidad a parte de este RAID5 en que tenemos espacio suficiente, sin tolerancia a fallos, pero es una emergencia hasta que llegue el disco sustituto. Para que os hagáis una idea, el almacen de buzones ocupa 6,7Gb y tardo aproximadamente 25 minutos en mover ese archivo al nuevo disco temporal, lo que explica que Exchange y por ende el conector SMTP se aburrieran de esperar y no montaran los almacenes y el conector SMTP no funcionara.
Bien, movemos los almacenes (45 minutos despues) montamos los almacenes, y perfecto a la primera, problema solucionado...o no....

Evidentemente el primer problema, está solucionado pero el servicio sigue sin funcionar, el servicio anti-spam no es capaz de entregar el correo al Exchange, sin embargo el Exchange si es capaz de sacarlo hacia fuera, y OWA y los Outlook funcionan correctamente. Bien, echemos un vistazo al puerto 25 a ver que pasa. Hacemos un telnet a la ip publica del la máquina Exchange, y nada, timeout (y el servicio está corriendo), hacemos un telnet a localhost al puerto 25 y ahi está nuestro Exchange perfectamente, recibe correo, pero evidentemente no nos sirve, nadie podrá llegar a localhost desde fuera que es lo que necesitamos.

Venga, algo se ha quedado tonto, reiniciamos la máquina a ver que pasa. Idem. Vale, a esa IP le ocurre algo extraño, pero curiosamente el resto de servicios funciona sin problemas, IIS, etc. Añadimos una segunda IP y ocurre lo mismo, no hay forma de conectar con el servicio, solo con localhost. Tras una charla con el amigo que pidió la ayuda descubrimos que esto es algo que había pasado previamente y había desaparecido de manera misteriosa. Pues bien, en ese momento aparece la "idea feliz", ya está, el antivirus....

Hay algunos antivirus, como en este caso el McAfee instalado, que reconfiguran el Outlook o el cliente de correo que tengamos para que sean los propios antivirus los que escuchen en el puerto 25 y todo lo que salga por ahi sea revisado por el propio antivirus. Aquí lo que estaba ocurriendo es que cuando el McAfee arrancaba antes que el servicio SMTP de Exchange ocupaba el puerto 25 haciendo que el servicio SMTP no pueda "bindearse" a las IPs públicas de la máquina que el ocupaba. Desinstalando McAfee...funcionando a la perfección.

Moraleja, jamas, jamas, jamas, instales un antivirus de cliente en un servidor, y si instalas un antivirus de los que se venden de servidor de ficheros, asegurate que solo escanea los ficheros que debe, si quieres un antivirus para Exchange hay soluciones muy buenas expresas para Exchange, por eso suelen añadirle al nombre del antivirus al final "for Microsoft Exchange"