Flipante

Pues sí, flipante es lo único que se me ocurre cuando veo la carga de la CPU del Host que gestiona estas 14 máquinas virtuales, entre las que hay 9 Windows XP que están haciendo funciones de escritorios "virtuales" para el personal que está fuera de la organización y que necesita acceder al software de ERP. 3 servidores de aplicaciones, uno que gestiona un programa de comunicaciones interno (y privado, Inbit Messenger, una pasada) y un SBS.

Por cierto, a las diez de la noche se ejecuta la copia de seguridad, os puedo asegurar que el resto del tiempo, en producción, y la gente trabajando a full la gráfica es prácticamente la misma. Como dice mi colega y amigo Josep, con lo que me resta de CPU monto un XP con el emule. ;-)


P.D.: Ah, se me olvidaba, y todo con VMWARE Server, con dos coj... y en producción!!!! ;-)

La importancia de tener un buen sistema de copias de seguridad y un entorno virtualizado

No se si lo he dicho, pero parece como si todo lo que me pudiese pasar me está pasando en los dos primeros meses del año. Menos mal, que para mi, lo más importante son las copias de seguridad.

En uno de mis clientes, con un servidor virtualizado (VMWARE Server) con Microsoft Windows Small Business Server 2003, además de algún que otro Windows 2003 Server para aplicaciones de ERP, el SBS le dió por joderse, si, esas cosas que casi nunca pasa y que además no avisa. Vamos más concretamente dejó de funcionar el Exchange... Después de varias horas intentando averiguar qué es lo que estaba pasando, decidí tirar de copia de seguridad.

Y aquí es donde la virtualización tiene una de sus mayores ventajas. El escenario es el siguiente:

• Dos servidores HP Proliant con Windows Server 2003 de 32 bits.
• VMWARE Server en cada uno de ellos.
• 3 máquinas en uno (entre ellas el SBS) y 5 en la otra.
• 1 NAS LaCie de 4TB
• Backup Exec System Recovery 8, como software de copia de seguridad.

Tiempo de recuperación del archivo del disco duro del SBS: 5 min.
Tiempo de inventariar una nueva máquina, tal y como era el día anterior: 1 min.

Tiempo total: 6 min.

Cuánto tiempo invertí en mi última recuperación con un servidor físico: 3 días.

Vamos que la diferencia es un poco mucho. ;-)

Gracias Josep Ros.

P.D.: Como yo, por norma, no me fío de nada, en un S.O. con Exchange, recomendaría que además de la copia completa de la máquina virtual, además se realizara una copia del exchange con los métodos tradicionales, ya sabéis, por si acaso...

Cómo limpiar una cola "inmensa" de golpe en Microsoft Exchange

Pues cuando necesitamos borrar "de golpe" algunos miles de correos que se han quedado "enganchados" en la cola de salida de nuestro servidor Exchange, mejor seguimos estos pasos:

1. Abrir el Administrador del sistema de Exchange.
   
2. Hacer clic con el botón derecho en Conector SMTP de SmallBusiness en Conectores y seleccionar Propiedades.
   
3. Hacer clic en la ficha General y pulsar sobre Reenviar el correo a través de este conector al siguiente host inteligente.
4. En el campo, escribir una dirección IP falsa entre corchetes.
5. Hacer clic en la ficha Opciones de entrega.
6. Hacer clic en Especificar el momento de envío de los mensajes a través de este conector.
7. En la lista Hora de conexión, hacer clic en Ejecutar diariamente a las 11:00 p.m.
8. Hacer clic en Aceptar
9. Expandir Servidores, Servidor, Protocolos y, finalmente, SMTP. Hacer clic con el botón derecho en el Servidor virtual SMTP predeterminado y, a continuación, hacer clic en Detener.
10. Según Microsot: "El servidor virtual SMTP puede tardar varios minutos en detenerse", vamos que yo, después de esperar "varios minutos", eso no se detenía, con lo que decidí salir (no salía, así que finalizando la tareaaaa mmc), volví a entrar y ya aparecía como detenido. En fin...
11. Una vez detenido, ahora toca volver a iniciarlo. Aquí, Microsoft vuele a decir "El servidor virtual SMTP puede tardar varios minutos en iniciarse", ni de coña, todas las veces que lo he hecho arranca cagando leches.
12. Una vez iniciado, el servidor virtual SMTP predeterminado puede volver a enumerar los mensajes y ponerlos en una cola para el conector SmallBusiness SMTP.
13. Expandir Servidor virtual SMTP predeterminado y hacer clic en Colas.
14. Buscar la cola para el conector SmallBusiness SMTP. La cola se indica mediante un pequeño reloj rojo en el icono de carpeta amarillo.
15. Borrar los mensajes seleccionando de 10.000 en 10.000 (por ejemplo), y elegir Eliminar todos los mensajes (sin NDR).
16. Cuando los mensajes se hayan eliminado, hacer clic con el botón derecho en Colas y, después, hacer clic en Actualizar.
17. Comprobar que el número total de mensajes es 0.
18. Una vez eliminados todos los mensajes, hay que deshacer todo lo que hemos hecho anteriormente (crear el conector falso, el horario de envío, etc)
    

Cambiar el puerto de escucha de escritorio remoto

¿Nunca hemos tenido la necesidad de cambiar el puerto de escucha del escritorio remoto de Windows? Pues yo si. Caso que se puede dar cuando tenemos en la red más de un equipo preparado para conectarnos desde el exterior.

Bueno pues los pasos, además de configurar el Router para que apunte al equipo en cuestión cuando reciba una solicitud desde ese puerto, son los siguientes:

1. Iniciar el Editor del Registro (Regedt32.exe).
2. Buscar la siguiente clave del Registro: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\TerminalServer\WinStations\RDP-Tcp\PortNumber
3. En el menú Edición, hacer clic en Modificar, Decimal, escribir el nuevo número de puerto y, después, hacer clic en Aceptar.
4. Salir del Editor del Registro.

Y nada más...

Maldito SPAM

Esta semana pasada hemos tenido en un cliente una incidencia cuanto menos, curiosa. Resulta que la cola de salida de SMTP del servidor de Exchange se le bloqueaba con más de 700.000 correos de postmaster y otros.

En principio, es algo típico de los reenviadores de exchange, que han de estar desactivados para que todo el spam que le llegue al servidor no se devuelva a su destinatario diciéndole que el usuario no se encuentra en la organización. Microsoft tiene al respecto varios enlaces que solucionan dicho problema.

http://support.microsoft.com/kb/324958/es

Pero... ¿qué hacer cuando ni tan siquiera haciendo esto se soluciona? Pues es que la infección viene de dentro. Vamos, que tenemos un equipo que está "spameando" (no se si existe dicho término) dentro de la organización.

Fácil averiguarlo, con todos los equipos apagados, la cola sin aumentar, al segundo equipo que encendí... Retiramos ese equipo, lo formateamos y todo normalizado.