Conexión de clientes de correo electrónico a Microsoft Exchange Server. Comprender el desarrollo de clientes EWS para Exchange Agregar el grupo de subsistemas de confianza de Exchange a servidores que no son de Exchange

www.microsoft.com

Las URL internas y externas de Exchange 2013 son necesarias para acceder a determinados servicios desde diferentes ubicaciones: desde una red local o Internet. De forma predeterminada, al instalar un servidor, solo se especifican las URL internas y se vinculan al fqdn del servidor, y las URL externas están completamente ausentes. .

Este artículo es el quinto de una serie que cubre las tareas necesarias para configurar Exchange 2013 inmediatamente después de la instalación. Si estás interesado en otras tareas, te recomiendo acudir al artículo principal sobre configuración -o al artículo principal sobre el tema-.

Pasemos al objetivo principal de este artículo: cambiar las URL internas y externas.

Ajustes

Para hacer esto, vaya al directorio EAC - Servidores\Servidores— seleccione el servidor deseado con el mouse (para mí es exch02)\ Cambiar(icono de lápiz) - Perspectiva móvil.

en el campo Proporcione un nombre de host externo (por ejemplo, contoso.com) para conectar a los usuarios con su organización.. Registramos la dirección externa que necesitamos. Para mí será mail.bissquit.com. También sería una buena idea cambiar el nombre del nodo interno por algo similar. Depende de usted decidir si los nombres externos e internos serán iguales o diferentes, pero hacerlos idénticos parece más que lógico.

Si no ha cambiado el tipo de autenticación, aparecerá una advertencia:

No tengo versiones anteriores de Exchange, así que ignoro la advertencia.

Puedes hacer esto a través de Powershell usando el cmdlet Establecer Outlook en cualquier lugar:

PowerShell

Comprobemos el resultado:

A continuación, cambiemos la configuración de los directorios virtuales agregándoles una URL externa (falta de forma predeterminada) y configurando una dirección similar para las conexiones internas. A través de la interfaz web de EAC podrá realizar las acciones correspondientes en el catálogo Servidores\Directorios virtuales- seleccione el directorio deseado con el mouse, haga clic Cambiar(icono de lápiz), configure las URL internas y externas requeridas.

Repita los pasos para cada directorio virtual excepto Detección automática (sitio web predeterminado). Ejemplo de cómo cambiar las propiedades del directorio virtual ecp (sitio web predeterminado)‎:

Habrá bastantes comandos para cambiar la configuración a través de PowerShell, ya que hay un conjunto separado de cmdlets para cada tipo de directorio virtual:

Para cambiar el directorio virtual del panel de control - Conjunto-EcpVirtualDirectory.
Para cambiar el directorio virtual de los servicios web de Exchange: Conjunto-WebServicesVirtualDirectory.
Para cambiar el directorio virtual de los servicios de Microsoft Exchange ActiveSync - Set-ActiveSyncVirtualDirectory.
Para cambiar el directorio virtual de OAB: Conjunto-OabVirtualDirectory.
Para cambiar Outlook virtual - Set-OwaVirtualDirectory.
Para cambiar el directorio virtual de PowerShell: Conjunto-PowerShellVirtualDirectory.

Entonces, más cerca del punto:

PowerShell

Set-EcpVirtualDirectory "exch02\ecp (sitio web predeterminado)" -InternalUrl https://mail.bissquit.com/ecp -ExternalUrl https://mail.bissquit.com/ecp Set-WebServicesVirtualDirectory "exch02\EWS (sitio web predeterminado) ) )" -InternalUrl https://mail.bissquit.com/EWS/Exchange.asmx -ExternalUrl https://mail.bissquit.com/EWS/Exchange.asmx Set-ActiveSyncVirtualDirectory "exch02\Microsoft-Server-ActiveSync (predeterminado Sitio web)" -InternalUrl https://mail.bissquit.com/Microsoft-Server-ActiveSync -ExternalUrl https://mail.bissquit.com/Microsoft-Server-ActiveSync Set-OabVirtualDirectory "exch02\OAB (sitio web predeterminado) " -InternalUrl https://mail.bissquit.com/OAB -ExternalUrl https://mail.bissquit.com/OAB Set-OwaVirtualDirectory "exch02\OWA (sitio web predeterminado)" -InternalUrl https://mail.bissquit. com /owa -ExternalUrl https://mail.bissquit.com/owa Set-PowerShellVirtualDirectory "exch02\PowerShell (sitio web predeterminado)" -InternalUrl https://mail.bissquit.com/PowerShell -ExternalUrl https://mail. bissquit.com/PowerShell

Establecer -EcpVirtualDirectory "exch02\ecp (sitio web predeterminado)"-Url interna https://correo. bizcocho. com/ecp -Url externa https://mail. bizcocho. es/ecp Establecer -WebServicesVirtualDirectory "exch02\EWS (sitio web predeterminado)"-Url interna https://correo. bizcocho. com/EWS/Exchange. asmx -Url externa https://correo. bizcocho. com/EWS/Exchange. asmx Establecer -ActiveSyncVirtualDirectory "exch02\Microsoft-Server-ActiveSync (sitio web predeterminado)"-Url interna https://correo. bizcocho. com/Microsoft-Server -ActiveSync -ExternalUrl https: //mail. bizcocho. es/Microsoft-Server-ActiveSync Establecer -OabVirtualDirectory "exch02\OAB (sitio web predeterminado)"-Url interna https://correo. bizcocho. com/OAB -Url externa https: //correo. bizcocho. com/OAB Establecer -OwaVirtualDirectory "exch02\OWA (sitio web predeterminado)"-Url interna https://correo. bizcocho. com/owa -Url externa https://mail. bizcocho. com/owa Establecer -PowerShellVirtualDirectory "exch02\PowerShell (sitio web predeterminado)"-Url interna https://correo. bizcocho. com/PowerShell -ExternalUrl https://mail. bizcocho. es/PowerShell

Pasemos al siguiente capítulo.

Configuración del servidor DNS local

Dado que hemos especificado las mismas URL internas y externas para los servicios de Exchange 2013, debemos descubrir cómo configurar correctamente los registros del servidor DNS local (de cara al futuro, diré que esto se llama DNS dividido).

Nota: el hecho es que el dominio mail.bissquit.com se resolverá en la dirección externa de la puerta de enlace y, por lo tanto, se enviará al exterior y, cuando llegue a la puerta de enlace, se devolverá a la red local. No hay nada terrible en esto, pero es claramente una ruta adicional que llevará todo el tráfico que se dirige a Exchange 2013 desde la red local.

En el controlador de dominio, debe ir al complemento "DNS" y crear una nueva zona de búsqueda directa:

Dejamos todas las configuraciones por defecto, solo especificamos el nombre requerido, para mí es bissquit.com. Después de crear una zona, debe agregar un registro CNAME. Necesitamos que mail.bissquit.com se resuelva en la dirección interna del servidor Exchange 2013:

Nota: Tenga en cuenta que agregar un dominio de segundo nivel a su servicio puede ser una muy mala idea si este dominio (o sus subdominios) está vinculado a algunos recursos externos. En este caso, su servidor DNS local se considerará responsable de toda esta zona y devolverá una respuesta de que, por ejemplo, el dominio del sitio no existe.

El registro ha sido creado, veamos cómo funciona:

El nombre mail.bissquit.com se resuelve en una dirección interna, todo está bien, según lo necesitamos. Sin embargo, cuando intentamos hacer "ping" a otro subdominio, para el cual no creamos entradas en la nueva zona, no podemos resolver el nombre. Esto sucede porque nuestro servidor DNS se considera responsable (autorizado) de todo el dominio bisquit. Puede enviar consultas DNS para un registro de sitio de forma externa mediante la delegación:

Especifique el dominio requerido en el nombre:

A continuación, registre uno (o mejor aún, varios) de los servidores NS de su proveedor, cuyos registros DNS administra. Si no conoce ningún servidor NS, ejecute nslookup en la línea de comando, configure el tipo de registro (set type=ns), ingrese el nombre de dominio requerido (para mí es bissquit.com):

Comprobémoslo de nuevo:

Como puedes ver, todo funciona. Gracias al artículo en el blog de Alexey. Un pequeño inconveniente de este método es que necesita registrar manualmente todos los subdominios externos. Es cierto que todavía no tengo muchos, solo uno.

Entonces, esto completa la configuración de DNS. En general, la administración del servidor DNS solo está indirectamente relacionada con la configuración de URL internas y externas, pero este es un punto importante a considerar porque la documentación en Technet al realizar la configuración de URL solo brinda información general sobre qué registros DNS deben crearse, pero cómo hacerlo. haz esto y qué matices hay no se explican:

Después de configurar la URL interna en los directorios virtuales del servidor de acceso de cliente, debe configurar registros DNS privados para Outlook Web App y otras opciones de conectividad. Dependiendo de su configuración, deberá configurar registros DNS privados para que apunten a la dirección IP interna o externa o al FQDN del servidor de acceso de cliente. A continuación se muestran ejemplos de registros DNS recomendados que debe crear para que se conecten los clientes internos.

FQDN	tipo de registro DNS	Significado
Correo.contoso.com	CNOMBRE	Ex2013CAS.corp.contoso.com
www.contoso.com	CNOMBRE	Ex2013CAS.corp.contoso.com

24.12.2012

Este artículo analizará la segmentación de OWA, que se utiliza para limitar los componentes disponibles para el usuario a través de la interfaz de OWA, y cómo personalizar las pantallas de inicio y cierre de sesión de OWA.

William Lefkowitz ([correo electrónico protegido]) - CTO de Mojave Media Group, autor de artículos sobre tecnologías de mensajería y colaboración. Tiene certificación MCSE y título MVP de Microsoft Exchange.

Outlook Web App (OWA) en Exchange Server 2010 es el nuevo nombre de Outlook Web Access, que existe desde hace aproximadamente 15 años desde el lanzamiento de Exchange Server 5.0. Desde que la primera versión de Exchange Server finalizó su sesión con OWA, los administradores siempre han querido agregar características únicas a OWA, incluso más allá de las personalizaciones admitidas. Las configuraciones de OWA van desde ajustes de color hasta cambios completos en los símbolos corporativos y cambios radicales en la interfaz. La facilidad de configurar OWA depende de la versión de Exchange Server, las herramientas de configuración disponibles y la habilidad del administrador.

La versión moderna de OWA es significativamente diferente de la sencilla aplicación Active Server Pages (ASP) en Exchange 5.0 y 5.5. Con los servicios web de Microsoft Exchange, introducidos en Exchange Server 2007, los datos de Exchange están disponibles desde una variedad de fuentes compatibles con la API de servicios web. Exchange Server 2010 con Exchange Web Services facilita el diseño de aplicaciones web personalizadas para acceder a los datos de Exchange Server. Exchange 2007 agrega cuatro temas seleccionables por el usuario a OWA. Exchange Server 2010 RTM no implementa opciones de configuración de OWA; Los temas antiguos de Exchange 2007 todavía están presentes en la instalación, pero no funcionan. La configuración de OWA se devolvió solo en Exchange Server 2010 Service Pack 1 (SP1). El Exchange Server 2010 SP2 actual no incluye configuraciones de OWA más allá de las analizadas en este artículo.

El enfoque de Microsoft para configurar OWA

Muchos de los cambios de OWA que se están discutiendo requieren reemplazar archivos existentes por otros actualizados. Cuando se trabaja con temas, hojas de estilo en cascada (CSS) simples y pantallas de inicio de sesión y cierre, los cambios se producen a nivel de archivo. Cuando Microsoft actualiza Exchange Server (para corregir errores, paquetes acumulativos de parches o paquetes de servicios), la empresa no garantiza que se conservarán los cambios. Tampoco hay garantía de que las actualizaciones de código no afecten las personalizaciones realizadas por el usuario. Por lo tanto, debe archivar su configuración y asegurarse de que después de aplicar las actualizaciones, la configuración de OWA funcionará. Los enfoques de Microsoft para configurar OWA para todas las versiones hasta Exchange 5.5 se describen en el artículo “Política de soporte de Microsoft para la personalización de Outlook Web Access para Exchange” (http://support.microsoft.com/kb/327178). También es una buena idea desarrollar y probar sus personalizaciones, ya sean aplicaciones OWA personalizadas completas o cambios en la pantalla de inicio de sesión a nivel de archivo para una pantalla de marca, en el laboratorio antes de pasar su trabajo a producción.

Segmentación

La segmentación es un método de configuración OWA totalmente compatible. Con la segmentación, el administrador simplemente define los componentes de OWA que son visibles para el usuario final. Muchas empresas quieren que sus usuarios tengan acceso al conjunto completo de funciones a través del cliente OWA. Sin embargo, es posible que algunos usuarios solo necesiten un conjunto limitado de funciones para sus actividades diarias. Por ejemplo, no hace mucho trabajé en una fábrica donde los trabajadores necesitaban acceso al correo electrónico y a los contactos, pero no al calendario, las tareas o las carpetas públicas. El acceso restringido a OWA también puede impedir que los usuarios revelen o vean información confidencial o que esté más allá de su autoridad. Restringir el acceso a componentes opcionales según el uso o mediante políticas también es una buena práctica de seguridad que reduce la exposición al riesgo. Además, la segmentación puede reducir el ancho de banda de comunicación consumido durante las sesiones de OWA.

De forma predeterminada, OWA está disponible en un servidor Exchange 2010 con la función de servidor Acceso de cliente instalada. La segmentación no requiere ninguna configuración adicional. En Exchange 2007, la segmentación se administra fácilmente a través de Exchange Management Console (EMC). La segmentación se configura a través del servidor de acceso de cliente en EMC.

En la consola de EMC, navegue hasta el servidor de acceso de cliente que aloja OWA, haga clic con el botón derecho en el sitio OWA y seleccione Propiedades. La pestaña Segmentación (Figura 1) enumera las funciones de OWA que los usuarios del servidor de acceso de cliente pueden habilitar y deshabilitar (consulte la Tabla 1 para obtener una lista de las funciones disponibles). Seleccione y habilite funciones individuales una a la vez.

Exchange Server 2010 introdujo políticas de buzón de correo OWA. Con estas políticas, los administradores pueden aplicar la segmentación a usuarios individuales o grupos de usuarios en lugar de a todos los conectados a OWA en un servidor de acceso de cliente específico. Aunque la función tiene "buzón" en su nombre, estas políticas técnicamente no se aplican a los buzones, sino a la aplicación web utilizada para acceder a los datos del buzón. Cuando se instala la función del servidor Acceso de cliente, se aplica la política de buzón de correo OWA estándar. De forma predeterminada, todas las funciones segmentadas enumeradas están activadas.

Las políticas de buzón de correo de OWA se configuran en EMC a nivel de empresa, como se muestra en la Figura 2. Seleccione Acceso de cliente en el centro de configuración de la organización en EMC; Las políticas de buzón de OWA se muestran en el panel central. Para agregar una nueva política, haga clic con el botón derecho en un área vacía en el panel central y seleccione Nuevo en el menú contextual, o selecciónela directamente desde el panel Acciones de EMC. Como muestra la Figura 2, el objetivo principal de una política de buzón de correo OWA es configurar una opción de segmentación específica para un usuario o grupo, ya que no hay nada más que configurar en la interfaz de usuario. Es útil darle a la política un nombre descriptivo, como la región o unidad de negocio a la que se aplica, o incluir un objetivo de segmentación específico en el nombre, como Sin diario. La Figura 3 muestra la ventana Propiedades de Outlook Web App, donde puede aplicar una política de buzón OWA existente a uno o varios buzones. Las políticas de buzón de correo de OWA se pueden crear y editar utilizando Exchange Management Shell (EMS) o los comandos New-OWAMailboxPolicy y Set-OWAMailboxPolicy.

Cuando utiliza estos comandos para crear una nueva política de buzón de correo OWA o modificar una política existente, puede activar o desactivar una lista de atributos. Estos atributos se aplican directamente a las funciones enumeradas en la Tabla 1. De forma predeterminada, las funciones están habilitadas, por lo que, en general, al configurar una política de buzón OWA en EMS, debe seleccionar los atributos de alternancia y establecerlos en falso para deshabilitarlos. Para obtener listas de atributos para cada comando, consulte los artículos de Microsoft "Set-OwaMailboxPolicy" (http://technet.microsoft.com/en-us/library/dd297989.aspx) y "New-OWAMailboxPolicy" (http://technet .microsoft.com/en-us/library/dd351067), así como en la ayuda del comando.

La segmentación también se puede configurar mediante EMS a nivel de servidor o usuario. El comando Set-CASMailbox aplica la segmentación según lo definido en la política de buzón de correo OWA específica. Por ejemplo, el siguiente código aplica una política de buzón de OWA denominada Personal de Norteamérica al usuario Steve que tiene acceso al buzón:

Set-CASMailbox -Identity Steve -OwaMailboxPolicy: "Personal de Norteamérica"

Si hay espacios en el nombre de la política del buzón de OWA, EMS requiere que utilice comillas. Para aplicar la política de buzón de correo de OWA denominada Executives a todos los usuarios que pertenecen a la unidad organizativa (OU) de Active Directory (AD) con el mismo nombre, utilice el código:

Get-CASMailbox -Ejecutivos de unidades organizativas | Set-CASMailbox -OWAMailboxPolicy:Ejecutivos

Con EMS, puede obtener una lista de usuarios con acceso al buzón a los que desea aplicar políticas de buzón de OWA basadas en atributos típicos existentes (por ejemplo, Título, Ubicación). Para hacer esto, use Get-User y canalice la salida al comando Set-CASMailbox. También puedes extraer datos de un archivo de texto a través de EMS usando el comando Get-Content:

Obtener contenido "c:\files\OWAPolicyList.txt" | Set-CasMailbox -OwaMailboxPolicy "Personal de Norteamérica"

OWAPolicyList.txt es un archivo de texto simple que contiene una lista de direcciones de correo electrónico para buzones, una dirección por línea:

[correo electrónico protegido]

[correo electrónico protegido]

[correo electrónico protegido]

[correo electrónico protegido]

Por supuesto, los administradores de Microsoft Office 365 necesitan utilizar EMS para configurar la segmentación dentro de la empresa. El Panel de control de Exchange (ECP) para Office 365 no proporciona acceso a la administración de políticas de OWA.

Exchange 2010 SP2 recupera una versión de correo web previamente eliminada: OWA Mini, anteriormente conocida como Outlook Mobile Access (OMA) y presente en Exchange Server 2003. La versión actualizada de OWA Mini presenta un conjunto de formularios dentro de OWA. Como parte de OWA, OWA Mini (para navegadores móviles) y OWA Basic (para navegadores no probados) también reconocen indicadores de segmentación. Los usuarios a los que se les niega el acceso a carpetas básicas, como Calendario, no pueden acceder a estas carpetas a través de OWA Mini (Figura 4) u OWA Basic.

Pantalla 4. OWA Mini

La segmentación hace que la experiencia web de OWA sea más sencilla y coherente para los usuarios. De forma predeterminada, OWA muestra las carpetas principales de Correo, Calendario, Contactos y Tareas en la parte inferior izquierda de la ventana del navegador. Como ejemplo simple, considere un usuario llamado Steve Bauer a quien inicialmente no se le aplicaron políticas de buzón de correo OWA y, por lo tanto, tenía todas las funciones habilitadas. Apliquemos una política de buzón de correo OWA que deshabilite el calendario, las tareas y la selección de temas. Las pantallas 5 y 6 muestran las diferencias en la interfaz antes y después de aplicar la política.

La segmentación también se puede aplicar a nivel de servidor mediante el comando Set-VirtualDirectory. Al igual que con el comando Set-OWAMailboxPolicy, puede habilitar o deshabilitar funciones individuales. De esta manera, todos los que se conecten a un servidor y directorio virtual específico, como owa (sitio web predeterminado), verán la misma funcionalidad OWA. Si está utilizando algún tipo de método de equilibrio de carga para el acceso OWA en varios servidores de acceso de cliente, debe aplicar los cambios en la configuración de segmentación a todos los servidores de acceso de cliente del grupo. De lo contrario, los usuarios verán diferentes configuraciones de OWA según el servidor de acceso de cliente al que se conecten a través del mecanismo de equilibrio de carga.

Finalmente, tenga en cuenta que si crea una nueva política de buzón de correo de OWA o realiza cambios en la segmentación a nivel de servidor y desea aplicar inmediatamente la política o los cambios a los usuarios, es posible que deba reiniciar el sitio de OWA. Cuando se reinicia Microsoft IIS, los cambios en OWA también entran en vigor inmediatamente. La mejor manera de hacerlo es desde la línea de comando en el servidor usando el siguiente comando:

Personalización de pantalla de inicio y cierre de sesión de Iisreset -noforce

Cuando los usuarios accedan a la URL de OWA, la primera pantalla será la pantalla de registro (a menos que haya un error de certificación). Algunas empresas buscan personalizar la pantalla de registro y cierre de sesión para enfatizar la marca o asegurar a los usuarios que están en el lugar correcto. Una pantalla de registro con un logotipo corporativo y colores familiares dará a los usuarios la confianza de que están en el sitio correcto. También puede incluir cierta información o un descargo de responsabilidad en la pantalla de registro. La configuración de la pantalla de inicio o cierre de sesión no afecta la funcionalidad básica de OWA.

Las pantallas de inicio o cierre de sesión de OWA son formularios web independientes que utilizan varios archivos gráficos. Tablas gif y CSS para fuentes y formato. Para los usuarios nuevos que inician sesión en OWA, hay una pantalla adicional que también se puede personalizar porque los archivos CSS y las imágenes son los mismos que los de la pantalla de inicio de sesión. La pantalla de inicio de sesión inicial consta de nueve archivos gif, organizados y colocados según logon.css. Otros aspectos de la pantalla de registro también están determinados por la información del archivo CSS, incluido el tipo de fuente y los colores utilizados fuera de los archivos de imagen gif. Los mismos archivos se utilizan para la primera pantalla de configuración de inicio de sesión y para la pantalla de cierre de sesión. Para cambiar estos archivos, sólo necesitas hacerlo una vez; Las actualizaciones se reflejan en las tres páginas. Las versiones estándar de las pantallas de inicio de sesión, primer inicio de sesión y cierre de sesión se muestran en las pantallas 7, 8 y 9.

Pantalla 7: Pantalla de inicio de sesión estándar

Pantalla 8: Pantalla estándar de registro por primera vez

Pantalla 9: Pantalla de cierre de sesión estándar

Los archivos utilizados para las pantallas de inicio y cierre de sesión se encuentran en un servidor Exchange que ejecuta la función del servidor Acceso de cliente en el directorio \Program Files\Microsoft\Exchange Server\V14\ClientAccess\Owa\\Themes\Resources. La variable está en el nivel de Exchange Server. Exchange 2010 SP2 muestra una carpeta denominada 14.2.247.5. Exchange 2010 SP2 Rollup 1 agrega la carpeta 14.2.283.3. OWA utiliza la fuente más nueva.

Como se señaló anteriormente, si es posible, los ajustes deben probarse en el laboratorio. De lo contrario, intente hacer copias de seguridad de sus archivos fuente antes de realizar cambios en los archivos OWA. Afortunadamente, Microsoft le ha dado nombres descriptivos a los GIF. La Figura 10 muestra la distribución de gifs en la pantalla de registro; La Tabla 2 enumera los nombres de los archivos de imágenes y sus tamaños (en píxeles).

La forma más sencilla de personalizar su pantalla de inicio de sesión es un proceso de dos pasos: reemplace los gifs con logotipos de empresas más apropiados y cambie logon.css y owafont.css en consecuencia. Naturalmente, estos cambios superficiales no son los únicos, pero de esta forma podrás conseguir el máximo efecto con el mínimo esfuerzo. El GIF del texto de Outlook Web App que se muestra en las Figuras 7, 8 y 9 se llama lgntopl.gif (el nombre del archivo significa inicio de sesión, arriba, izquierda). Es más fácil trabajar con él si solo desea agregar su logotipo sin cambiar el esquema de color estándar de OWA. Al preparar este artículo, tomé un archivo gif y agregué un logotipo ficticio de Las Vegas Webmail, tomando prestado el famoso letrero de Las Vegas del Strip de Las Vegas en Nevada, como se muestra en la Figura 11. El tamaño del archivo gif siguió siendo el mismo (456 x 115 píxeles), por lo que simplemente reemplazando los archivos en el servidor de Acceso de Cliente, los usuarios que inicien sesión en OWA en ese servidor de Acceso de Cliente verán el nuevo logotipo. Si utiliza un tamaño de archivo diferente y no realiza cambios en el archivo CSS, el formato gráfico será inconsistente. La ubicación de cada imagen en la página está determinada por los datos del archivo CSS y depende de la ubicación de los píxeles, por lo que si cambia el tamaño de los archivos gif, tendrá que acomodar estos cambios en el archivo CSS. Obviamente, una personalización profunda de la pantalla de registro más allá de cambiar la apariencia de las imágenes existentes requiere algunos conocimientos de CSS.

Figura 11: Pantalla de inicio de sesión de OWA personalizada

El estilo del texto en la pantalla de inicio de sesión también está determinado por las instrucciones del archivo logon.css. Los archivos CSS son archivos de texto simples que se pueden modificar en un editor de texto o en uno de los muchos editores de CSS. Pero hoy en día, todos los programas de desarrollo web también pueden modificar CSS. Microsoft Expression Web es una gran herramienta para trabajar con archivos CSS; Microsoft Visual Studio también puede servir como un potente editor de CSS, aunque obviamente es irracional utilizarlo sólo para este propósito. Los colores en CSS se definen mediante códigos de color hexadecimales: el símbolo (#) seguido de un código de 6 dígitos. La mayoría de los editores de CSS proporcionan paletas de colores con números hexadecimales. También hay recursos de acceso rápido disponibles en Internet (como VisiBone). Los profesionales de marketing, artistas y programadores web suelen definir códigos de color precisos para productos impresos y web que representan la combinación de colores de los logotipos corporativos.

La Tabla 3 enumera algunos de los colores definidos en el archivo logon.css para la pantalla de inicio de sesión. Para este ejemplo, cambié el color de fuente en el archivo logon.css de naranja a morado y cambié el fondo del campo de entrada de nombre de usuario y contraseña a gris claro en lugar de naranja claro. También resalté el borde alrededor de los campos de entrada cambiando el gris escaso a un azul más intenso, cambiando el código de color y aumentando la frecuencia de píxeles del borde. Para realizar estos cambios, cambié los valores de fff3c0 a cccccc, ff6c00 a 800080 y a4a4a4 a 000080 en el archivo logon.css. Fue necesario probar varias versiones para determinar exactamente qué elementos del archivo CSS se estaban aplicando a la página. Tomando la precaución de mantener una copia de seguridad de logon.css, coloqué el nuevo archivo en el directorio \Program Files\Microsoft\Exchange Server\V14\ClientAccess\Owa\14.2.283.3\Themes\Resources en el servidor de acceso de cliente. También copié la nueva imagen lgntopl.gif en el mismo directorio. La Figura 12 muestra cambios simples realizados en la pantalla de registro de OWA. Por supuesto, sus opciones no se limitan a estas sencillas configuraciones. Con un buen conocimiento de CSS y gráficos, puede crear pantallas personalizadas de inicio y cierre de sesión que son irreconocibles de las opciones estándar de OWA.

Es posible que sus usuarios necesiten borrar la memoria caché de su navegador local para ver los cambios inmediatamente. En mi laboratorio, tuve que reiniciar el sitio web para hacer llegar los cambios a los clientes. Si utiliza determinadas aplicaciones o dispositivos proxy en el perímetro de la red, puede haber un retraso antes de que los usuarios reciban las actualizaciones.

Aplicar configuración

Los cambios de OWA no se replican entre los servidores de acceso de cliente. Si varios servidores Exchange con la función de servidor Acceso de cliente instalada proporcionan OWA, se debe aplicar cualquier configuración en cada servidor. Sólo en este caso todos los usuarios verán las mismas pantallas. Los usuarios recibirán pantallas OWA del servidor de acceso de cliente al que se dirigen sus navegadores. Esto puede ser tanto una ventaja como una desventaja. A veces resulta útil que diferentes grupos de usuarios interactúen con OWA de forma diferente en un entorno empresarial.

Si no desea trabajar a nivel de archivos en Exchange Server, pero necesita cambios en las pantallas de inicio de sesión y cierre, algunas empresas de marcas empresariales brindan servicios para una variedad de soluciones de software personalizadas, incluido OWA 2010. Muchas realizan cambios profundos en OWA pantallas de registro para que la aplicación quede irreconocible. Un ejemplo de dicho proveedor (con varias capturas de pantalla de soluciones para clientes) es Techstur.com. Si utiliza los servicios de dicha empresa, esté preparado para afrontar los problemas que puedan surgir tras el lanzamiento de nuevos paquetes de servicios para OWA.

Configurar OWA en Exchange Server 2010

Material de Rosalab Wiki

Objetivo

Esta instrucción describe cómo conectar varios clientes de correo electrónico a un servidor Microsoft Exchange. El objetivo es obtener un sistema que coincida en funcionalidad con Microsoft Outlook.

Datos de entrada

Los ejemplos utilizan el servidor Microsoft Exchange 2010 (v14.03.0361.001) Service Pack 3 Update RollUp 18. Las pruebas se llevan a cabo dentro de la red corporativa. Los servidores DNS contienen direcciones de correo externas para el servidor de correo. Lo siguiente debería funcionar en el servidor Exchange:

1. OWA (Outlook Web Access): cliente web para acceder al servidor de colaboración de Microsoft Exchange
2. OAB (Libreta de direcciones sin conexión): libreta de direcciones sin conexión
3. EWS (Exchange Web Services) es un servicio que proporciona acceso a los datos del buzón almacenados en Exchange Online (como parte de Office 365) y en la versión local de Exchange (a partir de Exchange Server 2007).

Configuración del servidor Exchange

Un aspecto importante para que los clientes que no sean de Microsoft se ejecuten correctamente en Exchange 2010 es la autenticación. Puede ver sus parámetros en un servidor Exchange con la función CAS (Client Access Server). Inicie el complemento Administrador de IIS y abra la pestaña Sitios/Sitio web predeterminado. Tenga en cuenta que la autenticación tiene tres componentes:

• OWA - Estado " Activado" Para " Autenticación básica" Y " Autenticación de Windows»:

• VHA - Estado " Activado" Para " Autenticación básica" Y " Autenticación de Windows»:

• EWS - Estado " Activado" Para " Autenticación anónima», « Autenticación básica" Y " Autenticación de Windows»:

Capas (intermediarias) y utilidades auxiliares.

DavMail

Algunos clientes de correo electrónico no pueden conectarse directamente a Microsoft Exchange y requieren el uso de un intermediario. En este ejemplo, se utiliza un servidor proxy como intermediario. DavMail.

• Instalar DavMail después de obtener derechos de administrador usando su o sudo:

sudo urpmi davmail

• Correr DavMail:

• En la pestaña "Principal" en el " URL de OWA (intercambio)"Ingrese la dirección de su servidor en el formato "https:// /EWS/Exchange.asmx" o un enlace a OWA

en el formato "https:// /owa."

• Recuerde los números de puerto " Puerto IMAP local" Y " Puerto SMTP local" En este ejemplo, son 1143 y 1025, respectivamente.

Para no iniciar manualmente el servidor cada vez DavMail, debes agregar su llamada al inicio.

• Ir al menú " Configuración del sistema → Inicio y apagado → Ejecución automática", haga clic en [ Agregar una aplicación] e ingrese “davmail” en la barra de búsqueda, luego haga clic en [ DE ACUERDO]:

Ahora servidor proxy local DavMail se iniciará automáticamente cuando se inicie el sistema. Si su icono en la “Barra de tareas” le molesta, existe una opción para ocultarlo. Para hacer esto, en el archivo .davmail.properties, edite la línea davmail.server=false, cambiando false a true:

Sudo mcedit /inicio/<имя_пользователя>/.davmail.properties

Clientes de correo para conectarse a Exchange

Ahora puede comenzar a configurar clientes de correo electrónico.

pájaro trueno

Mozilla Thunderbird es el principal cliente de correo electrónico para las distribuciones ROSA Linux y, muy probablemente, ya esté instalado en su sistema y listo para usar. Si no, puedes instalarlo desde los repositorios de ROSA. Este ejemplo utiliza la versión 52.2.1.

• Instalar pájaro trueno:

sudo urpmi mozilla-thunderbird

• Agregue una interfaz en ruso:

sudo urpmi mozilla-thunderbird-ru

• Instale el complemento Lightning, que le permite utilizar calendarios:

sudo urpmi mozilla-thunderbird-relámpago

• Correr pájaro trueno.

• En la sección " Cuentas"en el párrafo" Crea una cuenta" seleccionar " Correo electrónico" Aparecerá una ventana de bienvenida.

• En la ventana que se abre, haga clic en [ Salta esto y usa mi correo electrónico existente.].

• En la ventana " Configurar una cuenta de correo"ingrese en los campos" Su nombre», « Dirección de correo electrónico correo" Y " Contraseña» sus credenciales.

• Haga clic en [ Continuar]. El programa intentará encontrar conexiones (sin éxito) y aparecerá un mensaje de error:

Aquí necesitará los números de puerto que recordó durante la configuración. DavMail.

• Para categorías " Bandeja de entrada" Y " Extrovertido» cambie el nombre del servidor a “localhost”.
• Especificar para " IMAP" puerto 1143 y para " SMTP" - puerto 1025.
• En el campo " Nombre de usuario» especifique UPN (Nombre principal de usuario): el nombre de dominio del usuario en el formato “Nombre de usuario@DominioOrganización.ru”.
• Haga clic en el botón [ Volver a probar].

Si ingresa sus credenciales correctamente, no habrá errores. Es posible que el sistema le solicite que acepte el certificado del servidor Exchange. Si esto no sucede, es posible que haya apagado la interfaz demasiado pronto DavMail.

Crear un calendario de usuario

• En la categoría " Cuentas» seleccione el elemento « Crear un nuevo calendario».
• En la ventana que aparece, seleccione el valor “ En línea» y presione [ Próximo].
• Seleccione formato " CalDAV"y en el campo" DIRECCIÓN"escriba "http://localhost:1080/usuarios/ /calendario":

Crear una libreta de direcciones

libreta de direcciones pájaro trueno no admite el protocolo CardDAV y solo se puede conectar al directorio LDAP del servidor Exchange.

• Abra las libretas de direcciones existentes haciendo clic en el botón [ libreta de direcciones] y seleccionando “ Archivo -> Nuevo -> Directorio LDAP».

• En la ventana del asistente, especifique los siguientes parámetros:
  • Nombre- cualquier nombre adecuado
  • Nombre del servidor- servidor local
  • Elemento raíz (DN base)- ou=personas
  • Puerto- 1389 (de Davmail)
  • Nombre de usuario (DN vinculado)- Nombre de usuario UPN

• Haga clic en [ DE ACUERDO]. El programa le pedirá que ingrese una contraseña.

• Ir al menú de opciones pájaro trueno. En la categoría " Compilación» seleccione la pestaña « Direccionamiento" y debajo del texto "Al ingresar una dirección, busque direcciones postales adecuadas en" marque la casilla " servidor de directorio" seleccionando el nombre de su libreta de direcciones.

Evolución

Un cliente de correo electrónico también está disponible en los repositorios de ROSA. Evolución(En este ejemplo se utiliza la versión 3.16.4).

• Instalar Evolución:

evolución de sudo urpmi

• Instale el conector Intercambio compatible con la versión 2007 y posteriores:

sudo urpmi evolución-ews

• Correr Evolución.

• En la ventana del asistente, haga clic en [ Próximo] hasta llegar al “ Cuenta».
• Complete los campos " nombre completo" Y " Correo electrónico».
• En el " Recibir correo"en la lista" Tipo de servidor» seleccione "Servicios web de Exchange".
• Para el nombre, ingrese el nombre UPN del usuario en el formato "Nombre de [email protected]".
• En el campo " URL del host"ingrese "https://MailServerNameExchange/EWS/Exchange.asmx .
• En el campo " URL de la VH» Ingrese la URL de la OAB.
• Seleccione "Básico" como tipo de autenticación.

Tras una configuración exitosa, el programa le pedirá una contraseña:

Después de ingresar la contraseña Evolución Tendrá acceso a su buzón, libreta de direcciones y calendarios.

Para cualquier pregunta relacionada con este artículo, comuníquese con [correo electrónico protegido].

En la parte 5 de esta serie de artículos, analizamos la creación de una matriz de acceso de cliente en cada sitio de Active Directory. Luego habilitamos Outlook Anywhere y también configuramos la configuración del proveedor de Outlook para que los clientes de Outlook Anywhere pudieran conectarse cuando ocurriera una emergencia.

En esta parte de la serie continuaremos desde donde lo dejamos en la parte anterior. Comenzaremos configurando las URL internas y externas para los servicios CAS en cada servidor Exchange 2010 en ambos sitios de Active Directory. A continuación, crearemos un DAG y realizaremos algunas configuraciones básicas de DAG.

Cambiar las URL CAS internas y externas de Exchange 2010 para que apunten a HLB

Ahora es el momento de configurar las URL internas y externas para los servicios CAS de Exchange 2010 en cada centro de datos para que apunten a cada solución de equilibrio de carga respectivamente.

Para resumir brevemente las partes anteriores de esta serie, podemos decir que la dirección ' correo.exchangeonline.dk'apunta a la dirección VIP configurada en la solución de equilibrio de carga en el centro de datos principal, y' conmutación por error.exchangeonline.dk'apunta a la dirección VIP configurada en la solución de equilibrio de carga en el centro de datos de conmutación por error. Esto significa que las URL deben configurarse de manera diferente para cada centro de datos.

Aplicación web de Outlook (OWA)

Comencemos con las URL de Outlook Web App (OWA). Para ello utilizamos los siguientes comandos:

Centro de datos principal:

Set-OwaVirtualDirectory -Identidad "EX01\OWA (sitio web predeterminado)" -InternalURL /OWA -ExternalURL https://mail.exchangeonline.dk/OWA

Set-OwaVirtualDirectory -Identidad "EX03\OWA (sitio web predeterminado)" -InternalURL https://mail.exchangeonline.dk/OWA -ExternalURL https://mail.exchangeonline.dk/OWA

Centro de datos de emergencia:

Set-OwaVirtualDirectory -Identidad "EX02\OWA (sitio web predeterminado)" -InternalURL https://failover.exchangeonline.dk/OWA -ExternalURL https://failover.exchangeonline.dk/OWA

Set-OwaVirtualDirectory -Identidad "EX04\OWA (sitio web predeterminado)" -InternalURL https://failover.exchangeonline.dk/OWA -ExternalURL https://failover.exchangeonline.dk/OWA

Figura 1: Configuración de URL para el directorio virtual OWA

Panel de control de cambios (ECP)

Para el Panel de control de Exchange (ECP) utilizamos los siguientes comandos:

Centro de datos principal:

Set-EcpVirtualDirectory -Identidad "EX01\ECP (sitio web predeterminado)" -InternalURL https://mail.exchangeonline.dk/ECP -ExternalURL https://mail.exchangeonline.dk/ECP

Set-EcpVirtualDirectory -Identidad "EX03\ECP (sitio web predeterminado)" -InternalURL https://mail.exchangeonline.dk/ECP -ExternalURL https://mail.exchangeonline.dk/ECP

Centro de datos de emergencia:

Set-EcpVirtualDirectory -Identidad "EX02\ECP (sitio web predeterminado)" -InternalURL https://failover.exchangeonline.dk/ECP -ExternalURL https://failover.exchangeonline.dk/ECP

Set-EcpVirtualDirectory -Identidad "EX04\ECP (sitio web predeterminado)" -InternalURL https://failover.exchangeonline.dk/ECP -ExternalURL https://failover.exchangeonline.dk/ECP

Figura 2: Configuración de URL para el directorio virtual de ECP

Intercambio ActiveSync (EAS)

Para Exchange ActiveSync (EAS) utilizamos los siguientes comandos:

Centro de datos principal:

Set-ActivesyncVirtualDirectory -Identity EX01\Microsoft-Server-ActiveSync (sitio web predeterminado)" -InternalURL https://mail.exchangeonline.dk/Microsoft-Server-Activesync -ExternalURL https://mail.exchangeonline.dk/Microsoft-Server -Sincronización activa

Set-ActivesyncVirtualDirectory -Identidad "EX03\Microsoft-Server-ActiveSync (sitio web predeterminado)" -InternalURL https://mail.exchangeonline.dk/Microsoft-Server-Activesync -ExternalURL https://mail.exchangeonline.dk/Microsoft- Servidor-Activesync

Centro de datos de emergencia:

Set-ActivesyncVirtualDirectory -Identidad "EX02\Microsoft-Server-ActiveSync (sitio web predeterminado)" -InternalURL https://failover.exchangeonline.dk/Microsoft-Server-Activesync -ExternalURL https://failover.exchangeonline.dk/Microsoft- Servidor-Activesync

Set-ActivesyncVirtualDirectory -Identidad "EX04\Microsoft-Server-ActiveSync (sitio web predeterminado)" -InternalURL https://failover.exchangeonline.dk/Microsoft-Server-Activesync -ExternalURL https://failover.exchangeonline.dk/Microsoft- Servidor-Activesync

Figura 3: Configuración de URL para el directorio virtual de EAS

Libreta de direcciones sin conexión (OAB)

Para la libreta de direcciones sin conexión utilizamos los siguientes comandos:

Centro de datos principal:

Set-OABVirtualDirectory -Identidad "EX01\oab (sitio web predeterminado)" -InternalUrl https://mail.exchangeonline.dk/oab -ExternalURL https://mail.exchangeonline.dk/oab

Set-OABVirtualDirectory -Identidad "EX03\oab (sitio web predeterminado)" -InternalUrl https://mail.exchangeonline.dk/oab -ExternalURL https://mail.exchangeonline.dk/oab

Centro de datos de emergencia:

Set-OABVirtualDirectory -Identidad "EX02\oab (sitio web predeterminado)" -InternalUrl https://failover.exchangeonline.dk/oab -ExternalURL https://failover.exchangeonline.dk/oab

Set-OABVirtualDirectory -Identidad "EX04\oab (sitio web predeterminado)" -InternalUrl https://failover.exchangeonline.dk/oab -ExternalURL https://failover.exchangeonline.dk/oab

Figura 4: Configuración de URL para el directorio virtual OAB

Servicios web de intercambio (EWS)

Para Exchange Web Services (EWS) utilizamos los siguientes comandos:

Centro de datos principal:

Set-WebServicesVirtualDirectory -Identidad "EX01\EWS (sitio web predeterminado)" -InternalUrl https://mail.exchangeonline.dk/ews/exchange.asmx -ExternalURL https://mail.exchangeonline.dk/ews/exchange.asmx

Set-WebServicesVirtualDirectory -Identidad "EX03\EWS (sitio web predeterminado)" -InternalUrl https://mail.exchangeonline.dk/ews/exchange.asmx -ExternalURL https://mail.exchangeonline.dk/ews/exchange.asmx

Centro de datos de emergencia:

Set-WebServicesVirtualDirectory -Identidad "EX02\EWS (sitio web predeterminado)" -InternalUrl https://failover.exchangeonline.dk/ews/exchange.asmx -ExternalURL https://failover.exchangeonline.dk/ews/exchange.asmx

Set-WebServicesVirtualDirectory -Identidad "EX04\EWS (sitio web predeterminado)" -InternalUrl https://failover.exchangeonline.dk/ews/exchange.asmx -ExternalURL https://failover.exchangeonline.dk/ews/exchange.asmx

Figura 5: Configuración de URL para el directorio virtual de EWS

Mensajería unificada (UM)

En este entorno de prueba no utilizamos mensajería unificada (MU), pero si tiene otros planes, deberá configurar una URL utilizando los siguientes comandos:

Centro de datos principal:

Set-UMVirtualDirectory -Identidad "EX01\unifiedmessaging (sitio web predeterminado)" -InternalUrl https://mail.exchangeonline.dk/unifiedmessaging/service.asmx -ExternalUrl https://mail.exchangeonline.dk/unifiedmessaging/service.asmx

Set-UMVirtualDirectory -Identidad "EX03\unifiedmessaging (sitio web predeterminado)" -InternalUrl https://mail.exchangeonline.dk/unifiedmessaging/service.asmx -ExternalUrl https://mail.exchangeonline.dk/unifiedmessaging/service.asmx

Centro de datos de emergencia:

Set-UMVirtualDirectory -Identidad "EX02\unifiedmessaging (sitio web predeterminado)" -InternalUrl https://failover.exchangeonline.dk/unifiedmessaging/service.asmx -ExternalUrl https://failover.exchangeonline.dk/unifiedmessaging/service.asmx

Set-UMVirtualDirectory -Identidad "EX04\unifiedmessaging (sitio web predeterminado)" -InternalUrl https://failover.exchangeonline.dk/unifiedmessaging/service.asmx -ExternalUrl https://failover.exchangeonline.dk/unifiedmessaging/service.asmx

URI de detección automática interna

Finalmente, debemos señalar el URI interno del servicio de detección automática al FQDN de la solución HLB. Esto se puede hacer usando los siguientes comandos:

Centro de datos principal:

Set-ClientAccessServer 'Identidad EX01 -AutoDiscoverServiceInternalUri: https://mail.exchangeonline.dk

Set-ClientAccessServer 'Identidad EX03 -AutoDiscoverServiceInternalUri: https://mail.exchangeonline.dk /descubrimiento automático/descubrimiento automático.xml

Centro de datos de emergencia:

Set-ClientAccessServer 'Identidad EX02 -AutoDiscoverServiceInternalUri: https://mail.exchangeonline.dk /descubrimiento automático/descubrimiento automático.xml

Set-ClientAccessServer 'Identidad EX04 -AutoDiscoverServiceInternalUri: https://mail.exchangeonline.dk /descubrimiento automático/descubrimiento automático.xml

Figura 6: Opciones de URI de detección automática interna

Tenga en cuenta que dirigimos los servidores Exchange 2010 en ambos centros de datos al mismo URI de detección automática. También es posible señalar AutoDiscoverInternalUri en los servidores CAS en el centro de datos de desastres a 'https://failover.exchangelabs.dk/autodiscover/autodiscover.xml', por lo que puede terminar en una situación en la que los SCP no estén disponibles durante un desastre. . Además, el tráfico entre sitios generado por el servicio de detección automática tendrá menos impacto en el enlace WAN porque las solicitudes de detección automática constan de pequeños archivos de texto XML.

Crear y configurar bases de datos de buzones de correo.

Ahora que hemos terminado con el lado de CAS, podemos concentrarnos en crear bases de datos de buzones de correo y crear y configurar un grupo de disponibilidad de bases de datos (DAG).

En el entorno de prueba utilizado en esta serie de artículos, creé 12 bases de datos de buzones de correo distribuidas en dos servidores Exchange 2010 en el centro de datos principal, como se muestra en Figura 7.

Figura 7: Bases de datos de buzones de correo de Exchange 2010

Nota: Dado que en este entorno no se utilizan clientes Outlook 2003 y las carpetas públicas no se utilizan como repositorios de datos, no existen bases de datos de carpetas públicas. Si su situación es diferente, tenga en cuenta que no puede utilizar la función DAG para proteger los datos de las carpetas públicas (como era el caso con CCR en Exchange 2007). En su lugar, debe crear al menos una base de datos de carpetas públicas en cada centro de datos y agregar los servidores adecuados que contienen esas bases de datos a la lista de copias de cada carpeta pública.

Como puede ver, nombré las bases de datos DAG01-MDB001, DAG01-MDB002, etc. No porque sea vago, sino porque simplemente no hay necesidad de usar nombres largos y complejos para estas bases de datos. Para las bases de datos que forman parte de un DAG, es mejor utilizar estándares de nomenclatura en los que el nombre de la base de datos esté precedido por el nombre del DAG al que pertenece la base de datos. En cuanto a las rutas a la base de datos y a las carpetas de registro, es mejor usar algo como E:\DAG_name\Database_name.edb y F:\Dag_name\Database_name.

Nota: Cuando tiene varias copias de una base de datos, no necesariamente necesita usar LUN dedicados para los archivos de registro; simplemente puede usar la misma ruta especificada para el archivo .edb (en nuestro ejemplo es 'E:\DAG_name\Database_name' ). Esto es totalmente compatible y es el método recomendado si no está utilizando una solución de copia de seguridad VSS de hardware para realizar copias de seguridad de sus bases de datos de Exchange. No hace falta decir que es necesario utilizar puntos de montaje porque, de lo contrario, rápidamente se quedará sin letras de unidad.

Agregar un grupo de subsistema de confianza de Exchange a servidores que no son de Exchange

Para aquellos de ustedes que han implementado servidores de buzones de correo basados ​​en Exchange 2007 CCR o Exchange 2010 Mailbox DAG, deben saber que es mejor usar un servidor de transporte de concentradores en el mismo sitio de Active Directory como servidor testigo para el clúster CCR o DAG.

Dado que este entorno consta de servidores Exchange 2010 con múltiples funciones que forman parte del mismo DAG, no podemos usar el servidor Hub Transport de Exchange 2010 como servidor testigo, sino que debemos usar un servidor de archivos tradicional de Windows Server 2008/R2 para este propósito. Por esta razón necesitamos agregar ' Subsistema de confianza de Exchange'grupo creado por la instalación de Exchange 2010 al grupo de administradores locales en el servidor de archivos correspondiente. Esto es para garantizar que se otorguen los permisos correctos a Exchange. Para ello, inicie sesión en el servidor de archivos y abra el administrador del servidor ' Administrador del servidor'. Expandir ' Configuración‘ > ‘Usuarios y grupos locales' y abre Propiedades grupos Administradores.

Figura 8: Búsqueda del grupo de administradores locales en un servidor de archivos de Windows Server 2008 R2

Ahora ingresa ' Subsistema de confianza de Exchange' en el campo de texto como se muestra en Figura 9 y presione DE ACUERDO.

Figura 9: Ingresando al grupo de subsistema confiable de Exchange

Haga clic de nuevo DE ACUERDO.

Figura 10: Página de propiedades del grupo de administradores

Como ya se indicó, este paso sólo es necesario cuando se utiliza un servidor que no es Exchange como servidor testigo.

Crear y configurar un DAG

Dado que nuestros usuarios activos están constantemente ubicados en un centro de datos (modelo de distribución de usuarios activos/pasivos), un DAG extendido será suficiente para este escenario.

Para crear un grupo DAG simple, ejecute el asistente de creación de grupos "". Para ello, expanda el centro de trabajo 'Configuración de la organización' y haga clic derecho en ' Buzón‘, luego seleccione la opción para crear un nuevo grupo’ Nuevo grupo de disponibilidad de base de datos' en el menú contextual. En el asistente, debe especificar el nombre del DAG e ingresar el nombre del servidor testigo. Finalmente, necesitamos especificar la ruta del directorio testigo. Llamaré al grupo DAG' DAG01' y utilizará un servidor de archivos unido a un dominio (FS01) como servidor testigo. Cuando esté listo, haga clic en ' Nuevo‘.

Figura 11: Creación de un DAG

en la final (Terminación) página tenemos una advertencia de que el grupo ' Subsistema de confianza de Exchange'no es miembro del grupo' Administradores locales' en el servidor testigo especificado. Este error se puede ignorar ya que ya agregamos este grupo.

Hacer clic Finalizar para salir del asistente ( Figura 12).

Figura 12: Página final del asistente DAG

Configurar un servidor testigo alternativo

Cuando se trata de utilizar un DAG extendido entre dos centros de datos (sitios AD), se recomienda configurar primero un servidor testigo alternativo, que en este escenario sería un servidor de archivos (FS02) en el centro de datos de conmutación por error.

Para hacer esto, primero debemos agregar ' Subsistema de confianza de Exchange'grupo al grupo de administradores locales' (Administradores locales)'de la misma manera que se describe anteriormente. Luego debe especificar FS02 como servidor testigo alternativo en el propio objeto DAG. Para hacer esto, abra la página de propiedades de DAG ' DAG01'. En la pestaña ' General‘vemos el servidor testigo principal FS01 y el directorio testigo para este servidor. A continuación tenemos la opción de ingresar un servidor testigo alternativo ( Figura 13). Hacemos esto y pulsamos ' Aplicar'. Deje abierta la página de propiedades.

Figura 13: Especificación de un servidor testigo alternativo

Asignar direcciones IP estáticas a un grupo DAG

Aunque es posible usar direcciones IP asignadas por DHCP para el DAG, prefiero usar direcciones estáticas, por lo que el siguiente paso es asignar una dirección IP estática para el DAG en cada centro de datos (en cada subred).

Nota: Si desea utilizar direcciones IP asignadas por DHCP, puede omitir este paso.

Para configurar una dirección IP estática, vaya a la pestaña ' Direcciones IP'. En la pestaña ' Direcciones IP'Establezca la dirección IP en cada subred para el DAG. Luego haga clic en ' DE ACUERDO'para salir de la página de propiedades.

Figura 14: Asignación de una dirección IP estática a un DAG

Entonces, hemos creado y configurado un DAG simple.

La información contenida en este documento puede ser una vista previa de características y productos y puede sufrir cambios significativos antes del lanzamiento comercial final. Este documento se proporciona "tal cual" y tiene fines informativos únicamente. Microsoft no ofrece ninguna garantía, expresa o implícita, en relación con este documento.

Consejos para desarrollar con EWS for Exchange.

Ámbito de aplicación: Intercambio en línea | Servidor Exchange 2013 | Oficina 365

Este artículo proporciona información general sobre la creación de una aplicación de servicios web de Exchange (EWS). Con esta información, puede determinar si la API de EWS es adecuada para su aplicación y qué tipo de implementación de cliente necesita. Este artículo también proporciona orientación para crear aplicaciones para Office 365, Exchange Online y versiones de Exchange a partir de Exchange 2007 utilizando una base de datos de código único. También le ayuda a decidir si desea desarrollar soluciones para Exchange Server local o Exchange Online.

Antes de comenzar a crear su aplicación, debe determinar si la API de EWS es adecuada para usted. Si está desarrollando una solución para Exchange Server o Exchange Online, EWS es la tecnología de acceso de cliente preferida. El desarrollo de soluciones de acceso de clientes para versiones de Exchange, comenzando con Exchange 2007, se ha centrado principalmente en EWS. EWS se utiliza para potenciar las nuevas funciones de acceso de clientes introducidas en Outlook. Estas incluyen pantallas de estado de fuera de la oficina y libre/ocupado, disponibles por primera vez en Exchange 2007, así como las sugerencias y funciones de adquisición de salas introducidas en Exchange 2010. Para los socios internos y externos que desarrollan aplicaciones cliente de Exchange, esto favorece la Inversiones en SAT obligatorias.

La API de EWS es la API principal de acceso de cliente para aplicaciones cliente de Exchange. Pero en algunos casos, otras API de Exchange pueden resultar útiles para desarrollar aplicaciones cliente. Por ejemplo, Exchange ActiveSync tiene las siguientes ventajas sobre EWS:

Para que el protocolo Exchange ActiveSync sea más compacto, se ha marcado la estructura XML.

Exchange ActiveSync le permite utilizar políticas para controlar el acceso de los clientes y otras soluciones confiables de mensajería móvil en la empresa.

MAPI RPC/HTTP es otra opción para programar aplicaciones cliente de Exchange. Sin embargo, MAPI RPC/HTTP no proporciona una interfaz intuitiva para la comunicación entre los clientes y el servidor.

Para obtener más información sobre tecnologías de desarrollo para Exchange, consulte este artículo.

Hay varias formas de desarrollar Exchange utilizando EWS. La mejor opción depende de la plataforma de desarrollo, las herramientas, las implementaciones disponibles y los requisitos de aplicación de la organización. Hay cuatro opciones principales disponibles para crear aplicaciones cliente EWS:

API administrada por EWS;

• proxies EWS creados automáticamente;

  API de cliente EWS personalizada.

API administrada por EWS

La API del servicio web de EWS puede ser más adecuada para usted que la API administrada de EWS por uno de los siguientes motivos:

su aplicación no utiliza .NET Framework;

no desea distribuir el ensamblaje de la API administrada de EWS;

La aplicación requiere funciones que no están disponibles en la API administrada de EWS.

Para obtener más información, consulte el artículo.

La API administrada de EWS ahora está disponible como proyecto de código abierto en GitHub. Con una biblioteca de código abierto puedes: agregar correcciones de errores y mejoras a la API; recibir correcciones de errores y mejoras antes de que estén disponibles en la versión oficial; Acceda a la implementación de API más completa y actualizada, que puede utilizar como referencia o para crear nuevas bibliotecas en nuevas plataformas.