Sugerir traducción
Otros han sugerido:

progress indicator
No hay más sugerencias.
TechNet Magazine > Inicio > Todos los números > 2009 > TechNet Magazine Mayo 2009 >  Preguntas y respuestas sobre Exchange: recupera...
Ver contenido:  en paraleloVer contenido: en paralelo
La información aquí ofrecida es contenido traducido automáticamente que los miembros de la comunidad pueden editar. Quienes deseen contribuir a mejorar la traducción, pueden hacer clic en el vínculo “editar” asociado a cualquiera de los siguientes enunciados.
Exchange Queue & A Recovering a Clustered Mailbox Server, Offline Address Book Issues, and More
Henrik Walther

QOur messaging infrastructure is based on Exchange 2007 SP1. All Exchange 2007 SP1 servers have been installed on Windows Server 2008. We have two datacenters—the primary datacenter and a backup where we can failover should a disaster strike the primary. In our primary datacenter, all Mailbox servers are based on cluster continuous replication (CCR) in order to provide a local high availability solution. For Mailbox server failovers from the primary datacenter to the backup datacenter, we use standby continuous replication (SCR). This means all the CCR-based clustered Mailbox servers (CMSs) in the primary datacenters also act as SCR sources. Each SCR source has corresponding SCR targets in the backup datacenter in the form of standby clusters on which only the passive Mailbox server role has been installed
Recently we did a site failover test between the two datacenters and, unfortunately, we ran into an issue when we tried to recover the CMSs to the standby clusters. When running with the /RecoverCMS switch, we got the error message shown in Figure 1.
Figure 1 Setup error when recovering CMS to a standby cluster
I was wondering if you have seen this error while recovering a CMS to a standby cluster and, more importantly, whether you have a resolution for it.
AYes, I had the misfortune of encountering this issue while trying to recover a CMS to a standby cluster. Luckily, this was also during a site level failover test. (Do I need to explain why testing your failover solutions is important?)
One thing that got me thinking was that I had tested the same setup many times before without issues. However, all the previous recovery tests were with Exchange 2007 SP1 installed on Windows Server 2003 and not Windows Server 2008 as was the case when I hit this issue.
This led me to discover how Windows Server 2008 failover clusters work compared to Windows Server 2003-based clusters. In Windows Server 2003, you created and dedicated a cluster service account to the cluster. In Windows Server 2008, you no longer do this; instead, the failover cluster runs under the "Local System." After examining the application and system logs on the standby cluster on which I tried to recover the CMS, I found the error shown in Figure 2.
Figure 2 Recovery error due to inadequate permissions
This event id error explains that the Windows Failover cluster doesn't have the permissions necessary to update the CMS computer account in Active Directory. It also lists three possible reasons. Since we're recovering an existing CMS on a standby cluster, we can ignore the first one. Since we haven't reached any quotas for the number of computer objects, we can ignore number two as well. The last item, however, is quite interesting. It tells us to verify that the Windows Failover cluster on which we recover the CMS has "Full Control" permissions to the CMS computer account object.
A look under the Security tab on the property page of the CMS computer object in the Active Directory Users and Computers reveals that the standby cluster does not have "Full Control" permissions (Figure 3).
Figure 3 The standby cluster does not have “Full Control” permissions
Adding the standby cluster with "Full Control" permissions to the CMS computer object resolved the issue for me and it should do the same in your environment.
At the time of this writing (the end of February), there's no information about this issue at public places like TechNet or in any KnowledgeBase articles. However, my good friend Tim McMichael from Microsoft Customer Support Services has written a blog post on this topic that goes into far more detail than I'm able to do here. So please go check out Tim's blog for more information (" Permissions recommended for the CNO (Cluster Name Object) in Windows 2008 for Exchange 2007 SP1 setup operations. ").
QWe're currently in the process of crafting a site-level failover solution. For our Exchange 2007 SP1-based messaging infrastructure, we're going to use standby continuous replication (SCR) as the disaster recovery solution between our primary and backup datacenter. Since only some of our end-users have been upgraded to Office Outlook 2007 with the rest still on Outlook 2003, we've got a question. When a failover of the Exchange 2007 SP1 servers occurs from the primary datacenter to the backup datacenter, will both Outlook versions simply pickup the changes after performing the required SCR site failover steps?
AVery good question and, actually, the answer depends on whether you're using RecoverCMS or Database portability to failover your mailbox servers to the backup datacenter. If you have standalone Mailbox servers in the primary datacenter and replicate these to standalone Mailbox servers in the backup datacenter using SCR, then you would use database portability in order to failover the Mailbo x databases. If you have single copy cluster (SCC) or CCR Mailbox servers in your primary backup datacenter and standby clusters in your backup datacenter, you would use the RecoverCMS switch to recover the whole CMS to the backup datacenter. When using RecoverCMS as the failover mechanism, you typically don't need to worry about Outlook client connectivity after the failover. Do bear in mind that the IP address of the CMS will change. But if you have configured the DNS Time to Live (TTL) value to five minutes according to best practice recommendations, note that there will be a slight delay before the Outlook clients will be able to reconnect to the CMS.
If you're using database portability as the recovery mechanism, the situation is a bit different, depending on the Outlook client version. Outlook 2007 clients will reflect the changes automatically via the Autodiscover service that runs on the Client Access servers. This means you don't have to do any manual changes for this Outlook version. However, that's not necessarily the case with Outlook 2003 clients. When a mailbox has been recovered on another server, the name of the server storing the Mailbox database(s) will obviously be different.
You might wonder, does this matter when you use the Move-Mailbox cmdlet with the –ConfigurationOnly switch after the failover? Yes, it still matters because Outlook 2003 doesn't support the Autodiscover service. This means that the original server where the Mailboxes were stored before the failover must be online so that the server name in the Outlook MAPI profile can be updated. If the original server is offline, the server name can't be updated automatically.
So, if you're facing a disaster where all servers in your primary datacenter are offline, you must reconfigure the Outlook 2003 MAPI profiles using a tool such as the Microsoft Exchange Server Profile Redirector (ExProfre) in combination with a login script to reflect the changes. It's worth noting that if all your clients were located in the primary datacenter, you would need to rebuild them anyway.
QIn our Exchange 2007 SP1-based messaging infrastructure, all our Mailbox servers are cluster continuous replication (CCR)-enabled. We have installed four network interface cards (NICs) in each cluster node. Two NICs have been teamed and are connected to the public network, which accepts Outlook client requests and so forth. The third NIC is used for the heartbeat network between the two cluster nodes in the CCR. The fourth NIC is there specifically for log shipping purposes. Using the Enable-ContinuousReplicationHostName cmdlet introduced in Exchange 2007 SP1, we have (in order to achieve log shipping redundancy) specified that both the heartbeat and the dedicated log shipping network can be used to ship logfiles from the active to the passive node. This works great and really reduces the traffic on the public network, especially in situations where a reseed of one or more Mailbox databases are required (though this should be pretty rare).
We also have SCR enabled between these CCR-based Mailbox servers and multiple SCR targets in our backup datacenter. This leads to our question. Is it possible to use the Enable-ContinuousReplicationHostName cmdlet with SCR?
AI'm glad that the EnableContinuousReplicationName cmdlet has been helpful to you. However, since this cmdlet was specifically created for CCR solutions, the answer to your question is, unfortunately, no, currently this is not supported in an SCR solution.
QWe have just transitioned from Exchange 2003 to Exchange 2007 SP1. All Exchange 2007 SP1 server roles are running on Window Server 2008 and our Exchange 2007 Mailbox servers are based on CCR.
Things work very well so far but we have observed an issue with the Offline Address Book (OAB). When it's updated with new mail objects, the updates aren't reflected in Outlook 2007 at the end users. We have been troubleshooting the issue and have found Event ID 1021 in the Application log on the Client Access Servers with the following description:
Process MSExchangeFDS.exe (PID=xxxx). Could not find directory <OAB share location> 
This is normal if the directory has never been generated. Otherwise, make sure this directory
and share has read permission for the "Exchange Servers" group.
We have tried to copy the OAB manually from the CCR-based Mailbox server where it is hosted to the Client Access Server. This results in updates in Outlook, but we would like to get the issue fixed permanently. Do you have the recipe?
AI've been down that road, too. The reason for this problem is because of the way Windows 2008 Failover Clusters behave. Windows 2008 Failover Clusters introduces a new concept called shared scoping. Basically, shared scoping means that a file share is specific to either the node name or to one of the cluster name objects that the share hosts. When a share is shared by the node name, it cannot be accessed by the Clustered Mailbox Server (CMS) name. For more geeky details about file share scoping, see this post on the Ask the Core Team blog (" File Share 'Scoping' in Windows Server 2008 Failover Clusters ").
To resolve the issue, you need to install Exchange 2007 SP1 Rollup Update 5 or later, which includes the required bug fix. Also see the article " Exchange 2007 CAS cannot copy the OAB from the OAB share on Windows Server 2008-based Exchange 2007 CCR clusters ." Because this Rollup Update brings some regressions with it, it's important you read the Rollup Update 5 KB article closely before using this solution.

Henrik Walther is a Microsoft Certified Master: Exchange 2007 and Exchange MVP with more than 15 years of experience in the IT business. He works as a Technology Architect for Trifork Infrastructure Consulting (a Microsoft Gold partner based in Denmark) and as a Technical writer for Biblioso Corporation (a US based company that specializes in managed documentation and localization services).

Exchange Queue & A Recuperar un servidor de buzones en clústeres, problemas de libreta de direcciones sin conexión y mucho más
Henrik Walther

QNuestra infraestructura de mensajería se basa en Exchange 2007 SP1. Todos los servidores de Exchange 2007 Service Pack 1 se han instalado en Windows Server 2008. Contamos con dos centros de datos, los centros de datos principal y una copia de seguridad que podemos conmutación por error un desastre debe alcanzar el principal. En nuestro centro de datos principal, todos los servidores de buzón se basan en replicación continua de clúster (CCR) para ofrecer una solución de alta disponibilidad local. Para conmutaciones por buzón servidor error de los centros de datos principal a los centros de datos copia de seguridad, utilizamos la replicación continua suspensión (SCR). Esto significa que todo los en función de la CCR agrupados servidores de buzones (CMSs) en los centros de datos principal también actúan como orígenes de SCR. Cada origen de SCR tiene destinos SCR correspondientes en el centro de datos copia de seguridad en forma de los clústeres de reserva en el que sólo la pasiva buzón función de servidor ha sido instalada
Recientemente hicimos una prueba de conmutación por error de sitio entre los dos centros de datos y, por desgracia, ejecutamos en un problema al intentar recuperar las CMSs a los clústeres de reserva. Cuando se ejecuta / con el /RecoverCMS conmutador, se obtuvo el mensaje de error que se muestra en Figure 1 .
Figura 1 configuración de un error al recuperar CMS a un clúster de reserva
Se pregunte si se ha visto este error al recuperar un CMS para un clúster de reserva y, lo que es más importante, si tiene una solución para él.
ASí, tuve la misfortune de encontrarse con este problema al intentar recuperar un CMS a un clúster de reserva. Afortunadamente, esto fue también durante una prueba de conmutación por error nivel de sitio. (¿Es necesario explicar por qué es importante probar sus soluciones de conmutación por error?)
Una cosa que obtuvo me pensar en era que había probado la misma configuración muchas veces antes sin problemas. Sin embargo, todas las pruebas de recuperación anteriores eran con Exchange 2007 SP1 instalado en Windows Server 2003 y no Windows Server 2008, tal como era el caso cuando presione este problema.
Me a descubrir cómo trabajo comparado con clústeres de Windows Server 2003, en función de clústeres de conmutación por error de Windows Server 2008 llevó. En Windows Server 2003, ha creado y había dedicado una cuenta de servicio de Cluster Server al clúster. En Windows Server 2008, ya no hacerlo; en su lugar, se ejecuta el clúster de conmutación por error en el "sistema local". Cuando examinar la aplicación y el sistema inicia una sesión en el clúster de reserva en el que al intentar recuperar el CMS, encontró el error que se muestra en la figura 2 .
La Figura 2 error de recuperación due to permisos inadecuados
Este error de identificador de evento explica que el clúster de conmutación por error de Windows no tiene los permisos necesarios actualizar la cuenta de equipo CMS en Active Directory. También muestra tres posibles razones. Puesto que se está recuperar un CMS existente en un clúster en espera, se puede omitir la primera uno. Puesto que hemos no ha llegado las cuotas para el número de objetos de equipo, se puede omitir así número dos. El último elemento, sin embargo, es muy interesante. Indica a nosotros para comprobar que el clúster de conmutación por error de Windows en el que se recuperar el CMS tiene permisos de "Full Control" al objeto de cuenta de equipo CMS.
Un aspecto en la ficha Seguridad en la página de propiedades del objeto de equipo CMS en los usuarios de Active Directory y equipos revela que el clúster de espera no tiene permisos de "Full Control" (Figure 3).
La figura 3 el clúster de espera no tiene permisos de “ Full Control ”
Agregar el clúster de reserva con permisos de "Full Control" al objeto de equipo CMS resolver el problema para mí y debe hacer lo mismo en su entorno.
En el momento de redactar este documento (el final de febrero), no hay ninguna información sobre este problema en lugares públicos como TechNet o en los artículos de Knowledge Base. Sin embargo, mi buen amigo Tim McMichael servicios de soporte al cliente de Microsoft de escribe una entrada de blog en este tema que se incluye en mucho más detalles que puedo hacer aquí. Por lo que se vuelva ir visite del Tim blog para obtener más información " Permisos recomendados para el CNO (objeto de nombre de clúster) en Windows 2008 para operaciones de instalación de Exchange 2007 SP1. ").
QEstamos actualmente en el proceso de elaborar una solución de conmutación por error de nivel de sitio. Para nuestra infraestructura de mensajería de Exchange 2007 SP1, en función, vamos a utilizar la replicación continua de reserva (SCR) como la solución de recuperación ante desastres entre nuestro centro de datos principal y de reserva. Puesto que sólo algunos de nuestros usuarios finales se han actualizado a Office Outlook 2007 con el resto todavía en Outlook 2003, tenemos una pregunta. ¿Cuando se produce una conmutación por error de los servidores de Exchange 2007 Service Pack 1 de los centros de datos principal en los centros de datos copia de seguridad, se ambas versiones de Outlook recogidas simplemente los cambios después de realizar los pasos de conmutación por error de sitio SCR necesarios?
AMuy buena pregunta y, en realidad, la respuesta depende si estás utilizando portabilidad RecoverCMS o base de datos para la conmutación por error los servidores de buzones para los centros de datos copia de seguridad. Si se tiene servidores de buzones independientes en los centros de datos principal y replican a servidores de buzones independientes en el centro de datos copia de seguridad mediante SCR, a continuación, utilizaría la portabilidad de base de datos para la conmutación por error el Mailbo x bases de datos. Si tiene clústeres de copia única (SCC) o servidores de buzones de CCR en los centros de datos copia de seguridad principal y espera clústeres en los centros de datos copia de seguridad, podría utilizar el modificador RecoverCMS para recuperar el CMS completo a los centros de datos copia de seguridad. Cuando se utiliza RecoverCMS como mecanismo de conmutación por error, normalmente no es necesario que preocuparse de conectividad de clientes de Outlook después de la conmutación por error. Tenga en cuenta que cambie la dirección IP del CMS. Pero si ha configurado el período de DNS valor Live (TTL) a cinco minutos según a recomendaciones de prácticas recomendadas, tenga en cuenta que habrá un retraso ligero antes de que los clientes de Outlook podrá volver a conectar con el CMS.
Si estás utilizando portabilidad de la base de datos como el mecanismo de recuperación, la situación es un poco diferente, dependiendo de la versión de cliente de Outlook. Los clientes de Outlook 2007 reflejará los cambios automáticamente mediante el servicio de detección automática que se ejecuta en los servidores de acceso de cliente. Esto significa que no debe hacer los cambios manuales para esta versión de Outlook. Sin embargo, no es necesariamente el caso con los clientes de Outlook 2003. Cuando se ha recuperado un buzón de otro servidor, el nombre del servidor almacena las bases de datos buzón Obviamente será diferente.
¿Es posible que pregunte, esta cuestión cuando se usa el cmdlet Move-Mailbox con el –ConfigurationOnly cambiar después de la conmutación por error? Sí, sigue importa debido a que Outlook 2003 no admite el servicio de detección automática. Esto significa que el servidor original en los buzones se almacenaron antes de que la conmutación por error debe ser en línea para que se puede actualizar el nombre del servidor en el perfil de MAPI de Outlook. Si el servidor original está sin conexión, el nombre del servidor no se actualizarán automáticamente.
Por lo tanto, si se está enfrentan un desastre donde se sin conexión todos los servidores en los centros de datos principal, deberá volver a configurar los perfiles de MAPI de Outlook 2003 con una herramienta como el redirector de perfil (ExProfre) de Microsoft Exchange Server en combinación con un script de inicio de sesión para reflejar los cambios. Merece la pena tener en cuenta que si todos los clientes se encuentran en los centros de datos principal, deberá reconstruirlos de todos modos.
QEn nuestra infraestructura de mensajería de Exchange 2007 SP1, en función, todos nuestros servidores de buzones son la replicación continua de clúster (CCR) - habilitado. Hemos instalado cuatro tarjetas de interfaz de red (NIC) en cada nodo del clúster. Dos NIC han se ha asociado y están conectadas a la red pública, que acepta las solicitudes de cliente de Outlook y así sucesivamente. La tercera tarjeta de interfaz de red se utiliza para la red de latido entre los nodos de clúster de dos de la CCR. La cuarta tarjeta NIC es hay específicamente para propósitos de trasvase de registros. Mediante el cmdlet Enable-ContinuousReplicationHostName que se introdujo en Exchange 2007 SP1, nos tener (para lograr la redundancia de envío de registro) especifica que se pueden utilizar tanto el latido y la red de envío de registro dedicado para enviar los archivos de registro de activo en el nodo pasivo. Este funciona realmente y gran reduce el tráfico en la red pública, especialmente en situaciones donde una reinicialización de uno o más buzones bases de datos son necesarios (aunque debería ser muy raro).
También tenemos SCR habilitada entre estos servidores de buzones en función de la CCR y varios destinos SCR en nuestro centro de datos copia de seguridad. Esto conduce a nuestro pregunta. ¿Es posible usar el cmdlet Enable-ContinuousReplicationHostName con SCR?
AEstoy congratula que ha sido útil para el cmdlet EnableContinuousReplicationName. Sin embargo, desde este cmdlet se creó específicamente para las soluciones CCR, la respuesta a su pregunta es, desafortunadamente, no, actualmente que esto no se admite en una solución SCR.
QSólo se dispone de transición de Exchange 2003 a Exchange 2007 SP1. Funciones de servidor Exchange 2007 SP1 todas se ejecutan en Windows Server 2008 y nuestros servidores de buzones de Exchange 2007 se basan en CCR.
Las cosas funcionan muy bien hasta ahora pero se ha observado un problema con el sin conexión direcciones Libreta (OAB). Cuando se se actualiza con nuevos objetos de correo, las actualizaciones no se reflejan en Outlook 2007 a los usuarios finales. Se ha se solucionar el problema y ha encuentra 1021 de ID. de evento en el registro de aplicación en los servidores de acceso de cliente con la siguiente descripción:
Process MSExchangeFDS.exe (PID=xxxx). Could not find directory <OAB share location> 
This is normal if the directory has never been generated. Otherwise, make sure this directory
and share has read permission for the "Exchange Servers" group.
Hemos tratado de copiar la libreta de direcciones sin conexión manualmente desde el servidor en función de la CCR buzón donde está hospedado en el servidor de acceso de cliente. Esto da como resultado las actualizaciones en Outlook, pero nos gustaría obtener el problema fijo de forma permanente. ¿Tiene la receta?
AHe hacia abajo que carretera, demasiado. El motivo de este problema es debido el comportamiento de los clústeres de conmutación por error de Windows 2008. Clústeres de conmutación por error de Windows 2008 presenta un nuevo concepto denominado ámbito compartido. Básicamente, significa ámbito compartido que un recurso compartido de archivos es específico a ser el nombre de un nodo o a una del clúster de nombre objetos que de los hosts de recurso compartido. Cuando un recurso compartido se comparte con el nombre de nodo, no se puede tener acceso al nombre de servidor de buzones de clústeres (CMS). Para obtener información más geeky detallada sobre el ámbito de recurso compartido de archivo, vea esta entrada en la consultar el blog del equipo principal " Archivo de recurso compartido 'Ámbito' en clústeres de Windows Server 2008 la conmutación por error ").
Para resolver el problema, deberá instalar Exchange 2007 Service Pack 1 informe de actualización de 5 o posterior, que incluye la corrección de errores necesaria. Vea también el artículo" CAS de Exchange 2007 no puede copiar la libreta de direcciones sin conexión desde el recurso compartido Libreta de direcciones sin conexión en clústeres de Windows Server 2008-basado Exchange 2007 CCR ." Dado que esta actualización informe aporta algunas regresiones con ella, es importante que lea el artículo informe de actualización de 5 KB estrechamente antes de utilizar esta solución.

Henrik Walther es un principal de certificado de Microsoft: Exchange 2007 y MVP de Exchange con más de 15 años de experiencia en el negocio de TI. Trabaja como un arquitecto de tecnología de Trifork infraestructura Consulting (un socio de oro de Microsoft en Dinamarca) y como un escritor técnico para Biblioso Corporation (una compañía de estados UNIDOS en función que está especializada en servicios de documentación y localización administrados).

Page view tracker