Exchange Queue &A: En los DAG
El uso de grupos de la disponibilidad de base de datos es una buena idea, sobre todo porque se puede copiar y almacenarlos en varias ubicaciones, pero le importa los problemas de asignación de direcciones.
Henrik Walther
Direccionamiento acertijo
P: Hemos implementado Exchange 2010 y todos los servidores de buzón altamente disponible con la base de datos de disponibilidad de grupos (DAGs). Cosas que se encuentran en buen y todo lo que funciona correctamente, excepto un detalle sin importancia.
Cuando una persona que recibe un mensaje enviado por un empleado con un buzón alojado en un d AG, a su vez envía otro mensaje a un empleado o a un destinatario de otra organización, el encabezado del mensaje de Internet de la muestra en el mensaje recibido que se ha configurado el servidor de buzón con una dirección APIPA como 169.254.5.133. Utilizamos las direcciones IP estáticas para todos nuestros servidores de Exchange 2010, por lo que no sabemos por qué muestra como una dirección APIPA (consulte de figura 1). ¿Puede profundización nosotros?
A: Se trata de una pregunta interesante. La respuesta muy resumida es que sólo ocurre cuando se han realizado alta disponibilidad mediante DAGs uno o varios servidores de buzones de Exchange 2010, y la funcionalidad de d AG se basa en el componente de clúster de conmutación por error de Windows (WFC). No ve este comportamiento con servidores de buzones que no forman parte de un d AG.
Let’s Veamos con más detalle lo que sucede aquí. El componente WFC en Windows Server 2008 R2 espera que las aplicaciones que utilizan WFC: por ejemplo, SQL, Exchange y servidores de archivos, para localizar los recursos de clúster en un modo específico. La aplicación debe conectarse a un recurso de clúster al encontrar la información correcta que se utiliza un servidor DNS.
Esto se conoce como un punto de acceso de cliente (CAP). Un CAP consta de un nombre NetBIOS y uno o más recursos de dirección IP. En Windows Server 2008 R2, si el servidor la admite actualizaciones dinámicas, la información de CAP se registra en DNS una vez que el CAP se pone en conexión en el WFC.
Desafortunadamente, hay aplicaciones que se omita el paso DNS y en su lugar se conectan directamente a un nodo de clúster con el primer adaptador de red en la lista de enlaces. De forma predeterminada, el primer adaptador de red enumerado en la lista de enlace es el adaptador de virtual de clúster de conmutación por error de Microsoft (vea de figura 2). Este adaptador está configurado con una dirección APIPA.
.png)
Figura 1 de APIPA una dirección en un encabezado de Internet
.png)
La figura 2 de La conmutación por error de Microsoft Cluster Server adaptador virtual
¿Por lo tanto, adivine qué aplicación no utiliza DNS para localizar y conectar un recurso de clúster? Adivinarlo: Exchange 2010 (y en Exchange 2007, también).
¿Podemos cómo se resuelve esta pequeña molestia? Por suerte, esto es fácil con la Ayuda de una pequeña herramienta conocida como nvspbind, que puede descargar desde MSDN Code Gallery: Code.msdn.Microsoft.com/nvspbind. Nvspbind se desarrolló específicamente para la modificación de los enlaces de red desde una línea de comandos.
Let’s, compruebe el orden de enlace de los adaptadores en el servidor. Ejecute nvspbind.exe /o ms_tcpip. Como puede ver en de figura 3, Local Area Connection * 9 (que es igual al adaptador de virtual de clúster de conmutación por error de Microsoft) se enumera en primer lugar.
.png)
La figura 3 de ver una lista de orden de enlace mediante nvspbind
A continuación, necesitamos Local Area Connection * 9 se desplazan hacia abajo de la lista. Ejecute el comando siguiente:
nvspbind.exe /- “Local Area Connection* 9” ms_tcpip
.png)
La figura 4 del movimiento Local Area Connection * 9 por la lista de orden de enlace
Como puede ver en de figura 4, Local Area Connection * 9 se ha movido hacia abajo de la lista de orden de enlace. Ahora intente enviar un correo electrónico nuevo. El encabezado de Internet debe mostrar la dirección IP real del servidor (consulte de figura 5).
.png)
La figura 5 del encabezado de una Internet que muestra la dirección IP real del servidor de buzón
Copias de manuales
P: Se acaba de implementar servidores de Exchange 2010. Pretendemos utilizar DAGs realizar nuestras bases de datos de buzón de alta disponibilidad. Nos estamos planear ocho copias de cada base de datos de buzones. Cada base de datos de buzones tendrá copias en tres ubicaciones físicas. Vamos a las bases de datos de aproximadamente 500 GB. Debido a de ancho de banda limitado a una de las ubicaciones físicas, se espera que una inicialización mucho tiempo. ¿Por lo tanto, en lugar de ello, nos estamos preguntando si nos podemos algún modo copiar manualmente los archivos de base de datos a una ubicación remota con una unidad USB?
A: Sí, puede hacer esta forma, al igual que con un método admitido. Para copiar manualmente una base de datos sin conexión, deshabilitar el registro circular para las bases de datos respectivos. Para ello, se está ejecutando:
Set-MailboxDatabaseMDB01 -CircularLoggingEnabled $false
A continuación, desmontar las bases de datos mediante:
Dismount-Database MDB01 -Confirm $false
A continuación, copie la base de datos y todos los archivos de registro en una segunda ubicación, por ejemplo, una unidad USB.
Cuando finalice el proceso de copia, monte de nuevo con la copia de base de datos activa:
Mount-Database MDB01
Ahora puede conectar el disco USB para el servidor que alojará la base de datos y copie los archivos de base de datos y registro en la misma ruta de acceso que el utilizado en el servidor de origen desde el que se han copiado los archivos.
A continuación, agregue la copia de la base de datos mediante el agregar-MailboxDatabaseCopy - parámetro SeedingPostponed. El comando exacto sería similar al siguiente:
Add-MailboxDatabaseCopy -Identity MDB01 -MailboxServer E2K10EX04–SeedingPostponed
Observe que no hay ningún proceso de transferencia porque el archivo EDB y archivos de registro asociados ya están en su lugar. Por último, habilitar nuevamente con el registro circular:
Set-MailboxDatabaseMDB01 -CircularLoggingEnabled $true
Carretera guerreros
P: Estamos trabajando Exchange 2010 y tenemos muchas “ carretera negocios ” que son altamente dependientes de la aplicación Web de Outlook o OWA (lo que se utiliza para que se llama a Outlook Web Access). Estos usuarios no pueden iniciar sesión en OWA cuando su contraseña ha caducado. También hemos encontrado que los nuevos empleados para el que se ha establecido la cuenta a “ el usuario debe cambiar la contraseña en el siguiente inicio de sesión ” cuando la cuenta de usuario se crea por primera vez (consulte de figura 6), no puede iniciar sesión en OWA, antes de que cambien la contraseña mediante otros mecanismos.
.png)
La figura 6 de usuario debe cambiar la contraseña en el siguiente inicio de sesión habilitado
Nos hemos ha viven con esta serie de molestias desde que se mueve desde Lotus Domino a Exchange 2003 hace muchos años. ¿Sabe cómo nos podemos corregir esto?
A: Buen momento para esta pregunta. Cuando el equipo de Exchange comenzaron a planear el Service Pack 3 de Exchange 2007, así como Service Pack 1 de Exchange 2010, decidieron solucionar la falta de capacidad de iniciar una sesión en OWA cuando ha caducado la contraseña de un usuario o la cuenta de usuario se ha establecido para el usuario debe cambiar la contraseña en el siguiente inicio de sesión. Presentó la herramienta de restablecimiento de contraseña de OWA. Se trata de un módulo de IIS 7 que detecta las contraseñas caducadas y redirecciona a los usuarios a una página de la contraseña de cambio totalmente nuevo.
.png)
La figura 7 de página de inicio de sesión autenticación basada en formularios de 2010 de la aplicación de Outlook Web
¿Let’s ver esto en acción, deberá nos? El usuario intenta iniciar sesión en OWA 2007 o 2010 utilizando la página de inicio de sesión autenticación basada en formularios (FBA), tal como se muestra en de figura 7. Ahora se redirige al usuario a la página Cambiar la contraseña nueva, que se muestra en de figura 8. En este caso, será necesario escribir la contraseña actual, así como una nueva y, a continuación, haga clic en el botón Enviar.
.png)
La figura 8 de la página de The Outlook Web App 2010 cambiar contraseña
A continuación, se cambia la contraseña y el usuario puede iniciar sesión con la nueva contraseña. Sencillo y fácil de usar, ¿verdad?
Tenga en cuenta que la página Cambiar la contraseña no está habilitada de forma predeterminada después de instalar Exchange 2007 Service Pack 3 o Service Pack 1 de Exchange 2010. Debe habilitar esta opción con una clave del registro. En concreto, debe iniciar sesión en cada servidor de acceso de cliente (CAS) de Exchange 2007 o Exchange 2010 y ejecutar el editor del registro.
En el editor del registro, desplácese hasta: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\MSExchange OWA. En este caso, debe crear una nueva clave REG_DWORD llamada ChangeExpiredPasswordEnabled. Activar esta opción, establezca el valor de datos “ 1 ”, tal como se muestra en de figura 9.
.png)
La figura 9 de la clave del registro que permiten cambiar la contraseña de OWA
Ahora sus negocios de viaje pueden iniciar sesión en OWA, independientemente de si su contraseña ha caducado o debe cambiarse.
_***Henrik Walther****es un principal de Microsoft Certified: Exchange 2007 y MVP de Exchange con más de 15 años de experiencia en el sector de TI. Trabaja como un arquitecto de tecnología forTimengoConsulting (un Microsoft Gold Certified Partner en Dinamarca) y como escritor técnico para Biblioso Corp.(los servicios de documentación y localización administrados una empresa estadounidense especializada en). Para enviar por correo electrónico Walther en v-henwal@microsoft.com de . * _