Anatol Emilio Lopez Maitchovcow

Como comprobar la conectividad de la Infraestructura de Exchange

muchas veces nos preguntamos como podemos comprobar que la infraestructura esta bien, o si el flujo saliente o entrante de correo es correcto para ello les traigo una de las mejores recomendaciones hecha por Microsoft

Vyatta solucion integral de router y seguridad para entornos virtualizados

La mejor Solucion Virtualizada para Seguridad Integral de Red, Balanceo, Firewall, Routing, DNS, VPN.

Generar Certificados con PowerShell

Como Generar Certificados con multiples Alias para nuestros Servidores de Exchange.

jueves, 5 de julio de 2012

como recuperar el Directorio Virtual de IIS de PowerShell

Hola existe varios motivos por el cual no podemos ver obligados a restaurar el directorio virtual de PowerShell, Para los que no conoces este directorio es al cual se conecta tanto la consola de Exchange mas conocida por EMC, o el PowerShell for Exchange, puede que nos tengamos que ver oblicagos a restaurar dicho directorios, para ello debemos seguir los siguientes pasos:

  1. Abrir una consola de PowerShell en modo Administrador (En el servidor a restaurar).
  2. Importamos los modulos de Exchange con el siguiente comando. “Add-PSSnapin Microsoft.Exchange.Management.PowerShell.E2010”
  3. Podremos listar los directorios de PowerShell que esta disponibles con el comando “Get-PowerShellVirtualDirectory |fl”.
  4. Posteriormente debemos eliminar el directorio, para ello debemos ejecutar el siguiente comando.”Get-PowerShellVirtualDirectory | Remove-PowerShellVirtualDirectory
    Remove-PowerShellVirtualDirectory -identity "powershell-vdir "”.(esto eliminara todos del anterior listado en caso de querer eliminar solo el del servidor, debemos ejecutar Remove-PowerShellVirtualDirectory -identity "powershell-vdir ")
  5. Reiniciaremos el IIS “IISRESTART”
  6. Crearemos el Directorio Virtual “New-PowerShellVirtualDirectory
    Name: PowerShell”
  7. Reiniciaremos el IIS “IISRESTART”
  8. ahora desabilitaremos el que requiera certificado para su conexion “Set-PowerShellVirtualDirectory -identity "powershell-vdir" -RequireSSL:$false”

 

     

como convertir tu windows 7 en un punto de acceso

Hola muchas veces no disponemos de wifi, y necesitamos que nuestros dispositivos se conecten a una red, y no disponemos de mas cables, o nuestros smartphone no dispone de este tipo de conexión, para ello podemos hacer que nuestro portátil o pc de casa actué de Punto de Acceso. En el siguiente apartado les dejo como configurar el windows 7.

Lo primero que debemos hacer es abrir un CMD en Modo Administrador.

netsh.exe wlan set hostednetwork mode=allow ssid=HotSpot key=ab123456789 keyUsage=persistent

Donde dice ssid es el nombre de la Wifi o su identificador, KEY colocaremos la clave de WEP que deseamos para nuestra WiFi en el caso de dejarla en blanco, la WiFi no sera segura y se configurara como una red Abierta.

A continuacion en el mismo CMD escribiremos “netsh.exe wlan start hostednetwork” con esto activaremos el servicio de punto de acceso.

NOTA: En el caso de algunos portátiles es necesario el habilitar la red WiFi antes de levantar dicho servicio. Esto dependerá de marca, modelo, y la configuración de ahorro de energía.

y a continuación abriremos el el centro de redes y centro compartido, Seleccionaremos configuración de adaptadores de red. Seleccionaremos el adaptador con internet, botón de la derecha, propiedades. Una vez abierto el cuadro de propiedades, seleccionaremos la pestaña compartir. Seleccionamos Habilitar esta red para otros usuarios y permitir que se conecten a este equipo para conectarse a internet. Seleccionaremos el adaptador correspondiente que será uno nuevo que se crea con la ejecución de las líneas de comando anteriores, y que será “Microsoft Virtual WiFi Miniport” y con esto ya tenemos configurado nuestro Windows 7 como un Punto de Acceso.

martes, 3 de julio de 2012

Migración detallada de Exchange 2003 a Exchange 2010

Cualquier actualización de organización desde Exchange 2003 tendrá un período de coexistencia. En un escenario de coexistencia, cualquier combinación de las siguientes versiones de Microsoft Exchange se implementa en una única organización de Exchange: Exchange 2003, Exchange 2007 y Exchange 2010. Este tema se centra principalmente en la coexistencia de Exchange 2003 y Exchange 2010.

En un escenario de coexistencia, varias versiones de Exchange se pueden comunicar entre sí y compartir recursos de datos, información de destinatarios e información de configuración. Partes de la organización aún hacen uso de la funcionalidad Exchange 2003, y otras han completado la actualización a Exchange 2010.

Importante: 

Solo se pueden instalar servidores de Exchange 2003 adicionales en la organización si había un servidor Exchange 2003 cuando se instaló el primer servidor de Exchange 2010. 

Tenga en cuenta los siguientes problemas de coexistencia:

·         Active Directory y dominios   Al realizar la actualización de Exchange 2003 a Exchange 2010, primero debe conceder permisos de Exchange específicos en cada uno de los dominios en los que se ejecutó DomainPrep de Exchange 2003. Para hacerlo, ejecute el comando setup /PrepareLegacyExchangePermissions. La concesión de estos permisos forma parte de la preparación del servicio de directorio de Active Directory y sus dominios para la instalación de Exchange 2010. Para obtener instrucciones detalladas, consulte Preparar Active Directory y los dominios.

·         Interfaces de administración   En Exchange 2010, puede administrar servidores y buzones de Exchange 2010 mediante el uso de la Consola de administración de Exchange (EMC) o el Shell de administración DE Exchange. Además se puede usar la EMC para ver algunos atributos en servidores de Exchange 2003. Para obtener más información, consulte Interoperabilidad de la Consola de administración de Exchange.

·         Características de rol de servidor   Las características de rol de servidor de Exchange 2010 disponibles para los clientes en la organización de Exchange durante el período de coexistencia dependen de la versión del servidor de Exchange en el que está almacenado el buzón del usuario y la versión de la aplicación de cliente de correo electrónico que se usa para obtener acceso a Exchange.

·         Grupos de enrutamiento   En una organización grande, con muchos grupos de enrutamiento, se debe planear la topología de enrutamiento para mantener el flujo de correo durante el período de coexistencia. Al planificar un período de coexistencia entre Exchange 2003 y Exchange 2010, debe comprender de qué forma cada versión determina su topología de enrutamiento. Para obtener más información acerca del enrutamiento y la coexistencia, consulte Actualización desde el servicio de transporte de Exchange 2003.

·         Modo nativo   Exchange 2010 solamente se puede implementar en una organización de Exchange 2003 que funcione de modo nativo. Para obtener más información acerca de cómo cambiar su organización Exchange 2003 al modo nativo.

Diferencias de administración

Exchange 2003 usa grupos administrativos para organizar los objetos de Exchange para delegar el permiso para administrar estos objetos. Exchange 2010 no usa grupos administrativos como unidad de administración lógica para la delegación administrativa.

No obstante, para que sea posible la coexistencia entre Exchange 2003 y Exchange 2010, todos los servidores de Exchange 2010 se ponen en un único grupo administrativo cuando se instala Exchange 2010. Este grupo administrativo se reconoce en el Administrador del sistema de Exchange de versiones anteriores de Exchange como Grupo administrativo de Exchange (FYDIBOHF23SPDLT).

Precaución: 

No mueva los servidores de Exchange 2010 fuera del grupo administrativo de Exchange (FYDIBOHF23SPDLT) y no cambie el nombre del grupo administrativo de Exchange (FYDIBOHF23SPDLT) mediante un editor de directorios de bajo nivel. Exchange 2010 debe usar este grupo administrativo para el almacenamiento de datos de configuración. No se admite el movimiento de los servidores de Exchange 2010 fuera del grupo administrativo de Exchange (FYDIBOHF23SPDLT) o el cambio de nombre del grupo administrativo de Exchange (FYDIBOHF23SPDLT).  

 

Se debe usar el Administrador del sistema de Exchange y las utilidades para administrar los servidores de Exchange 2003. En Exchange 2010, debe administrar los servidores y los buzones de Exchange 2010 mediante la EMC o el Shell. Sin embargo, puede usar la EMC para ver algunos atributos en los servidores de Exchange 2003. Para obtener más información acerca de la interoperabilidad de la EMC.

Coexistencia de modo mixto de Exchange 2007 y Exchange 2003

Cuando esté listo para actualizar un entorno de modo mixto, actualice cada uno de los sitios de Active Directory por separado. Si cuenta con sitios de Active Directory que solo tienen disponible Exchange 2007 o Exchange 2003, siga las instrucciones siguientes para actualizar la versión pertinente del sitio de Active Directory. Por ejemplo, si dispone de Exchange 2007 en el sitio A de Active Directory, siga las instrucciones de actualización para Exchange 2007. Si, en cambio, tiene instalado Exchange 2003 en el sitio B de Active Directory, siga las instrucciones de actualización para Exchange 2003. Para obtener más información sobre cómo actualizar sus versiones de Exchange 2003 y Exchange 2007.

Si cuenta con sitios de Active Directory que tienen instalado Exchange 2003y Exchange 2007, siga las instrucciones de actualización de Exchange 2003 y Exchange 2007, y complete los pasos de actualización necesarios para ambos sistemas. Para obtener más información sobre cómo actualizar su sistema a Exchange 2010 en este escenario, consulte los siguientes temas:

Descripción de la actualización a Exchange 2010

Exchange Server 2010 se puede implementar en un bosque de Active Directory que tenga un sistema de mensajería existente. Se da una situación de coexistencia si se cumplen las siguientes condiciones:

· Exchange Server 2010 se implementa en una organización existente de Exchange.

· Existe más de una versión de Microsoft Exchange que proporciona servicios de mensajería a la organización.

No se puede actualizar una organización de Exchange 2000 existente a Exchange 2010 directamente. Primero, debe actualizar la organización de Exchange 2000 a una organización de Exchange 2003 o Exchange 2007 y, a continuación, puede actualizar la organización de Exchange 2003 o Exchange 2007 a Exchange 2010. Le recomendamos que actualice su organización de Exchange 2000 a Exchange 2003 y, luego, actualice de Exchange 2003 a Exchange 2010. Para obtener más información sobre la actualización de Exchange 2000, consulte Diseño de una actualización de Exchange 2000 y Actualizar a Exchange 2007.

Si una organización realiza el tránsito gradual de su sistema de mensajería de Exchange Server 2003 o Exchange Server 2007 a Exchange 2010, probablemente deba mantener más de una versión de Exchange durante ese tiempo.

En la siguiente tabla, se enumeran los casos en los que se admite la coexistencia de Exchange 2010 y versiones anteriores de Exchange.

Coexistencia de Exchange 2010 y versiones anteriores de Exchange Server

Versión de Exchange

Coexistencia de organización de Exchange

Exchange 2000 Server

No se admite

Exchange Server 2003

Se admite

Exchange 2007

Se admite

Organización mixta de Exchange 2007 y Exchange Server 2003

Se admite

 

Proceso de actualización de Exchange 2003 a Exchange 2010

Ésta es una descripción general de alto nivel de los pasos de actualización que se siguen para actualizar de Exchange 2003 a Exchange 2010.

En primer lugar, actualice todos los sitios de Internet Active Directory mediante los siguientes procedimientos:

1.      Actualización de los servidores de Exchange 2003 existentes de Exchange 2003 Service Pack 2 (SP2).

2.      Implemente los servidores de Exchange 2010 en este orden:

a.       Acceso de cliente

b.      Transporte de concentradores

c.       Mensajería unificada

d.      Buzón

3.      Configure el servidor front-end de Exchange 2003 y el servidor de acceso de cliente de Exchange 2010.

4.      Configure el servidor Transporte de concentradores de Exchange 2010 y los servidores Mensajería unificada.

5.      Mueva los buzones de Exchange 2003 a Exchange 2010.

A continuación, actualice todos los sitios internos Active Directory de la misma manera.

La siguiente figura ilustra la descripción general del proceso de actualización de Exchange 2003 a Exchange 2010.

Orden de sitios de Active Directory para actualizar

Tal y como se muestra en la figura anterior, al actualizar una organización a Exchange 2010, se debe comenzar por los servidores que se encuentran en los sitios de Active Directory accesibles a través de Internet y, a continuación, actualizar los sitios de Active Directory internos. Este enfoque es necesario porque la conexión proxy del servidor de acceso de cliente al servidor de acceso de cliente solo es compatible desde las versiones más recientes del rol de servidor Acceso de clientes (Exchange 2010) a versiones más antiguas del rol del servidor Acceso de clientes (Exchange 2007) y no a la inversa.

Orden de los roles de servidor para actualizar

En el primer sitio o sitios de Active Directory que actualice, el primer rol de servidor de Exchange 2010 que se instala es el rol de servidor Acceso de clientes. Recomendamos que actualice un único sitio de Active Directory a Exchange 2010 al mismo tiempo. Según el tamaño de su sitio Active Directory, debería ser un único equipo de servidor de acceso de cliente o una matriz con equilibrio de carga de los equipos de servidor de acceso de cliente de Exchange 2010.

Se recomienda el orden siguiente para la instalación de roles de servidor de Exchange 2010:

1. Rol de servidor Acceso de clientes

2. Rol del servidor Transporte de concentradores

3. Rol de servidor Mensajería unificada (MU)

4. Rol de servidor Buzón de correo

NOTA:

Al actualizar a Exchange 2010, no puede realizar una actualización de servidor in situ de un servidor de Exchange existente.

Más tarde se puede agregar el rol de servidor Mensajería unificada, o si desea instalarla al mismo tiempo que otros roles de servidor, debe seleccionar Instalación personalizada de Exchange Server.

NOTA:

Debe implementar el rol de servidor Transporte perimetral en la red perimetral y fuera del bosque de Active Directory

Diferencias de administración Microsoft Exchange Server 2010

La Consola de administración de Exchange (EMC) está disponible en Exchange Server 2010 y Exchange Server 2007. A continuación, se enumeran las tareas y las acciones que pueden realizarse con la EMC en Exchange 2010 o Exchange 2007:

· Las acciones que crean objetos, como un nuevo buzón o una nueva libreta de direcciones sin conexión (OAB), solamente se pueden llevar a cabo en una versión de la EMC que sea igual a la del objeto de destino. Por ejemplo, para crear un buzón en un servidor de buzones de Exchange 2007, debe usarse la EMC en Exchange 2007. Se aplica lo siguiente:

o Las bases de datos de buzones de Exchange 2007 no pueden ser administradas por la EMC en Exchange 2010, aunque sí pueden verse.

o La EMC en Exchange 2010 no puede habilitar ni deshabilitar los buzones de mensajería unificada de Exchange 2007.

o La EMC en Exchange 2010 no puede administrar dispositivos móviles de Exchange 2007.

· Las acciones que requieren la visualización de objetos pueden realizarse desde cualquier versión de la EMC a cualquier versión de objetos de Exchange, con algunas excepciones:

o Los objetos de regla de transporte de Exchange 2010 y Exchange 2007 solo pueden ser visualizados desde la versión correspondiente de la EMC.

o Los servidores de Exchange 2010 y Exchange 2007 solo pueden visualizarse en la versión correspondiente de la EMC.

o La herramienta Visor de cola de la EMC en Exchange 2010 no se puede conectar con un servidor de Exchange 2007 para ver las colas o los mensajes.

NOTA:

Si un objeto de Exchange 2007 (por ejemplo, un grupo de almacenamiento) no se encuentra en Exchange 2010, no hay interoperabilidad esperada ni proporcionada, ya que Exchange 2010 no tiene constancia de la característica.

o No puede usar las tareas de configuración de seguimiento de mensajes entre Exchange 2010 y Exchange 2007. Debe usar las herramientas de seguimiento de mensajes de Exchange 2007 en los servidores Exchange 2007 y las herramientas de seguimiento de mensajes de Exchange 2010 en los servidores Exchange 2010.

Coexistencia del rol de servidor Microsoft Exchange Server 2003

En esta sección se proporcionan detalles acerca de cada rol de servidor de Exchange 2010 en un escenario de coexistencia.

Coexistencia del servidor de acceso de cliente

El rol de servidor de acceso de cliente proporciona nuevas características además de toda la funcionalidad proporcionada por un servidor front-end en Exchange 2003. Toda la conectividad de cliente (incluida la conectividad MAPI de Microsoft Outlook) ahora funciona mediante el rol de servidor de acceso de cliente. Los clientes ya no se conectan directamente al rol de servidor de buzón. El rol de servidor Acceso de clientes puede coexistir con servidores de Exchange 2003. En la siguiente lista se describen las dependencias y los requisitos del servidor de acceso de cliente de Exchange 2010 para la coexistencia con Exchange 2003:

· El hecho de que el usuario consulte el cliente de Outlook Web App de Exchange 2003 o el cliente de Outlook Web App de Exchange 2010 depende de la ubicación de su buzón. Por ejemplo, si el buzón se encuentra en un servidor back-end de Exchange 2003 y en el servidor de acceso de cliente se ejecuta Exchange 2010, el usuario verá Outlook Web Access, el cliente de Exchange 2003.

· La versión de Exchange ActiveSync que usen los clientes depende de la versión del servidor en que se encuentra el buzón del cliente. El buzón del usuario debe ubicarse en un servidor que ejecute Exchange 2003 SP2 o Exchange 2010 para que Direct Push se habilite para Exchange ActiveSync.

· Al realizar una actualización de Exchange 2003 a Exchange 2010, normalmente se actualizan todos los servidores de Exchange de un grupo de enrutamiento o sitio de Active Directory específico a Exchange 2010 a la vez, se configura la coexistencia y, a continuación, se actualiza el sitio siguiente.

Importante:

Al actualizar una organización de Exchange 2003, se requiere un servidor front-end de Exchange 2003 compatible con la actualización. Para cada servidor de acceso de cliente de Exchange 2010, solo se puede configurar una dirección URL de Outlook Web Access 2003 para redireccionamiento. Para ello, se necesita un único servidor front-end de Exchange 2003 o una matriz con equilibrio de carga de los servidores front-end de Exchange 2003.

Para obtener más información acerca de la coexistencia del servidor de acceso de cliente entre Exchange 2003 y Exchange 2010, y para obtener información sobre las nuevas características de Exchange 2010, consulte Actualizar desde el servicio de acceso de cliente de Exchange 2003.

Exchange 2007 introdujo los servicios Detección automática y Disponibilidad, y Exchange 2010 continúa dependiendo de estos servicios:

· El servicio Detección automática configura equipos cliente que ejecutan Microsoft Outlook 2010, Outlook 2007, Entourage y otras aplicaciones cliente. El servicio Detección automática también puede configurar dispositivos móviles compatibles. El servicio Detección automática permite el acceso a las características de Exchange a los clientes de Outlook 2010 que están conectados al entorno de mensajería de Exchange.

· El servicio Disponibilidad mejora la experiencia de calendario y planeación de reuniones de los trabajadores de información facilitando información de disponibilidad segura, coherente y actualizada a los equipos que ejecutan Outlook 2007 o Outlook 2010.

Coexistencia del servidor Transporte de concentradores

El rol del servidor Transporte de concentradores está diseñada para administrar todo el flujo de correos de la organización de Exchange. También es responsable de administrar las reglas de transporte, las directivas de registro en el diario y la entrega de mensajes. Este servidor se implementa en el bosque de Active Directory y es necesario para que los buzones de Exchange 2010 envíen y reciban mensajes. El servidor Transporte de concentradores retransmite los mensajes que se envían a Internet al rol de servidor Transporte perimetral o a un host inteligente de terceros.

Puede agregar un servidor Transporte de concentradores de Exchange 2010 a una organización de Exchange existente después de implementar de manera satisfactoria los servidores de acceso de cliente de Exchange 2010. Cuando se introducen los servidores Transporte de concentradores de Exchange 2010 en su entorno de Exchange 2003, todos los servidores Transporte de concentradores de Exchange 2010 se colocan en un grupo de enrutamiento único y separado.

Para habilitar el flujo de correo entre la implementación de Exchange 2010 y la organización de Exchange 2003 existente, debe crear un conector de grupo de enrutamiento. Este conector grupo de enrutamiento se crea durante la instalación del primer servidor Transporte de concentradores de Exchange 2010.

Coexistencia del servidor de buzones

Para que coexistan los servidores de buzones de Exchange 2010 y Exchange 2003, se debe poder enviar correo entre los buzones. Exchange 2010 usa el servidor Transporte de concentradores para enviar correo. Es necesario implementar un servidor Transporte de concentradores de Exchange 2010 en cada sitio de Active Directory que contenga un servidor de buzones de Exchange 2010. Además, se necesita un servidor de acceso de cliente en cada sitio de Active Directory en el que existe un servidor de buzón. Si mueve un buzón desde Exchange 2003 a Exchange 2010, y el buzón forma parte de una directiva de direcciones de correo electrónico, las direcciones de dicho buzón se actualizarán automáticamente según la configuración de la directiva de direcciones de correo electrónico. Si el buzón tenía una dirección SMTP principal diferente de la dirección de correo electrónico impuesta por la directiva, la dirección SMTP principal se convertirá en secundaria y la dirección generada por la directiva se convertirá en la dirección SMTP principal.

Puede replicar los datos de las carpetas públicas entre las bases de datos de las carpetas públicas de Exchange 2010 y Exchange 2003. Para ello, se debe crear una réplica de la carpeta pública mediante el uso del Administrador del sistema de Exchange 2003 Exchange.

Coexistencia del servidor Mensajería unificada

El rol de servidor Mensajería unificada está diseñado para proporcionar mensajería unificada para destinatarios de Exchange 2010. La mensajería unificada aúna mensajes de voz y de correo electrónico en un almacén al que se puede tener acceso desde un teléfono, el equipo de un usuario o un dispositivo móvil. Los usuarios pueden tener acceso a los mensajes de voz, al correo electrónico y a la información de calendario de su buzón de Exchange 2010 desde clientes de correo electrónico como, por ejemplo, Outlook y Outlook Web App.

La función del servidor Mensajería unificada depende de las funciones de servidor Transporte de concentradores y Buzón de correo. Todo el correo SMTP enviado desde un servidor Mensajería unificada debe enviarse a un servidor Transporte de concentradores de Exchange 2010. Para que los destinatarios puedan usar la mensajería unificada deben tener un buzón de Exchange 2010.

Las versiones de Exchange anteriores a Exchange 2007 no se pueden actualizar y usted debe implementar una organización de Exchange 2010 con todos los roles de servidor de Exchange, incluida la mensajería unificada, y después mover los buzones de Exchange 2003 (o versiones anteriores) a un servidor de buzones de Exchange 2010.

Coexistencia del servidor de transporte perimetral

La función del servidor Transporte perimetral está diseñada para mejorar la protección antivirus y frente al correo no deseado en la organización de Exchange. El servidor de transporte perimetral, además, aplica directivas a los mensajes que se envían de unas organizaciones a otras. Esta función de servidor se implementa en la red perimetral y fuera del bosque de Active Directory. El servidor Transporte perimetral se puede implementar como host inteligente y servidor de retransmisión SMTP en una organización de Exchange 2003 existente.

Puede agregar un servidor de transporte perimetral a cualquier organización de Exchange existente sin actualizar los servidores internos de Exchange ni tener que hacer ningún cambio en la organización. Tampoco hay que llevar a cabo ninguna preparación de Active Directory al instalar el servidor Transporte perimetral.

Si usa el Filtro inteligente de mensajes de Exchange en Exchange 2003 para realizar tareas de protección contra correo no deseado, puede usar el servidor Transporte perimetral para agregar un nivel adicional de protección. El servidor de transporte perimetral ofrece protección contra virus y correo no deseado cuando los mensajes llegan a la red.

Si se implementa un servidor Transporte perimetral en Exchange 2010 para que sea compatible con una organización de Exchange que aún no haya implementado Exchange 2010, solo habrá disponible un grupo limitado de características. En este caso, no se puede crear una suscripción perimetral. En consecuencia, no se puede usar la búsqueda de destinatarios ni la agregación de listas seguras.

NLB Microsoft

NOTA: Se debe de tener en cuenta que si hacemos un NLB, debemos crear los registros manualmente en el DNS, adicionalmente debemos tener en cuenta las recomendaciones de los fabricantes de Firewall y Routers ya que NLB, no sigue las normas en la creación de las MAC-Address Virtuales para las interfaces VIP, para entender como realizar la creación de entradas manuales en la tabla ARP de nuestro Router debemos seguir el siguiente procedimiento.

Ejemplo de configuración de un Switch Cisco para el soporte de NLB.

Primero debemos entender que es UNICAST y MULTICAST, para ello daremos una breve explicación de los dos tipos de NLB que podremos crear.

UNICAST

Esta es la opción por defecto y es la opción recomendada. La dirección MAC del Cluster, es asignada a todas las tarjetas de red asignadas al Cluster NLB, y la dirección MAC de cada tarjeta de red NO es utilizada. Es decir, cada tarjeta de red asignada al Cluster NLB mantiene una única dirección MAC, en particular, la MAC del Cluster. Así, tanto la dirección IP del Cluster como la dirección IP propia de la tarjeta de Red, se resuelven a la dirección MAC del Cluster, ya que se sobrescribe la dirección MAC real de las tarjetas de red del Cluster NLB con la dirección MAC del Cluster.

Esta configuración, implica que NO es posible la comunicación desde un Host del Cluster NLB a otro Host del Cluster NLB a través de la tarjeta de red utilizada en el Cluster, debido a que al compartir la dirección MAC (es decir, utilizar la misma dirección MAC en el equipo de origen y en la tarjeta de red del equipo destino), se produce una confusión, es decir, en el nivel de enlace OSI (Ethernet y direcciones MAC) no es posible diferenciar al destinatario del emisor, y por ello, la comunicación host-to-host (también conocida como intra-host) NO es posible.

Es interesante recordar (para aquellos pocos que lo puedan utilizar) que al utilizar Application Center 2000 para configurar NLB, se especificará el modo de operación del Cluster NLB en Unicast, conforme indicar el artículo de soporte KB 278431.

MULTICAST

La dirección MAC del Cluster, es asignada a todas las tarjetas de red asignadas al Cluster NLB, pero de forma adicional, cada tarjeta de red mantiene su dirección MAC. Es decir, cada tarjeta de red asignada al Cluster NLB mantiene dos direcciones MAC, pero sólo la dirección MAC del Cluster es utilizada para la comunicación con los equipos clientes. Así, la dirección IP del Cluster se resuelve a la dirección MAC del Cluster, y la dirección IP propia de la tarjeta de Red se resuelve a la dirección MAC propia de dicha tarjeta.

Este comportamiento implica que una tarjeta de Red de un Cluster NLB configurado en modo de operación Multicast, es capaz de manejar tanto el tráfico de los clientes (paquetes destinados a la dirección IP/MAC del Cluster) como el tráfico propio del Host (paquetes destinados a la dirección IP/MAC de la tarjeta de Red del Cluster NLB).

En algunos casos la utilización de direcciones MAC multicast, no es soportada por la implementación ARP de algunos enrutadores (routers), como es el caso de Cisco (ni más ni menos ;-), en cuyo caso, el Cluster NLB no será visible fuera del segmento Ethernet al que pertenece. Para evitar este tipo de problemas, debe garantizarse que el enrutador (Router) acepta respuestas ARP que incluyan una dirección MAC en el payload de la trama Ethernet, pero que parecen proceder de un dispositivo con una dirección MAC distinta, conforme se muestra en la cabecera Ethernet. Si el enrutador (router) o el conmutador multi-capa (multi-layer switch) correspondiente no soporta esta funcionalidad, es posible crear una entrada ARP estática en el router como solución al problema, para que así sea capaz de resolver la dirección IP Unicast a la dirección MAC Multicast correspondiente.

Multicast puede ofrecer un rendimiento inferior a Unicast, debido a que utiliza una única tarjeta de red tanto para el tráfico de los equipos clientes como para el tráfico host-to-host (también conocido como tráfico intra-host).

Al utilizar Multicast es posible activar la opción IGMP Multicast. La principal razón por la que activar o desactivar la opción IGMP Multicast, es en caso de descubrir algún tipo de problema de funcionamiento, como por ejemplo, problemas de convergencia.

Unas Vez explicado las opciones del NLB, procederemos a la configuración en el Switch, para ponernos en antecedentes explicaremos el entorno de Ejemplo.

La red se componen un Switch Cisco y dos equipos Windows con un NLB MULTICAST, con una IP virtual 172.16.241

 

 

Configuración Realizada en Catalyst 6509

Cat6K#show running-config

Building configuration...

!

version 12.1

service timestamps debug uptime

service timestamps log uptime

no service password-encryption

!

hostname Cat6K

!

boot buffersize 126968

boot system flash slot0:c6sup11-jsv-mz.121-8a.E.bin

!

redundancy

main-cpu

auto-sync standard

ip subnet-zero

!

!

interface GigabitEthernet1/1

no ip address

shutdown

!

interface GigabitEthernet1/2

no ip address

shutdown

!

interface FastEthernet2/1

description "Uplink to the Default Gateway"

no ip address

switchport

switchport access vlan 100

!

interface FastEthernet2/2

no ip address

shutdown

!

interface FastEthernet2/3

description "Connection to Microsoft server"

no ip address

switchport

switchport access vlan 200

!

interface FastEthernet2/4

description "Connection to Microsoft server"

no ip address

switchport

switchport access vlan 200

!

interface FastEthernet2/5

no ip address

shutdown

!

interface FastEthernet2/48

no ip address

shutdown

!

interface Vlan1

no ip address

shutdown

!

mac-address-table static 0300.5e11.1111 vlan 200 interface fa2/3 fa2/4 disable-snooping

! --- Creación de una entrada estática en el interruptor para el MAC de multidifusión virtual.

! --- fa2/3 Y fa2/4 son los puertos conectados al servidor.

!--- El desactivar snooping es aplicable sólo para switches de la serie Cisco Catalyst 6000/6500

arp 172.16.63.241 0300.5e11.1111

! --- 172.16.63.241 es la dirección IP virtual de los 2 servidores

interface Vlan100

ip address 172.17.63.240 255.255.255.192

!--- Vlan Del lado cliente

!

interface Vlan200

ip address 10.1.1.250 255.255.255.0

!--- Vlan Del lado Servidores

!--- Importante: Configure la puerta de enlace predeterminada

!--- del servidor de Microsoft a esta dirección.

!

ip classless

ip route 0.0.0.0 0.0.0.0 172.16.63.193

no ip http server

!

line con 0

line vty 0 4

login

!

End

Configurando proveedores gratuitos de Spam

estos proveedores de spam se basan muchas veces por denuncias, y reclamaciones de los usuarios, a continuación debéis abrir el PowerShell de vuestro edge Transport y pegar los siguientes comandos.

 

Add-IPBlockListProvider -Name "Spam and Open Relay Blocking System (SORBS) IP Block List Provider" -LookupDomain "dnsbl.sorbs.net"
Add-IPBlockListProvider -Name "SpamCop Blocking List (SCBL)IP Block List Provider" -LookupDomain "bl.spamcop.net"
Add-IPBlockListProvider -Name "Not Just Another Bogus List (NJABL.ORG)IP Block List Provider" -LookupDomain "dnsbl.njabl.org"
Add-IPBlockListProvider -Name "Composite Blocking List (CBL)IP Block List Provider" -LookupDomain "cbl.abuseat.org"
Add-IPBlockListProvider -Name "SpamHaus IP Block List Provider" -LookupDomain "zen.spamhaus.org"
Add-IPBlockListProvider -Name "Surriel IP Block List Provider" -LookupDomain "psbl.surriel.com"
Add-IPBlockListProvider -Name "BarracudaCentral IP Block List Provider" -LookupDomain "bb.barracudacentral.org"
Add-IPBlockListProvider -Name "Manitu IP Block List Provider" -LookupDomain "ix.dnsbl.manitu.net"
Add-IPAllowListProvider -Name "Spamhaus IP Allow List Provider" -LookupDomain "swl.spamhaus.org" -AnyMatch $true
Add-IPAllowListProvider -Name "Isipp IP Allow List Provider" -LookupDomain "iadb.isipp.com" -AnyMatch $true
Add-IPAllowListProvider -Name "Bondedsender IP Allow List Provider" -LookupDomain "query.bondedsender.org" -AnyMatch $true
Add-IPAllowListProvider -Name "Habeas IP Allow List Provider" -LookupDomain "hul.habeas.com" -AnyMatch $true

 

Con esto se configurara todos los proveedores gratuitos

Como importar los pre requisitos para cada rol de Exchange

 

 

Antes de Instalar Exchange debemos importar los prerrequisitos del sistema operativa para cada rol tenemos unas caracteristicas que necesitas.

Lo Primero que debemos hacer es Abrir el PowerShell en modo Administrador, y los siguientes comando dependiendo del rol que necesitemos instalar.

 

 

 

Client Access

Import-Module ServerManager


Add-WindowsFeature NET-Framework,RSAT-ADDS,Web-Server,Web-Basic-Auth,Web-Windows-Auth,Web-Metabase,Web-Net-Ext,Web-Lgcy-Mgmt-Console,WAS-Process-Model,RSAT-Web-Server,Web-ISAPI-Ext,Web-Digest-Auth,Web-Dyn-Compression,NET-HTTP-Activation,Web-Asp-Net,Web-Client-Auth,Web-Dir-Browsing,Web-Http-Errors,Web-Http-Logging,Web-Http-Redirect,Web-Http-Tracing,Web-ISAPI-Filter,Web-Request-Monitor,Web-Static-Content,Web-WMI,RPC-Over-HTTP-Proxy -Restart

HUB Transport

Import-Module ServerManager

Add-WindowsFeature NET-Framework,RSAT-ADDS,Web-Server,Web-Basic-Auth,Web-Windows-Auth,Web-Metabase,Web-Net-Ext,Web-Lgcy-Mgmt-Console,WAS-Process-Model,RSAT-Web-Server -Restart

Mail Box

Import-Module ServerManager

Add-WindowsFeature NET-Framework,RSAT-ADDS,Web-Server,Web-Basic-Auth,Web-Windows-Auth,Web-Metabase,Web-Net-Ext,Web-Lgcy-Mgmt-Console,WAS-Process-Model,RSAT-Web-Server -Restart

Unified Messaging

Import-Module ServerManager

Add-WindowsFeature NET-Framework,RSAT-ADDS,Web-Server,Web-Basic-Auth,Web-Windows-Auth,Web-Metabase,Web-Net-Ext,Web-Lgcy-Mgmt-Console,WAS-Process-Model,RSAT-Web-Server,Desktop-Experience -Restart

Edge Transport

Import-Module ServerManager

Add-WindowsFeature NET-Framework,RSAT-ADDS,ADLDS -Restart

A continuación  Roles Combinados.


Client Access, Hub Transport, and Mailbox

Import-Module ServerManager

Add-WindowsFeature NET-Framework,RSAT-ADDS,Web-Server,Web-Basic-Auth,Web-Windows-Auth,Web-Metabase,Web-Net-Ext,Web-Lgcy-Mgmt-Console,WAS-Process-Model,RSAT-Web-Server,Web-ISAPI-Ext,Web-Digest-Auth,Web-Dyn-Compression,NET-HTTP-Activation,Web-Asp-Net,Web-Client-Auth,Web-Dir-Browsing,Web-Http-Errors,Web-Http-Logging,Web-Http-Redirect,Web-Http-Tracing,Web-ISAPI-Filter,Web-Request-Monitor,Web-Static-Content,Web-WMI,RPC-Over-HTTP-Proxy -Restart

Client Access, Hub Transport, Mailbox, and Unified Messaging

Import-Module ServerManager

Add-WindowsFeature NET-Framework,RSAT-ADDS,Web-Server,Web-Basic-Auth,Web-Windows-Auth,Web-Metabase,Web-Net-Ext,Web-Lgcy-Mgmt-Console,WAS-Process-Model,RSAT-Web-Server,Web-ISAPI-Ext,Web-Digest-Auth,Web-Dyn-Compression,NET-HTTP-Activation,Web-Asp-Net,Web-Client-Auth,Web-Dir-Browsing,Web-Http-Errors,Web-Http-Logging,Web-Http-Redirect,Web-Http-Tracing,Web-ISAPI-Filter,Web-Request-Monitor,Web-Static-Content,Web-WMI,RPC-Over-HTTP-Proxy,Desktop-Experience -Restart

Client Access and Hub Transport

Import-Module ServerManager


Add-WindowsFeature NET-Framework,RSAT-ADDS,Web-Server,Web-Basic-Auth,Web-Windows-Auth,Web-Metabase,Web-Net-Ext,Web-Lgcy-Mgmt-Console,WAS-Process-Model,RSAT-Web-Server,Web-ISAPI-Ext,Web-Digest-Auth,Web-Dyn-Compression,NET-HTTP-Activation,Web-Asp-Net,Web-Client-Auth,Web-Dir-Browsing,Web-Http-Errors,Web-Http-Logging,Web-Http-Redirect,Web-Http-Tracing,Web-ISAPI-Filter,Web-Request-Monitor,Web-Static-Content,Web-WMI,RPC-Over-HTTP-Proxy -Restart

Con esto automáticamente instalaremos los prerrequisitos y se reiniciara el servidor de ser necesario.

Cambiar el valor por defecto de la Cookies de OWA, Privado y Publica

los valores por defecto de estas cookies son las siguientes:

  • Publica 5 minutos.
  • Privada 15 Minutos.

si queremos cambiar estos valores solo tentremos que ir al cas correspondiente y seleccionar el editor de registro con la siguiente ruta.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchange OWA

y dentro de esta ruta tendremos dos llaves

  • PublicTimeout
  • PrivateTimeout

No te preocupes si no existen, ya que si tienes los valores por defecto es posible que no existan, para ello solo tendrás que crearlas son de Tipo DWORD, y el valor siempre lo debemos poner en minutos.