Preguntas y problemas de Active Directory y la arquitectura de Exchange

Aquí está el trasfondo de nuestra situación ...

En este momento, estamos configurados como tres compañías distintas con tres sistemas completos de Active Directory y Exchange. Las tres oficinas (una en los EE. UU., Dos en Europa) están conectadas a través de una configuración de VPN de tres vías (por lo que cada oficina tiene comunicación segura con las otras dos). Hay una configuración de relación de confianza bidireccional en Active Directory para cada configuración. Todos los sistemas ejecutan Server 2003 y Exchange 2003.

Hay alrededor de 160 buzones entre las compañías y 80 usuarios (los buzones adicionales son para subsistemas de TI, cuentas de reenvío u otros usos).

Las compañías se están fusionando oficialmente (en lugar de solo tener una relación de confianza). Así que estamos buscando una solución combinada (basada en un nuevo nombre) donde cada oficina estará en los mismos sistemas (Exchange y Active Directory), así como consolidar nuestra infraestructura de TI (hay mucha duplicación).

Contrataron a una empresa externa para que ingresara y auditara nuestra infraestructura de TI. Han hecho una recomendación oficial para externalizar la infraestructura de TI (y adivinen qué, quieren proporcionar el servicio).

Me encargaron averiguar qué hacer. Lo he pensado bastante, y se me han ocurrido dos opciones. La diferencia básica es dónde se aloja Exchange (internamente nuestro tercerizado). Dado que la externalización es fácil de comprender, solo detallaré la configuración interna.

Dado que se requiere alta disponibilidad, queremos que se incorpore un poco de redundancia geográfica. Entonces, lo que se me ocurre es lo siguiente (llamaré a las oficinas Site1, Site2 y Site3):

Sitio1:

• Rol de FSMO Active Directory
• Rol de buzón de Exchange: primario
• Acceso de cliente de Exchange, roles del servidor de transporte de concentradores
• Rol compartido de archivos DFS (para unidades compartidas)

Sitio2:

• Rol de Active Directory: replicado del sitio1
• Rol del buzón de Exchange: secundario, replicado mediante la replicación CCR
• Acceso de cliente de Exchange, roles del servidor de transporte de concentradores
• Rol compartido de archivos DFS

Sitio3:

• Rol de Active Directory: replicado del sitio1
• Acceso de cliente de Exchange, roles del servidor de transporte de concentradores
• Testigo de recurso compartido de archivos (para conmutación por error)
• Rol compartido de archivos DFS

Entonces, básicamente, el clúster debería ser capaz de sobrevivir a una falla en un solo sitio sin derribar ninguno de los otros sitios (o ninguno de los sistemas). En el caso de una falla doble del sitio, Exchange se detendría por completo.

Entonces, mis preocupaciones son las siguientes:

1. ¿Es esta una configuración razonable? ¿O estoy sobre complicando las cosas?
2. El número de servidores necesarios (3 en cada sitio ya que los roles de buzón CCR deben ser el único rol instalado)
3. ¿Funcionará incluso como resumido (donde se conmutará por error automáticamente al nodo disponible en caso de que un sitio o servidor se caiga)?
4. Dado que cada oficina especificaría un servidor de acceso de cliente local para sus usuarios, ese servidor se convierte en un único punto de falla para todas las solicitudes locales (pero esto se puede resolver mediante un cambio manual de DNS)
5. ¿Todos estos servidores deben estar en la misma subred IP para que esto funcione? ¿O puedo dejar de usar un DNS jerárquico para ello (clientaccess.site1.foo.com, etc.)?
6. Esto me permitirá configurar cada oficina como un registro MX (ya que hay un servidor de transporte de concentradores en cada oficina para conectarse a Internet), por lo que si una oficina deja de funcionar, aún deberíamos poder recibir correos electrónicos en las otras, ¿correcto?
7. Mantenibilidad Tengo miedo de que esta configuración sea demasiado complicada para mantenerla a largo plazo (agregar oficinas, eliminar oficinas, actualizar servidores (sistema operativo y hardware), etc.). ¿Es un miedo justificado?

Ahora, también está la cuestión de si ir con el servidor 2003 o 2008 ... Si tomamos la ruta interna de Exchange, creo que puedo convencer a los poderes de actualizar a 2008 (de hecho, tendríamos que actualizar para usar Exchange 2010) ... Pero es realmente necesario o es que solo uno de mis "deseos" se infiltró en los planes (en lugar de una actualización justificable) ...

Ahora, una parte de mí solo quiere optar por Exchange subcontratado, ya que aliviará algunos de estos problemas (o la mayoría de ellos). Sin embargo, después de analizar los costos, el punto de equilibrio es de aproximadamente 1 año, por lo que después de eso, la subcontratación será considerablemente más costosa. Combine eso con el hecho de que algunas características de las que dependemos no se pueden externalizar, al menos con las empresas que analizamos, (como buzones compartidos, acoplamiento de Active Directory, incluido SSO, administración centralizada, seguridad de datos, etc.). Así que estoy realmente desgarrado sobre dónde ir con esto ...

Este es el primer proyecto de esta escala que estoy intentando, por lo que cualquier ayuda sería muy apreciada ...

Gracias de antemano (y perdón por el libro) ...

Estamos en una situación similar, excepto por el hecho de que en nuestro caso ya somos una empresa. Pero tenemos oficinas en Cambridge, Londres, Estocolmo, Shanghai y Atlanta. Todo conectado a través de VPN. Tres de estos tienen servidores de Exchange (2 en Exchange 2010, el tercero se actualizará muy pronto). La mayoría de nuestros controladores de dominio ejecutan Windows 2003, pero estamos en camino de actualizarlos a Windows 2008. Tenemos alrededor de 150 empleados, distribuidos por todo el lugar. Muy similar a tu situación.

Aquí hay algunas respuestas desde mi punto de vista:

1. Si tiene un equipo de TI decente, nunca consideraría la contratación externa. De hecho, incluso si su equipo no es decente, preferiría dedicar algo de esfuerzo para hacerlo decente. Sus tiempos de respuesta serán mucho mejores, su configuración de seguridad es más simple, pero lo más importante de todo: su equipo de TI se centrará principalmente en mantener la infraestructura de TI funcionando de la mejor manera. El enfoque principal del proveedor de outsourcing está en sacar el máximo provecho de usted, no en proporcionar el mejor servicio.
2. Su configuración planificada es muy factible. Su principal desafío será migrar todo a un dominio común, pero eso se puede hacer paso a paso.
3. Los servidores para la mayoría de lo que necesita no le costarán un brazo y una pierna. Si necesita comprar servidores adicionales, el desembolso de capital para eso será pequeño.
4. Si funciona o no como se resume, depende de qué tan bien tenga configurado su DNS público y su enrutamiento interno. Definitivamente se puede hacer que funcione.
5. Recomiendo encarecidamente tener subredes separadas para cada oficina. Hace que la vida como administrador de sistemas sea MUCHO más fácil. Use una subred de tamaño decente para cada oficina, y luego use enrutamiento estático para el tráfico entre los sitios u OSPF (la mayoría de los enrutadores VPN decentes ofrecerán OSPF de fábrica). En realidad, tenemos 2 subredes separadas en la mayoría de las oficinas, manteniendo el tráfico corporativo normal separado del tráfico de ingeniería (ya que nuestros ingenieros tienden a hacer muchas cosas funky con DNS, DHCP, transmisión de video y más). Y funciona de maravilla. De hecho, incluso llegamos al punto en que los ingenieros de cualquier oficina pueden usar una transmisión de video desde un transmisor en cualquier otro lugar, sin tener que saber de dónde proviene.
6. NO intente tener todas las computadoras en una subred grande. Te arrancarás el pelo. Promesa.
7. Tenemos tres puertas de enlace de correo público (ubicadas en las oficinas con el mayor ancho de banda de conexión a Internet), todas configuradas exactamente de la misma manera y todas reenviadas al servidor de Exchange más cercano, desde donde se distribuye el correo a los buzones finales. No hay problema.
8. Una vez que tenga un control básico sobre el enrutamiento y similares, encontrará que esto no es difícil de mantener. Tengo un total de alrededor de 150 servidores repartidos en todos estos sitios, aproximadamente media docena de enrutadores VPN, varias docenas de conmutadores administrados. Somos una configuración mixta (30% de Windows, 70% de Linux, en servidores y estaciones de trabajo) y tengo 4 personas que me informan. No es un problema en absoluto.

Confíe en su capacidad de aprender y tendrá éxito. El plan es bueno. Iría con Windows Server 2008 y migraría los servidores de Exchange uno por uno a Exchange 2010. Para la migración de Exchange, es posible que necesite ayuda externa (la necesitamos, y mis muchachos generalmente son bastante buenos con Exchange), pero si lo es temeroso del diseño de capital inicial, también puede migrar todo uno por uno. No hay necesidad de hacer todo esto de una sola vez.