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.
Cabecera PRINCIPAL
|
viernes, 30 de mayo de 2008
domingo, 18 de mayo de 2008
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"
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"
martes, 13 de mayo de 2008
Punto y seguido...
Bueno, en vista de los tiempos que corren, he decidido darle un pequeño giro a esto y profesionalizar el web, y poner en segundo plano el blog personal ya que es de uso muy restringido para familiares, y animales de compañía.
El objetivo de este Blog sigue siendo el mismo que el primer día, contar las andanzas a las que nos enfrentamos desde el pequeño departamento de sistemas en el que trabajo y que espero que os ayuden a ahorrar unos millones de minutillos en encontrar la típica chorrada que hace que arruines los planes de trabajo de una semana.
Bienvenidos y a vuestra disposicion.
El objetivo de este Blog sigue siendo el mismo que el primer día, contar las andanzas a las que nos enfrentamos desde el pequeño departamento de sistemas en el que trabajo y que espero que os ayuden a ahorrar unos millones de minutillos en encontrar la típica chorrada que hace que arruines los planes de trabajo de una semana.
Bienvenidos y a vuestra disposicion.
Suscribirse a:
Entradas (Atom)