18 de septiembre de 2007

VMware Site Recovery Manager

VMware va a por todas. En el VMWorld 2007 está presentando una serie de productos impresionantes. Os iré comentando alguno de ellos en los próximos días.

En primer lugar hablar de VMware Site Recovery Manager. Está claro que falta un producto completo de copia de seguridad (no replicación) para tener protegidas las VMs. Por la noticia no queda demasiado claro qué demonios es el producto y aún no hay demo disponible en la Web, pero empezamos a tomar nota del asunto.

Tenéis la noticia completa aquí:
http://www.optize.es/servlet/RdServlet?fwd=conten2&page=/conten/pNoticias.jsp?IdContenido=26315&IdTipoContenido=84&fechaInicio=13/09/2007

17 de septiembre de 2007

Antiespía y antivirus

En una instalación en la que he estado hace poco tuve la oportunidad de probar una herramienta llamada "Sin espías" que me ha resultado particularmente interesante.

La herramienta es un producto muy bueno y también muy simple de utilizar. Está en castellano. Encuentra bastante más detalle de errores que Windows Defender y, además, permite la descarga y ejecución de un antivirus gratuito llamado Kau Antivirus que está basado en ClamAV.

Si tenéis que pasar la fregona en algún sistema y no tenéis nada a mano estos productos os pueden resultar de ayuda.

El producto Sin Espías es comercial. Se puede descargar una demo completamente útil durante unos días de aquí:
http://www.sin-espias.com/

El Antivirus Kau es gratuito y sirve para XP y 2003, entre otros. Se puede descargar de aquí:
http://www.kauav.com/

Consulta Técnica: Problemas con Exchange

Tras unas breves pero intensas vacaciones por el País Vasco y arrastrando una depre post-vacacional de aupa (yo quiero ser millonario, joder...) paso a responder una consulta sobre Exchange que me formula nuestro amigo Eduardo:

Hola buenos días, investigando por las Web he visto que aceptas consultas pues aquí va una que me lleva loco.

Tengo mi sistema con varios servidores en uno de ellos va Exchange y servidor de ficheros, en otro un DC catalogo global (Virtual), uno de terminal server también virtual, y otro DC que es el maestro de operaciones y alguno más virtualizado, pero creo que no influyen para mi problema.

El caso es que cree un nuevo servidor virtual lo hice controlador de dominio, catalogo global y le pase los roles maestros desde el servidor que era maestro. Parecía que iba todo perfecto, pero ahora el servidor de Exchange ha empezado a dar problemas. Arroja unos sucesos de error constantemente:

Error 9074 MSExchangeSA
InterfazRFR

La interfaz de referencia del servicio de directorio no pudo atender una solicitud de un cliente. RFRI devuelve el código de error:[0x3f0].


Error 9176 MSExchangeSA Proxy
NSPI

El proxy NSPI puede ponerse en contacto con el catálogo global
controlador de dominio pero no es compatible con el servicio NSPI. Después de proporcionar un controlador de dominio a catálogo global, debe reinicia el catálogo global para que admita clientes MAPI. Reinicie controlador de dominio en cuanto sea posible.

Tampoco me deja acceder a el por escritorio remoto,
da un error diciendo que el Servicio RPC no esta disponible.
No puede ver a los demás equipos de la red, aunque si les hace ping.
Según he podido investigar y leer parece ser que este servidor de Exchange no es capaz de ver los controladores de dominio.

He probado varias cosas:

Reiniciar los controladores de dominio, y el de Exchange.

Registerdns y flushdns

He intentado hacerle un domainprep pero también me arroja errores.

He leído todo lo de Microsoft sobre esos sucesos, también en eventid pero no he conseguido nada claro.
He visto algo de usar las herramientas repadmin y ntdsutil pero me he perdido un poco.

He pensado en sacarlo del dominio y volver a meterlo, pero no se en que puede incidir eso en el Exchange y el servidor de fichero.

Esta es mi pregunta: ¿como puedo hacer para que ese servidor de Exchange vuelva a ver todo el dominio perfectamente?.


Estoy en proceso de ir poco a poco virtualizando mis sistemas,
cuando consiga solucionar esto pediré de tus consejos sobre virtualizacion si no es mucho pedir.

Enhorabuena por el blog.

Gracias por todo de antemano,

Un saludo.

Eduardo Martínez


Bueno Eduardo, evidentemente puedes hacerme las consultas que quieras siempre que estén en el ámbito de mi conocimiento.

Lo que me comentas es un problema bastante habitual de entornos con Exchange. Hay un par de cosas que te recomiendo, vamos por partes:

1. Verificación de Active Directory.

Exchange no es un servidor cualquiera que se puede llevar y traer a un Active Directory así como así. Cuando se instala realiza unos procesos de preparación del bosque y del dominio muy delicados y su dependencia de Active Directory es completa.

Por una parte verifica que el Directorio Activo esté correctamente. Para ello verifica lo siguiente:

1. Que los 5 roles FSMO estén localizados en un Controlador de Dominio. Herramientas Esquema de Active Directory, Dominios y Confianzas de Active Directory y Usuarios y equipos de Active Directory.
2. Que exista, al menos, un catálogo global (Sitios y Servicios de Active Directory).
3. Que los controladores de Dominio tengan instalado el servicio DNS y que esté funcionando correctamente.
4. Que el servidor de Exchange tenga como primer DNS el Controlador de Dominio/DNS que tiene los roles FSMO. Idealmente el DC con los 5 roles debería también tener DNS y ser también catálogo global, así lo tienes todo mucho más localizado y no se dispersa la información.
5. Que el DC FSMO, etc. también se tiene a sí mismo como primer DNS.
6. Instala en el DC las herramientas de soporte de Windows Server 2003 suptools.msi y ejecuta DCdiag y Netdiag. Verifica si todo está OK o si existen problemas en la estructura de Active Directory.
7. Con la herramienta Sistema de Exchange, selecciona el Servidor de Exchange y, en sus propiedades, selecciona la pestaña de Acceso al Directorio. Verifica ahí manualmente que se estén encontrando bien los controladores de dominio y catálogos globales de la red.

Creo entender que tienes 2 DCs. Ambos deberían ser DNS y apuntarse a sí mismos como primer DNS y al otro DC como secundario. El servidor de Exchange debería apuntar al DC con los roles FSMO como primer DC y al otro como secundario.

2. Sistema limpio y actualizado.

Aunque probablemente no tenga nada que ver con tu error, cada vez más estoy viendo sistemas muy dejados a nivel de seguridad. Verifica que todos los servidores estén actualizados en Windows Update con el SP2 y el resto de actualizaciones de actualidad hasta hoy, sin excluir ninguna.

Por otra parte verifica que no tienes virus ni troyanos en esos equipos. Es importante instalar, adicionalmente, un antivirus específico para Exchange, excluyendo en el antivirus de archivos las carpetas con las que trabaja Exchange.

El Exchange, obviamente, debería tener instalado su SP2.

Espero haberte ayudado.

Saludos

10 de septiembre de 2007

AMD presenta el Opteron Quad-Core llamado Barcelona

Por fin AMD ha sacado el Quad-Core de su Opteron. JL Medina me explicó un día con detenimiento (gracias por tu paciencia José Luis) a nivel técnico el porqué un Opteron Dual Core funciona mejor en temas de virtualización que un Intel Quad Core. Sin embargo esto es complicado de transmitir a los clientes que quieren ver muchas CPUs virtuales aunque luego el rendimiento no sea el óptimo.

Afortunadamente AMD ya ha dado el paso y la virtualización con procesador de cuádruple core ya es realidad. Eso sí, los precios iniciales seguro que son guapos.

Tenéis la noticia completa aquí:

http://www.idg.es/pcworldtech/mostrarNoticia.asp?id=60120&seccion=actualidad

5 de septiembre de 2007

Básicos: saber si un puerto está abierto.



En ocasiones necesitamos saber si un puerto de un servidor está abierto. Por ejemplo podemos necesitar saber si un servidor de Exchange escucha por el puerto SMTP (25) o si un servidor de archivos de Windows está o no escuchando (445) o si nos podemos conectar por Terminal Server contra un servidor (3389).

Una forma muy simple de verificar si un puerto está o no abierto es hacer un telnet contra la IP o el nombre (si existe resolución DNS). Por ejemplo:

telnet 192.168.0.30 3389

De este modo verificamos si el servidor 192.168.0.30 está escuchando por el puerto de Terminal Server.

Esto también lo podemos hacer contra una IP pública, obviamente. Si el puerto está abierto normalmente queda el cursor parpadeando y la pantalla en negro, buen síntoma. Si no se puede conectar sale un error similar a este:

Conectándose a 192.168.0.30... No se puede abrir la conexión al host, en puerto 3389: Error en la conexión.

Hay una utilidad gratuita para hacer estas operaciones que se llama IP Port Scanner. La podéis descargar desde la siguiente Web:
También tenéis en la misma URL diferentes utilidades gratuitas para escanear redes.