Exportar (0) Imprimir
Expandir todo

Notas de la versión de Exchange 2013

 

Se aplica a: Exchange Server 2013

Última modificación del tema: 2014-06-12

Bienvenido a Microsoft Exchange Server 2013! Este tema contiene información importante que debe conocer para implementar correctamente la Actualización acumulativa 5 de Exchange 2013. Lea todo este tema antes de comenzar su implementación.

En este tema se presentan las siguientes secciones:

  • La instalación solicita incorrectamente .NET Framework 4.0   Si intenta instalar Exchange 2013 sin tener .NET Framework instalado en el equipo, el programa de instalación solicita erróneamente que instale .NET Framework 4.0 cuando lo necesario es instalar .NET Framework 4.5.

    Para solucionar este problema, instale .NET Framework 4.5. No es necesario instalar .NET Framework 4.0. Para obtener una lista completa de requisitos previos, consulte Requisitos previos de Exchange 2013.

  • Los archivos de configuración de la aplicación XML de Exchange se sobrescriben durante la instalación de la actualización acumulativa   Las configuraciones personalizadas referentes al servidor que haga en los archivos de configuración de la aplicación XML de Exchange, por ejemplo, los archivos web.config de los servidores de acceso de cliente o el archivo EdgeTransport.exe.config de los servidores de buzones, se sobrescribirán cuando instale una actualización acumulativa de Exchange o un Service Pack. Asegúrese de guardar esta información para que pueda volver a configurar fácilmente su servidor tras la instalación. Debe reconfigurar estas opciones después de instalar una actualización acumulativa de Exchange o un Service Pack.

  • El directorio virtual de MAPI no se crea durante la recuperación del servidor   Cuando se ejecuta Setup.exe con el modificador RecoverServer en un servidor que tiene instalado el rol de servidor Acceso de cliente, el directorio virtual de MAPI no se crea. Si el directorio virtual de MAPI no existe, los clientes que usan el protocolo MAPI sobre HTTP para conectarse al servidor de Exchange, como Outlook, no podrán conectarse.

    NotaNOTA:
    Esto supone un problema únicamente si el protocolo MAPI sobre HTTP está habilitado en los servidores de acceso de cliente. Está deshabilitado de forma predeterminada. Si MAPI sobre HTTP está deshabilitado, los clientes usan en su lugar el protocolo RPC sobre HTTP.

    Para solucionar este problema, siga los pasos que se describen en el artículo de Knowledge Base KB2931223 (Falta el directorio virtual de MAPI desde el nodo sitio Web predeterminado).

Para obtener más información acerca de cómo instalar Exchange 2013, consulte Planificación e implementación.

  • Incremento del tamaño del buzón de correo al migrar de versiones anteriores de Exchange   Cuando mueve un buzón de correo de una versión anterior de Exchange a Exchange 2013, el tamaño del buzón de correo notificado, puede incrementar de un 30 a un 40 por ciento. El espacio de disco que usa la base de datos de buzón no se ha incrementado, sólo ha aumentado la atribución del espacio que usa cada buzón de correo. El incremento en el tamaño del buzón de correo es debido a la inclusión de todas las propiedades de los elementos en los cálculos de la cuota, que proporciona un cómputo más preciso del espacio que usan los elementos dentro de su buzón de correo. Este incremento puede provocar que algunos usuarios excedan sus cuotas de tamaño de buzón de correo cuando éste se mueve a Exchange 2013.

    Para evitar que los usuarios excedan sus cuotas de tamaño de buzón de correo, incremente los valores de la base de datos o de las cuotas del buzón de correo para acomodar el cálculo de la nueva cuota. Para configurar los valores de la base de datos o de la cuota del buzón de correo, use los parámetros IssueWarningQuota, ProhibitSendQuota y ProhibitSendReceiveQuota en los cmdlets Set-MailboxDatabase y Set-Mailbox, respectivamente.

  • Puede que los clientes de Outlook 2007 y Outlook 2010 no puedan bajar la Libreta de direcciones sin conexión   Si no se puede acceder a la dirección URL interna de la Libreta de direcciones sin conexión (OAB) desde Internet, los clientes de Outlook 2007 y Outlook 2010 no podrán bajar la OAB.

    Para solucionar este problema con los clientes de Outlook 2007 y Outlook 2010, haga que la dirección URL interna de la OAB sea accesible desde Internet. Outlook 2013 no se ve afectado por este problema.

  • Instalar Exchange 2013 en una organización de Exchange existente puede hacer que todos los clientes se bajen la OAB   Al instalar el primer servidor de Exchange 2013 en una organización existente de Exchange 2007 o de Exchange 2010, es posible que todos los clientes de la organización se bajen una nueva copia de la OAB, lo que hará que la red se sature y haya problemas de rendimiento del servidor. Este problema se produce porque Exchange 2013 crea una nueva OAB predeterminada en la organización que sustituye a la OAB de Exchange 2007 o de Exchange 2010. Los buzones que no tengan una OAB concreta asignada o que se encuentren en una base de datos de buzones de correo sin una OAB concreta asignada se bajarán la nueva OAB predeterminada.

    Para evitar que los clientes se bajen una nueva copia de la OAB cuando se instala Exchange 2013, asigne una OAB a cada buzón o a la base de datos de buzones de correo donde se encuentran los buzones. Deberá realizar este paso antes de instalar Exchange 2013 en la organización.

  • Los usuarios pueden enrutarse a un buzón de generación de OAB que no sea responsable de la OAB solicitada   Exchange 2013 CU5 modifica la forma en la que se vinculan las OAB con los buzones de generación de OAB. Este cambio permite enrutar un usuario a un buzón de generación de OAB que no es responsable de la OAB que el usuario está solicitando. Esto puede pasar si se cumplen todas las condiciones siguientes:

    • Cuenta con más de un buzón de generación de OAB en su organización.

    • Actualiza los servidores de buzones de correo que hospedan los buzones de generación de OAB antes de actualizar los servidores de acceso de cliente.

    • Está actualizando los servidores de Exchange 2013 de una versión anterior a CU5 a CU5 o una versión posterior (por ejemplo, está actualizando de Exchange 2013 CU3 a Exchange 2013 CU5).

    • Los servidores de acceso de cliente están ejecutando una versión anterior a CU5.

    Para solucionar este problema, asegúrese de actualizar los servidores de acceso de cliente a Exchange 2013 CU5 antes de actualizar los servidores de buzones de correo. De este modo se asegurará de que los servidores de acceso de cliente sepan cómo usar un proxy para las solicitudes del buzón de generación de OAB que es responsable de generar la OAB del usuario.

    Para más información sobre los cambios de OAB en Exchange 2013 CU5, vea las mejoras de OAB en la actualización acumulativa 5 de Exchange 2013.

  • Los remitentes no autorizados pueden enviar mensajes a carpetas públicas   Las carpetas públicas ubicadas en servidores que ejecutan Exchange 2013 SP1 o posterior aceptan mensajes de remitentes externos a la organización de Exchange, independientemente de la configuración de la carpeta pública. Este problema podría permitir que las carpetas públicas reciban correo no deseado y otros mensajes no deseados.

    En la actualidad no hay ninguna solución para este problema.

  • Las carpetas públicas heredadas no son accesibles mediante los servicios Web Exchange   Las carpetas públicas ubicadas en servidores de Exchange 2007 o Exchange 2010 no son accesibles para los clientes que se conectan a Exchange 2013 mediante los servicios Web Exchange (EWS). Los clientes que usan EWS son Mac Outlook y Outlook Web App. Si un cliente de EWS intenta acceder a una carpeta pública heredada, recibirán un error.

    La única solución por el momento es migrar las carpetas públicas heredadas a Exchange 2013. Sin embargo, hay algunos problemas a tener en cuenta antes de migrar las carpetas públicas. Para obtener más información, consulte Carpetas públicas.

  • Los cmdlets TransportAgent en los servidores de acceso de clientes requieren Windows PowerShell local   Existe un problema con los cmdlets *-TransportAgent que evita que dichos cmdlets instalen, desinstalen y administren agentes de transporte en los servidores de acceso de clientes usando el Shell de administración de Exchange. Para instalar, desinstalar y administrar agentes de transporte en servidores de acceso de clientes, debe cargar manualmente el complemento Exchange Windows PowerShell y, a continuación, ejecutar los cmdlets *-TransportAgent. Si intenta instalar, desinstalar o administrar agentes de transporte usando el Shell de administración de Exchange, sus cambios se aplicarán al servidor de buzones de correo de Exchange 2013 al que esté conectado.

    Para instalar, desinstalar o administrar los agentes de transporte en los servidores de acceso de clientes, haga lo siguiente en el servidor de acceso de clientes que desee administrar:

    PrecauciónPrecaución:
    La carga del complemento Microsoft.Exchange.Management.PowerShell.SnapIn Windows PowerShell y la ejecución de otros cmdlets diferentes a los cmdlets *-TransportAgent no es compatible y puede resultar en un daño irreparable a su implementación de Exchange.
    Debe ser un administrador local en el servidor de acceso de clientes donde desee instalar, desinstalar o administrar agentes de transporte. La modificación de las listas de control de acceso (ACLs) no es compatibles en los archivos de Exchange, en los directorios ni en los objetos de Active Directory.
    ImportanteImportante:
    Realice el siguiente procedimiento sólo en servidores de acceso de clientes. No es necesario que cargue el complemento de Exchange Windows PowerShell si desea administrar los agentes de transporte en los servidores de buzones de correo.
    1. Abra una nueva ventana de Windows PowerShell.

    2. Ejecute el siguiente comando.

      Add-PSSnapin Microsoft.Exchange.Management.PowerShell.SnapIn
      
    3. Realice las tareas de administración del agente de transporte de la forma habitual.

    4. Repita este procedimiento en cada servidor de acceso de clientes que desee administrar.

  • Error en la autenticación NTLM para clientes que no pertenecen a un dominio   Se puede producir un error en la autenticación entre un cliente, como Windows Live Mail y Exchange 2013, cuando las siguientes condiciones son verdaderas:

    • El método de autenticación utilizado por el cliente es NTLM.

    • El equipo no está conectado al dominio.

    Para evitar este problema, puede realizar una de las siguientes acciones:

    • Conecte al dominio el equipo en el que se ejecuta el cliente.

    • Cambie el tipo de autenticación que el cliente usa de NTLM a autenticación básica a través de TLS.

  • Error en la autenticación GSSAPI cuando se usa con el cmdlet Send-MailMessage   Se puede producir un error en la autenticación de la API de servicios de seguridad genéricos (GSSAPI) cuando el cmdlet Send-MailMessage, que se incluye con las instalaciones predeterminadas de Windows PowerShell, se usa para enviar correo autenticado a Exchange 2013. Cuando esto sucede, verá una entrada en el registro de eventos de la aplicación en el servidor de acceso de cliente de Exchange 2013 que recibió la conexión con la siguiente información:

    • Origen   MSExchangeFrontEndTransport

    • Id. de evento   1035

    • Descripción   Error de autenticación entrante IllegalMessage para front-end de cliente de conector de recepción <nombre de servidor>. El mecanismo de autenticación es Gssapi. La dirección IP de origen del cliente que intentó autenticar en Microsoft Exchange es [<dirección IP del cliente>].

    Para evitar este problema, necesita quitar el método de autenticación Integrated del conector de recepción del cliente en los servidores de acceso de cliente de Exchange 2013. Para quitar el método de autenticación Integrated de un conector de recepción de cliente, ejecute el siguiente comando en cada servidor de acceso de cliente de Exchange 2013 que podría recibir conexiones de los equipos que ejecutan el cmdlet Send-MailMessage:

    Set-ReceiveConnector "<server name>\Client Frontend <server name>" -AuthMechanism Tls, BasicAuth, BasicAuthRequireTLS
    
  • Puede que MAPI sobre HTTP experimente un bajo nivel de rendimiento al actualizar a Exchange 2013 SP1   Si actualiza desde una actualización acumulativa de Exchange 2013 a Exchange 2013 SP1 y habilita MAPI sobre HTTP, los clientes que se conecten a un servidor de Exchange 2013 SP1 usando el protocolo pueden experimentar un bajo nivel de rendimiento. El motivo es que las opciones necesarias no se configuran durante una actualización desde una actualización acumulativa a Exchange 2013 SP1. Este problema no se produce si actualiza a Exchange 2013 SP1 desde Exchange 2013 RTM o si instala un nuevo servidor de Exchange 2013 SP1 o una versión posterior.

    NotaNOTA:
    Esto supone un problema únicamente si el protocolo MAPI sobre HTTP está habilitado en los servidores de acceso de cliente. Está deshabilitado de forma predeterminada. Si MAPI sobre HTTP está deshabilitado, los clientes usan en su lugar el protocolo RPC sobre HTTP.

    Para resolver este problema, realice los siguientes pasos:

    1. En servidores que ejecutan el rol de servidor Acceso de cliente, ejecute los siguientes comandos en un símbolo del sistema de Windows:

      set AppCmdLocation=%windir%\System32\inetsrv
      set ExchangeLocation=%ProgramFiles%\Exchange Server\V15
      
      %AppCmdLocation%\appcmd.exe SET AppPool "MSExchangeMapiFrontEndAppPool" /CLRConfigFile:"%ExchangeLocation%\bin\MSExchangeMapiFrontEndAppPool_CLRConfig.config"
      %AppCmdLocation%\appcmd.exe RECYCLE AppPool "MSExchangeMapiFrontEndAppPool"
      
    2. En servidores que ejecutan el rol de servidor Buzón de correo, ejecute los siguientes comandos en un símbolo del sistema de Windows:

      set AppCmdLocation=%windir%\System32\inetsrv
      set ExchangeLocation=%ProgramFiles%\Exchange Server\V15
      
      %AppCmdLocation%\appcmd.exe SET AppPool "MSExchangeMapiMailboxAppPool" /CLRConfigFile:"%ExchangeLocation%\bin\MSExchangeMapiMailboxAppPool_CLRConfig.config"
      %AppCmdLocation%\appcmd.exe RECYCLE AppPool "MSExchangeMapiMailboxAppPool"
      
      %AppCmdLocation%\appcmd.exe SET AppPool "MSExchangeMapiAddressBookAppPool" /CLRConfigFile:"%ExchangeLocation%\bin\MSExchangeMapiAddressBookAppPool_CLRConfig.config"
      %AppCmdLocation%\appcmd.exe RECYCLE AppPool "MSExchangeMapiAddressBookAppPool"
      

  • Es posible que las solicitudes para acceder a buzones de correo de Exchange 2010 no funcionen cuando se redirijan mediante proxy a través de servidores de acceso de cliente de Exchange 2013   En algunas situaciones, es posible que la solicitud de proxy entre los servidores de acceso de cliente de Exchange 2013 y Exchange 2010 Service Pack 3 (SP3) sin ningún paquete acumulativo de actualizaciones instalado no funcione correctamente y que genere un error. Esto puede pasar si se cumplen todas las condiciones siguientes:

    • Un usuario con un buzón de Exchange 2013 intenta abrir un buzón de Exchange 2010 por alguno de los siguientes métodos:

      • La opción Abrir otro buzón de Outlook Web App -O-

      • La opción Otro usuario del Centro de administración de Exchange

    • El servidor de acceso de cliente al que se conectó el usuario ejecuta Exchange 2013.

    • El servidor de acceso de cliente de Exchange 2010 se actualizó a Exchange 2010 SP3 a partir de la versión RTM de Exchange 2010 o un Service Pack anterior de Exchange 2010.

    Si todas las condiciones anteriores se cumplen, el usuario no podrá acceder a las opciones de Exchange 2010 Outlook Web App del otro usuario y aparecerá una página en blanco.

    Para evitar este problema, instale el Paquete acumulativo de actualizaciones 1 de Exchange 2010 SP3 o posterior en cada servidor de Exchange 2010.

 
¿Te ha resultado útil?
(Caracteres restantes: 1500)
Gracias por sus comentarios
Mostrar:
© 2014 Microsoft