E2k3techref

c5541abf-15ce-464f-b5d2-758395fcdf3e

Guía de referencia técnica de Microsoft Exchange Server 2003

Microsoft Corporation Publicación: 12 de diciembre de 2006 Autor: Equipo de documentación de Exchange Server

Descripción breve Esta guía está dirigida a los expertos de Exchange Server 2003 que necesitan información detallada acerca de la arquitectura y la integración entre los componentes principales de Microsoft Exchange Server 2003. ¿Comentarios? Envíe sus comentarios a [email protected].

Contents Guía de referencia técnica ?de Exchange Server 2003 ....................................................... 17 Introducción a la Guía de referencia técnica de Exchange Server 2003 ............................... 17 Contenido de esta guía .................................................................................................... 17 A quién va dirigida esta guía ............................................................................................ 19 ¿Qué debe leer primero? ................................................................................................. 19 Introducción a la Biblioteca técnica de Exchange Server 2003 ............................................ 20 Exchange Server 2003 como sistema de tratamiento de mensajes ..................................... 21 Componentes generales de un sistema de tratamiento de mensajes................................ 21 El sistema de tratamiento de mensajes en la infraestructura de red ................................. 23 Integración de directorios .................................................................................................... 24 Objetos de destinatario del directorio ............................................................................... 24 Información de configuración del directorio ...................................................................... 26 Clases y atributos de Exchange en Active Directory ......................................................... 27 Arquitectura del acceso a directorios ................................................................................ 27 El transporte de mensajes ................................................................................................... 28 Arquitectura de enrutamiento de mensajes ...................................................................... 28 Enrutamiento de mensajes con grupos de enrutamiento .................................................. 29 El almacén de mensajes de Exchange ................................................................................ 32 Tecnología de bases de datos de Exchange Server 2003 ................................................ 32 Almacenes y grupos de almacenamiento ......................................................................... 32 Agentes de usuarios de una organización de Exchange Server 2003 .................................. 34 Dependencias de los servicios de Exchange Server 2003 ................................................... 35 Descripción de la arquitectura de los servicios de Windows ................................................ 37 Funciones del Administrador de control de servicios ........................................................ 38 Servicios de Exchange y cuenta LocalSystem.................................................................. 44 Examen de la base de datos de servicios ........................................................................ 45 Servicios del sistema operativo ........................................................................................... 51 Servicios de Internet Information Server .............................................................................. 55 Servicios básicos de Exchange Server 2003 ....................................................................... 61 Servicios adicionales de Exchange Server 2003 ................................................................. 72

Cómo detener todos los servicios de Exchange Server 2003 de un servidor........................ 75 Antes de empezar............................................................................................................ 76 Procedimiento.................................................................................................................. 76 Exchange Server 2003 y Active Directory ............................................................................ 76 Integración de directorios y Exchange Server 2003 ............................................................. 77 Clases y atributos de Exchange en Active Directory ......................................................... 78 Acceso al servicio de directorio ........................................................................................ 81 Equilibrio de carga y conmutación por error de la conexión LDAP .................................... 83 Descubrimiento de la topología de DSAccess .................................................................. 85 Descubrimiento inicial y descubrimiento continuo ............................................................. 86 Protección de servidores DSAccess................................................................................. 89 Perfiles de DSAccess ...................................................................................................... 91 Especificación del controlador de dominio de configuración ............................................. 93 Cómo DSAccess asigna funciones de servidor ................................................................ 94 La caché de Directory Access .......................................................................................... 97 Precarga de DSAccess .................................................................................................... 99 Proxy del servicio de directorio (DSProxy) ......................................................................... 102 Operaciones de DSProxy............................................................................................... 103 Comportamiento de referencia de Exchange Server 2003 anterior al Service Pack 2 ..... 103 Comportamiento de referencia de Exchange Server 2003 anterior a Service Pack 2 ...... 105 El categorizador SMTP ..................................................................................................... 110 Categorización de mensajes y Active Directory .............................................................. 111 Servicio de actualización de destinatarios y Exchange Server 2003 .................................. 113 Actualización de objetos de destinatario......................................................................... 113 Servicio de actualización de la metabase .......................................................................... 116 Operaciones de DS2MB ................................................................................................ 116 Arquitectura del Administrador del sistema de Exchange................................................... 117 Integración con Microsoft Management Console ............................................................... 118 Complementos de Exchange Server 2003 y extensiones de los complementos ............. 124 Creación de consolas de administración personalizadas de Exchange........................... 140 Administración de la información de configuración en Active Directory .............................. 142 Enlazar con un controlador de dominio .......................................................................... 142 La organización de Exchange en la partición del directorio de configuración .................. 144 El Administrador del sistema de Exchange y las configuraciones de permisos ............... 147 Habilitar la ficha Seguridad para objetos del Administrador del sistema de Exchange .... 148 La herencia de permisos y el Administrador del sistema de Exchange ........................... 150 Administración de recursos de almacén de Exchange ....................................................... 154

Comunicación basada en MAPI ..................................................................................... 154 Información obtenida a través de la interfaz IExchangeManageStore ............................. 155 El Administrador del sistema de Exchange y los clientes basados en MAPI ................... 156 Comunicación basada en DAV ...................................................................................... 157 Comunicación basada en DAV y directorios virtuales HTTP ........................................... 157 El Administrador del sistema de Exchange y el directorio virtual Exadmin ...................... 159 Conexión a un servidor de Exchange específico ............................................................ 161 El Administrador del sistema de Exchange y el sitio Web predeterminado ...................... 162 El directorio virtual Exadmin y el cifrado SSL ................................................................. 163 Cómo mostrar toda la información obtenida de un almacén de buzón o almacén de carpetas públicas ......................................................................................................................... 165 Procedimiento................................................................................................................ 165 Cómo conectar a un servidor de Exchange específico en el Administrador del sistema de Exchange ...................................................................................................................... 165 Procedimiento................................................................................................................ 166 Integración con el Instrumental de administración de Windows ......................................... 166 Configuración de servicios en el Administrador del sistema de Exchange .......................... 169 Arquitectura de enrutamiento de mensajes ........................................................................ 171 Topología de enrutamiento de mensajes de Exchange Server 2003 .................................. 173 Tratamiento de mensajes de Exchange Server 2003 ......................................................... 176 Enrutamiento de mensajes de Exchange Server 2003....................................................... 184 Rutas de mensajes y tablas de estado de vínculos ........................................................ 184 Inicialización de la tabla de estado de vínculos .............................................................. 184 El motor de enrutamiento y el servicio Motor de enrutamiento de Exchange................... 186 Examen de la tabla de estado de vínculos ..................................................................... 186 Selección de ruta de enrutamiento de Exchange ............................................................ 203 Proceso de selección de ruta de enrutamiento ............................................................... 206 El algoritmo de ruta más corta de Dijkstra ...................................................................... 207 Equilibrio de carga de transferencia de mensajes .......................................................... 211 Equilibrio de carga entre grupos de enrutamiento .......................................................... 211 Equilibrio de carga entre conectores y sistemas externos............................................... 214 Redireccionamiento de mensajes basado en la información de estado de vínculos ........ 215 Redireccionamiento de mensajes .................................................................................. 215 Redireccionamiento y espacios de direcciones .............................................................. 217 Recuperación de conectores.......................................................................................... 217 Programaciones de Redireccionamiento y activación ..................................................... 218 Propagación de estado de vínculos ................................................................................... 218

Algoritmo de estado de vínculos .................................................................................... 219 Ejemplo de LSA ............................................................................................................. 222 Cambios y propagación de estado de vínculos............................................................... 226 Cambio del maestro de grupo de enrutamiento .............................................................. 227 Conflictos entre maestros de grupo de enrutamiento ...................................................... 228 Compatibilidad con Exchange Server 5.5 .......................................................................... 229 Generación de la GWART ............................................................................................. 229 Problemas de enrutamiento en modo mixto ................................................................... 230 Actualizaciones de la topología ...................................................................................... 230 Propagación de estado de vínculos rotos ....................................................................... 231 Arquitectura de transporte SMTP ...................................................................................... 232 Diseño del servicio SMTP ................................................................................................. 234 Integración con los Servicios de Internet Information Server (IIS) ................................... 235 Ejecución de subprocesos asincrónica ........................................................................... 236 Tratamiento de conexiones SMTP entrantes .................................................................. 236 Limitación del número de subprocesos SMTP ................................................................ 238 Extensiones SMTP basadas en el modelo de objetos componentes .............................. 239 Sucesos del subsistema de transporte SMTP ................................................................ 240 El distribuidor y las notificaciones de sucesos ................................................................ 241 Interfaces administrativas .............................................................................................. 243 Opciones de configuración y enlaces de sucesos .......................................................... 243 Información de configuración de Active Directory ........................................................... 244 Opciones de configuración SMTP de la metabase ......................................................... 249 Claves de configuración SMTP ...................................................................................... 250 Edición directa de la metabase ...................................................................................... 252 Registros de dominios locales ........................................................................................ 252 Registros de receptores de sucesos .............................................................................. 253 Objetos de extensión de servidor ................................................................................... 255 Cómo habilitar la característica Habilitar la modificación directa de archivos de metabase en el Administrador de IIS................................................................................................... 257 Antes de empezar.......................................................................................................... 257 Procedimiento................................................................................................................ 257 El motor de cola avanzada ................................................................................................ 259 Sucesos desencadenados por el motor de cola avanzada ............................................. 260 Colas de mensajes del motor de cola avanzada ............................................................. 263 Limitación del número de mensajes en colas de mensajes ............................................. 268 ºComponentes del transporte SMTP ................................................................................. 269 Categorizador de Exchange ........................................................................................... 271 Bifurcación de mensajes ................................................................................................ 284

Conversión de contenido ............................................................................................... 285 IMAIL ............................................................................................................................. 286 TNEF ............................................................................................................................. 286 Tratamiento de los mensajes de las carpetas públicas ................................................... 289 Ajuste de rendimiento del categorizador......................................................................... 290 Equilibrio de carga del catálogo global ........................................................................... 292 Lotes de búsqueda LDAP .............................................................................................. 294 Categorización de los mensajes..................................................................................... 295 Secuencias de datos alternativas en el directorio \Queue ............................................... 296 Aplicación obligatoria de la categorización ..................................................................... 298 Controladores de almacén del servicio SMTP ................................................................... 299 Controlador del almacén NTFS ...................................................................................... 300 Cambio de ubicación del directorio \Mailroot .................................................................. 302 Controlador del almacén de Exchange ........................................................................... 303 Arquitectura del controlador del almacén de Exchange .................................................. 304 Sistema de archivos instalable de Exchange .................................................................. 306 Transferencia de mensajes salientes ............................................................................. 307 Transferencia de mensajes entrantes ............................................................................ 311 Reintentos de transferencia ........................................................................................... 313 Extensiones del protocolo SMTP ....................................................................................... 313 Categorías de sucesos de protocolo .............................................................................. 319 Extensiones del protocolo SMTP específicas de Exchange ............................................ 320 Información adicional ..................................................................................................... 327 Registro de protocolos, registro de sucesos y seguimiento de mensajes ........................... 327 Registro de protocolo ..................................................................................................... 328 Registro de sucesos ...................................................................................................... 329 Registro de ingeniería de campo .................................................................................... 329 Seguimiento de mensajes .............................................................................................. 330 Cómo habilitar el registro de diagnósticos para el servicio SMTP en el Administrador del sistema de Exchange..................................................................................................... 330 Antes de empezar.......................................................................................................... 331 Procedimiento................................................................................................................ 331 Cómo establecer el nivel de registro de diagnósticos para las categorías de MSExchangeTransport en Ingeniería de campo ............................................................. 331 Antes de empezar.......................................................................................................... 332 Procedimiento................................................................................................................ 332 Para más información .................................................................................................... 332 Cómo habilitar el seguimiento de mensajes en el Administrador del sistema de Exchange 333 Antes de empezar.......................................................................................................... 333

Procedimiento................................................................................................................ 333 Referencia ..................................................................................................................... 334 Arquitectura de transporte X.400 ....................................................................................... 334 MTA de Exchange en la arquitectura de Exchange Server 2003........................................ 335 Socios de comunicación del MTA de Exchange ............................................................. 336 Opciones de configuración del MTA de Exchange en Active Directory ........................... 339 Arquitectura interna del MTA de Exchange .................................................................... 344 Base de datos del MTA de Exchange ............................................................................ 348 Cambio de ubicación del directorio de la base de datos del MTA ................................... 351 Copias de mensajes protegidos y no protegidos ............................................................ 352 Base de datos del MTA en un clúster de servidores ....................................................... 353 Mensajes dañados en las colas de puerta de enlace ...................................................... 353 Corrección de daños en la base de datos del MTA......................................................... 355 Barrido de la base de datos del MTA ............................................................................. 355 Reproducción de archivos DAT ...................................................................................... 356 Examen del proceso del MTA de Exchange ................................................................... 356 Comprobación del MTA de Exchange mediante el Monitor del sistema .......................... 357 Registro de sucesos del MTA de Exchange ................................................................... 361 Registro de sucesos de texto ......................................................................................... 366 Registro del nivel de seguimiento ................................................................................... 366 Registro de comprobación del MTA ............................................................................... 367 Id. de objeto e Id. de mensaje ........................................................................................ 367 Cómo realizar un barrido de la base de datos del MTA ...................................................... 368 Antes de empezar.......................................................................................................... 368 Procedimiento................................................................................................................ 369 Para obtener más información ....................................................................................... 369 Cómo reproducir archivos DAT después de un barrido de la base de datos del MTA ......... 370 Antes de empezar.......................................................................................................... 370 Procedimiento................................................................................................................ 370 Referencia ..................................................................................................................... 370 Cómo reproducir archivos DAT después de un barrido de la base de datos del MTA mediante una reproducción completa ............................................................................................ 371 Antes de empezar.......................................................................................................... 371 Procedimiento................................................................................................................ 371 Para más información .................................................................................................... 372 Cómo reproducir archivos DAT después de un barrido de la base de datos del MTA mediante una reproducción remota ............................................................................................... 373 Antes de empezar.......................................................................................................... 373 Procedimiento................................................................................................................ 374

Para más información .................................................................................................... 375 Cómo reproducir archivos DAT después de un barrido de la base de datos del MTA mediante una reproducción incremental ........................................................................................ 375 Antes de empezar.......................................................................................................... 375 Procedimiento................................................................................................................ 376 Para más información .................................................................................................... 377 Pilas de transporte del MTA y conectores X.400 ............................................................... 377 Servicio de transferencia de mensajes ........................................................................... 379 Servicio de transferencia confiable ................................................................................. 384 Servicio de control de asociaciones ............................................................................... 386 Servicios de presentación y sesión ................................................................................ 388 Pilas de transporte del MTA ........................................................................................... 389 Ejemplo de comunicación MTA ...................................................................................... 393 Conectores X.400 .......................................................................................................... 394 Configuración de un conector X.400 .............................................................................. 394 Información de solicitud de conexión.............................................................................. 396 Información entrante y saliente de la dirección OSI ........................................................ 397 Direcciones X.400.......................................................................................................... 397 Espacios de direcciones X.400 ...................................................................................... 399 Año de conformidad y partes del cuerpo ........................................................................ 400 Detección de bucles de mensaje .................................................................................... 402 Objetos del conector X.400 en Active Directory .............................................................. 405 Ejecución de varios conectores X.400 ............................................................................ 410 Conexión de grupos de enrutamiento mediante conectores X.400 ..................................... 412 Equilibrio de carga entre grupos de enrutamiento .......................................................... 413 Enrutamiento de mensajes mediante los MTA de Exchange .......................................... 414 Puerta de enlace XAPI SMTP ........................................................................................ 414 Transferencia de mensajes del MTA de Exchange ......................................................... 416 Información de estado de vínculos y Redireccionamiento de mensajes .......................... 418 Intercambio de información de estado de vínculos entre los grupos de enrutamiento ..... 419 MTA de Exchange en una organización en modo mixto .................................................... 420 Comunicación MTA basada en RPC .............................................................................. 421 Impacto sobre el rendimiento de RPC ............................................................................ 422 Error de restablecimiento de enlace RPC ....................................................................... 423 Tabla de enrutamiento de direcciones de la puerta de enlace ........................................ 424 Bucles de mensajes entre Exchange Server 5.5 y Exchange Server 2003 ..................... 425 Arquitectura de los conectores de mensajería de puerta de enlace ................................... 426 Arquitectura del conector de EDK ..................................................................................... 427 Componentes de los conectores .................................................................................... 429

Transferencia de mensajes de y a Exchange Server 2003 ............................................. 437 Transferencia de mensajes salientes ............................................................................. 438 Transferencia de mensajes entrantes ............................................................................ 439 Perfiles MAPI para conectores basados en MAPI .......................................................... 439 Conversión de mensajes................................................................................................ 441 Traducción de direcciones ............................................................................................. 442 Direcciones proxy y direcciones de uso único ................................................................ 444 Problemas de asignación de direcciones ....................................................................... 444 Conversión de mensajes................................................................................................ 445 Sincronización de directorios ......................................................................................... 447 Sincronización de directorios de un sistema de mensajería que no es de Exchange con una organización de Exchange ................................................................................... 447 Sincronización de directorios de una organización de Exchange con un sistema de mensajería que no es de Exchange ............................................................................ 449 Cómo abrir un buzón del conector con Mdbvu32.exe ........................................................ 451 Antes de empezar.......................................................................................................... 451 Procedimiento................................................................................................................ 451 Arquitectura del Conector para Lotus Notes ...................................................................... 452 Transferencia de mensajes ............................................................................................ 459 Conversión de mensajes................................................................................................ 460 Conversión del tipo de mensaje de correo electrónico .................................................... 463 Asignación de propiedades de mensajes de correo electrónico ...................................... 463 Sincronización de directorios ......................................................................................... 465 Arquitectura del Conector para Novell GroupWise ............................................................. 467 Transferencia de mensajes ............................................................................................ 474 Conversión de mensajes................................................................................................ 477 Conversión del tipo de mensaje de correo electrónico .................................................... 479 Conversión de propiedades de mensajes de correo electrónico ..................................... 480 Sincronización de directorios ......................................................................................... 481 Arquitectura del Conector de calendario ............................................................................ 484 Información de disponibilidad ......................................................................................... 484 Publicación de datos de disponibilidad ........................................................................... 485 Mensajes de disponibilidad ............................................................................................ 485 Generación de datos de disponibilidad ........................................................................... 486 Publicación de disponibilidad en Outlook ....................................................................... 486 Publicación de disponibilidad en Outlook Web Access y Outlook Mobile Access ............ 488 Búsqueda de datos de disponibilidad ............................................................................. 489 Agente de publicación de disponibilidad (MadFB) .......................................................... 490 Limpieza de datos de disponibilidad ............................................................................... 490 Modificador de inicio de Outlook .................................................................................... 491 Limpieza mediante Outlook Web Access ....................................................................... 491

Componentes del Conector de calendario ...................................................................... 492 Búsquedas de disponibilidad hacia y desde Lotus Notes ................................................ 497 Búsquedas de disponibilidad desde Exchange 2003 ...................................................... 498 Búsquedas de disponibilidad desde Lotus Notes............................................................ 499 Búsquedas de disponibilidad hacia y desde Novell GroupWise ...................................... 500 Búsquedas de disponibilidad desde Novell GroupWise .................................................. 503 Cómo comprobar si un servidor en el que se ejecuta Exchange Server contiene una réplica de la carpeta del sistema de disponibilidad para el grupo administrativo......................... 504 Antes de empezar.......................................................................................................... 504 Procedimiento................................................................................................................ 505 Servidores virtuales de protocolos de Exchange Server 2003 ............................................ 505 Integración con IIS ............................................................................................................ 506 Examen de la comunicación entre procesos entre IIS y el servicio Almacén de información de Microsoft Exchange ............................................................................................... 507 Sistema de archivos instalable de Exchange .................................................................. 508 Mensajes entrantes ....................................................................................................... 509 Mensajes salientes ........................................................................................................ 510 Semántica del sistema de archivos ................................................................................ 510 Herramienta de enlace de ExIPC ................................................................................... 510 Códigos auxiliares de protocolo de ExIPC ...................................................................... 511 MAPI y RPC a través de HTTP ......................................................................................... 511 RPC a través de HTTP .................................................................................................. 511 Directorio virtual de RPC................................................................................................ 513 RPC a través de HTTP y el servicio Almacén de información de Microsoft Exchange ..... 513 Detalles de los protocolos de Internet ................................................................................ 514 HTTP ............................................................................................................................. 514 WebDAV y XML ............................................................................................................. 516 POP3............................................................................................................................. 516 IMAP4 ........................................................................................................................... 519 NNTP ............................................................................................................................ 523 Opciones de configuración en Active Directory............................................................... 524 Opciones de configuración en la metabase .................................................................... 524 Actualizaciones de la metabase de IIS mediante DS2MB ............................................... 525 Marcas de agua máxima ................................................................................................ 525 Arquitectura del servidor de aplicaciones para el usuario ............................................... 526 Consideraciones acerca del uso de servidores de aplicaciones para el usuario .............. 527 Exchange ActiveSync y Exchange 2003 ............................................................................ 528 Arquitectura del protocolo Exchange ActiveSync ............................................................ 528 Versiones del protocolo de sincronización y compatibilidad con dispositivos .................. 530

Comandos del protocolo de sincronización .................................................................... 531 Formato del comando de sincronización ........................................................................ 531 URI ................................................................................................................................ 531 Encabezado HTTP ........................................................................................................ 532 Cuerpo HTTP ................................................................................................................ 532 Los datos de multidifusión independientes de protocolo se almacenan en "colecciones":533 Perfil de Exchange ActiveSync ...................................................................................... 533 Notificaciones de actualización ...................................................................................... 533 Agregadores .................................................................................................................. 534 Outlook Mobile Access y Exchange 2003 .......................................................................... 534 Dependencias de Outlook Mobile Access ...................................................................... 535 Outlook Mobile Access y .NET ....................................................................................... 535 .NET Framework............................................................................................................ 536 ASP.NET ....................................................................................................................... 536 Administración de sesiones............................................................................................ 537 Id. de sesión de URL modificada .................................................................................... 537 Actualizaciones de dispositivos de ASP.NET ................................................................. 537 Arquitectura de Outlook Mobile Access .......................................................................... 538 Plantillas de Outlook Mobile Access y Microsoft Outlook Web Access ............................ 538 Orígenes de datos de Outlook Mobile Access ................................................................ 539 Configuración de directorios de Outlook Mobile Access ................................................. 540 Outlook Mobile Access y DS2MB ................................................................................... 542 Outlook Mobile Access y el Registro de Windows .......................................................... 542 Outlook Mobile Access y Web.Config ............................................................................. 544 Solicitudes del cliente de Outlook Mobile Access ........................................................... 546 Arquitectura de seguridad de Outlook Mobile Access ..................................................... 547 Arquitectura del servicio Almacén de información de Exchange ........................................ 547 Arquitectura de almacenamiento de Exchange .................................................................. 548 Grupos de almacenamiento ........................................................................................... 550 Arquitectura de los grupos de almacenamiento .............................................................. 550 Atributos del grupo de almacenamiento en Active Directory ........................................... 553 Requisitos de espacio mínimo en disco de los grupos de almacenamiento .................... 555 Bases de datos del almacén de Exchange ..................................................................... 556 Archivo de base de datos MAPI ..................................................................................... 556 Archivo de base de datos de secuencias ....................................................................... 557 Promoción de propiedades ............................................................................................ 557 Configuración y administración del límite del tamaño de la base de datos ......................... 558 Configuración del Registro ............................................................................................. 559 Límite de tamaño de la base de datos en GB ................................................................. 560 Advertencia de búfer de tamaño de la base de datos en porcentaje ............................... 560

Hora de inicio de comprobación de tamaño de la base de datos en horas desde la medianoche ................................................................................................................ 561 Comportamiento cuando se alcanza el límite de tamaño configurado de la base de datos o el establecido en la licencia ........................................................................................ 562 Límite de tamaño de la base de datos establecido en la licencia .................................... 562 Consideraciones sobre el diseño de recuperación de desastres ..................................... 563 Arquitectura del Motor de almacenamiento extensible ....................................................... 563 Transacciones ............................................................................................................... 564 Transacciones ACID ...................................................................................................... 564 El almacén de versiones ................................................................................................ 565 Aislamiento de instantáneas .......................................................................................... 566 Estructura de la base de datos de ESE .......................................................................... 566 Páginas de base de datos.............................................................................................. 566 Suma de comprobación de ECC .................................................................................... 567 Coherencia de la base de datos y errores -1018 ............................................................ 568 Equilibrio del árbol de base de datos.............................................................................. 570 División .......................................................................................................................... 571 Combinación.................................................................................................................. 571 Despliegue .................................................................................................................... 571 Índices ........................................................................................................................... 571 Valores largos ................................................................................................................ 572 Formato de registros ...................................................................................................... 572 Tipos de datos de columna ............................................................................................ 572 Columnas fijas y variables ............................................................................................. 574 Columnas etiquetadas ................................................................................................... 574 Responsabilidades del almacén de información ................................................................ 574 Interacción con otros servicios de Exchange .................................................................. 574 Administración del espacio ............................................................................................ 576 Desfragmentación de la base de datos .......................................................................... 576 Administración del búfer................................................................................................. 577 Asignación dinámica de búfer ........................................................................................ 577 El algoritmo de sustitución LRU-K .................................................................................. 578 Replicación de carpetas públicas ...................................................................................... 579 Árboles de base de datos de carpetas públicas .............................................................. 579 Introducción a la replicación ........................................................................................... 580 Empaquetado y desempaquetado .................................................................................. 581 Números de cambio ....................................................................................................... 581 Tipos de mensajes de replicación .................................................................................. 581 Proceso de replicación ................................................................................................... 587 Replicación de jerarquías ............................................................................................... 587 Replicación de contenido ............................................................................................... 588

Reposición ..................................................................................................................... 588 Matriz de reposición ....................................................................................................... 589 Estado de la replicación ................................................................................................. 589 Subproceso de estado de replicación............................................................................. 590 Solicitudes de estado de replicación .............................................................................. 590 Modificación de la lista de réplicas ................................................................................. 591 Agregar una réplica ....................................................................................................... 591 Eliminar una réplica ....................................................................................................... 592 Tablas de estado de replicación ..................................................................................... 592 Programación de sucesos de replicación predeterminados ............................................ 593 Valores de replicación predeterminados ......................................................................... 595 Arquitectura de clústeres de Exchange Server 2003.......................................................... 596 Arquitectura de clústeres de Windows ............................................................................... 598 Clústeres de servidores ................................................................................................. 598 Arquitectura de clústeres de servidor ............................................................................. 599 Componentes del servicio de Cluster Server .................................................................. 600 Conmutación por errores de clúster ............................................................................... 606 Conmutación por recuperación del clúster ..................................................................... 607 Quórum de clúster ......................................................................................................... 607 Quórum estándar ........................................................................................................... 608 Quórums de conjunto de nodos mayoritario ................................................................... 608 Recursos de clúster ....................................................................................................... 609 Administración del clúster .............................................................................................. 610 Formación y operaciones del clúster .............................................................................. 610 Creación de un clúster ................................................................................................... 610 Formación de un clúster................................................................................................. 611 Unión a un clúster .......................................................................................................... 612 Abandono de un clúster ................................................................................................. 612 Detección de errores...................................................................................................... 613 Servidores virtuales de Exchange ..................................................................................... 614 Componentes de Exchange en un clúster ...................................................................... 615 Clústeres activo/activo ................................................................................................... 617 Clústeres activo/pasivo .................................................................................................. 618 Dependencias de recursos ............................................................................................ 619 Servicio Operador de sistema de Microsoft Exchange .................................................... 619 Servicio Almacén de información de Microsoft Exchange ............................................... 620 Agente de transferencia de mensajes ............................................................................ 620 Protocolos ..................................................................................................................... 621 Microsoft Search ............................................................................................................ 621 Interacción de clústeres de Exchange ............................................................................... 621 Funciones ExchangeOpen/ExchangeClose.................................................................... 622

Funciones ExchangeOnline y ExchangeOffline .............................................................. 623 ExchangeIsAlive y ExchangeLooksAlive ........................................................................ 624 ExchangeTerminate ....................................................................................................... 624 Creación de recursos ..................................................................................................... 624 Configuraciones específicas del clúster ............................................................................. 624 MTA de Exchange ......................................................................................................... 625 Registro SMTP de IIS .................................................................................................... 625 AntiAffinityClassNames .................................................................................................. 625 Almacenes públicos MAPI ............................................................................................. 627 Eseutil ........................................................................................................................... 627 Instalación de actualizaciones ........................................................................................ 627 How to Disable MTA Monitoring on an Exchange Virtual Server ........................................ 628 Antes de empezar.......................................................................................................... 628 Procedimiento................................................................................................................ 628 How to Enable SMTP Logging and Log the Files to a Shared Disk .................................... 629 Antes de empezar.......................................................................................................... 629 Procedimiento................................................................................................................ 629 How to Create an HTTP Virtual Server in Exchange System Manager ............................... 630 Antes de empezar.......................................................................................................... 630 Procedimiento................................................................................................................ 630 How to Create Virtual Directories for an Exchange Virtual Server in a Windows Server Cluster ...................................................................................................................................... 632 Antes de empezar.......................................................................................................... 632 Procedimiento................................................................................................................ 632 Información adicional ..................................................................................................... 634 How to Create an HTTP Virtual Server Resource for an Exchange Virtual Server in a Windows Server Cluster................................................................................................. 634 Antes de empezar.......................................................................................................... 634 Procedimiento................................................................................................................ 634 Copyright .......................................................................................................................... 635

17

Guía de referencia técnica ?de ?de Exchange Server 2003 Esta guía de referencia técnica presenta una visión de la arquitectura del sistema de Microsoft® Exchange Server 2003. Incluye una introducción al diseño del sistema de mensajería de Exchange Server 2003, además de detalles más espec específicos, íficos, como las dependencias de servicios, la integración con el servicio de directorios Active Directory®, la arquitectura del Administrador del sistema de Exchange, la arquitectura de enrutamiento, la de transporte SMTP, la de X.400, la arquitectura del almacén de Exchange y la de clústeres. Esta información le ayudará a diseñar, mantener y solucionar los problemas de una organización de Exchange, así como a desarrollar soluciones personalizadas para los administradores. Esta detallada guía de referenci referencia a no está dirigida a los administradores principiantes y no muestra cómo implementar ni mantener Exchange Server 2003. En su lugar, esta guía está dirigida a los Ingenieros de sistemas certificados de Microsoft (MSCE) y a los expertos de Exchange Server que e desean ampliar sus conocimientos de Exchange Server 2003. Nota: Descargue la Guía de referencia técnica de Microsoft Exchange Server 2003 para imprimir o leer el archivo sin conexión.

Introducción ión a la Guía de referencia técnica de Exchange Server 2003 La Guía de referencia técnica de Microsoft Exchange Server 2003 está dirigida a los expertos que necesitan información detallada acerca de la arquitectura y la integración entre los componentes principales incipales de Microsoft Exchange Server 2003. Contenido de esta guía

Contenido de esta guía Esta guía de referencia técnica presenta una visión de la arquitectura del sistema de Exchange Server 2003. Incluye una descripción general del diseño del sistema de mensajería de Exchange Server 2003, además de detalles más específicos, como las dependencias ias de servicios, la integración con el servicio de directorios de Active Directory, la arquitectura del Administrador del sistema de Exchange, la arquitectura de enrutamiento, la de transporte SMTP, la de X.400, la del almacén de Exchange y la de clústeres. clústere Esta información le ayudará a diseñar, mantener y solucionar los problemas de una organización de Exchange, así como a desarrollar soluciones personalizadas para los administradores.

18

Esta detallada guía de referencia no está dirigida a administradores principiantes y no muestra cómo implementar o mantener Exchange Server 2003. En cambio, esta guía está dirigida a los Ingenieros de sistemas certificados de Microsoft (MSCE) y a los expertos de Exchange que desean ampliar sus conocimientos de Exchange Server 2003. Consulte "¿Qué debe leer primero?" más adelante en esta introducción para ver una lista de libros que podría interesarle estudiar antes de leer esta guía de referencia técnica. Esta guía de referencia técnica está estructurada de acuerdo con los componentes clave de Exchange Server 2003, para que pueda elegir el capítulo que le interese. Por ejemplo, si está solucionando problemas de comunicaciones de Active Directory, vaya a Exchange Server 2003 y Active Directory o bien, si tiene problemas con el servicio SMTP, vaya a Arquitectura de transporte SMTP. En esta guía se recogen respuestas detalladas a los siguientes interrogantes: •

¿En qué se parece y se diferencia la arquitectura de Exchange Server 2003 de la arquitectura general de un sistema de mensajería de cliente-servidor?

•

¿Cómo se integran los diversos componentes de Exchange Server 2003 en el sistema operativo?

•

¿Cuáles son las dependencias de servicios de cada componente de Exchange Server 2003?

•

¿Qué componentes de Exchange Server 2003 se comunican con Active Directory y en qué situaciones?

•

¿Con qué tipos de controladores de dominio se comunica Exchange Server 2003, y con qué motivo?

•

¿Cuáles son los componentes y las dependencias de comunicaciones del Administrador del sistema de Exchange?

•

¿Cómo trata Exchange Server 2003 la transferencia y enrutamiento de mensajes?

•

¿Cuáles son los componentes internos del servicio de Protocolo simple de transferencia de correo (SMTP) que Exchange Server 2003 sustituye o extiende para implementar funcionalidad específica de Exchange?

•

¿Cómo se comunica exactamente el servicio SMTP con el almacén de Exchange para la transferencia de mensajes entrantes y salientes?

•

¿Cuál es la función del agente de transferencia de mensajes (MTA) de Exchange en la arquitectura de transferencia de mensajes?

•

¿Cuáles son las implicaciones técnicas de la implementación de una red troncal de mensajería de X.400 en una organización de Exchange Server 2003?

•

¿Qué tipo de conectividad ofrece Exchange Server 2003 a sistemas de mensajería que no son de Exchange, como Lotus Notes y Novell GroupWise?

•

¿Cuál es la arquitectura general de los conectores del Kit de desarrollo de software de Exchange (EDK)?

•

¿Qué tipo de compatibilidad ofrece Exchange Server 2003 con clientes de mensajería de Internet?

19

•

¿Cuál es la arquitectura del Motor de almacenamiento extensible (ESE) que utiliza Exchange Server 2003 para mantener el almacén de Exchange?

•

¿Cuáles son las responsabilidades del almacén de Exchange?

•

¿Cómo replica Exchange Server 2003 las carpetas públicas entre servidores de la misma organización de Exchange?

•

¿Qué componentes le permiten implementar Exchange Server 2003 en un clúster de servidor?, y ¿cómo se integra Exchange Server 2003 en la arquitectura del Servicio de Cluster Server de Microsoft Windows?

A quién va dirigida esta guía Esta guía contiene información valiosa para los lectores que deseen saber más sobre Exchange Server 2003. Como se mencionó anteriormente, esta guía está dirigida a los consultores de mensajería avanzados, arquitectos de sistemas, administradores y personal técnico a cargo de solución de problemas que ya sean expertos en Exchange. Un conocimiento técnico detallado permitirá a estos expertos en Exchange implementar soluciones que sobrepasan las capacidades estándar del producto o solucionar cuellos de botella y otros problemas. Esta guía se ha diseñado para los siguientes tipos de expertos en Exchange: •

Arquitectos de IT, que diseñan e implementan Exchange Server 2003.

•

Los consultores de IT que ayudan a los clientes que implementan y mantienen organizaciones de Exchange Server 2003.

•

Los administradores de mensajería que dirigen una organización de Exchange Server 2003.

•

Los administradores del sistema que solucionan problemas en sistemas de mensajería.

•

Los desarrolladores de sistemas que crean soluciones de mensajería que sobrepasan las capacidades estándar de Exchange Server 2003.

¿Qué debe leer primero? Los lectores que no estén familiarizados con Exchange Server 2003 deben leer la documentación de producto de Windows, Microsoft Office Outlook y Exchange, además de los libros en línea de Exchange, antes de leer esta guía. La documentación de Exchange se encuentra disponible en la Exchange Server TechCenter. La Guía de referencia técnica de Exchange Server 2003 presupone que ha leído los libros siguientes: •

Planning an Exchange Server 2003 Messaging System En este libro se describen Exchange Server 2003 y las tecnologías de mensajería relacionadas a un alto nivel, incluidas sus características y limitaciones.

20

•

Exchange Server 2003 Deployment Guide Este libro contiene información sobre instalación y implementación para administradores con experiencia media y avanzada que planeen implementar Exchange Server 2003.

•

Exchange Server 2003 Administration Guide En este libro se abordan los conceptos básicos de la administración de Exchange Server 2003.

•

Exchange Server 2003 Interoperability and Migration Guide Este libro le guía en el proceso para determinar una estrategia eficaz para pasar de plataformas de mensajería habituales que no son de Exchange, como Lotus Notes y Domino, Novell GroupWise y otros sistemas de mensajería, a Exchange Server 2003.

Introducción a la Biblioteca técnica de Exchange Server 2003 Microsoft Exchange Server 2003, como plataforma de servidores de mensajería, comparte las siguientes características comunes con otros sistemas de correo electrónico: •

Transfiere mensajes de correo electrónico a sus correspondientes destinatarios de manera confiable, ya se encuentren los destinatarios en el servidor local, en otro servidor de la misma organización de Exchange Server 2003 o en otro servidor de un entorno de mensajería externo que esté conectado a la organización.

•

Almacena los mensajes de correo electrónico en un almacén de servidor.

•

Admite diversos clientes de correo electrónico que se utilizan para tener acceso a los mensajes o descargarlos.

•

Proporciona a los usuarios información acerca de los destinatarios de la organización mediante una libreta de direcciones o una lista global de direcciones.

Exchange Server 2003 incluye estas características y muchas otras. Sin embargo, no las proporciona directamente. Exchange Server 2003 se integra de forma muy estrecha con la infraestructura de TCP/IP que ofrece Microsoft Windows Server 2003 y el servicio de directorios de Active Directory. Para comprender la arquitectura de Exchange Server 2003, debe comprender en primer lugar las tecnologías relacionadas con TCP/IP, Microsoft Windows Server 2003 y Active Directory. Además, debe estar familiarizado con los siguientes conceptos generales de mensajería: •

Características de los sistemas de mensajeríaIncluye información para comprender los componentes habituales de un sistema de mensajería y del flujo básico de mensajes entre servidores.

•

Integración de Active Directory con Exchange Server 2003 Incluye información para comprender de qué manera Exchange Server 2003 utiliza Active Directory para implementar la infraestructura de directorios necesaria.

•

Conectividad de mensajería Incluye información para comprender cómo transfiere mensajes Exchange Server 2003 de los remitentes a los destinatarios.

21

•

Almacén de mensajes Incluye información para comprender la función y la finalidad del almacén de mensajes en un sistema de mensajería.

•

Clientes de correo electrónico admitidos Incluye información para comprender los diversos clientes y protocolos de acceso a mensajes que se pueden utilizar en una organización de Exchange Server 2003.

Esta sección le proporciona una base para posteriores temas de esta referencia técnica. Para obtener el máximo resultado de esta guía, debe estar familiarizado con las tecnologías de Windows Server 2003. Para obtener más información acerca de Windows Server 2003, consulte los Centros tecnológicos de Windows Server 2003.

Exchange Server 2003 como sistema de tratamiento de mensajes Todos los entornos de mensajería comparten algunos requisitos habituales. Como mínimo, todos los sistemas de mensajería de un entorno de mensajería requieren lo siguiente: •

Un mecanismo para el transporte de mensajes

•

Una lista de todos los usuarios del sistema de mensajería

•

Un lugar donde almacenar los mensajes hasta que el cliente los recupere

•

Una interfaz que los clientes de correo electrónico puedan utilizar para comunicarse con un servidor del entorno de mensajería

Componentes generales de un sistema de tratamiento de mensajes La figura siguiente ilustra los componentes de un sistema de tratamiento de mensajes. Componentes de un sistema de tratamiento de mensajes

Exchange Server 2003 implementa los siguientes componentes de mensajería:

22

•

Directorio El directorio contiene información de los usuarios del sistema. Esta información se utiliza para entregar mensajes a sus correspondientes destinatarios. El directorio almacena asimismo la mayoría de la información de configuración relativa al sistema de tratamiento de mensajes. Incluye información sobre cómo está configurado el sistema y cómo enrutar mensajes de un servidor de mensajería a otro. En Exchange Server 2003, Active Directory proporciona el directorio. Muchos componentes de Exchange Server 2003 utilizan un módulo de acceso al directorio, conocido como DSAccess, para poder comunicarse con Active Directory. Para obtener más información acerca de la estructura de directorios de Exchange Server 2003, consulte Exchange Server 2003 y Active Directory.

•

Subsistema de transferencia de mensajes Este componente implementa un mecanismo de enrutamiento y de transferencia para los mensajes de correo electrónico. El mensaje puede estar dirigido a destinatarios del mismo servidor o de otro servidor de la misma organización, o bien a destinatarios de Internet o de otros sistemas de mensajería. El motor de transporte central de Exchange Server 2003 es el motor de transporte de Protocolo simple de transferencia de correo (SMTP), que se implementa en el servicio SMTP que se incluye originalmente con Windows Server 2003. Exchange Server 2003 extiende el servicio SMTP para implementar las características de tratamiento de mensajes que necesita. Observe que la transferencia de mensajes en Exchange Server 2003 depende completamente del motor de transporte SMTP, incluso si el remitente y el destinatario se encuentran en el mismo servidor. Para obtener más información acerca del motor de transporte SMTP, consulte Arquitectura de transporte SMTP.

•

Almacén de mensajes En Exchange Server 2003, el almacén de mensajes (es decir, el almacén de Exchange) almacena los mensajes de correo electrónico y otros elementos en los buzones y carpetas públicas. También contiene tablas de mensajes que el subsistema de transferencia utiliza para almacenar mensajes temporalmente cuando estos se enrutan de un servidor a otro. El almacén de Exchange utiliza la tecnología de Motor de almacenamiento extensible (ESE) para implementar las bases de datos de mensajería. Para obtener más información acerca de la arquitectura de almacén de Exchange, consulte Arquitectura del servicio Almacén de información de Exchange.

•

Agente de usuario El agente de usuario proporciona acceso al sistema de mensajería. En otras palabras, el agente de usuario es el cliente de mensajería. Exchange Server 2003 admite una gran variedad de clientes de mensajería, como los clientes MAPI, clientes HTTP y los clientes que utilizan POP3, IMAP4 y el Protocolo de transferencia de noticias a través de la red (NNTP). Por otro lado, Active Directory proporciona compatibilidad con el Protocolo compacto de acceso a directorios (LDAP) para las búsquedas de directorios.

23

El sistema de tratamiento de mensajes en la infraestructura de red Para transferir un mensaje de un servidor a otro de la organización de Exchange Server 2003, la red debe admitir el protocolo TCP/IP. Tanto Active Directory como el servicio SMTP requieren dicho protocolo. La figura siguiente ilustra los componentes necesarios para la comunicación del sistema y la transferencia de mensajes. Debe tener en cuenta que los componentes específicos, como el Conector para Novell GroupWise, pueden requerir componentes adicionales que no se muestran en esta figura. Componentes de red para Exchange Server 2003

Exchange Server 2003 requiere los siguientes componentes de red: •

IP y TCP Exchange Server 2003 requiere el protocolo TCP/IP para comunicarse con otros equipos de la red. Exchange Server 2003 no admite otros protocolos de red.

•

DNS Exchange Server 2003 requiere DNS para poder resolver las direcciones IP de otros hosts de una red TCP/IP, ubicar controladores de dominio y servidores de catálogo de un dominio de Active Directory y ubicar servidores de correo electrónico en otras organizaciones de mensajería.

•

DHCP y WINS Exchange Server 2003 no necesita el Protocolo de configuración dinámica de host (DHCP) para funcionar. Sin embargo, es posible que algunos clientes de red de la red TCP/IP necesiten este servicio. DHCP se utiliza para asignar de manera automática una dirección IP a los equipos de una red. El Servicio de nombres Internet de Windows (WINS), por otra parte, es utilizado por los clientes de Microsoft Windows para realizar resoluciones de nombres NetBIOS. En entornos de red que contienen enrutadores que no reenvían redifusiones en segmentos de red, se requiere WINS para poder resolver las direcciones IP de otros equipos de la red. Exchange Server 2003 requiere WINS.

24

•

Sockets de Windows Exchange Server 2003 utiliza Windows Sockets para ofrecer puntos de conexión para clientes de red que se conecten a los servicios de un servidor. Un socket de Windows es una dirección IP de host combinada con un número de puerto que se usa para identificar un servicio del servidor.

•

Active Directory Active Directory proporciona el servicio de directorio para Exchange Server 2003.

•

Servicios de Internet Information Server (IIS) Exchange Server 2003 requiere IIS para poder proporcionar compatibilidad con el protocolo de Internet. Todos los servicios de protocolo de Internet, como HTTP, SMTP o IMAP4, se ejecutan dentro del entorno de procesamiento de IIS del servidor de Exchange. Para obtener más información sobre IIS, consulte Servicios de Internet Information Server.

•

Subsistema de seguridad Exchange Server 2003 utiliza un subsistema de seguridad de Windows Server 2003 para autenticar a los usuarios de la organización de Exchange. El subsistema de seguridad se asegura de que únicamente los usuarios autorizados puedan tener acceso a los buzones o enviar correo electrónico a los destinatarios especificados.

•

Administrador de E/S de Windows El Administrador de E/S del servidor que ejecuta Exchange Server administra la transferencia de datos entre los discos duros del servidor. Exchange Server 2003 utiliza el Administrador de E/S para tener acceso a los registros de transacciones y a las bases de datos que se almacenan en el disco duro del servidor. El Administrador de E/S controla asimismo los sistemas de archivos de la red, como servidor y cliente de las redes de Microsoft. Exchange Server 2003 comparte diversas carpetas de sistemas de archivos para el acceso a la red y tiene acceso a estas carpetas a través del sistema de archivos de la red de Microsoft.

Integración de directorios La información de Exchange Server 2003 en Active Directory incluye información de los destinatarios del sistema de mensajería, así como información de configuración relacionada con la organización de mensajería. Asimismo, Active Directory proporciona el subsistema de seguridad para Exchange Server 2003. La seguridad de Active Directory asegura que únicamente los usuarios autorizados puedan tener acceso a los buzones y que únicamente los administradores autorizados puedan modificar la configuración de Exchange de la organización.

Objetos de destinatario del directorio Los destinatarios de una organización de Exchange Server 2003 se representan mediante objetos de destinatario en Active Directory. Una organización de Exchange Server 2003 contiene los cinco tipos de objetos de destinatario siguientes:

25

•

Cuentas de usuario con buzón habilitado Un usuario con buzón habilitado es el objeto de destinatario más habitual en una organización de Exchange Server Ser 2003. Un usuario con buzón habilitado es un usuario de Windows con un buzón en un servidor de Exchange Server. Una cuenta de usuario con buzón habilitado es un objeto de Active Directory que tiene asignado un identificador de seguridad exclusivo (SID). Este identificador permite al usuario tener acceso a los recursos del dominio de Active Directory. Cuando una cuenta de usuario tiene un buzón habilitado, dispone de un buzón en un servidor que ejecuta Exchange Server, lo que permite al usuario enviar y recibir r mensajes de correo electrónico utilizando un cliente admitido, como Microsoft Office Outlook.

•

Cuentas de usuariocon correo habilitado Un usuario con correo habilitado dispone de una dirección de correo electrónico pero no de un buzón en un serv servidor que ejecuta Exchange Server. Una cuenta de usuario con correo habilitado tiene un SID y puede obtener acceso a los recursos del dominio de Active Directory, pero la dirección de correo electrónico que se utiliza para habilitar el correo del usuario hace ha referencia a un buzón que se encuentra en un sistema de mensajería que no es de Exchange o que es externo. Las cuentas de usuario con correo habilitado aparecen enumeradas en la lista global de direcciones.

•

Contactos con correo habilitado Un contacto o con correo habilitado no dispone de un SID y por ello no tiene un buzón de Exchange en la organización de Exchange. Esto significa que un contacto con correo habilitado no puede tener acceso a los recursos del dominio, pero el objeto de destinatario está visible en la lista global de direcciones. Los mensajes de correo electrónico enviados a un contacto se enrutan a la dirección de correo electrónico asociada con el objeto de contacto.

•

Grupos con correo habilitado Un grupo con correo habilitado es una colección de usuarios, grupos y contactos que se han configurado con direcciones de correo electrónico. Tanto los grupos universales como los de seguridad pueden tener correo habilitado, pero se recomienda utilizar los grupos universales para fines de correo cor electrónico. Un grupo con correo habilitado a menudo recibe el nombre de lista de distribución, ya que se le asigna una dirección de correo. Cuando se envía un mensaje al grupo, Exchange Server 2003 amplía la pertenencia al grupo y entrega el mensaje a cada uno de los destinatarios. Exchange Server 2003 permite utilizar grupos de distribución basados en consultas, que son listas de distribución en las que la pertenencia a la misma está determinada por una consulta de Protocolo compacto de acceso a directorios torios (LDAP).

•

Carpetas públicas con correo habilitado Una carpeta pública con correo habilitado es una carpeta pública a la que se puede enviar mensajes de correo electrónico. Una carpeta pública con correo habilitado tiene una dirección de correo electrónico ele exclusiva y puede mostrarse en la lista global de direcciones. Nota: Los objetos de destinatario de Exchange se almacenan en la partición de dominio de Active Directory (a las particiones de Active Directory también se las conoce como

26

particiones de directorio). La partición de dominio contiene todos los objetos de un dominio específico y se replica a todos los controladores de dominio de ese dominio, pero sin ir más allá del mismo. La partición de dominio se muestra en la figura 1.3. Para obtener más información acerca de la replicación de la información de dominio, consulte la documentación del producto en los Windows Server 2003 Technology Centers.

Información de configuración del directorio Exchange Server 2003 almacena la mayoría de la información de configuración de la organización de Exchange en Active Directory. Active Directory contiene información detallada acerca de los objetos de servidor, los contenedores para grupos administrativos y de enrutamiento, y todos los conectores de Exchange. Esta información especifica cómo está configurado cada uno de los servidores de Exchange Server, el número de grupos de almacenamiento y almacenes en cada servidor y la configuración del servidor de Servicios de Internet Information Server (IIS). La información de configuración de Exchange se almacena en la partición del directorio de configuración de Active Directory. Parte de la información que se almacena en la partición de configuración se muestra en la figura siguiente. Debido a que Active Directory replica la partición de configuración entre todos los dominios del bosque, la organización de Exchange también se replica en todo el bosque. Sin embargo, la partición de configuración no puede replicarse fuera del bosque. Esto significa que una organización de Exchange no puede abarcar varios bosques. No obstante, es posible implementar topologías de varios bosques en una organización de Exchange. Para obtener más información acerca de las topologías de varios bosques de Exchange, consulte la Exchange Server 2003 Deployment Guide.

27

Ver información de Exchange en Active Directory mediante adsiedit.msc

Clases y atributos de Exchange en Active Directory Además de la información almacenada en las particiones de dominio y configuración, Exchange Server 2003 también almacena la información de la partición de esquema. El esquema de Active Directory define todas las clases de objetos que se pueden crear en el directorio, así como los atributos que se pueden asignar a cada uno de los objetos de la clase. Antes de que se pueda instalar un servidor de Exchange Server 2003 en un bosque, debe extenderse el esquema de Active Directory para que incluya objetos y atributos específicos de Exchange. En la figura anterior se muestran la partición de esquema de Active Directory y algunos objetos específicos de Exchange.

Arquitectura del acceso a directorios La conexión entre Exchange Server 2003 y Active Directory es crucial para lograr un funcionamiento confiable del servidor. Exchange Server 2003 utiliza los dos componentes principales siguientes para ubicar y comunicarse con los controladores de dominio de Active Directory: •

DSAccess Este componente controla el modo en que otros componentes de Exchange tienen acceso a Active Directory. DSAccess lee la topología de Active Directory, detecta los controladores de dominio y los servidores de catálogo global, y mantiene una lista de servidores de directorios válidos que son adecuados para ser utilizados por los

28

componentes de Exchange. Además, DSAccess contiene una caché de memoria, que disminuye la carga de Active Directory al reducir el número de solicitudes LDAP que los componentes individuales deben en enviar viar a los servidores de Active Directory. Por ejemplo, para enrutar mensajes, el proceso de transporte utiliza DSAccess para obtener información acerca de la organización de conectores. El motor de transporte SMTP utiliza también DSAccess para resolver la información de los destinatarios. Esto permite a los mensajes ser enrutados a los servidores en los que se encuentran los buzones. •

DSProxy Este componente proporciona un servicio de lista de direcciones para los clientes MAPI que ejecutan Outlook 2002 Service Release 1 (SR-1) 1) y versiones anteriores. La versión 5.5 de Exchange y anteriores implementaban un servicio de directorio para que los clientes pudieran ver la lista global de direcciones consultando al servidor de Exchange Server. En Exchange 2000 Server y Exchange Server 2003, DSProxy emula este servicio de libreta de direcciones. Nota: Proxy del servicio de directorio (DSProxy) remite Microsoft Outlook 2003 directamente a un servidor de catálogo global. A diferencia de versiones anteriores de Outlook, Outlook 2003 no requiere un componente de proxy de directorio en el propio servidor de Exchange Server.

Para obtener información detallada acerca de DSAccess, consulte Exchange Server 2003 y Active Directory.

El transporte de mensajes La finalidad principal de un sistema de tratamiento de mensajes es proporcionar un medio para transferir mensajes de un servidor de mensajería a otro. Esta transfer transferencia de mensajes puede producirse en el mismo servidor, entre servidores de Exchange Server 2003 de la misma organización, entre servidores de Exchange Server y hosts de Internet, o bien entre servidores de Exchange Server y sistemas de mensajería externo externos. s. En todos los casos, el motor de transporte de mensajes de Exchange Server 2003 proporciona el enrutamiento y la retransmisión de los mensajes de correo electrónico.

Arquitectura de enrutamiento de mensajes En una organización de Exchange Server 2003, todos dos los mensajes se enrutan a través de SMTP. Asimismo, todos los servidores de mensajería de Internet admiten este protocolo. Si un servidor de Exchange Server envía un mensaje a otro servidor de mensajería que sólo admite el protocolo de mensajería X.400, X.400, el componente SMTP de Exchange Server 2003 se encarga de enrutar el mensaje. Para lograr esta funcionalidad, el componente SMTP incluye varios subcomponentes. Los siguientes componentes intervienen en todas las transferencias de mensajes de un servidor de e Exchange Server 2003:

29

•

Servicio SMTP El servicio SMTP controla la comunicación SMTP entre los hosts y clientes SMTP remotos. Este servicio implementa los comandos del protocolo SMTP admitidos por Exchange Server 2003.

•

Controlador del almacén El controlador del almacén permite que el servicio SMTP se comunique con el almacén de Exchange con el fin de guardar mensajes que pasen por el servicio SMTP. El controlador del almacén también se encarga de la entrega de mensajes a los destinatarios locales.

•

Motor de cola avanzada El motor de cola avanzada ofrece una administración y lógica de cola para la entrega, enrutamiento y retransmisión de mensajes.

•

Categorizador El categorizador ofrece servicios de categorización para los mensajes entrantes y salientes. Este componente también se encarga de la expansión de listas de distribución mediante LDAP y Active Directory.

•

Motor de enrutamiento El motor de enrutamiento proporciona la lógica de enrutamiento necesaria para pasar mensajes salientes al conector de mensajería o servidor virtual SMTP correcto.

•

Administrador de colas El administrador de colas controla las colas de vínculos. Las colas de vínculos se utilizan para almacenar mensajes que están a la espera de ser transferidos al siguiente destino remoto.

Para obtener información detallada acerca de la arquitectura de enrutamiento de mensajes y las relaciones entre estos componentes, consulte Arquitectura de enrutamiento de mensajes.

Enrutamiento de mensajes con grupos de enrutamiento Exchange Server 2003 utiliza grupos de enrutamiento para administrar la entrega de mensajes en una organización de Exchange. Un grupo de enrutamiento es una colección de servidores de Exchange Server que están conectados por vínculos de red permanentes. La entrega de mensajes dentro de un mismo grupo de enrutamiento se caracteriza por lo siguiente: •

Todas las entregas de mensajes se realizan punto a punto Dentro de un mismo grupo de enrutamiento, los mensajes se entregan siempre desde el servidor de Exchange Server del remitente directamente al servidor de Exchange Server del destinatario. Los mensajes nunca se enrutan entre varios servidores.

•

Todas las entregas de mensajes entre servidores de Exchange Server 2003 utilizan SMTP Los servidores de Exchange Server 2003 utilizarán siempre SMTP para entregar mensajes a otros servidores de Exchange Server 2003 del mismo grupo de enrutamiento.

•

Los mensajes se entregan en cuanto se reciben No se puede programar la entrega de mensajes dentro de un mismo grupo de enrutamiento. Si uno de los servidores de Exchange Server de un grupo de enrutamiento no tiene conexión, los otros servidores de

30

Exchange Server del grupo de enrutamiento pondrán en cola en ese servidor sin conexión todos los mensajes que se deben enviar. •

La entrega de mensajes se configura automáticamente entre los servidores de Exchange Server 2003 del mismo grupo de enrutamiento No existe ninguna manera de que un administrador pueda modificar el flujo de mensajes dentro de un mismo grupo de enrutamiento.

En la figura siguiente se ilustra la entrega de mensajes dentro de un mismo grupo de enrutamiento. Enrutamiento de mensajes en un único grupo de enrutamiento

Exchange Server 2003 admite el uso de varios grupos de enrutamiento. La entrega de mensajes entre grupos de enrutamiento se caracteriza por lo siguiente: •

Los conectores de grupos de enrutamiento deben estar configurados entre los grupos de enrutamiento.

•

Todos los mensajes enviados entre grupos de enrutamiento fluyen por servidores de cabeza de puente de cada grupo de enrutamiento.

•

La entrega de mensajes entre grupos de enrutamiento se puede configurar. Entre las opciones de configuración se encuentran la programación de la entrega de mensajes, la limitación del tamaño de estos y la restricción de los usuarios o grupos a la hora de enviar mensajes a través del conector.

La figura siguiente ilustra el enrutamiento de mensajes entre varios grupos de enrutamiento.

31

Enrutamiento de mensajes entre varios grupos de enrutamiento

Exchange Server 2003 admite los tres grupos de enrutamiento siguientes: •

Conector para grupo de enrutamiento El conector de grupo de enrutamiento es el conector recomendado para conectar grupos de enrutamiento que estén en la misma organización de Exchange. Este conector utiliza SMTP para transferir mensajes a otros servidores de Exchange Server 2003. El conector para grupo de enrutamiento sólo puede utilizarse para conectar grupos de enrutamiento.

•

Conector SMTP El conector SMTP establece una ruta de mensajería entre dos grupos de enrutamiento o entre un grupo de enrutamiento y un host que no es de Exchange. Aunque el conector para grupo de enrutamiento y el conector SMTP utilizan SMTP como protocolo de transporte, el conector SMTP ofrece funcionalidad adicional al poder utilizarse para conectar una organización de Exchange con cualquier servidor SMTP.

•

Conector X.400 El conector X.400 establece una ruta de mensajería X.400 entre dos grupos de enrutamiento o entre un grupo de enrutamiento y un sistema X.400. Al igual que el conector para grupo de enrutamiento y el conector SMTP, un conector X.400 puede utilizarse para vincular grupos de enrutamiento de Exchange. Por lo general, los conectores X.400 sólo se utilizan en las conexiones a otros sistemas de mensajería X.400.

Exchange Server 2003 admite los siguientes conectores opcionales que se pueden utilizar para conectar una organización a sistemas de mensajería que no sean de Exchange: •

Conector de Exchange para Lotus Notes El Conector de Exchange para Lotus Notes se utiliza para el enrutamiento de mensajes y la sincronización de directorios entre una organización de Exchange y un sistema de mensajería de Lotus Notes.

•

Conector de Exchange para Novell GroupWise El Conector de Exchange para Novell GroupWise se utiliza para el enrutamiento de mensajes y la sincronización de directorios entre una organización de Exchange y un sistema de mensajería de Novell GroupWise.

32

•

Conector de calendario de Exchange El Conector de calendario de Exchange se utiliza para intercambiar información de disponibilidad entre una organización de Exchange y un sistema de mensajería de Lotus Notes o Novell GroupWise.

El almacén de mensajes de Exchange Exchange Server 2003 admite el uso de dos tipos de almacenes: almacenes de buzones y almacenes de carpetas públicas. Cada almacén es una base de datos lógica que contiene dos archivos de base de datos. El primer archivo es un archivo de base de datos de secuencias (.stm) que almacena mensajes con formato de Internet, como el contenido nativo de Extensiones multipropósito de correo Internet (MIME). En este archivo se almacena cualquier mensaje con formato de Internet que envía al almacén cualquier cliente, excepto los clientes MAPI. El segundo archivo es el archivo de base de datos MAPI (.edb), que contiene todos los mensajes enviados al almacén a través de MAPI, así como las tablas de bases de datos que definen los buzones, los mensajes, las carpetas y los datos adjuntos. Las propiedades de los mensajes con formato de Internet se promueven a la base de datos MAPI para que los mensajes se muestren en la Bandeja de entrada de los clientes MAPI. En otras palabras, el archivo .stm comprende el contenido de los mensajes de correo electrónico con formato de Internet, como UUENCODE o MIME, al que hace referencia el archivo .edb correspondiente. Esto significa que la base de datos de secuencias y los archivos de base de datos MAPI que componen una base de datos concreta no pueden separase.

Tecnología de bases de datos de Exchange Server 2003 Exchange utiliza el Motor de almacenamiento extensible (ESE) para mantener bases de datos de transacciones, y utiliza archivos de registro de transacciones con escritura anticipada para asegurarse de que los datos de Exchange se procesan de forma eficaz. El almacén de Exchange orientado a transacciones proporciona el máximo nivel de recuperabilidad. Una transacción puede incluir varias acciones, pero para que la transacción se consigne, deben completarse correctamente todas las acciones. Si no puede completarse una parte de la transacción, se deshace toda la transacción y no se consigna en la base de datos. Para obtener más información acerca del tratamiento de las transacciones en Exchange Server 2003, consulte Arquitectura del servicio Almacén de información de Exchange.

Almacenes y grupos de almacenamiento Puede dividir el almacén de Exchange en varios grupos de almacenamiento y almacenes. Un grupo de almacenamiento es un grupo de bases de datos que comparte un mismo registro de transacciones. Un almacén es una sola base de datos que comprende el

33

contenido del buzón o de las carpetas públicas. En Exchange Server 2003, puede pue configurar hasta cuatro grupos de almacenamiento en cada servidor de Exchange Server. Cada grupo de almacenamiento puede contener hasta cinco almacenes. Exchange Server 2003 incluye asimismo un Grupo de almacenamiento de recuperación adicional y de uso exclusivo. El Grupo de almacenamiento de recuperación puede utilizarse para restaurar buzones o almacenes mientras permanecen en línea los otros almacenes. Para obtener más información acerca de los grupos de almacenamiento y del grupo de almacenamiento de recuperación, consulte Arquitectura del servicio Almacén de información de Exchange. Exchange La figura siguiente muestra un posible grupo de de almacenamiento y una posible configuración de almacén de un servidor de Exchange Server. Almacenes y grupos de almacenamiento de un servidor de Exchange Server

El motivo principal para implementar varios grupos de almacenamiento y almacenes es reducir el tamaño de cada base de datos mientras se continúa admitiendo a un elevado número de usuarios en un único servidor. Disponer de varios almacenes de menor tamaño mejora la realización de copias de seguridad y la recuperación de Exchange Server. Dado que todos los almacenes de un grupo de almacenamiento comparten un registro de transacciones, debe realizarse una copia de seguridad de cada grupo de almacenamiento como un todo. Si su infraestructura de copias de seguridad admite varias secuencias de copia, podrá odrá realizar copias de seguridad de varios grupos de almacenamiento a la vez. Si tiene que restaurar datos en el servidor de Exchange Server, podrá restaurar cada almacén por separado. Cuando restaure cada almacén, podrá montarlo y ponerlo a disposición de d los usuarios. Nota: Exchange Server 2003 admite un Grupo de almacenamiento de recuperación de uso exclusivo para que pueda restaurar bases de datos mientras los usuarios se encuentran conectados a las bases de datos originales. Mediante el Grupo de almacenamiento acenamiento de recuperación, podrá restaurar buzones por separado sin tener que desconectar del servidor a los usuarios no afectados.

34

Agentes de usuarios de una organización de Exchange Server 2003 Los agentes de usuarios son clientes de mensajería que los destinatarios utilizan para tener acceso a sus buzones en el servidor de Exchange Server. Exchange Server 2003 admite varios protocolos de acceso de cliente distintos. La tabla siguiente enumera los protocolos de mensajería admitidos. Protocolos de mensajería admitidos en una organización de Exchange Server 2003 Protocolo

Descripción

MAPI

Los clientes MAPI proporcionan el máximo de funcionalidad. Con un cliente MAPI como Outlook, puede tener acceso al contenido de todas las carpetas de un buzón y del almacén de carpetas públicas predeterminado. Los clientes MAPI utilizan llamadas a procedimientos remotos (RPC) para conectarse al servidor de Exchange Server. Exchange Server 2003 también admite RPC a través de HTTP cuando se ejecuta en Windows Server 2003. Windows Server 2003 proporciona la infraestructura necesaria para ello. El cliente y el servidor no tienen en cuenta la encapsulación del protocolo. Para obtener más información acerca de RPC a través de HTTP, consulte el artículo 833401 de Microsoft Knowledge Base, "How to configure RPC over HTTP on a single server in Exchange Server 2003".

HTTP

Exchange utiliza HTTP para proporcionar acceso al almacén de mensajes mediante Outlook Web Access, Exchange ActiveSync y Outlook Mobile Access.

POP3

POP3 es un protocolo de recuperación de correo que proporciona el acceso más básico a Exchange. POP3 permite a un usuario tener acceso a los mensajes de la carpeta Bandeja de entrada del buzón.

35

Protocolo

Descripción

IMAP4

IMAP4 es un protocolo de recuperación de correo flexible. Puede utilizar un cliente IMAP4 para organizar sus mensajes del servidor. Puede mover mensajes de una carpeta a otra y obtener una vista previa del contenido de los mensajes antes de descargar el mensaje completo o de una parte de un mensaje, como pueden ser los datos adjuntos.

NNTP

NNTP se utiliza para tener acceso a los grupos de noticias. Puede configurar Exchange para publicar partes de la jerarquía de carpetas públicas y ponerlas a disposición de los clientes NNTP.

Dependencias de los servicios de Exchange Server 2003 Microsoft Exchange Server 2003 es un sistema de mensajería de cliente-servidor en el que los procesos de servidor activos interactúan con los procesos de cliente. Puede ver estos procesos de servidor en la herramienta Servicios, que encontrará en el grupo de programas Herramientas administrativas. En la terminología de Microsoft Windows, un proceso de servidor se conoce como un servicio. El nombre de la mayoría de los servicios de Exchange Server acaba en "Microsoft Exchange". Un buen ejemplo de ello es el Almacén de información de Microsoft Exchange. En un sistema cliente-servidor, la mayor parte del procesamiento se realiza directamente en el servidor. Los servicios de servidor aceptan solicitudes y datos de los clientes, procesan las solicitudes, almacenan los datos y devuelven los resultados del procesamiento a los clientes. Microsoft Office Outlook es un cliente, concretamente un cliente de mensajería. La tarea principal de un cliente de mensajería es proporcionar una interfaz de usuario para que el usuario pueda interactuar con el sistema de mensajería de manera intuitiva. El Administrador del sistema de Exchange también es un cliente. Dicho cliente proporciona a los administradores una interfaz con la que pueden administrar una organización de Exchange Server 2003. Además, los propios servicios de servidor son clientes de otros servicios de servidor Por ejemplo, el servicio Protocolo simple de transferencia de correo (SMTP) debe comunicarse con el servicio Almacén de información de Exchange para tener acceso a los mensajes de correo electrónico de un servidor de Exchange Server. Cada servicio de Exchange Server 2003 tiene una finalidad específica. Todos los servicios deben

36

interactuar entre sí y con los servicios ofrecidos por el sistema operativo para poder funcionar conjuntamente como plataforma de mensajería. Para comprender que el hecho de que Exchange Server 2003 sea un sistema clienteservidor, debe tener en cuenta los componentes siguientes, así como sus dependencias e interacciones: •

Administrador de control de servicios y arquitectura de servicios de Windows El Administrador de control de servicios (SCM) constituye la base de la arquitectura de servicios de Windows, ya que se trata del componente central que controla todos los servicios y controladores de dispositivos de Windows que se ejecutan en Windows. SCM le permite controlar un servicio, pero no un controlador de dispositivo. Por ejemplo, el Administrador de control de servicios inicia los controladores de dispositivos en un orden muy preciso de acuerdo con sus árboles de dependencias, pero usted no puede detenerlos. No obstante, puede iniciar o detener servicios de Windows desde la herramienta Servicios del grupo de programas Herramientas administrativas. Cuando utiliza la herramienta Servicios, interactúa con el proceso SCM.

•

Servicios del sistema operativo El sistema operativo proporciona una serie de servicios necesarios, como el servicio Llamada a procedimiento remoto (RPC) y el Proveedor de compatibilidad con seguridad LM de Windows NT.

•

Servicios de Internet Information Server Los Servicios de Internet Information Server (IIS) son un proceso importante que debe ejecutarse en todos los servidores de Exchange 2003 Server. Exchange Server 2003 agrega servicios POP3 e IMAP4 a IIS y extiende el servicio SMTP, el servicio Protocolo de transferencia de noticias a través de la red (NNTP) y el servicio World Wide Web.

•

Servicios básicos de Exchange Para poder funcionar como sistema de mensajería, Exchange Server 2003 contiene varios servicios que no forman parte del sistema operativo ni de IIS. Los servicios básicos de Exchange Server 2003 son los que deben ejecutarse en todos los servidores de Exchange. En esta sección se describen todos los servicios básicos de manera detallada.

•

Servicios adicionales de Exchange Exchange Server 2003 puede configurarse para tratar tareas específicas. Por ejemplo, puede utilizar Exchange Server 2003 para implementar un servidor de buzón exclusivo o un servidor cabeza de puente exclusivo. Según la función del servidor, pueden ser necesarios servicios adicionales de Exchange, como los conectores de mensajería. Se consideran servicios adicionales los servicios de Exchange que se requieren únicamente en situaciones concretas.

Esta sección ofrece una introducción al sistema operativo y a los servicios específicos de Exchange que son necesarios para poder disponer de un servidor de Exchange Server 2003 plenamente funcional. Se asume que está familiarizado con la plataforma Microsoft Windows Server 2003, los servicios de red y Active Directory, así como con los conceptos de administración de Exchange Server 2003. Para obtener información adicional acerca de Windows Server 2003, consulte Windows Server 2003 Technology Centers. Para obtener información adicional acerca de la administración de Exchange Server 2003, consulte la Exchange Server 2003 Administration Guide.

37

Descripción de la arquitectura de los servicios de Windows Los servicios de Windows, también denominados denominados aplicaciones de servicios, son aplicaciones que se ejecutan en los equipos de Windows independientemente del hecho de que un usuario haya iniciado una sesión o no. Un servicio de Windows se compone de un archivo ejecutable, un directorio para almacenar almacenar componentes de la aplicación y valores del Registro que definen los parámetros del servicio. El servicio de Windows implementa una interfaz de programación que SCM puede utilizar para controlar el servicio. Un servicio de Windows puede iniciarse automáticamente tomáticamente cuando se inicia el sistema o manualmente a través de un programa de control de servicio. Un programa de control de servicio es una aplicación que utiliza funciones de SCM para controlar un servicio. Ejemplos de programas de control de servicios ios son la herramienta Servicios y las herramientas de línea de comandos net.exe y SC.exe. La figura siguiente ilustra la arquitectura de servicios de Windows. Relaciones entre el programa de control de servicio, el administrador de control de servicios y los servicios de Windows

Nota: El proceso SCM es un servicio de servidor de llamada a procedimiento remoto (RPC). Las RPC permiten a los programas de control de servicios comunicarse con SCM de manera local o a través de la red, con el fin de controlar controlar los servicios en equipos remotos.

38

Funciones del Administrador de control de servicios SCM, también conocido como el controlador de servicios, es un proceso genérico de Windows que realiza diversas tareas de servicios. Dichas tareas se tratan en profundidad en las secciones siguientes.

Mantenimiento de una base de datos de servicios instalados SCM mantiene una base de datos de todos los servicios instalados, incluida una lista de todos los servicios y controladores de dispositivos que deben cargarse para que Windows se inicie correctamente. A medida que se instalan en el servidor servicios adicionales, como los servicios de Exchange Server 2003, se van agregando entradas en la base de datos de servicios. SCM mantiene esta base de datos en la siguiente ubicación del Registro: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services La base de datos de servicios contiene una clave por cada uno de los servicios y controladores instalados. El nombre de la clave corresponde al nombre del servicio, tal como se especificó cuando el servicio fue instalado por un programa de configuración de servicio. Por ejemplo, MSExchangeIS es el nombre del servicio Almacén de información de Microsoft Exchange y MSExchangeSA es el nombre del servicio Operador de sistema de Microsoft Exchange. La longitud máxima de un nombre de servicio es 256 caracteres. La figura siguiente muestra varias entradas de servicios específicos de Exchange del Registro.

39

Entradas de servicios específicos de Exchange del Registro

Nota: Los nombres que ve al trabajar con la herramienta Servicios son los nombres descriptivos de los servicios de Windows. Por ejemplo, el nombre descriptivo de MSExchangeSA es Operador de sistema de Microsoft Exchange.. El nombre descriptivo se define en un val valor REG_SZ denominado DisplayName que encontrará en: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services HKEY_LOCAL_MACHINE Services\<nombre del servicio>.

Bloqueo y desbloqueo de la base de datos de servicios Durante su inicialización, SCM debe bloquear la base de datos de servicios con el fin de serializar el acceso a la información de configuración. Por ejemplo, SCM bloquea la base de datos de servicios antes de iniciar un servicio, de manera que la configuración de servicios no pueda cambiarse mientras se inicia otro. SCM desbloquea desbloquea la base de datos cuando el servicio se ha iniciado por completo. Los programas de configuración de servicios deben comunicarse también con SCM para solicitar un bloqueo antes de volver a configurar un servicio y para poder aplicar el desbloqueo. Puede utilizar utilizar la herramienta de línea de comandos SC.exe con el comando sc QueryLock para ver si la base de datos de servicios está bloqueada.

40

Nota: Al administrar servicios que requieran mucho tiempo para iniciarse, recuerde que no podrá volver a configurar el el tipo de inicio ni otras opciones de configuración durante el proceso de inicio del servicio, ya que SCM bloquea la base de datos de servicios. Únicamente podrá aplicar cambios de configuración antes o después de iniciar un servicio.

Enumeración de los servicios s instalados El proceso SCM lee cada clave del Registro de la base de datos de servicios para crear un registro de servicio para cada servicio. Un registro de servicio contiene el nombre del servicio, el tipo de inicio, el estado del servicio (por e ejemplo, jemplo, el estado actual del servicio y los códigos de control aceptables) así como un puntero hacia la lista de dependencias. SCM utiliza estos registros de servicio para determinar las acciones que son válidas para los servicios, de acuerdo con su estado y dependencias actuales. Por ejemplo, no puede detener el Operador de sistema desde la herramienta Servicios si se está ejecutando otro servicio que depende del Operador de sistema, como puede ser el servicio Almacén de información de Microsoft Exchange.

Inicio, detención, puesta en pausa y reanudación de servicios Para realizar tareas generales, como iniciar o detener un servicio, SCM se comunica con los servicios que controla. SCM puede iniciar los servicios de Windows automáticamente durante el inicio del el sistema (servicio de inicio automático) o manualmente cuando lo solicite un programa de control de servicio (servicio de inicio solicitado). Sin embargo, si el servicio de inicio automático depende de un servicio de inicio solicitado, éste último también tambié se iniciará automáticamente. El tipo de inicio puede determinar asimismo que el servicio esté deshabilitado, en cuyo caso no podrá iniciarse. No se puede iniciar un servicio de inicio automático o de inicio solicitado si el servicio depende de un servicio servicio deshabilitado. Es importante tener en cuenta esta dependencia, sobre todo si planea deshabilitar servicios (por ejemplo, de un servidor de aplicaciones para usuario que ejecute Exchange Server). No debe deshabilitar servicios esenciales. Si lo hace, puede puede ocurrir que el sistema operativo no se inicie, ya que los servicios deshabilitados impiden el inicio de todos los demás servicios que dependen de ellos. Si observa problemas de inicio después de deshabilitar un servicio, no inicie sesión en Windows. En ssu u lugar, debe reiniciar el sistema con la "última configuración buena conocida" para descartar los cambios más recientes en la configuración de servicios. Windows almacena la "última configuración buena conocida" en la clave del Registro HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001 HKEY_LOCAL_MACHINE ControlSet001 y actualiza esta clave cada vez que se inicia el sistema operativo correctamente. Cuando se inicia sesión en Windows con una configuración incorrecta, se aplican valores incorrectos a la "última configuración buena conocida". Para comprobar probar rápidamente las dependencias y el tipo de inicio de los servicios de Exchange, puede utilizar la herramienta SC.exe con el comando sc <nombre del servicio>

41

qc.. Por ejemplo, el resultado siguiente representa la configuración estándar del Operador de sistema (línea de comandos: sc qc MSExchangeSA): SERVICE_NAME: MSExchangeSA TYPE

: 10

WIN32_OWN_PROCESS

ERROR_CONTROL

: 1

NORMAL

BINARY_PATH_NAME

: "C:\Program "C: Files\Exchsrvr\bin\mad.exe" mad.exe"

LOAD_ORDER_GROUP GROUP

:

TAG

: 0

DISPLAY_NAME

: Microsoft Exchange System Attendant

SERVICE_START_NAME : LocalSystem

Para determinar el tipo de inicio, desde la herramienta Servicios, haga clic en la ficha General y, a continuación, uación, en Tipo de inicio.. Asimismo, puede utilizar la herramienta Servicios para iniciar el Operador de sistema o SC.exe con la línea de comandos sc start MSExchangeSA.. También puede iniciar servicios con el comando net start de esta manera: net start MSExchangeSA xchangeSA.. La mayoría de los administradores prefieren utilizar la herramienta Servicios. Tanto si utiliza la herramienta Servicios, como si utiliza SC.exe, el comando net start o cualquier otro programa de control de servicio, SCM realiza la siguiente secuencia sec de pasos para iniciar un servicio: 1. Recupera la información de cuenta almacenada en la base de datos de servicios El nombre y la contraseña del usuario de la cuenta de servicio se especifican cuando se instala el servicio. SCM almacena el nombre del usuario en un valor REG_SZ del Registro denominado ObjectName dentro de la clave del Registro del servicio en cuestión (HKEY_LOCAL_MACHINE HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services Services\<nombre del servicio>). La contraseña se encuentra en una parte segura de Autoridad de seguridad local (LSA). Puede cambiar la cuenta de servicio desde la herramienta Servicios, mediante la ficha Inicio de sesión. Nota: Los servicios de Exchange Server 2003 utilizan la cuenta LocalSystem de forma predeterminada. La cuenta LocalSystem es una cuenta local predefinida que cuenta con amplios privilegios en el equipo local. Esta cuenta sólo está disponible para los procesos del sistema y no tiene contraseña. 2. Inicia sesión en la cuenta de servicio Todos los procesos activos deben tener una identidad en Windows, lo cual incluye a las aplicaciones de servicios. Cuando se inicia un servicio, SCM utiliza la iinformación de cuenta obtenida de la base de datos de servicios e inicia sesión en Windows. En el

42

equipo local, la cuenta que utiliza SCM para iniciar sesión debe disponer del derecho especial de usuario Iniciar sesión como servicio. servicio Nota: La cuenta LocalSystem dispone implícitamente del derecho Iniciar sesión como servicio,, ya que tiene un acceso total a todos los recursos. 3. Crea el servicio en estado suspendido SCM inicia nuevos servicios en estado suspendido, ya que el servicio es útil sólo después de que SCM agregue la información de seguridad requerida al nuevo proceso. 4. Asigna el testigo de acceso al proceso Todo proceso ejecutado en Windows requiere un testigo de acceso, también conocido como testigo de inicio de sesión. El testig testigo o de acceso es un objeto que describe el contexto de seguridad del servicio. La información del testigo incluye la identidad y los privilegios de la cuenta de servicio que utiliza el servicio para interactuar con el sistema operativo. 5. Permite que se ejecute ecute el proceso Una vez que completa el procedimiento de inicio de sesión y asigna el testigo de acceso, SCM puede permitir que el servicio se ejecute y realice sus funciones. SCM realiza la siguiente secuencia de pasos cuando detiene un servicio: 1. SCM CM recibe una solicitud de detención de un servicio Un programa de control de servicio puede detener un servicio con una función de control de servicio mediante una solicitud del tipo SERVICE_CONTROL_STOP enviada al servicio a través de SCM. 2. SCM examina a las dependencias del servicio Si SCM determina que otros servicios en ejecución dependen del servicio especificado en la solicitud de detención, devolverá un código de error al programa de control de servicio. Antes de desencadenar el procedimiento de detención, detención, el programa de control de servicio debe enumerar y detener todos los servicios que dependan del servicio especificado. Por ejemplo, la herramienta Servicios muestra el cuadro de diálogo Detener otros servicios, en el que se pregunta si se desea de detener tener también todos los servicios dependientes. No obstante, SC.exe se limita a informar del código de error e indica que no se puede detener el servicio, ya que otros servicios activos dependen de él. 3. SCM reenvía la solicitud de detención al servicio Si no detecta ningún servicio dependiente activo, SCM ordena al servicio especificado que se detenga reenviándole el código de detención. El servicio debe liberar ahora los recursos que tenía asignados y cerrarse.

43

Mantenimiento de la información de estado de los servicios en ejecución Cuando se está ejecutando un servicio, éste envía notificaciones de estado al proceso SCM. SCM mantiene la información de estado en el registro de servicio de cada servicio. SCM realiza un seguimiento de dicha información con el fin de no enviar por error solicitudes de control que no correspondan al estado actual del servicio destinatario. La información de estado de servicio contiene: •

Tipo de servicio Un servicio puede ser un controlador del sistema de archivos, un controlador de dispositivo o un servicio de Windows, y puede ejecutar su propio proceso o compartir un proceso con otros servicios. El Operador de sistema es un ejemplo de servicio que ejecuta su propio proceso. El servicio SMTP, sin embargo, es un servicio servici que comparte un proceso con otros servicios integrados con los Servicios de Internet Information Server (IIS).

•

Estado actual El estado de servicio puede ser iniciándose, en ejecución, en pausa, deteniéndose o sin ejecutar.

•

Códigos de control acepta aceptables Son los códigos de control que el servicio puede aceptar y procesar en su función de controlador, según el estado actual.

•

Código de salida de Windows El servicio utiliza este código para informar de un error que se produce en el inicio o en la detención. detención. Para devolver un código de error específico al servicio, éste debe establecer el valor como ERROR_SERVICE_SPECIFIC_ERROR para indicar que se puede encontrar información adicional en el código de salida del servicio. El servicio establece este valor val como NO_ERROR cuando se ejecuta o se detiene correctamente.

•

Código de salida de servicio El servicio utiliza este código para informar de un error que se produce al iniciarse o detenerse. El valor se omite a no ser que se establezca el código de salida ida de Windows como ERROR_SERVICE_SPECIFIC_ERROR.

•

Sugerencia de espera El servicio utiliza este código para informar del tiempo estimado, en milisegundos, necesario para un inicio, detención, pausa u operación de continuación pendientes.

•

Punto de control El servicio utiliza este valor para informar periódicamente de su progreso durante un inicio, detención, pausa u operación de continuación de larga duración. Por ejemplo, la herramienta Servicios utiliza este valor para realizar un seguimiento del progreso rogreso del servicio durante las operaciones de inicio y detención. Sugerencia: Para mostrar el estado actual de todos los servicios de Windows, puede utilizar el comando sc query state= all type= service. service

44

Servicios de Exchange y cuenta LocalSystem Los servicios ervicios de Exchange Server 2003 se ejecutan con la cuenta LocalSystem. Esto tiene las implicaciones de seguridad siguientes: •

No se requiere ninguna cuenta de servicios ni contraseña adicional La cuenta LocalSystem (NT AUTHORITY AUTHORITY\LocalSystem) existe siempre iempre y utiliza como contraseña un número hexadecimal aleatorio. Esta contraseña cambia automáticamente cada siete días, por lo que no necesita crear una cuenta de servicios en Active Directory antes de instalar Exchange Server 2003 o cambiar una contraseña ña de servicios con frecuencia.

•

Control total de todos los recursos locales Dado que los servicios de Exchange Server 2003 ejercen un control total sobre todos los recursos, estos servicios suelen tener un acceso ilimitado a la base de datos del Regis Registro, tro, a la metabase de IIS y al sistema de archivos. Sin embargo esto no es así si a la cuenta especial de Windows SYSTEM o a la cuenta Todos se le deniega explícitamente el acceso, lo cual no se recomienda. De esta forma, si se instala Exchange 2003 en un controlador de dominio, los servicios de Exchange Server 2003 tendrán acceso total a Active Directory, ya que el controlador de dominio aloja una réplica de los directorios y LocalSystem tiene acceso total a los recursos locales. Nota: La mayoría de la lass organizaciones preocupadas por la seguridad no instala Exchange Server 2003 en un controlador de dominio, ya que esta instalación no permite una administración independiente de Exchange Server 2003 y de Active Directory.

•

LocalSystem permite el acceso ú únicamente nicamente a los recursos locales Cuando se ejecuta un servicio con la cuenta LocalSystem, sólo puede tener acceso a los recursos locales, a no ser que se utilice otra cuenta para el acceso a la red. Por lo tanto, los servicios que se ejecutan con LocalSy LocalSystem stem utilizan la cuenta NetworkService para el acceso a la red. El nombre de la cuenta es NT AUTHORITY AUTHORITY\NetworkService. NetworkService. Esta cuenta no tiene contraseña. La cuenta NetworkService corresponde a la cuenta de equipo del equipo local del dominio. Un servicio d de e Exchange que se ejecute en el contexto de seguridad de la cuenta LocalSystem utiliza las credenciales de la cuenta de equipo local al tener acceso a los recursos del dominio, como Active Directory, a través de la red. De esta forma, Exchange Server 2003 dispone de muchos menos privilegios en un servidor miembro que en un controlador de dominio, ya que de manera predeterminada las cuentas de equipo tienen muy pocos privilegios y no pertenecen a ningún grupo. La configuración predeterminada para las cuentas de equipo permite sólo un acceso mínimo a Active Directory. Para resolver esta situación y garantizar que la cuenta de equipo cuenta con los permisos necesarios, Exchange Server 2003 crea en Active Directory los dos grupos de seguridad especiales siguientes: siguie

45

•

Servidores de dominio de Exchange Los servidores de dominio de Exchange forman un grupo de seguridad global que contiene las cuentas de equipo de todos los servidores de Exchange Server de un dominio.

•

Servidores empresariales de Exchange Loss servidores empresariales de Exchange constituyen un grupo de seguridad local que contiene todos los grupos Servidores de dominio de Exchange del bosque. Este grupo de seguridad concede acceso a los recursos necesarios del dominio local para todas las cuentas cue de equipo de Exchange. Nota: No cambie el nombre de los grupos Servidores de dominio de Exchange y Servidores empresariales de Exchange ni los mueva, ni quite cuentas de equipo de servidores existentes de Exchange de estos grupos.

Examen de la base de datos de servicios Al abrir HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services HKEY_LOCAL_MACHINE en el Editor del Registro (Regedit.exe) y examinar claves sueltas de los servicios de Exchange, verá que muchos servicios cuyo nombre comienza por MSExchange muestran valores valores similares en las claves de servicio. En la tabla siguiente se enumeran estos valores. Valores generales de los servicios de Windows en el Registro Valor

Tipo

Descripción

DependOnGroup

REG_MULTI_SZ

Enumera grupos de orden de carga de los que dependen los os servicios de Windows. Los servicios que dependen de un grupo pueden ejecutarse si, después de intentar instalar todos los miembros de un grupo, se ejecuta al menos un miembro del grupo.

DependOnService

REG_MULTI_SZ

Enumera los nombres de los servicios de Windows de los que depende este servicio. SCM debe iniciar estos servicios antes de iniciar el servicio. Este valor puede ser una cadena en blanco si el servicio no tiene ninguna dependencia.

46

Valor

Tipo

Descripción

Description

REG_SZ

Describe el servicio. La descripción es simplemente un comentario que explica la finalidad del servicio.

DiagnosticsMessageFile

REG_SZ

Contiene el nombre del archivo DLL del recurso que contiene las cadenas de descripción de suceso de los sucesos que el servicio agrega al registro de sucesos de la aplicación. Los archivos DLL de los recursos se encuentran en el directorio \Archivos de programa\Exchsrvr\Res.

DisplayName

REG_SZ

Contiene el nombre descriptivo que se utiliza para identificar el servicio. Esta cadena tiene una longitud máxima de 256 caracteres. El nombre conserva las minúsculas y mayúsculas en SCM. Las comparaciones de nombres descriptivos no distinguen entre mayúsculas y minúsculas.

47

Valor

Tipo

Descripción

ErrorControl

REG_DWORD

Especifica la gravedad del error y la acción adoptada si este servicio no puede iniciarse. Este parámetro determina uno de los aspectos siguientes: •

El programa de inicio registra el error pero continúa con la operación de inicio.

•

El programa de inicio registra el error y muestra un mensaje pero continúa con la operación de inicio.

•

El programa de inicio registra el error. Si se inicia la "última configuración buena conocida", prosigue la operación de inicio. Si no es así, se reinicia el sistema con la "última configuración buena" conocida.

•

El programa de inicio registra el error, si es posible. Si se inicia la "última configuración buena conocida", se cancela la operación de inicio. Si no es así, se reinicia el sistema con la "última configuración buena" conocida.

48

Valor

Tipo

Descripción

FailureActions

REG_BINARY

Indica la acción que SCM debe emprender para cada error de un servicio. Se considera que un servicio ha fallado cuando se detiene sin informar del estado del controlador del servicio (por ejemplo, cuando falla un servicio).

Group

REG_SZ

Indica el grupo de orden de carga al que pertenece este servicio. Tenga en cuenta que si establece este valor puede reemplazar el contenido del valor DependOnService.

ImagePath

REG_EXPAND_SZ

Contiene la ruta de acceso completa del archivo binario del servicio. Si la ruta de acceso contiene un espacio, debe incluirse, para que pueda interpretarse correctamente. Por ejemplo, "d:\\Archivos de programa\\Exchsvr\\Bin\\mad. exe". La ruta de acceso puede incluir también argumentos de programa.

49

Valor

Tipo

Descripción

ObjectName

REG_SZ

Especifica el nombre de la cuenta con la que debe ejecutarse el servicio. Si el servicio utiliza la cuenta LocalService, este parámetro se establece como NT AUTHORITY\LocalService. Asimismo es posible especificar un nombre de cuenta con el formato NombreDeCuenta\NombreDe Usuario.

Start

REG_DWORD

Especifica cuándo se iniciará el servicio. SCM puede iniciar un servicio automáticamente durante el inicio del sistema, o bien cuando un proceso solicite el inicio del servicio. Este valor puede especificar también que un servicio no se puede iniciar y que cualquier intento de iniciarlo producirá el código de error ERROR_SERVICE_DISABL ED.

Tag

REG_DWORD

Determina el orden de inicio de servicios dentro de un grupo de orden de carga. Las etiquetas sólo se evalúan para los servicios de controladores.

50

Valor

Tipo

Descripción

Type

REG_DWORD

Especifica el tipo de servicio como controlador del sistema de archivos, un servicio que ejecuta su propio proceso, o bien un servicio que comparte un proceso con uno o más de los otros servicios. MSExchangeSA es un ejemplo de servicio que ejecuta su propio proceso. EXIFS es un ejemplo de un controlador del sistema de archivos específico de Exchange.

Además, pueden existir las siguientes subclaves para servicios de Exchange: •

Diagnostics Esta clave contiene parámetros REG_DWORD para posibles categorías de registros de sucesos que proporcione el servicio. El nombre de los parámetros de esta clave se compone de un número de identificador de recurso seguido de una cadena. Por ejemplo: 9 Clean Mailbox. El valor asociado con cada parámetro representa el nivel de registro de diagnóstico para esa categoría. Estos valores se suelen configurar a través de las propiedades de servidor del Administrador del sistema de Exchange. La ficha Registro de diagnóstico contiene las diversas categorías y asigna los valores seleccionados a estos parámetros.

•

Enum Esta clave contiene parámetros que SCM utiliza para enumerar los servicios de la base de datos de servicios. Por ejemplo, el parámetro REG_SZ 0 contiene un valor que hace referencia a las subclaves de la clave del Registro HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\Root. Esto permite al administrador de configuración de Windows enumerar los servicios como dispositivos lógicos durante el inicio del sistema.

•

Parameters Esta clave contiene parámetros del Registro de información de configuración específica de un servicio. La clave Parameters puede contener otras subclaves.

•

Performance Esta clave proporciona contadores de supervisión del rendimiento. El parámetro REG_SZ Library especifica el archivo DLL que contiene los contadores de rendimiento. Existen otras claves para los contadores de rendimiento. Por ejemplo, el parámetro REG_SZ PerfIniFile hace referencia al archivo .ini que define los contadores de rendimiento individuales.

•

Security Esta clave contiene un parámetro REG_BINARY denominado Security que contiene un descriptor de seguridad del servicio que especifica las cuentas que controlan

51

el servicio. Por ejemplo, un administrador administrador puede tener permisos para iniciar y detener un servicio, mientras que un usuario normal no. Precaución: La modificación incorrecta del Registro puede ocasionar problemas graves que quizás requieran volver a instalar el sistema operativo. Es posible que que los problemas derivados de una modificación incorrecta del Registro no se puedan resolver. Antes de modificar el Registro, se recomienda realizar una copia de seguridad de todos los datos importantes.

Servicios del sistema operativo Exchange Server 2003 depende en gran medida del sistema operativo para las comunicaciones de red, la seguridad, los servicios de directorio y otros aspectos. Por ejemplo, Exchange Server 2003 requiere TCP/IP y depende de la pila de protocolo TCP/IP y de sus componentes relacio relacionados. nados. Dichos componentes se implementan en controladores del núcleo que están muy integrados en el subsistema de E/S de Windows. Exchange Server 2003 utiliza interfaces de programación estándar de Win32 para interactuar con el núcleo. Además del núcleo de Windows, Exchange Server 2003 tiene las siguientes dependencias de servicios de Windows: •

Registro de sucesos Este servicio permite ver en el Visor de sucesos los mensajes de registros emitidos por los servicios de Exchange y otros programas y compon componentes de Windows. Este servicio no puede detenerse.

•

Proveedor de compatibilidad con seguridad LM de Windows NT Este servicio proporciona seguridad a los programas que utilizan llamadas a procedimiento remoto (RPC) y transportes distintos a canalizacione canalizaciones s con nombre para iniciar sesión en la red mediante el protocolo de autenticación NTLM.

•

Llamada a procedimiento remoto (RPC) Este servicio permite al asignador de puntos finales RPC admitir conexiones RPC con el servidor. Este servicio sirve también ccomo Modelo de objetos componentes (COM). RPC y las llamadas a procedimiento remoto ligeras (LRPC) son mecanismos de comunicación entre procesos importantes. Las LRPC son versiones locales de las RPC. Las LRPC se utilizan entre el almacén de Exchange y los los componentes de servidor que dependen de MAPI y sus API relacionadas para las comunicaciones, como por ejemplo conectores de mensajería para sistemas de mensajería que no son de Exchange. Las RPC normales, en cambio, se utilizan cuando los clientes deben comunicarse con los servicios de servidor a través de la red. Los clientes RPC habituales son los clientes MAPI, como Microsoft Outlook y Exchange System Manager, pero los componentes internos del Operador de sistema, como DSProxy, también son clientes RPC. RPC Para aceptar las solicitudes de directorio de los clientes MAPI y pasarlas a un proveedor de

52

libreta de direcciones, DSProxy debe utilizar RPC para comunicarse con Active Directory a través de la Interfaz de proveedor de servicios con nombre (NSPI). Para obtener más información acerca de DSProxy, consulte Exchange Server 2003 y Active Directory. Es importante comprender que las RPC son un mecanismo de comunicación de capa de aplicación, lo que significa que las RPC utilizan otros mecanismos de comunicación de red, como NetBIOS, canalizaciones con nombre o Windows Sockets, para establecer la ruta de comunicación. Para crear una conexión, es necesario el asignador de puntos finales RPC, ya que el cliente debe determinar en primer lugar el punto final que se tiene que usar. De manera predeterminada, los servicios de servidor RPC utilizan puntos finales de conexión dinámica. En una red TCP/IP, el cliente se conecta al asignador de puntos finales RPC a través del puerto TCP número 135, consulta el puerto TCP actual de un servicio concreto (por ejemplo, el puerto de Interfaz de proveedor de servicios con nombre (NSPI) de Active Directory), obtiene este puerto TCP del asignador de puntos finales, y finalmente utiliza el puerto para establecer la conexión RPC con el servidor RPC real. La figura siguiente ilustra la función del asignador de puntos finales RPC. Establecimiento de una conexión RPC con Active Directory Direc

Nota: De manera predeterminada, los servicios de Exchange utilizan puertos TCP dinámicos del número 1024 al número 5000 para la comunicación RPC. Para diversos servicios, como el Operador de sistema y el servicio Almacén de información de Exchang Exchange, e, es posible especificar puertos estáticos mediante parámetros del Registro. Sin embargo, el cliente debe establecer un contacto con el asignador de puntos finales RPC tanto si la asignación de puerto es dinámica como estática. •

Servidor Este servicio permite el uso compartido de archivos e impresoras así como el acceso de canalizaciones con nombre al servidor mediante el protocolo de bloques de mensaje del servidor (SMB). Por ejemplo, si se obtiene acceso a archivos de registro de seguimiento de mensajes mensajes mediante el centro de seguimiento de mensajes del Administrador del sistema de Exchange, se realiza una comunicación con el servicio de servidor ya que los registros de seguimiento de mensajes se comparten para el acceso a red a través de \\<nombre <nombre de servidor>\<nombre s <nombre de servidor>.Log, servidor>.Log por ejemplo,

53

\\Servidor01\Servidor01.log. El protocolo SMB también es necesario para la administración remota de Windows. La clave SCM del servicio de servidor es lanmanserver. Bajo esta clave del Registro, se encuentra una subclave importante denominada Shares. Esta clave contiene parámetros para todos los recursos compartidos del servidor. Un recurso compartido que tiene particular importancia para el Operador de sistema es Address, que proporciona acceso a los archivos DLL de generación de direcciones proxy que el Servicio de actualización de destinatarios utiliza para asignar objetos de destinatario con buzón habilitado y con correo habilitado, direcciones X.400, SMTP, de Lotus Notes, Microsoft Mail, Novell GroupWise y Lotus cc:Mail de acuerdo con la configuración de las directivas de destinatarios. A los archivos DLL de generación de direcciones se tiene acceso a través de la red, ya que los conectores de puerta de enlace (y sus archivos DLL de generación de direcciones) no tienen por qué existir necesariamente en el servidor local que ejecuta Exchange Server. El Servicio de actualización de destinatarios forma parte del Operador de sistema, por lo que el servicio de servidor debe iniciarse antes que el Operador de sistema. •

Estación de trabajo Este servicio es el equivalente al servicio de servidor. Permite al equipo conectarse a otros equipos de la red de acuerdo con el protocolo SMB. Este servicio debe iniciarse antes que el Operador de sistema.

•

Administrador de cuentas de seguridad El servicio Administrador de cuentas de seguridad (SAM) almacena la información de seguridad de las cuentas de usuario locales y es necesario para que las cuentas locales puedan iniciar sesión en el servidor. Dado que todos los servicios de Exchange deben iniciar sesión en el equipo local mediante la cuenta LocalSystem, Exchange Server 2003 no funcionará si no está disponible este componente.

•

Instrumental de administración de Windows Este servicio proporciona una interfaz estándar y un modelo de objetos para tener acceso a la información de administración referente al hardware y software del equipo. El Operador de sistema es el componente de Exchange Server 2003 responsable de la supervisión y del estado del servidor. Exchange Server 2003 agrega proveedores de Instrumental de administración de Windows (WMI) al servicio WMI, para que pueda tener acceso a la información de estado de Exchange a través de WMI. El servicio WMI es necesario para que se inicie el servicio Administración de Microsoft Exchange.

Además, existen varios servicios de Windows que Exchange Server 2003 necesita en situaciones específicas: •

Sistema de sucesos COM+ Este servicio admite la notificación de sucesos del sistema para componentes COM+, lo que proporciona una distribución automática de sucesos a los componentes COM suscritos. No debe deshabilitarse este servicio en los servidores de Exchange Server 2003, ya que los receptores de sucesos contenidos en una aplicación de componente COM+ que se ejecute fuera de proceso en el servidor no funcionará correctamente.

54

•

Aplicación de sistema COM+ Este servicio administra la configuración y el seguimiento de los componentes basados en COM+. Si se detiene el servicio, la mayoría de los componentes basados en COM+ de Exchange Server 2003 dejará de funcionar correctamente.

•

Servicio de informes de error Éste es un servicio opcional que permite la realización automática de informes de error. Los servidores de Exchange Server pueden utilizar este servicio para enviar de manera automática información de error grave de servicio a Microsoft.

•

SSL de HTTP Este servicio implementa HTTP seguro (HTTPS) para el servicio HTTP, a través de Secure Sockets Layer (SSL). Si desea utilizar HTTPS para un uso seguro de Outlook Web Access o RPC a través de las conexiones HTTP, debe habilitar este servicio.

•

Servicios IPSec Este servicio permite Seguridad del protocolo Internet (IPSec), lo que proporciona seguridad de un extremo a otro entre clientes y servidores de redes TCP/IP. Este servicio debe habilitarse si desea utilizar IPSec para proteger el tráfico de red entre un servidor de Exchange Server y otros equipos de la red, como un servidor de aplicaciones para usuario de Exchange Server o un controlador de dominio.

•

Microsoft Search Este servicio permite la indización de la información almacenada en el servidor. Este servicio es necesario si desea habilitar la indización de texto en un buzón o almacén de carpetas públicas del servidor de Exchange Server.

•

Proveedor de instantáneas de software de Microsoft Este servicio administra las instantáneas de volumen basadas en software obtenidas por el Servicio de instantáneas de volumen de Microsoft. Si utiliza la herramienta Copia de seguridad de Windows para realizar copias de seguridad de las bases de datos de mensajería de Exchange Server 2003, puede detener este servicio, ya que Copia de seguridad de Windows no utiliza el servicio de instantáneas de volumen. Por otro lado, deberá habilitar este servicio si utiliza una solución de copia de seguridad que no sea de Microsoft que lo utilice. En general, el servicio debe tener el mismo tipo de inicio que el servicio de instantáneas de volumen.

•

Inicio de sesión de red Este servicio permite el uso de un canal seguro entre el servidor de Exchange Server y un controlador de dominio. Este servicio es necesario para que los usuarios puedan tener acceso a los buzones del servidor de Exchange Server y para cualquier servicio que utilice una cuenta de dominio para iniciarse.

•

Registros y alertas de rendimiento Este servicio recopila datos de rendimiento de equipos locales o remotos basados en parámetros de programación previamente configurados, y a continuación escribe los datos en un registro o desencadena una alerta. Su detiene el servicio, no podrá recopilar información de rendimiento mediante el complemento Registros y alertas de rendimiento, que está disponible en la herramienta Rendimiento.

•

Registro remoto Este servicio permite a los usuarios modificar la configuración del Registro de forma remota. Exchange System Manager requiere el acceso al Registro, por ejemplo, si se desea configurar el registro de diagnóstico de los servicios de

55

Exchange. Este servicio debe estar disponible si ejecuta Exchange System Manager en una estación tación de trabajo de administración. Si se detiene el servicio, el Registro sólo podrá modificarse en el servidor local. •

Notificación de sucesos del sistema Este servicio supervisa los sucesos del sistema y los notifica a los suscriptores del Sistema d de e sucesos COM+. Si se detiene el servicio, los suscriptores del Sistema de sucesos COM+ no recibirán notificaciones de sucesos del sistema de Exchange. La tabla siguiente enumera los sucesos del sistema de Exchange Server 2003. Sucesos del sistema de Exchange Excha Server 2003

•

Suceso

Descripción

OnTimer

Llamado en un intervalo específico.

OnMDBStartUp

Llamado cuando se inicia un almacén.

OnMDBShutDown

Llamado cuando se detiene un almacén.

Instantáneas de volumen Este servicio administra e implementa Instantáneas de volumen utilizadas con fines de copia de seguridad y otros. Este servicio debe estar ejecutándose si su solución de copia de seguridad utiliza un solicitante de servicio de instantáneas de volumen de Exchange Server 2003 para crear instantáneas instantá de bases de datos de mensajería. Si el servicio está deshabilitado, los procesos de copia de seguridad podrían fallar. Nota: Los servicios enumerados anteriormente están configurados para iniciarse automáticamente en Windows Server 2003. Se ejecutan en el contexto de seguridad de la cuenta LocalSystem.

Servicios de Internet Information Server Servicios de Internet Information Server (IIS) forma parte integral de todos los servidores de Exchange 2003 Server. IIS aloja componentes esenciales que Exchan Exchange ge Server 2003 necesita para poder funcionar como sistema de mensajería. Las aplicaciones de Interfaz de programación de aplicaciones de servidor de Internet (ISAPI), que Exchange Server 2003 agrega al servicio Web, por ejemplo Outlook Web Access, Outlook Mobile Access y Exchange ActiveSync, proporcionan a los usuarios acceso a Exchange a través de diversos protocolos de HTTP. El servicio Web también se encarga de la comunicación RPC a través de HTTP, si sus usuarios utilizan este mecanismo de comunicación para tener acceso a sus buzones a través de Internet sin tener conexión de red privada virtual (VPN). IIS aloja el servicio SMTP, que implementa el motor de transporte central de Exchange 2003. IIS aloja asimismo los motores de protocolo NNTP, IMAP4 y POP3 que proporcionan a los usuarios

56

de Internet acceso a datos de mensajería a través de la mayoría de protocolos de acceso de Internet. El servicio Protocolo de transferencia de archivos (FTP) es el único servicio de protocolo de IIS que no es importante para Exchange 2003, ya que FTP no es un protocolo de mensajería. La figura siguiente ilustra cómo se integran SMTP, NNTP, IMAP4, POP3, Outlook Web Access, Outlook Mobile Access y Exchange ActiveSync en la arquitectura de IIS 6.0. Componentes de Exchange Server 2003 en la arquitectura de IIS 6.0

Exchange Server 2003 utiliza los siguientes componentes clave de IIS 6.0: •

Inetinfo.exe Inetinfo.exe es un componente de modo de usuario que ejecuta el proceso principal de IIS y aloja la mayoría de los motores de protocolo de IIS 6.0. Entre estos componentes se incluye FTP, SMTP, NNTP, IMAP4 y POP3. El servicio de administración también se ejecuta en el contexto del proceso Inetinfo.exe. Sin embargo, es importante comprender que el servicio Publicación en World Wide Web no se ejecuta en Inetinfo.exe. La arquitectura de IIS 6.0 se ha rediseñado para que ejecute el servicio Web en su propio contexto de procesamiento por motivos de tolerancia a errores, rendimiento y seguridad.

•

Metabase La metabase es un almacén de datos que contiene datos de configuración de IIS. La metabase es un archivo .xml de texto sin formato que puede editarse manualmente o mediante programación. El archivo metabase.xml se encuentra en el directorio \Windows\System32\Inetsrv. Para obtener más información acerca de la metabase, consulte Servidores virtuales de protocolos de Exchange Server 2003.

•

Servicio de administración de IIS El servicio de administración de IIS (IIS Admin) administra la metabase de IIS y actualiza en el Registro los valores de los servicios Web, FTP, SMTP, POP3, IMAP4 y NNTP. IIS Admin proporciona también acceso a la información de configuración de IIS a otras aplicaciones, como el servicio de

57

actualización de la metabase, que es un componente interno del Operador de Sistema. Para obtener más información acerca del servicio de actualización de la metabase, consulte Exchange Server 2003 y Active Directory. La clave del Registro ro del servicio IIS Admin es HKEY_LOCAL_MACHINE\ \SYSTEM\CurrentControlSet\Services\IISAdmin.

IIS Admin depende del servicio Llamada a procedimiento remoto (RPC) y del servicio Administrador de cuentas de seguridad. Todos los demás servicios de IIS dependen del servicio IIS Admin. IIS Admin se implementa en Iisadmin.dll, que se encuentra de manera predeterminada en el directorio \Windows\System32\Inetsrv. Nota: El servicio IIS Admin debe estar ejecutándose en todos los servidores de Exchange Server 2003. •

Servicio SMTP El servicio SMTP ejecuta el motor de protocolo SMTP que de manera predeterminada acepta los mensajes SMTP entrantes del puerto TCP número 25 y envía mensajes a otros hosts mediante SMTP. En un servidor de Exchange Server 2003, el servicio SMTP controla también el motor de transporte central. El servicio SMTP se incluye en Windows Server 2003 y se extiende con Exchange Server 2003. Para obtener más información acerca de la arquitectura de transporte SMTP, consulte Arquitectura de transporte SMTP. La clave del Registro del servicio SMTP es HKEY_LOCAL_MACHINE\ \SYSTEM\CurrentControlSet\Services\SMTPSvc.

El servicio SMTP se ejecuta en el contexto del proceso Inetinfo.exe y depende de los servicios Registro de sucesos y IIS Admin. El servicio SMTP se implementa en Smtpsvc.dll, que se encuentra de manera predeterminada en el directorio \Windows\System32\Inetsrv. Inetsrv. Nota: Aunque ningún otro servicio depe depende nde del servicio SMTP, éste debe estar ejecutándose en todos los servidores de Exchange Server 2003, ya que todo el sistema de mensajería de Exchange Server 2003 depende de él. •

Servicio POP3 El servicio POP3 se incluye en Exchange Server 2003 y proporciona propor a los usuarios de Internet acceso a sus buzones mediante el protocolo de oficina de correo, versión 3 (POP3). Los clientes como Outlook Express pueden descargar mensajes a través de POP3 cuando el usuario tiene los permisos necesarios y cuando el servicio vicio POP3 se ejecuta en el servidor de Exchange Server. El servicio POP3 proporciona acceso únicamente a la carpeta Bandeja de entrada. Otras carpetas de buzón o carpetas públicas no están accesibles. La clave del Registro del servicio POP3 es HKEY_LOCAL_MACHINE\ \SYSTEM\CurrentControlSet\Services\POP3Svc.

El servicio POP3 se ejecuta en el contexto del proceso Inetinfo.exe y depende del servicio IIS Admin para poder ser controlado por IIS. El servicio POP3 se implementa en Pop3svc.dll, que se encuentra de manera predeterminada en el directorio \Archivos de programa\Exchsrvr\Bin. Bin. De manera predeterminada, el servicio POP3 está deshabilitado.

58

Nota: Dado que ningún otro servicio de Exchange depende del servicio POP3, éste no tiene que estar ejecutándose obligatoriamente obligatoriamente si los usuarios no utilizan clientes POP3 para tener acceso a sus buzones. •

Servicio NNTP El servicio NNTP permite a un servidor de Exchange Server 2003 alojar grupos de noticias NNTP (como grupos de debate) basados en carpetas públicas. Debido a que esta característica respeta plenamente el protocolo NNTP, los usuarios pueden utilizar un cliente de lectura de noticias para participar en debates de grupos de noticias. Si el servicio NNTP se ejecuta en un servidor de Exchange Server 2003, el servicio NNTP puede utilizarse también para replicar grupos de noticias con otros hosts NNTP a través de suministros de noticias. El servicio NNTP se incluye en Windows Server 2003 y se extiende con Exchange Server 2003. La clave del Registro del servic servicio NNTP es HKEY_LOCAL_MACHINE\ \SYSTEM\CurrentControlSet\Services\NNTPSvc.

El servicio NNTP se ejecuta en el contexto del proceso Inetinfo.exe y depende de los servicios Registro de sucesos y IIS Admin. El servicio NNTP se implementa en Nntpsvc.dll, que se encuentra e de manera predeterminada en el directorio \Windows\System32\Inetsrv. Inetsrv. De manera predeterminada, el servicio NNTP está deshabilitado. Nota: Dado que ningún otro servicio de Exchange depende del servicio NNTP, éste no tiene que estar ejecutándose ejecutándose obligatoriamente si no se replican grupos de noticias con otros hosts NNTP y si los usuarios no utilizan clientes de lectura de noticias para tener acceso a carpetas públicas. •

Servicio IMAP4 El servicio IMAP4 se incluye en Exchange Server 2003 y permite perm a los usuarios de Internet tener acceso a sus buzones y carpetas públicas mediante el Protocolo de acceso a correo de Internet, versión 4 (IMAP4). Los clientes como Outlook Express pueden descargar mensajes a través de IMAP4 cuando el usuario dispone de e los permisos necesarios y el servicio IMAP4 se está ejecutando en el servidor de Exchange Server. Los usuarios de IMAP4 pueden trabajar también con los mensajes directamente en el servidor. La clave del Registro del servicio IMAP4 es HKEY_LOCAL_MACHINE\ \SYSTEM\CurrentControlSet\Services\IMAP4Svc.

El servicio IMAP4 se ejecuta en el contexto del proceso Inetinfo.exe y depende del servicio IIS Admin. El servicio IMAP4 se implementa en IMAP4svc.dll, que se encuentra de manera predeterminada en el directorio \Archivos de programa\Exchsrvr\Bin. Bin. De manera predeterminada, el servicio IMAP4 está deshabilitado. Nota: Dado que ningún otro servicio de Exchange depende del servicio IMAP4, éste no tiene que estar ejecutándose obligatoriamente si los usuarios no utilizan clientes IMAP4 para tener acceso a sus buzones.

59

•

Servicio Publicación en World Wide Web El servicio Publicación en World Wide Web, que se incluye en Windows Server 2003, es un administrador de configuraciones y procesos en modo de usuario, que administra los componentes de IIS que procesan solicitudes HTTP y ejecutan aplicaciones Web, como Outlook Web Access, Outlook Mobile Access y Exchange ActiveSync. El servicio Web es asimismo un componente de supervisión, que comprueba las aplicaciones Web de manera periódica para determinar si dichas aplicaciones están ejecutándose o se han detenido inesperadamente. El servicio Web se incluye en Windows Server 2003. Exchange Server 2003 extiende este servicio con componentes ISAPI para Outlook Web Access, Outlook Mobile Access y Exchange ActiveSync. La clave del Registro del servicio World Wide Web es HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W3Svc. A diferencia de todos los otros servicios de IIS, el servicio Web no se ejecuta en el contexto del proceso Inetinfo.exe. Si observa el parámetro ImagePath en la clave del Registro W3Svc, verá que el servicio Web se ejecuta en el contexto del proceso Svchost.exe, que es un proceso de host genérico para servicios que se implementan en archivos DLL. El servicio Web se implementa en Iisw3adm.dll.

El servicio Web se ejecuta en un grupo de servicios Svchost.exe denominado IISSvcs. Svchost.exe utiliza grupos de servicios para ejecutar servicios distintos juntos en una sola instancia de Svchost.exe. Pueden ejecutarse varias instancias de Svchost.exe en un servidor y cada sesión de Svchost.exe puede contener un grupo de servicios distinto. Los grupos Svchost se enumeran en la siguiente clave del Registro: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Svchost.

Cada entrada de esta clave es un parámetro REG_MULTI_SZ que representa un grupo Svchost distinto. Cada valor contiene los nombres de los servicios que se ejecutan juntos dentro del grupo de servicios. Si observa el valor de la entrada IISSvcs, verá que el servicio Web es el único servicio del grupo IISSvcs. •

Proceso de trabajo World Wide Web Todo el procesamiento de aplicaciones Web, incluida la carga de filtros y extensiones ISAPI, así como la autenticación y la autorización, lo lleva a cabo un proceso de trabajo World Wide Web. El archivo ejecutable del proceso de trabajo se llama w3wp.exe. Cada proceso de trabajo proporciona un aislamiento total de los componentes del sistema y otras aplicaciones Web, y recibe solicitudes directamente del controlador de modo de núcleo HTTP.sys.

•

Grupo de aplicaciones Un grupo de aplicaciones es una cola de solicitudes de HTTP.sys utilizada por uno o más procesos de trabajo. En otras palabras, un grupo de aplicaciones puede atender solicitudes de una o más aplicaciones Web distintas. Estas aplicaciones Web se asignan al grupo de aplicaciones de acuerdo con su dirección URL. Cada grupo de aplicaciones está separado de los restantes grupos de aplicaciones por límites de proceso. Una aplicación que se asigna a un grupo de aplicaciones no se ve afectada por otros grupos de aplicaciones y no puede enrutarse a otro grupo de aplicaciones mientras es atendida por el grupo de aplicaciones actual.

60

Todos los servicios de tiempo de ejecución necesarios de las aplicaciones HTTP, como la compatibilidad con las extensiones ISAPI, están igualmente disponibles en cualquier grupo upo de aplicaciones. Este diseño impide que el funcionamiento incorrecto de una aplicación Web o de un sitio Web afecte a otras aplicaciones Web (o a otros sitios Web) que están siendo atendidas por otros procesos de trabajo de ese servidor. Ahora es posible le descargar componentes en proceso sin tener que detener todo el servicio Web. El proceso de trabajo host puede ponerse en pausa temporalmente sin que ello afecte a otros procesos de trabajo que se estén comunicando con exploradores Web u otras aplicaciones es Web. Un grupo de aplicaciones puede aprovechar asimismo otros servicios del sistema operativo que estén disponibles en el nivel de proceso (por ejemplo, límite de CPU). Nota: Las aplicaciones pueden asignarse a otro grupo de aplicaciones del complemento mento Administrador IIS mientras se ejecuta el servidor. IIS admite un máximo de 20.000 grupos de aplicaciones por servidor. •

HTTP.sys Éste es el componente de modo de núcleo para la escucha, enrutamiento, puesta en cola y almacenamiento en caché HTTP. HTTP.sys es un único punto de contacto para todas las solicitudes HTTP entrantes. Proporciona conectividad de alto rendimiento para las aplicaciones de servidor HTTP. El controlador se sitúa por encima de TCP/IP y se registra para todos los sockets de Windows Windows (combinaciones de IP y puerto) en los que se reciben solicitudes de conexión entrantes. HTTP.sys se encarga asimismo de la administración de conexiones, limitación de ancho de banda y registro de servidores Web en general. HTTP.sys mantiene una cola para cada grupo de aplicaciones de manera que las distintas solicitudes HTTP se enruten a los procesos de trabajo de modo de usuario correctos que atienden a un grupo de aplicaciones. Si un proceso de trabajo de modo de usuario se cierra inesperadamente, HTTP.sys HTTP.sys continúa aceptando y poniendo en cola solicitudes, siempre que siga ejecutándose el servicio Web. HHTP.sys continúa aceptando solicitudes y las pone en la cola adecuada hasta que no quedan colas disponibles, no queda espacio en las colas o se cierra cierra el servicio Web. Una vez que el servicio Web advierte el proceso de trabajo con errores, inicia un nuevo proceso de trabajo, si existen solicitudes pendientes de ser atendidas para el grupo de aplicaciones del proceso de trabajo. De esta forma, aunque pudiera pudiera producirse una perturbación temporal del proceso de solicitudes de modo de usuario, el usuario no percibiría el error ya que se continúa aceptando y poniendo en cola peticiones.

61

Servicios básicos de Exchange Server 2003 La figura siguiente ilustra los componentes básicos de Exchange Server 2003 y sus dependencias de servicios. Los componentes básicos son el Operador de sistema, el servicio Almacén de información de Exchange, el servicio IIS Admin, el servicio SMTP y el sistema de archivos instalable de Exchange (ExIFS). Todos estos servicios deben ejecutarse en todos los servidores de Exchange Server 2003 para garantizar un sistema de mensajería plenamente funcional. Servicios básicos de Windows y sus servicios básicos de Exchange Server 2003 dependientes

El servicio IIS Admin y SMTP están integrados con IIS, tal como se explica en la sección anterior. El servicio SMTP debe ejecutarse en todos los servidores de Exchange Server 2003 ya que todos los mensajes enviados a o de destinatarios locales deben pasar por el motor de transporte SMTP. Si este servicio se detiene o no está disponible, Exchange Server 2003 no podrá entregar ningún mensaje. Para obtener más información acerca de la arquitectura de enrutamiento de Exchange Server 2003, consulte Arquitectura de enrutamiento de mensajes. Los componentes básicos de Exchange Server 2003 se encargan de las siguientes tareas: •

Servicio Operador de Sistema de Microsoft Exchange El Operador de sistema es uno de los servicios más importantes de Exchange Server 2003. Este componente se encarga de muchas tareas, incluido el mantenimiento de la comunicación con Active Directory, la generación de listas de direcciones sin conexión, la realización del seguimiento de los mensajes y otras. El archivo ejecutable es Mad.exe y se encuentra en el directorio \Archivos de programa\Exchsrvr\Bin. Existen varias claves del Registro que el Operador de sistema utiliza para sus diversos componentes en

62

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\,

como MSExchangeSA, MSExchangeDSAccess, MSExchangeAL, MSExchangeFBPublish, MSExchangeMU y MSExchangeADDXA. La tabla siguiente enumera las tareas del Operador de sistema.

63

Componentes internos de Operador de sistema y sus tareas Componente

Tarea

Comentarios

Componente DSAccess

Buscar controladores de dominio en la red y proporcionar a otros servicios de Exchange información de Active Directory

El Operador de sistema debe buscar controladores de dominio y catálogos globales en la red, de manera que los servicios de Exchange puedan tener acceso a la información de destinatarios y de configuración. Para buscar controladores, el Operador de sistema utiliza ADSI con el fin de realizar un enlace sin servidor. El Operador de sistema incluye un componente DSAccess (DSAccess.dll) para permitir el acceso de directorios mediante proxy a Active Directory desde otros componentes de Exchange, como el almacén de Exchange y el motor de transporte SMTP. Además, DSAccess almacena en caché la información de directorios para reducir el número de consultas a Active Directory. Para obtener más información acerca de las funciones de los controladores de dominio y catálogos globales, y de DSAccess, consulte Exchange Server 2003 y Active Directory.

64

Componente

Tarea

Comentarios

Componente DSProxy

Conectar a través de proxy los clientes MAPI heredados a Active Directory

El componente DSProxy de Operador de sistema (Dsproxy.dll) remite Outlook 2000 y las versiones posteriores a un servidor de catálogo global para que el cliente MAPI pueda comunicarse con Active Directory con el fin de obtener acceso a la lista de direcciones global. Además, DSProxy retransmite la comunicación de directorios para clientes MAPI antiguos que no pueden ser remitidos directamente. Para obtener más información acerca de DSProxy, consulte Exchange Server 2003 y Active Directory.

65

Componente

Tarea

Comentarios

Componente de disponibilidad

Mantener la información de disponibilidad para los usuarios de Outlook Web Access

El Operador de sistema interviene cuando se publica información de disponibilidad en Outlook Web Access. Cuando un usuario crea una cita, el almacén de Exchange extrae la información de disponibilidad del calendario del usuario y envía los datos en un mensaje al buzón del Operador de sistema. El componente de disponibilidad (Madfb.dll) procesa estos mensajes y publica la información de disponibilidad en la carpeta pública del sistema SCHEDULE+ FREE BUSY. Para obtener más información acerca de la publicación de información de disponibilidad, consulte Arquitectura del servicio Almacén de información de Exchange.

Componente Administrador de buzones

Administrar buzones

El componente Administrador de buzones aplica directivas de retención de mensajes y cuotas de buzón que puede utilizar para administrar el tamaño de almacén de los buzones.

66

Componente

Tarea

Comentarios

Servicio de actualización de la metabase

Replicar configuraciones de Active Directory a la metabase de IIS

El servicio de actualización del Servicio de directorio a la metabase (Ds2mb.dll) es un componente interno del Operador de sistema. El Servicio de actualización de la metabase replica la configuración del protocolo de Active Directory a la metabase de IIS con el fin de aplicar los valores del protocolo Internet que usted configure en el Administrador del sistema de Exchange a los motores de protocolo Internet, como el servicio SMTP. Para obtener más información acerca del servicio de actualización de la metabase, consulte Exchange Server 2003 y Active Directory.

67

Componente

Tarea

Comentarios

Generador de libretas de direcciones sin conexión

Generar libretas de direcciones sin conexión

El Generador de libretas de direcciones sin conexión (Oabgen.dll) crea listas de direcciones del almacén de Exchange en un servidor de listas de direcciones sin conexión. Después, los usuarios pueden conectarse a este servidor y descargar dichas listas. Las listas de direcciones sin conexión proporcionan acceso a la información de direcciones cuando un usuario trabaja remotamente y no dispone de una conexión permanente al servidor. Dado que estas listas se almacenan en una carpeta pública oculta, es posible replicarlas a varios servidores.

Servicio de actualización de destinatarios

Aplicar directivas de destinatarios y generar direcciones proxy

El Servicio de actualización de destinatarios (Abv_dg.dll) es el componente del Operador de sistema que supervisa todas las directivas de destinatarios y objetos de usuario con correo habilitado y aplica las primeras a los segundos. Para obtener más información acerca del servicio de actualización de destinatarios, consulte Exchange Server 2003 y Active Directory.

68

Componente

Tarea

Comentarios

Componente Monitor de servidores

Supervisar los recursos de servidor

El Operador de sistema supervisa los recursos de servidor de forma periódica y actualiza la información de estado de vínculos (LSI) a través del Instrumental de administración de Windows (WMI). Además, el Operador de sistema actualiza la tabla de enrutamiento para que el motor de enrutamiento pueda adoptar decisiones de enrutamiento fundamentadas según el estado actual de los servidores y conectores. Para obtener más información acerca de la información del estado de los vínculos, consulte Arquitectura de enrutamiento de mensajes. El Operador de sistema también se encarga de mantener los registros de seguimiento de mensajes si se ha habilitado éste en el servidor.

69

•

Componente

Tarea

Comentarios

Componente Operador de sistema

Comprueba la configuración de cuenta de equipo

La cuenta de equipo de un servidor de Exchange debe ser miembro de un grupo de seguridad global denominado Servidores de dominio de Exchange para poder conceder a Exchange Server 2003 los permisos de acceso necesarios para Active Directory. El Operador de sistema comprueba, en segundo plano, que la cuenta de equipo pertenece a este grupo.

Servicio Almacén de información de Exchange El servicio Almacén de información de Microsoft Exchange es otro componente muy importante de Exchange Server 2003, ya que mantiene las bases de datos de mensajería que contienen todos los buzones y carpetas públicas de servidor. El archivo ejecutable del servicio Almacén de información de Exchange es Store.exe y se encuentra en el directorio \Archivos de programa\Exchsrvr\Bin. La clave del Registro correspondiente es HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS. El almacén de Exchange utiliza el Motor de almacenamiento extensible (ESE) para mantener las bases de datos de mensajería y admite una diversidad de clientes mediante las extensiones de almacén correspondientes. La figura siguiente ilustra el modo en que los distintos tipos de cliente pueden obtener acceso a los datos de mensajería.

70

Arquitectura de almacén de Exchange y clientes de mensajería admitidos

Los clientes MAPI se comunican directamente con el servicio Almacén de información de Exchange mediante RPC MAPI. Sin embargo, los clientes de Internet utilizan motores de protocolo integrados con IIS, tal como se explicó anteriormente en esta sección. Los clientes de Internet y las aplicaciones Web se comunican con el almacén de Exchange a través de motores de protocolo de IIS. Esta comunicación se produce a través de un controlador de almacén, Epoxy.dll, y extensiones de almacén, como ExSMTP.dll o ExIMAP.dll. La capa EPOXY es un mecanismo de comunicación entre procesos (IPC) rápido basado en memoria compartida que es utilizada por Drviis.dll y las extensiones de almacén para coordinar su procesamiento. Por ejemplo, cuando se entrega un mensaje entrante a través de SMTP, Drviis.dll utiliza el sistema de archivos instalable de Exchange para crear un mensaje en el almacén de Exchange, y después se comunica con ExSMTP.dll a través de EPOXY para ordenar al almacén de Exchange que continúe procesando el mensaje (es decir, que coloque el mensaje en el buzón del destinatario). Para obtener más información acerca de la interacción entre Drviis.dll, Epoxy.dll, extensiones de almacén, Store.exe y ExIFS, consulte Arquitectura del servicio Almacén de información de Exchange. •

Sistema de archivos instalable de Exchange El sistema de archivos instalable de Exchange es un controlador de modo de núcleo, implementado en ExIfs.sys, que los motores de protocolo de IIS y las aplicaciones Web pueden utilizar para leer y escribir en elementos de bases de datos de mensajería. Para obtener acceso a las bases de datos,

71

el controlador del sistema d de e archivos ExIFS debe comunicarse con el almacén de Exchange. Esto se realiza mediante una extensión del almacén (exWin32.Dll) y un empaquetador de modo de usuario (Ifsproxy.dll). El almacén de Exchange, por otro lado, utiliza ESE para tener acceso a los a archivos rchivos .stm y .edb, que son archivos que se encuentran en una unidad con formato de sistema de archivos NTFS. En la siguiente ilustración se muestra esta arquitectura. Arquitectura de ExIFS

Como se mencionó en Introducción a la Biblioteca técnica de Exchange Server 2003 2003, un almacén de buzones o carpeta pública está formado por una base de datos de secuencias (.stm) y una base de d datos atos MAPI (.edb). Los componentes de IIS utilizan ExIFS para trabajar con bases de datos de secuencias, mientras que los clientes MAPI, como Outlook, trabajan con bases de datos MAPI (.edb). Una base de datos de secuencias aloja mensajes de Internet con su formato nativo, como MIME, mientras que una base de datos .edb almacena mensajes de correo electrónico con formato MAPI. El almacén de Exchange debe mantener sincronizadas las bases de datos de secuencias y las correspondientes bases de datos MAPI. Para e ello, llo, el almacén de Exchange debe comunicarse con ExIFS, además de ESE. Por ejemplo, al asignar espacio libre en una base de datos, ExIFS solicita espacio a ESE. ESE debe realizar un seguimiento de las páginas de la base de datos de secuencias reservadas y consignadas. De este modo, el servicio Almacén de información de Exchange depende de ExIFS. La clave del Registro de ExIFS es HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services HKEY_LOCAL_MACHINE Services\EXIFS. Para obtener más información acerca de ExIFS y la arquitectura del almacén almacén de Exchange, consulte Arquitectura del servicio Almacén de información de Exchange. Exchange Nota: ExIFS es el único componente de modo de núcleo de Exchange Server 2003.

72

Servicios adicionales de Exchange Server 2003 Además de los motores de protocolo de IIS y los servicios básicos de Exchange Server 2003, los siguientes servicios de Exchange proporcionan funciones adicionales: •

Conector de calendario El servicio Conector de calendario permite el uso compartido de información de disponibilidad entre los usuarios de Exchange Server 2003 y los de Lotus Notes o Novell GroupWise. Este servicio depende del registro de sucesos, del servicio Almacén de información de Exchange y del Controlador de conectividad de Microsoft Exchange. Para obtener más información acerca de la arquitectura del Conector de calendario, consulte Arquitectura de los conectores de mensajería de puerta de enlace. El archivo ejecutable es Calcon.exe, que se encuentra en el directorio \Archivos de programa\Exchsrvr\Bin. La clave del Registro es HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeCalCon.

•

Controlador de conectividad El servicio Controlador de conectividad proporciona servicios de soporte para el Conector para Lotus Notes, Conector para Novell GroupWise y el Conector de calendario. Este servicio depende del servicio Registro de sucesos y de Operador de sistema. Para ver información adicional acerca de la arquitectura del Conector de calendario, consulte Arquitectura de los conectores de mensajería de puerta de enlace. El archivo ejecutable es Lscntrl.exe, que se encuentra en el directorio \Archivos de programa\Exchsrvr\Bin. La clave del Registro es HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeCOCO.

•

Conector para Lotus Notes El servicio Conector para Lotus Notes permite la transferencia de mensajes y la sincronización de directorios entre Exchange Server 2003 y Lotus Notes. Este servicio depende del Registro de sucesos, del Controlador de conectividad y del servicio Almacén de información de Exchange. Para obtener más información acerca de la arquitectura del Conector para Lotus Notes, consulte Arquitectura de los conectores de mensajería de puerta de enlace. El archivo ejecutable es Dispatch.exe, que se inicia con parámetros de línea de comandos LME-NOTES para ejecutar procesos del conector específicos de Lotus Notes. Dispatch.exe se encuentra en el directorio \Archivos de programa\Exchsrvr\Bin. La clave del Registro es HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LME-NOTES.

•

Conector para Novell GroupWise El servicio Conector para Novell GroupWise permite la transferencia de mensajes y la sincronización de directorios entre Exchange Server 2003 y Novell GroupWise. Este servicio depende del Registro de sucesos, del Controlador de conectividad, del Enrutador para Novell GroupWise y del servicio Almacén de información de Exchange. Para obtener más información acerca de la arquitectura del Conector para Novell GroupWise, consulte Arquitectura de los conectores de mensajería de puerta de enlace.

73

El archivo ejecutable es Dispatch.exe, que se inicia con parámetros de línea de comandos LME-GWISE para ejecutar procesos del conector específicos de Novell GroupWise. Dispatch.exe se encuentra en el directorio \Archivos de programa\Exchsrvr\Bin. La clave del Registro es HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LME-GWISE. •

Servicio de sucesos de Exchange El Servicio de sucesos de Exchange supervisa las carpetas y desencadena sucesos de secuencias de servidor que son compatibles con Exchange Server 5.5. Este servicio es necesario únicamente cuando se ejecutan aplicaciones compatibles con Exchange Server 5.5 en un servidor de Exchange Server 2003. De manera predeterminada, está deshabilitado. Este servicio depende del servicio Almacén de información de Exchange. El archivo ejecutable es Events.exe, que se encuentra en el directorio \Archivos de programa\Exchsrvr\Bin. La clave del Registro es HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeES.

•

Servicio Administración de Exchange Este servicio proporciona información de administración de Exchange a través del Instrumental de administración de Windows (WMI). Si se detiene este servicio, no funcionarán los proveedores WMI implementados para funcionar en Administración de Microsoft Exchange, como el seguimiento de mensajes y el acceso a Active Directory. Por este motivo, debe dejar que se ejecute este servicio en todos los servidores de Exchange Server, de modo que pueda ver y establecer los controladores de dominio y los servidores de catálogo global de un servidor de Exchange Server 2003, así como utilizar el centro de seguimiento de mensajes para auditar el flujo de mensajes que pasa por Exchange. Para proporcionar acceso al directorio, puede utiliza el Administrador del sistema de Exchange para configurar manualmente un controlador de dominio o un servidor de catálogo global (abra la página Propiedades del servidor y utilice las opciones de la ficha Acceso al directorio). De este modo, los servidores de Exchange Server utilizarán los servidores especificados para tener acceso al directorio. El servicio Administración de Exchange depende del servicio Llamada a procedimiento remoto (RPC) y del servicio Instrumental de administración de Windows (WMI). El archivo ejecutable es Exmgmt.exe, que se encuentra en el directorio \Archivos de programa\Exchsrvr\Bin. La clave del Registro es HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeMGMT.

•

Servicio Pila MTA de Microsoft Exchange El servicio Pila MTA de Microsoft Exchange (MTA) enruta mensajes a través de X.400 y conectores de puerta de enlace a sistemas de mensajería que no son de Exchange. En un entorno mixto con servidores de Exchange Server 5.5 en el grupo de enrutamiento local, también se utiliza el servicio MTA para transferir mensajes entre Exchange Server 2003 y Exchange Server 5.5. Esto sucede debido a que las MTA de Exchange Server 5.5 se comunican entre sí en el sitio local de forma directa mediante RPC. Exchange Server 2003 debe utilizar este método de comunicación para mantener la compatibilidad con versiones anteriores. El archivo ejecutable del servicio Pila MTA de Microsoft Exchange MTA es EMSMTA.exe, que se encuentra en el directorio \Archivos de programa\Exchsrvr\bin.

74

Este servicio depende del Operador de sistema y mantiene sus colas de mensajes específicas fuera del de almacén de Exchange en el directorio \Archivos Archivos de programa\Exchsrvr\Mtadata. Mtadata. La clave del Registro es HKEY_Local_Machine\ \System\CurrentControlSet\Services\MSExchangeMTA MSExchangeMTA. Nota: Debe dejar que se ejecute el servicio Pila MTA de Microsoft Exchange MTA, de modo que los monitores de servidor en su configuración predeterminada no notifiquen que un servidor de Exchange Server no está disponible. Para obtener más información acerca del seguimiento del estado del servidor, consulte Arquitectura del Administrador del sistema de Exchange. Exchange •

Enrutador para Novell GroupWise El servicio Enrutador para Novell GroupWise funciona junto con el Conector Conector para Novell GroupWise para transferir mensajes y realizar la sincronización de directorios entre Exchange Server 2003 y Novell GroupWise. El servicio Enrutador para Novell GroupWise actúa como interfaz de la puerta de enlace API de Novell GroupWise, mientras mientras que el Conector para Novell GroupWise actúa como interfaz de Exchange Server 2003. Para obtener más información acerca de la arquitectura del Conector para Novell GroupWise, consulte Arquitectura de los conectores de mensajería de puerta de enlace. enlace El servicio Enrutador para Novell GroupWise depende del Operador de sistema. El archivo ejecutable es GWRouter.exe, que se encuentra encuentra en el directorio \Archivos de programa\Exchsrvr\Bin. Bin. La clave del Registro es HKEY_LOCAL_MACHINE\ \System\CurrentControlSet\Services\MSExchangeGWRtr MSExchangeGWRtr.

•

Motor de enrutamiento El servicio Motor de enrutamiento proporciona información de topología y enrutamiento utamiento a los servidores de Exchange Server 2003. El motor de cola avanzada del subsistema de transporte SMTP utiliza dicho servicio para proporcionar información del siguiente salto a la hora de enrutar mensajes en la organización de Exchange. Si se detiene iene el servicio, no se realizará un enrutamiento óptimo de los mensajes. Para obtener información adicional acerca del servicio Motor de enrutamiento y su función en la entrega de mensajes, consulte Arquitectura de transporte SMTP. SMTP El servicio Motor de enrutamiento depende de IIS Admin y se ejecuta dentro del proceso Inetinfo.exe. Este servicio se implementa en un archivo denominado RESvc.dll, que se encuentra en n el directorio \Archivos de programa\Exchsrvr\Bin. Bin. La clave del Registro es HKEY_LOCAL_MACHINE\ \System\CurrentControlSet\Services\RESvc.

•

Servicio de replicación de sitios El Servicio de replicación de sitios (SRS) proporciona una integración de directo directorios entre Exchange Server 5.5 y Exchange Server 2003. SRS se ejecuta en Exchange Server 2003 y funciona como un directorio modificado de Exchange Server 5.5. Exchange server 5.5 responde a SRS como otro asociado de replicación de directorios de Exchange Server S 5.5. SRS se habilita automáticamente en el primer servidor que se une a un sitio de Exchange Server 5.5. Cuando se quita el último servidor de Exchange Server 5.5 de la red, se puede deshabilitar SRS.

75

SRS no tiene dependencias de servicios. Este servicio se implementa en un archivo ejecutable denominado srsmain.exe, que se encuentra en el directorio \Archivos de programa\Exchsrvr\Bin. La clave del Registro es HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeSRS.

La figura siguiente ilustra el modo en que los servicios adicionales se integran con los servicios básicos de Exchange, de IIS y del sistema operativo. Servicios básicos y adicionales de Exchange Server 2003

Para detener todos los servicios de Exchange Server 2003 de un servidor, debe detener el Operador de sistema, el servicio IIS Admin, ExIFS y SRS (si este servicio se está ejecutando), así como todos los servicios dependientes. Para obtener instrucciones detalladas acerca de cómo detener todos los servicios de Exchange Server 2003 en un servidor, consulte Cómo detener todos los servicios de Exchange Server 2003 de un servidor.

Cómo detener todos los servicios de Exchange Server 2003 de un servidor En este tema se explica cómo detener todos los servicios de Exchange Server 2003 en un servidor.

76

Antes de empezar Antes de realizar el procedimiento de este tema, tenga en cuenta lo siguiente: •

Para detener todos los servicios de Exchange Server 2003 de un servidor, debe detener el Operador de sistema, el servicio IIS Admin, ExIFS y SRS (si este servicio se está ejecutando), así como todos los servicios dependientes. El modo más sencillo de reiniciar todos los servicios consiste en reiniciar el servidor.

Procedimiento Detenga todos los servicios de Exchange Server 2003 en un servidor 1. Utilice el comando net stop MSExchangeSA /y para detener el Operador de sistema y todos sus servicios dependientes. 2. Utilice el comando net stop IISAdmin /y para detener todos los motores de IIS. 3. Utilice el comando net stop ExIFS el controlador del sistema de archivos instalable de Exchange (ExIFS). 4. Utilice el comando net stop MSExchangeSRS para detener SRS.

Exchange Server 2003 y Active Directory Microsoft Exchange Server 2003 depende completamente del servicio de directorio Microsoft Active Directory para sus operaciones de directorio. Active Directory proporciona toda la información acerca de buzones, servicios de listas de direcciones y otra información relacionada con el destinatario. La mayor parte de la información de configuración de Exchange 2003 se almacena también en Active Directory. Operador de sistema es el componente de Exchange 2003 que se encarga de administrar el acceso a directorios. Operador de sistema incluye diversos componentes internos, como DSAccess y DSProxy, que se comunican con Active Directory y almacenan en caché la información de directorios para aumentar la velocidad a la cual se recupera la información de los directorios y para reducir la carga de trabajo en los controladores de dominio y los servidores de catálogo globales. Esta sección describe los componentes de acceso a directorios de Exchange Server 2003, su objetivo, su arquitectura y la forma en que trabaja la tecnología básica. Esta información puede ayudarle a mantener el acceso a directorios y a solucionar los problemas relacionados el mismo. En esta sección se explican los siguientes conceptos: •

Extensión del esquema de Active Directory Exchange extiende el esquema de Active Directory y aprovecha Active Directory para la información de configuración y del destinatario.

77

•

Diferencias entre los controladores de dominio y los servidores de catálogo globales Un servidor de catálogo global siempre es un controlador de dominio, pero lo mismo no siempre sucede a la inversa. En esta sección se describen las diferencias, incluidos los motivos por los cuales Exchange Server 2003 debe comunicarse con controladores de dominio y servidores de catálogo global.

•

El componente Directory Service Access de Exchange Server 2003 El componente Acceso al servicio de directorio (DSAccess) es un componente interno del Operador de sistema que se utiliza para obtener acceso y almacenar información de directorios. DSAccess detecta de forma estática o dinámica los servidores del servicio de directorio de la organización.

•

Componente DSProxy de Exchange Server 2003 DSProxy permite la comunicación entre equipos de Active Directory y de Exchange 2003. DSProxy proporciona servicios de referencia y proxy a los clientes MAPI, como las últimas versiones de Microsoft Office Outlook.

•

Categorizador SMTP del motor de transporte de Exchange El categorizador SMTP debe comunicarse con Active Directory para resolver información de destinatarios y determinar las restricciones de mensajes durante su transferencia. Aunque el categorizador utiliza DSAccess, también usa su propio mecanismo para comunicarse con Active Directory.

•

Servicio de actualización de destinatarios Exchange Server 2003 se comunica con los servidores de directorios para actualizar objetos de destinatario (como cuentas de usuario con buzón habilitado o grupos con correo habilitado) con direcciones de correo electrónico, siguiendo las directivas de destinatarios definidas para la organización.

•

Servicio de actualización de la metabase El servicio de actualización de la metabase debe comunicarse con Active Directory para obtener los valores de configuración relacionados con los componentes de los Servicios de Internet Information Server (IIS), como el servicio de Protocolo simple de transferencia de correo (SMTP) y el servicio World Wide Web. Es tarea del servicio de actualización de la metabase la transferencia de estos valores de configuración a la metabase de IIS.

Para obtener más información acerca del planeamiento, el diseño y la implementación de Exchange 2003, consulte las guías siguientes: •

Planning an Exchange Server 2003 Messaging System

•

Exchange Server 2003 Deployment Guide

Integración de directorios y Exchange Server 2003 La información de Exchange Server 2003 en Active Directory incluye datos acerca de los destinatarios y datos de configuración relativos a la organización de la mensajería. Active Directory proporciona el subsistema de seguridad para Exchange Server 2003. La seguridad

78

de Active Directory asegura que únicamente los usuarios autorizados autorizados puedan tener acceso a los buzones y que únicamente los administradores autorizados puedan modificar la configuración de Exchange de la organización. Las tres particiones de directorio siguientes de Active Directory contienen datos relacionados con Exchange: •

Partición de directorio de dominio Los objetos del sistema y de destinatario de Exchange están almacenados en la partición de directorio de dominio de Active Directory. La partición de directorio de dominio se replica a cada controlador de dominio nio de un dominio determinado.

•

Partición de directorio de configuración Los objetos de configuración de Exchange, como los grupos administrativos, los valores de configuración globales, las directivas del destinatario, las directivas del sistema y las listas de direcciones o la información de direcciones se almacenan en la partición de directorio de configuración. La partición de directorio de configuración se replica a todos los controladores de dominio del bosque.

•

Partición de directorio de esquema Las modificaciones de esquema de Exchange (por ejemplo, clases y atributos) se almacenan en la partición de directorio de esquema. La partición de directorio de esquema se replica a todos los controladores de dominio del bosque. Nota: No toda la información de configuración se almacena en Active Directory. Exchange utiliza también el Registro local, la metabase de IIS y, en situaciones especiales, archivos de configuración.

Clases y atributos de Exchange en Active Directory El esquema de Active Directory Directory define las clases de objeto que pueden crearse en el directorio y los atributos que pueden asignarse a cada instancia de un objeto. Durante la instalación del primer servidor de Exchange 2003 en un bosque de Active Directory, Exchange debe modifica modificar este esquema para que Active Directory pueda almacenar información de configuración y de destinatarios específica de Exchange. El proceso ForestPrep del programa de instalación de Exchange extiende el esquema de Active Directory. También puede ejecutar este este proceso de forma explícita utilizando la línea de comandos Setup/ForestPrep para agregar clases y atributos específicos de Exchange al esquema de Active Directory, sin llegar a instalar un servidor. Este paso adicional es necesario si la persona que instala in Exchange Server 2003 no tiene derechos de administrador de esquema. El programa de instalación de Exchange Server 2003 extiende el esquema de Active Directory importando una serie de archivos .ldf en Active Directory. A excepción de Exschema.ldf, todos os los archivos .ldf están en el directorio \Setup\i386\Exchange Exchange del CD del producto. El archivo Exschema.ldf está en el directorio \Setup\i386\Exchange Exchange\Bin.

79

En la tabla siguiente aparecen listados los diversos archivos .ldf que definen los objetos y atributos de Exchange Server 2003. Archivos de instalación de Exchange Server 2003 con extensiones de esquema de Active Directory Nombre de archivo

Descripción

Schema0.ldf

Incluye extensiones de esquema para objetos de destinatario, como la definición de los atributos de extensión de Exchange, que puede utilizar para asignar información, no tratada por ninguno de los atributos estándar, a los objetos de destinatario.

Schema1.ldf

Incluye extensiones de esquema para el Conector de Active Directory, que puede utilizar para integrar una organización de Exchange Server 5.5 con Active Directory.

Schema2.ldf

Incluye extensiones de esquema para protocolos de acceso a Internet, sincronización de directorios y objetos de configuración de almacén de Exchange.

Schema3.ldf

Incluye extensiones de esquema para la supervisión del sistema, objetos de configuración del Conector para Lotus Notes, valores de configuración de libreta de direcciones sin conexión y valores de configuración pertenecientes a conectores X.400.

Schema4.ldf

Incluye extensiones de esquema para grupos de enrutamiento, servidores de cabeza de puente, contenedores de protocolo, bases de datos de mensajería, servicios de listas de direcciones y objetos de configuración de MTA de Microsoft Exchange.

Schema5.ldf

Incluye extensiones de esquema para contenedores de protocolo, conectores de grupos de enrutamiento y parámetros que pertenecen al Motor de almacenamiento extensible (ESE).

80

Nombre de archivo

Descripción

Schema6.ldf

Incluye extensiones de esquema para servidores virtuales de protocolo, grupos administrativos, conectores de mensajería y el almacén de Exchange.

Schema7.ldf

Incluye extensiones de esquema para bases de datos de mensajería y el administrador de buzones.

Schema8.ldf

Incluye extensiones de esquema para el administrador strador de buzones, la supervisión del sistema, carpetas públicas y objetos de configuración de transporte SMTP.

Schema9.ldf

Incluye extensiones de esquema para el Conector de calendario, el Conector para Novell GroupWise, las listas de distribución dinámicas icas y Outlook Mobile Access. Nota: Los archivos Schema1.ldf a Schema8.ldf son idénticos para Exchange 2000 Server y Exchange Server 2003. El archivo Schema9.ldf contiene las extensiones de esquema nuevas en Exchange Server 2003.

Exschema.ldf

Agrega los atributos Object-GUID, Object Replication-Signature, Signature, Unmerged-Attributes Unmerged y ADC-Global-Names Names al esquema para actualizar un esquema anterior a Exchange 2000 Service Pack 1 con la información necesaria para Exchange Server 2003.

Nota: Puede utilizar archivos .l .ldf df junto con herramientas de bajo nivel de Active Directory, como Ldifde.exe, para reparar un esquema dañado de Active Directory. La solución de problemas del esquema de Active Directory, no obstante, queda fuera del alcance de este manual. Tenga en cuenta que los cambios de esquema pueden restablecer el catálogo global, en cuyo caso todos los destinatarios de objetos deben ser

81

replicados de nuevo al catálogo global. Esto puede causar aumentos significativos en el tráfico de datos en las organizaciones de gran g tamaño.

Acceso al servicio de directorio Los servicios de Exchange 2003 tienen acceso a información que se almacena en Active Directory y escriben información en Active Directory. Si esta comunicación se produce directamente entre cada servicio y Active Activ Directory, Exchange 2003 podría saturar un controlador de dominio de Active Directory con solicitudes de comunicación. Se necesita un componente central para simplificar la comunicación con Active Directory. Este componente es el módulo DSAccess. DSAccesss es una API compartida que utilizan diversos componentes de Exchange 2003 para realizar consultas a Active Directory y obtener información de configuración y de destinatarios. DSAccess se implementa en DSAccess.dll, que se carga en componentes de Exchange y que no son de Exchange, incluido el Operador de sistema, el agente de transferencia de mensajes, el servicio Almacén de información de Microsoft Exchange, el Servicio de administración de Exchange, los Servicios de Internet Information Server (IIS) y el Instrumental de administración de Windows (WMI). DSAccess descubre la topología de Active Directory, detecta controladores de dominio y servidores de catálogo globales y mantiene una lista de los servidores de directorio válidos adecuados para ser utilizados utiliza por los componentes de Exchange. Además, DSAccess mantiene una caché que se utiliza para minimizar la carga en Active Directory reduciendo el número de solicitudes del Protocolo compacto de acceso a directorios (LDAP) que los componentes individuales e envían a los servidores de Active Directory. Importante: DSAccess.dll es el archivo DLL principal que implementa DSAccess. Para que funcione correctamente, la versión de DSAccess.dll debe coincidir con la versión de los archivos DLL que lo acompañan. Los archivos DLL que lo acompañan, Dscmgs.dll y Dscperf.dll, almacenan cadenas de mensaje de registro de sucesos y proveedores de objetos de rendimiento, respectivamente. DSAccess crea particiones en los servidores de servicio de directorios disponibles en las tres categorías siguientes (que posiblemente se superponen): •

Servidores de catálogo global Exchange Server 2003 debe tener acceso a los servidores de catálogo global para obtener información de la dirección completa de todos los objetos de destinatario del bosque. Únicamente los servidores de catálogo global contienen una réplica completa de todos los objetos del dominio y una réplica parcial de todos los objetos del bosque. Los servidores de catálogo global que utiliza actualmente un servidor de Exchange se llaman servidores de catálogo global en funcionamiento. Prácticamente todas las transacciones transacciones del servicio de directorio de contexto de usuario tienen como destino catálogos globales. Independientemente del número de servidores de catálogo global que estén ubicados en el sitio local de Active Directory, pueden agregarse un máximo de diez servidores de catálogo global a la lista de catálogos

82

globales en funcionamiento. Si no hay servidores de catálogo global en el sitio local, o si ninguno de los servidores de catálogo global del sitio local pasa la prueba de idoneidad, DSAccess utiliza un máximo de 200 servidores de catálogo global que están fuera del sitio con los costos más bajos. Como el servidor del servicio de directorio utilizado para un catálogo global es también propiamente un controlador de dominio, este servidor puede utilizarse como los dos tipos de directorios. •

Controladores de dominio Los controladores de dominio se utilizan para solicitudes de contexto de usuario cuando el servicio solicitante dispone de conocimiento suficiente acerca de la ubicación del objeto de usuario solicitado en la búsqueda emitida. A estos controladores de dominio se les llama también controladores de dominio en funcionamiento. Los controladores de dominio en funcionamiento son controladores de dominio del dominio local que pueden aceptar consultas de contexto de nomenclatura del dominio. Independientemente del número de controladores de dominio que estén ubicados en el sitio local de Active Directory, pueden agregarse un máximo de diez controladores de dominio a la lista de controladores de dominio en funcionamiento. Si no hay controladores de dominio en el sitio local, o si ninguno de los controladores de dominio del sitio local pasa la prueba de idoneidad, DSAccess utiliza controladores de dominio que están fuera del sitio con los costos más bajos. Se aplica un equilibrio de carga por turnos a las consultas a los controladores de dominio en funcionamiento, para evitar la sobrecarga de un único controlador de dominio. Si los controladores de dominio en funcionamiento no están protegidos en el registro, la lista de controladores de dominio en funcionamiento vuelve a evaluarse y a generarse cada 15 minutos utilizando el proceso de descubrimiento de topología y las pruebas de idoneidad.

•

Controladores de dominio de configuración Exchange Server 2003 puede leer múltiples controladores de dominio. Para evitar conflictos al aplicar modificaciones a la configuración de Active Directory, Exchange Server 2003 escribe su información de configuración en un único controlador de dominio, llamado el controlador de dominio de configuración. Al seleccionar un controlador de dominio de configuración de la lista de controladores de dominio en funcionamiento, DSAccess da preferencia a un controlador de dominio sobre el servidor de catálogo global. Además, DSAccess da preferencia a un servidor de directorio del sitio local antes de utilizar un servidor de directorio de un sitio secundario. Si el controlador de dominio de configuración deja de estar disponible para Exchange Server 2003 por cualquier motivo, DSAccess selecciona otro controlador de dominio en funcionamiento como su controlador de dominio de configuración. Cada ocho horas, DSAccess vuelve a evaluar la función del controlador de dominio de configuración ejecutando un conjunto de pruebas de idoneidad. Si las pruebas son satisfactorias, DSAccess sigue usando el mismo controlador de dominio de configuración. Si las pruebas fallan, DSAccess elige otro controlador de dominio de la lista de controladores de dominio en funcionamiento como controlador de dominio de configuración.

83

Los componentes básicos de Exchange Server 2003 se basan en DSAccess para proporcionar una lista actualizada de servidores de Active Directory. Por ejemplo, el agente de transferencia de mensajes (MTA) dirige las solicitudes de LDAP a través travé de la capa de DSAccess a Active Directory. Para conectarse a las bases de datos, el proceso de almacén utiliza DSAccess para obtener información de configuración de Active Directory. Para enrutar mensajes, el proceso de transporte utiliza DSAccess para obtener obtener información acerca de la organización de conectores. DSAccess actualiza la lista de controladores de dominio y catálogos globales disponibles a medida que se detectan modificaciones en el servicio de directorio. Esta lista puede compartirse con otross consumidores de directorios que no utilizan DSAccess como puerta de enlace para obtener acceso al servicio de directorio (por ejemplo, DSProxy y otros componentes del Operador de sistema). El servicio que solicita la lista es el responsable de la detección ón de las modificaciones subsiguientes del estado del servicio de directorio. Nota: A no ser que los controladores de dominio y los servidores de catálogo global estén protegidos en el registro, la lista de servidores de catálogo global y controladores de d dominio volverá a evaluarse y a generarse cada 15 minutos utilizando un proceso de descubrimiento de topología y pruebas de idoneidad.

Equilibrio de carga y conmutación por error de la conexión LDAP En Exchange Server 2003, DSAccess determina la topología topologí de Active Directory, abre las conexiones LDAP adecuadas y soluciona los errores del servidor. Para cada servidor de servicio de directorio disponible, DSAccess abre conexiones LDAP dedicadas exclusivamente a cada proceso que utiliza DSAccess. DSAccess actualiza actualiza estas conexiones LDAP con información del estado del servicio de directorio (activo, lento o desconectado) que detecta. DSAccess utiliza esta información de estado para decidir qué conexión LDAP debe utilizar para enviar solicitudes a Active Directory. ory. El conjunto de conexiones LDAP a controladores de dominio disponibles y servidores de catálogo globales y sus estados asociados forma el perfil de DSAccess. DSAccess admite un mecanismo de equilibrio de carga que distribuye por turnos peticiones de servicio ervicio de directorio de contexto del usuario entre las conexiones LDAP del perfil de DSAccess. El equilibrio de carga ayuda a asegurar la confiabilidad y la escalabilidad. Puede configurar de forma estática todos los perfiles del registro para utilizar ex exclusivamente clusivamente un conjunto específico de servidores del servicio de directorio. Sin embargo, el estado actual y el equilibrio de carga de estas conexiones pueden variar entre los distintos procesos (de perfil a perfil). Esto no sucede en el caso de las solicitudes solicitudes de contexto de configuración. Nota: Dado que todos los servicios de IIS y Exchange Server 2003 utilizan el mismo contexto de seguridad (la cuenta LocalSystem), DSAccess puede reutilizar las

84

conexiones LDAP entre solicitudes. Durante el arranque o cuando se produce una modificación de topología, DSAccess abre conexiones LDAP a todos los servidores de catálogo global y controladores de dominio adecuados de la topología. Cuando la implementación basada en Microsoft Windows de LDAP (WLDAP) devuelve un error de una operación de LDAP, DSAccess la analiza y determina si indica que el servidor de directorios está teniendo algún problema. En caso afirmativo, el servidor de directorios se marca inmediatamente como no adecuado, y la operación del usuario vuelve vuelv a intentarse automáticamente en un servidor distinto. Si existe por lo menos un controlador de dominio en funcionamiento en la topología, DSAccess puede continuar realizando la operación sin ningún tipo de problema. Para comprobar la idoneidad de un controlador controlador de dominio o de un servidor de catálogo global, DSAccess determina que pueda establecerse comunicación con el servidor a través del puerto 389 (controlador de dominio) y el puerto 3268 (servidor de catálogo global) y que resida en un dominio que ha sido preparado con DomainPrep. DomainPrep asegura que la lista de control de accesos (ACL) del sistema de directivas de grupo esté configurada correctamente para confirmar que los servicios de Exchange Server 2003 tengan acceso a Active Directory. Las com comprobaciones probaciones de idoneidad del servidor se tratan más adelante en esta misma sección. Sugerencia: Para obtener informes de idoneidad en el registro de sucesos de la aplicación, puede habilitar el registro de diagnósticos para la categoría de topología del servicio DSAccess en el Administrador del sistema de Exchange. La topología de DSAccess siempre contiene dos listas, la lista del sitio y la lista de fuera del sitio. Una lista (la del sitio) contiene servidores del sitio Active Directory local del servidor servid Exchange y la otra lista (la de fuera del sitio) contiene servidores de otros sitios de Active Directory. Inicialmente, DSAccess utiliza únicamente servidores del sitio local, pero cuando ninguno de los servidores locales de una categoría determinada (por (p ejemplo, servidores de catálogo global) es adecuado, DSAccess se inicia inmediatamente utilizando la lista de servidores de fuera del sitio. Después, DSAccess sigue comprobando el sitio local cada cinco minutos y realiza una conmutación por recuperación lo más pronto posible. Las solicitudes del usuario se reintentan en los servidores de fuera del sitio inmediatamente y sin problemas para los usuarios. Algunos componentes de Exchange Server 2003, como el servicio Motor de enrutamiento de Exchange, se registran gistran también con Active Directory para ser informados automáticamente por Active Directory acerca de cualquier modificación en la información de configuración. Este mecanismo de notificación elimina el sondeo, pero el registro de sucesos se realiza por servidor de destino. Si DSAccess marca el servidor de destino como inactivo, vuelve a emitir el registro de sucesos e informa al proceso del cliente, como el servicio Motor de enrutamiento, acerca de una modificación, ya que los valores supervisados podrían podría haberse modificado durante el proceso de selección de un nuevo controlador de dominio o servidor de catálogo global.

85

Descubrimiento de la topología de DSAccess Durante el inicio, DSAccess utiliza un proceso de descubrimiento para identificar la topología de Active Directory y evaluar la disponibilidad de controladores de dominio y servidores de catálogo global. Cuando ha finalizado el inicio (y posteriormente cada 15 minutos), DSAccess utiliza un proceso prácticamente idéntico para volver a descubrir la topología t y comprobar cualquier posible modificación en la disponibilidad del servidor. Nota: Si ha protegido los servidores de directorio que utiliza DSAccess (como se ha descrito anteriormente), DSAccess omite el proceso de descubrimiento y únicamente comprueba la idoneidad del servidor. La lista secuencial que se proporciona a continuación resume el proceso de descubrimiento e indica las diferencias entre el descubrimiento inicial y el redescubrimiento: 1. El proceso del Operador de sistema (Mad.exe) ccrea rea instancias e inicializa el archivo DSAccess.dll durante el inicio. 2. Desde el dominio local, DSAccess abre una conexión LDAP con un controlador de dominio elegido aleatoriamente. Se hace referencia a este servidor como servidor de descubrimiento. SAccess lee el Registro local para determinar si la topología está protegida. Si la 3. DSAccess topología está protegida, se detiene el proceso de descubrimiento. Si no se detecta ninguna protección, DSAccess sigue con el proceso de descubrimiento. 4. DSAccess consulta ta al servidor de descubrimiento para identificar controladores de dominio y servidores de catálogo global locales. DSAccess determina posteriormente la idoneidad del servidor y asigna funciones de servidor. 5. DSAccess consulta al servidor de descubrimien descubrimiento to para determinar si uno o más sitios secundarios están conectados con el sitio local. Si existe el sitio secundario, DSAccess ordena los objetos siteLink de cada sitio, empezando por los de costo menor y acabando por los de costo más elevado. DSAccess co coloca loca los sitios de menor costo en una lista de topología secundaria. 6. DSAccess consulta al servidor de descubrimiento para identificar los controladores de dominio y los servidores de catálogo global que están ubicados en los sitios de topología secundaria. 7. DSAccess identifica la topología completa y compila una lista de controladores de dominio en funcionamiento, y una lista de servidores de catálogo global en funcionamiento. De forma predeterminada, la inicialización de DSAccess durante el arranque debe d finalizar en un minuto; de otro modo, DSAccess se detiene. Normalmente un minuto es tiempo suficiente para que DSAccess se inicialice. Si la inicialización tarda más de un minuto, podría indicar la presencia de un problema con la configuración de la topología topología o la red. Aunque puede extender el parámetro de tiempo de espera estableciendo una clave de Registro,

86

primero debe determinar el motivo por el cual la inicialización tarda más de lo esperado. Para configurar el tiempo de espera, utilice la siguient siguiente e configuración del Registro. Ubicación

HKEY_LOCAL_MACHINE\SYSTEM SYSTEM \CurrentControlSet\Services Services\MSExchangeDSAc cess

Valor

TopoCreateTimeoutSecs

Tipo

REG_DWORD

Descripción

Establece el valor de tiempo de espera de inicialización de DSAccess en segundos, por ejemplo 0x200. El valor predeterminado es 0x3C segundos (1 minuto).

Nota: Si establece el nivel de registro de diagnósticos de todas las categorías del servicio MSExchangeDSAccess changeDSAccess con el nivel Máximo,, el Administrador del sistema de Exchange obtiene automáticamente información detallada acerca de la inicialización de DSAccess y coloca dicha información en el registro de sucesos de la aplicación.

Descubrimiento inicial y descubrimiento continuo Cuando DSAccess descubre la topología de Active Directory, determina si la lista descubierta de controladores de dominio y servidores de catálogo global en funcionamiento es adecuada para ser utilizada. Durante el descubrimiento inicial y el redescubrimiento continuo, DSAccess determina la idoneidad de los servidores ejecutando una serie de pruebas de idoneidad. Las pruebas de idoneidad pueden clasificarse en dos categorías: pruebas exhaustivas y pruebas generales. Las pruebas exhaustivas exhaustivas determinan si el controlador de dominio o el catálogo global es un candidato viable para ser utilizado. Si el servidor no pasa las pruebas exhaustivas, se considera como no utilizable, se quita de la lista de servidores descubiertos y ya no se ejecutan ejecutan las pruebas generales. DSAccess ejecuta las siguientes pruebas exhaustivas de idoneidad: •

Capacidades del catálogo global DSAccess determina si el servidor de directorios está especificándose a sí mismo como servidor de catálogo global, mediante la determinación de si el atributo isGlobalCatalogReady del objeto RootDSE del servidor se establece como TRUE. Si el atributo se establece como TRUE, el servidor de directorios se determina como un controlador global válido y utilizable.

•

Accesibilidad DSAccess utiliza el Protocolo de mensajes de control de Internet (ICMP) para emitir un comando ping a cada servidor para comprobar que está disponible. DSAccess comprueba también que el servidor de directorios es accesible a través del

87

puerto 389 (para los os controladores de dominio) y el puerto 3268 (para los servidores de catálogo global). Si utiliza ICMP para determinar si un servidor está disponible, puede originar un problema si ninguna de las conexiones de la red admite ICMP. Por ejemplo, un servidor servido de Exchange puede residir en una red perimetral, sin conectividad ICMP entre el servidor de Exchange y los controladores de dominio. En esta situación, debería deshabilitar la comprobación de ICMP y establecer el siguiente parámetro del Registro como cero. cer Ubicación

HKEY_LOCAL_MACHINE\SYSTEM SYSTEM \CurrentControlSet\Services Services\MSExchangeDSAc cess

Valor

LdapKeepAliveSecs

Tipo

REG_DWORD

Información del valor

0x0

Descripción

Si la clave del Registro no existe o no se establece en 0, DSAccess utiliza el protocolo ping.

Para obtener más información acerca de la clave del Registro LdapKeepAliveSecs, consulte el artículo 320529 de Microsoft Knowledge Base ""XADM: XADM: Using DSAccess in a Perimeter eter Network Firewall Scenario Requires a Registry Key Setting". Setting Precaución: La modificación incorrecta del Registro puede ocasionar problemas graves que quizás requieran volver a instalar el sistema operativo. Es posible que los problemas derivados de una modificación incorrecta del Registro no se puedan resolver. Antes de modificar el Registro, se recomienda realizar una copia de seguridad de todos los datos importantes. •

Permiso SACL de la Directiva de grupos Junto con los permisos de las listas de control de acceso habituales (ACL), la instalación garantiza a todos los servidores que ejecutan listas de control de acceso de seguridad (SACL) de Exchange 2003 Server permiso para ver atributos ntSecurityDescriptor. El permiso se garantiza a través del privilegio SeSecurityPrivilege. DSAccess lee el descriptor de seguridad del objeto de la partición de directorio de configuración, en el servidor, para comprobar que la SACL es legible. Si la SACL no se puede leer, DSAccess considera que el servidor no es adecuado.

•

Datos críticos El servidor de directorios debe estar ubicado en un dominio en el cual se ejecute DomainPrep. El dominio debe contener el objeto servidor de Exchange Server 2003 en el contenedor de configuración de Exchange.

88

•

Sincronización DSAccess comprueba que el servidor está sincronizado determinando si el atributo isSynchronized del objeto rootDSE del servidor está establecido como TRUE.

•

Netlogon DSAccess envía una llamada a procedimiento remoto (RPC) DSGetDcName al servidor de directorios para probar su idoneidad general. Si el servidor de directorios no está sincronizado, si se queda sin disco o si experimenta otros problemas, no se identificará a si mismo como servidor de directorios. En una red perimetral, en la cual no se permite el tráfico RPC, no puede producirse la comprobación NetLogon. Sin embargo, la comprobación NetLogon sigue emitiendo llamadas RPC hasta que se produce un error, lo cual tarda mucho tiempo en suceder. Dado que las comprobaciones NetLogon reducen el rendimiento, debería hacer que DSAccess dejara de emitir comprobaciones NetLogon, creando la siguiente clave del Registro. Ubicación

HKEY_LOCAL_MACHINE\SYSTEM \CurrentControlSet\Services\MSExchangeDSAc cess

Valor

DisableNetLogonCheck

Tipo

REG_DWORD

Información del valor

0x0

Descripción

Si la clave del registro no existe o no se establece en 0, DSAccess realiza la comprobación Netlogon.

Para obtener más información, consulte el artículo 320228 de Microsoft Knowledge Base "XGEN: The "DisableNetLogonCheck" Registry Value and How to Use ItXGEN: The "DisableNetLogonCheck" Registry Value and How to Use It". •

Versión del sistema operativo Exchange Server 2003 puede utilizar únicamente controladores de dominio y servidores de catálogo global que ejecuten Microsoft Windows Server 2003 o Windows 2000 Server Service Pack 3 o posterior. DSAccess determina si el servidor de directorios cumple estos requisitos.

Una vez finalizadas las pruebas exhaustivas, DSAccess ejecuta una serie de pruebas generales para determinar qué servidores de directorios pueden acomodar la carga adicional que Exchange Server 2003 les ha colocado. Para realizar esta determinación, DSAccess ejecuta las pruebas generales de idoneidad siguientes: •

Ponderación de DNS DSAccess utiliza el valor de ponderación de los controladores de dominio y los servidores de catálogo global, como se ha especificado en los registros de recurso de cada servidor (SVR) en DNS para determinar el servidor preferido por el cliente. Unos resultados de ponderación mayores suponen una mayor probabilidad de

89

que DSAccess elija a un servidor. Si DSAccess no puede leer la ponderación, utiliza una ponderación predeterminada de 100. •

Propietario de la función de controlador de dominio primario de FSMO Si su topología contiene servidores que ejecutan Windows NT Server, el servidor de directorios con la función de controlador de dominio primario (PDC) de la operación principall única y flexible (FSMO) experimentará cargas fuertes, provocando que sea un candidato menos adecuado para que lo utilice Exchange Server 2003. Por este motivo, DSAccess realiza una prueba de idoneidad general para localizar el propietario de la función PDC DC de FSMO, para poder quitarlo de la lista de servidores de directorios adecuados.

•

Tiempo de respuesta DSAccess realiza una consulta LDAP al servidor de directorios para comprobar su tiempo de respuesta. Un tiempo de respuesta mayor de dos segundos se considera un error de prueba de idoneidad general. Nota: DSAccess incluye compatibilidad para la conmutación por error y el equilibrio de carga por turnos completo a otro servidor de directorios, si un servidor utilizado actualmente pasa a estar no dis disponible. ponible. Estas funciones están deshabilitadas cuando Exchange Server 2003 se ejecuta en un controlador de dominio o un servidor de catálogo global.

Protección de servidores DSAccess DSAccess permite a un administrador configurar de forma estática controladores controlad de dominio específicos y catálogos globales para que los utilice DSAccess, y también deshabilitar el proceso de descubrimiento de topología automático. Estas entradas protegidas están configuradas en la interfaz de usuario del Administrador del sistema sistema de Exchange, como se muestra en la figura siguiente.

90

Ficha Directory Access del Administrador del sistema de Exchange

Durante la inicialización, DSAccess lee el registro para determinar si hay algún controlador de dominio o servidor de catálogo global configurado estáticamente. Si existe algún controlador de dominio o servidor de catálogo global configurado estáticamente, no se realiza la detección de topología dinámica. Si no se identifica ningún servidor de directorios, DSAccess detecta de forma dinámica los servidores de servicio de directorio en la topología. Cuando DSAccess se configura de forma dinámica, las funciones de conmutación por error y equilibrio de carga de DSAccess no coinciden, y no se utiliza ni se detecta otro catálogo global ni otro catálogo de dominio. Como consecuencia, si alguno de los catálogos de dominio o catálogos globales configurados estáticamente está sin conexión o no puede obtenerse acceso al mismo, las operaciones de DSAccess fallarán. Si los catálogos globales están configurados estáticamente, pero no se especifica ningún catálogo de dominio en el registro, se detectará y se utilizará de forma dinámica cualquier controlador de dominio disponible. De forma parecida, si los catálogos de dominio están configurados estáticamente, pero no se especifica ningún catálogo global en el registro, se detectará y se utilizará de

91

forma dinámica cualquier catálogo global disponible. Si el controlador de dominio de configuración no está configurado de forma estática, se quita de la lista de controladores de dominio disponibles (independientemente de si la lista está configurada estática o dinámicamente).

Perfiles de DSAccess Los controladores de dominio y los catálogos globales utilizados para las solicitudes de contexto de usuario dependen del perfil. Por ello, los valores del Registro para esta configuración se encuentran bajo una subclave HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeDSAccess\Profiles\Defau lt.

Las claves del Registro siguientes son necesarias para configurar de forma estática controladores de dominio y servidores de catálogo global para que los utilice DSAccess.

Ubicación

MSExchangeDSAccess\Profiles\Default\

Valor

IsGC

Tipo

REG_DWORD

Información del valor

0x0

Ubicación

MSExchangeDSAccess\Profiles\Default\

Valor

HostName

Tipo

REG_SZ

Información del valor



Ubicación

MSExchangeDSAccess\Profiles\Default\

Valor

DSType

Tipo

REG_SZ

Información del valor

0

Ubicación

MSExchangeDSAccess\Profiles\Default\

92

Valor

PortNumber

Tipo

REG_DWORD

Información del valor

0x00000185 (389)

Ubicación

MSExchangeDSAccess\Profiles\Default\

Valor

IsGC

Tipo

REG_DWORD

Información del valor

0x1

Ubicación

MSExchangeDSAccess\Profiles\Default\

Valor

HostName

Tipo

REG_SZ

Información del valor



Ubicación

MSExchangeDSAccess\Profiles\Default\

Valor

DSType

Tipo

REG_SZ

Información del valor

0

Ubicación

MSExchangeDSAccess\Profiles\Default\

Valor

PortNumber

Tipo

REG_DWORD

Información del valor

0x00000cc4 (3268)

93

Especificación del controlador de dominio de configuración El controlador de dominio de configuración utilizado por DSAccess puede establecerse de una de las tres formas siguientes: •

Configurado estáticamente en el Registro El controlador de dominio de configuración se comparte entre todos los perfiles. Por este motivo, los valores de configuración del Registro para el controlador de dominio de configuración se especifican bajo la subclave \Instance0, del modo siguiente. Ubicación

MSExchangeDSAccess\Instance0

Valor

ConfigDCHostName

Tipo

REG_SZ

Información del valor



Ubicación

MSExchangeDSAccess\Instance0

Valor

ConfigDCPortNumber

Tipo

REG_DWORD

Información del valor

0x00000185 (389)

•

Detectado dinámicamente Si un controlador de dominio de configuración no se especifica de forma estática, DSAccess utiliza el descubrimiento de topología dinámico para localizar un controlador de dominio de configuración. DSAccess utiliza el controlador de dominio de configuración seleccionado durante ocho horas, tras lo cual escoge aleatoriamente un nuevo controlador de dominio de configuración. DSAccess elige un nuevo controlador de dominio de configuración antes si el Operador de sistema se reinicia o si el controlador de dominio de configuración seleccionado actualmente falla o se apaga.

•

Por el Operador de sistema durante el arranque En Exchange Server 2003, el proceso del Operador de sistema elige el controlador de dominio de configuración únicamente durante el primer inicio de servicio, que se produce durante la instalación o la actualización. En todos los casos, la elección realizada por el Operador de sistema se ignora si el controlador de dominio de configuración se configura de forma estática en el Registro. DSAccess toma una entrada de controlador de dominio de configuración como sugerencia. Así, si el controlador de dominio de configuración se configura de forma estática, DSAccess lo prefiere para las solicitudes de contexto de configuración. Si este controlador de dominio pasa a estar no disponible, se elige un controlador de dominio alternativo de la lista de controladores de dominio en funcionamiento. En tal caso,

94

DSAccess realiza una conmutación por error del controlador de dominio, eligiendo un controlador de dominio disponible y actuando como si la información del Registro del controlador de dominio de configuración no estuviera presente.

Cómo DSAccess asigna funciones de servidor Los ejemplos siguientes muestran distintas configuraciones de Active Directory y muestran la forma en que DSAccess asigna funciones de servidor en cada caso. En estos ejemplos, se asume que todos los controladores de dominio y catálogos globales se ejecutan en Windows 2000 Server con Service Pack 3 o posterior, que todas las pruebas de idoneidad se pasan correctamente y que no hay ningún controlador de dominio estático protegido (es decir, DSAccess que realiza el descubrimiento de topologías dinámico).

Ejemplo 1: Topología de dominio único simple La figura siguiente muestra un bosque único con un dominio único compuesto de dos sitios. El sitio A contiene un controlador de dominio único y un catálogo global único, y el sitio B contiene tres controladores de dominio y dos catálogos globales. Un dominio con dos sitios

Si DSAccess se ejecuta en servidores Exchange Server 2003 del sitio A detectará la topología que se muestra en la tabla siguiente: Topología para el sitio A Tipo de controlador de dominio

Servidor

Controlador de dominio de configuración

Controlador de dominio 1 o catálogo global 1

Controladores de dominio en funcionamiento

Controlador de dominio 1 y catálogo global 1

95

Tipo de controlador de dominio

Servidor

Catálogos globales en funcionamiento

Catálogo global 1

Si DSAccess se ejecuta en servidores Exchange Server 2003 del sitio B detectará la topología que se muestra en la tabla siguiente: Topología para el sitio B Tipo de controlador de dominio

Servidor

Controladores de dominio de configuración

Controladores de dominio 2, 3 y 4 Catálogo global 2 o 3

Controladores de dominio en funcionamiento

Controladores de dominio 2, 3 y 4 Catálogos globales 2 y 3

Catálogos globales en funcionamiento

Catálogos globales 2 y 3

En cada caso, el orden de los servidores listados es importante. Los servidores se enumeran y se utilizan en el orden en que son descubiertos por DSAccess y se determina que son adecuados.

Ejemplo 2: Topología de dominios compleja La figura siguiente muestra una topología más compleja, que incluye dos dominios y dos sitios, con el sitio A repartido entre los dos dominios. Dos dominios con un sitio repartido entre ambos dominios

Si DSAccess se ejecuta en servidores Exchange Server 2003 del dominio 1 y sitio A detectará la topología que se muestra en la tabla siguiente.

96

Topología para el dominio 1 y el sitio A Tipo de controlador de dominio

Servidor

Controlador de dominio de configuración

Controladores de dominio 1, 2, 3 y 4 Catálogos globales 1, 2 o 3

Controladores de dominio en funcionamiento

Controladores de dominio 1, 2, 3 y 4 Catálogos globales 1, 2 y 3

Catálogos globales en funcionamiento

Catálogos globales 1, 3 y 2

Si DSAccess se ejecuta en servidores Exchange Server 2003 del dominio 2 y sitio A detectará la topología que se muestra en la tabla siguiente Topología para el dominio 2 y el sitio A Tipo de controlador de dominio

Servidor

Controlador de dominio de configuración

Controladores de dominio 1, 2, 3 y 4 Catálogos globales 1, 2 o 3

Controladores de dominio en funcionamiento

Controladores de dominio 1, 2, 3 y 4 Catálogos globales 1, 2 y 3

Catálogos globales en funcionamiento

Catálogos globales 2, 1 y 3

Si DSAccess se ejecuta en servidores Exchange Server 2003 del dominio 2 y sitio B detectará la topología que se muestra en la tabla siguiente. Topología para el dominio 2 y el sitio B Tipo de controlador de dominio

Servidor

Controlador de dominio de configuración

Controlador de dominio 5 Catálogo global 4

Controlador de dominio en funcionamiento

Controlador de dominio 5 Catálogo global 4

Catálogos globales en funcionamiento

Catálogo global 4

Nuevamente los servidores se listan y se utilizan en el orden en que son descubiertos y se determina que son adecuados.

97

La caché de Directory Access La caché de DSAccess es una caché en la memoria del servidor Exchange que contiene registros del usuario y configuración recuperados de Active Directory. Se obtiene acceso a los registros de la caché a través del nombre completo (DN) del objeto, del identificador único global (GUID) o de una clave construida desde el ámbito, el nombre completo básico (BaseDN) y el filtro utilizados para encontrar este objeto en Active Directory. Las subsiguientes obtenciones de acceso que utilicen los mismos DN, GUID o claves encontrarán el registro en la caché. Como se ha mencionado anteriormente, DSAccess es una API compartida utilizada por varios procesos en un equipo Exchange Server 2003. La siguiente tabla enumera los procesos que DSAccess.dll carga en su pila y se benefician del almacenamiento en caché de la información de Active Directory. Procesos que cargan DSAccess.dll Proceso

Descripción

Mad.exe

Servicio Operador de sistema de Microsoft Exchange

Store.exe

Servicio Almacén de información de Microsoft Exchange

EMSMTA.exe

Servicio Pila MTA de Microsoft Exchange

ExMgmt.exe

Servicio Administración de Exchange

RESvc.exe

Servicio Motor de enrutamiento de Exchange

Inetinfo.exe o W3WP.exe

Procesos de trabajo e IIS

Winmgmt.exe

Servicio Instrumental de administración de Windows

La tabla siguiente muestra una lista los diversos componentes de Exchange que utilizan DSAccess para adquirir información acerca de la configuración y el usuario. Uso de DSAccess de los componentes de Exchange Componente

Usa DSAcces para

Servicio de actualización de la metabase (DS2MB)

Seguimiento de los cambios del directorio mediante el número de secuencia de actualización (USN)

Motor de enrutamiento de Exchange (RESVC)

Consultas de usuarios y de configuración

Categorizador SMTP (SMTP CAT)

Lista de servidores de catálogo global de la topología

98

Componente

Usa DSAcces para

Proxy del servicio de directorio (DSProxy)

Lista de servidores de catálogo global de la topología

Almacén de Exchange

Consultas de usuarios y de configuración

WebDAV

Consultas de usuarios y de configuración

Agente de transferencia de mensajes (MTA)

Consultas de usuarios y de configuración

La caché de DSAccess permite que las búsquedas de directorio realizadas por estos componentes se almacenen en la caché durante un período de tiempo. Durante este período de tiempo, si otro proceso necesita la misma información, se puede recuperar de la caché de DSAccess, en lugar de repetir la misma consulta en un catálogo global en funcionamiento. Todas las obtenciones de acceso a directorios, excepto las búsquedas en la Libreta de direcciones desde clientes API y determinadas partes del enrutamiento entrante y saliente de SMTP, pasan por el proceso de DSAccess y se almacenan en la caché. De forma predeterminada, las entradas de directorio se almacenan en la caché durante 15 minutos. El tamaño predeterminado de la caché del usuario es de 140 megabytes (MB), y la caché de configuración es de 50 MB. El número de usuarios, el número máximo de entradas, el tamaño máximo de caché (memoria) y el tiempo de caducidad de la caché son todos los parámetros que pueden afectar al rendimiento y el tamaño óptimo de la caché de DSAccess. Las siguientes entradas del Registro (ninguna de las cuales está presente de forma predeterminada) proporcionan un control de bajo nivel sobre la caché de DSAccess para los datos de configuración. Ubicación

MSExchangeDSAccess\Instance0

Valor

CacheTTLConfig

Tipo

REG_DWORD

Información del valor

0x384 (900 seconds)

Descripción

Se utiliza para especificar el periodo de vida (TTL) para los datos de configuración de la caché

Ubicación

MSExchangeDSAccess\Instance0

Valor

MaxEntriesConfig

Tipo

REG_DWORD

Información del valor

0 (no limit)

99

Descripción

Se utiliza para especificar el número máximo de entradas de datos de configuración de la caché

Las siguientes entradas del Registro (ninguna de las cuales está presente de forma predeterminada) proporcionan un control de nivel bajo sobre la caché de DSAccess para los datos de usuario. Ubicación

MSExchangeDSAccess\Instance0 Instance0

Valor

CacheTTLUser

Tipo

REG_DWORD

Información del valor

0x258 (600 seconds)

Descripción

Se utiliza para especificar el periodo de vida (TTL) para los datos de usuario de la caché

Ubicación

MSExchangeDSAccess\Instance0 Instance0

Valor

MaxEntriesUser

Tipo

REG_DWORD

Información del valor

0 (no limit)

Descripción

Se utiliza para especificar el número máximo de entradas de datos de usuario de la caché

Precarga de DSAccess Debería precargar los filtro filtros s de búsqueda para evitar el problema que supone ejecutar múltiples instancias de búsqueda en Active Directory de forma concurrente, situación que se produce cuando se emiten varios filtros de búsqueda en el mismo objeto del usuario. Puede habilitar la precarga carga a través de las siguientes entradas del Registro, que definen el ámbito, el nombre completo básico (BaseDN) y el filtro de la búsqueda. Precaución: La modificación incorrecta del Registro puede ocasionar problemas graves que quizás requieran volver a instalar el sistema operativo. Es posible que los problemas derivados de una modificación incorrecta del Registro no se puedan resolver. Antes de modificar el Registro, se recomienda realizar una copia de seguridad de todos los datos importantes. Los siguientes valores del Registro pueden utilizarse para precargar la caché de DSAccess.

100

Ubicación

MSExchangeDSAccess

Valor

PreloadBaseDNs

Tipo

REG_MULTI_SZ

Información del valor

BaseDN value (for example, DC=contoso,DC=com)

Descripción

Identifica el objeto contenedor que se utiliza como raíz de la búsqueda. Este es un valor de configuración de cadena múltiple. Cada BaseDN debe correlacionarse con un único filtro precargado. Esto significa que los nombres BaseDN y la cadena de filtro deben coincidir entre ellos exactamente.

Ubicación

MSExchangeDSAccess\

Valor

PreloadFilters

Tipo

REG_MULTI_SZ

Información del valor

A filter string, for example, legacyExchangeDN=%

101

Descripción

DSAccess lee el registro e interpreta el signo de porcentaje (%) como un parámetro abierto, que se determinará. Cuando se emite una búsqueda real, el registro que devuelve el directorio se analiza, y el valor de este atributo, que se especifica en el filtro precargado, se inserta en la entrada de búsqueda. A continuación, los punteros se establecen en el registro de usuario adecuado. Al igual que con todas las modificaciones del Registro, tenga mucho cuidado al actualizar el Registro. Del mismo modo que otros servicios de Exchange, DSAccess no comprueba la validez de los servidores de Active Directory que están especificados en el Registro y no reconoce errores de escritura ni otros posibles errores. Los valores que están rellenados para la precarga se establecen de forma óptima para la mayoría de búsquedas de Exchange.

Un número determinado de transacciones de Exchange podría desencadenar un suceso de precarga, pero deben cumplirse los criterios específicos. Estos sucesos de precarga se producen en el orden siguiente: 1. Se realiza una búsqueda de Active Directory. Si se cumplen las tres condiciones siguientes en la búsqueda, la caché de DSAccess se carga: •

El nombre completo debe ser devuelto por una búsqueda de partición de directorio de usuario.

•

El nombre completo resultante debe contener el nombre BaseDN especificado en los valores de configuración del Registro precargados. Por ejemplo, si la búsqueda real especifica un nombre BaseDN más general que el nombre BaseDN precargado, no se produce la precarga.

•

En este punto, se analiza el registro devuelto, y se extraen los atributos especificados en la cadena de búsqueda precargada. Deben existir los atributos necesarios para crear el filtro de búsqueda. En el ejemplo siguiente de una búsqueda multiplexada, debe existir al menos uno de los atributos: (|(objectGuid=%) (msExchMailboxGuid=%))

Debido a la ambigüedad del resultado devuelto, el atributo de la cadena del filtro precargado no debe tener múltiples valores. Por ejemplo, proxyAddresses = % no es un filtro precargado válido, ya que proxyAddresses es un atributo de múltiples valores, y DSAccess no sabe qué valor debe utilizar para el valor abierto.

102

2. Se crea una entrada de búsqueda desde la cadena de ámbito, nombre BaseDN, atributos y filtro, y se vincula con su entrada de nombre completo en la caché. Por ejemplo: [scope cope = Whole Subtree] / [baseDN = DC=mydom,DC=com] / [filter = (objectClass=myclass)]

DSAccess procesa solicitudes de Active Directory futuras en los nombres BaseDN y los filtros precargados utilizando la caché en lugar de Active Directory.

Proxy del servi servicio cio de directorio (DSProxy) El Proxy del servicio de directorio (DSProxy) es el componente de Exchange Server 2003 que proporciona un servicio de libreta de direcciones a los clientes de Microsoft Office Outlook. DSProxy está implementado en DSProxy.dll y tiene dos funciones: •

Emular un servicio de libreta de direcciones MAPI y solicitudes proxy a un servidor de Active Directory

•

Proporcionar un mecanismo de referencia para que los clientes de Outlook puedan ponerse directamente en contacto con los servidores serv de Active Directory

Aunque su nombre implica que proporciona únicamente servicios proxy, DSProxy proporciona servicios proxy y de referencia. Los clientes MAPI que ejecutan versiones de Outlook anteriores a Outlook 2000 tienen acceso al directorio a través del componente DSProxy. Estos clientes de versiones anteriores fueron diseñados asumiendo que cada servidor Exchange contiene un servicio de directorio. En Exchange Server 2000 y versiones posteriores ya no sucede así. Por lo tanto, DSProxy emula un servicio de directorio, de forma que los clientes anteriores puedan funcionar haciendo que el servidor de Exchange 2003 reenvíe las solicitudes a Active Directory. Las últimas versiones de Outlook, como Outlook 2000 y Outlook 2002, sigue utilizando un proxy Interfaz del proveedor del servicio de nombres (NSPI) en la conexión inicial de Exchange Server. Sin embargo, una vez que el cliente entre en contacto con el servidor, el servicio DSProxy pasa una referencia de nuevo al cliente. Desde este punto en adelante, a todas las futuras solicitudes de directorio se envían directamente al servidor de referencia. El servidor de referencia en este caso es el servidor de catálogo global. Nota: En la versión original de Outlook 2000, una referencia sólo se actualiza actuali si no se puede tener acceso al servidor de catálogo global. En Outlook 2000 Service Release 2 (SR2), la referencia se actualiza cada vez que se inicia Outlook. Este cambio impide que Outlook 2000 se enlace continuamente a un servidor de catálogo global inadecuado. Outlook 2002 y versiones posteriores actualizan su referencia de catálogo global cuando el cliente se reinicia o se produce un error.

103

DSProxy obtiene su lista de servidores de catálogo global en funcionamiento de DSAccess, pero no enruta sus consultas a través de DSAccess. Esto sucede porque DSProxy utiliza NSPI para enviar búsquedas de libretas de direcciones MAPI. DSAccess únicamente maneja consultas LDAP. Sin embargo, DSProxy confía plenamente en que DSAccess será compatible con la conmutación por error del catálogo global.

Operaciones de DSProxy DSProxy realiza las operaciones siguientes: •

Adquiere la lista de catálogos globales en funcionamiento de DSAccess y filtra los catálogos globales que no son apropiados.

•

Envía mediante proxy consultas MAPI desde los clientes de versiones anteriores de Outlook 2000 al resto de servidores de catálogo global en función del número de catálogos globales y la IP del cliente.

•

Refiere a los clientes de Outlook 2000 y versiones posteriores a servidores de catálogo global mediante un mecanismo por turnos.

DSProxy ejecuta inicialmente un único subproceso que puede admitir hasta 512 conexiones cliente. DSProxy emite automáticamente un subproceso adicional por cada 512 conexiones. A diferencia de DSAccess, DSProxy no tiene ningún mecanismo de almacenamiento en caché. Esto significa que cada consulta de MAPI procesada a través de DSProxy se envía a un catálogo global en funcionamiento.

Comportamiento de referencia de Exchange Server 2003 anterior al Service Pack 2 Se ha realizado un cambio de diseño en Exchange Server 2003 Service Pack 2 (SP2) relacionado con el modo en el que el servicio DSProxy refiere a los clientes de Outlook a catálogos globales. Este tema explica el comportamiento anterior y posterior de este cambio. Antes de Exchange Server 2003 SP2, los clientes MAPI de Outlook o recibían una referencia a un servidor de catálogo global, o usaban el servidor de Exchange para enviar solicitudes de directorio. Si el cliente es Outlook 2000, después de que el cliente de Outlook se conecte al servidor de Exchange, el servicio de DSProxy pasa una referencia de nuevo al cliente. Desde este punto, todas las futuras solicitudes de directorio se envían directamente al servidor de catálogo referencia. En este caso, el catálogo global se encuentra en una de estas dos ubicaciones: •

El catálogo global está ubicado en el mismo sitio de Active Directory que el servidor de Exchange (comportamiento habitual).

•

El catálogo global está ubicado en un sitio de Active Directory que se conecta directamente al sitio de Active Directory del servidor de Exchange (cuando no hay catálogos globales del sitio que estén disponibles).

104

Además de priorizar la pertenencia al sitio, DSProxy prefiere utilizar servidores de catálogo global que son miembros del mismo dominio que el servidor de Exchange. Si no hay ninguno disponible, DSProxy utiliza otros servidores de catálogo global del sitio de Active Directory. Este comportamiento presenta problemas en entornos de múltiples dominios en los que DomainPrep se ha ejecutado en los dominios. En concreto, si se refiere un cliente de Outlook a un servidor de catálogo global que no resida en el mismo dominio que el usuario con buzón habilitado, dicho usuario tendrá acceso a los datos que estén en fformato de sólo lectura. Esto implica que podrían no realizarse las actualizaciones a ciertos objetos. Las actualizaciones podrían ser actualizaciones al usuario con buzón habilitado, como el acceso delegado o la pertenencia al grupo de distribución.

Antes de SP2 El bosque contiene tres dominios y se ha preparado a cada uno de ellos para Exchange Server. Todos los usuarios y grupos de distribución residen en el dominio, DominioUsuario. Un servidor de catálogo global y TercerDominio son miembros del sitio de Active Directory del servidor de Exchange. Los clientes de Outlook residen en otro sitio de Active Directory. El dominio del servidor de Exchange no está representado y no hay servidores de catálogo global de dicho dominio en el sitio de Active Directory del servidor de Exchange.

Cuando un cliente de Outlook 2003 se conecta al servidor de Exchange, DSProxy podría referir el cliente a cualquiera de los tres servidores de catálogo global del sitio de Active Directory del servidor de Exchange, teniendo en cuenta que uno o más de estos servidores están en línea y son accesibles. Como no hay servidores de catálogo global que sean miembros del dominio del servidor de Exchange, el comportamiento anterior a SP2 no tiene preferencia por ninguno de los servidores de catálogo global. DSProxy equilibrará la carga de las solicitudes de referencia entre los servidores de catálogo global disponibles para hacer una distribución uniforme. Teniendo en cuenta este diseño, hay un 66 por ciento de posibilidades de que DSProxy DSProx refiera el cliente de Outlook a un servidor de catálogo global que no esté en el dominio

105

principal del cliente. Para esta explicación, asuma que DSProxy refiere el cliente a un servidor de catálogo global TercerDominio. En este caso, los clientes de Outlook pueden utilizar ese servidor de catálogo global correctamente para todas las solicitudes de directorio excepto para las siguientes: •

Actualizar la pertenencia de los grupos de distribución que residen en DominioUsuario.

•

Asignar permisos delegados a los buzones de estos grupos de distribución, que residen en DominioUsuario.

•

Publicar certificados en la lista global de direcciones (GAL) utilizando la opción Publicar en GAL de Outlook.

Si DSProxy hubiera referido el cliente de Outlook al DominioUsuario GC1, el cliente de Outlook podría realizar las solicitudes anteriores. Para obtener más información acerca del comportamiento anterior a SP2 y sus problemas potenciales, consulte en Microsoft Knowledge Base los siguientes artículos. •

256976, "XCLN: Cómo acceden los clientes MAPI a Active Directory".

•

872897, "How to control the DSProxy process for RPC over HTTP connections in Exchange Server 2003 sp1 "(Cómo controlar el proceso DSProxy a través de conexiones HTTP en Exchange Server 2003 SP1para RPC)

•

318074, "Mensaje de error "no dispuesto de suficientes permisos" aparece cuando utiliza Libreta de direcciones de Outlook para administrar pertenencia a lista de distribución".

•

329622, "No se asigna permiso "reexpide nombre" a un usuario después de que delegue acceso en Outlook".

Comportamiento de referencia de Exchange Server 2003 anterior a Service Pack 2 En Exchange Server 2003 SP2, el proceso de referencia intenta ofrecer al cliente de Outlook un catálogo global que pertenezca al mismo dominio que el usuario con buzón habilitado a través de un nuevo algoritmo. Este algoritmo resuelve el problema de la delegación si el servidor de Exchange para el destinatario de correo tiene a su disposición un servidor de catálogo global de dominio principal. Puede resolver el problema del grupo de distribución si éste reside en el mismo dominio que el buzón. Si no reside en el mismo dominio no resolverá el problema porque el catálogo global contiene una copia de sólo lectura del grupo de distribución.

Funcionamiento del nuevo algoritmo El servicio DSProxy de Exchange Server 2003 SP2 intenta referir el cliente de Outlook a un servidor de catálogo global que está disponible, admite el protocolo que utiliza el cliente y reside en el dominio de Active Directory principal del propietario del buzón. Para poder encontrar un servidor de catálogo global que reúna estos requisitos, DSProxy evalúa si estos catálogos son adecuados función de las siguientes restricciones:

106

•

Restricción 1 Un catálogo global que esté disponible (ping RPC), 16 puntos

•

Restricción 2 Un catálogo global que admita el protocolo del cliente, 8 puntos

•

Restricción 3 Un catálogo global que pertenezca al dominio del usuario, 4 puntos

•

Restricción 4 Un catálogo global que esté en el mismo sitio de Active Directory que el servidor de Exchange, 2 puntos

•

Restricción 5 Un catálogo global que sea uno de los catálogos globales que utilice el servidor de Exchange en ese momento, 1 punto

DSProxy distribuye primero los servidores de catálogo global que tienen más puntos y va asignando recursos sucesivamente si hay más solicitudes. La restricción 1 se computa cada 5 minutos y se puede configurar mediante la modificación de la clave del Registro LdapKeepAliveSecs. Las restricciones 2 y 3 son "dinámicas" en el sentido de que pueden calcularse cada vez que un cliente solicite una referencia. Las restricciones 4 y 5 son "estáticas", ya que se calculan una vez por cada catálogo global y después se almacenan. La restricción 5 también se conoce como lista de encarnación (incarnation list). Cuando se inicializa DSAccess, crea una lista de encarnación de 10 servidores de catálogo global del sitio que se pueden utilizar. Si los servidores de catálogo global del sitio no están disponibles, DSAccess crea una lista de encarnación de 10 servidores que no pertenecen al sitio a partir de los sitios conectados directamente y empieza por el sitio que tenga el menor costo de vínculo. Debido al orden de las restricciones, DSProxy prefiere servidores de la lista de encarnación de DSAccess; de modo que optará de manera predeterminada por los 10 servidores cuyos costos de vínculos sean más rentables. Sin embargo, DSProxy tiene una lista de todos los servidores de catálogo global de todos los sitios conectados directamente y sólo utiliza la pertenencia en la lista de encarnación para asignar puntos a los servidores. En la siguiente figura hay dos dominios, Dominio de Exchange y DominioUsuario.

107

En este caso, el servicio DSProxy asignará los puntos a los los servidores de catálogo global tal y como se muestra en la tabla siguiente. Tenga en cuenta que se asume que todos los servidores de catálogo global funcionarán correctamente en el sitio de Active Directory de Exchange. Servidor

DominioUsuario GC1

DominioUsuario GC2

Sitio de Active

¿En uso por

Puntos totales por

Directory

DSAccess?

valor de restricción

Sitio de Active Directory cliente

No

16+8+4=28

Sitio de Active Directory cliente

No

(1, 2, 3) 16+8+4=28 (1, 2, 3)

108

Servidor

Sitio de Active

¿En uso por

Puntos totales por

Directory

DSAccess?

valor de restricción

Sitio B de Active Directory

No

16+8+4=28

Sitio B de Active Directory

No

Dominio GC1 de Exchange

Sitio de Active Directory de Exchange

Sí

Dominio GC2 de Exchange

Sitio de Active Directory de Exchange

Sí

Dominio GC3 de Exchange

Sitio A de Active Directory

No

Dominio de Exchange GC4

Sitio A de Active Directory

No

Dominio de Exchange GC5

Sitio B de Active Directory

No

Dominio de Exchange GC6

Sitio B de Active Directory

No

DominioUsuario GC3

DominioUsuario GC4

(1, 2, 3) 16+8+4=28 (1, 2, 3) 16+8+2+1=27 (1, 2, 4, 5) 16+8+2+1=27 (1, 2, 4, 5) 16+8=24 (1, 2) 16+8=24 (1, 2) 16+8=24 (1, 2) 16+8=24 (1, 2)

Nota: Como puede ver en la tabla, no se incluyen ni el Dominio de Exchange GC7 ni el DominioUsuario GC5 porque no están conectados directamente con el sitio de Active Directory del servidor de Exchange. Es decir, el servidor de Exchange nunca utiliza esos servidores de catálogo global para funciones de DSAccess o DSProxy. En este ejemplo puede apreciar que este algoritmo puede dar prioridad a un servidor de catálogo global que no per pertenezca tenezca al sitio sobre otro que sí lo haga; esto supone una diferencia en relación al comportamiento de DSProxy anterior a SP2. En este ejemplo, Exchange Server proporciona los servidores de catálogo global de DominioUsuario a los clientes de Outlook (de una manera sucesiva para equilibrar la carga de solicitudes) porque la puntuación de esos servidores supera a la obtenida por los servidores de catálogo global del dominio de Exchange. Esto significa que Exchange puede ahora referir los clientes a servidores servidores de catálogo global que no sean del sitio (pero sólo a aquellos que estén directamente conectados al sitio de Active Directory de Exchange), en el caso de que no haya servidores de catálogo global de dominio principal de buzón disponibles en el sitio de Active Directory del servidor de Exchange. En este caso, el cliente

109

de Outlook podría recibir una referencia para un servidor de catálogo global de DominioUsuario que esté ubicado en el sitio B de Active Directory o el sitio de Active Directory de cliente. Además, si los servidores de catálogo global de DominioUsuario no fueran accesibles (es decir, esos servidores no pasaron la restricción 1), DSProxy referiría los clientes de Outlook a los servidores de catálogo global que residan en el sitio de Active Directory Directory de Exchange, ya que son los siguientes con la puntuación más alta. Para obtener más información sobre la referencia de DSProxy después del SP2, consulte el artículo de blog del equipo de Exchange Server Exchange 2003 post-SP2 SP2 DSProxy Referral Update (en inglés). Nota: El contenido de cada blog y su dirección URL están sujetos a cambios sin previo aviso.

¿Qué sigue sin resolver DSProxy de Exchange Server 2003 SP2? El cambio de referencia de DSProxy resulta útil para el usuario final cuando DSProxy puede encontrar un servidor de catálogo global de dominio principal. Si no hay servidores de catálogo global de dominio principal en el sitio de Active Directory del servidor de Exchange, ni en ninguno guno de los sitios de Active Directory conectados directamente al servidor de Exchange, el cliente de Outlook recibe una referencia a un servidor de catálogo global que contiene una copia de sólo lectura del usuario con buzón habilitado. Este acceso de sólo sól lectura significa que el buzón en cuestión no puede realizar modificaciones de delegación o publicar certificados en el GAL. Además, aunque el nuevo comportamiento puede resolver los problemas de publicación de certificados y de permiso de delegación, podría podría no encargarse de la capacidad del destinatario de correo de actualizar la pertenencia del grupo de distribución. El grupo de distribución debe pertenecer al mismo dominio que el destinatario de correo para que éste pueda actualizar la pertenencia. Si el grupo de distribución no pertenece al mismo dominio que el destinatario de correo, no se realizará la actualización de la pertenencia. Por lo tanto, es posible que aún sea necesario buscar otra solución que proporcione a todos los usuarios la capacidad de actualizar la pertenencia de grupo.

Implicaciones del comportamiento de referencia de DSProxy Es necesario revisar los siguientes elementos de la infraestructura: •

Si no existe consideración previa alguna en relación al diseño de red, este cambio podrí podría causar que los clientes se referencien a servidores de catálogo global incorrectos desde una perspectiva de red (latencia, ancho de banda, uso, número de saltos). Se recomienda que considere las implicaciones de red antes de la implementación.

110

•

Para asegurarse de que Exchange Server sigue ofreciendo referencias de catálogo global, podría ser necesario agregar servidores de catálogo global al sitio de Active Directory de Exchange para aquellos dominios que contengan buzones que residan en los servidores de Exchange en ese sitio de Active Directory.

El categorizador SMTP El categorizador SMTP (al cual se hace referencia también como “el categorizador”) es un componente del motor de transporte de Exchange Server 2003. Cuando un mensaje se envía al proceso de transporte, el categorizador utiliza la información de cabecera del mensaje para consultar a Active Directory información acerca de cómo y dónde debe enviarse el mensaje. Por ejemplo, desde una dirección SMTP como [email protected], el categorizador identifica el servidor Exchange Server 2003 que contiene el buzón de correo del usuario y determina cómo direccionar el mensaje a dicho servidor. El categorizador también amplía la lista de distribución y aplica límites por usuario a los mensajes. Para obtener más información acerca de la arquitectura del motor de transporte SMTP, consulte Arquitectura de transporte SMTP. El categorizador confía en DSAccess para la lista de servidores Active Directory que debería utilizar para las búsquedas. Sin embargo, como DSProxy, el categorizador utiliza su propio mecanismo para leer información desde Active Directory, únicamente una vez dispone de la lista de servidores. Hay dos tipos de categorizadores. Uno es el categorizador básico, que está instalado con la pila de transporte SMTP de IIS, y el otro es el categorizador de Exchange, que está instalado con Exchange. El categorizador básico está implementado en Aqueue.dll. El categorizador básico realiza algunas funciones básicas, como utilizar consultas LDAP a Active Directory para resolver información de destinatario. También realiza un procesamiento por lotes eficaz, enviando un determinado número de consultas como si fueran una sola. El categorizador básico puede realizar también una extensión de la lista de distribución. Dispone de las funciones de reenvío de SMTP, y desencadena sucesos de servidor categorizador. Exchange Server 2003 habilita el categorizador básico mediante la instalación de un archivo DLL llamado PhatCat.dll. El archivo PhatCat.dll se agrega a la funcionalidad proporcionada por el categorizador básico. No sustituye a la funcionalidad predeterminada del categorizador básico, pero extiende la funcionalidad del categorizador básico para su propio uso. La arquitectura del categorizador de Exchange se muestra en la figura siguiente.

111

La arquitectura del categorizador de Exchange

Categorización de mensajes y Active Directory Cuando el mensaje se introduce en la cola previa a la categorización, el categorizador selecciona el mensaje para su procesamiento. El categorizador resuelve el emisor del mensaje buscando la dirección en el atributo proxyAddresses de Active Directory. El categorizador resuelve los destinatarios del mensaje buscando las direcciones en el atributo proxyAddresses de Active Directory. Si la lista de destinatarios incluye un grupo de distribución, amplía el grupo para incluir a estos miembros, si la extensión del grupo de distribución está permitida en el servidor. De otro modo, Exchange transfiere el mensaje al servidor de expansión especificado en el grupo de distribución para la expansión del grupo. El categorizador también comprueba para comprobar que el atributo de correo existe en Active Directory, y marca el atributo de correo como la dirección SMTP. El categorizador es también responsable de la aplicación de los límites por destinatario y por emisor y de marcar los destinatarios adecuadamente. El categorizador aplica posteriormente, por dominio, valores de configuración de formato de los mensajes de Internet de entrada y de salida al emisor y los destinatarios, y establece marcas adecuadas para las propiedades de conversión IMAIL. Puede configurar valores de configuración de formato de los mensajes en el Administrador del sistema de Exchange al seleccionar el contenedor Configuración global. Para el envío local, el categorizador marca el destinatario como local estableciendo una propiedad por destinatario en un mensaje indicando el servidor de destino de cada destinatario. El formato habitual de esta propiedad es el nombre de dominio completo (FQDN) del servidor del destinatario. El atributo homeMDB del destinatario indica el servidor en el cual reside el buzón del destinatario. Las operaciones del categorizador se ejecutan como una serie de receptores de sucesos de transporte en la parte de suceso del categorizador del motor de cola avanzada. El

112

categorizador básico incluye diez receptores de sucesos. Los siguientes siete receptores de sucesos se utilizan para buscar en Active Directory: •

Register Se llama a este receptor de sucesos para que se inicialice al principio de la categorización del mensaje.

•

BeginMessageCategorization Se llama a este receptor de sucesos una vez por cada mensaje enviado al categorizador.

•

EndMessageCategorization Se llama a este receptor de sucesos para significar el final de la categorización del mensaje.

•

BuildQuery Se llama a este receptor de sucesos una vez por cada usuario que debe comprobarse en el directorio.

•

BuildQueries Se llama a este receptor de sucesos una vez por cada búsqueda por lotes. En cada uno de estos escenarios, el categorizador crea un filtro compatible con LDAP para el usuario.

•

SendQuery Este receptor de sucesos envía la búsqueda por lotes. Ejecuta el trabajo del servidor de directorio bajo los atributos de solicitud (Request). Realiza una búsqueda LDAP asíncrona en un servidor de directorio.

•

SortQueryResult Este receptor de sucesos hace coincidir los resultados devueltos por Active Directory con los usuarios individuales.

Los tres receptores de sucesos siguientes se utilizan por usuario y después de los sucesos de búsqueda de servicios post-directorio: •

ProcessItem Este receptor de sucesos resuelve las direcciones. Por ejemplo, si un cliente MAPI local envía un mensaje, el cliente MAPI resuelve el resto de direcciones, como direcciones X.400, X.500 DN, Legacy-Exchange-DN y SMTP, y las devuelve en el mensaje de correo.

•

ExpandItem Este receptor de sucesos agrega más destinatarios al mensaje, por ejemplo, en el caso de la creación de un diario de mensajes, la expansión de grupos de distribución y las conversiones de contenido. Este es el suceso de servidor que agrega miembros, como la extensión del reenvío de SMTP.

•

CompleteItem Este receptor de sucesos realiza su procesamiento cuando el resto de receptores de sucesos del categorizador ha finalizado su trabajo. Este receptor de sucesos recoge los códigos de estado que los receptores de sucesos anteriores han devuelto y correlaciona estos códigos con los destinatarios del mensaje de correo electrónico. Los códigos de error provocan posteriormente que el motor de cola avanzada genere informes de no entrega (NDR) para los destinatarios afectados.

Los componentes del categorizador de Exchange en el archivo PhatCat.dll extienden el categorizador IIS agregando los tres receptores de sucesos siguientes: •

Register Sink Este receptor de sucesos inicializa los componentes del categorizador de Exchange, pero también inicializa DSAccess, el motor de enrutamiento y el código del controlador de almacén. Si falla alguno, también PhatCat.dll fallará en su intento de inicializarse.

113

•

BuildQuery Este receptor de sucesos comprueba si el usuario reside en la caché de DSAccess. Si la comprobación es afirmativa, devuelve un objeto ICategorizerItemAttributes. Omite el código de búsqueda del servicio de directorio para el categorizador de IIS. El procesamiento continúa con el suceso ProcessItem.

•

ProcessItem Exchange PhatCat dispone de un código especial para manejar contactos y usos únicos para cada caso específico. En este escenario, únicamente las direcciones de destino del contexto se agregan al mensaje de correo electrónico.

Servicio de actualización de destinatarios y Exchange Server 2003 Exchange Server 2003 se comunica con los servidores de directorios para actualizar objetos del destinatario (como cuentas de usuario habilitadas para buzón y grupos habilitados para correo) con direcciones de correo electrónico, siguiendo las directivas definidas por la organización para el destinatario. Para llevarlo a cabo, Exchange Server 2003 usa el Servicio de actualización de destinatarios, un componente del Operador de sistema. El Servicio de actualización de destinatarios crea y mantiene valores de atributo específicos de Exchange Server 2003 en Active Directory. Si crea un buzón para un usuario, el Servicio de actualización de destinatarios genera automáticamente la dirección SMTP del usuario, y otras direcciones proxy definidas para los destinatarios. Exchange Server 2003 instala dos instancias del Servicio de actualización de destinatarios: •

Servicio de actualización de destinatarios de configuración de la organización Existe únicamente una instancia de este Servicio de actualización de destinatarios en la organización, ya que el Servicio de actualización de destinatarios de la organización se utiliza para actualizar la partición del directorio de configuración, y únicamente existe una única partición de directorio de configuración compartida por el bosque completo.

•

Servicio de actualización de destinatarios de dominio Debe tener un Servicio de actualización de destinatarios para cada dominio que contenga usuarios habilitados para buzón.

Para cada dominio específico de un bosque, el Servicio de actualización de destinatarios asocia un equipo Exchange Server 2003 (en el cual se ejecuta el Servicio de actualización de destinatarios) con un controlador de dominio (en el cual están actualizados los objetos de directorio). Únicamente puede asociarse un Servicio de actualización de destinatarios con un servidor de directorios en un momento determinado.

Actualización de objetos de destinatario El método que utiliza el Servicio de actualización de destinatarios para realizar una búsqueda se determina mediante las acciones que realiza un administrador de Exchange en

114

el Administrador del sistema de Exchange. Por ejemplo, en el Administrador del sistema de Exchange, puede hacer clic con el botón secundario del mouse (ratón) en un objeto de configuración del Servicio de actualización de destinatarios y seleccionar el comando Reconstruir para volver a calcular las pertenencias a la lista de direcciones y los valores de configuración de la directiva de destinatarios de todos los destinatarios de un dominio en el próximo intervalo programado. También puede seleccionar el comando Actualizar ahora para realizar este procesamiento de forma inmediata. El Servicio de actualización de destinatarios busca en el directorio objetos para actualizar, de las tres formas siguientes: •

Actualizar únicamente objetos nuevos y modificados Éste es el comportamiento predeterminado que exhibe el Servicio de actualización de destinatarios cada vez que busca objetos para actualizar. Éste es también el comportamiento predeterminado que exhibe el Servicio de actualización de destinatarios cuando se utiliza Actualizar ahora, si no se selecciona la opción Reconstruir y no se ha modificado o aplicado ninguna de las directivas. El Servicio de actualización de destinatarios realiza un seguimiento de la última modificación que se ha producido en el controlador de dominio, con el cual se ha configurado el Servicio de actualización de destinatarios para su ejecución. En base a la programación establecida en el objeto del Servicio de actualización de destinatarios, éste comprueba periódicamente la presencia de objetos que han sido creados o actualizados desde la última comprobación. La función Actualizar ahora en el Administrador del sistema de Exchange establece el atributo msExchReplicateNow como TRUE, y hace que el Servicio de actualización de destinatarios ignore de forma temporal su programación y consulte inmediatamente la presencia de nuevas modificaciones y toma las acciones oportunas sobre estos objetos. Tras finalizar el proceso Actualizar ahora, msExchReplicateNow se restablece como FALSE.

•

Actualizar todos los objetos Al seleccionar la opción Reconstruir en el Administrador del sistema de Exchange, se establece el atributo msExchDoFullReplication del Servicio de actualización de destinatarios como TRUE. Cuando msExchDoFullReplication se establece como TRUE, la próxima vez que se inicia el Servicio de actualización de destinatarios, busca todos los objetos, en lugar de buscar exclusivamente objetos nuevos. Cuando finaliza el proceso Reconstruir, msExchDoFullReplication se restablece como FALSE.

•

Actualizar objetos que corresponden a una directiva de destinatarios específica Puede modificar el filtro en una directiva (el atributo purportedSearch) para que el Servicio de actualización de destinatarios tome las acciones oportunas más allá de su comportamiento predeterminado. Al modificar el filtro de una directiva, la directiva puede aplicarse a un conjunto de usuarios completamente distinto de aquellos a los cuales se ha aplicado con anterioridad. Por este motivo, si el filtro de una directiva se modifica, el Servicio de actualización de destinatarios consulta cada usuario que coincide tanto con el filtro anterior como con el filtro siguiente. Esto se produce la próxima vez que

115

el Servicio de actualización de destinatarios es iniciado por la programación o por el comando Actualizar ahora. El Servicio de actualización de destinatarios se ejecuta para todos los usuarios que coinciden con cada filtro y actualiza su atributo msExchPoliciesIncluded para reflejar el filtro que se aplica ahora. Sin embargo, a los usuarios que están sujetos a una directiva distinta no se les vuelven a generar de forma automática sus direcciones de correo electrónico. Para actualizar las direcciones en estos usuarios para que coincidan con la directiva actual, debe utilizar el mandato Aplicar ahora para aplicar la directiva actual. Si únicamente modifica las direcciones de correo electrónico en una directiva, el comportamiento predeterminado del Servicio de actualización de destinatarios no se modifica. Actualiza únicamente objetos nuevos y modificados. Debe modificar el filtro de la directiva para que el Servicio de actualización de destinatarios consulte automáticamente todos los usuarios que coinciden con dicha directiva y para actualizarlos todos. Sin embargo, incluso si modifica el filtro en la directiva, y el Servicio de actualización de destinatarios consulta todos los usuarios, el Servicio de actualización de destinatarios no vuelve a generar las direcciones de correo electrónico existentes de los usuarios para que coincidan con los nuevos valores de configuración de la directiva de destinatarios. De forma alternativa, se agregan nuevas direcciones de correo electrónico. Al aplicar una directiva, el Administrador del sistema de Exchange rellena el atributo gatewayProxy de los objetos del Servicio de actualización de destinatarios con cada dirección de la directiva aplicada. El atributo gatewayProxy actúa como una lista de acción. Por ejemplo, el atributo gatewayProxy de los objetos del Servicio de actualización de destinatarios puede rellenarse con una lista de valores parecida a los valores siguientes: {667A1454-FCD1-434F-B3C6-D9B6D2B4A336}X400:c=us;a= ;p=Organization;o=Exchange; {667A1454-FCD1-434F-B3C6-D9B6D2B4A336}SMTP:@contoso.com {667A1454-FCD1-434F-B3C6-D9B6D2B4A336}smtp:@fabrikam.com

Estos valores contienen el atributo objectGUID de la directiva, seguido por la dirección de la directiva. Tenga en cuenta que dos de los tipos de dirección se escriben en mayúsculas. Esto indica que son direcciones proxy principales. El tipo de dirección SMTP que está escrito en minúsculas es una dirección proxy secundaria. En base a esta lista de acciones, el Servicio de actualización de destinatarios actualiza las direcciones proxy de todos los usuarios que coinciden con el filtro de la directiva correspondiente. Para aplicar la directiva a todos los usuarios, también debe modificar el filtro de la política (el atributo purportedSearch), agregando o quitando un espacio. Esta modificación hace que el Servicio de actualización de destinatarios, la próxima vez que se ejecute, consulte todos los objetos que coinciden con la directiva, en lugar de consultar únicamente las modificaciones nuevas. Una vez que el Servicio de actualización de destinatarios finaliza la actualización de destinatarios, las direcciones correspondientes a esta directiva específica se quitan de la lista de acción gatewayProxy.

116

Nota: El Servicio de actualización de destinatarios vuelve a generar o quita las direcciones existentes en un destinatario únicamente cuando se rellena la lista de acción con estos tipos de direcciones.

Servicio de actualización de la metabase El servicio de actualización de la metabase, al cual se hace referencia también como proceso de sincronización de la metabase metabase y el servicio de directorios o DS2MB (ya que este proceso se implementa en DS2MB.dll), es un componente de Exchange Server 2003 que se utiliza para sincronizar varios valores de configuración de Exchange en Active Directory con sus valores de configura configuración ción equivalentes en la metabase de IIS. La función de DS2MB consiste en replicar la información de configuración desde Active Directory a la metabase de IIS local. El proceso DS2MB copia subárboles enteros desde Active Directory, sin modificar la forma del el subárbol. Es una escritura de una dirección, desde Active Directory a la metabase; la metabase nunca escribe en Active Directory. El proceso DS2MB no agrega ni contabiliza ningún atributo durante la copia. Las rutas de acceso en la metabase se llaman cl claves. Cada clave puede tener definidas propiedades y cada propiedad puede tener atributos que la personalicen. Todos los identificadores existentes en la imagen del servicio de directorio del subárbol son obligatorios en la metabase, incluidos identificado identificadores res como KeyType. Además, el Nombre completo relativo del objeto en el directorio se correlaciona directamente con el nombre de la clave en la metabase.

Operaciones de DS2MB La actualización de la metabase es un proceso iniciado cuando el Operador de siste sistema se inicia. El funcionamiento de SMTP, POP3, IMAP4, Outlook Web Access y Outlook Mobile Access depende completamente de la réplica realizada por DS2MB. DS2MB se registra con el controlador de dominio de configuración tras el arranque, permitiendo que el controlador de dominio de configuración notifique a DS2MB las modificaciones realizadas en la configuración de Exchange. Esta notificación se produce durante los 15 segundos que siguen al cambio. Tan pronto como se ha replicado la modificación en el controlador contro de dominio de configuración, la modificación debe ser replicada en la metabase por DS2MB. DS2MB realiza un seguimiento de las modificaciones en los objetos de directorio en base a los números de secuencia de actualización (USN).

117

Arquitectura del Administrador del sistema de Exchange El Administrador del sistema de Exchange es una herramienta basada en Microsoft Management Console (MMC) que proporciona a los administradores una interfaz gráfica de usuario (GUI) para administrar la configuración de organizaciones de Exchange 2000 Server o Exchange Server 2003. Sin embargo, el Administrador del sistema de Exchange es más que un complemento. Es un sistema de complementos autónomos y de extensión, que se ejecutan en el proceso de MMC (MMC.exe). Estos complementos se guardan en un archivo MMC preconfigurado denominado Exchange System Manager.msc. Este archivo se encuentra ubicado en el directorio \Archivos de programa\Exchsrvr\Bin. Puede iniciarlo desde el grupo de programas Microsoft Exchange en el menú Inicio, utilizando el acceso directo del Operador de sistema. También puede agregar el complemento del Sistema de Exchange para personalizar herramientas basadas en MMC. El complemento del Sistema de Exchange representa el componente básico del Administrador del sistema de Exchange. En esta sección se explican los siguientes conceptos: •

Integración de MMC Debido a que los complementos del Administrador del sistema de Exchange se basan en MMC, debe comprender cómo se integran estos complementos con MMC.

•

Comunicación con el servicio de directorio de Microsoft Active Directory La mayoría de los objetos de configuración de Exchange Server 2003 residen en Active Directory. Por consiguiente, debe saber qué objetos son y cómo se comunica el Administrador del sistema de Exchange con Active Directory para obtener acceso a estos objetos.

•

Comunicación con el almacén de Exchange Los grupos de almacenamiento, las bases de datos de mensajería y los buzones individuales y carpetas públicas son componentes de almacén de Exchange. Al configurar estos componentes, el Administrador del sistema de Exchange se comunica con el almacén de Exchange a través de MAPI o del protocolo Creación distribuida y control de versiones (DAV). Para determinar los servidores de una red informática que pueden administrarse desde una única consola, debe comprender estos mecanismos de comunicación.

•

Integración con el Instrumental de administración de Windows (WMI) El Administrador del sistema de Exchange se comunica con los proveedores del WMI para mostrar información dinámica, como la lista de los mensajes que actualmente están esperando su entrega en una cola de mensajes. Para comprender como funcionan las herramientas de supervisión, como el visor de colas de mensajes o el centro de seguimiento de mensajes, debe saber cuándo y cómo se comunica el Administrador del sistema de mensajes con los proveedores de WMI y los servicios relacionados

•

Configuración de servicios de Exchange Server 2003 El Administrador del sistema de Exchange también es un programa de configuración de servicios, que puede utilizar para establecer parámetros específicos del servicio en el Registro de un servidor

118

Exchange. Por ejemplo, al especificar niveles de registro de diagnósticos, el Administrador del sistema de Exchange debe tener acceso a la base de datos del Registro de un servidor Exchange. •

En esta sección se asume la familiaridad con Active Directory y los conceptos fundamentales de la administración de una organización de Exchange Server 2003. Se asume también el conocimiento de cómo instalar el Administrador del sistema Exchange en una estación de trabajo dedicada.

Para obtener más información acerca de cómo instalar el Administrador del sistema de Exchange y cómo administrar una organización de Exchange Server 2003 de forma eficaz, consulte Guía de administración de Exchange Server 2003.

Integración con Microsoft Management Console Al instalar el Administrador del sistema de Exchange en un servidor que ejecute Exchange Server 2003 o una estación de trabajo de administración, el programa de instalación registra los complementos de MMC de Exchange en el Registro local, para que estén disponibles en la herramienta MMC. Los complementos se implementan en las bibliotecas de vínculos dinámicos (DLL) del servidor en proceso del Modelo de objetos componentes (COM). En contraste con una aplicación autónoma que se ejecuta como proceso independiente, una biblioteca DLL de servidor en proceso expone uno o más objetos COM y se ejecuta en el proceso de la aplicación cliente que utiliza estos objetos. Por ejemplo, el complemento de MMC se ejecuta en el proceso de MMC.exe. Los complementos deben registrarse en el Registro en las claves siguientes: •

A cada complemento se le asigna un GUID que identifica el complemento como objeto de clase COM exclusivo en una biblioteca DLL de servidor en proceso. Estos identificadores, conocidos como identificadores de clase (CLSID), deben registrarse para cada objeto en la clave del Registro CLSID. Por ejemplo, {1B600AEA-10BA11d2-9F28-00C04FA37610} es el CLSID de la clase SystemMgr. La clase SystemMgr puede encontrarse en una biblioteca DLL de servidor en proceso denominada Exadmin.dll, que se encuentra ubicada en el directorio \Archivos de programa\Exchsrvr\Bin. (La mayoría de complementos de Exchange se encuentran en esta biblioteca DLL.) Las entradas bajo la clave del Registro CLSID definen el modelo de subprocesamiento para las clases COM, el identificador de programa (ProgID), el número de versión de la clase COM, y otros aspectos.

•

Para definir componentes COM como complementos de MMC, los CLSID deben estar registrados bajo la clave SnapIns. Por ejemplo, si busca una clave CLSID de {1B600AEA-10BA-11d2-9F28-00C04FA37610} bajo la clave SnapIns (es decir, el CLSID de la clase SystemMgr), verá que esta entrada pertenece al complemento Sistema de Exchange, que es el complemento básico del

HKEY_CLASSES_ROOT\CLSID

HKEY_LOCAL_MACHINE\Software\Microsoft\MMC\SnapIns

119

Administrador del sistema de Exchange. La tabla siguiente lista las entradas de los complementos bajo la clave SnapIns.

120

Parámetros del Registro para complementos de MMC Clave principal

Parámetro

Tipo

Comentarios

{CLSID}

NameString

REG_SZ

El valor NameString especifica el nombre que se visualiza del complemento, tal y como aparece en la interfaz de usuario de MMC al agregar un complemento a una consola. Por ejemplo, Namestring=Exchan ge System define el nombre que se visualiza del complemento Sistema de Exchange.

{CLSID}

About

REG_SZ

El valor About contiene el CLSID del objeto que se utiliza para proporcionar un icono, una descripción y el cuadro de diálogo Acerca de del complemento. Por ejemplo, About= {1B600AEB-10BA11d2-9F2800C04FA37610} apunta a un CLSID específico. Si busca este CLSID bajo HKEY_CLASSES_ROOT\CL SID,

verá que es el CLSID para la clase AboutSystemMgr, que también reside en Exadmin.dll.

121

Clave principal

Parámetro

Tipo

{CLSID}

NameStringIndirect

REG_SZ

Comentarios

El valor NameStringIndirect

proporciona un identificador de cadena y nombre de biblioteca DLL de recurso, como forma indirecta de recuperar el nombre del complemento. Por ejemplo, NameStringIndirect =@C:\\Archivos de programa\\Exchsrvr \\bin\\exadmin.dll,12577 especifica el nombre del complemento del Sistema de Exchange, como aparece en Exadmin.dll. Si NameStringIndirect

no existe, o si sus datos de valor no conducen a una carga de cadenas satisfactoria, MMC utiliza el valor NameString como cadena de nombre.

122

Clave principal

Parámetro

Tipo

Comentarios

{CLSID}\ StandAlone

N/A

N/A

Una clave StandAlone existente indica que el complemento es un complemento autónomo. Puede agregar complementos autónomos en una consola MMC en el cuadro de diálogo Agregar o quitar complemento. También puede agregar complementos autónomos a subnodos de otros complementos, utilizando el complemento autónomo de la misma forma que un complemento de extensión. Los complementos de extensión no tienen una clave StandAlone. Por consiguiente, el complemento no puede agregarse a una consola MMC sin agregar primero un complemento autónomo que proporcione los nodos que el complemento de extensión ha designado para ampliar. Por ejemplo, el complemento de extensión del Almacén de información de Exchange extiende el complemento del

123

Clave principal

Parámetro

Tipo

Comentarios

{CLSID}\ NodeTypes

{CLSID}

N/A

Por nodos se hace referencia a los objetos de configuración del árbol de la consola MMC. Por ejemplo, en el Administrador del sistema de Exchange, los objetos de servidor individuales en el contenedor para servidores bajo un grupo administrativo son un tipo de nodo específico. Los tipos de nodo se registran en la clave NodeTypes. La clave NodeTypes contiene subclaves que son los GUID de los tipos de nodos. MMC utiliza estos GUID para enumerar los tipos de nodo del complemento y posteriormente utiliza la lista de tipos de nodo para obtener los complementos de extensión para estos tipos de nodo. El conjunto de complementos de extensión aparece posteriormente como extensiones disponibles para el complemento en la ficha Extensiones del cuadro de diálogo Agregar o quitar complemento.

124

•

Todos los tipos de nodo extensibles tienen su propia subclave (es decir, el GUID del tipo de nodo) registrada bajo la clave MMC\NodeTypes. Cada clave GUID contiene una subclave Extensions. La clave Extensions contiene subclaves adicionales que representan los tipos actuales de extensiones que puede tener este tipo de nodo. Cada subclave de tipo de extensión contiene valores que representan los CLSID de los complementos que amplían dicho tipo de nodo. Por ejemplo, el objeto contenedor del Protocolo de oficina de correo versión 3 (POP3) de Exchange (GUID {F54E0C6b-11FF-11d2-9F28-00C04FA37610}) es un tipo de nodo extensible del complemento Protocolos de Exchange. KEY_LOCAL_MACHINE\Software\Microsoft\MMC\NodeTypes

De forma similar, la clave \NodeTypes\{F54E0C6b-11FF-11d2-9F28-00C04FA37610} tiene una subclave Extensions que lista los CLSID del complemento de extensión POP3 de Exchange en las subclaves ContextMenu y NameSpace. Esto indica que el complemento de extensión POP3 de Exchange extiende el espacio de nombres y el menú contextual del Administrador del sistema de Exchange para el objeto contenedor POP3 de Exchange. El espacio de nombres es la jerarquía de todos los objetos que pueden gestionarse a través de una consola MMC.

Complementos de Exchange Server 2003 y extensiones de los complementos Como se ha tratado en la sección anterior, los complementos de extensión y autónomos crean la interfaz de usuario del Administrador del sistema de Exchange. Los complementos de extensión pueden extender las funciones de los complementos autónomos o de otros complementos de extensión. Esta arquitectura modular permite a los desarrolladores implementar funciones de administración específicas. También permite a los administradores crear consolas de administración personalizadas. Por ejemplo, puede poner el complemento Centro de seguimiento de mensajes de Exchange en una consola MMC personalizada y proporcionar este complemento a un administrador de mensajería que sea responsable único de la realización del seguimiento de los mensajes. La tabla siguiente lista los complementos disponibles de Exchange Server 2003 y sus posibles extensiones de complemento.

125

Complementos de Exchange Server 2003 y extensiones de los complementos Complemento

Extensión de

DLL de servidor en

complemento

proceso

Descripción

Centro de seguimiento de mensajes de Exchange

No aplicable

Exadmin.dll

Proporciona obtención de acceso al centro de seguimiento de mensajes. Éste es un complemento autónomo.

Protocolos de Exchange

No aplicable

Exadmin.dll

Implementa el contenedor Protocolos y proporciona nodos de subnivel vacíos que los complementos de extensión adicionales pueden utilizar para mejorar la interfaz de usuario en el Administrador del sistema de Exchange. El complemento Protocolos de Exchange es un complemento de extensión del complemento autónomo Sistema de Exchange. Este complemento es también un complemento de extensión del complemento de extensión Servidores de Exchange.

126

Complemento

Extensión de

DLL de servidor en

complemento

proceso

Descripción

HTTP de Exchange

Exadmin.dll

Permite la administración del protocolo HTTP y de servidores virtuales HTTP.

IMAP4 de Exchange

Imapmgr.dll

Permite la administración del Protocolo de acceso al correo de Internet versión 4 (IMAP4) y de servidores virtuales IMAP4.

NNTP de Exchange

Nntpmgr.dll

Permite la administración del Protocolo de transferencia de noticias a través de la red (NNTP) y de servidores virtuales NNTP.

POP3 de Exchange

Pop3mgr.dll

Permite la administración del protocolo POP3 y de servidores virtuales POP3.

SMTP de Exchange

Exps.dll

Permite la administración del Protocolo simple de transferencia de correo (SMTP) y de servidores virtuales SMTP.

127

Complemento

Servidores Exchange

Extensión de

DLL de servidor en

complemento

proceso

Descripción

X.400 de Exchange

Exadmin.dll

Permite la administración del agente de transferencia de mensajes (MTA) local y de valores de configuración del protocolo X.400.

No aplicable

Exadmin.dll

Permite la administración de valores de configuración específicos del almacenamiento en un servidor Exchange. El complemento Servidores de Exchange es un complemento de extensión del complemento autónomo del Sistema de Exchange.

128

Complemento

Extensión de

DLL de servidor en

complemento

proceso

DXA de Exchange

Exadmin.dll

Descripción

Permite la comprobación de los valores de configuración de la sincronización de directorios al ejecutar el Conecto Conector de Microsoft Exchange para Microsoft Mail en un servidor con una versión anterior de Exchange. Nota: No se admite la configuración de recursos de Exchange 20 00 Server utilizando el Administrado r del sistema de Exchange Server 2003. Asegúrese de utilizar el Administrado r del sistema de Exchange 20 00 para configurar la sincronizació n de directorios con Microsoft Mail.

129

Complemento

Extensión de

DLL de servidor en

complemento

proceso

Descripción

Almacén de información de Exchange

Exadmin.dll

Permite la administración de grupos de almacenamiento, almacenes de buzones y almacenes de carpetas públicas.

Supervisión de Exchange

Exadmin.dll

Le permite examinar el estado de los conectores de mensajería y servidores Exchange entre los grupos de enrutamiento.

Protocolos de Exchange

Exadmin.dll

Como se ha mencionado anteriormente en esta tabla, este complemento implementa el contenedor Protocolos y proporciona nodos de subnivel vacíos que los complementos de extensión HHTP de, IMAP4 de Exchange, NNTP de Exchange, POP3 de Exchange, SMTP de Exchange y X.400 de Exchange utilizan para mejorar la interfaz de usuario en el Administrador del sistema de Exchange.

130

Complemento

Sistema de Exchange

Extensión de

DLL de servidor en

complemento

proceso

Descripción

Visor de colas de Exchange

Exadmin.dll

Proporciona obtención de acceso al visor de colas en el Administrador del sistema de Exchange, que proporciona interfaces de administración para SMTP, MTA, X.400 y otras colas de conector.

No aplicable

Exadmin.dll

El complemento básico de MMC del Administrador del sistema de Exchange. Este complemento autónomo implementa la interfaz de usuario desde la cual un administrador controla los valores de configuración y las propiedades del servidor. También proporciona nodos adicionales que los complementos restantes pueden utilizar para extender la interfaz de usuario.

131

Complemento

Extensión de

DLL de servidor en

complemento

proceso

Descripción

Listas de direcciones de Exchange

Exadmin.dll

Permite la administración de listas de direcciones, incluidas las listas de direcciones globales y las libretas de direcciones sin conexión.

Plantillas de direcciones de Exchange

Exadmin.dll

Permite la administración de plantillas de direcciones.

Conector de calendario de Exchange

Exadmin.dll

Permite la administración de las instancias del Conector de calendario. El Conector de calendario permite la sincronización de información de disponibilidad entre los usuarios de Exchange y los usuarios de Lotus Notes o Novell GroupWise.

132

Complemento

Extensión de

DLL de servidor en

complemento

proceso

cc:Mail para Exchange

Exadmin.dll

Descripción

Permite la comprobación de la configuración del Conector para Lotus cc:Mail que se ejecuta en sistemas Exchange 2000 Server. Nota: No se admite la configuración de recursos de Exchange 20 00 Server utilizando el Administrado r del sistema de Exchange Server 2003. Asegúrese de utilizar el Administrado r del sistema de Exchange 20 00 para configurar el Conector para Lotus cc:Mail.

133

Complemento

Extensión de

DLL de servidor en

complemento

proceso

DXA de Exchange

Exadmin.dll

Descripción

Permite la comprobación de los valores de configuración de la sincronización de directorios al ejecutar el Conector para Microsoft Mail en un servidor con una versión anterior de Exchange. Nota: No se admite la configuración de recursos de Exchange 20 00 Server utilizando el Administrado r del sistema de Exchange Server 2003. Asegúrese de utilizar el Administrado r del sistema de Exchange 20 00 para configurar la sincronizació n de directorios con Microsoft Mail.

134

Complemento

Extensión de

DLL de servidor en

complemento

proceso

Descripción

Carpetas de Exchange

Exadmin.dll

Permite la administración de carpetas públicas y árboles de carpetas públicas.

Conector de Exchange para GroupWise

Exadmin.dll

Permite la administración del Conector para Novell GroupWise.

Almacén de información de Exchange

Exadmin.dll

Permite la administración de grupos de almacenamiento, almacenes de buzones y almacenes de carpetas públicas.

Centro de recuperación de buzones de Exchange

Exadmin.dll

Proporciona obtención de acceso al Centro de recuperación de buzones, que puede utilizarse para recuperar buzones individuales desde una copia de seguridad.

Centro de seguimiento de mensajes de Exchange

Exadmin.dll

Proporciona obtención de acceso al Centro de seguimiento de mensajes y permite su utilización.

135

Complemento

Extensión de

DLL de servidor en

complemento

proceso

Supervisión de Exchange

Exadmin.dll

Descripción

Proporciona obtención de acceso a las funciones de supervisión y estado para administrar la conectividad entre los grupos de enrutamiento.

136

Complemento

Extensión de

DLL de servidor en

complemento

proceso

MSMail para Exchange

Exadmin.dll

Descripción

Permite la comprobación de los valores de configuración del Conector para Microsoft Mail que se ejecuta en servidores Exchange 2000. Nota: No se admite la configuración de recursos de Exchange 20 00 Server utilizando el Administrado r del sistema de Exchange Server 2003. Asegúrese de utilizar el Administrado r del sistema de Exchange 20 00 para configurar el Conector para Microsoft Mail.

Conector de Exadmin.dll Exchange para Notes

Proporciona obtención de acceso a los valores de configuración del Conector para Lotus Notes.

137

Complemento

Extensión de

DLL de servidor en

complemento

proceso

Descripción

Protocolos de Exchange

Exadmin.dll

Como se ha mencionado anteriormente en esta tabla, este complemento implementa el contenedor Protocolos y proporciona nodos de subnivel vacíos que los complementos de extensión HHTP de, IMAP4 de Exchange, NNTP de Exchange, POP3 de Exchange, SMTP de Exchange y X.400 de Exchange utilizan para mejorar la interfaz de usuario en el Administrador del sistema de Exchange.

Visor de colas de Exchange

Exadmin.dll

Proporciona obtención de acceso al visor de colas en el Administrador del sistema de Exchange, que proporciona interfaces de administración para SMTP, MTA, X.400 y otras colas de conector.

138

Complemento

Extensión de

DLL de servidor en

complemento

proceso

Directivas de destinatario de Exchange

Exadmin.dll

Descripción

Permite la administración de directivas de destinatario, que el Servicio de actualización de destinatarios utiliza para asignar información de los destinatarios, como direcciones de correo electrónico, a las cuentas de usuario.

139

Complemento

Extensión de

DLL de servidor en

complemento

proceso

Conector de Exchange para la disponibilidad de Schedule+

Exadmin.dll

Descripción

Permite la comprobación de los valores de configuración del Conector de disponibilidad de Schedule+ en servidores que eje ejecutan Exchange 2000 Server. Nota: No se admite la configuración de recursos de Exchange 20 00 Server utilizando el Administrado r del sistema de Exchange Server 2003. Asegúrese de utilizar el Administrado r del sistema de Exchange 20 00 para configurar el Conector de disponibilidad de Schedule+.

140

Complemento

Extensión de

DLL de servidor en

complemento

proceso

Servidores Exchange

Exadmin.dll

Descripción

Permite la administración de valores de configuración específicos del almacenamiento en un servidor Exchange.

Creación de consolas de administración personalizadas de Exchange Para crear consolas de administración personalizadas basadas en complementos de Exchange, puede utilizar los complementos autónomos Sistema de Exchange o Centro de seguimiento de mensajes de Exchange en la consola MMC. No puede, sin embargo, crear una consola MMC para la administración de carpetas públicas únicamente con el complemento de extensión Carpetas de Exchange. Primero debe agregar el complemento autónomo Sistema de Exchange en la consola. Sin embargo, al agregar el complemento Sistema de Exchange, proporciona al administrador la obtención de acceso a los valores de configuración globales y las propiedades del servidor, cosa que probablemente no desea hacer. Afortunadamente, existe una solución a este dilema. En lugar de agregar complementos independientes a la consola, puede agregar el complemento completo Sistema de Exchange y a continuación ubicar el objeto en el espacio de nombres de MMC que desee proporcionar, como el nodo Carpetas públicas. Al hacer clic con el botón secundario del mouse (ratón) sobre este nodo, puede seleccionar el comando Nueva ventana desde aquí en el menú contextual. De este modo se abrirá una ventana secundaria con el nodo seleccionado como raíz de la jerarquía. A continuación puede cerrar la ventana secundaria que muestra todos los nodos y guardar la consola en su estado actual en un archivo .msc. Las consolas MMC pueden ejecutarse en uno de estos dos modos: modo de autor o modo de usuario. Puede utilizar el modo de autor para crear consolas nuevas o para modificar consolas existentes. El modo de usuario se utiliza para trabajar con consolas existentes para la administración del sistema. Existen tres niveles del modo de usuario: •

Modo de usuario: acceso total Al ejecutar una consola en este modo, el usuario puede utilizar toda la funcionalidad disponible de los complementos, pero no puede agregar o quitar complementos ni guardar modificaciones en la consola.

•

Modo de usuario: acceso limitado, ventanas múltiples Al ejecutar una consola en este modo, el usuario no puede agregar o quitar complementos ni guardar

141

modificaciones en la consola. El usuario no puede tampoco cerrar ninguna ventana que esté abierta cuando el autor de la consola haya guardado la consola por última vez. •

Modo de usuario: acceso limitado, ventana única ú Al ejecutar una consola en este modo, el usuario no puede agregar o quitar complementos ni guardar modificaciones en la consola. El usuario tampoco puede abrir ventanas secundarias adicionales.

La figura siguiente muestra una consola personalizada para para la administración de carpetas públicas. Una consola para la administración de carpetas públicas en modo de usuario

Puede utilizar el modificador de línea de comandos de MMC /a para abrir una consola guardada en modo de autor y realizar modificaciones en las consolas guardadas. Al abrir consolas guardadas utilizando el modificador /a,, se abren en modo de autor, independientemente de su modo predeterminado. Sin embargo, esto no modifica m permanentemente el valor de configuración del modo predeterminado. Si no especifica el modificador /a,, MMC abre los archivos de la consola de acuerdo con sus valores de configuración del modo predeterminado. Nota: No agregue la clave StandAlone a los valores de configuración del Registro de un complemento de extensión para convertir el complemento de extensión en un complemento autónomo. Los complementos de extensión dependen de nodos y funciones expuestas por sus complementos principales y no pue pueden den funcionar correctamente como complementos autónomos.

142

Administración de la información de configuración en Active Directory Al agregar el complemento Sistema de Exchange a una consola personalizada, aparece un cuadro de diálogo Cambiar el controlador de dominio.. Desde este cuadro de diálogo puede seleccionar un controlador de dominio desde un dominio del bosque de la organización de Exchange Server 2003, o puede aceptar la configuración predeterminada para conectar con cualquier controlador de dominio en el cual se pueda escribir. Es necesario tener acceso a Active Directory para llegar a la información de configuración de una organización de Exchange Server 2003, que reside en la partición del directorio de configuración, como se ha explicado anteriormente anteriormen en Exchange Server 2003 y Active Directory. Nota: Puede administrar una organización de Exchange Server 2003 únicamente desde un equipo que sea miembro de un dominio que sea de confianza para los controladores de dominio del bosque que contiene los servidores que ejecutan Exchange Server 2003.

Enlazar con un controlador de dominio El Administrador del sistema de Exchange utiliza Interfaces de serv servicio icio de Active Directory (ADSI) para comunicarse con Active Directory. ADSI se basa en el Protocolo ligero de acceso a directorios (LDAP). Si especifica un controlador de dominio específico en el cuadro de diálogo Cambiar el controlador de dominio, dominio se establece blece una conexión LDAP directa con el controlador de dominio cuando se abre el Administrador del sistema de Exchange. De forma alternativa, si acepta la configuración predeterminada (sin ningún controlador de dominio especificado), ADSI realiza un enlace sin servidor con un controlador de dominio. El enlace sin servidor es el proceso en el cual ADSI utiliza el servicio de ubicación implementado por el servicio Netlogon para buscar el mejor controlador de dominio que se puede utilizar. Este controlador de dominio siempre se encuentra ubicado en el dominio asociado con el contexto de seguridad actual del usuario que se conecta a Active Directory. Cada controlador de dominio registra su nombre de host en el Sistema de nombres de dominio (DNS) y su nombre NetB NetBIOS IOS utilizando un mecanismo específico de transporte, por ejemplo, el Servicio de nombres Internet de Windows (WINS). El servicio de ubicación localiza el nombre y posteriormente envía un datagrama al controlador de dominio que ha registrado el nombre. Para Para los nombres de dominio de NetBIOS, el datagrama es un mensaje de buzón entre procesos. Un buzón entre procesos es un mecanismo proporcionado por el sistema operativo para las comunicaciones entre procesos de uno a uno o de varios a uno (IPC). Para los no nombres mbres de dominio DNS, el datagrama es una búsqueda de Protocolos de datagramas de usuario (UDP) de LDAP. Cada controlador de dominio que responde indica que está actualmente en funcionamiento.

143

Nota: NetBIOS sigue siendo necesario para Exchange Server 2003. 2003. Por consiguiente, no debe retirar los servidores WINS instalados en su red. Por ejemplo, el Administrador del sistema de Exchange podría seleccionar NetBIOS para la comunicación basada en llamadas a procedimientos remotos (RPC) con un servidor Exchange, Exchange si está definido en el orden de enlazado del protocolo RPC. El orden de enlazado del protocolo PRC se define en un parámetro del Registro REG_STRING denominado Rpc_Binding_Order, ubicado bajo: HKEY_LOCAL_MACHINE\ \SOFTWARE\Microsoft\Exchange\Exchange Provider der. El valor predeterminado incluye a NetBIOS: ncalrpc,ncacn_ip_tcp,ncacn_spx,ncacn_np,netbios,ncacn_vns_spp. Sin embargo, la comunicación con los controladores de dominio se basa en LDAP y no necesita NetBIOS o WINS. Como se indica en la figura siguiente,, el servicio de ubicación prefiere los controladores de dominio en el sitio Active Directory local, y se conecta con el primer controlador de dominio que responde. Cuando el servicio de ubicación envía un datagrama al controlador de dominio, el controladorr de dominio busca la dirección IP (protocolo Internet) del cliente en el contenedor Configuration/Sites/Subnet de Active Directory, para buscar un objeto de subred que corresponda a la región de dirección IP del cliente. La propiedad siteObject del objeto de subred revela el nombre completo del sitio que contiene el cliente, por ejemplo: CN=DefaultCN=Default First-Site-Name,CN=Sites,CN=Configuration,DC=fabrikam,DC=com. Name,CN=Sites,CN=Configuration,DC=fabrikam,DC=com. El controlador de dominio responde al datagrama con el nombre completo del sitio que contiene el cliente, c junto con un indicador de si el controlador cubre el sitio. Si el controlador de dominio no cubre el sitio, y el servicio de ubicación todavía no ha intentado buscar un controlador de dominio en el sitio del cliente, el servicio de ubicación intenta intenta buscar de nuevo un controlador de dominio en el sitio local. Una vez se ha localizado un controlador de dominio, se establece una conexión LDAP con Active Directory, y se almacena en caché la información de conexión, para que las conexiones subsiguientes desde la misma aplicación no requieran la repetición del algoritmo de enlace sin servidor. La caché de enlace contiene identificadores de conexión con los servidores adecuados, además de características de conexión, como la información de cifrado y autent autentificación.

144

Enlazado sin servidor con un controlador de dominio

Nota: Un enlace sin servidor es el método de conexión preferido, ya que equilibra las solicitudes de múltiples clientes entre múltiples controladores de dominio, y puede cambiar a otro controlador trolador de dominio automáticamente cuando un controlador de dominio pasa a estar no disponible.

La organización de Exchange en la partición del directorio de configuración La mayor parte de los valores de configuración que puede administrar con el Administrador Adminis del sistema de Exchange se almacena en objetos de directorio en la partición del directorio de configuración de Active Directory. La jerarquía de los objetos de configuración que aparece en el árbol de la consola del Administrador del sistema de Exc Exchange hange coincide en gran manera con la jerarquía de los objetos de directorio de la partición del directorio de configuración. Únicamente existen pequeñas diferencias. Por ejemplo, en una organización con un único grupo administrativo y un grupo de enrutamie enrutamiento, nto, puede visualizar los objetos de configuración en una jerarquía con o sin grupos administrativos y de enrutamiento. Para hacerlo, debe activar o desactivar las casillas de comprobación Mostrar los grupos de enrutamiento y Mostrar los grupos administrat administrativos de la ficha General en las propiedades del objeto de organización de Exchange (es decir, el objeto raíz en el árbol de la consola del Administrador del sistema de Exchange). No obstante, los contenedores administrativos y de enrutamiento siempre existen existen en la partición del directorio de configuración. La figura siguiente ilustra la jerarquía de los objetos de directorio desde la partición del directorio de configuración (que aparece en Sitios y servicios de Active Directory) comparada con la jerarquía de los objetos de configuración en el Administrador del sistema de Exchange (con los grupos administrativos y de enrutamiento habilitados).

145

Jerarquías de directorio y objetos de configuración

El Administrador del sistema de Exchange ordena los objetos de configuración de la partición del directorio de configuración en el árbol de la consola, de acuerdo con las categorías generales siguientes: •

Objetos globales de Exchange Los objetos globales de Exchange son objetos que definen los formatos de los mensajes de Internet y otros valores de configuración que afectan a toda la organización de Exchange. Por ejemplo, el objeto Servicios móviles define los valores de configuración para Exchange ActiveSync y Microsoft Office Outlook Mobile Access que se aplican a todos los destinatarios de la organización de Exchange. Los objetos de directorio que corresponden a estos objetos de configuración residen en el contenedor Configuración global, bajo el contenedor de organización de Exchange en la partición del directorio de configuración.

•

Objetos de destinatario Los objetos de destinatario definen reglas que determinan las direcciones de correo electrónico que el Servicio de actualización de destinatarios asigna a los objetos de destinatario habilitados para correo y habilitados para buzón. Los objetos de destinatario determinan también la forma en que se generan las listas de direcciones basadas en servidor. Mediante el uso de los objetos de configuración en el contenedor Destinatarios del Administrador del sistema de Exchange, se pueden personalizar las plantillas de detalles y de dirección para modificar la interfaz de usuario de la libreta de direcciones en Outlook. El contenedor Destinatarios del Administrador del sistema de Exchange consolida objetos de directorio desde unos contenedores determinados en la partición del directorio de configuración. Los objetos de definición de la lista de direcciones y los

146

objetos del Servicio de actualización de destinatarios se encuentran en el contenedor Listas de direcciones, los objetos para las plantillas de detalles y de dirección se encuentran en el contenedor Direccionamiento, y los objetos para las directivas que definen las direcciones de correo electrónico para los destinatarios habilitados para correo y habilitados para buzón se encuentran en el contenedor Directivas de destinatarios, bajo el objeto de organización de Exchange en Active Directory. •

Objetos de grupo de enrutamiento y administrativo Los objetos de grupo administrativo y de enrutamiento no proporcionan acceso a ningún parámetro de configuración en el Administrador del sistema de Exchange. En lugar de ello, se utilizan para definir la topología administrativa y la topología de enrutamiento de mensajes de una organización de Exchange. Por ejemplo, puede utilizar grupos administrativos para dividir la administración de servidores y recursos de Exchange. Con los grupos de enrutamiento, puede simplificar la transferencia de mensajes entre distintos sitios y ubicaciones. Para obtener más información acerca de la planificación de grupos administrativos y de enrutamiento, consulte Planning an Exchange Server 2003 Messaging System.

•

Objetos de servidor Los objetos de servidor contienen los valores de configuración que se aplican a servidores Exchange individuales en la organización de la mensajería. Los objetos de servidor también contienen objetos de configuración adicionales para grupos de almacenamiento y protocolos de mensajería. Cuando se muestran las propiedades de un objeto de servidor, el Administrador del sistema de Exchange consolida información de una gran variedad de orígenes de información en las diversas fichas de propiedades. Los objetos de configuración del servidor corresponden a los objetos del directorio del servidor en la partición del directorio de configuración que reside en el contenedor Servidores, bajo un grupo administrativo.

•

Objetos de directiva del sistema Puede utilizar objetos de directiva del sistema para simplificar la administración del sistema mediante la configuración de parámetros para múltiples servidores Exchange a través de un único objeto de configuración, como un almacén de buzones, un almacén de carpetas públicas o valores de configuración del servidor. No obstante, de forma predeterminada, los objetos de directiva del sistema no existen. Para crear una directiva del sistema, primero debe agregar un contenedor de Directivas del sistema específico a su grupo administrativo. Para hacerlo, haga clic con el botón secundario del mouse (ratón) en el grupo administrativo, apunte a Nuevo, y posteriormente seleccione Contenedor de Directivas del sistema. Posteriormente, para crear una Directiva de almacenamiento en buzón, Directiva del almacén público o Directiva del servidor, haga clic con el botón secundario del mouse en el contenedor Directivas del sistema y configure su directiva. Para obtener más información acerca de la configuración del almacén de buzones, del almacén de carpetas públicas o de las propiedades del servidor, consulte Exchange Server 2003 Administration Guide.

•

Jerarquías de carpetas Los objetos de jerarquía de carpetas pueden encontrarse en el contenedor Carpetas, bajo un grupo administrativo. Cada objeto de jerarquía en este

147

contenedor hace referencia a un árbol de carpeta pública específico en el almacén de Exchange. Un árbol de carpeta pública puede replicarse a través de almacenes alm públicos en múltiples servidores Exchange. Sin embargo, los objetos de jerarquía residen en el contenedor Jerarquías de carpetas, bajo un grupo administrativo en la partición del directorio de configuración. Nota: El nodo Herramientas del Administ Administrador rador del sistema de Exchange no corresponde a un objeto de directorio en la partición del directorio de configuración. El nodo Herramientas proporciona obtención de acceso a complementos de extensión, como el Centro de seguimiento de mensajes, que a su vez vez podría tener acceso a objetos de Active Directory para mantener la información de configuración.

El Administrador del sistema de Exchange y las configuraciones de permisos El modelo de permisos de Exchange Server 2003 se basa completamente en el modelo de d seguridad de Microsoft Windows. El modelo de permisos está estructurado en el objeto de organización de Exchange y los grupos administrativos en la partición del directorio de configuración. Mediante un clic con el botón secundario del mouse en el objeto de organización o el grupo administrativo del árbol de la consola del Administrador del sistema de Exchange, puede seleccionar el mandato Delegar control para iniciar el Asistente para delegar la administración. Mediante la utilización del asistente para delegar la administración, puede asignar a un administrador de Exchange una de las tres funciones siguientes: •

Administrador total de Exchange Esta función unción garantiza al administrador un control total sobre la organización de Exchange. Sin embargo, los permisos Recibir como y Enviar como están específicamente denegados. Por ello, un Administrador total de Exchange no puede representar a otro usuario en la organización de Exchange. Por ejemplo, un administrador que no tiene permiso Enviar como no puede enviar mensajes de correo electrónico en sustitución de otro usuario.

•

Administrador de Exchange Esta función garantiza al administrador unos permisos similares imilares a los de un Administrador total de Exchange, pero deniega los permisos Modificar propietario y Modificar permisos. Por consiguiente, un administrador de Exchange puede administrador todos los valores de configuración de una organización de Exchange, e, pero no puede modificar los valores de configuración de seguridad.

•

Administrador con permiso de vista de Exchange Esta función garantiza al administrador permisos para Leer todas las propiedades, Mostrar contenido, Permisos de lectura y Ver estado d del el almacén de información. Por ejemplo, los permisos del Administrador con permiso de vista de Exchange son necesarios para los administradores de buzones que deben habilitar para correo o habilitar para buzón las cuentas de usuario, pero no son responsables responsables de la administración del servidor Exchange.

148

La tabla siguiente lista las diferencias clave entre las diversas funciones de administrador de Exchange. Diferencias clave entre las funciones de administrador de Exchange Función de

Modifica los valores

Administra los valores

Visualiza los valores

administrador

de configuración de

de configuración de

de configuración de

seguridad

Exchange

Exchange

Administrador total de Exchange

Sí

Sí

Sí

Administrador de Exchange

No

Sí

Sí

Administrador con permiso de vista de Exchange

No

No

Sí

Habilitar la ficha Seguridad para objetos del Administrador del sistema de Exchange El Asistente de delegación de administración se utiliza para asegurar las funciones a los grupos o administradores de Exchange individuales a nivel de grupo administrativo o de la organización. Sin embargo, el Asistente para delegar la administración no muestra todos los valores de configuración de seguridad y algunas veces puede incluso mostrar una lista de administrador incompleta. Esto se debe a que el Asistente para delegar la administración realiza un seguimiento de los administradores a los cuales asegura las funciones de administrador de Exchange, en un atributo del objeto de organización de Exchange en Active Directory. Este atributo se denomina msExchAdmins. Sin embargo, el Asistente para delegar la administración no realiza un seguimiento de los administradores con permisos heredados de contenedores de nivel superior en la partición del directorio de configuración. Por ejemplo, de forma predeterminada, los Administradores de organización tienen permisos totales en toda la partición del directorio de configuración. Esto es debido a que la configuración de los permisos totales se hereda del contenedor de Configuración raíz a todos los contenedores secundarios. Sin embargo, el Asistente para delegar la administración no lista estos administradores como Administradores totales de Exchange, ya que no están listados en el atributo msExchAdmins. La herencia de permisos se explica en la sección "La herencia de permisos y el Administrador del sistema de Exchange", más adelante en este tema. Es más, si asigna a un grupo de seguridad la función de Administrador total de Exchange a nivel de la organización, posteriormente no podrá utilizar el Asistente para delegar la administración para rebajar el nivel de los miembros de dicho grupo a la función de Administrador con permiso de vista de Exchange para un grupo administrativo específico.

149

Esto se debe a que el Asistente para delegar la administración no deniega permisos asegurados mediante valores de configuración de seguridad heredados de contenedores primarios. Si utiliza el Asistente para delegar la administración para asignar a miembros individuales la función de Administrador con permiso de vista de Exchange para un grupo administrativo, el Asistente para delegar la administración lista estas cuentas como cuentas de Administrador con permiso de vista de Exchange. Sin embargo, estas cuentas retienen su función de Administrador total de Exchange, que se hereda a través de su pertenencia al grupo desde el nivel de organización. Para examinar los valores de configuración de seguridad actuales, debe habilitar la ficha Seguridad de los objetos de grupo de organización y administrativo, en el Administrador del sistema de Exchange. Para hacerlo, establezca el parámetro del Registro ShowSecurityPage, como se muestra en la tabla siguiente. El parámetro del registro ShowSecurityPage HKEY_CURRENT_USER\Software\Microsoft\Ex change\ExAdmin

Nombre de valor

ShowSecurityPage

Tipo de datos

REG_DWORD

Valor

1

Descripción

Este valor de configuración únicamente afecta al usuario que actualmente ha iniciado la sesión. Si el valor ShowSecurityPage no está presente o se establece en 0, la ficha Seguridad aparece únicamente en los objetos siguientes: •

Listas de direcciones

•

Listas globales de direcciones

•

Almacenes de buzones

•

Almacenes de carpetas públicas

•

Jerarquías de carpetas públicas de nivel superior

Si el valor ShowSecurityPage se establece en 1, la ficha Seguridad aparece en todos los objetos del Administrador del sistema de Exchange. Las modificaciones de producen inmediatamente. No tiene que reiniciar el Administrador del sistema de Exchange.

150

Precaución: La modificación incorrecta del Registro puede ocasionar problemas graves que quizás requieran volver a instalar el sistema operativo. Es posible que los problemas derivados de una modificación incorrecta del Registro no se puedan resolver. Antes de modificar el Registro, se recomienda realizar u una na copia de seguridad de todos los datos importantes.

La herencia de permisos y el Administrador del sistema de Exchange Si examina los valores de configuración de seguridad de una organización de Exchange, en el Administrador del sistema de Exchange, en lla ficha Seguridad,, observará que los valores de configuración de seguridad se asignan a varios grupos y cuentas del sistema, además de a las cuentas a las que se ha asignado específicamente una función de Administrador de Exchange. La tabla siguiente lista estas cuentas y sus permisos. Cuentas predeterminadas con permisos en una organización de Exchange Cuenta

Permitido

Denegado

INICIO DE SESIÓN ANÓNIMO

•

Crear propiedades con nombre en el almacén de información

Ninguno

•

Crear carpeta pública

•

Ejecutar

•

Mostrar contenido

•

Mostrar objeto

•

Leer

•

Permisos de lectura

•

Propiedades de lectura

•

Propiedades de lectura

•

Mostrar objeto

Usuarios autenticados

Ninguno

151

Cuenta

Permitido

Denegado

Administradores de dominio (dominio raíz)

•

Leer

•

Recibir como

•

Escribir

•

Enviar como

•

Ejecutar

•

Eliminar

•

Permisos de lectura

•

Cambiar permisos

•

Tomar posesión

•

Crear secundarios

•

Mostrar contenido

•

Agregarse o quitarse a sí mismo

•

Propiedades de lectura

•

Propiedades de escritura

•

Mostrar objetos

•

Crear carpeta pública

•

Crear carpeta pública de nivel superior

•

Modificar ACL de administración de carpeta pública

•

Modificar lista de replicación de carpeta pública

•

Abrir cola Mail Send

•

Leer propiedades de la metabase

•

Administrar almacén de información

•

Crear propiedades con nombre en el almacén de información

•

Ver el estado del almacén de información

•

Recibir como

•

Enviar como

152

Cuenta

Permitido

Denegado

Administradores de organización

•

•

Recibir como

•

Enviar como

Todos

•

Crear propiedades con nombre en el almacén de información

•

Crear carpeta pública

•

Ejecutar

•

Mostrar contenido

•

Mostrar objetos

•

Leer

•

Permisos de lectura

•

Propiedades de lectura

•

Control total

Servidores de dominio de Exchange

Control total

Ninguno

Ninguno

La mayoría de los valores de configuración de los permisos son heredados por los objetos de configuración desde contenedores primarios en la jerarquía de la partición del directorio de configuración. Por ejemplo, los Administradores de organización tienen asegurado el Control total en el contenedor raíz de la partición del directorio de configuración. Dado que los permisos son heredados de forma predeterminada por todos los objetos secundarios de la partición del directorio de configuración, incluido el contenedor de organización de Exchange, los Administradores de organización son también Administradores totales de Exchange. No puede utilizar el Administrador del sistema de Exchange para examinar los valores de configuración de seguridad para los contenedores primarios de la partición del directorio de configuración, pero puede examinar los valores de configuración reales utilizando la herramienta Editor de ADSI. La figura 4.4 muestra los valores de configuración de seguridad para el grupo del Administradores de organización, tal y como se aplican al contenedor de configuración. La figura siguiente muestra también que estos valores de configuración se aplican al contenedor de configuración y a sus objetos secundarios, incluida la organización de Exchange.

153

Valores de configuración de seguridad para Administradores de organización tal y como aparecen en el Editor ADSI

La herencia de permisos es una función que facilita la asignación de permisos en la partición del directorio de configuración de Active Directory. Por ejemplo, en el Administrador del sistema de Exchange, El Asistente para delegar la administración se base en la herencia de permisos para asignar funciones de administración de Exchange a cuentas y grupos en el nivel de grupo administrativo y de organización. Cuando asigna la función de Administrador total de Exchange a una cuenta de administrador en el nivel de organización, el Asistente para delegar la administración asegura a la cuenta permisos de Control total en el contenedor primario, denominado Microsoft Exchange (figura 4.4). Por ello, se aplica el control total tanto al contenedor secundario, denominado Conexiones de Active Directory, como a la organización de Exchange. Sin embargo, las cuentas con permisos administrativos asignados en el nivel de grupo administrativo tienen asegurados permisos de Lectura también en el nivel organizativo, de tal forma que estos administradores pueden mostrar la información de configuración en el Administrador del sistema de Exchange. Para obtener más información acerca del Asistente para delegar la administración y las asignaciones de permisos en una organización de Exchange, consulte Exchange Server 2003 Security Hardening Guide.

154

Administración de recursos de almacén de Exchange Active Directory no es el único asociado de comunicación del Administrador del sistema de Exchange. Diversos complementos del Administrador del sistema de Exchange se comunican también con el almacén de Exchange. Esto le permite visualizar información en tiempo real acerca de recursos de almacenamiento de Exchange y administrar carpetas públicas. El Administrador del sistema de Exchange utiliza MAPI para visualizar estadísticas de buzón e inicios de sesión de cliente. Utiliza el protocolo de Creación distribuida y control de versiones (DAV) para visualizar y administrar recursos públicos.

Comunicación basada en MAPI La figura siguiente ilustra la diferencia entre los objetos de almacén de buzones y almacén de carpetas públicas en Active Directory y el Administrador del sistema de Exchange. En Sitios y servicios de Active Directory, los objetos de almacén de buzones y almacén de carpetas públicas se representan mediante nodos de hoja que no contienen objetos secundarios. En el Administrador del sistema de Exchange, sin embargo, los objetos de almacén de buzones y almacén de carpetas públicas están representados como nodos en el árbol de la consola. Contienen diversos contenedores secundarios, como Inicios de sesión, Buzones o Carpetas públicas, Instancias de carpetas públicas, Estado de la replicación e Indización de texto completo.

155

Objetos de buzón y de almacén de carpetas públicas en Sitios y servicios de Active Directory y en el Administrador del sistema de Exchange

Información obtenida a través de la interfaz IExchangeManageStore Los contenedores secundarios bajo los objetos de almacén de buzones y almacén de carpetas públicas son contenedores virtuales que no existen en Active Directory ni en ningún otro lugar. Para visualizar estos contenedores, El Administr Administrador ador del sistema de Exchange debe comunicarse con el almacén de Exchange a través de la interfaz IExchangeManageStore, que es una interfaz interna basada en MAPI. Esta comunicación MAPI es de naturaleza dinámica y se produce al expandir un almacén de buzones buzon o un almacén de carpetas públicas específico en el Administrador del sistema de Exchange. No se pueden visualizar los contenedores secundarios de un almacén de buzones o un almacén de carpetas públicas si el almacén de buzones o el almacén de carpetas públicas p está desmontado. La comunicación a través de MAPI se produce también al agregar almacenes de buzones o almacenes de carpetas públicas a un servidor Exchange, al visualizar las propiedades de un almacén de buzones individual o un almacén de carpetas públicas, y al montar o desmontar almacenes de buzones o almacenes de carpetas públicas. Nota: La comunicación basada en MAPI requiere que trabaje con una cuenta del Administrador del sistema de Exchange que sea miembro del grupo de Administradores local. local. Esto le proporciona permisos de escritura en el directorio

156

\System32 System32 del equipo local. Esto es necesario para que al Administrador del sistema de Exchange pueda crear un perfil MAPI dinámico. La comunicación con un servidor Exchange no puede producirse a través de MAPI sin un perfil MAPI. El Administrador del sistema de Exchange llama a los métodos siguientes de IExchangeManageStore para obtener información dinámica acerca de los almacenes de buzones y de carpetas públicas: •

GetMailboxTable El método método GetMailboxTable obtiene información acerca de todos los buzones de un almacén de buzones. Este método devuelve un puntero a una interfaz MAPI IMAPITable, que contiene información acerca de todos los buzones en el almacén de Exchange especificado. Cada fi fila la de esta tabla MAPI representa un buzón individual. Las columnas de la tabla proporcionan información detallada acerca del buzón, como el nombre, el número de mensajes, el tamaño de los mensajes, el nombre de la cuenta de usuario de Windows del último us usuario uario que ha iniciado una sesión en el buzón, y la fecha y la hora en que ha iniciado la sesión el último usuario. De forma adicional, las columnas indican si un buzón está actualmente dentro de los límites de almacenamiento.

•

GetPublicFolderTable El método GetPublicFolderTable obtiene información acerca de todas las carpetas públicas en un almacén de carpetas públicas. Este método devuelve un puntero a una interfaz MAPI IMAPITable, que contiene información acerca de todas las carpetas públicas en el almacén almacén de Exchange especificado. Cada fila de esta tabla MAPI representa una carpeta pública individual. Las columnas de la tabla proporcionan información detallada acerca de la carpeta pública, como el nombre, el número de mensajes asociados, los tamaños (en bytes) de todos los mensajes asociados, el número de mensajes asociados con datos adjuntos, el número de columnas almacenadas en caché y de categorizaciones en la carpeta pública, el número de contactos de carpetas públicas, la fecha y la hora en que se se ha obtenido acceso a la réplica de una carpeta pública, y la fecha y la hora en que se ha modificado por última vez un objeto en una carpeta pública. Sugerencia: Puede visualizar toda la información obtenida para un almacén de buzones o un almacén de carpetas arpetas públicas. Para obtener instrucciones detalladas, consulte Cómo mostrar toda la información información obtenida de un almacén de buzón o almacén de carpetas públicas.

El Administrador del sistema de Exchange y los clientes basados en MAPI Como el Administrador del sistema de Exchange utiliza MAPI para obtener información dinámica del almacén de Exchange, no instale clientes basados en MAPI, como Microsoft Outlook, en una estación de trabajo o un servidor Exchange que ejecute el Administrador del sistema de Exchange. El Administrador del sistema de Exchange utiliza Mapi32.dll para comunicarse con el almacén de Exchange. Mapi32.dll representa un componente básico del

157

subsistema MAPI, y está ubicado en la carpeta Winnt Winnt\System32. System32. Si instala Microsoft Office Outlook 2000 o posterior en el mismo equipo que contiene el Administrador del sistema de Exchange, el subsistema sistema MAPI se traslada a la carpeta Archivos de programa\Common programa Files\System\Mapi\1033\\NT. NT. Normalmente, Outlook instala una versión auxiliar de MAPI en la carpeta Winnt\System32, System32, que posteriormente dirige las llamadas MAPI a la implementación de Outlook. Si sustituye la versión de Exchange Server 2003 de Mapi32.dll con la implementación de Outlook, el sistema podría experimentar conflictos de versión en el subsistema MAPI y podría causar que fallara el Administrador del sistema de Exchange. Nota: Si debe be instalar Outlook y Exchange Server 2003 en el mismo equipo porque, por ejemplo, una solución que no es de Microsoft (como un programa de copias de seguridad basado en MAPI) requiere componentes de Outlook, lea primero el artículo 266418 de Microsoft Kno Knowledge Base "Microsoft Microsoft does not support installing Exchange Server components and Outlook on the same computer". computer

Comunicación basada en DAV Para crear, administrar y suprimir recursos d de e carpetas públicas, el Administrador del sistema de Exchange (específicamente el complemento Carpetas públicas) utiliza DAV para comunicarse con el almacén de Exchange. DAV es un protocolo basado en HTTP. Por consiguiente, la obtención de acceso al almacén almacén de Exchange se proporciona a través del Servicio de publicación en World Wide Web (w3svc). Los comandos de DAV, como PROPFIND, SEARCH, DELETE, MOVE, COPY y OPTIONS, están codificados mediante XML. Nota: El Administrador del sistema de Exchange utiliza DAV para la Administración de carpetas públicas, ya que DAV es el único protocolo con capacidades remotas en Exchange Server 2003 que funciona con jerarquías de carpetas públicas de propósito general y basadas en MAPI.

Comunicación basada en DAV y director directorios virtuales HTTP De forma predeterminada, Exchange Server 2003 crea los siguientes directorios virtuales HTTP en un servidor Exchange: •

Exchweb Almacena gráficos y archivos adicionales requeridos por Microsoft Office Outlook Web Access para Exchange Server 2003. Este es un directorio virtual estándar que apunta al directorio \Archivos de programa\Exchsrvr\Exchweb Exchweb del disco duro del servidor.

158

•

Exchange Utilizado por Outlook Web Access para obtener acceso a buzones. Este directorio virtual enlaza con la dirección URL \\.\BackOfficeStorage\<nombre de dominio completo del servidor>\mbx.

•

Public Utilizado por Outlook Web Access para la obtención de acceso a las carpetas públicas. Este directorio virtual enlaza con la dirección URL \\.\BackOfficeStorage\<nombre de dominio completo del servidor>\public folders.

•

Exadmin Utilizado por el Administrador del sistema de Exchange para administrar carpetas públicas. Este directorio virtual enlaza con la dirección URL \\.\BackOfficeStorage.

Para el Administrador del sistema de Exchange, el directorio virtual HTTP más importante es el directorio Exadmin. Exadmin proporciona acceso a todas las jerarquías de carpetas públicas, también denominadas árboles de carpetas públicas, en un servidor Exchange. Este acceso está habilitado porque Exadmin apunta directamente al espacio de nombres BackOfficeStorage. Para proporcionar acceso a todos los almacenes de buzones y de carpetas públicas en un servidor Exchange, el proveedor OLE DB (ExOLEDB) de Exchange registra el espacio de nombres BackOfficeStorage con el RootBinder de OLE DB. Al expandir la jerarquía de carpetas públicas o crear, administrar o eliminar carpetas públicas en el Administrador del sistema de Exchange, se produce la comunicación a través del directorio virtual Exadmin. El Administrador del sistema de Exchange también utiliza otros directorios virtuales HTTP. Por ejemplo, el Administrador del sistema de Exchange utiliza el directorio virtual Public para visualizar el contenido de las carpetas públicas basadas en MAPI. El directorio virtual Public existe en todos los servidores Exchange. Sin embargo, si crea un árbol de carpetas de propósito general adicional y lo asocia con un almacén público adicional, el Administrador del sistema de Exchange no podrá mostrar contenidos de carpetas públicas hasta que se cree un directorio virtual para proporcionar acceso basado en HTTP a esta jerarquía. Para obtener información adicional acerca de cómo crear y configurar almacenes y jerarquías de carpetas públicas, consulte la Exchange Server 2003 Administration Guide. La figura siguiente muestra el contenido de una carpeta pública, tal y como aparece en el Administrador del sistema de Exchange.

159

El contenido de una carpeta pública basada en MAPI en el Administrador del sistema de Exchange

El Administrador del sistema de Exchange y el directorio virtual Exadmin La mayor parte de la interacción que tiene lugar entre el complemento Carpetas públicas del Administrador del sistema de Exchange y el almacén de Exchange se lleva a cabo a través del directorio virtual Exadmin. Exadmin depende del proveedor ExOLEDB, que es un componente al que no se puede obtener acceso de forma remota. El Administrador del sistema de Exchange debe obtener acceso al directorio virtual Exadmin del servidor de Exchange que aloja el almacén público asociado a la jerarquía de carpetas públicas. Este servidor se determina con información obtenida del objeto de directorio que se corresponde con la jerarquía de carpetas públicas. La figura siguiente muestra cómo se comunica el Administrador del sistema de Exchange con un almacén de Exchange a través del directorio virtual Exadmin.

160

Comunicación con un almacén público a través del directorio directorio virtual Exadmin

El Administrador del sistema de Exchange lleva a cabo los siguientes pasos al conectarse al directorio virtual Exadmin. 1. Obtiene una lista de almacenes de Exchange de la jerarquía de objetos El Administrador del sistema de Exchange lee el atributo msExchOwningPFTreeBL del objeto de jerarquía de carpetas públicas de Active Directory. Esto determina la lista de servidores de Exchange que alojan almacenes públicos asociados a la jerarquía de carpetas públicas. Sugerencia: Puede ver los almacenes de Exchange tal y como figuran en el atributo msExchOwningPFTreeBL al mostrar las propiedades de la jerarquía de carpetas públicas del Administrador del sistema de Exchange. Los almacenes figuran en la ficha General, General en Almacenes públicos blicos asociados al árbol de carpetas. carpetas 2. Selecciona el servidor de destino y recupera la información de enlace de Exadmin El Administrador del sistema de Exchange selecciona un servidor que contiene una réplica de la jerarquía de carpetas públicas y, a continuación, lee la información de configuración del directorio virtual Exadmin de ese servidor. El directorio virtual Exadmin está representado en Active Directory por un objeto de directorio, denominado Exadmin, Exadmin que reside en el servidor virtual HTTP predeterminado edeterminado del servidor, denominado Servidor virtual de Exchange.. El atributo msExchServerBindings de ese objeto de directorio contiene el número de puerto TCP que debe usar el Administrador del sistema de Exchange para conectarse al directorio virtual Exadmin E del servidor de Exchange que aloja la jerarquía de carpetas públicas. Si no se establece este atributo, el Administrador del sistema de Exchange usa el puerto TCP 80 predeterminado.

161

Nota: Si ejecuta el Administrador del sistema de Exchange de forma forma local en un servidor de Exchange que aloja un almacén público asociado a la jerarquía de carpetas públicas, el Administrador del sistema de Exchange intenta conectarse primero al servidor local. 3. Usainformación de enlace para conectarse al directorio virtual Exadmin El Administrador del sistema de Exchange usa el número de puerto TCP obtenido del atributo msExchServerBindings para conectarse al directorio virtual Exadmin del servidor de Exchange seleccionado. A continuación, solicita una lista de tod todas as las carpetas públicas de nivel superior de la jerarquía. En el encabezado de agente de usuario HTTP de la solicitud HTTP, el Administrador del sistema de Exchange se identifica como un cliente de administración de Exchange. Los Servicios de Internet Information Information Server (IIS) autentican el cliente y devuelven la lista de carpetas públicas de nivel superior al Administrador del sistema de Exchange. 4. Muestra las carpetas públicas de nivel superior El Administrador del sistema de Exchange muestra las carp carpetas etas públicas de nivel superior como objetos contenedores en el árbol de consola, bajo la jerarquía de carpetas públicas. Este paso no se muestra en la figura anterior. Nota: De forma predeterminada, sólo se muestran las carpetas de nivel superior del subárbol ubárbol de mensajes interpersonales (IPM), pero también se pueden mostrar las carpetas del subárbol que no es IPM haciendo clic con el botón secundario del mouse (ratón) en el objeto de jerarquía y seleccionando Ver carpetas del sistema.

Conexión a un servidor servidor de Exchange específico Puede asociar una jerarquía de carpetas públicas con almacenes de carpetas públicas de varios servidores de Exchange. Al hacer esto, la jerarquía se replica entre esos almacenes públicos de forma automática. Esta replicación garantiza garantiza que todas las carpetas públicas saben de la existencia de todas las carpetas públicas de la jerarquía. Por lo tanto, puede conectarse a cualquiera de esos servidores de Exchange para administrar recursos de carpetas públicas. De hecho, el cambio de un servidor a otro le permite comprobar que todos los almacenes públicos tienen una vista coherente de la jerarquía. Por ejemplo, podría desear hacer esto al realizar un diagnóstico de problemas relacionados con la replicación de la jerarquía. Para ver instrucciones instrucciones detalladas acerca de cómo conectar con un servidor de Exchange específico, consulte Cómo o conectar a un servidor de Exchange específico en el Administrador del sistema de Exchange Exchange. Nota: El Administrador del sistema de Exchange siempre se conecta directamente al servidor de Exchange que aloja el almacén público asociado a la jerarquía de

162

carpetas rpetas públicas seleccionada. No se puede establecer la conexión con un almacén público a través de un servidor de aplicaciones para usuario.

El Administrador del sistema de Exchange y el sitio Web predeterminado Tanto si especifica un almacén de carpetas públicas al que conectarse como si deja que el Administrador del sistema de Exchange lo escoja, los mecanismos de conexión siguen siendo los mismos, tal y como se explicó anteriormente en esta sección. No obstante, el directorio virtual Exadmin debe estar ubicado en el servidor de Exchange del sitio Web predeterminado de IIS. En el Administrador de IIS, compruebe que Dirección IP esté establecida como (Todos sin asignar), asignar) Puerto TCP como 80 y que Valor de encabezado de host no se ha especificado. Esto se debe a que el Administrador del sistema de Exchange intenta conectarse al puerto TCP 80 de forma predeterminada y especifica el nombre del servidor de Exchange en el valor de encabezado de host de las solicitudes HTTP. Si especifica pecifica un valor de encabezado de host para el sitio Web predeterminado del Administrador de IIS distinto del nombre del servidor, el Administrador del sistema de Exchange no puede obtener acceso al directorio Exadmin. Por lo tanto, se recibe un mensaje de e error que indica que no se pudo realizar la operación debido a un formato inválido de la solicitud HTTP. No podrá administrar los recursos de carpetas públicas, aunque podría conseguir obtener acceso a carpetas públicas en Outlook Web Access. Para obtener obtene más información acerca de los problemas con el acceso al directorio virtual Exadmin, consulte el artículo 325920 de Knowledge Base "Error "Error Message When You View Public Folders in Exchange ge System Manager Manager". Nota: No se puede modificar el valor de encabezado de host que utiliza el Administrador del sistema de Exchange al conectarse al directorio virtual Exadmin. El Administrador del sistema de Exchange siempre usa el nombre NetBIOS del servidor se de Exchange de destino. Por lo tanto, el sitio Web debe definir el nombre NetBIOS del servidor en el parámetro Valor de encabezado de host o no definir ningún valor. No obstante, puede usar el Administrador de IIS para asignar al sitio Web predeterminado predeterm que aloja el directorio virtual Exadmin una dirección IP dedicada y un puerto TCP personalizado. Al mostrar las propiedades del sitio Web, especifique una Dirección IP o un Puerto TCP personalizado en la ficha Sitio Web.. El Administrador del sistema de Exchange intenta conectarse primero al puerto TCP 80. Si falla este intento de conexión, el Administrador del sistema de Exchange se comunica con el servicio de administración de IIS del servidor de Exchange a través de llamadas a procedimiento remoto (RPC) (RPC) para determinar el número de puerto requerido. El servicio de administración de IIS devuelve el número de puerto personalizado al Administrador del sistema de Exchange porque está registrado en la metabase de IIS. A continuación, el Administrador del sistema de Exchange registra el puerto personalizado en el atributo msExchServerBindings del objeto de directorio

163

Exadmin. Entonces, el Administrador del sistema de Exchange se conecta al directorio virtual Exadmin, tal y como se explicó anteriormente en esta e sección. La comunicación con el servicio de administración de IIS no llega a establecerse cuando no se admiten las RPC entre el servidor de Exchange y el equipo que ejecuta el Administrador del sistema de Exchange. Por ejemplo, un servidor de seguridad que bloquee el acceso al asignador de puntos finales RPC a través del puerto TCP 135 podría evitar esta comunicación. En ese caso, el Administrador del sistema de Exchange no puede determinar el puerto predeterminado de forma dinámica. Se recomienda usar el número de puerto predeterminado 80 para el directorio virtual Exadmin. Nota: No se admite el uso del Administrador del sistema de Exchange en conexiones de red que no admiten RPC.

El directorio virtual Exadmin y el cifrado SSL La versión de Exchange Server Server 2003 del Administrador del sistema de Exchange es compatible totalmente con Nivel de socket seguro (SSL). Por lo tanto, puede instalar un certificado SSL en el servidor de Exchange y exigir el cifrado SSL a través de HTTP, que protege los directorios virtuales de Exchange Server 2003 tales como Public y Exadmin. La exigencia de un canal de comunicaciones seguro resulta conveniente si el servidor de Exchange y el equipo que ejecuta el Administrador del sistema de Exchange deben comunicarse entre sí en un segmento de red pública o no confiable. La figura siguiente muestra cómo funciona el proceso de conexión de un directorio virtual Exadmin a través de HTTP sobre SSL (HTTPS).

164

Conexión a Exadmin a través de HTTPS

Al conectarse al directorio virtual Exadmin a través de HTTPS por primera vez, el Administrador del sistema de Exchange lleva a cabo los siguientes pasos: 1. El Administrador del sistema de Exchange trata de conectarse a través de HTTP, tal y como se explicó licó anteriormente en esta sección. 2. Puesto que el directorio Exadmin requiere HTTPS, el servidor Web responde a la solicitud HTTP con un código de estado HTTP 403 - Prohibido. 3. El Administrador del sistema de Exchange solicita al servicio de administ administración de IIS a través de RPC información específica de SSL, como el puerto SSL que se debe usar para la conexión al sitio Web que aloja el directorio virtual Exadmin. El servicio de administración de IIS devuelve esta información al Administrador del sistema sist de Exchange. 4. El Administrador del sistema de Exchange se conecta al directorio virtual Exadmin a través de HTTPS y muestra la lista de carpetas públicas de la jerarquía. Nota: El certificado de seguridad que registre para el sitio Web alojado en el e directorio virtual Exadmin debe incluir el nombre de dominio completo (FQDN) del servidor local de Exchange como nombre común del sitio Web. Además, el equipo que ejecuta el Administrador del sistema de Exchange debe confiar en la autoridad emisora de certificados rtificados que emitió el certificado SSL. De lo contrario, el Administrador del sistema de Exchange muestra un mensaje de error que indica que el certificado SSL es incorrecto y no muestra la jerarquía de carpetas públicas.

165

5. El administrador del sistema de Exchange escribe el número de puerto SSL en el atributo msExchSecureBindings del objeto de directorio que se corresponde con el directorio virtual Exadmin. En conexiones posteriores, no es necesario ejecutar el algoritmo para obtener el número de puerto SSL del servidor.

Cómo mostrar toda la información obtenida de un almacén de buzón o almacén de carpetas públicas Este tema explica cómo visualizar toda la información obtenida para un almacén de buzones o un almacén de carpetas públicas en el panel de detalles del Administrador del sistema de Exchange.

Procedimiento Visualice toda la información obtenida para un almacén de buzones o un almacén de carpetas públicas. 1. Haga clic con el botón secundario del mouse (ratón) en el contenedor en cuestión (por ejemplo, Buzones o Inicios de sesión). 2. Seleccione Ver. 3. Seleccione Agregar o quitar columnas. 4. En el cuadro de diálogo Agregar o quitar columnas, agregue todas las entradas de la lista Columnas disponibles a la lista Columnas visualizadas. 5. Haga clic en Aceptar.

Cómo conectar a un servidor de Exchange específico en el Administrador del sistema de Exchange En este tema se explica cómo conectar con un servidor Exchange concreto en el Administrador del sistema de Exchange. Es posible que desee hacer esto al realizar un diagnóstico de problemas relacionados con la replicación de la jerarquía. El cambio de un servidor a otro le permite comprobar que todos los almacenes públicos tienen una vista coherente de la jerarquía.

166

Procedimiento Cómo conectar con un servidor Exchange concreto en el Administrador del sistema de Exchange 1. Haga clic con el botón secundario del mouse (ratón) en el objeto de jerarquía de carpetas públicas (por ejemplo, Carpetas públicas) en el Administrador del sistema de Exchange. 2. Seleccione Conectar con. 3. Seleccione el almacén de carpetas públicas de destino que desee en el cuadro de diálogo Seleccionar un almacén público.

Integración con el Instrumental de administración de Windows El Administrador del sistema de Exchange también es una aplicación de administración del Instrumental de administración de Windows (WMI). WMI se comunica con el servicio Instrumental de administración de Windows (Winmgmt) para obtener acceso a información dinámica del sistema de Exchange. WMI es un subsistema de Microsoft Windows Server 2003 que proporciona un modelo de programación independiente del lenguaje para realizar consultas y controlar la información de administración de un entorno empresarial. Todas las interfaces WMI están basadas en el Modelo de objetos componentes (COM). Por lo tanto, la comunicación entre el Administrador del sistema de Exchange y Winmgmt se basa en las RPC. WMI está basado en un modelo de tres niveles que incluye aplicaciones de administración, el Administrador de objetos comunes de información (CIM) y proveedores WMI. La figura siguiente muestra la arquitectura general de WMI.

167

Arquitectura de tres niveles de WMI

Las aplicaciones de administración, que consumen datos de WMI, están situadas en la parte superior de la arquitectura de WMI. El Administrador del sistema de Exchange es un ejemplo de aplicación de administración de WMI. También puede crear aplicaciones personalizadas y secuencias de comandos para procesar datos de WMI. Las aplicaciones de administración usan una API común, WMI, para comunicarse con el Administrador de objetos comunes de información (CIM) en el nivel intermedio. El Administrador de objetos CIM proporciona las clases de objetos programables que representan los orígenes de información subyacentes. El Administrador de objetos CIM se implementa en el servicio WMI de Windows Server 2003. El servicio WMI mantiene su propia base de datos, denominada base de datos CIM, para realizar un seguimiento de las clases WMI que están disponibles y del proveedor que se encarga de proporcionar instancias de esas clases. Las definiciones de clases están almacenadas en la base de datos CIM. Los datos estáticos también pueden almacenarse en la base de datos CIM y recuperarse sin ningún proveedor. No obstante, el subsistema WMI está diseñado para obtener información dinámica acerca de un sistema administrado como Exchange Server 2003. Esto se puede llevar a cabo totalmente a través de proveedores WMI. Los proveedores WMI están situados en la parte inferior de la arquitectura WMI. Los proveedores WMI obtienen acceso al Administrador de objetos CIM mediante un conjunto de interfaces COM estandarizadas y actúan de intermediarios entre el sistema administrado y el Administrador de objetos CIM. Los proveedores WMI extraen información de administración del sistema administrado subyacente. A continuación, asignan esa información a clases de objetos que el Administrador de objetos CIM presenta a las aplicaciones de administración WMI. Exchange Server 2003 incluye muchos proveedores y clases WMI. Para obtener información acerca de estas clases, consulte la WMI documentation in the Exchange SDK. El Administrador del sistema de Exchange usa los siguientes proveedores WMI:

168

•

ExchangeDsAccessProvider Este proveedor WMI permite al Administrador del sistema de Exchange comunicarse con el componente DSAccess para ver y definir controladores de dominio y servidores de catálogo global, que usa DSAccess para obtener acceso a información de Active Directory. El Administrador del sistema de Exchange se comunica con el proveedor ExchangeDsAccessProvider cuando se hace clic en la ficha Acceso al directorio de las propiedades del servidor de Exchange Server 2003. ExchangeDsAccessProvider se implementa en el servicio Administración de Microsoft Exchange (MSExchangeMGMT). Si se detiene el servicio, ExchangeDsAccessProvider no está disponible y no se puede ver ni modificar la lista de controladores de dominio y catálogos globales que utiliza DSAccess en ese servidor de Exchange. No obstante, DSAccess no requiere el servicio Administración de Exchange. DSAccess sigue utilizando la lista predefinida de controladores de dominio y servidores de catálogo global, o los determina de forma dinámica. Para obtener más información acerca de DSAccess, consulte Exchange Server 2003 y Active Directory.

•

ExchangeMessageTrackingProvider Este proveedor WMI ofrece información acerca de mensajes enrutados a través del motor de transporte de un servidor de Exchange donde está habilitado el seguimiento de mensajes. El seguimiento de mensajes es una característica que le permite seguir las rutas de mensajes a medida que se transfieren por la organización de Exchange. El seguimiento de mensajes está deshabilitado de forma predeterminada. Puede seleccionar el seguimiento de mensajes para cada servidor desde la ficha General del servidor. Con el seguimiento de mensajes habilitado, la información de estado se escribe en archivos de registro diarios, que se almacenan en el directorio \Archivos de programa\Exchsrvr\<nombreServidor>.log (por ejemplo, \Archivos de programa \Exchsrvr\Servidor01.log). El archivo de registro sigue el esquema .LOG (por ejemplo, 20040321.LOG). Los archivos de registro de seguimiento son archivos de texto separados por tabuladores que se comparten para el acceso de red en todos los servidores de Exchange. El nombre del recurso compartido es .LOG. Puede analizar información de seguimiento de mensajes en un editor de texto cuando abre archivos de registro de seguimiento directamente, o en el complemento Centro de seguimiento de mensajes de Exchange. El Centro de seguimiento de mensajes de Exchange está disponible como complemento independiente en el Administrador del sistema de Exchange, en el nodo Herramientas, y también puede usarse independientemente en herramientas de MMC personalizadas. En Exchange Server 2003, el Centro de seguimiento de mensajes lee información de seguimiento del proveedor ExchangeMessageTrackingProvider en el equipo local. Si se utilizan servidores remotos para la transferencia de mensajes, el proveedor ExchangeMessageTrackingProvider del servidor local se comunica con el proveedor ExchangeMessageTrackingProvider de los servidores remotos. De este modo, se realiza un seguimiento de la ruta del mensaje de servidor a servidor en toda la organización de Exchange y se devuelve información completa al Centro de seguimiento de mensajes.

169

ExchangeMessageTrackingProvider también se ha implementado en el servicio Administración de Microsoft Exchange. Si el servicio no se ejecuta en el servidor local que ejecuta Exchange Server 2003, ExchangeMessageTrackingProvider no está disponible y el Centro de seguimiento de mensajes no funciona. Si el servicio Administración de Exchange no se ejecuta en un servidor remoto con Exchange Server 2003, podría devolverse información de seguimiento de mensajes incompleta. No obstante, para garantizar la compatibilidad con Exchange 2000 Server, el Centro de seguimiento de mensajes también puede obtener acceso a los recursos compartidos de red de seguimiento de mensajes mediante el protocolo Bloque de mensajes de servidor (SMB) de Windows Server 2003. La figura siguiente muestra cómo los proveedores de Exchange y el servicio Administración de Exchange se integran con el subsistema WMI. Proveedores de Exchange en el subsistema WMI

Configuración de servicios en el Administrador del sistema de Exchange Para poder admitir la actualización remota de las opciones de configuración que están almacenadas en el Registro, el Administrador del sistema de Exchange requiere que el Servicio de Registro remoto se esté ejecutando en todos los servidores de Exchange. Por ejemplo, cuando consulta las propiedades de un objeto de servidor en el Administrador del sistema de Exchange y cambia a la ficha Registro de diagnósticos para ver o definir el

170

nivel de registro de sucesos para las distintas categorías de los servicios de Exchange, el Administrador del sistema de Exchange obtiene acceso a la configuración del Registro para los servicios correspondientes a través de la API del Registro. Las categorías que se muestran para un servicio en la ficha Registro de diagnósticos se corresponden con los parámetros REG_DWORD que están almacenados en la subclave Diagnostics del servicio de Exchange en HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services. La figura siguiente muestra esta relación para el componente DSAccess. Configuración de Registro de diagnósticos en el Editor del Registro y en el cuadro de diálogo Propiedades para un objeto de servidor del Administrador del sistema de Exchange

El Servicio de Registro remoto se omite cuando se trabaja con la configuración del Registro del equipo local. No obstante, si desea definir el nivel de registro de diagnósticos para un servidor de Exchange de forma remota, el Administrador del sistema de Exchange debe usar primero la función RegConnectRegistry de la API del Registro para establecer una conexión con la clave del Registro que desea del equipo remoto. Para esta llamada de función, el

171

administrador de Exchange debe tener permisos de acceso al servicio Registro remoto. De lo contrario, no se puede establecer la conexión al Registro remot remoto. Precaución: La modificación incorrecta del Registro puede ocasionar problemas graves que quizás requieran volver a instalar el sistema operativo. Es posible que los problemas derivados de una modificación incorrecta del Registro no se puedan resolver. Antes de modificar el Registro, se recomienda realizar una copia de seguridad de todos los datos importantes. La configuración predeterminada de Windows sólo permite el acceso remoto al Registro a los administradores locales. Para garantizar que los administradores administradores de Exchange puedan administrar un servidor de Exchange de forma remota, el Operador de sistema agrega automáticamente las cuentas que disponen de una función de administrador de Exchange a la lista de control de accesos (ACL) de la clave del Registro Reg WinReg y les otorga permisos de Control total. Esta clave puede encontrarse bajo la siguiente subclave: HKEY_LOCAL_MACHINE\SYSTEM SYSTEM\CurrentControlSet\Control\SecurePipeServers SecurePipeServers. Con los permisos necesarios para el Servicio de Registro remoto, el Administrador de Exchange puede establecer una conexión remota al Registro de destino. No obstante, esto no implica que al administrador de Exchange se le permita también leer o escribir opciones o de configuración de otras claves del Registro. Por ejemplo, un administrador podría tener permisos de Control total para la clave WinReg y no para la clave MSExchangeMTA en la base de datos de control de servicios. En ese caso, el Administrador del sistema de Exchange podría conectarse al Registro del servidor remoto, pero quizás no podría mostrar las categorías de servicios o diagnósticos en la ficha Registro de diagnósticos.. Para garantizar que el administrador de Exchange puede leer y escribir op opciones ciones de configuración para servicios de Exchange, el Operador de sistema otorga a los administradores de Exchange permisos de Control total para la clave HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet CurrentControlSet\Control\Services. Todas las subclaves de esta clave del Registro heredan la configuración de permisos. Para obtener más información sobre los valores del Registro de los servicios de Exchange, consulte Dependencias de los servicios de Exchange Server 2003 2003. Nota Si el Administrador del sistema de Exchange no puede obtener acceso a la clave HKEY_LOCAL_MACHINE\SYSTEM SYSTEM\CurrentControlSet\Control\Services de un servidor de Exchange porque no se puede e establecer stablecer una conexión al Servicio de Registro remoto o porque no dispone de permisos de acceso suficientes, recibirá un mensaje de error indicándole que no se encontró la ruta de red y que no puede administrar el servidor.

Arquitectura de enrutamiento de mensajes Cuando se enruta un mensaje, se mueve del remitente al destinatario en función de un conjunto de reglas de enrutamiento de mensajes. La ruta del mensaje puede incluir varios saltos. Un salto es un nodo de la ruta de enrutamiento. En la arquitectura arquitectura de enrutamiento de una organización de Microsoft Exchange Server 2003, los nodos de la ruta del mensaje

172

están representados por grupos de enrutamiento. Los conectores de mensajería conectan entre sí los nodos o grupos de enrutamiento en el entorno de mensajería interno. La organización de Exchange también podría estar conectada a un entorno de mensajería externo, como Internet, por medio de conectores de mensajería que permiten a los mensajes entrar o salir de la organización de Exchange. En esta sección se explican los siguientes conceptos: •

Elementos clave de la topología de enrutamiento de Exchange Server 2003 Debe poder identificar los componentes que conforman la topología de enrutamiento de mensajes de una organización de Exchange para poder comprender los aspectos básicos del enrutamiento de mensajes en Exchange Server 2003.

•

Tratamiento de mensajes de Exchange Server 2003 Antes de examinar los mecanismos de enrutamiento de Exchange Server 2003, debe conocer cómo Exchange 2003 enruta los mensajes dirigidos a destinatarios que residen en el mismo servidor de Exchange y los dirigidos a destinatarios que residen en otros servidores de Exchange del mismo grupo de enrutamiento, en otros grupos de enrutamiento o en sistemas de mensajería externos.

•

Enrutamiento de mensajes de Exchange Server 2003 Exchange Server 2003 usa la información de estado de vínculos para tomar decisiones de enrutamiento dinámicas en lugar de basar las decisiones en una tabla de enrutamiento estático. Para comprender el enrutamiento de mensajes dinámico de Exchange Server 2003, debe conocer cómo Exchange Server 2003 selecciona las rutas de mensajes y cómo afectan al proceso de enrutamiento de mensajes los cambios de la topología de enrutamiento.

•

Propagación de información de estado de vínculos Deben existir procedimientos para replicar la información de estado de vínculos entre servidores de Exchange. Estos procedimientos garantizan que cada servidor tenga información precisa acerca de toda la organización. Con esta información, el servidor puede recalcular la ruta óptima a cualquier destino del entorno de mensajería en función del estado actual de la topología de enrutamiento. Debe entender de qué modo los servidores propagan los cambios a la topología de enrutamiento de mensajes en una organización Exchange Server 2003. Además, debe comprender todos los detalles de la tabla de estado de vínculos (la tabla que contiene la información de enrutamiento) y el algoritmo que se usa para replicar la información de estado de vínculos entre servidores de Exchange.

•

Compatibilidad con Exchange Server 5.5 Se producen varios problemas de enrutamiento cuando se integra Exchange Server 2003 en una organización de Exchange Server 5.5. Debe conocer esos problemas para entender cómo puede usar Exchange Server 5.5 los conectores de Exchange Server 2003 y viceversa.

Esta sección presupone que está familiarizado con el diseño de topologías de grupos de enrutamiento y la configuración de conectores de mensajería. Para obtener más información acerca del transporte y enrutamiento, consulte la Exchange Server 2003 Transport and Routing Guide.

173

Topología de enrutamiento de mensajes de Exchange Server 2003 La figura siguiente muestra una topología de enrutamiento de una organización de Exchange Server 2003 con varios grupos de enrutamiento internos conectados mediante conectores para grupo de enrutamiento y un conector que realiza la conexión de la organización de Exchange con un sistema de mensajería externo. En esta topología, el grupo de enrutamiento A representa un concentrador de enrutamiento central. Todos los mensajes dirigidos a grupos de enrutamiento remotos (grupos de enrutamiento B y C) y al sistema de mensajería que no es de Exchange se enrutan a través del grupo de enrutamiento A. Varios servidores cabeza de puente están implementados en el grupo de enrutamiento A para proporcionar rutas de transferencia de mensajes redundantes. Una topología de enrutamiento de mensajes de Exchange Server 2003

La topología de enrutamiento de mensajes que se muestra en la figura anterior incluye los siguientes componentes clave: •

Grupos de enrutamiento Son conjuntos lógicos de servidores que se utilizan para controlar el flujo de correo y las referencias a carpetas públicas. Los grupos de enrutamiento comparten una o varias conexiones físicas. En un grupo de enrutamiento, todos los servidores de Exchange se comunican y transfieren mensajes directamente entre sí mediante servidores virtuales SMTP (Protocolo simple de transferencia de correo). En una organización en modo nativo, los grupos de enrutamiento pueden incluir servidores de grupos administrativos distintos. No obstante, en una organización en modo mixto, los grupos de enrutamiento no pueden abarcar varios grupos administrativos para mantener la compatibilidad con Exchange Server 5.5. Esto se debe

174

a que la topología de enrutamiento de Exchange 5.5 está definida por sitios, y los sitios proporcionan la funcionalidad tanto del grupo admini administrativo strativo como del grupo de enrutamiento. Sugerencia: SMTP funciona correctamente en cualquier tipo de conexión TCP/IP. Por lo tanto, un grupo de enrutamiento no tiene por qué definir regiones de una red informática con ancho de banda alto. Los grupos de de enrutamiento pueden abarcar conexiones de red lentas si la conexión es permanente y confiable. Por ejemplo, si todos los servidores de la figura 5.1 pueden comunicarse directamente a través de TCP/IP, usted podría consolidar todos los servidores de Exchange nge en un grupo de enrutamiento y así eliminar cuatro de los cinco servidores cabeza de puente y todos los conectores para grupo de enrutamiento. De este modo, se simplifica considerablemente la topología de grupos de enrutamiento. En la figura 5.1, el servidor vidor cabeza de puente que ejecuta un conector para el sistema de mensajería que no es de Exchange debe permanecer conectado al sistema de mensajería externo. Observe, sin embargo, que todos los servidores de un grupo de enrutamiento sondean periódicamente el maestro del grupo de enrutamiento. La obtención del control de la comunicación entre servidores podría requerir la implementación de varios grupos de enrutamiento, lo que podría ser especialmente importante si la comunicación en la red de área extensa (WAN) genera costos. Para obtener más información acerca del diseño y de la configuración de topologías de grupos de enrutamiento, consulte la Guía de transporte y enrutamiento de Exchange Server 2003 (). •

Conectores para grupo de enrutamiento Los conectores tores para grupo de enrutamiento permiten la transferencia de mensajes entre dos grupos de enrutamiento. Los siguientes conectores de Exchange pueden usarse para establecer rutas de transferencia de mensajes entre grupos de enrutamiento. •

Conectores para grupo de enrutamiento Los conectores para grupo de enrutamiento ofrecen una ruta de conexión unidireccional a través de la cual se enrutan los mensajes desde los servidores de un grupo de enrutamiento hasta los servidores de otro grupo de enrutamiento. Los conectores para grupo de enrutamiento usan SMTP para comunicarse con servidores de grupos de enrutamiento conectados. Los conectores para grupo de enrutamiento proporcionan la mejor conexión entre grupos de enrutamiento. Nota: El Conector para grupo de enrutamiento (observe la mayúscula inicial) es un tipo de conector específico que sólo se puede usar para conectar grupos de enrutamiento entre sí. Otros conectores que pueden usarse para conectar grupos de enrutamiento son el conector SMTP y el conector conector X.400. No obstante, estos conectores también pueden usarse para conectar una

175

organización de Exchange a un sistema de mensajería externo a través de SMTP o X.400. Para evitar confusiones, esta guía usa "Conector para grupo de enrutamiento" para hacer re referencia ferencia al conector específico que sólo se puede usar entre grupos de enrutamiento y "conector para grupo de enrutamiento" para hacer referencia a todos los tipos de conectores que se pueden usar para conectar grupos de enrutamiento. •

Conectores para SMT SMTP Los conectores para SMTP pueden usarse para conectar grupos de enrutamiento, aunque no se recomiendan. Los conectores para SMTP están diseñados para la entrega de mensajes externos. Los conectores para SMTP definen rutas específicas para mensajes de correo correo electrónico que están dirigidos a Internet o a un destino externo, como por ejemplo, un sistema de mensajería que no es de Exchange.

•

Conectores X.400 Aunque se pueden utilizar conectores X.400 para conectar grupos de enrutamiento, los conectores X.400 están diseñados para conectar servidores que ejecutan Exchange con otros sistemas X.400 o con servidores que ejecutan Exchange Server 5.5 fuera de una organización de Exchange. Así, un servidor que ejecute Exchange Server 2003 puede enviar mensajes con el protocolo X.400 a través de este conector. Nota: Los conectores X.400 sólo están disponibles en Exchange Server 2003 Enterprise Edition.

•

Conectores s a sistemas de mensajería distintos de Exchange Estos conectores admiten la transferencia de mensajes y la sincronización de directorios entre sistemas de mensajería que son de Exchange y sistemas que no lo son. Cuando se implementan conectores adecuados, adecuados, la experiencia del usuario es similar en ambos sistemas de mensajería y la transferencia de mensajes y de otra información entre el sistema de mensajería de Exchange y el sistema de mensajería que no es de Exchange es transparente para el usuario. No ob obstante, stante, podrían perderse algunas propiedades de mensajes durante la conversión de mensajes del formato de Exchange al otro formato o viceversa.

•

Servidores de buzón Los servidores de buzón son servidores de Exchange configurados para alojar buzones. Los usuarios pueden obtener acceso a sus buzones a través de diversos clientes, tales como Microsoft Office Outlook, Microsoft Office Outlook Web Access, Microsoft Office Outlook Mobile Access, clientes basados en el Protocolo de oficina de correo versión 3 (POP3) POP3) y clientes basados en el Protocolo de acceso a correo de Internet versión 4 rev 1 (IMAP4). En la topología de enrutamiento de Exchange Server 2003, los servidores de buzón suelen ser el origen y el destino de los mensajes de correo electrónico.

•

Servidores vidores cabeza de puente Los servidores cabeza de puente son puntos de conexión que llevan a cabo la transferencia de un grupo de enrutamiento a otro o a un sistema de mensajería externo. En las organizaciones de gran tamaño, los servidores

176

cabeza de puente suelen estar separados de los servidores de buzón para evitar cuellos de botella de rendimiento. Los servidores de buzón crean cuellos de botella debido al aumento de los requisitos de procesamiento durante las horas punta de mensajería. Los servidores cabeza de puente se identifican como servidores cabeza de puente locales o remotos tal y como sigue: •

•

Servidores cabeza de puente locales Estos servidores alojan un conector y lo utilizan para transferir mensajes. Al crear un conector, se designa al menos un servidor de Exchange como servidor cabeza de puente. También puede designar varios servidores cabeza de puente para lograr equilibrio de carga, rendimiento y redundancia. Por ejemplo, la opción predeterminada para los conectores para grupo de enrutamiento es Cualquier servidor local puede enviar correo por este conector. En ese caso, todos los servidores de Exchange del grupo de enrutamiento local pueden usar el conector para transferir mensajes.

Servidores cabeza de puente remotos El servidor cabeza de puente remoto, que se especifica en la configuración del conector, es el servidor (en el grupo de enrutamiento conectado o en el sistema de mensajería que no es de Exchange) que recibe todos los mensajes transferidos a través de un conector. El Conector para grupo de enrutamiento puede tener diversos servidores cabeza de puente remotos (es decir, servidores SMTP virtuales remotos). No obstante, el conector SMTP y X.400 sólo puede tener un servidor cabeza de puente por instancia de conector. Los servidores cabeza de puente remotos también se denominan servidores cabeza de puente de destino.

Tratamiento de mensajes de Exchange Server 2003 La transferencia de mensajes en Exchange 2003 depende principalmente del servicio SMTP. Observe que el motor de transporte SMTP de Exchange 2003 interviene en todo el tratamiento de mensajes, independientemente del destino final del mensaje. Un mensaje podría estar destinado a un usuario del mismo servidor, a otro servidor del mismo grupo de enrutamiento, a un servidor de otro grupo de enrutamiento o a un servidor de un sistema de mensajería externo. La figura siguiente muestra la arquitectura de transporte SMTP de Exchange Server 2003. Para obtener información detallada acerca de los componentes del motor de transporte SMTP y de sus responsabilidades, consulte Arquitectura de transporte SMTP.

177

La arquitectura de transporte SMTP de Exchange Server 2003

En Exchange Server 2003, el motor de transporte SMTP trata los mensajes tal y como sigue: 1. Los mensajes se reciben a través de SMTP, llamadas a procedimiento remoto (RPC), X.400 o protocolos de transferencia MAPI, tal y como se muestra en la tabla siguiente.

178

Protocolos de transferencia de mensajes entrantes Protocolo de transferencia

Comentarios

SMTP

Los servidores de Exchange 2000 y Exchange Server 2003 se comunican entre sí a través de SMTP. Los hosts que no son de Exchange y los clientes POP3 e IMAP4 también usan SMTP para transferir mensajes a servidores que ejecutan Exchange Server 2003. Estos mensajes se reciben a través del servicio de protocolo SMTP, que los guarda en la carpeta \Exchsrvr\Mailroot\vsi 1\Queue del sistema de archivos antes de transferirlos a la cola de envío previo. Todos los servidores SMTP virtuales de servidores de Exchange 2003 mantienen su propio subdirectorio en la carpeta Exchsrvr\Mailroot\. Por ejemplo, la ruta de la carpeta mailroot predeterminada del servidor SMTP virtual es \Exchsrvr\Mailroot\vsi 1. Otra forma de enviar mensajes al servicio SMTP sería usar el subdirectorio \Pickup de la carpeta mailroot del servidor SMTP virtual. Puesto que el archivo de mensajes debe estar en formato RFC-822 para que el servicio SMTP lo obtenga y lo procese correctamente, la transferencia de mensajes también se considera basada en SMTP.

179

Protocolo de transferencia

Comentarios

RPC

Los servidores de Exchange 5.5 se comunican entre sí en el sitio local a través de las RPC. Los Agentes de transferencia de mensajes (MTA) de Exchange 5.5 usan las RPC para transferir mensajes de correo electrónico entre sí en el sitio local sin requerir ninguna definición de conector de mensajería. Si se implementa Exchange Server 2003 en un sitio de Exchange 5.5 existente, los mensajes se intercambian con Exchange 5.5 a través de RPC mediante el servicio Pila MTA de Microsoft Exchange. Cuando se utiliza un conector de sitio, los servidores de Exchange 5.5 de sitios distintos también se comunican entre sí mediante RPC. Exchange 2003 puede comunicarse con un conector de sitio si se implementa un conector para grupo de enrutamiento que se conecta a un servidor de Exchange 5.5 en un sitio remoto. En ese caso, el conector para grupo de enrutamiento cambia a RPC automáticamente, en lugar de SMTP, para mantener la compatibilidad con Exchange 5.5.

X.400

Si desea intercambiar mensajes con un agente de transferencia de mensajes (MTA) X.400 remoto, deberá configurar un conector X.400. Tal y como se mencionó anteriormente, también puede usar conectores X.400 para conectar grupos de enrutamiento entre sí en la organización de Exchange. El servicio Pila MTA de Microsoft Exchange recibe mensajes X.400 entrantes y los pasa al almacén de Exchange. A continuación, el controlador del almacén de Exchange los coloca en la cola de envío previo. Para obtener más información acerca de la arquitectura de X.400, consulte Arquitectura de transporte X.400.

180

Protocolo de transferencia

Comentarios

MAPI

Los clientes basados en MAPI, como Microsoft Outlook, además de los conectores de mensajería basados en MAPI, como el Conector para Lotus Notes y el Conector para Novell GroupWise, se comunican directamente con el almacén de Exchange. Por ejemplo, los clientes MAPI colocan los mensajes salientes en la carpeta Bandeja de salida del buzón del usuario y, a continuación, notifican al almacén de Exchange para transferir el mensaje. Sin embargo, los conectores de mensajería basados en MAPI usan una carpeta MTS-IN en el almacén de Exchange como cola de mensajes entrantes. Los conectores de mensajería basados en MAPI convierten mensajes entrantes al formato de Exchange y, a continuación, los colocan en la carpeta MTS-IN. De cualquier modo, el mensaje MAPI se coloca en el almacén de Exchange y el controlador del almacén de Exchange lo coloca a continuación en la cola de envío previo. Para obtener más información acerca de los conectores de mensajería basados en MAPI, consulte Arquitectura de los conectores de mensajería de puerta de enlace.

2. La cola de envío previo es el punto de entrada del motor de cola avanzada. Cuando un mensaje se coloca en la cola de envío previo, éste se procesa con código de procesamiento SMTP personalizado, como por ejemplo, receptores de sucesos para detección de virus. El motor de cola avanzada mueve el mensaje a la cola de categorización previa para que el categorizador (un componente interno del motor de transporte SMTP) lo siga procesando. 3. El categorizador resuelve tanto la dirección del destinatario como la del remitente, expande los grupos de correo, comprueba las restricciones, aplica límites por remitente y por destinatario, etc. Si el buzón del destinatario reside en la organización de Exchange Server 2003 local, el categorizador marca el destinatario como local mediante la definición de una propiedad por destinatario que indica el nombre de dominio completo (FQDN) del servidor principal del destinatario. Éste es un paso de enrutamiento

181

importante. Posteriormente, el motor de cola avanzada usa el FQDN del servidor principal del destinatario para determinar la ruta de transferencia de mensajes. 4. Tras la categorización, el motor de cola avanzada coloca el mensaje en la cola de categorización posterior. Debe distinguirse entre los mensajes para destinatarios locales y los mensajes para destinatarios de sistemas remotos tal y como sigue: •

Entrega local Para los destinatarios locales, se omite el enrutamiento. El almacén de buzones que contiene el buzón de destino se marca en el mensaje y el motor de cola avanzada transfiere el mensaje a la cola de entrega local. Desde la cola de entrega local, el controlador del almacén de Exchange obtiene el mensaje y lo coloca en el buzón del destinatario.

•

Entrega remota El motor de enrutamiento debe procesar todos los mensajes para destinatarios no locales puesto que el motor de transporte SMTP debe encontrar una ruta de transferencia disponible para el destino. En consecuencia, el motor de cola avanzada transfiere el mensaje a la cola de enrutamiento previo, llama al motor de enrutamiento y, a continuación, pasa la dirección de destino (es decir, el FQDN del servidor principal del destinatario para destinatarios internos o el nombre de dominio SMTP para destinatarios externos) al motor de enrutamiento. El motor de enrutamiento devuelve al que llama el siguiente salto que usará el mensaje y lo clasifica tal y como se indica en la tabla siguiente.

182

Tipos de salto para la entrega remota Tipo de salto

Comentarios

El siguiente salto es al servidor local

Indica que el motor de transporte debe pasar el mensaje al MTA de Exchange para su transferencia, tanto mediante las RPC a un servidor de Exchange 5.5 como mediante un conector X.400 a un MTA X.400 remoto, o bien mediante un conector de mensajería basado en MAPI, como por ejemplo, el Conector para Lotus Notes o el Conector para Novell GroupWise, a un sistema de mensajería que no es de Exchange.

El siguiente salto es a un servidor del grupo de enrutamiento local

Indica que el motor de transporte debe pasar el mensaje al servidor SMTP virtual predeterminado para transferirlo a su destino a través de SMTP.

El siguiente salto es a un servidor del grupo de enrutamiento local

Indica que el motor de transporte debe pasar el mensaje a un conector para grupo de enrutamiento del servidor de Exchange local. No obstante, observe que este tipo sólo se aplica a mensajes transferidos a través de SMTP. Si usa conectores X.400 para conectar grupos de enrutamiento, el motor de transporte pasa los mensajes al MTA de Exchange (es decir, el siguiente salto es al servidor local).

El siguiente salto es a un servidor situado fuera de la organización de Exchange

Indica que el motor de transporte debe pasar el mensaje a un conector SMTP o a un servidor SMTP virtual que pueda transferir el mensaje al sistema de mensajería externo. Como ya se indicó, este tipo de salto sólo hace referencia a destinos que se pueden alcanzar mediante SMTP. Si el mensaje está destinado a un sistema de mensajería que no es de Exchange conectado a través de un conector basado en MAPI que controla el MTA de Exchange, el motor de transporte pasa los mensajes al MTA de Exchange (es decir, el siguiente salto es al servidor local).

183

Tipo de salto

Comentarios

El siguiente salto es a un servidor al que no se puede obtener acceso en este momento

Indica que existe una ruta de destino, pero que no está disponible en la actualidad. El motor de transporte retiene el mensaje hasta que la ruta de transferencia tra vuelve a estar disponible o hasta que caduca el mensaje y debe devolverse al remitente con un NDR.

El siguiente salto es a un servidor al que no se puede obtener acceso

Indica que no existe ninguna ruta de destino final y el motor de transporte devuelve el mensaje al remitente con un NDR.

5. El motor de cola avanzada almacena en caché la información de tipo y el destino del siguiente salto, y mueve el mensaje a una cola de vínculos correspondiente. Las colas de vínculos son dinámicas y de su a administración dministración se encarga el Administrador de colas. El nombre de cada cola de vínculos coincide con el destino de entrega remota. Nota: Las colas de vínculos existen y están disponibles en el Visor de cola del Administrador del sistema de Exchange sólo cuando hay mensajes esperando para su transferencia al destino correspondiente. El Administrador de colas hace que caduque una cola de vínculos un minuto después de la transmisión del último mensaje de la cola de vínculos. 6. Los mensajes de las colas de vínculos vínculos distintas de la cola del MTA de Exchange se transfieren mediante el motor de protocolo SMTP. No obstante, los mensajes de la cola del MTA de Exchange se transfieren a la cola de mensajes salientes del MTA de Exchange en el almacén de Exchange, que es una carpeta del sistema denominada MTS-OUT. OUT. El controlador del almacén de Exchange realiza esta tarea. El MTA de Exchange obtiene el mensaje y, a continuación, se comunica con el motor de enrutamiento a través de MTARoute.dll para determinar el conector apropiado y disponible. Si el mensaje es para un conector a un sistema de mensajería que no es de Exchange, el MTA de Exchange coloca el mensaje en la cola de mensajes salientes de ese conector en el almacén de Exchange (la carpeta MTS-OUT MTS OUT del conector). De lo contrario, el MTA transfiere el mensaje directamente mediante RPC o un conector X.400. Para obtener más información acerca del MTA de Exchange, consulte Arquitectura de transporte X.400.

184

Enrutamiento de mensajes de Exchange Server 2003 En el caso de mensajes a destinatarios que no son locales, el motor de enrutamiento debe proporcionar al motor de cola avanzada información acerca del host del siguiente salt salto en la ruta de transferencia del destino y del tipo del siguiente salto, tal y como se indicó en la sección anterior. El host del siguiente salto es la dirección de enrutamiento y el tipo del siguiente salto determina el tratamiento del mensaje por parte del motor de cola avanzada. Para proporcionar esta información esencial, el motor de enrutamiento debe disponer de una vista completa de toda la topología de enrutamiento, incluidos todos los grupos de enrutamiento y sus servidores, los conectores para grupo grupo de enrutamiento y los conectores a los sistemas de mensajería externos. En Exchange Server 2003, esta información está disponible en el servicio de directorios Active Directory.

Rutas de mensajes y tablas de estado de vínculos Todos los servidores de Ex Exchange 2003 mantienen su propia tabla de enrutamiento, denominada tabla de estado de vínculos, de forma dinámica en la memoria en función de la información de estado de vínculos y de Active Directory, tal y como sigue: •

Información de Active Directory relacionada elacionada con el enrutamiento Esta información está almacenada en atributos del objeto de organización, objetos de grupo de enrutamiento, objetos de conector y objetos de servidor. Esos objetos residen en la partición del directorio de configuración y d definen efinen la topología de enrutamiento de toda la organización de Exchange. Nota: Los grupos administrativos no forman parte de la topología de enrutamiento de una organización de Exchange.

•

Información de estado de vínculos Esta información especifica si cada conector de la topología de enrutamiento está disponible (activo) o no disponible (desconectado). La información de estado de vínculos es dinámica y podría cambiar cuando un conector experimenta problemas de transferencia o cuando se resuelven problemas problemas de transferencia. Para obtener más información acerca de los cambios de estado de vínculos y la propagación de información de estado de vínculos en toda la organización de Exchange, consulte Propagación de estado de vínculos.

Inicialización de la tabla de estado de vínculos Al inicio, cada servidor de Exchange inicializa su tabla de estado de vínculos con la siguiente información de Active Directory:

185

•

Objeto de organización El límite de la topología de enrutamiento es la organización de Exchange. Es decir, la tabla de estado de vínculos no incluye ninguna información acerca de servidores cabeza de puente externos ni de conectores de mensajería de sistemas de mensajería externos. Respecto al motor de enrutamiento, la topología de enrutamiento finaliza en el conector al sistema de mensajería externo. De este modo, el motor de enrutamiento lee el GUID que está registrado en el atributo objectGUID del objeto de organización de Exchange en Active Directory y marca la tabla de estado de vínculos con ese GUID para identificar la organización a la que pertenece la información de enrutamiento.

•

Objetos de grupo de enrutamiento El motor de enrutamiento enumera todos los grupos de enrutamiento que existen en los grupos administrativos y solicita todos los atributos de objeto a cada grupo de enrutamiento, incluido el atributo msExchRoutingGroupMembersBL que contiene una lista de todos los servidores miembro de grupos de enrutamiento. El motor de enrutamiento incluye esta información en la tabla de estado de vínculos. El motor de enrutamiento también incluye los servidores junto con el GUID del grupo de enrutamiento del servidor en una caché del servidor en memoria. Cada entrada de la caché del servidor es un FQDN de servidor anexado por el GUID de grupo de enrutamiento del servidor. Otro atributo importante de grupo de enrutamiento es el atributo msExchRoutingMasterDN, que señala el nombre completo del maestro de grupo de enrutamiento del grupo de enrutamiento seleccionado. Para obtener más información acerca de las tareas y responsabilidades del maestro de grupo de enrutamiento, consulte la explicación más adelante en esta sección.

•

Objetos de conector de mensajería El motor de enrutamiento enumera todos los objetos secundarios con tipo de objeto msExchconnector que existen en el contenedor de conexiones de cada grupo de enrutamiento. Los objetos msExchconnector del contenedor de conexiones son los conectores para grupo de enrutamiento y los conectores a sistemas de mensajería externos que están configurados en el grupo de enrutamiento. El motor de enrutamiento lee todos los atributos de los objetos de conector para determinar espacios de dirección, valores de costo, restricciones, etc. El motor de enrutamiento incluye la información de cada conector en la tabla de estado de vínculos. Esto permite el enrutamiento de los mensajes a destinos situados fuera del grupo de enrutamiento local.

El proceso continúa hasta que el motor de enrutamiento identifica todos los grupos de enrutamiento conectados directa e indirectamente y solicita los detalles de configuración de los conectores de mensajería. Una vez finalizado este proceso, el motor de enrutamiento dispone de una vista completa de todas las rutas de transferencia disponibles en toda la organización de Exchange. Se presupone que todos los vínculos están activos y disponibles para la transferencia de mensajes. Tras la inicialización de la tabla de estado de vínculos, el motor de enrutamiento se comunica con el servicio Motor de enrutamiento de Microsoft Exchange del servidor local para obtener información dinámica de estado de vínculos que refleje el estado actual de cada conector. El servicio Motor de enrutamiento de Exchange se

186

conecta al maestro de grupo de enrutamiento del grupo de enrutamiento local a través del puerto TCP 691 para recuperar esa información. Para obtener más información acerca de la información de estado de vínculos, consulte la sección "Examen de de la tabla de estado de vínculos", más adelante en este tema.

El motor de enrutamiento y el servicio Motor de enrutamiento de Exchange El motor de enrutamiento del subsistema de transporte y el servicio Motor de enrutamiento de Exchange tienen funciones distintas. distintas. El servicio Motor de enrutamiento de Exchange no lleva a cabo ningún enrutamiento de mensajes. El servicio Motor de enrutamiento de Exchange comunica información de estado de vínculos entre servidores que ejecutan Exchange 2000 Server y Exchange Server 2003 del grupo de enrutamiento local. El servicio Motor de enrutamiento de Exchange se implementa en resvc.dll, que reside en el directorio \Archivos de programa\Exchsrvr Exchsrvr\bin\.. El nombre del servicio es RESvc. Para obtener más información acerca de los os servicios de Microsoft Windows de Exchange Server 2003, consulte Dependencias de los servicios de Exchange Server 2003 2003. El servicio Motorr de enrutamiento de Exchange, más que un motor de enrutamiento, es un servicio de comunicación de estado de vínculos dentro de grupos de enrutamiento. El motor de enrutamiento que usan para enrutar mensajes el motor de cola avanzada SMTP y el MTA de Exchange nge se implementa en un archivo denominado reapi.dll. En el caso del MTA de Exchange, el archivo mtaroute.dll contiene código adicional. Por lo tanto, cuando se detiene el servicio Motor de enrutamiento de Exchange, tanto el motor de cola avanzada como el MTA de Exchange siguen utilizando el código de reapi.dll para enrutar mensajes. Sólo dejan de recibirse las actualizaciones dinámicas de la tabla de estado de vínculos. Nota: Aunque no se suele recomendar, se puede deshabilitar el servicio Motor de enrutamiento de Exchange en todos los servidores que ejecutan Exchange Server 2003 de la organización. El código de reapi.dll aún puede inicializar la tabla de estado de vínculos de cada servidor con información de Active Directory, pero no se producen actualizaciones ualizaciones dinámicas de la tabla de estado de vínculos. En ese caso, Exchange Server 2003 lleva a cabo el enrutamiento de mensajes estático.

Examen de la tabla de estado de vínculos La tabla de estado de vínculos es una pequeña base de datos residente en memoria que no está almacenada en el disco. Para examinar las entradas que usa el motor de enrutamiento para tomar decisiones de enrutamiento, puede usar la herramienta WinRoute de Exchange Server 2003 (Winroute.exe), que se puede descargar en el sitio We Web Descargas para Exchange Server 2003 (en inglés).

187

Nota: La herramienta WinRoute también se incluye en Exchange 2000 Server, pero se recomienda descargar y usar la versión de Exchange Server 2003 de la herramienta en todos los servidores de Exchange 2000 y Exchange Server 2003 de la organización. La herramienta WinRoute se conecta al puerto de estado de vínculos (el puerto TCP 691) del servidor de Exchange seleccionado y extrae la tabla de estado de vínculos. La información de esta tabla son varios GUID y texto ASCII que representan grupos de enrutamiento, miembros de grupos de enrutamiento y conectores de los grupos de enrutamiento. La tabla de estado de vínculos también contiene información acerca acerca de la configuración de cada conector. Los campos de información de la tabla de estado de vínculos están separados por paréntesis, tal y como se indica a continuación: 'General Info' ('Routing Group' 'Routing Group Master' 'Version Info' 'Routing Group Addresses' ddresses' (Routing Group Members) (Connectors in Routing Group (Connector configuration))).

A continuación, figura un ejemplo resumido de una tabla de estado de vínculos (se han quitado todos los grupos de enrutamiento excepto uno): d38082e7c9ecd74dbff32ba d38082e7c9ecd74dbff32bada8932642 d037d6eaf2fa7cd10934aca433390623 (489416bfa3a4ff459b8f4403f20cad0d 1650c1fe32aef740be236e1089e0da6a 8 0 2 c2da71f9b39ec748aaf44119a2bdcb36 {26}*.489416BF-A3A4-FF45-9B8F-4403F20CAD0D {26}*.489416BF 4403F20CAD0D {4c}c=DE;a= ;p=TailspinToys;o=Exchange;cn=489416BF-A3A4-FF45-9B8F-4403F20CAD0D;* ;p=TailspinToys;o=Exchange;cn=489416BF 4403F20CAD0D;* {55}/o=TailspinToys/ou=First administrative Group/*/489416BF-A3A4-FF45 Group/*/489416BF FF45-9B8F4403F20CAD0D ( 1650c1fe32aef740be236e1089e0da6a YES 1 1b20 {10}0701000000000101 ) ( aa582d35e9621c4ca8ae57aa33d953a1 ( CONFIG {4}SMTP {} {23}_aa582d35e9621c4ca8ae57aa33d953a1_D {63}/o=TailspinToys/ou=First administrative {23}_aa582d35e9621c4ca8ae57aa33d953a1_D Group/cn=Configuration/cn=Connections/cn=RGC RG A <-> < > RG B 0 0 0 0 ffffffff ffffffff 0 1 0 () 0 () 0 () 0 ()

ARROWS ( {2}RG {20}83bd0e29fad06d4eb8b00faab3265cd5 1

{4}X400

{23}c=DE;a= ;p=TailspinToys;o=Exchange; ;p=TailspinTo 1 ) BH () TARGBH ( 766a192b43bfc3459ee85608d65a98a9 CONN_AVAIL {19}server01.TailspinToys.com ) STATE UP))) (... next routing group... (... next routing members...) (... connectors in routing group (... connector configuration..)))

La tabla siguiente iguiente asigna esta información a los diversos campos de información de la tabla de estado de vínculos.

188

Información de la tabla de estado de vínculos Campo

Valor

Comentarios

Organization objectGUID d38082e7c9ecd74dbff32bada89 (objectGUID de organización) 32642

El GUID que está registrado en el atributo objectGUID del objeto de organización de Exchange en Active Directory.

MD5 Digest (código MD5)

Un código MD5 o valor hash. Se trata de una firma cifrada que representa el número de versión de la tabla de estado de vínculos. En función de esta información, los motores de enrutamiento pueden determinar si disponen de la misma información de estado de vínculos. Si la información es distinta, los motores de enrutamiento intercambian paquetes OrgInfo para determinar el servidor que tiene la información más actualizada. El paquete OrgInfo contiene la tabla de estado de vínculos, con todos los detalles y estados de la topología de enrutamiento. La propagación de información de estado de vínculos se explica más adelante en esta sección.

d037d6eaf2fa7cd10934aca4333 90623

Routing Group objectGUID (objectGUID de grupo de enrutamiento)

489416bfa3a4ff459b8f4403f20 cad0d

El GUID que está registrado en el atributo objectGUID del objeto de grupo de enrutamiento al que pertenece la información de enrutamiento. Este GUID es el siguiente que aparece en la tabla de estado de vínculos.

189

Campo

Valor

Comentarios

Routing Group Master objectGUID (objectGUID de maestro de grupo de enrutamiento)

1650c1fe32aef740be236e1089e

El GUID que está registrado en el atributo objectGUID del servidor que actúa de maestro de grupo de enrutamiento de este grupo de enrutamiento.

0da6a

El maestro de grupo de enrutamiento de cada grupo se encarga de mantener y comunicar la información de estado de vínculos a todos los miembros del grupo de enrutamiento. Sólo existe un maestro de grupo de enrutamiento en cada grupo de enrutamiento. Para obtener más información acerca de la función del maestro de grupo de enrutamiento, consulte la explicación más adelante en esta sección.

190

Campo

Valor

Comentarios

Version Info (Información de versión)

8 0 2

Los valores 8 0 2 son las versiones principal, secundaria y de usuario de la información de estado de vínculos. El motor de enrutamiento usa esta información de versión para clasificar actualizaciones de la información de estado de vínculos tal y como sigue:

c2da71f9b39ec748aaf44119a2b dcb36

•

Actualizaciones principales Representa n cambios en la topología de enrutamiento, como cambios en la configuración de un conector (es decir, agregar o eliminar un conector, agregar o eliminar un espacio de direcciones de un conector, o cuando se designa un nuevo servidor como maestro de grupo de enrutamiento).

•

Actualizaciones secundarias Represent an cambios en la disponibilidad de un servidor virtual o conector. Por ejemplo, el estado de un conector podría cambiar de activo a inactivo si no está disponible el servidor cabeza de puente del conector.

•

Actualizaciones de usuario Representan cambios que se producen cuando se inician o se detienen servicios de un servidor de Exchange o cuando un servidor pierde la conexión al maestro de

191

Campo

Valor

Comentarios

Routing Group Addresses (Direcciones de grupos de enrutamiento)

{26}*.489416BF-A3A4-FF45-

Asigna información de SMTP, X.400, X.500 y direcciones a cada GUID de grupo de enrutamiento. El motor de enrutamiento usa esta información para generar una caché del servidor interna, que sirve para identificar el grupo de enrutamiento de cada servidor en la topología de enrutamiento. La caché del servidor es una tabla interna del motor de enrutamiento.

9B8F-4403F20CAD0D {4c}c=DE;a= ;p=TailspinToys;o=Exchange; cn=489416BF-A3A4-FF45-9B8F4403F20CAD0D;* {55}/o=TailspinToys/ou=Firs t administrative Group/*/489416BF-A3A4-FF459B8F-4403F20CAD0D

Por ejemplo, supongamos que SERVER01 de un grupo de enrutamiento denominado First Routing Group tiene el FQDN SERVER01.TailspinToys.co m. Según la definición de direcciones de grupo de enrutamiento, el motor de enrutamiento crea la siguiente entrada para SERVER01 en la caché del servidor: SERVER01.TailspinToys.com.4 89416BF-A3A4-FF45-9B8F4403F20CAD0D.

Durante un suceso de enrutamiento, cuando el motor de cola avanzada pasa el FQDN al motor de enrutamiento, el motor de enrutamiento consulta la caché del servidor, busca la entrada de SERVER01.TailspinToys.co m y determina rápidamente el grupo de enrutamiento de destino. El principio es idéntico para direcciones X.400 y X.500, pero la información de dirección es más compleja.

192

Campo

Valor

Comentarios

Routing Group Members (Miembros de grupo de enrutamiento)

(

Contiene una lista de todos los servidores que pertenecen al grupo de enrutamiento e identifica su estado. Observe, sin embargo, que el motor de enrutamiento no usa esta información para el enrutamiento de mensajes. Tal y como se explicó anteriormente en esta sección, el motor de enrutamiento usa la caché del servidor.

1650c1fe32aef740be236e1089e 0da6a YES 1 1b20 {10}0701000000000101 )

Los miembros de grupo de enrutamiento figuran en la lista Routing Group Members () con fines de supervisión del sistema. Puede ver esta información en el Administrador del sistema de Exchange, al abrir el nodo Herramientas, a continuación, Supervisión y estado, y después Estado. Las entradas del estado del servidor de la lista Miembros del grupo de enrutamiento () contienen la siguiente información: •

El objectGUID del servidor: 1650c1fe32aef740be236 e1089e0da6a

•

Si el miembro está conectado o no al maestro de grupo de enrutamiento. YES indica que el servidor está conectado.

•

Número de versión del servidor: 1

•

Versión de compilación: 1b20 hex = 6944

•

Datos de usuario: {10}0701000000000101

193

Campo

Valor

Comentarios

Connectors in Routing Group (Conectores del grupo de enrutamiento)

(

A partir del siguiente paréntesis de apertura, cada conector que pertenece al grupo de enrutamiento figura en una entrada separada que incluye el objectGUID del conector y la información de configuración que usa el motor de enrutamiento para tomar decisiones sobre el enrutamiento de los mensajes.

aa582d35e9621c4ca8ae57aa33d 953a1 ( CONFIG ))

La información de configuración del conector de la tabla de estados de vínculos contiene los campos siguientes: Connector objectGUID (objectGUID de conector)

aa582d35e9621c4ca8ae57aa33d 953a1

El GUID que identifica al conector de forma exclusiva en la organización de Exchange.

194

Campo

Valor

Comentarios

Connector Type (Tipo de conector)

{4}SMTP

Este campo identifica el tipo de conector cuando sigue a la palabra clave CONFIG. Puede ser: SMTP, X.400, Notes o Exchange Development Kit (EDK). Los tipos Notes y EDK hacen referencia a instancias de un conector de mensajería basado en MAPI que se conecta a un sistema de mensajería que no es de Exchange. Para obtener más información acerca de los conectores basados en MAPI, consulte Arquitectura de los conectores de mensajería de puerta de enlace. Sugerencia: El número que figura entre llaves no es un identificador. Este número indica la longitud de cadena del valor del campo en formato hexadecimal. Nota: No existe ningún tipo explícito para conectores para grupos de enrutamiento. Los conectores para grupos de enrutamiento usan SMTP para transferir mensajes.

195

Campo

Valor

Source Bridgehead Address {} (Dirección de servidor cabeza de puente de origen)

Comentarios

Este campo puede tener uno de estos tres valores: •

Ningún valor Si no se especifica ningún servidor cabeza de puente de origen, cualquier servidor del grupo de enrutamiento local puede usar el conector para transferir mensajes. Se aplica a conectores para grupo de enrutamiento si se utiliza la opción Cualquier servidor local puede enviar correo por este conector.

•

Un GUID de conector En el caso de conectores para SMTP y conectores para grupo de enrutamiento, puede especificar servidores cabeza de puente locales específicos, en cuyo caso el campo Source BridgeHead Address incluye el GUID de conector con el sufijo "_S" (sin las comillas) para indicar un servidor cabeza de puente de origen, como: {23}_76290a25817c0643a1 a6999e669b1d5f_S

Los servidores cabeza de puente locales figuran en el campo BH de la información de conector. •

Una dirección de servidor cabeza de puente Los conectores X.400 y los conectores basados en MAPI no pueden tener más de un servidor cabeza de

196

Campo

Valor

Destination Bridgehead {23}_aa582d35e9621c4ca8ae57 Address (Dirección de aa33d953a1_D servidor cabeza de puente de destino)

Comentarios

Al igual que con el campo Source Bridgehead Address, este campo puede tener uno de tres valores. •

Sin valor Los conectores X.400 y los conectores basados en MAPI no disponen de un servidor cabeza de puente en la tabla de estado de vínculos. Estos conectores usan información específica de conector para determinar su sistema de destino, como el nombre de host remoto en la configuración de pila de un conector X.400.

•

Un GUID de conector En el caso de conectores para grupo de enrutamiento, el campo Destination Bridgehead Address incluye el GUID de conector con el sufijo "_D" (sin las comillas) para indicar un servidor cabeza de puente de destino. En este caso, los servidores cabeza de puente de destino figuran más adelante en el campo TARGBH de la información de conector.

•

Una dirección de cabeza de puente Los conectores para SMTP no pueden tener varios hosts de destino cuando conectan grupos de enrutamiento entre sí. La configuración de conector requiere que especifique un host inteligente en el grupo de enrutamiento remoto,

197

Campo

Valor

Comentarios

Legacy Distinguished Name (Nombre completo heredado)

{63}/o=TailspinToys/ou=Firs

Éste es el nombre completo del conector en formato de directorio heredado de Exchange 5.5. El valor corresponde al atributo legacyExchangeDN del objeto de conector de Active Directory.

t administrative Group/cn=Configuration/cn=C onnections/cn=RGC RG A <-> RG B

Schedule ID (Id. de programación)

0

El campo Schedule ID no se usa y siempre está establecido en 0. El motor de cola avanzada y el MTA de Exchange consultan Active Directory para determinar la programación de activación de un conector.

198

Campo

Valor

Comentarios

Restrictions (Restricciones)

0 0 0 ffffffff ffffffff 0 1

El campo Restrictions identifica el ámbito del conector, las restricciones restri de tamaño de mensajes y otras restricciones como sigue:

0 () 0 () 0 () 0 ()

•

El ámbito del conector se identifica por el primer dígito. Si el valor es 0, indica que el ámbito es "Organización". Si el valor es 1, indica que el ámbito es "Grupo de enrutamiento". Nota: Los conectores para grupo de enrutamiento siempre tienen el ámbito "Organización". Los conectores a sistemas de mensajería externos pueden restringirse al grupo de enrutamiento local.

•

El siguiente dígito indica si se ha configurado la entrega desencadenada. desencade Si el valor es 0, indica que no se ha configurado la entrega desencadenada. Si el valor es 1, indica que el host remoto debe desencadenar la transferencia del mensaje (por ejemplo TURN/ETRN).

•

El tercer dígito identifica el tipo de mensaje (alta, normal, rmal, baja, sistema, no del sistema) que se permite a través del conector.

•

Los siguientes ocho

199

Campo

Valor

Comentarios

Address Spaces (Espacios de direcciones)

ARROWS ( {2}RG

Cada conector tiene como mínimo un espacio de direcciones asociado. El motor de enrutamiento utiliza esta información para determinar posibles conectores para un mensaje concreto; para ello, compara las direcciones de los destinatarios con la información de espacios de direcciones disponible.

{20}83bd0e29fad06d4eb8b00fa ab3265cd5 1

{4}X400

{23}c=DE;a= ;p=TailspinToys;o=Exchange; 1 )

En la tabla de estado de vínculos, la lista ARROWS () contiene los espacios de direcciones individuales que pertenecen al conector. Cada entrada de espacio de direcciones contiene los siguientes fragmentos de información: •

Tipo de espacio de direcciones El tipo de espacio de direcciones determina el formato de la información de espacio de direcciones que le sigue en la siguiente posición. Por ejemplo, un espacio de direcciones X.400 requiere información de espacio de direcciones en un formato X.400 válido. Por otro lado, el espacio de direcciones SMTP contiene partes de un nombre de dominio SMTP. En el caso de conectores para grupo de enrutamiento, el tipo de espacio de direcciones es RG, que indica un objectGUID de grupo de enrutamiento.

•

Espacio de direcciones El espacio

200

Campo

Valor

Comentarios

Source Bridgeheads (Servidores cabeza de puente de origen)

BH ()

El campo BH incluye los servidores cabeza de puente locales para el conector y su información de estado. Los servidores cabeza de puente se identifican mediante los siguientes fragmentos de información: •

objectGUID de servidor cabeza de puente El GUID de un servidor SMTP virtual, que se especifica en la configuración de conector como servidor cabeza de puente local.

•

Estado del servidor cabeza de puente Información que indica la disponibilidad del servidor cabeza de puente tal y como sigue: •

CONN_AVAIL El servidor cabeza de puente está disponible.

• VS_NOT_STAR TED Un servidor SMTP virtual se ha detenido o no se ha iniciado. • CONN_NOT_AV AIL La conexión no está disponible en el servidor cabeza de puente. Por ejemplo, el servidor cabeza de puente de origen no puede establecer una conexión a un servidor cabeza de puente de destino. •

FQDN del servidor

201

Campo

Valor

Comentarios

Destination Bridgeheads (Servidores cabeza de puente de destino)

TARGBH (

Al igual que con la lista BH (), la lista TARGBH () contiene los servidores cabeza de puente de destino de un conector. Esta lista es especialmente importante para conectores para grupo de enrutamiento, que pueden tener varios servidores cabeza de puente remotos.

766a192b43bfc3459ee85608d65 a98a9 CONN_AVAIL {19}server01.TailspinToys.c om )

En el ejemplo, la siguiente información identifica el servidor cabeza de puente remoto: •

objectGUID de servidor cabeza de puente 766a192b43bfc34 59ee85608d65a98a9

•

Estado del servidor cabeza de puente CONN_AVAIL

•

FQDN del servidor virtual {19}server01.Ta ilspinToys.com

202

Campo

Valor

Comentarios

Status (Estado)

STATE UP

Estado del conector. Este campo puede tener dos valores: •

STATE UP Indica que el conector está disponible.

•

STATE DOWN Indica que el conector no está disponible.

El estado del conector se deriva el estado de los servidores cabeza de puente de origen del conector. Un conector sólo puede tener el estado STATE UP cuando está disponible como mínimo un servidor cabeza de puente de origen (CONN_AVAIL). Si no se ha iniciado ninguno de los servidores cabeza de puente virtuales de origen del conector (VS_NOT_STARTED) o los servidores cabeza de puente de origen no pueden establecer una conexión (CONN_NOT_AVAIL), el estado del conector es STATE DOWN. Nota: Para que se marque un conector como no disponible, deben estar no disponibles todos los servidores cabeza de puente locales. Los conector para conectores grupo de enrutamiento que están configurados para usar la opción Cualquier servidor local puede enviar correo por este conector además conector,

203

Nota: La herramienta WinRoute proporciona una vista intuitiva de la topología de enrutamiento y de e la tabla de estado de vínculos mediante la resolución de los GUID de la tabla de estado de vínculos en nombres en un formato legible, siempre que la herramienta tenga acceso a Active Directory. El panel superior de la ventana de programa de WinRoute mues muestra tra la información interpretada, el panel intermedio incluye todos los espacios de direcciones existentes y el panel inferior muestra la información sin procesar de la tabla de estado de vínculos. Para obtener más información acerca de la herramienta WinRoute, WinRoute, consulte las descargas de herramientas en Herramientas para Exchange Server 2003 (en inglés).

Selección de ruta de enrutamiento de Exchange En una organización con varios grupos de enrutamient enrutamiento, o, puede llegarse al mismo destino a través de diversas rutas. Normalmente, se usa la ruta más eficiente para la transferencia de mensajes y las rutas adicionales se mantienen en espera, por si la mejor ruta deja de estar disponible temporalmente. Por ejem ejemplo, plo, en la topología que se muestra en la figura siguiente, existen varias rutas de transferencia entre todos los grupos de enrutamiento.

204

Topología de enrutamiento con cinco grupos de enrutamiento

Nota: El enrutamiento de mensajes debería seguir la topología de red física. Si la topología de red subyacente se ha diseñado como topología radial verdadera (con el grupo de enrutamiento A como concentrador), no tiene sentido definir conectores para grupo de enrutamiento tal y como se muestra en la figura anterior. En su lugar, los grupos de enrutamiento B, C, D y E se deberían conectar directamente al grupo de enrutamiento A y todas las transferencias de mensajes entre grupos de enrutamiento deberían enrutarse a través del grupo de enrutamiento A. En una topología topología radial verdadera, no existen rutas de mensaje alternativas y la selección de ruta de enrutamiento es directa. No obstante, en las explicaciones de esta sección se presupone que la topología de red física es una malla que sigue la organización de conectores onectores para grupo de enrutamiento que se muestra.

205

El motor de enrutamiento usa la siguiente información para determinar la mejor ruta: •

Espacio de direcciones Al configurar conectores para grupo de enrutamiento, se asocian destinos posibles a conectores de mensajería mediante la ficha Grupos de enrutamiento conectados de las propiedades de conector. Sin embargo, el conector para grupo de enrutamiento no incluye esta ficha. Puesto que este conector sólo se usa para la conexión a grupos de enrutamiento, el motor de enrutamiento puede determinar los espacios de direcciones de grupos de enrutamiento a partir de la configuración del conector. GUID y espacios de direcciones de grupo de enrutamiento

Los espacios de direcciones pueden agregarse a un conector mediante la ficha Espacio de direcciones. Tal y como se mencionó en la tabla "información de la tabla de estado de los vínculos", los espacios de direcciones se componen de un tipo de dirección, como RG, SMTP, X400, MSMAIL o CCMAIL, una dirección y un valor de costo. El valor de costo que asigne a un espacio de direcciones es un criterio de enrutamiento importante. El motor de enrutamiento usa el algoritmo de ruta más corta de Dijkstra para tomar decisiones de enrutamiento. Este algoritmo está basado en valores de costo. •

Ámbito del conector Los conectores a sistemas de mensajería externos pueden estar restringidos al grupo de enrutamiento del conector, en cuyo caso sólo los usuarios del grupo de enrutamiento local del conector pueden usar el conector. De forma predeterminada, todos los conectores tienen un ámbito de Toda la organización.

206

Nota: Los conectores para grupo de enrutamiento siempre están disponibles en toda la organización. •

Restricciones El motor de enrutamiento determina el tamaño, la prioridad y el tipo del mensaje (es decir, mensaje del sistema o mensajes no del sistema). El motor de enrutamiento compara estas propiedades con la información de restricciones de conectores disponible. A continuación, excluye de la lista de conectores potenciales los conectores que no pueden transferir el mensaje debido debido a las restricciones de conectores activas.

•

Estado En el proceso de selección de rutas, sólo se incluyen los conectores disponibles. El campo de estado de cada conector indica si el conector está disponible (STATE UP) o no (STATE DOWN).

Proceso de selección de ruta de enrutamiento Para seleccionar la mejor ruta hasta el destino, el motor de enrutamiento calcula la ruta de transferencia más corta desde el grupo de enrutamiento de origen al grupo de enrutamiento de destino en la organización de Exchange Exchange y, para ello, usa el algoritmo de ruta más corta de Dijkstra. Entonces, el motor de enrutamiento determina el siguiente salto de la ruta más corta que debería usar el motor de cola avanzada para la transferencia de mensajes. El proceso de selección de ruta de enrutamiento consta de dos pasos: 1. El motor de cola avanzada llama al método GetMessageType de la interfaz IMessageRouter del motor de enrutamiento. En el método GetMessageType, el motor de cola avanzada pasa el mensaje al motor de enrutamiento en forma de objeto MailMsg. En este paso, el motor de enrutamiento realiza los siguientes procesos: a. Comprueba la información de seguimiento de mensajes para detectar bucles. Si se detecta un bucle de mensajes, se omite el mensaje y se envía un NDR al remitente. b. Lee o vuelve a calcular (en cas caso o necesario) la topología de la organización actual (es decir, determina la lista de rutas más cortas a todos los destinos de la topología de enrutamiento, a partir del grupo de enrutamiento local). c.

Comprueba y actualiza la información de restricciones acerca de conectores de la tabla de estado de vínculos.

d. Determina todos los conectores al destino del mensaje de la topología de la organización y, a continuación, analiza las características del mensaje y las restricciones de conectores para excluir to todos dos los conectores que no se deben usan para transferir el mensaje. e. Calcula un valor de filtro para el mensaje, que define de forma exclusiva el tipo de mensaje. El tipo de mensaje identifica la ruta que pueden usar los mensajes que tienen características características similares. El tipo de mensaje se almacena en caché. Por lo tanto, el motor de enrutamiento no vuelve a calcular el valor de filtro para los mensajes sucesivos que tengan características similares.

207

Nota: El motor de cola avanzada mantiene una cola d de e mensajes independiente para cada tipo de mensaje. f.

Crea tipos de mensajes asociados. El tipo de mensaje asociado es similar al tipo de mensaje real, pero se calcula con restricciones menos estrictas. Los tipos de mensajes asociados permiten al subsistema subsistema de transporte SMTP devolver códigos de error ampliados si una ruta de transferencia no está disponible para el tipo de mensaje debido a restricciones de conectores.

g. Devuelve el índice del tipo de mensaje en caché al motor de cola avanzada. 2. El motorr de enrutamiento determina el siguiente salto de la ruta más corta. Para completar este paso, el motor de cola avanzada llama al método GetMessageType de la interfaz IMessageRouter. La información más importante que pasa el motor de cola avanzada al motor de enrutamiento en este momento es la dirección de destino y el Id. de tipo de mensaje. Para los destinatarios de la organización de Exchange, la dirección de destino es el FQDN del servidor principal del destinatario. El motor de enrutamiento determina ell grupo de enrutamiento de destino a partir de la caché del servidor, comprueba la ruta disponible para el tipo de mensaje y devuelve el siguiente salto de la ruta al grupo de enrutamiento de destino al motor de cola avanzada. El motor de cola avanzada puede de así transferir el mensaje al siguiente salto de la ruta al destino.

El algoritmo de ruta más corta de Dijkstra Para tomar decisiones de enrutamiento correctas, el motor de enrutamiento debe conocer las rutas más cortas a todos los destinos posibles de la la topología de enrutamiento. El motor de enrutamiento debe encontrar las rutas más cortas de entre todas las rutas de transferencia disponibles a todos los destinos de una topología de enrutamiento compleja. Este problema se conoce como el problema de ruta rutass más cortas de origen único. La figura siguiente muestra que, incluso en una topología de enrutamiento relativamente sencilla, pueden existir muchas rutas desde un grupo de enrutamiento a cualquier otro grupo de enrutamiento. La figura muestra los conectores conectores para grupo de enrutamiento de la figura 5.4 de forma simplificada con sus valores de costo predeterminado de 1.

208

Conectores para grupo de enrutamiento con valores de costo predeterminado

En 1959, el profesor Edsger Dijkstra resolvió el problema de rutas más cortas de origen único mediante la creación de un algoritmo que encuentra, en un solo cálculo, las rutas más cortas desde un origen dado a todos los puntos de una topología. El motor de enrutamiento usa el algoritmo de Dijkstra tal y como sigue: 1. Se presupone que la topología de enrutamiento que representa a todas las rutas desde un grupo de enrutamiento a todos los otros grupos de enrutamiento es un árbol de expansión. Esto determina que la topología debe incluir todos los grupos de enrutamiento y todos los conectores para grupo de enrutamiento, y que no hay bucles entre grupos de enrutamiento. Por lo tanto, las rutas de la topología de enrutamiento que permiten a un mensaje volver al grupo de enrutamiento de origen son rutas de transferencia ilegales y no están incluidas en el cálculo. 2. Según el algoritmo de Dijkstra, el motor de enrutamiento mantiene dos conjuntos de grupos de enrutamiento. El primer conjunto incluye todos los grupos para los que ya se ha determinado la ruta más corta desde el grupo de enrutamiento de origen. El segundo conjunto incluye todos los grupos de enrutamiento restantes. Al principio, el conjunto de grupos de enrutamiento para los que ya se han determinado las rutas más cortas está vacío. Siempre que queden grupos de enrutamiento por procesar, el motor de enrutamiento lleva a cabo los pasos 3 a 6 tal y como sigue: 3. El motor de enrutamiento ordena los grupos de enrutamiento restantes en función de la mejor estimación actual de su distancia (es decir, la suma de los valores de costo) a partir del grupo de enrutamiento de origen. 4. A continuación, agrega el grupo de enrutamiento más próximo al conjunto de grupos de enrutamiento para los que se han determinado las rutas más cortas.

209

5. El motor de enrutamiento actualiza entonces los costos de todos los grupos de enrutamiento conectados a ese grupo de enrutamiento (si esto mejora la mejor estimación de la ruta más corta para cada uno de los grupos de enrutamiento restantes) incluyendo el valor de costo del conector entre esos grupos de enrutamiento en el valor de distancia. 6. Actualiza el predecesor para todos los grupos de enrutamiento actualizados. La lista de predecesores finalmente define la ruta más corta desde cada grupo de enrutamiento al grupo de enrutamiento de destino. Los pasos siguientes muestran cómo encuentra el motor de enrutamiento las rutas más cortas desde el grupo de enrutamiento A a todos los otros grupos de enrutamiento de la topología de enrutamiento. 1. El cálculo comienza en el grupo de enrutamiento A, ya que en este ejemplo el origen es el grupo de enrutamiento A. El valor de distancia del grupo de enrutamiento A respecto a sí mismo es cero. El valor de distancia de todos los otros grupos de enrutamiento no se ha determinado. 2. Se agrega el grupo de enrutamiento A al conjunto de grupos de enrutamiento para los que se han determinado las rutas más cortas desde el grupo de enrutamiento de origen. A continuación, se actualiza el valor de distancia de todos los grupos de enrutamiento adyacentes al grupo de enrutamiento A con los valores de costo de sus conectores. Luego se actualiza el predecesor (indicado por el origen de las flechas negras) de todos los grupos de enrutamiento. El predecesor es el grupo de enrutamiento A. 3. El motor de enrutamiento ordena los grupos de enrutamiento restantes en función de la mejor estimación actual de su distancia desde el grupo de enrutamiento de origen. Agrega el grupo de enrutamiento más próximo al conjunto de grupos de enrutamiento para los que se han determinado las rutas más cortas. Puesto que los grupos de enrutamiento B y C tienen el mismo valor de distancia, el motor de enrutamiento selecciona un grupo de enrutamiento de forma aleatoria. Este ejemplo presupone que el motor de enrutamiento selecciona el grupo de enrutamiento B. 4. El motor de enrutamiento calcula el valor de distancia de todos los grupos de enrutamiento restantes adyacentes al grupo de enrutamiento B mediante la combinación del valor de costo del conector entre el grupo de enrutamiento B y el grupo de enrutamiento adyacente con el valor de distancia del grupo de enrutamiento B. Actualiza el valor de distancia de un grupo de enrutamiento adyacente sólo si el valor de distancia calculado es inferior al valor que ya está asignado al grupo de enrutamiento, y sólo entonces actualiza el predecesor (indicado por flechas negras). Los vecinos del grupo de enrutamiento B son los grupos de enrutamiento C, D y E. El valor de distancia actual de los grupos C y D no está definido. Por lo tanto, su valor de distancia se actualiza con los valores de costo de sus conectores, más el valor de distancia del grupo de enrutamiento B (1+1). Entonces, se actualiza el predecesor (indicado por el origen de las flechas negras) de todos los grupos de enrutamiento. El predecesor es el grupo de enrutamiento B.

210

El grupo de enrutamiento C no se actualiza porque la suma del valor de distancia del grupo de enrutamiento C y el costo del conector (1+1) es mayor que el valor de distancia actual del grupo de enrutamiento C. 5. El motor de enrutamiento ordena los grupos de enrutamiento restantes en función de la mejor estimación actual de su distancia desde el grupo de enrutamiento de origen y agrega el grupo de enrutamiento más próximo al conjunto de grupos de enrutamiento para los que se han determinado las rutas más cortas. El algoritmo escoge ahora el grupo de enrutamiento C porque este grupo de enrutamiento tiene el valor de distancia inferior. 6. El motor de enrutamiento calcula el valor de distancia de todos los grupos de enrutamiento restantes adyacentes al grupo de enrutamiento C mediante la combinación del valor de costo del conector entre el grupo de enrutamiento C y los grupos de enrutamiento adyacentes con el valor de distancia del grupo de enrutamiento C. Actualiza el valor de distancia de un grupo de enrutamiento adyacente sólo si el valor de distancia calculado es inferior al valor que ya está asignado al grupo de enrutamiento y sólo entonces actualiza el predecesor (indicado por flechas negras). Los grupos de enrutamiento restantes que son vecinos del grupo de enrutamiento C son los grupos de enrutamiento D y E (los grupos de enrutamiento A y B ya se procesaron). El valor de distancia actual de los grupos de enrutamiento D y E es 2. Este valor es inferior a la suma del costo de conector y el valor de distancia del grupo de enrutamiento C (1+2). Por lo tanto, no se actualizan el valor de distancia ni la lista de predecesores de los grupos de enrutamiento D y E. 7. El motor de enrutamiento ordena los grupos de enrutamiento restantes (grupos de enrutamiento D y E) en función de la mejor estimación actual de su distancia desde el grupo de enrutamiento de origen y agrega el grupo de enrutamiento más próximo al conjunto de grupos de enrutamiento para los que se han determinado las rutas más cortas. Puesto que los grupos de enrutamiento D y E tienen el mismo valor de distancia, el motor de enrutamiento selecciona un grupo de enrutamiento de forma aleatoria. Este ejemplo presupone que el motor de enrutamiento selecciona el grupo de enrutamiento D. El único vecino restante es el grupo de enrutamiento E, que tiene un valor de distancia actual de 2. Este valor es inferior a la suma del costo de conector y el valor de distancia del grupo de enrutamiento D (1+2). Por lo tanto, no se actualizan el valor de distancia ni la lista de predecesores del grupo de enrutamiento E. El último grupo de enrutamiento que no se ha agregado a la lista de grupos de enrutamiento para los que se han determinado las rutas más cortas es el grupo de enrutamiento E. No queda ningún grupo de enrutamiento adyacente. Por lo tanto, ha finalizado el cálculo de la ruta más corta. Se han determinado las rutas más cortas desde el grupo de enrutamiento A a cualquier otro grupo de enrutamiento de la topología.

211

Equilibrio de carga de transferencia de mensajes Si existen varias rutas con el mismo valor de costo, el motor de enrutamiento selecciona una ruta de transferencia al azar, tal y como se describe en los pasos anteriores. No obstante, el motor de enrutamiento no lleva a cabo el equilibro de carga. Tal y como se explicó anteriormente, el motor de enrutamiento almacena en caché la información de tipo de mensaje que hace referencia a la ruta más corta que puede tomar un mensaje para llegar a su destino. Por lo tanto, todos los mensajes del mismo tipo viajan por la misma ruta, incluso si existe otra ruta con el mismo valor de costo (por ejemplo, "grupo de enrutamiento A > grupo de enrutamiento B > grupo de enrutamiento E" y "grupo de enrutamiento A > grupo de enrutamiento C > grupo de enrutamiento E").

Equilibrio de carga entre grupos de enrutamiento Sólo se puede lograr un verdadero equilibrio de carga entre grupos de enrutamiento si se usa un conector de grupos de enrutamiento con varios servidores cabeza de puente. La tabla siguiente incluye las configuraciones de equilibrio de carga que puede usar entre grupos de enrutamiento.

212

Configuraciones posibles entre grupos de enrutamiento Configuración posible

Comentarios

Un solo conector de grupos de enrutamiento con varios servidores cabeza de puente de origen o de destino, o ambos.

Con estos tipos de conectores, el motor de enrutamiento devuelve el GUID de conector en la información de siguiente salto al motor de cola avanzada. A continuación, el motor mot de cola avanzada selecciona al azar el servidor cabeza de puente que se debe usar y así realiza el equilibrio de carga de la transferencia del mensaje por todos los servidores cabeza de puente. Si un mensaje llega a un servidor cabeza de puente de origen n de un conector para grupo de enrutamiento con varios servidores cabeza de puente de origen, el mensaje no se vuelve a enrutar a ningún otro servidor cabeza de puente de origen. Una vez que el mensaje llega al conector para grupo de enrutamiento, la transferencia ferencia del mensaje al grupo de enrutamiento de destino es directa. Por consiguiente, los usuarios con buzones en el servidor cabeza de puente siempre usan el servidor local para la transferencia de mensajes al grupo de enrutamiento de destino. Nota: Se recomienda especificar varios servidores cabeza de puente de origen y de destino para un único conector para grupo de enrutamiento entre dos grupos de enrutamiento. Esta práctica mejora el equilibrio de carga y la redundancia.

213

Configuración posible

Comentarios

Varios conectores con el mi mismo espacio de direcciones (o grupo de enrutamiento conectado), el mismo peso (costo) y cada uno con un único servidor cabeza de puente de origen y de destino

En este tipo de configuración, no se logra un verdadero equilibrio de carga. El equilibrio de carga ga se realiza únicamente con el propósito de seleccionar un conector inicialmente para un tipo de mensaje concreto. El motor de enrutamiento determina el tipo de mensaje una vez, almacena la información en caché y, a continuación, enruta todos los mensajes del mismo tipo por el mismo conector. El segundo conector sólo se utiliza si falla el primer conector. No obstante, es posible que un segundo servidor seleccione el segundo conector y que de este modo equilibre la carga hasta cierto punto. Nota: No se recomienda ecomienda usar varias instancias de conectores entre grupos de enrutamiento para el equilibrio de carga porque no se puede obtener un equilibrio de carga real.

Varios conectores con el mismo espacio de direcciones (o grupo de enrutamiento conectado), diferentes rentes pesos (costo) y cada uno con un único servidor cabeza de puente de origen y de destino

Si desea configurar conectores para que conmuten por error automáticamente, puede crear dos conectores distintos en servidores cabeza de puente diferentes, cada uno con un costo distinto. El estado del vínculo para un conector está determinado por su servidor cabeza de puente local. Si el servidor cabeza de puente del conector preferido que tiene el menor costo no está disponible, se considerará que ese conector no n está disponible y el enrutamiento elegirá automáticamente el segundo conector. Cuando el servidor cabeza de puente que hospeda el conector con el menor costo esté disponible, los servidores de Exchange empezarán a utilizarlo de nuevo.

214

Equilibrio de carga entre conectores y sistemas externos Según el escenario, existen varias formas de lograr el equilibrio de carga entre conectores SMTP. •

Si desea lograr el equilibrio de carga de solicitudes salientes entre varios servidores en la organización que las envía, configure varios servidores cabeza de puente de origen.

•

Si desea equilibrar la carga del tráfico entre varios servidores de destino, haga que el administrador de destino configure DNS correctamente (con una configuración adecuada de los registros MX y A), o especifique varias direcciones de host inteligente en el conector.

O bien, si desea garantizar la resistencia de la conmutación por error, cree varios conectores SMTP con ámbito en el mismo espacio de direcciones, diferentes costos y diferentes servidores cabeza de puente de origen. Si el servidor cabeza de puente del conector preferido que tiene el menor costo no está disponible, se considerará que ese conector no está disponible y el enrutamiento elegirá automáticamente el segundo conector. Si usa dos conectores con el mismo costo, los servidores de Exchange seleccionarán de forma aleatoria el servidor cabeza de puente y el conector que usarán. Después, si el servidor cabeza de puente deja de estar disponible, realizarán la conmutación por error al segundo conector. Sin embargo, una vez que el primer servidor cabeza de puente esté disponible, los servidores no conmutarán por error a este servidor porque la ruta tiene el mismo costo que el servidor que ya están utilizando. Por ejemplo, la configuración de conectores de la figura siguiente no es una configuración de equilibrio de carga para conmutación por error, porque los espacios de direcciones no coinciden. Los mensajes enviados a usuarios externos en un dominio de .NET siempre viajan por el conector SMTP con el espacio de direcciones .NET. Esto se debe a que el motor de enrutamiento selecciona el espacio de direcciones más detallado antes de evaluar los costos. Configuración de conector que no proporciona equilibrio de carga ni tolerancia a errores

215

Nota: Si existen restricciones sobre el conector con el espacio de direcciones *.NET y las restricciones impiden que determinados mensajes crucen el conector (por ejemplo, porque se deniega al remitente la transferencia de mensajes por este conecto conector), el motor de enrutamiento devuelve el mensaje al remitente con un NDR. El motor de enrutamiento no vuelve a pasar por el segundo conector para esos mensajes. El espacio de direcciones más detallado determina los conectores que se pueden usar para transferir erir un mensaje. Los conectores con menos espacios de direcciones se excluyen del cálculo de ruta.

Redireccionamiento de mensajes basado en la información de estado de vínculos Si un conector no puede transferir mensajes, el motor de cola avanzada notifica al motor de enrutamiento el error de vínculo. Esto podría hacer que el motor de enrutamiento marque el conector como no disponible, en cuyo caso se vuelven a enrutar los mensajes en cola. El motor de enrutamiento considera un conector como no disponible si se cumple una de las siguientes condiciones: •

El motor de enrutamiento no puede establecer una conexión al menos a uno de los servidores cabeza de puente de origen del conector y no hay hay ninguna conexión TCP/IP al puerto 691 entre el maestro de grupo de enrutamiento y los servidores cabeza de puente de origen. Los servidores cabeza de puente de origen no disponibles se marcan como VS_NOT_STARTED en la tabla de estado de vínculos.

•

Ninguno no de los servidores cabeza de puente de origen puede transferir correctamente el mensaje a un servidor cabeza de puente de destino. Los servidores cabeza de puente de origen que no pueden transferir mensajes al destino se marcan como CONN_NOT_AVAIL. Nota: Si usa conectores X.400 y el conector no puede transferir mensajes, el MTA de Exchange comunica al motor de enrutamiento que se produjo un error de vínculo. Por lo tanto, el estado del servidor cabeza de puente de origen es CONN_NOT_AVAIL. Los conectores conectores X.400 sólo pueden tener un servidor cabeza de puente de origen.

Redireccionamiento de mensajes Para garantizar la transferencia de mensajes eficiente, el motor de enrutamiento informa inmediatamente al motor de cola avanzada y al MTA de Exchange de cualquier cualq cambio de estado de vínculos. Para evitar enviar mensajes por rutas interrumpidas, todos los mensajes en cola deben volver a enrutarse. Este proceso se denomina redireccionamiento. En el redireccionamiento, el motor de cola avanzada omite toda la información información de siguiente salto

216

en caché porque esa información ya no es válida. Cada mensaje que está actualmente en espera de transferencia se pasa al motor de enrutamiento para recalcular el siguiente salto. Esta tarea puede consumir muchos recursos. La figura siguiente muestra un ejemplo de redireccionamiento en el que el servidor cabeza de puente del grupo de enrutamiento E no está disponible. En la actualidad, ningún mensaje puede llegar a este grupo de enrutamiento. Cuando el motor de enrutamiento recalcula recalcu las rutas más cortas para mensajes a destinatarios del grupo de enrutamiento E, descubre que no está disponible ninguna ruta. Los conectores marcados como no disponibles se excluyen del proceso de enrutamiento. Por lo tanto, el grupo de enrutamiento E está stá aislado en la actualidad. Conectores para grupos de enrutamiento no disponibles

Puesto que no existe una ruta válida, el motor de enrutamiento no puede determinar un siguiente salto válido para los mensajes que están a la espera de ser transferidos al grupo de enrutamiento E. En la información de tipo de siguiente salto, el motor de enrutamiento comunica al motor de cola avanzada que no se puede obtener acceso al siguiente salto. El motor de cola avanzada debe retener el mensaje hasta que esté disponible disponible al menos una ruta de transferencia o hasta que caduque el mensaje y se devuelva al remitente con un NDR. Nota: Si sólo existe un conector a un grupo de enrutamiento y no hay rutas alternativas, el estado de vínculo se marca siempre como disponible para para reducir el número de cambios de estado de vínculo en la topología de enrutamiento. Exchange Server 2003 coloca los mensajes en la cola y los envía cuando vuelve a estar disponible la ruta.

217

Redireccionamiento y espacios de direcciones Al igual que con ell equilibrio de carga, Exchange Server 2003 sólo vuelve a enrutar mensajes sobre conectores que tienen el mismo espacio de direcciones. Por ejemplo, puede crear dos conectores independientes en servidores cabeza de puente distintos, cada uno con el mismo espacio spacio de direcciones, pero con costos diferentes. Si deja de estar disponible el conector preferido, el motor de enrutamiento selecciona automáticamente el segundo conector, hasta que el conector primario vuelve a estar disponible. Nota: El motor de enrutamiento utamiento no vuelve a enrutar mensajes de un conector con un espacio de direcciones específico a un conector con un espacio de direcciones menos específico, porque el motor de enrutamiento lo considera un destino distinto. Los mensajes permanecen en el servidor servidor cabeza de puente de origen hasta que el conector con el espacio de direcciones detallado vuelve a estar disponible. Si existen restricciones sobre el conector con el espacio de direcciones .NET y las restricciones impiden que determinados mensajes cr crucen ucen el conector (por ejemplo, porque se deniega al remitente la transferencia de mensajes por este conector), el motor de enrutamiento devuelve el mensaje al remitente con un NDR. El motor de enrutamiento no vuelve a pasar por el segundo conector para eso esos s mensajes. El espacio de direcciones más detallado determina los conectores que se pueden usar para transferir un mensaje. Los conectores con espacios de direcciones menos detallados se excluyen del cálculo de ruta.

Recuperación de conectores El motor de enrutamiento determina que un conector vuelve a estar disponible de una de las siguientes formas: •

VS_NOT_STARTED El maestro de grupo de enrutamiento establece una conexión al puerto TCP 691 del servidor cabeza de puente de origen. El servidor cabeza de puente de origen está marcado como CONN_AVAIL, y puesto que para el conector está disponible como mínimo un servidor cabeza de puente de origen, el estado del conector cambia a STATE UP.

•

CONN_NOT_AVAIL En el caso de conectores no disponibles, los servidores se cabeza de puente de origen siguen reintentando establecer la conexión a intervalos de 60 segundos, incluso si no hay ningún mensaje en espera para transferir. Cuando se establece una conexión, el motor de cola avanzado o los informes de MTA de Exchange Exc informan al motor de enrutamiento del establecimiento de una conexión saliente de forma satisfactoria desde el servidor cabeza de puente de origen. A continuación, el motor de enrutamiento cambia el servidor cabeza de puente de origen a CONN_AVAIL y el conector a STATE UP.

218

Programaciones de Redireccionamiento y activación Todos los tipos de conectores permiten configurar una programación para el conector que permite transferir mensajes de correo electrónico a horas específicas. Los conectores pueden configurarse para estar siempre activos, para activarse sólo a horas específicas especí o para estar permanentemente desactivados, en cuyo caso el conector no transfiere mensajes hasta que se vuelve a modificar su programación. También puede configurar un conector como inicializado de forma remota, lo que indica que el conector no inicia inicia una conexión por sí mismo. En su lugar, espera un servidor remoto para conectarse y desencadenar la transferencia de mensajes. La programación del conector sólo afecta a la transferencia de mensajes. No afecta al enrutamiento de mensajes. El motor de enrutamiento enrutamiento considera a los conectores con cualquier tipo de programación como disponibles si están en STATE UP. Por lo tanto, los mensajes podrían incluso enrutarse a conectores para los que nunca se establece una programación de activación. Los cambios y el redireccionamiento no se producen en estos conectores. Los mensajes esperan en la cola del conector hasta que se modifica la programación de activación. Lo mismo sucede con los conectores inicializados. Los mensajes no se vuelven a redireccionar mientra mientras s esperan por su recuperación. Sugerencia: Si desea evitar el enrutamiento de mensajes a un conector, establezca su tamaño máximo de mensaje en 1 KB.

Propagación de estado de vínculos Para garantizar el enrutamiento de mensajes eficiente y confiable, los servidores de Exchange deben disponer de información actualizada en su tabla de estado de vínculos. Esta información debe reflejar de forma precisa el estado de todos los servidores cabeza de puente y conectores de mensajería. Para propagar la información de estado de vínculos a todos los servidores de la organización de Exchange, se usa un protocolo de propagación conocido como algoritmo de estado de vínculos (LSA). La propagación de estado de vínculos entre todos los servidores tiene las siguientes ventajas: •

Cada servidor de Exchange puede seleccionar la ruta óptima de mensajes en el origen, en lugar de enviar mensajes por una ruta en la que un conector no está disponible.

•

Los mensajes ya no van y vuelven de un servidor a otro porque cada servidor de d Exchange tiene información actualizada sobre si hay disponibles rutas alternativas o redundantes.

•

Ya no se producen bucles de mensajes.

219

Algoritmo de estado de vínculos La propagación de información de estado de vínculos varía dentro de los grupos de enrutamiento y de un grupo de enrutamiento a otro. Dentro de los grupos de enrutamiento, se presupone la existencia de una conexión TCP/IP confiable y los servidores se comunican entre sí a través de conexiones TCP/IP directas. No obstante, de un grupo de enrutamiento a otro, podría no ser posible establecer conexiones TCP/IP directas. De un grupo a otro, Exchange Server 2003 propaga la información de estado de vínculos mediante SMTP o X.400. Exchange Server 2003 propaga información de estado de vínculos tal como sigue: •

LSA dentro de grupos de enrutamiento Dentro de un grupo de enrutamiento, el maestro de grupo de enrutamiento realiza un seguimiento de la información de estado de vínculos y la propaga a los otros servidores del grupo de enrutamiento. Los otros servidores también se denominan nodos miembro o miembros de grupo de enrutamiento. Cuando se inicia un nodo miembro y ha inicializado su tabla de enrutamiento con información de Active Directory, establece una conexión TCP/IP al puerto 691. A continuación, realiza la autenticación con el maestro de grupo de enrutamiento y obtiene la información más reciente acerca el estado de todos los vínculos de la topología de enrutamiento. Todas las conexiones dentro de grupos de enrutamiento requieren autenticación en ambos sentidos. La conexión permanece de forma que el nodo maestro y el subordinado pueden comunicarse entre sí cada vez que se producen cambios en el estado de vínculos. Maestro y subordinado en un grupo de enrutamiento

Dentro de un grupo de enrutamiento, Exchange Server 2003 actualiza la información de estado de vínculos tal y como sigue: a. Cuando el motor de cola avanzada o el MTA de Exchange detecta un problema de un servidor cabeza de puente o un conector de grupo de enrutamiento, informa al motor de enrutamiento local, tal como se explicó en la sección "Redireccionamiento de mensajes basado en información de estado de vínculos", en Enrutamiento de mensajes de Exchange Server 2003. b. El motor de enrutamiento local, que actúa de proxy en caché entre el maestro de grupo de enrutamiento y el motor de cola avanzada o el MTA de Exchange, reenvía la información de estado de vínculos al maestro de grupo de enrutamiento mediante la conexión de estado de vínculos al puerto TCP 691.

220

c.

Cuando do se informa al maestro de grupo de enrutamiento de una actualización, éste sobrescribe la tabla de estado de vínculos con la nueva información. El maestro de grupo de enrutamiento crea un nuevo hash MD5 basado en esa información, lo inserta en la tabla de de estado de vínculos y, a continuación, propaga la nueva información a todos los servidores del grupo de enrutamiento. Tal y como se especificó anteriormente, la comunicación tiene lugar a través del puerto TCP 691. Nota: Un hash MD5 es un bloque criptográfico criptográfico de datos derivados de un mensaje por medio de un algoritmo hash que genera un hash de 128 bits a partir de una lista de bloques con 512 bits. El mismo mensaje produce siempre el mismo valor hash cuando el mensaje pasa por el mismo algoritmo de hash. Los mensajes que se diferencian incluso tan sólo en un carácter pueden producir valores hash muy distintos.

d. El maestro de grupo de enrutamiento envía toda la tabla de estado de vínculos (es decir, el paquete OrgInfo) a cada miembro de grupo de enrutamiento. enrutamiento. Cada miembro de grupo de enrutamiento compara el hash MD5 del nuevo paquete OrgInfo con el hash MD5 de su propia tabla de estado de vínculos y determina si el servidor local dispone de la información más actualizada. e. Si los valores de MD5 son distintos, distintos, el miembro de grupo de enrutamiento procesa el paquete OrgInfo. Una vez reemplazada la tabla de estado de vínculos en la memoria, el miembro de grupo de enrutamiento envía una respuesta breve al maestro de grupo de enrutamiento, que ahora también hace hace referencia al nuevo valor hash MD5. f.

El maestro de grupo de enrutamiento procesa esta información, descubre que se ha actualizado el miembro de grupo de enrutamiento y envía una breve confirmación a éste.

g. A partir de entonces, el miembro de grupo d de e enrutamiento sondea el maestro cada cinco minutos para que solicite información de enrutamiento actualizada. El nodo maestro y el nodo miembro comparan sus valores hash MD5 para determinar si se produjo algún cambio. Nota: Todos los servidores de un grupo grupo de enrutamiento deben comunicarse con el maestro del grupo de enrutamiento a través de una conexión TCP/IP. •

LSA entre grupos de enrutamiento La información de estado de vínculos se comunica de forma indirecta de un grupo de enrutamiento a otro por medio de servidores cabeza de puente y conectores para grupo de enrutamiento. Para enviar información de estado de vínculos a otro grupo de enruta enrutamiento, miento, el maestro de grupo de enrutamiento comunica la información de estado de vínculos en forma de paquete OrgInfo y lo envía al servidor cabeza de puente del grupo de enrutamiento a través del puerto TCP 691. A continuación, el servidor cabeza de puente puente reenvía esa información a todos los

221

servidores puente de otros grupos de enrutamiento a los que se conecta por medio de los diversos conectores para grupo de enrutamiento que aloja. Si la comunicación entre grupos de enrutamiento está basada en SMTP (es decir, Conector para grupo de enrutamiento o conector SMTP), la información de estado de vínculo se intercambia antes de la transferencia normal de mensajes mediante el comando SMTP ampliado (X (X-LINK2STATE) tal y como sigue: a. El servidor cabeza de puen puente te establece una conexión TCP/IP al servidor cabeza de puente de destino a través del puerto TCP 25. b. Los servidores cabeza de puente se autentican entre sí con el comando X-EXPS X GSS API. c.

Tras la conexión y la autenticación, se inicia la comunicación de estado de vínculos mediante el comando X X-LINK2STATE.

d. En primer lugar, los servidores cabeza de puente comparan sus hash MD5 para detectar cambios de la información de estado de vínculos. A continuación, el servidor cabeza de puente local usa el verbo DIGEST_QUERY para solicitar el hash MD5 al servidor cabeza de puente remoto. El verbo DIGEST_QUERY contiene el GUID de la organización de Exchange y el hash MD5 del servidor cabeza de puente local. e. El servidor cabeza de puente remoto compara entonces su su hash MD5 con el hash MD5 recibido a través del verbo DIGEST_QUERY. Si los hash son idénticos, el servidor cabeza de puente remoto envía un verbo DONE_RESPONSE para indicar que la tabla de estado de vínculos no requiere actualización. De lo contrario, el servidor cabeza de puente remoto envía el paquete OrgInfo completo. f.

Después de recibir el paquete OrgInfo, los servidores cabeza de puente remoto y local invierten las funciones y el servidor cabeza de puente local envía su propio paquete OrgInfo al servidor servidor cabeza de puente remoto. Ambos servidores cabeza de puente transfieren el paquete OrgInfo recibido a sus maestros de grupo de enrutamiento. El maestro de grupo de enrutamiento determina si se debe actualizar la tabla de estado de vínculos con la info información rmación del paquete OrgInfo. Un número de versión superior indica un paquete OrgInfo más reciente. Nota: Los maestros de grupo de enrutamiento nunca aceptan información acerca de su grupo de enrutamiento local procedente del maestro de un grupo de enrutamiento miento remoto.

g. Tras el intercambio de paquetes OrgInfo, el servidor cabeza de puente remoto inicia la transferencia de mensajes de correo electrónico o emite un comando Quit para finalizar la conexión SMTP. Para obtener detalles acerca de la comunicación SMTP entre servidores que ejecutan Exchange Server 2003, consulte Arquitectura de transporte SMTP.

222

Nota: o se vinculan grupos de enrutamiento mediante un conector X.400, se Cuando intercambia información de estado de vínculos entre los MTA como parte de la transmisión habitual de mensajes. Se envía un objeto binario, denominado paquete OrgInfo, en un mensaje del sistema sistema al MTA receptor antes de transferir los mensajes interpersonales. A continuación, el MTA receptor transfiere el paquete OrgInfo al motor de enrutamiento local, que comunica la transferencia al maestro de grupo de enrutamiento.

Ejemplo de LSA La figura siguiente muestra cómo funciona el algoritmo de estado de vínculos en una organización de Exchange que contiene varios grupos de enrutamiento. La figura muestra un entorno que contiene un servidor cabeza de puente no disponible en el grupo de enrutamiento E. Además, los servidores cabeza de puente de los otros grupos de enrutamiento no han recibido la información relativa al problema de enrutamiento. Organización con un servidor cabeza de puente no disponible antes de los cambios de estado de vínculos

Exchange Server 2003 detecta el problema de enrutamiento de la siguiente forma: 1. Un usuario del grupo de enrutamiento A envía un mensaje a un destinatario del grupo de enrutamiento E. 2. El motor de enrutamiento escoge la ruta que se muestra en la figur figura 5.9. Por lo tanto, el mensaje se transfiere al servidor cabeza de puente del grupo de enrutamiento B. 3. El servidor cabeza de puente del grupo de enrutamiento B intenta realizar una transferencia directa al servidor cabeza de puente del grupo de enrutam enrutamiento E. Puesto

223

que el servidor cabeza de puente remoto no está disponible, el intento falla. Tras tres intentos de conexión consecutivos, el servidor cabeza de puente local del conector para grupo de enrutamiento se marca como CONN_NOT_AVAIL. Puesto que no queda ningún servidor cabeza de puente en la configuración del conector, éste se marca como STATE DOWN. Primer conector no disponible

4. El servidor cabeza de puente del grupo de enrutamiento B se conecta a su maestro de grupo de enrutamiento a través del puerto TCP 691 y transmite la nueva información de estado de vínculos. El maestro incorpora la información en la tabla de estado de vínculos y notifica el cambio a todos los servidores del grupo de enrutamiento. 5. El cambio de estado de vínculos ocasiona un suceso de redireccionamiento en el grupo de enrutamiento B. Exchange Server 2003 puede seleccionar entre dos rutas con los mismos valores de costo. En este ejemplo, el mensaje se envía al grupo de enrutamiento C porque el motor de enrutamiento escoge esta ruta de transferencia aleatoriamente. 6. Antes de transferirse el mensaje, los servidores cabeza de puente del grupo de enrutamiento B y el grupo de enrutamiento C comparan sus hash MD5. Puesto que los hash MD5 no coinciden, los servidores intercambian información de estado de vínculos. El servidor cabeza de puente del grupo de enrutamiento B informa a los servidores cabeza de puente remotos adyacentes que quedan (grupos de enrutamiento A, C y D) acerca de los cambios de estado de vínculos. 7. El servidor cabeza de puente del grupo de enrutamiento C se conecta a su maestro de grupo de enrutamiento a través del puerto TCP 691 y transmite la nueva información de estado de vínculos. El maestro de grupo de enrutamiento incorpora la información en la

224

tabla de estado de vínculos y notifica el cambio a todos los servidores del grupo de enrutamiento. Todos los servidores de los grupos de enrutamiento B y C saben que el conector para grupo de enrutamiento entre el grupo de enrutamiento B y el grupo de enrutamiento E no está disponible. 8. El servidor cabeza de puente del grupo de enrutamiento C intenta realizar una transferencia directa al servidor cabeza de puente del grupo de enrutamiento E. Puesto que el servidor cabeza de puente remoto no está disponible, el intento de conexión falla. Tras tres intentos de conexión, el conector se marca como STATE DOWN. Segundo conector no disponible

9. El servidor cabeza de puente del grupo de enrutamiento C se conecta a su maestro de grupo de enrutamiento a través del puerto TCP 691 y transmite la nueva información de estado de vínculos. El maestro de grupo de enrutamiento incorpora la información en la tabla de estado de vínculos y notifica el cambio a todos los servidores del grupo de enrutamiento. 10. El cambio de estado de vínculos ocasiona un suceso de redireccionamiento en el grupo de enrutamiento C. El mensaje se envía ahora al grupo de enrutamiento D porque el motor de enrutamiento sigue viendo una ruta de transferencia disponible desde el grupo de enrutamiento D al grupo de enrutamiento E. El servidor cabeza de puente del grupo C informa a sus otros servidores cabeza de puente remotos adyacentes (grupos de enrutamiento A, B y D) de los cambios de estado de vínculos. 11. El mensaje se transfiere al grupo de enrutamiento D, pero antes de la transferencia del mensaje, los servidores cabeza de puente del grupo de enrutamiento B y C comparan sus hash MD5 e intercambian información de estado de vínculos.

225

12. El servidor cabeza de puente del grupo de enrutamiento D se conecta a su maestro de grupo de enrutamiento a través del puerto TCP 691 y transmite la nueva información de estado de vínculos. El maestro incorpora la información en la tabla de estado de vínculos y notifica el cambio a todos los servidores del grupo de enrutamiento. Todos los servidores del grupo de enrutamiento D saben que los conectores para grupo de enrutamiento entre los grupos de enrutamiento B y E y los grupos de enrutamiento C y E no están disponibles. 13. El servidor cabeza de puente del grupo de enrutamiento D intenta realizar una transferencia directa al servidor cabeza de puente del grupo de enrutamiento E, pero puesto que el servidor cabeza de puente remoto no está disponible, el intento de conexión falla. Tras tres intentos de conexión, el conector se marca como STATE DOWN. Tercer conector no disponible

14. El servidor cabeza de puente del grupo de enrutamiento D se conecta a su maestro de grupo de enrutamiento a través del puerto TCP 691 y transmite la nueva información de estado de vínculos. El maestro incorpora la información en la tabla de estado de vínculos y notifica el cambio a todos los servidores del grupo de enrutamiento. 15. El cambio de estado de vínculos ocasiona un suceso de redireccionamiento en el grupo de enrutamiento E. Puesto que no están disponibles rutas de transferencia adicionales para el grupo de enrutamiento E, el mensaje permanece en el grupo de enrutamiento D hasta que una ruta de transferencia esté disponible. El mensaje se transfiere al grupo de enrutamiento E tan pronto como está disponible el servidor cabeza de puente del grupo de enrutamiento E.

226

16. El servidor cabeza de puente del grupo de enrutamiento B informa a los servidores cabeza de puente remotos adyacentes que quedan (grupos de enrutamiento B y C) acerca de los cambios de estado de vínculos. Estos grupos de enrutamiento propagan entonces los cambios de estado de vínculos al grupo de enrutamiento A.

Cambios y propagación de estado de vínculos La tabla de estado de vínculos contiene información de versión para cada grupo de enrutamiento en forma de números de versión principales, secundarios y de usuario. Los cambios principales de versión tienen la mayor prioridad, seguidos de los cambios secundarios y los cambios de números de versión de usuario. Exchange Server 2003 detecta los cambios de estado de vínculos de la siguiente forma: •

Número de versión principal Los cambios principales son cambios físicos de la topología de enrutamiento. Por ejemplo, se crea un cambio principal cuando se agrega un conector nuevo al grupo de enrutamiento o cuando se cambia la configuración de un conector. Para recibir la notificación de cambios importantes en su grupo de enrutamiento de la topología de enrutamiento, el maestro de grupo de enrutamiento se registra en Active Directory para recibir notificaciones de cambios mediante DSAccess. El controlador de dominio de configuración envía esas notificaciones al servidor de Exchange conforme al proceso de notificación de cambios LDAP (Protocolo ligero de acceso a directorios) estándar. Cuando un maestro de grupo de enrutamiento recibe una actualización de la topología de enrutamiento desde el controlador de dominio de configuración, envía la información actualizada a todos los servidores miembro de su grupo de enrutamiento. También se lo notifica a todos los servidores cabeza de puente de grupos en enrutamiento remotos, tal y como se explicó anteriormente en la sección "Algoritmo de estado de vínculos". Para obtener más información acerca de la función de DSAccess y el controlador de dominio de configuración de Exchange 2003, consulte Exchange Server 2003 y Active Directory.

•

Número de versión secundario Los cambios secundarios son los que se realizan en la información de estado de vínculos, por ejemplo, que un conector cambie de STATE UP a STATE DOWN. No obstante, las conexiones de red no confiables podrían provocar una situación en la que los conectores se marcan como activos e inactivos, lo que provoca actualizaciones de estado de vínculos en toda la organización de Exchange. Podría producirse un aumento considerable de la carga de procesamiento debido a los restablecimientos de ruta adicionales y al redireccionamiento de mensajes. De forma predeterminada, Exchange Server 2003 mitiga los conectores oscilantes mediante el retraso de los cambios de estado de vínculos durante un período de diez minutos. Durante este período, los cambios que se producen se consolidan y se replican en toda la organización en un solo lote. No obstante, una conexión oscilante todavía puede generar tráfico de estado de vínculos si se producen cambios durante períodos largos de tiempo.

227

Puede aumentar o disminuir el intervalo de actualización mediante el siguiente parámetro del Registro. Ubicación

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSe t\Services\RESvc\Parameters\

Valor

StateChangeDelay

Tipo

REG_DWORD

Información del valor

Intervalo en segundos entre actualizaciones de estado de vínculos. El valor predeterminado es 10 minutos. El valor máximo es 7 días. Puede resultar útil establecer este parámetro en 0 durante la resolución de errores de conexión. De este modo, los errores se reflejan inmediatamente en los estados de conector.

También puede impedir que el maestro de grupo de enrutamiento marque sus conectores como no disponibles si define la siguiente clave del Registro. Esto puede resultar especialmente útil en los escenarios de enrutamiento radial, en los que cada destino sólo se puede alcanzar a través de un solo conector. No se puede llevar a cabo el redireccionamiento de los mensajes si no están disponibles conectores alternativos. Ubicación

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSe t\Services\RESvc\Parameters\

•

Valor

SuppressStateChanges

Tipo

REG_DWORD

Información del valor

El valor 0x1 deshabilita los cambios de estado de vínculos.

Número de versión de usuario Las actualizaciones de usuario incluyen cambios mínimos, como cuando el maestro del grupo de enrutamiento ha cambiado, cuando se han iniciado o detenido servicios en un servidor de Exchange, cuando se ha agregado otro servidor al grupo de enrutamiento o cuando un servidor miembro pierde su conexión con el maestro del grupo de enrutamiento.

Cambio del maestro de grupo de enrutamiento El primer servidor que se instaló en el grupo de enrutamiento se designa automáticamente como maestro del grupo de enrutamiento. Si se produce un error en este servidor o se

228

desconecta, la información de estado de vínculos dej deja a de propagarse en el grupo de enrutamiento. Todos los servidores del grupo de enrutamiento siguen funcionando con la información anterior. Cuando vuelve a estar disponible el maestro de grupo de enrutamiento, éste reconstruye su información de estado de vvínculos. ínculos. El maestro del grupo de enrutamiento empieza por todos los servidores y conectores que están marcados como no disponibles. A continuación, detecta todos los servidores que no están disponibles y actualiza los miembros del grupo de enrutamiento. Si desconecta un maestro de grupo de enrutamiento durante un período largo de tiempo, deberá nominar otro maestro de grupo de enrutamiento para impedir el enrutamiento de mensajes ineficiente. En el Administrador del sistema de Exchange, expanda el grupo de d enrutamiento deseado y seleccione el contenedor Miembros.. En el panel de detalles, haga clic con el botón secundario del mouse (ratón) en el servidor que desea promover a maestro del grupo de enrutamiento y, a continuación, seleccione Configurar como maestro. mae Nota: El cambio de maestro de grupo de enrutamiento representa un cambio de estado de vínculos importante. En un cambio de este tipo, la información de estado de vínculos se propaga por la organización y todos los servidores de Exchange deben volver volve a enrutar sus mensajes. Por lo tanto, no cambie el maestro del grupo de enrutamiento con frecuencia.

Conflictos entre maestros de grupo de enrutamiento En un grupo de enrutamiento, sólo se reconoce un servidor como maestro del grupo de enrutamiento. Se exige xige esta configuración mediante un algoritmo donde ((N/2) +1 servidores del grupo de enrutamiento deben aceptar y reconocer al maestro. N indica el número de servidores del grupo de enrutamiento. Por consiguiente, los nodos miembro envían datos ATTACH de estado stado de vínculos al maestro. En ocasiones, dos o más servidores confunden al maestro del grupo de enrutamiento con un servidor que no lo es. Por ejemplo, si se mueve o elimina un maestro de grupo de enrutamiento sin escoger otro maestro de grupo de enruta enrutamiento, msExchRoutingMasterDN el atributo de Active Directory que designa al maestro del grupo msExchRoutingMasterDN, de enrutamiento, podría señalar un servidor eliminado porque no se ha vinculado el atributo. Esta situación también puede producirse cuando un maestro de grupo de enrutamiento antiguo no se desconecta como maestro o cuando un maestro de grupo de enrutamiento sigue enviando información ATTACH de estado de vínculos a un maestro de grupo de enrutamiento antiguo. En Exchange 2003, si msExchRoutingMasterDN señala a un objeto eliminado, el maestro de grupo de enrutamiento renuncia a su función de maestro e inicia un cierre de dicha función. Lleve a cabo los pasos siguientes para resolver este problema:

229

•

Compruebe si se está propagando correctamente el estado de vínculos dentro del grupo de enrutamiento en el puerto 691. Compruebe que no haya un servidor de seguridad o un filtro SMTP bloqueando la comunicación.

•

Compruebe que ningún servicio de Exchange esté detenido.

•

Compruebe si se están produciendo latencias de replicación en Active Directory mediante la herramienta Monitor de réplica de Active Directory (Replmon.exe), que se incluye en Microsoft Windows Server 2003.

•

Compruebe si hay problemas y latencias de comunicación en la red.

•

Compruebe si hay maestros de grupo de enrutamiento eliminados o servidores que ya no existan. En estas instancias, se registra un suceso de transporte 958 en el registro de aplicaciones del Visor de sucesos. Este suceso indica que ya no existe un maestro de grupo de enrutamiento. Compruebe esta información mediante una herramienta de acceso a directorios, como LDP (ldp.exe) o ADSI Edit (adsiEdit.msc). Estas aplicaciones están incluidas en las herramientas de soporte técnico de Windows Server 2003.

Compatibilidad con Exchange Server 5.5 Exchange Server 5.5 utiliza una Tabla de enrutamiento de direcciones de la puerta de enlace (GWART) para seleccionar rutas dentro de una organización de Exchange. Este método utiliza un algoritmo de enrutamiento por vector de distancia que puede dar lugar a bucles de enrutamiento en determinadas situaciones. No obstante, Exchange Server 2003 usa una tabla de estado de vínculos que está almacenada en la memoria, junto con el algoritmo de ruta más corta de Dijkstra, para seleccionar rutas. Sin embargo, para mantener la compatibilidad con versiones anteriores, Exchange 2003 debe generar una GWART, de forma que los servidores de Exchange 5.5 puedan usar conectores de Exchange 2003. Además, el motor de enrutamiento debe incluir conectores de Exchange 5.5 existentes en la tabla de estado de vínculos para que los servidores de Exchange Server 2003 puedan usar estas rutas de transferencia.

Generación de la GWART El MTA de Exchange genera la GWART. El MTA de Exchange se comunica con el motor de enrutamiento a través del empaquetador de la interfaz de enrutamiento, MTARoute.dll, para obtener información de enrutamiento. A continuación, escribe esta información en el atributo gatewayRoutingTree de un objeto denominado GWART heredada, que reside en el grupo administrativo del servidor de Exchange. El MTA también actualiza el atributo GWARTLastModified para indicar los cambios más recientes. El Servicio de replicación de sitios (SRS) replica el objeto GWART al directorio de Exchange 5.5. A continuación, los servidores de Exchange 5.5 pueden incluir conectores de Exchange Server 2003 en sus decisiones de enrutamiento.

230

Problemas de enrutamiento en modo mixto El Servicio de replicación de sitios también replica información de conectores de Exchange Server 5.5 a Active Directory. Por lo tanto, los servidores que ejecutan Exchange Server 2003 pueden enrutar mensajes por conectores de Exchange Server 5.5. Esto permite a los usuarios de Exchange Server 2003 enviar mensajes mediante cualquier conector existente, como los conectores que no están disponibles en Exchange Server 2003. Esto incluye conectores como el Conector de Microsoft Mail para redes de PC. La funcionalidad de los grupos de enrutamiento en un entorno en modo mixto, en el que algunos servidores ejecutan Exchange Server 2003 o Exchange 2000, mientras que otros servidores ejecutan Exchange Server 5.5, está limitada tal y como sigue: •

Los grupos de enrutamiento no pueden abarcar varios grupos administrativos. Esto se debe a que la topología de enrutamiento de Exchange Server 5.5 está definida por sitios. Los sitios de Exchange Server 5.5 proporcionan la funcionalidad tanto del grupo administrativo como del grupo de enrutamiento en Exchange Server 2003. Esta diferencia en la topología de enrutamiento limita la funcionalidad de los grupos de enrutamiento en un entorno en modo mixto.

•

No se pueden mover servidores entre grupos de enrutamiento que se encuentren en grupos administrativos diferentes.

•

Los conectores de Exchange Server 5.5 con un ámbito local están disponibles para todos los usuarios de Exchange 2003 de la organización, puesto que este ámbito de conectores no un equivalente en Exchange Server 2003. En Exchange Server 5.5, puede especificar la disponibilidad de los conectores en tres niveles distintos: organización, sitio y ubicación de servidor. En Exchange Server 2003, sólo están disponibles los ámbitos de organización y de grupo de enrutamiento (sitio).

Actualizaciones de la topología Puesto que los servidores de Exchange Server 5.5 no usan una tabla de estado de vínculos, los grupos de enrutamiento con un maestro de grupo de enrutamiento que ejecuta Exchange Server 5.5 (es decir, sitios sin un servidor con Exchange Server 2003) no envían actualizaciones de la topología. Para solucionar este problema, los maestros de grupo de enrutamiento obtienen periódicamente la topología de grupos de enrutamiento para todos los grupos de enrutamiento controlados por Exchange Server 5.5 de Active Directory y, a continuación, replican esta información en toda la topología de enrutamiento de Exchange Server 2003. Puede configurar la siguiente clave del Registro en un maestro de grupo de enrutamiento para determinar cuándo lee información de topología de Active Directory el motor de enrutamiento. Ubicación

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSe t\Services\RESvc\Parameters\

231

Valor

ReloadOsInterval

Tipo

REG_DWORD

Información del valor

Intervalo transcurrido en segundos entre la recarga de información de topología de Active Directory.

Propagación de estado de vínculos rotos Los servidores que ejecutan Exchange 2003 no esperan que los servidores de Exchange 5.5 intercambien con ellos información de estado de vínculos. No obstante, cuando a un servidor cabeza de puente que ejecuta Exchange 5.5 en un grupo de enrutamiento de Exchange lo sustituye un servidor que ejecuta Exchange 2003 y se designa como servidor cabeza de puente, el grupo de enrutamiento empieza a participar en la propagación de la información de estado de vínculos. Deja de tener el número de versión principal cero. Un número de versión principal cero indica un servidor que no participa en la información de estado de vínculos o que no intercambia este tipo de información. Todos los servidores de Exchange 5.5 tienen un número de versión cero porque no intercambian información de estado de vínculos. Cuando un grupo de enrutamiento propaga información de estado de vínculos, aumenta su número de versión principal. Los servidores cabeza de puente de otros grupos de enrutamiento esperan recibir cambios de estado de vínculos de este grupo de enrutamiento. No obstante, si usted revierte el servidor cabeza de puente a Exchange Server 5.5, se produce un problema, porque el servidor cabeza de puente no tiene ninguna tabla de estado de vínculos. Otros servidores siguen esperando que el servidor cabeza de puente que ejecuta Exchange Server 5.5 (el servidor cabeza de puente que anteriormente ejecutaba Exchange Server 2003) participe en la propagación de estado de vínculos. Por lo tanto, otros servidores esperan a que este servidor les proporcione información de estado de vínculos actualizada. Cuando sucede esto, el grupo de enrutamiento se aísla y no participa en las actualizaciones dinámicas de estado de vínculos que se producen en la organización. La figura siguiente ilustra una situación en la que este grupo de enrutamiento aislado puede ser problemático. En concreto, dado que el servidor cabeza de puente de Exchange 5.5 del grupo de enrutamiento de Exchange 5.5 era antes un servidor cabeza de puente de Exchange 2000 o Exchange 2003, los restantes servidores esperan que participe en la propagación del estado de los vínculos. En la figura 5.13, el conector para correo de Internet de Exchange 5.5 y el conector SMTP de Exchange 2003 utilizan ambos un único host inteligente para enrutar el correo a Internet. El host inteligente deja de estar disponible. Por lo tanto, el servidor cabeza de puente que ejecuta Exchange Server 2003 marca la ruta a través de su conector SMTP como no disponible. Sin embargo, puesto que el servidor cabeza de puente espera que el servidor de Exchange 5.5 envíe información de estado de vínculos sobre sus grupos de enrutamiento y sus conectores, presupone que está disponible

232

la ruta a través del conector para correo de Internet e intenta entregar mensajes a través de ella. Después de un error, el servidor que ejecuta Exchange 2003 detecta un posible bucle y no intenta entregar correo a través de esta ruta. Servidores que ejecutan Exchange 5.5 y Exchange 2003 conectándose a un host inteligente

La propagación de estado de vínculos también se puede interrumpir si se agrega al sistema un servidor de seguridad que la bloquee. Por ejemplo, los puertos 25 y 691 son obligatorios dentro de un grupo de enrutamiento y el puerto 25 es obligatorio entre los grupos de enrutamiento. Además, ningún servidor de seguridad debe bloquear el comando XLINK2STATE del Protocolo simple de transferencia de correo extendido (ESMTP). Para resolver este problema, están disponibles las siguientes soluciones: •

Actualizar el servidor cabeza de puente de Exchange 5.5 a un servidor de Exchange 2000 o Exchange 2003, o utilizar otro servidor de Exchange 2000 o Exchange 2003 para enviar de nuevo la información de estado de los vínculos para este grupo de enrutamiento. Cualquiera de estas opciones constituye la solución más simple y preferida.

•

Para restablecer los grupos de enrutamiento no conectados al número de versión principal 0 del vínculo, cierre todos los servidores de Exchange de la organización simultáneamente y reinícielos.

•

Configure el servidor de seguridad para que no se impida la propagación de estado de los vínculos.

Para obtener más información acerca de los grupos de enrutamiento aislados o disjuntos, consulte el artículo 842026 de Microsoft Knowledge Base, "Routing status information is not propagated correctly to all servers in Exchange 2000 Server or in Exchange Server 2003".

Arquitectura de transporte SMTP El subsistema de transporte de Microsoft Exchange Server 2003 es una colección de motores basados en COM (Modelo de objetos componentes) que se integran a la perfección con el servicio SMTP (Protocolo simple de transferencia de correo) de Microsoft Windows 2000 Server y Microsoft Windows Server 2003. Puesto que Exchange Server 2003

233

debe ampliar el servicio SMTP de Windows con sus propios componentes, sólo puede ejecutar el programa de instalación de Exchange Server 2003 en un equipo que ejecute Windows Server 2003 con el servicio SMTP instalado. Es importante tener en cuenta que los componentes de Exchange, como el motor de cola avanzada, el categorizador y el motor de enrutamiento, no sólo amplían el servicio SMTP, sino que también reemplazan componentes SMTP por componentes específicos de Exchange. La versión ampliada del servicio SMTP es compatible con: •

Comandos SMTP ampliados para la comunicación eficaz entre servidores de Exchange

•

La integración con el servicio de directorio Microsoft Active Directory para la categorización y el enrutamiento de mensajes

•

La integración con el almacén de Exchange para la entrega local

•

El seguimiento de mensajes para analizar rutas de mensajes en la organización de Exchange

En esta sección se explican los siguientes conceptos: •

Diseño del servicio SMTP El servicio SMTP se ejecuta en el proceso Inetinfo y cuando se amplía mediante receptores de sucesos de Exchange, procesa todos los mensajes entrantes y salientes. Cuando los mensajes pasan por el subsistema de transporte, SMTP utiliza intensivamente recursos de Servicios de Internet Information Server (IIS). Debe comprender el diseño del servicio SMTP para poder comprender el funcionamiento de todo el subsistema de transporte de Exchange 2003.

•

Motor de cola avanzada El motor de cola avanzada es un componente central del subsistema de transporte SMTP y el principal distribuidor de sucesos de transporte. Debe comprender las tareas del motor de cola avanzada para entender la interacción entre los componentes de transporte SMTP centrales y las extensiones de receptores de sucesos de Exchange.

•

Componentes de transporte Estos componentes procesan cada mensaje tras su recepción desde un host remoto o un cliente de mensajería. En Exchange Server 2003, todos los mensajes deben pasar por el subsistema de transporte SMTP. Esto incluye los mensajes enviados a través de clientes MAPI, como Microsoft Office Outlook 2003, Microsoft Office Outlook Web Access, el protocolo Creación y control de versiones distribuidas (DAV), X.400 y cualquier conector del Kit de desarrollo de Exchange (EDK), incluso si no participa el protocolo SMTP y si los destinatarios tienen sus buzones en el mismo almacén de buzones que el remitente. Si detiene el servicio SMTP en un servidor que ejecuta Exchange Server 2003, se detiene toda la transferencia y entrega de mensajes en ese servidor. Debe comprender el tratamiento de mensajes por parte de Exchange Server 2003 para comprender cómo procesan cada mensaje los receptores de sucesos de transporte.

•

Controladores del almacén Exchange Server 2003 implementa un controlador del almacén de Exchange para que el servicio SMTP pueda obtener mensajes salientes del almacén de Exchange y entregar mensajes entrantes a destinatarios de Exchange. Debe

234

conocer la implementación del controlador del almacén para identificar la ubicación física de los mensajes a medida que pasan por el subsistema de transporte. •

Extensiones de protocolo Las extensiones de protocolo implementan comandos de protocolo SMTP específicos de Exchange, también denominados verbos SMTP ampliados. Para comprender las características de protocolo SMTP específicas, debe comprender cómo se implementan las ampliaciones del protocolo.

•

Registro y seguimiento de mensajes El registro de protocolos, el registro de sucesos y el seguimiento de mensajes son características que puede usar para analizar los detalles de la transferencia de mensajes. Debe conocer la implementación de estas características, especialmente en situaciones de resolución de problemas.

Esta sección presupone que está familiarizado con el concepto general de tratamiento de mensajes de Exchange Server 2003. Para obtener más información acerca del tratamiento de mensajes, consulte Arquitectura de enrutamiento de mensajes. En esta sección también se presupone que está familiarizado con los conceptos de configuración de servidores SMTP virtuales, conectores para SMTP y conectores para grupo de enrutamiento. Para obtener información acerca de estos conceptos, consulte Exchange Server 2003 Transport and Routing Guide.

Diseño del servicio SMTP El motor de protocolo SMTP básico se implementa en SMTPSvc.dll, que reside en el directorio \WINDOWS\system32\inetsrv. Este motor de protocolo se ejecuta como código sin administrar en el proceso Inetinfo de IIS y trata las conexiones SMTP entrantes y salientes en el nivel de sesión. La figura siguiente muestra que el servicio SMTP está ubicado en los niveles Sesión, Presentación y Aplicación según el modelo OSI (Interconexión de sistemas abiertos) de la ISO (International Organization for Standardization).

235

Proceso Inetinfo y servicio SMTP en el modelo mod OSI

Nota: El código no administrado hace referencia al código que ejecuta directamente el sistema operativo, fuera de Common Language Runtime (CLR) de .NET Framework de Microsoft. El código no administrado proporciona su propia administración de memoria, emoria, el control de tipos y el soporte técnico de seguridad. El código administrado recibe estos servicios de Common Language Runtime.

Integración con los Servicios de Internet Information Server (IIS) El hecho de que el servicio SMTP se ejecute en el pr proceso oceso Inetinfo indica que el subsistema de transporte de Exchange Server 2003 comparte recursos IIS con otros servicios que también se ejecutan en IIS, como el servicio Protocolo de oficina de correo versión 3 (POP3), el servicio Protocolo de acceso a correo correo de Internet (IMAP4) y el servicio Motor de enrutamiento de Exchange (RESvc). Inetinfo.exe es el proceso central de IIS y el servicio Administración de IIS controla Inetinfo.exe. Esto se explica en Dependencias de los servicios de Exchange Server 2003 2003.

236

Ejecución de subprocesos asincrónica Uno de los recursos más importantes que comparte el servicio SMTP con todos los otros servicios en el proceso roceso Inetinfo es la Cola de subprocesos asincrónica (ATQ). Se trata de un conjunto de subprocesos que usa IIS para tratar todas las solicitudes de conexión de red entrantes. Los subprocesos son instancias de ejecución de código dentro de un proceso. Los procesos constan de un espacio de direcciones virtual, un contexto de procesador y, como mínimo, de un subproceso. Los subprocesos se crean mediante el método CreateThread() del sistema operativo y se ejecutan dentro del espacio de direcciones virtual del proceso que llama (es decir, el proceso Inetinfo de IIS). En el procesamiento asincrónico, cada subproceso se ejecuta en el proceso Inetinfo sin esperar a que otros subprocesos finalicen su procesamiento. En el procesamiento sincrónico, los subprocesos se ejecutan uno después de otro de forma sincronizada (la ejecución de código se bloquea en la llamada de función hasta que finaliza la función). Para sincronizar subprocesos asincrónicos (por ejemplo, para evitar conflictos debido al acceso simultáneo a un recurso concreto), el sistema operativo proporciona objetos de sincronización. Un ejemplo de objeto de sincronización para un recurso específico sería un objeto de suceso para un socket de Windows. El servicio SMTP usa objetos de suceso para recibir notificaciones caciones de conexiones SMTP entrantes. Los sockets de Windows son direcciones IP combinadas con números de puerto. El puerto predeterminado que permite llegar al motor del protocolo SMTP es el puerto TCP 25. Combinado con la dirección IP del servidor de Exchange change que ejecuta el servicio SMTP, este número de puerto forma el socket del servidor virtual SMTP predeterminado; por ejemplo, 192.168.1.100:25. 192.168.1.100:25. Nota: En un servidor de Exchange, sólo existe el servidor virtual SMTP predeterminado. El servidor virtual SMTP predeterminado acepta conexiones entrantes en el puerto TCP 25 para todas las direcciones IP del servidor. Puede modificar la configuración en el Administrador del sistema de Exchange, desde la ficha General, General en las propiedades del Servidor virtual SMTP predeterminado predeterminado.

Tratamiento de conexiones SMTP entrantes El proceso Inetinfo trata las conexiones SMTP entrantes tal y como sigue: 1. Cuando se inicia el servicio SMTP, el proceso Inetinfo inicializa el socket del servidor virtual SMTP en TCP/IP para escuchar si hay solicitudes de conexión entrantes. Para poder admitir varias conexiones simultáneas a través del mismo servidor virtual, se inicializa el socket en modo de no bloqueo para operaciones de E/S superpuestas. De forma predeterminada, erminada, el servidor virtual SMTP puede aceptar un número prácticamente ilimitado de conexiones de red entrantes (aunque el límite físico real es alrededor de 5000).

237

Nota: En Microsoft Windows Server 2003, el servidor sólo puede tratar unas 2.000 conexiones ones simultáneas. En Windows Server 2003 Service Pack 1, el valor se incrementa de 2.000 a 5.000 y puede aumentarse cada vez más a través de una opción de configuración de la metabase. 2. El proceso Inetinfo crea un objeto de sincronización para informar al al sistema operativo de que está interesado en recibir una notificación de suceso de red para conexiones entrantes a través del socket. ATQ está asociada a este objeto de sincronización de forma que puede notificarse un subproceso del conjunto de subprocesos subproceso cuando el objeto de sincronización indica la llegada de una conexión de red. 3. La pila de transporte TCP/IP recibe una conexión SMTP entrante y indica este suceso al proceso Inetinfo. Ahora puede ejecutarse un subproceso de ATQ para leer información del socket SMTP. Nota: El proceso Inetinfo puede crear subprocesos adicionales en ATQ para garantizar la disponibilidad de subprocesos suficientes para escuchar si hay solicitudes de conexión entrantes. Para ajustar el rendimiento de IIS, puede especificar el número máximo de subprocesos que se pueden crear en el sistema a través del siguiente iguiente parámetro del Registro. Ubicación

HKEY_LOCAL_MACHINE\SYSTEM SYSTEM\CurrentControlSe t\Services\InetInfo\ \Parameters

Valor

PoolThreadLimit

Tipo

REG_DWORD

Información del valor

0 - 4,294,967,295 (unlimited)

Descripción

PoolThreadLimit es un límite codificado que incluye todos los subprocesos del grupo IIS.

4. El subproceso IIS ejecuta el código en SMTPSvc.dll y responde a la solicitud de cliente entrante con un saludo del servidor, denominado titular SMTP, como por ejemplo: 220 server01.TailspinToys.com Microsoft ESMTP MAIL Service, Version: 6.0.3790.0 ready at Sun, 21 Mar 2004 23:48:47 +0100 +0100. 5. La conversación SMTP avanza a medida que el host SMTP transfiere el mensaje. Cada vez que se recibe un comando SMTP, un subproceso de ATQ ejecuta el código de protocolo SMTP en SMTPSvc.dll y desencadena sucesos en el servicio servicio SMTP que hacen que se ejecute código en otras DLL. Por ejemplo, el controlador del almacén NTFS escribe el mensaje en forma de archivo en la carpeta \Queue Queue del servidor SMTP virtual del sistema de archivos.

238

6. Una vez procesado el comando SMTP actua actual,l, el proceso Inetinfo vuelve a colocar el subproceso que se usó para realizar el procesamiento SMTP en ATQ para escuchar comandos entrantes nuevos o nuevas solicitudes de conexión. IIS reutiliza subprocesos existentes para evitar la carga de trabajo de cr crear ear un nuevo subproceso cada vez que se recibe un nuevo comando o una nueva solicitud de conexión. 7. El host remoto emite un comando Quit y el servicio SMTP libera la conexión. Nota: El período de vida (TTL) de subprocesos inactivos en ATQ es de 24 horas. El proceso Inetinfo tiene como mínimo dos subprocesos en ATQ en todo momento para responder a solicitudes de conexión entrantes.

Limitación del número de subprocesos SMTP De forma predeterminada, el servicio SMTP puede usar hasta un 90% de los subprocesos subproc disponibles en ATQ. Puesto que este conjunto de subprocesos se comparte con otros servicios IIS que también podrían ejecutarse en el mismo servidor, como los servicios FTP (Protocolo de transferencia de archivos), POP3, RESvc e IMAP4, una carga SMTP elevada e puede crear un cuello de botella de rendimiento en el proceso Inetinfo. Esto puede hacer que se produzca un error en el servicio FTP, POP3, RESvc o IMAP4. Para evitar esta situación, puede reservar un número apropiado de subprocesos para otros servicios icios IIS mediante la limitación del porcentaje de subprocesos que puede usar el servicio SMTP. Esto se consigue por medio del siguiente parámetro del Registro. Ubicación

HKEY_LOCAL_MACHINE\System System\CurrentControlSe t\Services\SMTPSVC\Queuing Queuing

Valor

MaxPercentPoolThreads

Tipo

REG_DWORD

Información del valor

El valor predeterminado es 0x5A (90%)

Descripción

Limita el porcentaje de subprocesos ATQ que puede usar el servicio SMTP. El valor recomendado es: MaxPercentPoolThreads = 90/(2*número

de

instancias de servidor virtual SMTP) También puede incrementar el número total de subprocesos del proceso Inetinfo por medio del siguiente parámetro del Registro si hay suficiente memoria disponible para los subprocesos adicionales.

239

Ubicación

HKEY_LOCAL_MACHINE\Syste System\CurrentControlSe t\Services\SMTPSVC\Queuing Queuing

Valor

AdditionalPoolThreadsPerProc

Tipo

REG_DWORD

Información del valor

El valor predeterminado es 0x5A (90%)

Descripción

Determina los subprocesos de conjunto adicionales por procesador que crea el proceso Inetinfo cuando se inicia el servicio SMTP. El valor recomendado es: AdditionalPoolThreadsPerProc = ((9/(MaxPercentPoolThreads/100)) ((9/(MaxPercentPoolThreads/100))–4)/2

Nota: Si el valor de AdditionalPoolThreadsPerProc es superior a 200, deberá aumentar el valor del parámetro PoolThreadLimit PoolThre en HKEY_LOCAL_MACHINE\ HKEY_LOCAL_MACHINE System\CurrentControlSet CurrentControlSet\Service s\InetInfo\Parameters Parameters\. Establezca PoolThreadLimit por lo menos en el mismo valor que AdditionalPoolThreadsPerProc.

Extensiones SMTP basadas en el modelo de objetos componentes El protocolo SMTP MTP admite el envío de varios mensajes durante una sola sesión. El envío o retransmisión de un mensaje puede continuar mientras se transmite el siguiente mensaje. El indicador de "final de datos de correo" SMTP (es decir, un retorno de carro y un avance de línea seguidos por un punto, seguido a su vez de otro retorno de carro y avance de línea) o el fragmento BDAT final de cada mensaje individual informa al servicio SMTP receptor de que debe procesar los destinatarios y los datos de ese mensaje concreto. Este Es procesamiento se denomina procesamiento de transporte porque entrega el mensaje al almacén local de Exchange o lo reenvía al servidor principal del destinatario si el buzón del destinatario no reside en el servidor local. El servicio SMTP también puede retransmitir mensajes a destinatarios externos. Por ejemplo, la retransmisión de mensajes se lleva a cabo cuando los usuarios de Exchange que trabajan con clientes de Internet envían mensajes a destinatarios externos.

240

Una vez recibido un mensaje a través de SMTP, se pasa al motor de cola avanzada (Phatq.dll). A continuación, el subproceso que usa el servicio SMTP para pasar el mensaje al motor de cola avanzada se devuelve a ATQ. El motor de cola avanzada usa su propio conjunto de subprocesos para procesar mensajes en cola. El conjunto de subprocesos es independiente del conjunto de subprocesos utilizado para tratar las operaciones de protocolo SMTP. En El motor de cola avanzada, encontrará información adicional acerca del motor de cola avanzada.

Sucesos del subsistema de transporte SMTP Cuando los subprocesos ejecutan el código de protocolo de Smtpsvc.dll o el código de transporte de Phatq.dll, desencadenan sucesos que hacen que se ejecute el código de otros archivos DLL. Esta arquitectura de sucesos está basada totalmente en COM. SMTP usa la biblioteca COM de objetos de extensiones de servidor de Microsoft (Seo.dll) para desencadenar sucesos SMTP y usa la activación COM para crear instancias de los receptores de sucesos que se registran para cada suceso concreto. Los sucesos SMTP pueden indicar la transmisión o la llegada de un comando de protocolo SMTP o el envío de un mensaje al subsistema de transporte SMTP, entre otras cosas. Los receptores de sucesos, como las extensiones de protocolo SMTP, el categorizador y el motor de enrutamiento, se registran para sucesos específicos en el servicio SMTP. En el subsistema de transporte SMTP de Exchange 2003 pueden producirse los siguientes tipos de sucesos: •

Sucesos de protocolo SMTP Estos sucesos son específicos de SMTP y permiten a los receptores de sucesos modificar el comportamiento del motor de protocolo SMTP mediante la modificación, la deshabilitación o la adición de comandos entrantes y salientes junto con respuestas a estos comandos. Por ejemplo, el receptor de sucesos de protocolo X-LSA Sink de Exchange Server 2003 implementa un comando SMTP adicional (X-LINK2STATE) para transmitir información de estado de vínculos a grupos de enrutamiento, tal y como se explicó en Arquitectura de enrutamiento de mensajes. Los receptores de sucesos de protocolo también pueden utilizarse para modificar comandos SMTP y ESMTP estándar, como EHLO, con el fin de ampliar las capacidades del protocolo SMTP. Los receptores de sucesos de protocolo se explican en Extensiones del protocolo SMTP.

•

Sucesos de almacén SMTP Estos sucesos permiten que los receptores de sucesos de almacén (es decir, las implementaciones de controladores de almacén) mantengan el contenido de los mensajes en directorios del sistema de archivos o en el almacén de Exchange. Por ejemplo, en el subsistema de transporte de Exchange Server 2003, los sucesos de almacén sirven para llevar a cabo la entrega local a destinatarios de Exchange. Los controladores de almacén se tratan en Controladores de almacén del servicio SMTP.

•

Sucesos de transporte SMTP Estos sucesos se producen cuando los mensajes llegan al servidor, fluyen por el subsistema de transporte básico y se entregan a destinatarios

241

de Exchange o se retransmiten a otros host SMTP. En Exchange Server 2003, los sucesos de transporte sirven para llevar a cabo la categorización y el enrutamiento de mensajes. El motor de enrutamiento se trata en Arquitectura de enrutamiento de mensajes.. Los receptores de sucesos de categorizador se explican en ºComponentes del transporte SMTP SMTP. •

Sucesos del sistema SMTP Estos sucesos se convierten en llamadas a un receptor que actúa como componente del sistema. Por ejemplo, el receptor Eventlog SMTP es un componente del sistema que registra sucesos del sistema para escribir información de procesamiento interno en el re registro de sucesos de aplicación.

Receptores de sucesos del servicio SMTP

Nota: Los receptores de sucesos SMTP permiten a los proveedores distintos de Microsoft implementar extensiones personalizadas en el subsistema de transporte SMTP, como filtros de e mensajes y detectores de virus. Los receptores de sucesos SMTP no son compatibles con las aplicaciones COM+.

El distribuidor y las notificaciones de sucesos Cuando se produce un suceso, un subproceso del servicio SMTP, que actúa como distribuidor de sucesos, sos, comprueba los registros de sucesos (almacenados como enlaces de sucesos en la metabase de IIS) para determinar si hay algún receptor asociado al suceso. El distribuidor de sucesos determina todos los receptores de sucesos que están registrados para ejecutarse ecutarse y cuándo debe ejecutarlos. El orden depende de la prioridad del receptor, tal y como se especifica en la información de enlaces de sucesos. Los receptores reciben la notificación de un suceso por orden. Los receptores con la prioridad más baja se ejecutan primero.

242

Para cada receptor, se produce el siguiente proceso: 1. El distribuidor de sucesos compara el registro de sucesos del receptor con las condiciones de sucesos. Si se cumplen las condiciones, se ejecuta el receptor. Nota: Algunos sucesos sos SMTP, como los sucesos de almacén, no tienen condiciones de sucesos. 2. En caso necesario, el distribuidor de sucesos crea una instancia del receptor mediante el Id. de clase (CLSID) de la clase COM del receptor de sucesos. Nota: Los receptores pueden pueden almacenarse en caché para evitar este paso en sucesos posteriores. 3. El distribuidor de sucesos llama al método IUnknown::QueryInterface de COM para obtener la interfaz de notificación de sucesos adecuada del receptor de sucesos. La mayoría de los receptores ptores usan Active Template Library (ATL) para implementar la interfaz de receptor. 4. El distribuidor de sucesos ejecuta el receptor llamando al método de sucesos correspondiente de la interfaz del receptor. En el caso de sucesos de transporte, el distribuidor de sucesos pasa el mensaje en forma de objeto MailMsg al receptor de sucesos. Este objeto contiene el mensaje entero junto con los campos de sobre de transporte. El receptor puede modificar los campos del mensaje y del sobre. 5. Una vez finalizado zado el procesamiento por parte del receptor, devuelve un indicador de estado de suceso al distribuidor de sucesos. El distribuidor de sucesos comprueba este indicador para determinar si debe realizar la notificación a receptores posteriores. Por ejemplo, un receptor de sucesos podría indicar al distribuidor de sucesos que omita todos los receptores restantes para detener por completo el procesamiento de mensajes. Los receptores de sucesos devuelven los siguientes códigos para indicar si deben realizar la notificar a receptores posteriores: •

S_OK Se llama a otros receptores con la misma prioridad o con prioridad inferior.

•

S_FALSE No se llama a otros receptores con la misma prioridad o con prioridad inferior. Nota: Los receptores de sucesos de protocolo protocolo SMTP también pueden devolver el valor MAILTRANSPORT_S_PENDING para indicar que el procesamiento finalizará de modo asincrónico mediante la llamada al método NotifyAsyncCompletion. Un receptor de sucesos de protocolo puede llamar al método NotifyAsyncCompletion NotifyAsyncCompletion para notificar al distribuidor de sucesos de protocolo entrantes que ha finalizado el procesamiento asincrónico y que debe pasar el resultado del procesamiento.

243

6. En el caso de sucesos de transporte, tras la notificación de cada receptor, o d después de que un receptor indica que deben omitirse los receptores restantes, se examina el campo de sobre de estado para que el mensaje determine la siguiente acción. Un mensaje puede enviarse a la ubicación correspondiente, descartarse o colocarse en la carpeta \Badmail Badmail del servidor virtual SMTP del sistema de archivos. Nota: En el servicio SMTP, el motor de protocolo y el motor de cola avanzada desempeñan las funciones de distribuidores de sucesos. El motor de protocolo distribuye sucesos de protocolo. El motor de cola avanzada distribuye sucesos de transporte. Tanto el motor de protocolo como el motor de cola avanzada distribuyen sucesos de almacén y del sistema.

Interfaces administrativas La herramienta principal para administrar la configuración del protocolo SMTP y los servidores virtuales SMTP en un servidor que ejecuta Exchange Server 2003 es el Administrador del sistema de Exchange, en concreto, el complemento SMTP de Exchange (\Programme\Exchsrvr\bin bin\SMTPMgr.dll). SMTPMgr.dll). Puede encontrar este complemento en el Administrador del sistema de Exchange, en cada objeto de servidor (en Protocolos, Protocolos en el contenedor SMTP). ). También puede controlar la mayor parte de las opciones de configuración que se aplican a la transferencia de mensajes entrantes y, en menor medida, med la configuración del correo saliente. Gracias al Administrador del sistema de Exchange, también podrá crear servidores virtuales SMTP en el servidor de Exchange. Cada servidor virtual SMTP representa una instancia del servicio SMTP y se define por medio med de una combinación exclusiva de una dirección IP y un número de puerto TCP. Cada servidor virtual SMTP desencadena sus propios sucesos y administra su propio conjunto de receptores de sucesos. Para obtener más información acerca de la configuración servidores servidores virtuales SMTP, consulte la Guía de de transporte y enrutamiento de Exchange Server 2003 2003. Nota: La creación de varios servidores virtuales SMTP en un servidor que ejecuta Exchange Server 2003 003 no mejora el rendimiento del sistema. Cada servidor virtual SMTP es multiproceso y puede admitir numerosas conexiones simultáneas. Por ejemplo, el número máximo predeterminado de conexiones salientes simultáneas por dominio SMTP es de 100, y el número máximo total de conexiones salientes concurrentes es 1.000.

Opciones de configuración y enlaces de sucesos El subsistema de transporte SMTP de Exchange Server 2003 depende de los tres repositorios siguientes para información de configuración:

244

•

Active Directory El Administrador del sistema de Exchange almacena y recupera información de configuración principalmente de Active Directory. Por ejemplo, las propiedades y restricciones de destinatarios, junto con la topología de enrutamiento de la organización de Exchange, incluidos todos los grupos de enrutamiento y los conectores de mensajería, se definen en Active Directory. Los componentes del subsistema de transporte SMTP se comunican con Active Directory para obtener esta información, tal y como se explicó en Exchange Server 2003 y Active Directory.

•

Metabase de IIS Los componentes principales del servicio SMTP que se incluyen en Windows Server 2003 no son compatibles con Active Directory. Por ejemplo, todas las opciones de configuración que se aplican a un servidor virtual SMTP deben transferirse de Active Directory a la metabase de IIS. De esta tarea se encarga el servicio de actualización de la metabase. El servicio de actualización de la metabase se registra en el controlador de dominio de configuración que usa Exchange Server 2003 para recibir la notificación de los cambios realizados en la configuración de Exchange. Esta notificación se produce durante los 15 segundos que siguen al cambio. Tan pronto como se replica el cambio al controlador de dominio de configuración, el servicio de actualización de la metabase de IIS replica el cambio en la metabase de IIS.

•

Registro La mayor parte de las opciones de configuración que se pueden configurar para el subsistema de transporte SMTP están almacenadas en Active Directory o en la metabase de IIS. No obstante, varios parámetros del sistema que afectan al servicio SMTP, como MaxPercentPoolThreads or AdditionalPoolThreadsPerProc, están almacenados en la base de datos del Registro, en la siguiente clave: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\SMTPSVC. Otra clave importante es: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\InetInfo,

que contiene parámetros de configuración para el proceso Inetinfo que aloja el servicio SMTP. Varios parámetros importantes del Registro ya se presentaron anteriormente en esta sección. Puesto que todos los receptores de sucesos SMTP son componentes COM, deben estar registrados en el subárbol HKEY_CLASSES_ROOT del Registro. Puede usar Regsvr32.exe para registrar y anular el registro de componentes COM de forma manual.

Información de configuración de Active Directory El Administrador del sistema de Exchange almacena las opciones de configuración de servidores virtuales SMTP en la partición del directorio de configuración de Active Directory. Cada servidor virtual se representa mediante un objeto de configuración independiente. La ubicación de este objeto coincide con la jerarquía de los objetos de configuración que se muestran en el Administrador del sistema de Exchange y el nombre común corresponde al numeral del servidor virtual en la metabase de IIS. Por ejemplo, el servidor virtual SMTP predeterminado es el primer servidor virtual SMTP de IIS y, por lo tanto, el nombre común (CN) correspondiente del objeto de configuración del servidor virtual SMTP predeterminado

245

de Active Directory es 1 (por ejemplo, CN=1,CN=SMTP,CN=Protocols,CN=SERVER01,CN=Servers,CN=First administrative Group,CN=Administrative Groups,CN=TailspinToys,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=TailspinToys,DC=com).

La tabla siguiente contiene información de configuración importante que Exchange Server 2003 almacena para servidores virtuales SMTP en Active Directory. Para obtener información acerca de cómo administrar opciones de configuración de servidor virtual SMTP en Active Directory mediante programación, consulte Setting Message Restriction on an SMTP Virtual Server Using ADSI (Establecimiento de restricción de mensajes en un servidor virtual SMTP mediante ADSI). Atributos importantes de Active Directory para servidores virtuales SMTP Atributo de Active Directory

Descripción

msExchServerBindings

Especifica el enlace de puerto de protocolo de Internet (IP) para conexiones SSL (Nivel de socket seguro).

msExchAuthenticationFlags

Indica el tipo de autenticación que acepta este servidor virtual SMTP.

msExchMaxIncomingConnections

Especifica el número máximo de conexiones entrantes permitidas para este servidor virtual SMTP.

msExchLogType

Especifica los formatos de registro que usa este servidor virtual SMTP para el registro de protocolos.

msExchAccessSSLFlags

Identifica el tipo de canal cifrado que admite este servidor virtual SMTP.

msExchServerAutoStart

Especifica cuándo iniciar el servidor virtual. Si se establece en true, inicia el servidor virtual cuando se reinicia el sistema operativo.

246

Atributo de Active Directory

Descripción

msExchNTAuthenticationProviders

Especifica una lista de paquetes SSPI (Interfaz de proveedor de compatibilidad con seguridad) que se pueden usar para llevar a cabo la autenticación en este servidor virtual SMTP. Exchange Server 2003 admite la autenticación Kerberos a través de GSSAPI (Interfaz de programación de aplicaciones de servicios de seguridad genéricos) así como el protocolo heredado de autenticación LAN Manager de Windows NT (NTLM).

msExchIncomingConnectionTimeout

Especifica el máximo tiempo transcurrido antes de que se cancelen las conexiones entrantes inactivas.

msExchSmtpMaxOutgoingConnections

Especifica el número máximo de conexiones salientes permitidas desde este servidor virtual SMTP.

msExchSmtpOutgoingConnectionTimeout

Especifica el máximo tiempo transcurrido antes de que se cancelen las conexiones salientes inactivas.

msExchSmtpMaxOutgoingConnectionsPerDo Especifica el número máximo de conexiones main salientes permitidas desde este servidor virtual SMTP a un dominio específico. msExchSmtpOutgoingPort

Especifica el número de puerto de conexión saliente que usa el servidor virtual SMTP para ponerse en contacto con un host SMTP remoto.

msExchSmtpOutgoingSecurePort

Especifica el número de puerto de conexión saliente que usa el servidor virtual SMTP para ponerse en contacto con un host SMTP remoto si se utiliza TLS (Seguridad del nivel de transporte) para proteger el canal de transmisión.

msExchSmtpMaxHopCount

Especifica el número máximo de saltos que puede aceptar el mensaje transportado por este servidor virtual SMTP para llegar al destino final.

247

Atributo de Active Directory

Descripción

msExchSmtpMaxMessageSize

Especifica el tamaño máximo permitido de un mensaje enviado por este servidor virtual SMTP.

msExchSmtpMaxSessionSize

Especifica la cantidad máxima de datos en KB que se puede transferir en una sesión SMTP.

msExchSmtpMaxRecipients

Especifica el número máximo de destinatarios permitidos en un mensaje transferido por este servidor virtual SMTP.

msExchSmtpLocalQueueExpirationTimeout

Especifica la hora a la que este servidor virtual SMTP puede hacer que caduque un mensaje local no entregado.

msExchSmtpLocalQueueDelayNotification

Especifica la hora a la que este servidor virtual SMTP debe generar una notificación de estado de entrega para informar al remitente de que un mensaje local no alcanzó su destino.

msExchSmtpRemoteQueueExpirationTimeou Especifica la hora a la que este servidor t virtual SMTP debe hacer que caduque un mensaje saliente no entregado. msExchSmtpRemoteQueueDelayNotification

Especifica la hora a la que este servidor virtual SMTP debe generar una notificación de estado de entrega para informar al remitente de que no se produjo la transferencia de un mensaje saliente.

msExchSmtpSmartHost

Especifica una ruta de host inteligente para mensajes salientes desde este servidor virtual SMTP.

msExchSmtpSmartHostType

Especifica el tipo de host inteligente.

msExchSmtpMaxOutboundMsgPerDomain

Especifica el número máximo de mensajes salientes que puede transferir este servidor virtual SMTP por dominio en una sesión.

msExchSmtpOutboundSecurityFlag

Especifica la autenticación que se usa al establecer la conexión saliente desde este servidor virtual SMTP.

248

Atributo de Active Directory

Descripción

msExchSmtpInboundCommandSupportOptio ns

Controla los comandos SMTP que se admiten en conexiones entrantes. Si cambia este valor, puede deshabilitar características como 8BITMIME, BDAT, CHUNKING y PIPELINING.

msExchSmtpRelayForAuth

Determina si la retransmisión de mensajes requiere autenticación.

msExchSmtpPerformReverseDnsLookup

Especifica si se deben realizar consultas de Sistema de nombres de dominio (DNS) inversas para la entrega.

msExchSmtpDoMasquerade

Especifica si se debe usar un dominio de enmascaramiento para informes de no entrega (NDR). Si se define este atributo, use el dominio de enmascaramiento. Entonces los NDR se devolverán al dominio alternativo especificado en lugar de enviarse al dominio desde el que se originó el mensaje de correo electrónico.

msExchSmtpBadMailDirectory

Especifica la ubicación donde está almacenado el correo con errores (mensajes de correo contenidos en la carpeta BadMail) en el sistema de archivos.

msExchSmtpSendBadmailTo

Especifica la dirección a la que debe enviarse el correo con errores.

msExchSmtpFullyQualifiedDomainName

Especifica el nombre de dominio completo (FQDN) de este servidor virtual SMTP.

msExchSmtpPickupDirectory

Especifica el directorio desde el que se obtienen mensajes de correo.

msExchSmtpQueueDirectory

Especifica el directorio desde el que se ponen en cola los mensajes de correo.

msExchSmtpRemoteQueueRetries

Especifica el primero, segundo, tercero y posteriores intentos de entrega de correo remoto.

msExchSmtpRelayIpList

Especifica una lista de direcciones IP para las restricciones de retransmisión.

249

Atributo de Active Directory

Descripción

msExchBridgeheadedLocalConnecto msExchBridgeheadedLocalConnectorsDNBL

Especifica una lista de conectores del grupo de enrutamiento del servidor virtual SMTP para los que este servidor virtual SMTP es el servidor cabeza de puente local.

msExchBridgeheadedRemoteConnectorsDN BL

Especifica una lista de conectores de grupos grupo de enrutamiento remotos para los que este servidor virtual SMTP es un servidor cabeza de puente remoto.

Nota: El servicio de actualización de la metabase replica todas estas opciones de configuración a la metabase de IIS.

Opciones de configuración SMTP SMTP de la metabase La metabase IIS es un almacén jerárquico de información de configuración y de esquema que sirve para configurar recursos IIS. La configuración de la metabase y el esquema de IIS 4.0 y IIS 5.0 se almacenan en un archivo binario (MetaBase.bin) que no es fáci fácil de leer ni de editar. Deberá usar la herramienta MetaEdit para ver y editar la metabase de IIS 4.0 e IIS 5.0. MetaEdit 2.2 se puede descargar en http://go.microsoft.com/fwlink/?LinkId=47942. http://go.microsoft.com/fwlink/?LinkId=47942 En IIS 6.0, los archivos XML (Lenguaje de marcado extensible) denominados MetaBase.xml y MBSchema.xml sustituyen al archivo binario anterior. La información de configuración de IIS se almacena en el archivo MetaBase.xml, mientras que el esquema de metabase se almacena en el archivo MBSchema.xml. Cuando se inicia IIS, el nivel de almacenamiento de la metabase lee esos archivos y luego los escribe en la metabase en memoria por medio de los Objetos base de administrador (ABO), tal y como puede verse en la siguient siguiente figura. Arquitectura de la metabase de IIS 6.0

250

Claves de configuración SMTP Los miembros del grupo local Administradores pueden ver y modificar el archivo MetaBase.xml, que es un archivo de texto sin formato ubicado en la carpeta \Windows\System32\Inetsrv. Las entradas de la metabase que se aplican al servicio SMTP y sus servidores virtuales empiezan por IIsSmtp. La propiedad Location de las entradas de configuración define la jerarquía de los objetos de configuración. Por ejemplo, en Location ="/LM/SmtpSvc/1", LM indica el equipo local, SmtpSvc representa el servicio SMTP en general y el numeral (1), el servidor virtual SMTP predeterminado. El enumerador "1" corresponde al atributo CN del objeto de servidor virtual SMTP predeterminado de Active Directory. La figura siguiente muestra la jerarquía de entradas de configuración de servidores virtuales SMTP en función de la propiedad Location de cada entrada de la metabase IIsSmtp. Jerarquía de entradas de configuración SMTP en la metabase de IIS

Los parámetros que se aplican al servicio SMTP en general se registran en el nodo SmtpSvc de la metabase . Para encontrar este nodo, busque Location ="/LM/SmtpSvc". La siguiente sección es un listado abreviado de esta clave:
251

DefaultDomain="server01.TailspinToys.com" DomainRouting="" EnableReverseDnsLookup="FALSE" FullyQualifiedDomainName="server01.TailspinToys.com" ... SmtpRemoteProgressiveRetry="15,30,60,240" SmtpRemoteRetryThreshold="3" > ...

En el nodo SmtpSvc, encontrará las opciones de configuración de cada servidor virtual SMTP que creó en el servidor que ejecuta Exchange Server 2003. Los servidores virtuales SMTP heredan las opciones generales configuradas para el servicio SMTP y pueden sobrescribir estas opciones. A continuación, figura un listado esquemático de la sección de configuración del servidor virtual SMTP. Observe la información de Location.
Location ="/LM/SmtpSvc/1"

... property definitions that apply only to the particular virtual server ... >
252

... custom property defintion... />

Nota: Cuando se comparan los nombres nombres de parámetros de servidores virtuales SMTP de la metabase de IIS con los atributos de los servidores virtuales SMTP de Active Directory, se observan correspondencias casi exactas. Por ejemplo, el parámetro de metabase denominado PickupDirectory corr corresponde esponde al atributo de Active Directory denominado msExchSmtpPickupDirectory.

Edición directa de la metabase Puesto que MetaBase.xml es un archivo de texto, los miembros del grupo Administradores pueden editar directamente la metabase de IIS 6.0 con herramientas de texto habituales, como el Bloc de notas. No obstante, este archivo permanece abierto y bloqueado cuando cu se está ejecutando IIS. Para permitir la edición directa, debe habilitar la característica Habilitar la modificación directa de archivos de metabase en el Administrador de IIS. Para obtener instrucciones detalladas acerca de cómo habilitar la edición directa de la metabase de IIS, consulte Cómo habilitar la característica Ha Habilitar bilitar la modificación directa de archivos de metabase en el Administrador de IIS. IIS

Registros de dominios locales En cada nodo de servidor virtual SMTP de la metabase puede encontrar nodos secundarios importantes, como los nodos Domain (Location ="/LM/SmtpSvc/1/Domain") y EventManager (Location ="/LM/SmtpSvc/1/EventManager"). El nodo Domain contiene definiciones de dominios minios que determinan las acciones de ruta que debe realizar el servidor virtual SMTP. Por ejemplo, el servicio SMTP debe aceptar mensajes para todos los dominios SMTP locales, tal y como se define en las directivas de destinatarios, pero podría ser necesa necesario para rechazar intentos de retransmisión de mensajes a dominios no locales. El servicio de actualización de la metabase replica la información de dominio desde las directivas de destinatarios a la metabase de IIS para todos los servidores virtuales SMTP SMTP. Nota: Las definiciones de dominio también contienen entradas que hacen referencia a sitios de Active Directory. Un ejemplo de un dominio de este tipo es 705260ab-46c4705260ab 454d-bfdd-96b9c605364c._msdcs.fabrikam.com. 96b9c605364c._msdcs.fabrikam.com. La acción de ruta de estas entradas hace que el servidor virtual SMTP coloque los mensajes en el directorio \Drop, Drop, desde donde Active Directory puede recuperarlos. No modifique ni quite estas entradas de dominio para evitar problemas de replicación de directorios. Active Directory usa el servicio SMTP para replicar cambios de directorios entre sitios.

253

Registros de receptores de sucesos Las entradas del nodo EventManager son registros de sucesos. Para que el servicio SMTP funcione con los receptores de sucesos, los receptores de sucesos deben estar registrados en la metabase de IIS, de modo que el servicio SMTP pueda crear y ejecutar estos receptores cuando se produzcan sucesos pertinentes. Los objetos IIsConfigObject definen los enlaces de sucesos en la metabase de IIS. Por ejemplo:
Location ="/LM/SmtpSvc/1/EventManager/

EventTypes/{283430C9-1850-11D2-9E03-00C04FA322BA}/ Bindings/{A928AD15-1610-11D2-9E02-00C04FA322BA}/ SinkClass" >

Este enlace asocia el GUID de un suceso concreto, como 283430C9-1850-11D2-9E0300C04FA322BA, a un receptor de sucesos, como el receptor Exchange Router. La segunda entrada de GUID de la información de enlace {A928AD15-1610-11D2-9E02-00C04FA322BA} es el identificador (Id.) de esta entrada de enlace de sucesos concreta. Los Id. de enlace de sucesos deben ser exclusivos en la metabase, pero un suceso específico puede tener varios receptores de sucesos asociados a él, tal y como se indica en la figura 6.4, anteriormente en esta sección. Los parámetros de enlace de sucesos se definen en cada nodo de receptor de sucesos de la jerarquía de la metabase. La lista actual define un valor SinkClass que crea una asociación entre el suceso OnGetMessageRouter de transporte SMTP y la clase de receptor Exchange.Router. Existen más entradas de enlace para definir el nombre para mostrar del receptor de sucesos, como Exchange Router, y para definir otros parámetros, como la prioridad del receptor de sucesos. La tabla siguiente contiene una lista de los parámetros que se pueden especificar para un enlace de sucesos.

254

Información de enlace de sucesos Descripción de la propiedad

Descripción de la propiedad

ID

GUID que identifica el enlace de manera única. Esta información es obligatoria.

DisplayName

Nombre descriptivo opcional del enlace.

SinkClass

El identificación de programación (ProgID) de la clase de receptor de sucesos.

Habilitado

Indicador que especifica si el enlace está habilitado en la actualidad. Si no se incluye este indicador, el receptor de sucesos está habilitado. Este parámetro es opcional.

MaxFirings

El número de notificaciones de sucesos que puede recibir el receptor antes del enlace está deshabilitado. Este parámetro es opcional.

EventBindingProperties

Diccionario (o hash) de propiedades adicionales que se definen para todo el enlace. Este parámetro es opcional.

SinkProperties

Las propiedades de receptor se reservan para una implementación de receptor específica. Cuando se notifica al receptor acerca de un suceso, el distribuidor de sucesos pasa la colección de propiedades de receptor al receptor de sucesos. Por ejemplo, un receptor de sucesos que se usa para agregar un texto de limitación de responsabilidades a un mensaje podría recibir ese texto a través de una propiedad de receptor.

255

Descripción de la propiedad

Descripción de la propiedad

SourceProperties

Las propiedades de origen se definen mediante una implementación de distribuidor de sucesos específica. Por ejemplo, el distribuidor de sucesos de protocolo entrante y saliente usa una propiedad Rule y Priority para determinar cuando se notifica a un receptor acerca de un suceso. La mayoría de los receptores de sucesos no usan las propiedades de origen Rule, excepto el suceso OnTransportSubmission. Todos los sucesos de protocolo y de transporte admiten el uso de la propiedad de origen Priority. Las siguientes propiedades de origen sirven para enlaces de sucesos para sucesos de protocolo y de transporte: •

Rule Cadena que identifica un filtro de protocolo para el enlace de receptor. El distribuidor usa la regla como condición o grupo de condiciones que determinan si se notifica al receptor. Las reglas son reglas de comando de protocolo SMTP, como por ejemplo, EHLO. Las reglas pueden incluir condiciones, como EHLO=*.contoso.com. Si hay varias reglas, se separan con puntos y comas.

•

Priority La prioridad de notificación del receptor, comparada con la de otros receptores registrados para recibir notificaciones del suceso. El intervalo de valores es de 0 (superior) a 32767 (inferior). Esta propiedad es opcional. La prioridad predeterminada es 24575. Los receptores con la misma prioridad se ejecutan en un orden no definido.

Objetos de extensión de servidor Los GUID de enlaces de suceso garantizan una asociación única entre un tipo de suceso y un receptor de sucesos, pero estos identificadores pueden resultar problemáticos porque no son evidentes. Por ejemplo, si desea conocer el suceso que está asignado al receptor de

256

sucesos en el listado de la tabla anterior, debe buscar el GUID 283430C9-1850-11D2-9E0300C04FA322BA en el Registro, en HKEY_CLASSES_ROOT\Component Categories. Así podrá averiguar que este GUID identifica el tipo de suceso OnGetMessageRouter de transporte SMTP. El segundo GUID de este ejemplo de una definición de enlace, A928AD15-1610-11D2-9E02-00C04FA322BA, es el CLSID de la clase Exchange Router, implementada en Reapi.dll. La clave del Registro de este componente COM es HKEY_CLASSES_ROOT\CLSID\{A928AD15-1610-11d2-9E02-00C04FA322BA}. No obstante, este CLSID sólo se usa para crear un Id. único para el enlace de sucesos en la metabase. Lo que importa es el valor de SinkClass que define la asociación existente entre el tipo de suceso y la clase de receptor de sucesos. Afortunadamente, no es necesario trabajar con GUID para administrar los enlaces de receptores de sucesos. En su lugar, puede utilizar objetos de extensión de servidor implementados en Seo.dll. Microsoft ha desarrollado una secuencia de comandos que demuestra el uso de objetos de extensión de servidor para administrar los enlaces de sucesos del servicio SMTP. El nombre de esta secuencia de comandos es SMTPReg.vbs y puede encontrarla en smtpreg.vbs Event Management Script (Secuencia de comandos de administración de eventos smtpreg.vbs). Por ejemplo, puede usar SMTPReg.vbs con el siguiente comando para escribir todos los enlaces de sucesos SMTP de la metabase de IIS en un archivo denominado Event_Bindings.txt: cscript smtpreg.vbs /enum > Event_Bindings.txt. El siguiente listado muestra la salida para la entrada de enlace de Exchange Router: --------| Binding | --------Event: SMTP Transport OnGetMessageRouter ID: {A928AD15-1610-11D2-9E02-00C04FA322BA} Name: Exchange Router SinkClass: Exchange.Router Enabled: True SourceProperties: { priority = 8192 }

257

Cómo habilitar la característica Habilitar la modificación directa de archivos de metabase en el Administrador de IIS Este procedimiento explica cómo habilitar la característica Habilitar la modificación directa de archivos de metabase en el Administrador de IIS. Para editar el archivo MetaBase.xml directamente en la metabase IIS 6.0 cuando IIS se está ejecutando, debe llevar a cabo este procedimiento; en caso contrario, el archivo permanece abierto y bloqueado mientras IIS se ejecuta.

Antes de empezar Antes de realizar el procedimiento de este tema, tenga en cuenta lo siguiente: Puesto que la actualización de Active Directory a la metabase de IIS es una replicación unidireccional, se recomienda tener cuidado al modificar la configuración configuración de la metabase de IIS directamente. El servicio de actualización de la metabase podría sobrescribir cualquier valor modificado del servidor virtual SMTP durante el siguiente ciclo de actualización. Se recomienda utilizar el Administrador del sistema de Exchange Exchange para configurar el servicio SMTP en un servidor de Exchange 2003 y modificar solamente aquellos parámetros que no están disponibles en el Administrador del sistema de Exchange, como la opción ConnectResponse. Precaución: Si edita la metabase de fforma orma incorrecta, podría causar problemas graves que podrían requerir la reinstalación del servidor de Exchange. Microsoft no puede garantizar que usted pueda resolver los problemas derivados de un uso incorrecto de la metabase de IIS. La edición de la meta metabase base la lleva a cabo bajo su propia responsabilidad. Asegúrese de que dispone de una copia de seguridad válida de los archivos de metabase antes de aplicar los cambios.

Procedimiento Para habilitar la característica Habilitar la modificación directa de archivos arc de metabase en el Administrador de IIS 1. En el Administrador de IIS, haga clic con el botón secundario del mouse en el objeto de servidor y, a continuación, haga clic en Propiedades. 2. Active la casilla de verificación Habilitar la modificación directa directa de archivos de metabase. 3. Si desea modificar parámetros que no están disponibles en el Administrador del sistema de Exchange, puede editar la configuración de la metabase directamente.

258

Por ejemplo, el titular SMTP de un servidor SMTP se puede cambi cambiar agregando un valor de la propiedad ConnectResponse al objeto de configuración del servidor virtual SMTP predeterminado () para impedir revelar información de versión específica de Exchange en las comunicaciones SM SMTP, tal y como sigue:
Location ="/LM/SmtpSvc/1"

AdminACL="4963...

...

...a472"

ClusterEnabled="FALSE"

ConnectionTimeout="600" ...

4. Si no desea usar el Bloc de notas, puede usar ADSI (Interfaces del servicio Active Directory) en lugar de modificar opciones de configuración de la metabase). El siguiente bloque de código realiza el mismo cambio en el titular SMTP. La figura siguiente muestra mue el titular SMTP modificado. ' Get the configuration object for the default SMTP virtual server

' Configure the ConnectResponse setting

' Write the changed parameter into the metabase

5. Para obtener más información acerca de cómo obtener acceso a la configuración de metabase de IIS con ADSI, consulte Using ADSI to Configure IIS en Microsoft Platform SDK. Nota: Debe reiniciar el servicio de administración de IIS y todos sus servicios dependientes, ndientes, incluido el servicio SMTP, para guardar los cambios. El servicio SMTP está diseñado para obtener cambios de la configuración del sistema de forma automática sin que sea necesario reiniciar. No obstante, algunas modificaciones, como la modificación modificación del titular SMTP, podrían requerir un reinicio. Cambio de información de versión de Exchange en el titular SMTP

259

El motor de cola avanzada El motor de cola avanzada es un componente clave del tratamiento de mensajes de Exchange 2003 porque todos los mensajes deben pasar por este motor, incluso cuando el remitente y el destinatario están ubicados en el mismo servidor que ejecuta Exchange Server 2003. Esto permite que los componentes de transporte de Exchange Server 2003 procesen todos los mensajes. Ni Ningún ngún mensaje de correo electrónico puede pasar por alto el subsistema de transporte. Nota: El servicio SMTP básico de Windows Server 2003 usa un motor de cola avanzada implementado en Aqueue.dll para procesar mensajes recibidos. La versión ampliada del servicio ervicio SMTP no usa Aqueue.dll. Exchange Server 2003 sustituye este componente por un motor de cola avanzada de Exchange, implementado en Phatq.dll. Para cargar Phatq.dll, Exchange Server 2003 modifica la propiedad SmtpAdvQueueDll del servicio SMTP en la m metabase etabase de IIS y hace que señale al motor de cola avanzada de Exchange. Aqueue.dll y Phatq.dll desempeñan funciones parecidas, pero Phatq.dll es la única versión que funciona con Exchange Server 2003.

260

Sucesos desencadenados por el motor de cola avanzada Tall y como se puede ver en la figura siguiente, el motor de cola avanzada actúa de controlador o distribuidor de información de sucesos de sistema, de almacén y de transporte para procesar cada mensaje una vez que llega al subsistema de transporte SMTP. El motor de cola avanzada en la arquitectura SMTP

El motor de cola avanzada distribuye los siguientes sucesos: •

OnSubmission de transporte SMTP Este suceso se produce cuando llega un mensaje al subsistema de transporte a través del directorio \Pickup, la conexión SMTP o el controlador del almacén de Exchange. Para la categorización, el enrutamiento y la entrega, el mensaje debe pasar al motor de cola avanzada. Esta acción desencadena un suceso OnSubmission, también denominado OnTransportSubmission. El motor de cola avanzado usa este suceso para invocar receptores de sucesos (como un detector de virus) que comprueban todos los mensajes entrantes antes de que se produzca ningún otro procesamiento de transporte. En consecuencia, por ejemplo, el receptor de sucesos de la API de transporte de Exchange se registra para el suceso OnSubmission. Otro receptor registrado para este suceso es el receptor de envío XEXCH50 de transporte de Exchange, que prepara mensajes con datos de sobre XEXCH50 para procesamiento posterior sterior desde servidores remotos que ejecuten Exchange Server 2003. Nota: El suceso OnSubmission es el único suceso que ofrece una interfaz CDO (Objetos de datos de colaboración). Por lo tanto, puede programar receptores de sucesos con Microsoft Visual Basic o con Visual Basic Scripting Edition (VBScript). El resto de receptores de sucesos debe programarlos con C/C++ o con Microsoft Visual C#.

261

Los receptores de sucesos basados en CDO pueden registrarse para el suceso CDO_OnArrival, que es un empaquetador del suceso OnSubmission que proporciona un identificador al mensaje en formato de mensaje CDO. La mayor ventaja de usar CDO_OnArrival es que la interfaz de objetos de mensaje CDO dispone de varios métodos útiles, como el análisis de encabezados MIME y RFC 822. Para obtener más información acerca de la ampliación del servicio SMTP a través de un receptor CDO, consulte el artículo 837851 de Microsoft Knowledge Base, "Cómo configurar un servidor virtual SMTP Servicios de Internet Information Server para archivar o quitar mensajes en un entorno de prueba de Exchange Server 2003". El mayor inconveniente de los receptores de sucesos basados en CDO es que la interfaz CDO agrega carga de trabajo. Los receptores de sucesos basados en VBScript no son tan rápidos como los receptores escritos en C, C++ o Visual C#. También debe tenerse en cuenta que los receptores de sucesos basados en CDO funcionan de forma sincrónica y hay un límite de tiempo de 60 segundos para procesar el mensaje. Tras 60 segundos, el motor de cola avanzada presupone que la secuencia de comandos no responde y detiene el procesamiento. El límite de 60 segundos está codificado y no puede modificarse. Además, la interfaz CDO no admite el cambio del contenido de los mensajes enviados a través del almacén. Esta es una limitación que comparten los receptores de sucesos CDO_OnArrival con todos los otros receptores de sucesos. Esta limitación existe porque Exchange convierte un mensaje enviado a través del almacén a una versión SMTP temporal para el tratamiento por parte del receptor de sucesos y, a continuación, descarta la versión temporal una vez finalizado el procesamiento del receptor. Para obtener más información al respecto, consulte el artículo 273233 de Microsoft Knowledge Base, "PRB: CDOEX: No puede modificar mensajes MAPI que se capturan en un receptor de sucesos de transporte SMTP". Puesto que Exchange descarta la copia temporal de un mensaje enviado a través del almacén, no puede usar un receptor de sucesos para agregar un texto de limitación de responsabilidad u otras modificaciones a todos los mensajes salientes, excepto si exige que todos los mensajes se reciban a través de SMTP. Para ello, debe instalar el receptor de sucesos en un servidor cabeza de puente que sea independiente de los servidores de buzón de la organización. Los servidores que ejecutan Exchange Server 2003 se comunican entre sí a través de SMTP, por lo que todos los mensajes transferidos al servidor cabeza de puente se reciben a través de SMTP. •

OnPreCategorize de transporte SMTP Este suceso se produce inmediatamente antes de que un mensaje se envíe al categorizador. Este suceso es parecido al suceso OnSubmission, excepto en que no ofrece ninguna versión CDO. De forma predeterminada, no hay ningún receptor registrado para este suceso.

•

OnCategorize de transporte SMTP Este suceso se produce cuando se debe categorizar un mensaje. No se trata de un suceso único, sino de una categoría de sucesos. Pueden desencadenarse diez tipos distintos de sucesos para los receptores que enlazan con esta categoría. Un receptor de sucesos que enlaza con esta categoría es el receptor de categorizador que resuelve el remitente y los destinatarios y

262

proporciona información de categorización, categorización, como el servidor principal de cada destinatario, al motor de cola avanzada. En Exchange Server 2003, están registrados dos receptores de sucesos para el suceso OnCategorize: el categorizador de Exchange y el categorizador de inserción de Outlook Mob Mobile ile Access (registrado en la metabase de IIS como categorizador móvil). El categorizador de Exchange, entre muchas otras cosas, procesa los mensajes de correo electrónico para resolver la información de destinatario, expandir las listas de distribución y comprobar comprobar las restricciones por destinatarios. El categorizador móvil implementa notificaciones actualizadas para dispositivos móviles. •

OnPostCategorize de transporte SMTP Este suceso se produce inmediatamente después de la categorización del mensaje. E En n este momento, todas las listas de distribución (que tienen el servidor local como servidor de expansión) se han expandido y los destinatarios figuran en el sobre de transferencia de mensajes. De forma predeterminada, no hay ningún receptor registrado par para a este suceso. Nota: El categorizador de Exchange puede dividir un mensaje en varias copias independientes, con contenido o sobres distintos, durante un proceso denominado bifurcación (explicado más adelante en esta sección). Tras la categorización, el suceso OnPostCategorize de transporte SMTP se desencadena independientemente y de forma no correlacionada para cada copia del mensaje. Es posible que los destinatarios del mensaje estén distribuidos en varias copias distintas del mensaje.

•

OnGetMessageRouter de transporte SMTP Este suceso se produce cuando un OnGetMessageRou mensaje está dirigido a destinatarios remotos y se debe enrutar. No se trata de un suceso único, sino de una categoría de sucesos. Existen varios sucesos que se pueden desencadenar para un receptor que enlaza con esta categoría. Por ejemplo, el receptor que determina el Id. de tipo de mensaje y la información del siguiente salto de Exchange Server 2003 se denomina Exchange Router. El motor de cola avanzada también usa el receptor Exchange Router para actualizar la información del estado de los vínculos si cambia el estado de los conectores de mensajería locales, tal y como se explicó en Arquitectura de enrutamiento de mensajes. Nota: El servicio SMTP básico de Windows Server 2003 no implementa un receptor de enrutador y envía mensajes punto a punto al destino final de destinatario.

•

OnMsgTrackLog de transporte SMTP Este suceso se produce cuando el motor de cola avanzada procesa un mensaje de forma que un receptor puede continuar realizando el seguimiento de información acerca del mensaje en un archivo de registro. Exchange Server 2003 implementa un receptor MsgTrackLog para este suceso, para escribir esc información de estado acerca de todos los mensajes que pasan a través del motor de cola avanzada en archivos de registro de seguimiento de mensajes, almacenados en el directorio \Archivos Archivos de programa\Exchsrvr\<nombreServidor>.log programa <nombreServidor>.log (por ejemplo, \Archivos de programa\Exchsrvr Exchsrvr\Servidor01.log).

263

Nota: El seguimiento de mensajes está deshabilitado de forma predeterminada. •

OnDnsResolveRecord de transporte SMTP Este suceso se produce cuando se debe resolver un nombre de dominio en una dirección IP. Exchange Server 2003 registra un receptor denominado Exchange LoadBalancer para este suceso, que sirve para equilibrar la carga de transferencia de mensajes salientes en conectores para grupo de enrutamiento con varios servidores cabeza de puente.

•

OnMaxMsgSize sgSize de transporte SMTP Este suceso se produce cuando el contenido del mensaje enviado supera el tamaño máximo de mensaje configurado en la actualidad. Un receptor de sucesos que trate este suceso puede omitir el bloqueo predeterminado. De forma predeterminada, erminada, no hay ningún receptor registrado para este suceso.

•

StoreDriver SMTP Este suceso se produce cuando un mensaje debe guardarse en disco o en el almacén de Exchange. No se trata de un suceso único, sino de una categoría de sucesos. Existen varios varios sucesos que se pueden desencadenar para un receptor que enlaza con esta categoría. Por ejemplo, el motor de cola avanzada desencadena numerosos sucesos StoreDriver cuando un mensaje pasa por el subsistema de transporte. Puede obtener más información acerca acerca de los receptores de sucesos StoreDriver más adelante en esta sección. Nota: Los sucesos StoreDriver SMTP pueden desencadenarlos el motor de cola avanzada o el motor de protocolo.

Colas de mensajes del motor de cola avanzada El motor de cola avanzada mantiene varias colas de mensajes en memoria. Un grupo compartido de subprocesos se encarga de estas colas internas. Puede ver estas colas en el Administrador del sistema de Exchange. En concreto, el complemento Visor de cola de Exchange, implementado en Exadmin.dll, se comunica con el motor de cola avanzada a través de la interfaz de administración de colas (PhatQAdm.dll) para incluir estas colas y para realizar funciones de administración de colas, como la inmovilización o la liberación de mensajes en una a cola de mensajes. La figura siguiente muestra las colas de mensajes más importantes del motor de cola avanzada y su relación con los sucesos de transporte.

264

Colas de mensajes y sucesos de transporte

El motor de cola avanzada usa las siguientes colas de mensajes: •

Mensajes pendientes de envío Esta cola también se denomina cola de envío previo. Éste es el punto de entrada en el motor de cola avanzada. Se desencadena el suceso OnSubmission para todos los mensajes de la cola. Si el suceso es correcto, los mensajes se colocan en la cola de categorización previa.

•

Mensajes a la espera de una búsqueda en el directorio Esta cola también se denomina cola de categorización previa. Se trata de una cola de limitación de peticiones para el categorizador. Esta cola contiene los mensajes antes de que lleguen al categorizador. El categorizador resuelve la información de destinatario y de remitente en Active Directory, expande las listas de distribución, comprueba las restricciones, aplica límites por remitente y por destinatario, etc. Puede obtener información más detallada acerca del categorizador en la sección "Categorizador de Exchange", en ºComponentes del transporte SMTP. Los mensajes no están en ninguna cola durante la categorización de mensajes. Un mensaje que se está categorizando está en el categorizador y no figura en ninguna cola. Por lo tanto, el Visor de cola podría mostrar una cola de categorización previa vacía, mientras que la herramienta Supervisión del rendimiento podría mostrar un recuento positivo para el contador de rendimiento denominado Categorizaciones en curso. De forma predeterminada, el motor de cola avanzada permite 1.000 categorizaciones

265

pendientes como máximo antes de retener mensajes en la cola de categorización previa. Este umbral puede modificarse en la siguiente clave del Registro. Ubicación

HKEY_LOCAL_MACHINE\System\CurrentControlSe t\Services\SMTPSVC\Queuing

Valor

MaxPendingCat

Tipo

REG_DWORD

Información del valor

0x3E8

Descripción

Indica el número máximo de categorizaciones pendientes antes de que el motor de cola avanzada empiece a retener mensajes en la cola de categorización previa. El valor predeterminado es 1.000 conexiones.

•

Mensajes a la espera de enrutamiento Esta cola también se denomina cola de enrutamiento previo. Contiene todos los mensajes en cola para la entrega local y remota después de su categorización y del desencadenamiento de los sucesos de categorización posterior. Éste es el momento en que el motor de cola avanzada decide los mensajes que deben ir a la cola de entrega local y los mensajes que se deben enrutar. Para todos los mensajes a los destinatarios remotos, el motor de cola avanzada llama al motor de enrutamiento de un suceso OnGetMessageRouter para determinar el siguiente salto de cada mensaje en la cola y mover los mensajes a sus respectivas colas de vínculos.

•

Entrega local Tras la categorización, los mensajes pasan por la cola de enrutamiento previo y entran en la cola de entrega local si el buzón del destinatario reside en el servidor local que ejecuta Exchange Server 2003. El categorizador de mensajes marca el destinatario como local mediante el establecimiento de una propiedad por destinatario que indica el servidor de destino, en función del atributo homeMDB del destinatario, que señala al almacén de buzones del destinatario. Para los destinatarios locales, el suceso OnGetMessageRouter se omite y el motor de cola avanzada mueve mensajes a la cola de entrega local antes de crear un suceso StoreDriver. El suceso StoreDriver informa al controlador del almacén de Exchange de que se deben transferir los mensajes al servicio Almacén de información de Microsoft Exchange.

•

Entrega dinámica Estas colas son colas de dominio con nombres que coinciden con la dirección de dominio remoto o de siguiente salto del vínculo. El nombre de la cola identifica el destino. Caso especial es la transferencia de mensajes a través del MTA de Exchange, que se suele denominar entrega de puerta de enlace, puesto que el MTA también se encarga de la transferencia desde todos los conectores basados en MAPI a los sistemas de

266

mensajería distintos de Exchange, tal y como se explica más detalladamente en Arquitectura de transporte X.400 y Arquitectura de los conectores de mensajería de puerta de enlace. El subsistema de transporte SMTP usa el controlador del almacén de Exchange para mover mensajes al MTA y desde el MTA a través del almacén de Exchange. No obstante, el motor de cola avanzada desconoce si un mensaje se debe transferir a través de SMTP o del MTA hasta que el motor de enrutamiento devuelve esta información. Si el siguiente salto del destinatario es a través de un conector que no es SMTP (los Conectores para grupo de enrutamiento se consideran conectores SMTP, excepto cuando la instancia del Conector para grupo de enrutamiento tiene un servidor cabeza de puente de Exchange 5.5), el mensaje se envía a la cola de entrega del MTA de Exchange y, a continuación, a la cola de entrega local. Desde ella, el controlador del almacén de Exchange lo envía al almacén de Exchange. Las propiedades de destinatario que define el categorizador en el sobre de transferencia de mensajes sirven para distinguir los destinatarios para los que la entrega debe realizarse en un buzón local y aquellos para los que debe realizarse en el MTA de Exchange. •

Sistema Estas colas contienen mensajes con parámetros específicos. La tabla siguiente contiene las colas de sistema que mantiene el motor de cola avanzada, además de las colas de entrega.

267

Colas del sistema del motor de cola avanzada Cola

Descripción

Mensajes con destino inalcanzable

Esta cola contiene mensajes que no pueden alcanzar su servidor de destino final. Por ejemplo, Exchange no puede determinar una ruta ni un conector al destino final, o todas las rutas y conectores disponibles se consideran como no disponibles.

Mensajes puestos en cola para entrega diferida

Esta cola contiene mensajes en cola para su posterior rior entrega. Esta cola puede contener mensajes que se enviaron desde versiones anteriores de Microsoft Outlook, como Microsoft Outlook 2000. Las versiones más recientes de Outlook almacenan estos tipos de mensaje en el almacén de Exchange. Los mensajes permanecen rmanecen en la cola Mensajes puestos en cola para entrega diferida hasta su hora de entrega programada. Nota: Esta cola también podría contener mensajes enviados a un buzón que se movió recientemente a otro almacén de buzones o a otro servidor de Exchange, Exchang mientras se espera que la replicación de directorios actualice la ubicación del buzón.

268

Cola

Descripción

Mensajes DSN pendientes de envío

Esta cola contiene notificaciones de estado de entrega que están a la espera de ser procesadas por Exchange. Por ejemplo, si un mensaje permanece en una cola de mensajes durante un largo período de tiempo, el motor de cola avanzada genera una notificación de estado de entrega para informar al remitente de que se envió el mensaje. Los informes de no entrega (NDR) también son notificaciones del estado de entrega. Para obtener más información acerca de las notificaciones de estado de entrega, consulte los siguientes artículos de Microsoft Knowledge Base:

Cola de reintento de mensajes

•

284204, "Notificaciones de estado de entrega en Exchange 2000 Server y en Small Business Server"

•

256321, "Códigos mejorados de estado para entrega RFC 1893".

Esta cola contiene mensajes que no superaron el envío de cola. Los mensajes pueden no superar el envío de cola por varias razones y el error puede producirse antes de llevarse a cabo ningún otro procesamiento. Si los mensajes están dañados o los recursos del sistema son insuficientes, los mensajes se muestran en esta cola.

Limitación del número de mensajes en colas de mensajes Cada mensaje de una cola de mensajes consume al menos 4 KB de memoria. Por lo tanto, podría ocurrir que la memoria sea insuficiente en el caso de una cola de gran tamaño. Para evitar esta situación, puede usar el siguiente parámetro del Registro para limitar el número de mensajes que se almacenan en la cola en un momento dato.

269

Precaución: El uso del Editor del Registro puede ocasionar problemas problemas graves que quizás requieran reinstalar el sistema operativo. Microsoft no puede garantizar que estos problemas derivados del uso incorrecto del Editor del Registro puedan solucionarse. Utilice el Editor del Registro bajo su propia responsabilidad. Ubicación

HKEY_LOCAL_MACHINE\Software Software\Microsoft\Exch ange\Mailmsg

Valor

MaxMessageObjects

Tipo

REG_DWORD

Información del valor

0x000186a0

Descripción

Si no se ha especificado un valor, el valor predeterminado es 0x000186a0 (100,000) mensajes. Al disminuir este valor, se reduce el número máximo de mensajes que pueden residir en el motor de cola avanzada, lo que disminuye el consumo máximo de memoria por parte de SMTP. Cuando se alcanza este límite, cada conexión SMTP que se establece con el servidorr devuelve un error de memoria insuficiente. Por ejemplo, si se reduce este valor a 10.000 mensajes, SMTP rechazará los mensajes entrantes una vez alcanzados los 10.000 mensajes.

ºComponentes del transporte SMTP En Exchange Server 2003, el motor de cola avanzada utiliza los siguientes seis receptores de sucesos de transporte para entregar los mensajes a sus destinos finales: •

Envío XEXCH50 de transporte de Exchange Este receptor de sucesos está implementado en Peexch50.dll y permite al subsistema de transporte SMTP recibir los mensajes desde servidores de Exchange remotos a través de SMTP mediante el comando XEXCH50. Este suceso está registrado para el suceso OnSubmission.

•

API antivirus de transporte de Exchange Este receptor de sucesos está implementado mentado en OnSubmit.dll y permite a los proveedores distintos de Microsoft implementar programas antivirus, que comprueban que los mensajes no contengan datos adjuntos o estructuras de datos perjudiciales antes de alcanzar su destino final. Este suceso está á registrado para el suceso OnSubmission.

270

De forma predeterminada, la exploración del transporte no está habilitada porque los mensajes se exploran por duplicado, una vez en la capa SMTP y otra en el almacén de Exchange. Sin embargo, si utiliza servidores de aplicaciones para el usuario para conectar una organización de Exchange a Internet, puede habilitar esta característica en estos servidores mediante la siguiente clave del Registro. Ubicación

HKey_Local_Machine\Software Software\Microsoft\Exch ange\TransportAVAPI

Valor

Enabled

Tipo

REG_DWORD

Información del valor

0x1

Descripción

El valor 0x1 habilita la exploración del transporte. El valor 0x0 deshabilita la exploración del transporte. Si no se especifica cifica ningún valor, se utiliza el valor predeterminado 0x0..

Nota: La exploración del transporte es una función que solamente está disponible en los programas antivirus de Exchange basados en la interfaz de programación para aplicaciones de detección de virus (VSAPI) 2.5. •

Categorizador de Exchange Este receptor de sucesos está implementado en Phatcat.dll y está registrado para los distintos sucesos de la categoría de sucesos OnCategorize. El categorizador es uno de los componentes más importantes del subsistema de transporte. Realiza la resolución de direcciones, lleva a cabo el reenvío de los mensajes, define para cada dominio los indicadores de conversión de formato de los mensajes de Internet de entrada y salida, amplía los grupos de distribución distribució e impone la configuración global para bloquear las notificaciones de estado de entrega. El categorizador también puede agregar destinatarios alternativos a los mensajes para tareas del diario, bifurcar los mensajes (si se deben crear varias copias de un mensaje), entre otras funciones. El categorizador se describe con más detalle en la sección "Categorizador de Exchange", más adelante en este tema.

•

Categorizador móvil Este receptor de sucesos está implementado en Miscat.dll y también está registrado para para los distintos sucesos de la categoría de sucesos OnCategorize. Este receptor de sucesos admite las notificaciones de actualización para los dispositivos móviles, como Microsoft Pocket PC. Se trata de una característica nueva en Exchange Server 2003. De forma predeterminada, las notificaciones de actualización están instaladas en Exchange Server 2003. Cuando se genera un suceso, por ejemplo, cuando un usuario recibe un mensaje, se envía una notificación al dispositivo Pocket PC del usuario. De este modo, el dispositivo Pocket PC puede realizar la sincronización en

271

segundo plano para que la información más actualizada esté disponible cuando el usuario vuelva a comprobar el contenido del dispositivo. Nota: Las notificaciones de actualización solamente están disponibles en los dispositivos que tienen instalado el sistema operativo Microsoft Windows Mobile 2003. •

Enrutador de Exchange Este receptor de sucesos está implementado en Reapi.dll y está registrado para los sucesos de la categoría de sucesos O OnGetMessageRouter. nGetMessageRouter. El receptor Enrutador de Exchange es el segundo componente más importante del subsistema de transporte. El motor de cola avanzada utiliza este componente para determinar el siguiente salto hacia el destino del mensaje. Para obtener más información i sobre la arquitectura de enrutamiento de Exchange Server 2003, consulte Arquitectura de enrutamiento de mensajes mensajes.

•

Equilibrador de carga de Exchange Este receptor de sucesos está implementado en Reapi.dll y está registrado para el suceso OnDnsResolveRecord. El motor de cola avanzada utiliza este receptor para distribuir la transferencia de mensajes salientes de forma uniforme entre todos los servidores cabeza de puente especificados para un conector para grupo de enrutamiento. Para obtener más información sobre el equilibrio de carga de la transferencia de mensajes entre grupos de enrutamiento, consulteArquitectura Arquitectura de enrutamiento de mensajes mensajes.

Categorizador de Exchange El sistema de categorización de mensajes de Exchange consta de dos componentes: un categorizador base y el categorizador de Exchange. El categorizador base está formado por el código originalmente implementado en Aqueue.dll. Exchange Server 2003 reemplaza Aqueue.dll mediante el registro de una DLL denominada Phatq.dll, que incluye todas las características disponibles en Aqueue Aqueue.dll .dll además de las características específicas de Exchange. El categorizador de Exchange está implementado en PhatCat.dll. PhatCat.dll está registrado para los sucesos de la categoría de sucesos OnCategorize. El motor de cola avanzada desencadena estos suc sucesos esos a través del categorizador base. El categorizador base y el categorizador de Exchange procesan conjuntamente el mensaje en diez sucesos de categorizador. Nota: El categorizador base desencadena los sucesos que controlan el proceso de categorización de los mensajes. El motor de cola avanzada desencadena los diez sucesos del categorizador siguientes: •

Register El categorizador base y el categorizador de Exchange utilizan este suceso para inicializar sus interfaces. Por ejemplo, el categorizador de Exchange inicializa sus interfaces con Directory Service Access (DSAccess), el motor de enrutamiento y el

272

controlador del almacén. Si se produce un error en alguna de estas interfaces, el categorizador de Exchange no logrará inicializarse. Todos los categorizadores gorizadores requieren interfaces con estos componentes por las siguientes razones: a. La comunicación con DSAccess es necesaria para determinar si los destinatarios están en la caché DSAccess, en cuyo caso la información necesaria puede obtenerse directa directamente mente de DSAccess sin necesidad de realizar búsquedas en Active Directory. El categorizador de Exchange también determina la lista de servidores de catálogo global que DSAccess utiliza y la proporciona al categorizador base para que la utilice en sus búsquedas quedas del protocolo ligero de acceso a directorios (LDAP). De forma predeterminada, el categorizador base utiliza la topología de dominio de Active Directory para determinar los servidores de catálogo global para las búsquedas LDAP. No obstante, en un ser servidor vidor en el que se ejecute Exchange Server 2003, el categorizador debería utilizar los servidores de catálogo global que DSAccess ha determinado dinámicamente, según la topología del sitio de Active Directory, o estáticamente, si ha codificado los servidor servidores es de catálogo global en un perfil DSAccess del Registro. Para obtener más información sobre el proceso de detección DSAccess, consulte Exchange Server 2003 003 y Active Directory. b. La comunicación con el motor de enrutamiento es necesaria, por ejemplo, cuando se encapsula una dirección no SMTP de uso único con una dirección SMTP. Una dirección de uso único es una dirección que no se resuelve en función de un objeto de destinatario en Active Directory. El categorizador de Exchange llama al motor de enrutamiento para determinar si existe una ruta al destino. Si no existe, el categorizador genera un NDR. Si existe, el categorizador marca el destinatario de uso único con la dirección encapsulada en el objeto MailMsg. Más tarde, el motor de cola avanzada transmite la información de la dirección al motor de enrutamiento, que determina el siguiente salto para el destinatario. Nota: El objeto MailMsg es una estructura estructura en la memoria que contiene un sobre de transferencia de mensajes y un puntero que señala al mensaje en el almacén de NTFS o el almacén de Exchange. El sobre de transferencia de mensajes contiene todas las propiedades de encabezado del mensaje y la información formación de usuario del destinatario que el categorizador necesita para procesar el mensaje. c.

La comunicación con el controlador del almacén de Exchange es necesaria en determinadas situaciones durante la categorización. Por ejemplo, puede que el categorizador orizador de Exchange deba copiar un mensaje de la carpeta \Queue para permitir que el almacén de Exchange pueda procesar y convertir el contenido RFC 822 mediante la lógica de conversión de contenido implementada en el componente de correo de Internet (IMA (IMAIL) IL) del almacén de Exchange.

273

•

BeginMessageCategorization Este suceso se llama una vez para cada objeto MailMsg que se envía al categorizador base e indica el comienzo de un proceso de categorización de mensajes.

•

EndMessageCategorization Este suceso se llama para cada objeto MailMsg enviado al categorizador base. Denota el final de la categorización de mensajes.

•

BuildQuery Este suceso se llama una vez para cada destinatario y para el remitente que debe determinarse. Sin embargo, los miembros del grupo de distribución basado en consultas no se determinan porque sus atributos ya se determinan al procesar el grupo de distribución ución basado en consultas. Para todos los destinatarios que se deben determinar, el categorizador de Exchange comprueba si el destinatario se encuentra en la caché DSAccess. En caso afirmativo, el categorizador de Exchange devuelve un objeto ICategorizerItemAttributes ICategorizerItemAttributes para pasar por alto el código de búsqueda del servicio de directorio del categorizador base. El proceso continúa con el suceso ProcessItem de este destinatario. Si el destinatario no está en la caché DSAccess, el código de búsqueda de LDAP del categorizador base crea un filtro de búsqueda compatible con LDAP para el usuario, que suele estar basado en el atributo proxyAddresses y la dirección de entrada. Por ejemplo:

(proxyAddresses=smtp:[email protected])

La dirección de entrada puede ser una dirección SMTP, una dirección X.400 o una dirección que no sea de Exchange, dependiendo del origen y el destino del mensaje. Sugerencia: Para saber cómo un filtro LDAP, basado en proxyAddresses, puede utilizarse para encontrar un objeto de destinatario determinado en Active Directory, puede utilizar la herramienta LDIFDE (Ldifde.exe) incluida con Windows Server 2003. El parámetro "r" de la línea de comandos de LDIFDE permite especificar un filtro de búsqueda de LDAP. Por ejemplo, puede utilizar el siguiente comando para encontrar a Ted en el catálogo global en Server01 de un dominio denominado fabrikam.com: ldifde -f c:\Ted.ldf -s Server01 -t 3268 -d "dc=fabrikam,dc=com" -p subtree -r "(proxyAddresses=smtp:[email protected])". Si la dirección SMTP de Ted "(proxyAddresses=smtp:[email protected])". es [email protected], LDIFDE encontrará el objeto de destinatario en Active Directory y escribirá todos sus atributos en un archivo de texto ssin formato denominado Ted.ldf. El categorizador de Exchange utiliza exactamente el mismo principio para buscar objetos de destinatario, recuperar los atributos SMTP, X.400 y legacyExchangeDN predeterminados del destinatario y definirlos como propiedades en el objeto MailMsg. Más adelante, el categorizador de Exchange utilizará esta información en el procesamiento de los mensajes. El categorizador de Exchange utiliza el atributo proxyAddresses para casi todos los tipos de direcciones (salvo los nombres compl completos etos de Exchange heredados y los nombres completos de X.500, ya que esta información de dirección no se almacena en el atributo proxyAddresses). Por ejemplo, cuando un usuario de Outlook envía un mensaje a otro

274

usuario de la organización de Exchange o a un usuario externo que tiene un objeto de destinatario habilitado para enviar y recibir correo en Active Directory, el cliente de Outlook especifica la dirección legacyExchangeDN del destinatario en el mensaje saliente para mantener la compatibilidad con Exchange Exc Server 5.5. Además, el categorizador de Exchange utiliza el atributo legacyExchangeDN en el filtro de búsqueda para buscar el objeto de destinatario en Active Directory. El categorizador de Exchange debe hacerse cargo de los nombres completos de X.500 X. al resolver los miembros de un grupo de distribución porque los miembros del grupo figuran en una lista con sus nombres completos en el atributo del miembro. En esta situación, el categorizador de Exchange analiza el nombre completo para determinar el nombre completo relativo (RDN) del destinatario, que es el nombre común (CN) del destinatario en Active Directory. A continuación, el categorizador de Exchange utiliza el atributo cn en el filtro de búsqueda con el resto del nombre completo (que señala al contenedor primario del objeto de destinatario en Active Directory) como raíz de la búsqueda LDAP para encontrar el objeto del destinatario. De forma predeterminada, el atributo cn se indiza en Active Directory, lo cual permite realizar una búsqueda de directorio eficaz. •

BuildQueries Este suceso se llama una vez para cada búsqueda procesada por lotes. El categorizador base utiliza este suceso para combinar en una única consulta las búsquedas individuales de hasta 20 destinatarios. De este modo, SendQue SendQuery puede realizar una sola búsqueda que devolverá un lote de destinatarios. Normalmente es más eficaz ejecutar una sola búsqueda para varios destinatarios que varias búsquedas para varios destinatarios. Esto es cierto incluso cuando es preciso realizar procesamiento pro adicional para controlar un suceso SortQueryResults al realizar búsquedas en lotes y hacer coincidir los resultados obtenidos con los destinatarios individuales del mensaje. El grado de coincidencia cuando se devuelven menos de 20 resultados es mayor que el de varias consultas LDAP de ida y vuelta en Active Directory. El siguiente ejemplo muestra un filtro de búsqueda compatible con LDAP que puede utilizarse para buscar varios usuarios a la vez:

(|(proxyAddresses=smtp:[email protected]) (proxyAddresses=smtp:[email protected])) (proxyAddresses=smtp:[email protected]))

Sugerencia: Para saber cómo funciona un filtro LDAP para varios usuarios, puede utilizar el siguiente comando para encontrar a Ted y a Birgit en el catálogo global en Server01 dentro del dominio fabrikam.com: ldifde -f c:\TedandBirgit.ldf TedandBirgit.ldf -s Server01 -tt 3268 -d "dc=fabrikam,dc=com" -p subtree -r "(|(proxyAddresses=smtp:[email protected]) (proxyAddresses=smtp:[email protected]))". Si la dirección SMTP de Ted (proxyAddresses=smtp:[email protected]))". es [email protected] y la de Birgit es [email protected], LDIFDE LDI encontrará los dos objetos de destinatario en Active Directory y escribirá todos sus atributos en secciones separadas en un archivo de texto sin formato denominado

275

TedandBirgit.ldf. El categorizador utiliza exactamente el mismo principio para buscar varios objetos de destinatario. •

SendQuery El categorizador desencadena este suceso una vez para cada búsqueda procesada por lotes y, a continuación, realiza la búsqueda del directorio de forma asincrónica.

•

SortQueryResult El categorizador llama a este suceso una vez para cada búsqueda procesada por lotes y, a continuación, determina los usuarios que pertenecen a cada objeto de directorio (los resultados de LDAP devueltos para la consulta). El atributo proxyAddresses se utiliza para comparar los resultados de las búsquedas según una dirección SMTP, una dirección X.400 o una dirección que no sea de Exchange. El atributo legacyExchangeDN se utiliza para hacer coincidir las búsquedas legacyExchangeDN, mientras que el atributo distinguishedName se utiliza para hacer coincidir las búsquedas de nombres completos de X.500. Para que este proceso funcione, la información de la dirección debe identificar de forma única a cada destinatario. Si los valores no son distintivos, se obtiene un NDR 5.1.4 como resultado. La tabla siguiente ofrece información detallada del NDR 5.1.4. Detalles de NDR con código 5.1.4

•

Código numérico

5.1.4

Causa posible

Hay dos objetos con la misma dirección (proxy) y se envía correo a dicha dirección.

Solución de problemas

Compruebe la dirección del destinatario y vuelva a enviar el mensaje. Este problema también puede producirse si el destinatario no existe en el servidor remoto.

Comentarios

Para obtener más información sobre los códigos NDR, consulte el artículo 284204 de Microsoft Knowledge Base, "Notificaciones de estado de entrega en Exchange 2000 Server y en Small Business Server".

ProcessItem El categorizador base desencadena este suceso para agregar las direcciones SMTP, X.400, X.500 y legacyExchangeDN predeterminadas de cada destinatario en el objeto MailMsg. Las direcciones que el categorizador de Exchange establece en el destinatario se basan en los atributos devueltos para el destinatario desde Active Directory. El atributo mail contiene la dirección SMTP, el atributo textEncodedORAddress contiene la dirección X.400, el atributo distinguishedName contiene la dirección X.500 y el atributo legacyExchangeDN contiene la dirección de Exchange heredada.

276

Nota: Las direcciones utilizadas para el destinatario a partir de este momento no coinciden necesariamente con la dirección utilizada para buscar el destinatario en Active Directory. Por ejemplo, puede que un usuario que no sea de Exchange envíe un mensaje a la dirección proxy secundaria de un usuario de Exchange. Durante el suceso ProcessItem, el categorizador de Exchange reemplaza la dirección proxy secundaria por la dirección principal del usuario de Exchange. El categorizador de Exchange también dispone de de un código especial para administrar los contactos y las direcciones de uso único. Los contactos son destinatarios que no son de Exchange, pero residen en Active Directory. Las direcciones de uso único no existen en Active Directory. Es posible que el remitente remitente haya escrito la dirección del destinatario directamente en la línea Para, o que haya especificado un objeto de contacto de su carpeta de contactos personales en Outlook. En cualquiera de los dos casos, sólo se conoce la dirección de destino del dest destinatario, inatario, que se agrega al objeto MailMsg. Si una dirección de contacto o una dirección SMTP de uso único coincide con un espacio de direcciones de la organización de Exchange local, se produce un conflicto porque los contactos y las direcciones de uso úni único co deben hacer referencia a destinatarios que se encuentran fuera de la organización de Exchange local. Al activar la casilla Esta organización de Exchange es responsable de todos los mensajes entregados a esta dirección, dirección, el categorizador impone su autoridad autor para las direcciones que coinciden con espacios de direcciones especificados en directivas de destinatarios. Si un usuario envía un mensaje a una dirección que no consta en Active Directory pero coincide con un espacio de direcciones en una directiva de destinatario autorizada, el categorizador de Exchange incluye un estado de error en el destinatario que, más tarde, provoca que el motor de cola avanzada genere un informe de no entrega 5.1.1, que denota una dirección desconocida. El categorizador de Exchange change también tiene autorización para las direcciones legacyExchangeDN y X.400 que coinciden con el espacio de direcciones del sitio del grupo administrativo local. Nota: Si dispone de un servidor alternativo configurado en un servidor virtual SMTP (opción Reenviar a este host el correo con destinatarios sin resolver), resolver el categorizador vuelve a enrutar los mensajes hacia direcciones que no existen en sus espacios de direcciones autorizados al servidor alternativo, en lugar de generar un informe de no entrega entrega 5.1.1 para los destinatarios. Esta acción tiene lugar durante el suceso CompleteItem. En la tabla siguiente, se muestran los detalles del informe de no entrega 5.1.1. Detalles de informes de no entrega con código 5.1.1 Código numérico

5.1.1

277

Causa posible

La cuenta de correo electrónico no existe en la organización a la que se envió el mensaje. Por ejemplo, si un usuario de Internet envía un mensaje a [email protected], donde su servidor tiene autorización para fabrikam.com y nadie en Active Directory tiene esa dirección, se generará un NDR 5.1.1. Un informe NDR 5.1.1 es un NDR de "autorización no encontrada". Se aplica a direcciones SMTP según las directivas de destinatario, a destinatarios de legacyExchangeDN según el atributo legacyExchangeDN del grupo administrativo local y a direcciones X.400 según la dirección del sitio X.400 del grupo administrativo. De lo contrario, se generará un informe NDR 5.1.2 siempre que exista una dirección no SMTP que no se pueda enrutar y que no coincida con un objeto de destinatario en Active Directory.

Solución de problemas

El formato de la dirección del destinatario es incorrecto o el categorizador no puede resolver correctamente el destinatario. Para solucionar este error, compruebe la dirección del destinatario y vuelva a enviar el mensaje. Para obtener más información sobre los códigos NDR, consulte el artículo 284204 de Microsoft Knowledge Base, "Notificaciones de estado de entrega en Exchange 2000 Server y en Small Business Server".

Para las direcciones que no constan en Active Directory y no coinciden con una directiva de destinatarios autorizada o un espacio de direcciones de sitios locales, el categorizador no registra ningún error. En su lugar, registra una retransmisión a un destino remoto. •

ExpandItem El categorizador desencadena este suceso para administrar las siguientes tareas: •

Expansión de la lista de distribución Si el servidor local es un servidor de expansión para los grupos de distribución del mensaje, los grupos de distribución pueden expandirse localmente. El atributo msExchExpansionServerName lista el servidor en

278

el que se ejecuta Exchange Server 2003 que se encarga de la expansión de la lista de distribución. Si el atributo no está definido, cualquier servidor en el que se ejecute Exchange puede expandir ese grupo de distribución. Si se especifica un servidor que no es el servidor local, el categorizador debe reenviar el mensaje a ese servidor porque el grupo habilitado para enviar y recibir correo debe expandirse en ese servidor en concreto. Cuando se expande un grupo de distribución, el categorizador resuelve cada destinatario individual. •

Comprobación de restricciones El categorizador comprueba todas las restricciones, límites y configuraciones de formato de mensaje de cada remitente y destinatario, y marca cada destinatario en consecuencia. Por ejemplo, si el remitente tiene un límite de destinatarios y un mensaje sobrepasa dicho límite, el categorizador solicita al motor de cola avanzada que genere un informe NDR 5.5.3 para garantizar que ningún mensaje contenga un número de destinatarios superior al permitido. Detalles de NDR con código 5.5.3

•

Código numérico

5.5.3

Causa posible

Hay demasiados destinatarios en el mensaje enviado.

Solución de problemas

El límite de destinatarios puede configurarse en el servidor de recepción. Para solucionar este problema, aumente el límite de destinatarios o divida el mensaje en varios mensajes para que entre dentro del límite del servidor.

Comentarios

Para obtener más información sobre los códigos NDR, consulte el artículo 284204 de Microsoft Knowledge Base, "Notificaciones de estado de entrega en Exchange 2000 Server y en Small Business Server".

Destinatarios alternativos Mediante Usuarios y equipos de Active Directory puede especificar destinatarios alternativos para los usuarios de Exchange en la ficha Opciones generales de Exchange bajo Opciones de entrega. El categorizador de Exchange agrega esta información de los destinatarios al objeto MailMsg y reenvía el mensaje. Cuando el mensaje se transfiere entre una organización de Exchange, se transmite un indicador en el sobre de transferencia de mensajes a través de XEXCH50 con el destinatario original. Esto impide que se reenvíen varias copias de un mensaje a un destinatario alternativo. Cuando el categorizador de Exchange descubre este indicador para un destinatario original, omite el código para agregar el destinatario alternativo.

279

El categorizador de Exchange también comprueba las condiciones de bucle (por ejemplo, cuando Ted reenvía a Birgit y después Birgit reenvía a Ted). Si se detecta un bucle, el categorizador indica al motor de cola avanzada que genere un informe NDR 5.4.6 para el primer usuario del bucle. Detalles de informes de no entrega con código 5.4.6 Código numérico

5.4.6

Causa posible

Se ha detectado un bucle de reenvío en el categorizador. Se ha definido un atributo targetAddress en un usuario habilitado para utilizar el buzón que contiene una dirección que se encuentra en un dominio SMTP autorizado. El atributo targetAddress debe señalar a un dominio remoto. También se genera un NDR 5.4.6 cuando existe un bucle de reenvío en Active Directory. Por ejemplo, este NDR se genera si una cadena de usuarios de Exchange tiene destinatarios alternativos que se señalan entre ellos de forma circular.

Solución de problemas

Compruebe el destinatario alternativo del contacto. Compruebe y quite el atributo targetAddress para los usuarios habilitados para utilizar el buzón.

Comentarios

•

•

Para obtener más información sobre los códigos NDR, consulte el artículo 284204 de Microsoft Knowledge Base, "Notificaciones de estado de entrega en Exchange 2000 Server y en Small Business Server".

Bifurcación de mensajes Si los destinatarios requieren formatos de mensaje distintos, el categorizador de Exchange bifurca el mensaje para crear varias copias del mismo. La bifurcación de mensajes se describe con más detalle más adelante en esta sección.

CompleteItem El categorizador base llama a este suceso para llevar a cabo el procesamiento final cuando el trabajo del resto de receptores de sucesos del categorizador ha finalizado. El procesamiento final incluye estas tareas: •

Tareas de diario Proceso que consiste en copiar los mensajes enviados o recibidos por los usuarios de un servidor de Exchange en un archivo de almacenamiento de

280

mensajes. Si el servidor actual es el primer servidor que trata un remitente o destinatario en el que deben rrealizarse ealizarse tareas de diario (por ejemplo, porque las tareas de diario de los mensajes están habilitadas para el almacén del buzón local de un remitente o un destinatario), el categorizador de Exchange agrega la dirección de diario del almacén del buzón al ssobre obre de transporte de mensajes y transfiere el mensaje. La configuración de diario se almacena en Active Directory y está disponible para todos los servidores de Exchange de la organización. Por ejemplo, puede que un usuario de Exchange (cuyo almacén del buzón local tiene habilitadas las tareas de diario) utilice un cliente de Internet para enviar mensajes a través de SMTP hacia un servidor cabeza de puente que forma parte de la organización de Exchange. A continuación, el servidor cabeza de puente agrega la dirección de diario al sobre de transferencia de mensajes y reenvía una copia del mensaje al buzón de almacenamiento de ese remitente. Los servidores en los que se ejecuta Exchange Server 2003 comunican la información de los sobres de transferencia de mensajes, m incluida la lista de direcciones de diario del remitente y los destinatarios, mediante el comando XEXCH50. Si varios servidores de Exchange intervienen en la transferencia de mensajes y un servidor encuentra una dirección de diario en el sobre de transferencia de mensajes, no agregará otra vez la dirección de diario para impedir la duplicación de mensajes en el archivo de almacenamiento de mensajes. Nota: Es posible que las tareas de diario de los mensajes no tengan en cuenta de forma confiable a los destinatarios en copia oculta, los destinatarios de las reglas de reenvío de transporte o los destinatarios de las expansiones de grupos de distribución. Si, además de los datos del mensaje, también debe registrar los datos del sobre de transporte d de e mensajes, será preciso que habilite Tareas de diario de sobre. Esto se consigue mediante la herramienta E-Mail Mail Journaling Advanced Configuration (Configuración avanzada de registro en diario de correo electrónico), disponible para descarga en el sitio Web Exchange Server Email Journaling Advanced Configuration (en inglés). •

Reenvío de destinatarios no resueltos Si ha configurado el servidor virtual SMTP para que reenvíe todos los mensajes con destinatarios no resueltos a un host alternativo, el categorizador de Exchange establece el servidor de destino de todos los destinatarios no resueltos en el nombre de dominio completo (FQDN) del servidor alternativo.

•

Marcado de destinatarios El categorizador rizador de Exchange marca cada destinatario mediante una propiedad por destinatario en el mensaje. Esta propiedad indica el servidor de destino de cada destinatario. El formato habitual de esta propiedad es el FQDN del servidor principal del destinatario. En función del FQDN que el categorizador establece en cada destinatario, el motor de cola avanzada decide si entrega el mensaje localmente o llama al motor de enrutamiento. Todos los mensajes que coinciden con el FQDN del servidor local se dirigen directamente directam de la

281

cola de enrutamiento previo a la cola de entrega local, sin realizar el enrutamiento de mensajes. Para los destinatarios que no son locales, el motor de cola avanzada debe llamar más tarde al motor de enrutamiento para determinar el siguiente salto sa para la transferencia de mensajes. Nota: El categorizador de Exchange determina el FQDN del servidor principal de cada destinatario mediante un componente denominado MDAccess. MDAccess utiliza la información de configuración en Active Directory para determinar la dirección de red del servidor en el que se aloja el almacén del buzón de un destinatario. El categorizador de Exchange establece el atributo homeMDB del destinatario como una propiedad en el destinatario del sobre de transferencia de mensaje mensajes, s, si el buzón del destinatario se encuentra en el servidor de Exchange local. Con esta información, el controlador del almacén de Exchange puede determinar más adelante el almacén del buzón al que entregará el mensaje del destinatario. •

Redirección de las la notificaciones de estado de entrega Cuando un usuario envía un mensaje en nombre de un grupo de distribución (es decir, el usuario especifica el grupo en el campo De)) y solicita una confirmación de entrega o lectura, las notificaciones de estado de ent entrega rega se generan y envían al grupo de distribución, en lugar de únicamente al remitente. Para solucionar este problema, el categorizador dirige las notificaciones de estado al remitente real; para ello, cambia la dirección del remitente en el sobre de trans transferencia ferencia de mensajes del mensaje por la dirección del remitente real. Los usuarios envían muy pocas veces mensajes en nombre de un grupo de distribución. La recepción por parte del usuario de varias notificaciones de ausencia de la oficina, las respuestas respuestas automáticas y las notificaciones de estado de entrega, como los informes de no entrega, es un hecho mucho más frecuente después del envío de un mensaje a un grupo de distribución de gran tamaño. Para mitigar este problema, el categorizador de Exchange su suprime prime las notificaciones de ausencia de la oficina y las respuestas automáticas de forma predeterminada cuando envía mensajes a un grupo de distribución. Para conseguirlo, el categorizador de Exchange agrega una propiedad a los destinatarios del sobre del mensaje. El almacén de Exchange utiliza esta propiedad como un parámetro durante la operación de entrega local para suprimir las reglas que de otra forma generarían notificaciones de ausencia de la oficina y respuestas automáticas. Esta propiedad ampliada del sobre del mensaje se transmite mediante XEXCH50 entre los servidores en los que se ejecuta Exchange Server 2003, si cada miembro del grupo de distribución se encuentra en servidores de buzón distintos. El categorizador de Exchange redirige o elimina las notificaciones de ausencia de la oficina, las respuestas automáticas y las notificaciones de estado de entrega conforme a los criterios de la tabla siguiente.

282

Criterios de redirección y eliminación de notificaciones de estado de entrega Criterio

Acción

El grupo de distribución tiene un propietario y los informes de entrega están configurados para enviarse a este propietario

Los informes de no entrega se redirigen a fin de informar al propietario configurado del grupo de los errores que se produzcan durante la entrega de un mensaje al grupo o a alguno de sus miembros. El categorizador redirige todos los informes de no entrega de los miembros del grupo que normalmente se devolverían al remitente del mensaje. De forma predeterminada, solamente los informes de no entrega (NDR) se redirigen al propietario del grupo. En los casos donde un remitente solicita explícitamente las notificaciones de estado (como las notificaciones de confirmación de entrega), se utilizan las extensiones de notificación de estado de entrega del protocolo SMTP para generar los informes. Si un remitente solicita una notificación de estado de entrega de un mensaje dirigido a un grupo que tiene habilitada la redirección de informes, el remitente recibirá la notificación de estado de entrega cuando el grupo se haya expandido o redirigido correctamente a su servidor de expansión (si el servidor local no es un servidor de expansión del grupo).

Los informes de entrega están configurados para enviarse al autor del mensaje

Se envía una notificación de estado de entrega al remitente del mensaje. El categorizador suprime las notificaciones de ausencia de la oficina y las respuestas automáticas si la casilla Enviar mensajes Fuera de la oficina al autor del mensaje, en la ficha Opciones avanzadas de Exchange, no está activada para el grupo. De forma predeterminada, esta casilla no está activada.

283

Criterio

Acción

El grupo de distribución está configurado para suprimir los informes de entrega para los miembros del grupo a fin de evitar la divulgación de información informació de los miembros del grupo

Se suprimen todas las notificaciones de ausencia de la oficina, las respuestas automáticas y cualquier tipo de notificaciones de estado de entrega (como las notificaciones de entrega y las confirmaciones de lectura). Esta medida es parecida a la redirección de informes NDR, con la diferencia que el categorizador suprime todos los tipos de notificaciones de entrega, incluidos los informes de no entrega para los miembros individuales del grupo. Para bloquear todos los informes de entrega, e el categorizador cambia la dirección del remitente en el sobre de transferencia de mensajes a "<>". Si un remitente solicita una notificación de estado de entrega (como una notificación de confirmación de entrega) en un mensaje dirigido al grupo, las l extensiones de notificación de estado de entrega del protocolo SMTP generarán la notificación de estado de entrega cuando el grupo se haya expandido o redirigido correctamente a su servidor de expansión (si el servidor local no es un servidor de expansión expansi del grupo).

Nota: De forma predeterminada, el categorizador suprime las notificaciones de ausencia de la oficina, las respuestas automáticas y las notificaciones de estado de entrega cuando un usuario envía un mensaje a una lista de distribución. Para Para configurar esta opción, active la casilla Enviar mensajes Fuera de la oficina al autor del mensaje, en la ficha Opciones avanzadas de Exchange, en las propiedades del grupo de distribución. Para obtener más información, consulte en Microsoft Knowledge Base el artículo 325469 "Las " respuestas automáticas de grupos de distribución no funcionan en Exchange Server 2003 o Exchange 2000 Server Server". •

Asignación de los códigos de estado El categorizador tegorizador de Exchange también asigna los códigos de estado que los receptores anteriores del categorizador han devuelto a los destinatarios en el mensaje de correo electrónico. Los códigos de error permiten

284

que el motor de cola avanzada genere informes de no entrega para los destinatarios afectados.

Bifurcación de mensajes Como se ha mencionado anteriormente, el categorizador puede crear varias copias de un mensaje durante el proceso de categorización. Este proceso se denomina bifurcación y se lleva a cabo siempre que distintos destinatarios deban recibir copias diferentes del mismo mensaje. La bifurcación tiene lugar por los siguientes motivos: •

Conversión de contenido El contenido debe convertirse cuando un usuario de Exchange envía un mensaje en formato MAPI a un usuario que no utiliza MAPI. Por ejemplo, un usuario de Outlook puede enviar un mensaje a un destinatario en Internet, por lo que el categorizador deberá realizar una conversión de contenido de MAPI a algún formato de mensaje de Internet. La conversión de contenido también debe producirse cuando un mensaje MAPI debe transferirse a través de un conector para grupo de enrutamiento basado en SMTP en una organización de Exchange en modo mixto. La bifurcación es necesaria para la conversión de contenido porque el categorizador no puede cambiar el contenido de los mensajes existentes. Más adelante en esta sección encontrará más información acerca de la conversión de contenido.

•

Eliminación de las solicitudes de confirmación de entrega y lectura para cada destinatario Esto es necesario cuando se envía un mensaje que contiene una solicitud de confirmación de lectura a un grupo de distribución con información de pertenencia al grupo oculta y a un destinatario individual adicional en la línea Para. Puesto que la pertenencia al grupo debe ser confidencial, no deben generarse confirmaciones de lectura cuando los miembros del grupo de distribución reciben el mensaje. De lo contrario, el remitente podría identificar los miembros del grupo en función de las confirmaciones de lectura recibidas. Para evitar esta situación, se crean dos copias del mensaje: una para el grupo de distribución con la pertenencia al grupo oculta y otra para el destinatario individual. La solicitud de confirmación de lectura se quitará del mensaje que se envía al grupo de distribución.

•

Notificaciones de estado de entrega con varios destinatarios Cuando el categorizador de Exchange detecta notificaciones de estado de entrega con varios destinatarios, bifurca el mensaje para cada destinatario, puesto que el MTA de Exchange, a fin de cumplir el estándar X.400, no admite más de un destinatario por notificación. Puesto que el categorizador no puede determinar si el MTA participa en la transferencia del mensaje (sólo el motor de enrutamiento puede saberlo), el categorizador debe crear una notificación de estado de entrega diferente para cada destinatario individual.

La bifurcación tiene lugar en el servidor en el que se ejecuta Exchange Server cuando el cliente envía el mensaje. Mediante la herramienta Rendimiento puede comprobar el número de mensajes nuevos que el categorizador ha creado. En la figura siguiente se muestra el contador de rendimiento relevante.

285

Cat: Contador de rendimiento de mensajes bifurcados

Conversión de contenido Los usuarios de clientes MAPI, como Outlook, pueden especificar para cada mensaje o destinatario el formato en que envían el mensaje: texto enriquecido, HTML o texto sin formato. El categorizador deberá convertir el mensaje en consecuencia. Los administradores también pueden especificar sus formatos de preferencia en las propiedades de los objetos de destinatario con correo habilitado en Active Directory o definir formatos de correo de Internet por cada espacio de direcciones (por ejemplo, por cada dominio de Internet, en el Administrador del sistema de Exchange, bajo Configuración global). De este modo, los mensajes enviados a los usuarios de un dominio de Internet pueden tener un formato de texto enriquecido, Extensiones multipropósito de correo Internet (MIME) o una codificación de Unix a Unix (UUEncoded). El categorizador utiliza una lógica específica para combinar esta configuración de formatos tan variada para cada destinatario. Cuando el categorizador resuelve los destinatarios del mensaje, puede que averigüe que se necesitan varios formatos de mensaje para subconjuntos de destinatarios o destinatarios individuales. El categorizador debe bifurcar el mensaje para que tenga el formato de mensaje correcto, por ejemplo, texto enriquecido, HTML o texto sin formato, para cada destinatario. La conversión de contenido también es un proceso necesario para los mensajes MAPI dirigidos a los destinatarios de Exchange que se encuentran en la organización de Exchange local si los mensajes se transfieren a través de SMTP. Los servidores en los que se ejecuta Exchange Server 2003 en el grupo de enrutamiento local siempre se comunican entre sí a

286

través de SMTP. Los servidores en los que se ejecuta Exchange Server 2003 en grupos de enrutamiento distintos se comunican a través través de SMTP cuando se implementa el Conector para grupo de enrutamiento o los conectores para SMTP. Para ofrecer compatibilidad con SMTP, el formato MAPI debe convertirse al formato RFC 822 para poder transferir el mensaje. Nota: La conversión de contenido contenido se lleva a cabo en el servidor donde el usuario envía el mensaje. De este modo, el mensaje puede desplazarse entre servidores por medio de SMTP, sin que sea necesario realizar más conversiones. La conversión de contenido solamente se realiza para los mensajes MAPI.

IMAIL El proceso de conversión de mensajes en Exchange Server 2003 recibe el nombre de IMAIL. IMAIL es un componente interno del almacén de Exchange. El categorizador de Exchange no realiza la conversión real de los mensajes. El categorizador categorizador de Exchange crea copias del mensaje por medio solamente del controlador del almacén de Exchange y establece algunas propiedades en el sobre de transferencia de mensajes de cada copia. A continuación, el controlador del almacén utiliza estas propiedades como como parámetros para especificar el formato que utilizará cuando solicite el contenido RFC 822 del almacén de Exchange. El almacén de Exchange utiliza IMAIL para convertir el mensaje MAPI al formato RFC 822 mediante los parámetros de formato solicitados. Cuando Cuando se genera el contenido RFC 822 de un mensaje, IMAIL sólo crea una presentación del mensaje MAPI. El mensaje real del almacén de Exchange no cambia. Los cambios en el contenido RFC 822 presentado no se asocian dinámicamente con el mensaje MAPI utilizad utilizado o para generar el contenido RFC 822.

TNEF Exchange Server 2003 utiliza el formato de encapsulación neutro para el transporte (TNEF) para convertir los mensajes MAPI al formato RFC 822. TNEF aparece en un mensaje como un dato adjunto MIME del tipo aplicació aplicación/ms-tnef. tnef. El archivo adjunto se denomina Winmail.dat e incluye el contenido completo del mensaje y todos los archivos adjuntos. Sólo los clientes MAPI, como Outlook, pueden descodificar el archivo adjunto Winmail.dat. Los clientes que no son MAPI no pued pueden en descodificar TNEF, por lo que el archivo Winmail.dat se mostrará como un archivo normal pero inservible. Nota: Los destinatarios que tienen buzones en un servidor de Exchange y que utilizan clientes de Internet para obtener acceso a sus mensajes no se consideran destinatarios que no son MAPI. Esto se debe a que el almacén de Exchange en el que se alojan los buzones puede generar el contenido RFC 822 necesario en un formato distinto de MAPI cuando los usuarios descargan los mensajes MAPI de sus Bandejas de entrada mediante un cliente POP3 o IMAP4.

287

Existen varios escenarios posibles de transferencia de Exchange a Exchange que necesitan la conversión de MAPI a RFC 822: •

El destinatario se encuentra en un servidor de Exchange en el mismo grupo de enrutamiento Exchange Server 2003 presenta los mensajes MAPI en el formato Summary-TNEF TNEF (S/TNEF), un tipo especial del formato de encapsulación neutro para el transporte (TNEF) que carece de la parte de texto sin formato y se presenta en un formato binario de ocho cho bits. Los mensajes S/TNEF constan únicamente del archivo Winmail.dat. Nota: Dentro de un grupo de enrutamiento, Exchange Server 2003 siempre utiliza S/TNEF porque en todos los casos de entrega remota se garantiza que el mensaje realizará directament directamente e un salto SMTP hacia un servidor en el que se ejecuta Exchange 2000 Server o Exchange Server 2003 o se dirigirá al MTA de Exchange. Exchange 2000 Server y Exchange Server 2003 admiten MIME binario. Por otra parte, si el mensaje se transmite al MTA de Exchange Exch para realizar la entrega a un servidor en el que se ejecuta Exchange Server 5.5 a través de RPC, la conversión del mensaje no es necesaria porque el formato RFC 822 no se utiliza.

•

El destinatario se encuentra en un servidor de Exchange en otro grupo de enrutamiento y la organización de Exchange funciona en modo nativo Exchange Server 2003 presenta los mensajes MAPI en el formato Summary Summary-TNEF TNEF (S/TNEF) porque, en modo nativo, una organización de Exchange solamente puede incluir servidores en los que se ejecute Exchange 2000 Server o Exchange Server 2003 que admitan MIME binario.

•

El destinatario se encuentra en un servidor de Exchange en otro grupo de enrutamiento y la organización de Exchange funciona en modo mixto En el modo mixto es posible usar el Servicio de correo de Internet de Exchange Server 5.5 como un conector SMTP, pero el Servicio de correo de Internet no admite MIME binario. Puesto que la representación RFC 822 de S/TNEF que IMAIL genera es MIME binario, el Servicio de correo de Internet Internet no puede transferir los mensajes S/TNEF. Como el categorizador de Exchange no puede detectar con antelación la ruta que seguirá un mensaje, no convierte el mensaje a S/TNEF para los destinatarios que se encuentren en un servidor ubicado fuera del grupo de enrutamiento local en modo mixto. Para aceptar una instancia potencial del Servicio de correo de Internet en la ruta de transferencia, el categorizador de Exchange convierte el mensaje a una parte de texto sin formato y a datos adjuntos en TNEF heredado heredado,, cuyo formato es MIME de siete bits transferibles por parte del Servicio de correo de Internet.

•

El destinatario es un destinatario MAPI fuera de la organización local de Exchange Los usuarios y administradores pueden habilitar la transferencia de TNEF a través de los límites de la organización local de Exchange para destinatarios en entornos de mensajería externa que utilizan Outlook. Puesto que el destinatario no se encuentra en la organización de Exchange local, el categorizador de Exchange no puede

288

determinar si todos los hosts SMTP que participan en la transferencia del mensaje admiten MIME binario. En consecuencia, el categorizador de Exchange convierte el mensaje a una parte de texto sin formato y a datos adjuntos en TNEF heredado. Nota: Los destinatarios stinatarios que no son MAPI normalmente prefieren recibir un mensaje de texto sin formato o en formato HTML sin TNEF porque sus clientes no pueden descodificar el archivo Winmail.dat que incluye el mensaje y todos los archivos adjuntos. La encapsulación TN TNEF EF impide que los clientes que no son MAPI obtengan acceso a los datos adjuntos. Puede que las herramientas que no sean de Microsoft, como EPOC WMDecode para Windows, puedan extraer los datos adjuntos de los archivos Winmail.dat. •

Mensajes MAPI enviados a carpetas públicas Los mensajes enviados a carpetas públicas siempre se retransmiten en formato TNEF heredado. Más adelante en esta sección se proporciona más información acerca del tratamiento de los mensajes de las carpetas públicas.

•

Mensajes MAPI enviados viados a un servidor de expansión a través de SMTP Si un mensaje contiene una lista de distribución con un servidor de expansión explícito que no es el servidor local, el mensaje se reenvía al servidor de expansión en formato TNEF heredado (si se utiliza SMTP para la transferencia de los mensajes). En este caso, se transmite una propiedad en el sobre de transferencia de mensajes a través de XEXCH50 que informa al servidor de expansión sobre la hora de recepción original del mensaje a través del controlador controlador del almacén de Exchange. Una vez que el categorizador del servidor de expansión expande la lista de distribución, deberá aplicar los formatos de mensaje RFC 822 adecuados para cada destinatario. El categorizador utiliza el controlador del almacén de Exchange Exchange para copiar el mensaje al almacén de Exchange, donde IMAIL lee los datos TNEF para construir un mensaje MAPI con la hora de envío del mensaje original. A continuación, el subsistema de transporte SMTP puede leer el mensaje MAPI desde el almacén en un formato RFC 822 coherente con los requisitos de formato de los destinatarios.

Puede controlar el comportamiento de formato de TNEF para enviar mensajes añadiendo la siguiente clave de registro. El número nn representa la instancia de servidor virtual de esta es máquina. Ubicación

HKey_Local_Machine\Software Software\Microsoft\Exch ange\StoreDriver\Exchange Exchange\nn\EnableTnef

Valor

Disabled

Tipo

REG_DWORD

Información del valor

0x0

289

Descripción

Un valor de 0x0 disables TNEF, and messages are generated without using TNEF. A value of 0x1 will generate a message using legacy TNEF when S/TNEF would ordinarily be generated. A value of 0x2 has no effect, as that is the default behavior.

Tratamiento de los mensajes de las carpetas públicas Las carpetas públicas pueden habilitarse para enviar y recibir correo a fin de que los usuarios puedan enviar mensajes a dichas carpetas. Sin embargo, a diferencia de las cuentas de usuario habilitadas para utilizar el buzón, en las que los buzones pueden encontrarse en un servidor de Exchange designado en una organización, las carpetas públicas pueden replicarse entre varios servidores y pueden estar ausentes de otros servidores que tienen un almacén de carpetas públicas asociado con la jerarquía de nivel superior de la carpeta pública en cuestión. Por lo tanto, es difícil determinar la ubicación de entrega de los mensajes enviados a la carpeta pública. Para realizar la entrega de los mensajes, el categorizador de Exchange debe entregar el mensaje a un almacén de carpetas públicas que conozca la ubicación de las réplicas de la carpeta pública. Esta información está incluida en el almacén de Exchange en el atributo PTagReplicaList. Únicamente el almacén de Exchange con un almacén de carpetas públicas asociado con la jerarquía de nivel superior de la carpeta pública dispone de esta información PTagReplicaList. Para buscar un almacén de carpetas públicas asociado con la jerarquía de nivel superior de la carpeta pública, el categorizador de Exchange lee el atributo homeMDB de la carpeta pública. El atributo homeMDB contiene el nombre completo (DN) del objeto de la jerarquía de nivel superior en Active Directory. A su vez, este objeto tiene un atributo msExchOwningPFTreeBL que enumera los almacenes de carpetas públicas asociados con la jerarquía de nivel superior. A continuación, el categorizador de Exchange elige un almacén de carpetas públicas de esa lista y dirige el mensaje a ese almacén de carpetas públicas. El almacén de carpetas públicas determina la entrada PTagReplicaList de esa carpeta, redirige el mensaje hacia un almacén de carpetas públicas que contenga una réplica de la carpeta pública y vuelve a enviar el mensaje. El mensaje pasa de nuevo por el motor de cola avanzada, incluida la categorización. Cuando el categorizador de Exchange localiza la ubicación de la carpeta actualizada en el almacén de carpetas públicas, establece la ubicación de la carpeta actualizada como el destino del mensaje y vuelve a enrutar el mensaje. El categorizador de Exchange aplica las siguientes prioridades, de arriba a abajo, para seleccionar el almacén de carpetas públicas del mensaje:

290

1. Los almacenes de carpetas públicas del servidor local en el que se ejecuta Exchange Server tienen la prioridad priorid más alta 2. Los almacenes de carpetas públicas del grupo de enrutamiento local 3. Los almacenes de carpetas públicas del grupo administrativo local 4. Los almacenes de carpetas públicas de la organización de Exchange local 5. Los almacenes de carpetas públicas de los servidores en los que se ejecuta Exchange Server 5.5 Nota: Si existen varios almacenes de carpetas públicas en el grupo de enrutamiento local, el categorizador de Exchange elige el primero de la lista.

Ajuste de rendimiento del categorizador Como ya se ha mencionado en la sección "Categorizador de Exchange" de este tema, el categorizador de Exchange determina la lista de servidores de catálogo global que se utilizan para las búsquedas LDAP desde DSAccess. DSAccess determina esta lista de forma dinámica, en función de la topología del sitio de Active Directory o de las estadísticas, si se han codificado los servidores de catálogo global en un perfil DSAccess del Registro, tal y como se explica en Exchange Server 2003 y Active Directory. De forma predeterminada, DSAccess determina dinámicamente la lista de servidores de catálogo global, lo que permite excluir de la lista a los servidores servidores de catálogo global que dejen de estar disponibles por cualquier motivo. El período de reintento de conexión de un servidor de catálogo global no disponible es de cinco minutos. De forma predeterminada, DSAccess vuelve a calcular la lista al menos cad cada a 15 minutos. El categorizador de Exchange llama a DSAccess una vez cada hora para actualizar la lista de servidores de catálogo global. El categorizador de Exchange también actualiza la lista de servidores de catálogo global si se producen más de 100 erro errores res de conexión por cada servidor de catálogo global. Un servidor de catálogo global puede estar inactivo para realizar tareas de mantenimiento o por cualquier otro motivo, o puede que se haya producido un problema de comunicación de la red que ha provocado o un error en la conexión LDAP. Puede utilizar los siguientes parámetros del Registro para especificar los valores de tiempo de espera que el categorizador usa para clasificar las conexiones LDAP como no operativas. Precaución: El uso del Editor del Registro Registro puede ocasionar problemas graves que quizás requieran reinstalar el sistema operativo. Microsoft no puede garantizar que estos problemas derivados del uso incorrecto del Editor del Registro puedan solucionarse. Utilice el Editor del Registro bajo su propia p responsabilidad.

291

Ubicación

HKEY_LOCAL_MACHINE\System\CurrentControlSe t\Services\SMTPSVC\Parameters

Valor

LdapResultTimeout

Tipo

REG_DWORD

Información del valor

0x79

Descripción

Tiempo máximo en segundos que el categorizador de Exchange espera hasta recibir los nuevos resultados de las búsquedas pendientes del servidor de catálogo global. Si el tiempo de espera se agota y el categorizador de Exchange no ha recibido ningún resultado, las búsquedas pendientes en la conexión LDAP mostrarán un error con el código de estado LDAP_SERVER_DOWN. El categorizador de Exchange puede volver a enviar estas búsquedas en nuevas conexiones LDAP. El período de tiempo de espera predeterminado es de dos minutos y un segundo (121 segundos).

Ubicación

HKEY_LOCAL_MACHINE\System\CurrentControlSe t\Services\SMTPSVC\Parameters

Valor

LdapRequestTimeLimit

Tipo

REG_DWORD

Información del valor

0x258

Descripción

Tiempo máximo en segundos durante el que el categorizador permite que una sola solicitud LDAP pueda estar pendiente. Las búsquedas que tardan más que el límite de tiempo especificado muestran un error con el código de estado LDAP_TIMELIMIT_EXCEEDED, aunque el servidor de catálogo global responda con resultados de esa búsqueda. El valor predeterminado es diez minutos (600 segundos).

292

Ubicación

HKEY_LOCAL_MACHINE\System\CurrentControlSe t\Services\SMTPSVC\Parameters

Valor

MaxConnectionRetries

Tipo

REG_DWORD

Información del valor

0x14

Descripción

Número máximo de veces que la conexión LDAP de una sola categorización puede ser errónea y puede volver a enviar sus búsquedas en una nueva conexión hasta que se produce un error en la categorización y se coloca en una cola de reintentos. El valor predeterminado es 20 errores.

Si se produce un error en una categorización porque se supera MaxConnectionRetries, el categorizador vuelve a colocar el mensaje afectado en la cola de categorización previa y notifica al motor de cola avanzada que la categorización puede ser satisfactoria en un intento posterior. De forma predeterminada, el motor de cola avanzada vuelve a intentar la categorización al cabo de una hora. Este período de tiempo puede ajustarse con el siguiente parámetro del Registro. Ubicación

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSe t\Services\SMTPSVC\Queuing

Valor

CatRetryMinutes

Tipo

REG_DWORD

Información del valor

0x3C

Descripción

Número máximo de minutos que el categorizador espera hasta volver a intentar una categorización para un mensaje erróneo que podría solucionarse con un reintento, como un error de conexión LDAP. El valor predeterminado es una hora (60 minutos).

Equilibrio de carga del catálogo global Si hay disponibles varios servidores de catálogo global para un servidor en el que se ejecuta Exchange Server 2003, el categorizador de Exchange puede equilibrar la carga de las búsquedas LDAP entre los catálogos globales. De forma predeterminada, el categorizador de Exchange comienza el equilibrio de carga de las búsquedas LDAP cuando hay más de 16

293

búsquedas LDAP pendientes en un servidor de catálogo global. El categorizador de Exchange elige los servidores de catálogo global según los valores de costo. Los valores de costo están determinados por las siguientes características: •

Número ro de conexiones LDAP existentes El categorizador de Exchange prefiere las conexiones LDAP existentes a las conexiones nuevas porque es más eficaz utilizar una conexión que ya está establecida que establecer una nueva conexión con un servidor de catálogo global. El establecimiento de conexiones implica una sobrecarga de procesamiento. De forma predeterminada, el categorizador base puede abrir hasta ocho conexiones LDAP simultáneas (dependiendo de la carga de trabajo) por cada servidor de catálogo global para realizar las búsquedas de directorio. Para ajustar el número de conexiones puede utilizar la siguiente clave del Registro. Ubicación

HKEY_LOCAL_MACHINE\System System\CurrentControlSe t\Services\SMTPSVC\Parameters Parameters

Valor

MaxLdapConnections

Tipo

REG_DWORD

Información del valor

0x8

Descripción

Número máximo de conexiones LDAP con un servidor de catálogo global que pueden abrir los componentes del servicio SMTP. El valor predeterminado es ocho conexiones. Nota: Este valor se aplica individualmente a cada proceso roceso del categorizador que realiza búsquedas LDAP: uno resuelve los destinatarios de los mensajes enviados durante la categorización y otro comprueba las restricciones de los mensajes por cada destinatario. Cada uno de estos procesos puede tener ocho conexiones, exiones, por lo que el número máximo total es de 16 conexiones con los servidores de catálogo global.

•

Estado de las conexiones LDAP existentes El categorizador de Exchange prefiere las conexiones LDAP disponibles que no tienen búsquedas pendientes.

294

•

Proximidad del servidor de Exchange El categorizador de Exchange prefiere los servidores de catálogo global que se encuentran en el sitio de Active Directory local a los servidores de catálogo global de sitios remotos. Se da por hecho que las conexiones conexione TCP/IP del sitio local son rápidas y confiables.

•

Número de consultas LDAP pendientes El categorizador prefiere las conexiones inactivas a las conexiones con consultas pendientes. Si todas las conexiones tienen consultas pendientes, el categorizador d de e Exchange elige la conexión con menos consultas pendientes.

El categorizador de Exchange selecciona el servidor de catálogo global con el costo más bajo. Si varios servidores de catálogo global tienen el mismo valor de costo, el categorizador realiza por turnos el equilibrio de carga entre todas las conexiones LDAP disponibles. El categorizador de Exchange selecciona una conexión de la siguiente forma: 1. El categorizador de Exchange consulta repetidamente la lista de conexiones LDAP existentes y selecciona ona automáticamente la primera conexión que no tiene búsquedas pendientes. 2. Si no hay disponible o no existe ninguna conexión LDAP, el categorizador de Exchange establece una conexión nueva con el servidor de catálogo global.

Lotes de búsqueda LDAP El categorizador tegorizador de Exchange puede realizar búsquedas asincrónicas y en lotes de un máximo de 20 destinatarios. La realización de una sola búsqueda de Active Directory para varios objetos de destinatario mediante un filtro OR de LDAP puede mejorar el rendimiento, rendimient aunque se necesite procesamiento adicional para hacer coincidir los resultados con los destinatarios del mensaje. Las búsquedas LDAP por lotes funcionan correctamente para objetos de destinatario individuales que pueden agruparse dentro de una sola consulta cons en un catálogo global. La mayoría de operaciones del categorizador de Exchange se encuentran en esta categoría, pero existen excepciones. El categorizador utiliza consultas que no están agrupadas por lotes en las siguientes situaciones: •

El categorizador rizador debe expandir un grupo de distribución dinámico.

•

El categorizador debe solicitar atributos paginados. Es el caso, por ejemplo, de los grupos de distribución que contienen más de 1.000 miembros. Nota: El categorizador de Exchange consulta DSAccess DSAccess para determinar si un objeto de destinatario se encuentra en la caché DSAccess. Para los objetos almacenados en la caché no se realizan búsquedas de directorio.

El rendimiento del categorizador de Exchange puede administrarse mediante las siguientes claves aves del Registro. Por ejemplo, puede aumentar el número máximo de destinatarios en una búsqueda por lotes. No obstante, si este número se aumenta excesivamente puede afectar negativamente al rendimiento porque también aumenta la sobrecarga generada al hacer hac

295

coincidir los resultados con los destinatarios. Por lo general, los valores predeterminados son suficientes para la mayoría de situaciones. Por lo tanto, no es aconsejable cambiar estos valores sin la ayuda de un especialista de Soporte técnico de Microsoft. Ubicación

HKEY_LOCAL_MACHINE\System\CurrentControlSe t\Services\SMTPSVC\Parameters

Valor

MaxSearchBlockSize

Tipo

REG_DWORD

Información del valor

0x14

Descripción

"Límite del lote" o número máximo de búsquedas de categorizador que pueden enviarse conjuntamente como una sola búsqueda LDAP. El valor predeterminado es el valor hexadecimal 0x14 búsquedas de categorizador o el valor decimal 20 búsquedas de categorizador.

Ubicación

HKEY_LOCAL_MACHINE\System\CurrentControlSe t\Services\SMTPSVC\Parameters

Valor

MaxPendingSearches

Tipo

REG_DWORD

Información del valor

0x3C

Descripción

Número máximo de búsquedas pendientes y preagrupadas en lotes por cada conexión LDAP. El valor predeterminado es el valor hexadecimal 0x3C búsquedas pendientes o el valor decimal 60 búsquedas pendientes.

Categorización de los mensajes Los mensajes sólo se categorizan una vez. Para los mensajes de la carpeta \Queue en el sistema de archivos, el categorizador utiliza secuencias de datos alternativas, una característica poco conocida de NTFS, para mantener la secuencia de la propiedad MailMsg, que incluye la información de categorización y el sobre del mensaje. Las secuencias de datos alternativas permiten almacenar datos en archivos ocultos, que están vinculados a un archivo visible en una partición NTFS. Cuando el servicio SMTP no puede transferir un mensaje inmediatamente y debe volver a intentarlo en otro momento, el mensaje se guarda y

296

se cierra. Una parte de la operación implica guardar la secuencia de la propiedad MailMsg MailM existente para que pueda recargarse y utilizarse cuando la transferencia del mensaje se reintenta. No obstante, si debe volver a categorizar un mensaje (por ejemplo, si está en la cola para un servidor de destino que ya no existe), observará que la categorización cate no se realiza una segunda vez. El motor de cola avanzada almacena los mensajes como archivos .eml en el directorio \Queue Queue del servidor virtual SMTP o como archivos del Sistema de archivos instalable de Exchange (ExIFS) en el almacén de Exchange Exchange.. Para los archivos .eml, el categorizador utiliza dos secuencias de datos alternativas NTFS, denominadas PROPERTIES y PROPERTIES-LIVE, LIVE, durante el proceso de categorización para conservar las propiedades del objeto MailMsg y la información de categorización. categorización. La secuencia de datos PROPERTIES proporciona una copia del mensaje original. La secuencia de datos PROPERTIES-LIVE PROPERTIES proporciona una copia del mensaje actual. Las secuencias de datos alternativas se quitan cuando el servicio SMTP coloca un mensaje en la carpeta c \Badmail. Badmail. En esta situación, el mensaje se guarda con una extensión de nombre de archivo .bad y la secuencia de la propiedad se guarda en un archivo independiente con el mismo nombre pero con una extensión de archivo .bdp. Nota: La forma en que se guarda la secuencia de la propiedad depende del controlador de almacén que se utiliza. El controlador del almacén NTFS guarda las secuencias de la propiedad mediante secuencias de datos alternativas. El controlador del almacén de Exchange guarda las secue secuencias ncias de la propiedad mediante la copia de los datos en una propiedad MAPI binaria especial del mensaje (si la secuencia de la propiedad es pequeña) o en un archivo ExIFS independiente (si la secuencia de la propiedad es grande), en cuyo caso se guarda un vínculo al archivo ExIFS en la propiedad MAPI binaria.

Secuencias de datos alternativas en el directorio \Queue Queue Puede utilizar el Bloc de notas para ver las secuencias de datos alternativas de un archivo .eml en el directorio \Queue Queue del servidor virtual SM SMTP. TP. Por ejemplo, el siguiente comando muestra la información de categorización de un mensaje de prueba con el nombre de archivo NTFS_0ec25fe701c4120a00000001.EML: notepad C:\NTFS_0ec25fe701c4120a00000001.EML:PROPERTIES NTFS_0ec25fe701c4120a00000001.EML:PROPERTIES-LIVE. Tenga presente que el punto final nal pertenece al comando. Si lo omite, el Bloc de notas agregará una extensión de nombre de archivo .txt a PROPERTIES-LIVE, PROPERTIES pero PROPERTIES-LIVE.txt LIVE.txt no es el nombre de la secuencia de datos alternativa. La primera parte del nombre de archivo hace referencia referenci al archivo principal de la secuencia. La segunda parte corresponde al nombre real de la secuencia. La figura siguiente muestra un ejemplo del contenido del archivo principal (a la izquierda), junto con información de la propiedad MailMsg en la secuencia de datos alternativa (a la

297

derecha). Observe que la secuencia PROPERTIES-LIVE PROPERTIES LIVE de la ventana superior contiene información detallada acerca del destinatario obtenida para el remitente y el destinatario desde Active Directory. Archivo de mensaje con una sec secuencia uencia de datos alternativa para la información de categorización

Nota: Si mueve un archivo NTFS con una secuencia de datos alternativa a una partición FAT (Tabla de asignación de archivos), la secuencia de datos alternativa se perderá porque FAT no admite esta característica. En esta pérdida se incluye la información de categorización y el sobre de transferencia de mensajes. Más adelante, si mueve este archivo al directorio de recogida, se utilizará la lista de destinatarios P2 (RFC 822) para entrega entregarr el mensaje, a no ser que se especifiquen los encabezados x-sender y x-receiver. receiver. Esta lista puede diferir de la lista de destinatarios P1 (RFC 821) utilizada para enviar el mensaje originalmente, por lo que puede que algunos destinatarios reciban el mensaje mensaje dos veces, que los destinatarios con copia oculta no lo reciban o que destinatarios a los que no iba dirigido el mensaje reciban una copia del mismo. Esto sucede porque la lista de destinatarios P1 original se perdió en la secuencia de la propiedad MailMsg, MailMsg, dejando al servicio SMTP sólo con

298

la lista de destinatarios P2 como información. La lista de destinatarios P2, no obstante, no está diseñada para mantener una lista de destinatarios para el transporte y la entrega.

Aplicación obligatoria de la categorización categorización La explicación anterior demuestra que no es recomendable mover archivos a una partición FAT para cancelar la secuencia de la propiedad MailMsg y, de este modo, obligar al subsistema de transporte a recategorizar un mensaje. Es posible que la categorización orización de un mensaje deba aplicarse obligatoriamente en las siguientes situaciones: •

Metabase dañada Si la metabase de los Servicios de Internet Information Server (IIS) está dañada o se ha reemplazado por una versión que no es de Exchange, es posible posi que los mensajes se categoricen a partir de una versión del categorizador incorrecta. Para categorizar los mensajes mediante el categorizador de Exchange (quizás después de reinstalar Exchange Server 2003), debe recategorizar los mensajes.

•

Servidor de e expansión incorrecto Si cambia el servidor de expansión para una lista de distribución, el servidor de expansión de la lista de distribución incorrecta puede quedar marcado en el objeto de mensaje hasta que los cambios de la lista de distribución se repliquen pliquen en Active Directory. Si esto ocurre, el mensaje se envía al servidor de expansión incorrecto. Por ejemplo, si el servidor de expansión se quita de la red y ya hay mensajes categorizados en el servidor local, deberá recategorizar los mensajes para enviarlos nviarlos al servidor de expansión correcto.

•

Servidor de servicios de fondo incorrecto También pueden surgir problemas de categorización si se restauran buzones en un servidor de Exchange que no es el servidor original de la organización. Por ejemplo, puede puede decidir restaurar los buzones en otro servidor si se produce un error en el hardware de un servidor de buzones. Puede que los mensajes que se encuentren en las colas de otros servidores en los que se ejecuta Exchange Server (como los servidores de aplicaciones aplicaciones para el usuario) no se entreguen porque el motor de cola avanzada intenta la entrega en un servidor que no existe. Si no recategoriza los mensajes, el FQDN del servidor anterior se incluye en el sobre de transferencia de mensajes.

En estas situaciones, iones, debe volver a categorizar los mensajes. No obstante, los reinicios del servidor no afectan a las secuencias de datos alternativas. Por este motivo, el reinicio del servidor en el que se ejecuta Exchange Server no recategoriza los mensajes. Para desencadenar ncadenar la categorización sin mover archivos a una partición FAT, debe restablecer el estado del mensaje mediante la siguiente clave del Registro: Precaución: El uso del Editor del Registro puede ocasionar problemas graves que quizás requieran reinstalarr el sistema operativo. Microsoft no puede garantizar que estos

299

problemas derivados del uso incorrecto del Editor del Registro puedan solucionarse. Utilice el Editor del Registro bajo su propia responsabilidad. Ubicación

HKEY_LOCAL_MACHINE\System\CurrentControlSe t\Services\SMTPSVC\Queuing\

Valor

ResetMessageStatus

Tipo

REG_DWORD

Información del valor

0x1

Descripción

Este parámetro hace que sea obligatorio realizar la categorización de todos los mensajes durante la enumeración. Si este parámetro no existe, el valor predeterminado es no efectuar la categorización (0x0). Para que los cambios surtan efecto, debe detener y reiniciar el servicio SMTP. Una vez reiniciado el servicio SMTP, el categorizador enumera y vuelve a procesar todos los mensajes que estaban en cola. Cuando los mensajes abandonen la carpeta \Queue, vuelva a eliminar la clave ResetMessageStatus. A continuación, puede reiniciar el servicio SMTP para reanudar el funcionamiento normal.

Controladores de almacén del servicio SMTP El motor de cola avanzada transfiere un objeto MailMsg (un objeto de mensaje en memoria que permite el procesamiento rápido) de receptor a receptor. El objeto MailMsg está formado por un sobre de transferencia de mensajes y un puntero que señala al mensaje físico real, si el mensaje se encuentra en el directorio \Queue en NTFS. Si el mensaje se encuentra en el almacén de Exchange, el puntero hace referencia al contenido RFC 822 del mensaje, que se encuentra en un archivo temporal en la base de datos de secuencias. Tenga en cuenta que los receptores de sucesos no trabajan directamente con los mensajes MAPI, y que cualquier cambio realizado en un mensaje MAPI durante el procesamiento del mensaje en el subsistema de transporte no se conserva. Los componentes, como el categorizador, utilizan el puntero de mensajes principalmente para leer los datos del contenido de los mensajes. El

300

motor de cola avanzada también utiliza el puntero de mensajes para administrar la eliminación de los mensajes cuando se solicita. Nota: La secuencia ecuencia de la propiedad MailMsg es el mecanismo principal que utilizan los componentes de transporte para realizar cambios permanentes en un mensaje. La secuencia de la propiedad MailMsg se conserva después de los reinicios del servicio. Para crear el objeto jeto MailMsg en memoria de un mensaje recibido y para que funcione con el mensaje real, el motor de cola avanzada utiliza los siguientes controladores de almacén: •

Controlador del almacén NTFS Este controlador de almacén está implementado en NTFSDrv.dll, que se encuentra en la carpeta \Windows\System32\Inetsrv. Inetsrv. Se trata del controlador de almacén básico que se suministra con Windows Server 2003. Proporciona almacenamiento permanente para las propiedades del sobre de transferencia de mensajes y el contenido de un objeto MailMsg en el sistema de archivos.

•

Controlador del almacén de Exchange Este controlador de almacén está implementado en Drviis.dll, que se encuentra en la carpeta \Archivos Archivos de programa\Exchsrvr\bin. bin. Exchange Server 2003 implementa este controlador para proporcionar almacenamiento permanente para las propiedades del sobre de transferencia y el contenido de un objeto MailMsg en el almacén de Exchange. Este controlador de almac almacén én también administra la entrega local de mensajes. Nota: Los cambios escritos en el contenido del mensaje no son siempre permanentes. En el caso de los mensajes cuya copia de seguridad la ha realizado el controlador del almacén de Exchange, los cambios se pierden porque el almacén de Exchange sólo funciona con una copia temporal de los mensajes.

Controlador del almacén NTFS El servicio SMTP almacena los mensajes entrantes en una unidad del disco duro antes de confirmar la transferencia y desconectar la conexión SMTP con el host remoto. Cuando los mensajes llegan a través del motor del protocolo SMTP, los datos se escriben en la carpeta \Queue Queue en el sistema de archivos en forma de archivo NTFS (extensión .eml). Esta carpeta se encuentra en el directorio \Mailroot Mailroot del servidor virtual SMTP. La ruta de acceso al directorio \Mailroot Mailroot del servidor virtual SMTP predeterminado es: \Archivos Archivos de programa\Exchsrvr\Mailroot Mailroot\Vsi Vsi 1. Cuando se crean servidores virtuales SMTP adicionales en el Administrador del sistema de Exchange, también se crean estructuras adicionales de la carpeta \Vsi Vsi x en el directorio \Mailroot, Mailroot, según el número del servidor virtual SMTP. Todos los directorios \Vsi Vsi x se encuentran en \Archivos de programa\Exchsrvr\Mailroot Mailroot y su nombre es secuencial (es decir, \Vsi Vsi 1, \Vsi 2 y así sucesivamente).

301

Nota: El programa de instalación de Exchange Server 2003 mueve el directorio \Mailroot del servicio SMTP de \Inetpub\Mailroot a \Archivos de programa\Exchsrvr Exchsrvr\Mailroot. La estructura de carpetas anterior no se elimina. Sin embargo, todos los mensajes que se encontraban en las carpetas \Pickup y \Queue Queue antiguas no se entregarán. Para enviar estos mensajes, deberá moverlos manualmente a la carpeta \Pickup actual del servidor virtual SMTP. Cada carpeta \Vsx contiene tres o cuatro subcarpetas para las siguientes finalidades: •

\Badmail Se utiliza para guardar los mensajes que no se pueden entregar. Un mensaje que no se puede entregar solicita al motor de cola avanzada que devuelva el mensaje al remitente junto unto a un NDR. Si el NDR no se puede entregar, el mensaje se guarda en tres archivos independientes en la carpeta \Badmail.

•

\Pickup Ofrece un método alternativo para enviar mensajes de correo electrónico. En esta carpeta puede colocar los mensajes com como o archivos de texto formateados según RFC 822 para realizar su entrega. El proceso Inetinfo utiliza un subproceso de ATQ para supervisar el directorio \Pickup Pickup de cada servidor virtual SMTP. Este subproceso obtiene inmediatamente todos los mensajes de la carpeta ca \Pickup, Pickup, crea un nuevo archivo en el directorio \Queue Queue y, a continuación, analizar el contenido del archivo del directorio \Pickup Pickup y escribe los datos en el archivo del directorio \Queue. Queue. Tenga en cuenta que el contenido puede modificarse durante est este e proceso. Por ejemplo, los encabezados "x"x sender" y "x-receiver" receiver" no se copian al contenido que se escribe en el archivo del directorio \Queue. El siguiente ejemplo muestra un mensaje de texto de Internet con información de encabezado ampliada acerca de llos os destinatarios y el remitente. El encabezado "x"x receiver" identifica un único destinatario. Si desea incluir varios destinatarios, agregue un encabezado "x-receiver" receiver" para cada destinatario. Los encabezados deben aparecer en primer lugar en el archivo de texto y el primer encabezado debe ser "x-sender". "x Según RFC 822, debe existir una línea vacía entre la información de encabezado y el cuerpo del mensaje. El nombre de archivo del elemento del mensaje es irrelevante. El servicio SMTP utiliza su propia lógica ica para dar nombre al archivo de mensaje del directorio \Queue y agregar una extensión de nombre de archivo .eml, por ejemplo NTFS_7224ae2001c4125c0000001b.eml. x-sender: sender: [email protected] x-receiver: receiver: [email protected] From: [email protected] To: [email protected] abrikam.com Subject: RFC 822 Pickup Message

This message is passed to the SMTP service through the \Pickup Pickup directory.

302

Nota: Debe crear los mensajes de texto en otra carpeta del sistema de archivos y moverlos a la carpeta \Pickup. Pickup. Para evitar conflictos con el servicio de supervisión de SMTP, no cree los archivos directamente en la carpeta \Pickup. •

\Queue Esta carpeta contiene contiene todos los mensajes recibidos a través de SMTP que están a la espera de ser transferidos a un destino remoto a través de SMTP. No obstante, los mensajes recibidos a través del almacén de Exchange no se encuentran en este directorio durante el procesamie procesamiento nto en el subsistema de transporte SMTP. Los mensajes pueden acumularse en esta carpeta si una conexión está ocupada o no está disponible. Nota: El motor de cola avanzada intenta reenviar los mensajes de la carpeta \Queue a intervalos designados. Estos intervalos pueden configurarse en el Administrador del sistema de Exchange, en las propiedades del servidor virtual SMTP, en la ficha Entrega.. Sin embargo, e el contenido de la carpeta \Queue Queue no se examina a intervalos. El contenido de esta carpeta sólo se examina al iniciar un servicio o cuando se reinicia un servidor virtual SMTP.

•

\Filter De forma predeterminada, esta carpeta no existe. Se crea automáticamente au cuando se filtra el primer mensaje, después de habilitar el filtrado de mensajes en un servidor virtual determinado. Para habilitar el filtrado de mensajes, en el Administrador del sistema de Exchange, seleccione las propiedades del servidor virtual SMTP, seleccione la ficha General y, a continuación, haga clic en Avanzadas. Avanzadas Nota: También existe una carpeta \Windows\NTDS\Drop Drop que el servicio SMTP utiliza en los controladores de dominio para entregar los mensajes de replicación de directorioss entre sitios a Active Directory. La carpeta \Drop Drop no se utiliza para entregar mensajes de Exchange.

Cambio de ubicación del directorio \Mailroot Mailroot En Exchange Server 2003, el Administrador del sistema de Exchange permite cambiar de ubicación las carpetas \Badmail Badmail y \Queue Queue en el sistema de archivos (en las propiedades del servidor virtual SMTP, desde la ficha Mensajes). Las carpetas \Badmail Badmail y \Queue son las más importantes para el tratamiento de los mensajes de Exchange, puesto que son las carpetas que más utiliza el servicio SMTP. También puede cambiar de ubicación la carpeta \Pickup Pickup si establece msExchSmtpPickupDirectory para el objeto de servidor virtual SMTP en Active Directory mediante ADSI Edit (AdsiEdit.msc). El servicio de actualización de la metabase e transfiere las opciones de configuración a la metabase de IIS, tal como se ha descrito anteriormente en esta sección. No coloque el directorio \Mailroot Mailroot en una partición FAT, ya que las particiones FAT no admiten secuencias de datos alternativas hacia un objeto de archivo y, además, están

303

sometidas a otras restricciones. Por ejemplo, las particiones FAT16 admiten como máximo 65.535 archivos. Esto puede suponer un problema en los servidores cabeza de puente con mucha actividad. Si una cola empieza a llenarse, llenarse, es posible reducir las entradas para crear archivos nuevos. Sin embargo, este proceso es complicado porque cada mensaje requiere tres archivos. Puesto que las secuencias de datos alternativas no están disponibles en una partición FAT, el controlador del del almacén NTFS debe crear tres archivos distintos para cada mensaje, en lugar de un archivo con dos secuencias de datos alternativas. El rendimiento de FAT no es óptimo en grandes volúmenes porque proporciona una tolerancia a errores mínima y una capacidad de recuperación nula cuando se produce una parada inesperada del sistema. El rendimiento mejorará si coloca el directorio \Mailroot Mailroot en un subsistema de disco de alto rendimiento, como una matriz redundante de discos independientes (RAID). Una RAID 0+1 que disponga entre ocho y diez discos es un buen punto de inicio para la entrega de mensajes de gran volumen. Un controlador RAID con una capacidad de caché de más de 64 megabytes (MB) también contribuye a mejorar el rendimiento. Nota: Cada mensaje procesa procesado do por el motor del protocolo SMTP se confirma en el disco y, a continuación, se lee en un objeto MailMsg.

Controlador del almacén de Exchange El controlador del almacén de Exchange soluciona un problema interesante de la arquitectura de transporte de Exchange Exchange Server 2003. Los subprocesos del motor de cola avanzada se ejecutan en el proceso Inetinfo, pero no todos los mensajes se reciben a través del motor del protocolo SMTP. Tal y como se muestra en la figura siguiente y se ha descrito en Arquitectura de enrutamiento de mensajes, mensajes, los mensajes procedentes de los clientes MAPI, como Outlook y del MTA de Exchange se transfieren al subsistema de transporte SMTP MTP a través del servicio Almacén de información de Microsoft Exchange. Puesto que no se reciben a través del motor del protocolo SMTP, estos mensajes deben transferirse al motor de cola avanzada de otra forma. El controlador del almacén de Exchange ofrece este método alternativo. Además, puede que los mensajes no abandonen un servidor en el que se ejecuta Exchange Server 2003 a través del motor del protocolo SMTP. Los mensajes pueden dirigirse a un destinatario con un buzón en el almacén local de Exchange, en cuyo caso el mensaje se entrega a través del controlador del almacén de Exchange. Los mensajes para los destinatarios remotos a los que se llega por medio del MTA de Exchange también deben transferirse al almacén de Exchange porque la cola de mensajes salientes del MTA de Exchange está ubicada en el almacén de Exchange. El MTA de Exchange controla la transferencia de mensajes a los servidores en los que se ejecuta Exchange 5.5 en el grupo de enrutamiento local, a los MTA de Exchange remotos y MTA X.400 que no son de Exchange mediante un conector X.400, o a los sistemas de mensajería distintos de Exchange mediante un conector de mensajería basado en MAPI. Para obtener más información acerca del MTA de Exchange, consulte Arquitectura de transporte X.400. X.400

304

Transferencia de mensajes no SMTP a través del motor de cola avanzada

Arquitectura del controlador del almacén de Exchange Es importante tener presente que el almacén de Exchange (Store.exe) y el proceso IIS Inetinfo (Inetinfo.exe) son procesos independientes del sistema operativo, como se indica en la figura siguiente. Los procesos independientes no comparten sus espacios de direcciones virtuales directamente entre sí, por lo que Inetinfo.exe no tiene acceso a los datos del espacio de direcciones virtuales de Store.exe y viceversa. Para colocar un mensaje MAPI en la cola de envío previo del motor de cola avanzada, el controlador del almacén de Exchange debe transferir una llamada a funciones desde el espacio de direcciones virtuales de Store.exe al espacio de direcciones virtuales del proceso Inetinfo. El controlador del almacén de Exchange también debe transferir una llamada a funciones en la otra dirección, desde el proceso IIS Inetinfo al almacén de Exchange, para la entrega local al buzón de un destinatario o a la cola de mensajes del MTA de Exchange.

305

Arquitectura del controlador del almacén de Exchange

El receptor de sucesos del controlador del almacén de Exchange utiliza los tres componentes clave siguientes para habilitar la comunicación entre procesos entre el almacén de Exchange e Inetinfo. El conjunto de estos componentes forma el controlador del almacén de Exchange. •

Drviis.dll Esta DLL se ejecuta en el proceso Inetinfo y se comunica con el motor de cola avanzada a través de los sucesos COM StoreDriver de SMTP.

•

Epoxy.dll Esta DLL implementa la capa de comunicaciones entre procesos de Exchange (ExIPC) entre IIS y el almacén de Exchange. IIS IIS y el almacén de Exchange utilizan esta capa de comunicaciones para intercambiar datos rápida y directamente entre los límites del proceso. Esto se consigue mediante la memoria compartida que se carga por medio de esta DLL en el espacio de direcciones virtuales virtuales de ambos procesos. El modelo de memoria compartida de Epoxy.dll está basado en el modelo Cola circular de memoria compartida (SMQ). Esto significa que dentro de la capa Epoxy.dll se utilizan colas circulares individuales de tamaño fijo para la transferencia transferencia de datos en ambas direcciones. La capa Epoxy.dll incluye una herramienta de enlace que permite al controlador del almacén crear y conectar un número arbitrario de colas circulares entre IIS y el almacén de Exchange. Esta herramienta de enlace incluye incluye un administrador central de colas que supervisa las colas que se comunican a través de este proceso. También se utiliza para desenlazar y limpiar las colas. Nota: Epoxy.dll utiliza llamadas a procedimiento remoto/local (LRPC) y un montón de memoria ria compartida para transferir los datos entre IIS y el almacén de Exchange. La memoria compartida solamente funciona para los procesos que se ejecutan en el mismo equipo. La comunicación entre procesos remotos, como en el caso de las llamadas a procedimiento procedimiento remoto (RPC), no es posible mediante Epoxy.dll.

•

ExSMTP.dll Esta DLL se ejecuta en el proceso del almacén de Exchange e implementa el código auxiliar del protocolo para comunicarse con el almacén de Exchange a través de EPOXY y la interfaz Inetinfo de Dviis.dll.

306

Sistema de archivos instalable de Exchange Para minimizar las diferencias entre el controlador del almacén de Exchange y el controlador del almacén NTFS que se incluye en Windows Server 2003, Exchange Server 2003 implementa un sistema de arch archivos ivos Microsoft Win32 sobre las bases de datos de secuencias (.stm) en el almacén de Exchange. El archivo .stm de un almacén de Exchange guarda los mensajes de Internet en su formato original (texto sin formato, MIME o UUEncode), mientras que el archivo .edb b correspondiente almacena los mensajes en formato MAPI. Una base de datos de secuencias carece de una estructura de directorios en el archivo .stm. Las estructuras del almacén de Exchange se mantienen en tablas de mensajes en el archivo .edb. En Arquitectura del servicio Almacén de información de Exchange, Exchange, encontrará información adicional acerca de la arquitectura y el diseño de las bases bases de datos de mensajería. El sistema de archivos instalable de Exchange está formado por los siguientes componentes principales (que se muestran en la figura siguiente): •

Exifs.sys Controlador de modo de núcleo que el controlador del almacén de Exchange Exc puede usar para leer o escribir elementos en las bases de datos de mensajería. Este controlador proporciona la API de archivos Win32 para el almacén de Exchange.

•

Exwin32.dll Extensión del almacén de Exchange que se ejecuta en el proceso Store.exe y controla las solicitudes de las operaciones de nivel de archivo (por ejemplo, crear, abrir, cambiar de nombre, confirmar, eliminar, etc.) de Exifs.sys. Tenga presente que se trata de un componente de modo de usuario utilizado para las operaciones del sistema stema de archivos Win32. El subsistema de transporte SMTP no utiliza archivos Win32.

•

Ifsproxy.dll Empaquetador de modo de usuario de Exwin32.dll que proporciona una interfaz directa para las llamadas del sistema de archivos Win32. Ifsproxy.dll también desempeña un papel determinante en la asignación de espacio libre en el archivo .stm. ExIFS solicita espacio de ESE cuando asigna espacio libre en una base de datos. Por ejemplo, si el controlador del almacén de Exchange crea un elemento nuevo en el almacén n de Exchange para entregar un mensaje localmente, ExIFS solicita espacio de ESE.

ExIFS admite el acceso a archivos en dos modos distintos. •

Win32 Este modo se basa en los nombres de archivo y sirve para que el almacén de Exchange esté visible en el ssistema istema de archivos de una forma parecida a una unidad de disco. El sistema operativo asigna el espacio de nombres de archivo \\.\backofficestorage al sistema de archivos instalable de Exchange. Este espacio de nombres proporciona acceso a todas las bases d de e datos privadas y públicas. El formato es file://./backofficestorage/ file://./backofficestorage/nombreDeDominio, por ejemplo file://./backofficestorage/fabrikam.com. Nota: El protocolo HTTP-DAV HTTP DAV y las API EXOLEDB y CDOEX utilizan principalmente los archivos Win32.

307

•

EA EA es el acrónimo correspondiente a atributos extendidos (EA, Extended Attributes), que se almacenan en una propiedad especial de cada mensaje. ExIFS copia los atributos extendidos a una estructura en memoria denominada lista de dispersión (SLIST). La lista de dis dispersión persión es básicamente un objeto binario de gran tamaño (BLOB) que puede utilizarse para abrir un elemento de mensaje. Los archivos EA están destinados al uso interno por parte del subsistema de transporte de Exchange y no están visibles para los usuarios a través de ninguna de las API o protocolos documentados. Las rutas de acceso EA son parecidas a ésta: \;E:\Ted\$705260a-46c4 46c4-454d-b0dd96b9c605364\369b6c05 369b6c05-0256-46c7-fad3-54ffa867d089-0000001e. Nota: Los componentes del subsistema de transporte SMTP utilizan exclusivamente atributos extendidos para abrir archivos en ExIFS.

Integración de IIS y el almacén de Exchange

Transferencia de mensajes salientes El controlador del almacén de Exchange debe realizar los pasos siguientes para transferir un mensaje saliente a la cola de envío previo del motor de cola avanzada. 1. Cuando un usuario de Outlook envía un mensaje, éste se coloca en la Bandeja de salida del el buzón del usuario y se marca para su entrega. 2. El almacén de Exchange coloca el mensaje en su carpeta SendQ interna y llama al controlador del almacén de Exchange para transferir el mensaje a IIS. 3. ExSMTP.dll determina el identificador de carpeta (FID) (FID) y el identificador de mensaje (MID) del mensaje y lee las propiedades del mensaje relativas al transporte (como las direcciones del remitente y el destinatario y si se solicitan o no informes de entrega).

308

ExSMTP.dll cambia el formato de estas propieda propiedades des por una secuencia de propiedades para el objeto MailMsg. ExSMTP.dll incluye el FID y el MID del mensaje para que Drviis.dll pueda recuperar más adelante, si es necesario, el contenido del mensaje del lado de Inetinfo. El FID identifica de forma única la la carpeta de mensajes del almacén de Exchange que contiene el mensaje. El MID identifica de forma exclusiva el mensaje. Nota: El sobre del mensaje no incluye el contenido del mensaje. Epoxy.dll se utiliza para transferir la información del sobre del men mensaje saje a Inetinfo. ExIFS.sys se utiliza para ordenar el contenido del mensaje, si es necesario. Puede que nunca sea necesario obtener acceso al contenido de un mensaje si se trata de una entrega "local a local" o "local a MTA de Exchange". El contenido RFC 822 sólo se debe generar para la entrega a los destinatarios de otros almacenes de buzones, para la entrega SMTP saliente o para los receptores que solicitan el contenido durante un suceso de transporte. 4. ExSMTP.dll transfiere un puntero de la sección de memoria compartida a través de una cola circular de memoria compartida a Drviis.dll. Como se indica en la figura siguiente, el puntero hace referencia a la parte de la memoria compartida asignada que contiene la secuencia de propiedades del sobre, el Id. de de carpeta y el Id. de mensaje. Comunicación entre procesos mediante EPOXY

Nota: Para asignar y liberar memoria dinámicamente se utiliza un montón, además de los recursos que el sistema operativo asigna para el código y la pila durante el tiempo de ejecución. ecución. 5. Drviis.dll quita el puntero de la cola en el lado de Inetinfo (es decir, elimina el puntero de la cola de memoria circular). El puntero hace referencia a la memoria compartida que contiene la secuencia de propiedades del sobre, el Id. de carpeta carpeta y el Id. de mensaje. 6. Drviis.dll utiliza el puntero de memoria para leer la secuencia de propiedades de la memoria compartida en el objeto MailMsg. Como se ha mencionado anteriormente en esta sección, el objeto MailMsg está formado por un sobre de tra transferencia nsferencia de mensajes que proporciona la información necesaria para enrutar el mensaje hasta el siguiente salto, así como un puntero que señala al mensaje físico real. En este punto, el objeto MailMsg tiene en su poder la información del sobre de transfer transferencia encia de mensajes porque

309

todas las propiedades de MailMsg se encuentran en el bloque de memoria compartido preparado por ExSMTP.dll. 7. Drviis.dll coloca el objeto MailMsg en la cola de envío previo. El subsistema de transporte ya puede procesar el mensaje. mensaje 8. El motor de cola avanzada desencadena sus sucesos de transporte y sistema para invocar a los categorizadores base y de Exchange y al motor de enrutamiento, así como otros receptores de sucesos registrados para procesar el mensaje. La mayor parte del procesamiento rocesamiento del transporte tiene lugar en el sobre de transferencia de mensajes. El contenido del mensaje no se abre hasta que se requiere explícitamente. Por ejemplo, puede que el categorizador de Exchange deba realizar una conversión de contenido. Si el mensaje debe transferirse al siguiente salto a través de SMTP, el motor del protocolo SMTP debe obtener acceso al contenido del mensaje en formato RFC 822. Nota: Para la entrega local de mensajes MAPI (enviados y recibidos en el mismo servidor sin conv conversión ersión de contenido), los componentes del transporte SMTP nunca abren el contenido (si no ha instalado ningún receptor de sucesos personalizado que intente leer el contenido de los mensajes RFC 822, como pueda ser un receptor de archivos). 9. Cuando un componente mponente del subsistema de transporte abre el contenido del mensaje mediante una llamada al método ReadContent o WriteContent del objeto MailMsg, se obtiene acceso al contenido del mensaje como archivo, de forma parecida a un elemento de mensaje de la carp carpeta \Queue Queue del sistema de archivos (por ejemplo, mensajes que deben enviarse a través de SMTP). Cuando los mensajes se envían a través del almacén de Exchange, se utilizan los archivos ExIFS en lugar de los archivos NTFS. 10. Para los mensajes del almacén de Exchange, MailMsg llama a Drviis.dll para abrir un identificador de archivo ordinario. El contenido del mensaje se solicita en el formato RFC 822. Para los mensajes categorizados, es posible que la secuencia de propiedades también contenga algunos valores valores de conversión saliente adicionales que se pueden utilizar para solicitar un formato específico cuando se recupera el contenido. 11. Como se ha mencionado anteriormente en esta sección, Drviis.dll guarda un puntero que señala al mensaje físico en el objeto objeto MailMsg. Este puntero está formado por el Id. de mensaje y el Id. de carpeta del mensaje. Drviis.dll utiliza este puntero y cualquier parámetro de formato de contenido adicional para transferir un paquete de solicitud del mensaje a través de Epoxy.dll h hasta asta Exsmtp.dll dentro del proceso Store.exe. 12. Exsmtp.dll llama a un método interno del almacén de Exchange denominado EcGetMime con el Id. de carpeta y el Id. de mensaje para solicitar el contenido del mensaje en formato RFC 822, especificando cualquier cualquier parámetro adicional que Drviis.dll haya podido transferir. Nota: Puede que la llamada EcGetMime en las entradas del registro de sucesos de la aplicación vaya acompañada de un origen de suceso de MSExchangeTransport

310

y una categoría de suceso del controlador del almacén de Exchange. Para ver un ejemplo, consulte el artículo 319682 de Microsoft Knowledge Base, "XGEN: " The Exchange 2000 Information Store Reports an Event ID327 Warning Warni Message and Virtual Memory May Be FragmentedXGEN: FragmentedXGEN: The Exchange 2000 Information Store Reports an Event ID327 Warning Message and Virtual Memory May Be Fragmented". 13. Dado que el mensaje se envió a través de Outlook, el mensaje no está en formato RFC 822. El mensaje está en formato MAPI y almacenado en el archivo .edb. Por lo tanto, el contenido que Exsmtp.dll solicita no existe en la base de datos de secuencias (que ExIFS utiliza) cuando un componente de transporte o cliente de Internet abre el mensaj mensaje. Nota: Exchange Server 2003 almacena los mensajes recibidos de los clientes MAPI, los conectores X.400 o los conectores basados en el Kit de desarrollo de Exchange (EDK) en formato MAPI en la base de datos .edb. 14. Si el mensaje no existe en la base de datos de secuencias, deberá crearse mediante las distintas propiedades y tablas de la base de datos .edb que describe al mensaje. Consecuentemente, el almacén de Exchange utiliza IMAIL para crear un archivo ExIFS temporal y presentar el mensaje de la base base de datos a ese archivo en formato RFC 822,según los parámetros de formato solicitados que se han transferido. Nota: El categorizador de Exchange utiliza el mecanismo IMAIL para aplicar los formatos de mensaje al contenido, tal como se define para lo loss dominios de Internet en el Administrador del sistema de Exchange o como especifica el usuario para cada destinatario en Outlook. Si no se transfieren parámetros de formato a IMAIL, IMAIL formatea los mensajes MAPI en formato Summary-TNEF Summary (S/TNEF). 15. En Exchange Server 2003, ExIFS.sys crea un archivo ExIFS temporal para que los receptores de sucesos erróneos que intentan modificar el contenido RFC 822 no puedan dañar las páginas confirmadas en la base de datos de secuencias. En lugar de escribir en las páginas áginas reales de contenido, el receptor de sucesos escribe sólo en una copia. 16. Cuando el archivo ExIFS se ha generado, el identificador del archivo se vuelve a transferir a Exsmtp.dll. Exsmtp.dll llama a ExIFS para recuperar un puntero que señala a las páginas que ocupa el archivo en la base de datos de secuencias (es decir, a los atributos extendidos que ExIFS copia en una estructura en memoria denominada lista de dispersión). 17. Exsmtp.dll copia la lista de dispersión en la memoria compartida y la vu vuelve a transferir a Drviis.dll a través de Epoxy.dll. 18. Drviis.dll utiliza esta lista de dispersión para abrir el archivo ExIFS como un archivo de atributos extendidos (EA). Ahora que Drviis.dll dispone del identificador del archivo ExIFS abierto, devuel devuelve ve el identificador del archivo a MailMsg para que pueda procesar

311

las solicitudes ReadContent o WriteContent con respecto al contenido de mensaje RFC 822. 19. Ahora, el motor del protocolo SMTP puede leer el contenido del mensaje y transferir los datos a un n host remoto o a un servidor de Exchange a través de SMTP. 20. Después de transferir correctamente el mensaje, el motor de cola avanzada elimina el objeto MailMsg porque ya no se necesita. Consecuentemente, el motor de cola avanzada llama al controlador d del el almacén de Exchange (drviis.dll) para eliminar el mensaje. Drviis.dll crea una solicitud para eliminar el mensaje de la memoria compartida y transfiere la solicitud a través de EPOXY a Exsmtp.dll. A continuación, Exsmtp.dll mueve el mensaje de la Bandeja Bandeja de salida del remitente a la carpeta Elementos enviados, o bien elimina el mensaje. Nota: El contenido se vuelve a presentar cada vez que se solicita. Cuando el contenido se solicita, se devuelve en un archivo ExIFS temporal. El archivo puede utilizarse utilizars siempre que esté abierto. Cuando se cierra, se descarta automáticamente porque sólo es una copia temporal del mensaje. Para minimizar el número de ciclos de presentación, el motor de cola avanzada mantiene abierto el archivo de contenido hasta que el mensaje saje se transfiere o entrega. El archivo de contenido sólo se cierra cuando los mensajes están preparados para eliminarse o se han programado para un reintento posterior. Los mensajes pueden reintentarse posteriormente porque el servidor remoto no está dis disponible ponible o porque hay más de 10.000 archivos de contenido abiertos y que se procesan activamente en la cola. Si hay más de 10.000 archivos de contenido abiertos que se procesan activamente, deben cerrarse algunos archivos para dejar espacio para otros mensajes. mensajes. Cuando un mensaje se vuelve a abrir más tarde (por ejemplo, porque se reintenta la transferencia del mensaje), el contenido debe presentarse de nuevo. Es importante tener en cuenta de que IMAIL presenta un nuevo archivo ExIFS temporal cuando el archivo archiv se abre. Los cambios realizados en este archivo ExIFS se pierden cuando se cierra el archivo.

Transferencia de mensajes entrantes El controlador del almacén de Exchange lleva a cabo los siguientes pasos para los mensajes entrantes que deben entregarse a un destinatario local o al MTA de Exchange. 1. Se coloca un mensaje en la cola de envío previo a través del motor del protocolo SMTP o del controlador del almacén de Exchange y, a continuación, este mensaje se categoriza y marca para la entrega local. 2. El motor de cola avanzada desencadena un suceso StoreDriver de SMTP para indicar al receptor Controlador del almacén de Exchange que un mensaje debe transferirse al almacén de Exchange.

312

3. Si el mensaje se recibe a través de una conexión SMTP o de la carpeta carpeta \Pickup, el mensaje todavía se encuentra en la carpeta \Queue. Queue. En consecuencia, Drviis.dll llama a CreateFile() para crear un archivo nuevo en ExIFS y copia el elemento del mensaje al nuevo archivo en el almacén de Exchange. Nota: Si los mensajes se envían y reciben en el mismo almacén de buzones, el contenido no se copia al almacén. Si se envían y reciben en almacenes de buzones diferentes del mismo servidor, el mensaje se copia con RFC 822 S/TNEF como formato intermedio. No se ordena el contenido del del almacén de Exchange al proceso Inetinfo. El procesamiento se realiza en el almacén de Exchange. IMAIL presenta el contenido en formato S/TNEF en un archivo ExIFS cuando Exsmtp.dll lo solicita. El almacén de Exchange utiliza este archivo ExIFS para construir ruir un mensaje nuevo para la entrega en un almacén de buzones que contiene el buzón del destinatario. 4. En el caso de SMTP/Pickup, ExIFS devuelve la lista de dispersión en la que se indica la ubicación de los datos del elemento nuevo en la base de datos de secuencias. 5. Drviis.dll asigna memoria del montón de memoria compartida y coloca la lista de dispersión en el bloque de memoria asignada. A continuación, un puntero que señala a esa parte de memoria compartida asignada se coloca en la cola en la dirección direc del proceso Store.exe. 6. ExSMTP.dll obtiene el puntero de la cola en el lado del almacén de Exchange. El puntero hace referencia a la memoria compartida que contiene la lista de dispersión del mensaje entrante. 7. ExSMTP.dll llama a Ifsproxy.dll con la lista de dispersión para recibir un identificador de archivo desde ExIFS. Para confirmar el elemento en la base de datos debe crearse un mensaje, por lo que ExSMTP.dll llama al núcleo del almacén de Exchange (Store.exe) a través de la interfaz externa d de e la base de datos de mensajería (MDBEIF) para crear un objeto de mensaje. A continuación, ExSMTP.dll transfiere explícitamente el identificador de archivo del contenido al núcleo del almacén de Exchange y éste transfiere el identificador de archivo a ESE para confirmar los datos cuando ExSMTP.dll confirma el objeto de mensaje. Nota: Las sumas de comprobación de las páginas se almacenan en archivos de base de datos basados en MAPI (.edb). El archivo de base de datos de secuencias (.stm) no contiene sumas suma de comprobación de páginas. 8. El almacén de Exchange informa a Outlook cuando llega un mensaje nuevo y Outlook muestra el mensaje en la carpeta Bandeja de entrada. 9. ExSMTP.dll comunica a Drviis.dll a través de EPOXY que la entrega se ha realizado y, a continuación, Drviis.dll devuelve un resultado positivo al motor de cola avanzada. Después, el motor de cola avanzada puede eliminar el mensaje de una de las siguientes maneras:

313

•

El mensaje se ha recibido a través de SMTP o del directorio \Pickup Pickup Hay un archivo .eml en el directorio \Queue Queue para el mensaje. El motor de cola avanzada vuelve a llamar a MailMsg para eliminar el mensaje. Puesto que el objeto MailMsg está enlazado al controlador del almacén NTFS, la llamada se transfiere a NTFSDrv.dll, que elimina limina el mensaje del directorio \Queue Queue en el sistema de archivos.

•

El mensaje se ha enviado a través del controlador del almacén de Exchange El motor de cola avanzada vuelve a llamar a MailMsg para eliminar el mensaje. Puesto que el objeto MailMsg está enlazado al controlador del almacén de Exchange, la llamada se transfiere a Drviis.dll, que pone en cola una solicitud EPOXY para ExSMTP.dll. A continuación, ExSMTP.dll mueve el mensaje de la Bandeja de salida del remitente a la carpeta Elementos enviados o elimina el mensaje.

Nota: Los mensajes para destinatarios remotos que llegan a través del directorio \Pickup o el motor del protocolo SMTP no llegan al almacén de Exchange. Permanecen en la carpeta \Queue Queue del sistema de archivos hasta que se transfier transfieren en correctamente al siguiente salto hacia su destino. Sin embargo, el categorizador puede utilizar el almacén de Exchange para los mensajes que no se entregan a través del controlador del almacén de Exchange. Puede que el categorizador deba generar notificaciones aciones de estado de entrega, que se crean en el almacén de Exchange.

Reintentos de transferencia Tenga en cuenta que los mensajes que entran en el motor de cola avanzada a través del controlador del almacén de Exchange permanecen en el almacén de Exchange durante el proceso de categorización y enrutamiento, así como durante el proceso de transferencia real. El mensaje no se copia a la carpeta \Queue Queue del servidor virtual SMTP. Estos tipos de mensajes también permanecen en el almacén de Exchange si se produce produc un error de conexión y debe reintentarse. Si un mensaje no se puede transferir inmediatamente, se mueve a una tabla temporal. Por lo tanto, el mensaje desaparece de la carpeta Bandeja de salida del remitente y se copia en la carpeta Elementos enviados (s (sii Outlook se ha configurado para conservar una copia de todos los mensajes en la carpeta Elementos enviados). El mensaje permanece en la tabla temporal hasta que caduca o se transfiere correctamente. Puede ver estos mensajes en la cola Error de reintento d de e mensajes mediante el complemento Visor de cola en el Administrador del sistema de Exchange.

Extensiones del protocolo SMTP El motor de cola avanzada no es el único distribuidor de sucesos COM del servicio SMTP. El motor del protocolo SMTP es otro distribuidor distribuidor importante de sucesos COM, en concreto de sucesos de protocolo SMTP. El motor del protocolo SMTP principal es el responsable de todas las comunicaciones SMTP estándar y controla la mayoría de extensiones del servicio

314

SMTP estándar (es decir, el estándar Protocolo simple de transferencia de correo extendido (ESMTP), tal como se define en RFC 821 y RFC 1869). Los sucesos de protocolo pueden utilizarse para modificar el protocolo SMTP a fin de agregar nuevos comandos de ESMTP o incluso cambiar la acción de los comandos existentes. Exchange Server 2003 utiliza estos sucesos de protocolo para implementar comandos SMTP extendidos específicos de Exchange para comunicarse con otros servidores de Exchange en la organización con más eficacia que a través de SMTP estándar. Puede comprobar si los comandos SMTP extendidos para Exchange Server 2003 se cargan cuando se conecta al puerto TCP de su servidor virtual SMTP mediante telnet. En la figura siguiente, la respuesta del servidor indica las características que el servidor virtual SMTP admite cuando ejecuta el comando EHLO para iniciar una conexión ESMTP. Los comandos estándar se muestran cuando ejecuta un comando HELP. Comandos SMTP estándar y extendidos de Exchange Server 2003

La tabla siguiente describe las características de SMTP admitidas por el servicio SMTP extendido por Exchange. Características de SMTP admitidas en Exchange Server 2003 Respuesta del servidor SMTP

Comentarios

8BITMIME

Indica que el servidor virtual SMTP local admite mensajes MIME (Extensiones multipropósito de correo Internet) de ocho bits.

315

Respuesta del servidor SMTP

Comentarios

AUTH, AUTH GSSAPI NTLM LOGIN y AUTH=LOGIN

Indica que el servidor virtual SMTP local admite la extensión del servicio de autenticación de SMTP. La información adicional después de la palabra clave AUTH identifica los mecanismos de autenticación admitidos.

BDAT, CHUNKING

Alternativa al comando DATA, que utiliza dos argumentos. Cuando un servidor virtual SMTP responde a la palabra clave EHLO con CHUNKING, el servidor SMTP indica que admite el comando BDAT y que aceptará mensajes fragmentados. El primer argumento indica la longitud del paquete de datos binarios para que el host SMTP no deba explorar continuamente el final de los datos. El servidor de recepción cuenta los bytes del mensaje y, cuando el tamaño del mensaje es igual que el valor enviado por el comando BDAT, supone que ha recibido todos los datos del mensaje. El segundo argumento indica si el paquete de datos es el último paquete de la transmisión actual. El segundo argumento es opcional.

BINARYMIME

Indica que el servidor virtual SMTP acepta mensajes que contienen material binario sin codificación de transporte mediante un parámetro BODY con un valor "BINARYMIME" en el comando MAIL. Cuando el servidor SMTP acepta un comando MAIL con un parámetro BODY de valor BINARYMIME, el servidor conserva todos los bits de cada octeto transferido mediante el comando BDAT. La extensión SMTP BINARYMIME sólo se puede usar con CHUNKING.

DATA

Enviado por un host remoto para iniciar la transferencia del contenido del mensaje.

316

Respuesta del servidor SMTP

Comentarios

DSN

Comando ESMTP que habilita las notificaciones de estado de entrega tal como se define en la Solicitud de comentarios (Request for Comments, RFC) 1891.

EHLO

Enviado por un cliente para indicar el inicio de una sesión ESMTP. El servidor puede identificar su compatibilidad con los comandos ESMTP en su respuesta a EHLO (figura 6.14).

ENHANCEDSTATUSCODES

Indica que el servidor SMTP proporciona códigos de estado de error mejorados. Las partes de texto de todas las respuestas de estado de SMTP, salvo el saludo inicial y las respuestas a HELO o EHLO, están precedidas por un código de estado tal como se define en RFC 1893.

ETRN

Enviado por un servidor SMTP para solicitar que el servidor virtual local envíe los mensajes de correo electrónico que tiene en la cola para los dominios indicados en el comando ETRN.

HELO

Enviado por un cliente para identificarse, normalmente con un nombre de dominio, y para indicar el inicio de una sesión SMTP estándar.

HELP

Muestra una lista de comandos SMTP admitidos por el servidor virtual SMTP en las sesiones SMTP estándar (a diferencia de las sesiones ESMTP).

MAIL

Identifica el inicio de una transferencia de mensaje mediante la identificación del remitente del mensaje; se utiliza con el formato MAIL FROM.

PIPELINING

Permite enviar una secuencia de comandos sin esperar una respuesta de cada comando.

QUIT

Indica el final de una sesión SMTP estándar o extendida.

317

Respuesta del servidor SMTP

Comentarios

RCPT

Identifica a los destinatarios del mensaje; se utiliza con el formato RCPT TO.

RSET

Anula toda la transacción del mensaje y restablece el búfer.

SIZE

Proporciona un mecanismo mediante el cual el servidor virtual SMTP puede indicar el tamaño máximo de mensaje admitido. Los servidores compatibles deben proporcionar extensiones de tamaño para indicar el tamaño máximo de mensaje que pueden aceptar. Los hosts remotos no deben enviar mensajes de un tamaño mayor que el indicado por el servidor.

STARTTLS

Indica que el servidor SMTP admite SMTP seguro a través de Seguridad de nivel de transporte (TLS). La extensión del servicio SMTP para SMTP seguro a través de TLS está definida en RFC 2487.

TURN

Permite que un host remoto y un host local intercambien funciones y envíen correo en la dirección contraria, sin establecer una nueva conexión.

VRFY

Comprueba que el buzón está disponible para la entrega de mensajes. Por ejemplo, VRFY TED comprueba que un buzón para Ted se encuentra en el servidor local. Este comando está disponible en Exchange 2003 de forma predeterminada, pero no comprueba usuarios. El servidor comunicará al host remoto que, aunque el usuario no puede comprobarse, los mensajes se aceptarán. El formato de la respuesta del servidor es el siguiente: 252 2.1.5 No se puede VRFY el usuario, pero se aceptará el mensaje para

318

Respuesta del servidor SMTP

Comentarios

XEXCH50

Ofrece la posibilidad de enviar las propiedades extendidas del sobre de transporte de mensajes en formato MDBEF (Formato de codificación de base de datos de mensajes) durante una comunicación entre servidores de Exchange Server 2003.

X-EXPS GSSAPI NTLM TLM LOGIN, XX EXPS=LOGIN

X-EXPS EXPS es un comando exclusivo de Exchange. Es parecido a AUTH porque indica los métodos que los servidores en los que se ejecuta Exchange Server 2003 o Exchange 2000 Server pueden utilizar para realizar la autenticación, de la siguiente sigu manera:

X-LINK2STATE

•

GSSAPI Método que significa Generic Security Services Application Programming Interface y que permite la autenticación a través de Kerberos.

•

NTLM Método que significa Windows NT y LAN Manager y que permite la autenticación mediante el protocolo de desafío/respuesta de Windows NT.

•

LOGIN Método que significa AUTH LOGIN, un método de autenticación por texto sin formato mediante un nombre de usuario y una contraseña codificadas en base 64.

Ofrece compatibilidad para la propagación pr de estado de vínculos al servicio SMTP. Para obtener más información acerca del algoritmo de estado de vínculos utilizado para propagar la información de estado de vínculos dentro de grupos de enrutamiento y entre ellos, consulte Arquitectura de enrutamiento de mensajes. mensajes

Nota: Todos los comandos SMTP específicos de Exchange empiezan con "X-" "X (sin comillas). Si estos comandos no se incluyen en en la respuesta EHLO del servidor virtual SMTP, en el servidor se ejecuta la versión básica de Windows Server 2003

319

del servicio SMTP. En tal caso, debe reinstalar Exchange Server 2003 y todos los Service Packs.

Categorías de sucesos de protocolo El motor del protocolo SMTP desencadena sucesos de protocolo para controlar la comunicación entre hosts. Existen tres tipos principales de sucesos que pueden producirse en este tipo de comunicación a través de SMTP: •

El servicio SMTP recibe un comando SMTP Estos sucesos se producen cuando un host o cliente SMTP remoto se conecta al servicio SMTP local y establece una sesión al enviar un comando HELO o EHLO. Los sucesos de esta categoría son sucesos OnInboundCommand del protocolo SMTP en conexiones entrantes.

•

El servicio SMTP recibe una respuesta SMTP Estos sucesos se producen cuando el servicio SMTP local recibe respuestas a los comandos SMTP salientes desde un host o cliente SMTP remoto. Los sucesos de esta categoría son sucesos OnServerResponse del protocolo SMTP en conexiones salientes.

•

El servicio SMTP envía un comando SMTP Estos sucesos se producen cuando el servicio SMTP local se conecta a un host SMTP remoto y establece una sesión para transferir mensajes. Los sucesos de esta categoría son sucesos OnSessionBegin, OnMessageStart, OnPerRecipient, OnBeforeData y OnSessionEnd del protocolo SMTP en conexiones salientes.

En la tabla siguiente se resume la finalidad de cada suceso de protocolo SMTP. Sucesos de protocolo del servicio SMTP Suceso

Comentarios

OnInboundCommand

Se produce cuando el servicio de protocolo SMTP recibe un comando SMTP, lo que ofrece a un receptor de sucesos la oportunidad de responder.

OnServerResponse

Se produce cuando el servicio SMTP recibe una respuesta SMTP a un comando SMTP enviado con anterioridad.

OnSessionBegin

Se produce antes de transmitir el comando EHLO.

OnMessageStart

Se produce antes de transmitir el comando MAIL FROM.

OnPerRecipient

Se produce antes de transmitir el comando RCPT TO.

320

Suceso

Comentarios

OnBeforeData

Se produce antes de transmitir el comando de protocolo DATA.

OnSessionEnd

Se produce antes de transmitir el comando QUIT.

Extensiones del protocolo SMTP específicas de Exchange El programa de instalación de Exchange Server 2003 registra las extensiones del protocolo SMTP específicas de Exchange para las siguientes características del protocolo SMTP: •

XEXCH50 Esta característica se implementa mediante nueve receptores de sucesos para permitir una comunicación total entre dos servidores en los que se ejecuta Exchange Server. La tabla siguiente muestra la asignación de los sucesos de protocolo a sus receptores de sucesos XEXCH50. Todos los receptores XEXCH50 están implementados en peexch50.dll, que se encuentra en el directorio \Archivos de programa\Exchsrvr\bin.

321

Extensiones de protocolo para el comando XEXCH50 Receptor de sucesos

Suceso de protocolo

Comentarios

Receptor Exchange SMTP Protocol XEXCH50 Before Data

OnBeforeData

Notifica al receptor XEXCH50 que el comando de protocolo DATA está a punto de transmitirse. El receptor XEXCH50 dispone ahora de la oportunidad de solicitar al servicio SMTP que envíe un comando XEXCH50 en lugar de iniciar una comunicación XEXCH50.

Receptor Exchange SMTP Protocol XEXCH50 Inbound EHLO

OnInboundCommand

Notifica al receptor XEXCH50 que se ha recibido un comando EHLO.

Receptor Exchange SMTP Protocol XEXCH50 Inbound XEXCH50

OnInboundCommand

Implementa el comando XEXCH50 para iniciar una conversación XEXCH50.

Receptor Exchange SMTP Protocol XEXCH50 Inbound MAIL

OnInboundCommand

Implementa el comando MAIL en una conversación XEXCH50.

Receptor Exchange SMTP Protocol XEXCH50 Inbound RCPT

OnInboundCommand

Permite al servidor virtual SMTP local recibir información del destinatario en una comunicación XEXCH50 entrante.

Receptor de sucesos Exchange SMTP Protocol XEXCH50 Per Recipient

OnPerRecipient

Permite al servidor virtual SMTP local enviar información del destinatario en una comunicación XEXCH50 saliente.

322

Receptor de sucesos

Suceso de protocolo

Comentarios

Receptor Exchange SMTP Protocol XEXCH50 Ehlo Response

OnServerResponse

Permite al servidor virtual SMTP local recibir una respuesta después de enviar un comando EHLO al host remoto. La respuesta del host remoto puede indicar la aceptación de las comunicaciones XEXCH50. Exchange incluye XEXCH50 en la lista de comandos admitidos que se devuelven al host de conexión (figura 6.14).

Receptor Exchange SMTP Protocol XEXCH50 Response

OnServerResponse

Permite al servidor virtual SMTP local recibir una respuesta a un comando XEXCH50 saliente ejecutado previamente. Por ejemplo, si el servicio SMTP local ha ejecutado un comando XEXCH50 sin autenticación previa, el servidor remoto responde con: 504 Es necesario autenticarse primero.

323

•

Receptor de sucesos

Suceso de protocolo

Comentarios

Receptor Exchange SMTP Protocol XEXCH50 RCPT Response

OnServerResponse

Permite al servidor virtual SMTP local recibir información de estado del servidor de Exchange remoto para cada destinatario indicado con un comando RCPT saliente. Una dirección de destinatario puede estar formateada de forma incorrecta o es posible que el servidor no pueda realizar la retransmisión. Si la información del destinatario es correcta, el servidor virtual SMTP remoto vuelve a reflejar la dirección al servicio SMTP local con la información de estado, por ejemplo: 250 2.1.5 [email protected] m.

X-LINK2STATE Esta característica se implementa mediante cinco receptores de sucesos. No obstante, un receptor de sucesos se utiliza para dos sucesos distintos, tal como se describe en la tabla siguiente. Todos los receptores de sucesos X-LINK2STATE están implementados en Xlsasink.dll, que se encuentra en el directorio \Archivos de programa\Exchsrvr\bin.

324

Extensiones de protocolo para el comando X-LINK2STATE Receptor de sucesos

Suceso de protocolo

Comentarios

Receptor EHLO Inbound Command Handler para XLSA

OnInboundCommand

Notifica a los receptores de sucesos de X-LINK2STATE que se ha recibido un comando EHLO entrante.

Receptor X-LSA Inbound Command Handler

OnInboundCommand

Notifica a los receptores de sucesos de X-LINK2STATE que se ha recibido un comando X-LINK2STATE entrante.

Receptor X-LSA

OnMessageStart, OnSessionEnd

Indica el inicio (comando MAIL) y el final (comando QUIT) de una comunicación X-LINK2STATE saliente. Puesto que el servidor virtual SMTP remoto es el último destinatario del paquete Orginfo que se transmite, no es preciso especificar destinatarios en un comando RCPT saliente. Este receptor de sucesos transmite la información de estado de vínculos.

Receptor X-LSA Response Handler

OnServerResponse

Responde a un comando XLINK2STATE entrante con información acerca de cómo transmitir la información de estado de vínculos. Un ejemplo de respuesta es: 200 LAST CHUNK={00000029} MULTI (5) ({00000010} DONE_RESPONSE), que indica el último fragmento de datos enviado por este servidor virtual SMTP.

325

•

Receptor de sucesos

Suceso de protocolo

Comentarios

Receptor EHLO Response Handler para X-LSA

OnServerResponse

Responde a un comando EHLO entrante mostrando el comando X-LINK2STATE en la respuesta del servidor.

X-EXPS Estas características se implementan mediante cinco receptores de sucesos, tal como se describe en la tabla siguiente. Todas las extensiones de seguridad del protocolo están implementadas en Exps.dll, que se encuentra en el directorio \Archivos de programa\Exchsrvr\bin.

326

Extensiones de seguridad de protocolo X-EXPS

•

Receptor de sucesos

Suceso de protocolo

Comentarios

Receptor Exchange SMTP Protocol Security EXPS-EOD

OnInboundCommand

Indica el final de la transferencia de datos ( _EOD).

Receptor Exchange SMTP Protocol Security EXPS-Aux

OnInboundCommand

Indica un comando AUTH entrante.

Receptor Exchange SMTP Protocol Security EHLO

OnInboundCommand, OnServerResponse

Indica un comando EHLO entrante y responde a EHLO mostrando el comando XEXPS en la respuesta del servidor.

Receptor Exchange SMTP Protocol Security Mail

OnInboundCommand, OnServerResponse, OnMessageStart

Indica el inicio de la transferencia de datos. Este receptor de sucesos se implementa para todos los escenarios de comandos MAIL importantes. Este receptor de sucesos procesa los sucesos que indican un comando MAIL entrante, responde a un comando MAIL entrante y puede ejecutar un comando MAIL saliente.

Receptor Exchange SMTP Protocol Security EXPS

OnInboundCommand, OnServerResponse, OnSessionStart

Indica el inicio de una sesión X-EXPS. Este receptor de sucesos se implementa para todos los escenarios de comandos X-EXPS importantes. Este receptor de sucesos procesa los sucesos que indican un comando XEXPS entrante, responde al comando X-EXPS entrante y puede ejecutar un comando X-EXPS saliente.

SPAM Control Esta característica se implementa mediante tres receptores de sucesos que procesan la información del remitente y del destinatario en las conexiones SMTP

327

entrantes, tal como se muestra en la tabla siguiente. Los receptores de sucesos de control de correo no deseado (SPAM Control) están implementados en Turflist.dll, que se encuentra en el directorio \Archivos de programa\Exchsrvr\bin. Extensiones SMTP de SPAM Control Receptor de sucesos

Suceso de protocolo

Comentarios

Receptor RCPT Inbound Command Handler

OnInboundCommand

Indica un comando RCPT entrante con una dirección de destinatario que debería comprobarse.

Receptor MAIL Inbound Command Handler para TURF

OnInboundCommand

Indica un comando MAIL entrante con una dirección de remitente que debería comprobarse.

Receptor EOD Inbound Command Handler

OnInboundCommand

Indica un comando _EOD entrante.

Información adicional Para obtener información completa sobre SMTP, consulte SMTP Server (en inglés).

Registro de protocolos, registro de sucesos y seguimiento de mensajes El subsistema de transporte SMTP de Exchange Server 2003 implementa los siguientes receptores de sucesos para mantener un historial de todas las actividades del servicio SMTP: •

Receptor de registro del protocolo SMTP de Exchange Este receptor de sucesos está implementado en Protolog.dll y se registra para los sucesos OnServerResponse y OnInboundCommand del protocolo para realizar el seguimiento de todos los comandos SMTP entrantes y respuestas del servidor. El receptor de registro del protocolo se llama para los siguientes comandos SMTP: RCPT, QUIT, EHLO, X-EXPS, STARTTLS, TLS, X-LINK2STATE, HELO, XEXCH50, MAIL, RCPT, QUIT, EHLO, X-EXPS, STARTTLS, TLS, X-LINK2STATE, HELO, XEXCH50, MAIL.

•

Receptor Eventlog de SMTP Este receptor de sucesos está implementado en Tranmsg.dll y se registra para los sucesos del sistema StoreDriver y OnEventLog.

•

Receptor MsgTrackLog Este receptor de sucesos está implementado en Msgtrack.dll y se registra para el suceso del sistema OnMsgTrackLog.

328

Registro de protocolo Si mantiene un historial de todas las actividades del protocolo SMTP, puede demostrar si un mensaje determinado ha salido del servidor, comprobar si el servidor virtual SMTP realiza sus tareas como estaba previsto o sufre problemas de comunicación, así como identificar los ataques producidos desde Interne Internet. El siguiente registro de protocolos puede configurarse para un servidor virtual SMTP en el Administrador del sistema de Exchange, en la ficha General de las propiedades del servidor virtual: •

Sin registro El receptor de sucesos no realiza un seguimiento seguimiento de las actividades del protocolo SMTP.

•

Formato del archivo de registro de Microsoft IIS El receptor de sucesos realiza un seguimiento de las actividades del protocolo SMTP en un archivo de texto sin formato separado por comas. Este formato incluy incluye e la dirección IP del host remoto, el nombre de host si se especifica, la fecha y la hora de la solicitud, el código de estado, el número de bytes recibidos, el tiempo transcurrido de la solicitud, el número de bytes enviados y la acción realizada. Los ele elementos mentos se separan mediante comas y la lista no se puede personalizar. Puede configurar la ruta de acceso a los archivos de registro en el Administrador del sistema de Exchange. La ruta de acceso predeterminada al directorio del archivo de registro es Windows\System32\LogFiles. Windo Nota: Para obtener un mayor grado de detalle del registro en los archivos de texto, seleccione Formato del archivo de registro de Microsoft IIS. IIS

•

Formato del archivo de registro común NCSA El receptor de sucesos realiza un seguimiento miento de las actividades del protocolo SMTP en un archivo de texto sin formato separado por comas. Se trata de un formato ASCII que no puede personalizarse que incluye información básica, por ejemplo, el nombre del host remoto, el nombre del usuario, la fecha, echa, la hora, el tipo de comando, el código de estado y el número de bytes recibidos. Los elementos están separados mediante espacios.

•

Registro ODBC El receptor de sucesos realiza un seguimiento de las actividades del protocolo SMTP en una base de da datos tos compatible con ODBC (Conectividad abierta de bases de datos), por ejemplo Microsoft Access o Microsoft SQL Server. Para solucionar problemas, es posible que sea suficiente registrar las actividades del protocolo en un archivo de texto ASCII en lugar de una base de datos compatible con ODBC. Nota: IIS incluye un archivo de plantillas SQL que puede ejecutarse en una base de datos SQL para crear una tabla que acepte entradas de registro de IIS.

•

Formato del archivo de registro extendido W3C El receptor de sucesos realiza un seguimiento de las actividades del protocolo SMTP en un archivo de texto sin formato personalizable. Si elige este formato, puede excluir todos los campos del archivo de registro que no contienen información relevante para las las actividades del protocolo SMTP,

329

por ejemplo, el nombre del usuario en las comunicaciones SMTP anónimas. Esto permite limitar el tamaño del registro al omitir los campos innecesarios. Los campos están separados por espacios.

Registro de sucesos Exchange Server 2003 utiliza el receptor Eventlog de SMTP para registrar los sucesos de los componentes internos del servicio SMTP en el registro de sucesos de la aplicación. En este contexto, un suceso es cualquier instancia relevante del sistema que puede precisar de la atención del administrador. Los registros de sucesos pueden ayudarle a identificar y diagnosticar el origen de los problemas actuales del sistema o a pronosticar problemas potenciales. De forma predeterminada, en el registro de sucesos sólo se escribe escri la información mínima necesaria. No obstante, puede aumentar la cantidad de información mediante la configuración del registro de diagnósticos disponible en el Administrador del sistema de Exchange. Nota: Para reducir la cantidad de información que se se escribe en el registro de sucesos de la aplicación durante el funcionamiento normal, puede que Exchange Server 2003 sólo registre un suceso cada hora para los sucesos que se repiten varias veces en una hora. Para ver instrucciones detalladas acerca de có cómo mo habilitar el registro de diagnóstico, consulte Cómo habilitar el registro de diagnósticos diagnósticos para el servicio SMTP en el Administrador del sistema de Exchange. Exchange

Registro de ingeniería de campo Los niveles de registro controlan la cantidad de datos registrados en el registro de la aplicación. Cuantos más sucesos se registren, más sucesos re relacionados lacionados con el transporte podrá ver en el registro de sucesos de la aplicación. Por tanto, tendrá más posibilidades de averiguar la causa del problema en el flujo de mensajes. Para obtener la mayor información posible acerca del servicio SMTP, puede est establecer ablecer el nivel de registro de diagnósticos de los componentes internos del servicio SMTP en Ingeniería de campo para permitir el registro de los sucesos de nivel de seguimiento. La opción Ingeniería de campo no se muestra en el Administrador del sistema de Exchange y solamente se puede establecer mediante el Editor del Registro. Para ver instrucciones detalladas acerca de cómo establecer el nivel de registro de diagnósticos para las categorías de MSExchangeTransport en Ingeniería de campo, consulte Cómo establecer el nivel de registro de diagnósticos para las categorías de MSExchangeTransport changeTransport en Ingeniería de campo campo. Para obtener más información acerca del registro de ingeniería de campo, consulte en Microsoft Knowledge Base el artículo 262308, "XCON: How to Generate nerate Application Log Events for Non-Delivery Delivery Report Failures". Failures

330

Seguimiento de mensajes El seguimiento de mensajes es una característica que puede utilizar para realizar el seguimiento de los mensajes de una organización de Exchange. Puede realizar el seguimiento guimiento de todo tipo de mensajes, incluidos los del sistema y los mensajes de correo electrónico normales que se envían o se reciben de un sistema de mensajería que no es de Exchange. Un ejemplo de mensajes del sistema lo constituyen los mensajes de replicación repl de las carpetas públicas que los almacenes de Exchange en varios servidores se intercambian entre sí para mantener sincronizadas las instancias de carpetas públicas en servidores distintos. Puede utilizar el Centro de seguimiento de mensajes para localizar l los mensajes que no han conseguido llegar a los buzones de los usuarios, por ejemplo, los mensajes bloqueados en la cola de mensajes de un conector. De forma predeterminada, el seguimiento de mensajes no está habilitado. Debe habilitar esta función n en todos los servidores en los que desee realizar el seguimiento de mensajes. Una vez habilitada, Exchange Server 2003 utiliza el receptor MsgTrackLog del servicio SMTP para agregar la información de seguimiento de los mensajes enrutados a través del servidor ser a los registros de seguimiento de mensajes. Para habilitar el seguimiento de mensajes para varios servidores, puede utilizar una directiva de servidor. Para ver instrucciones detalladas acerca de cómo habilitar el seguimiento de mensajes, consulte Cómo habilitar el seguimiento de mensajes en el Administrador del sistema de Exchange.. También puede configurar configur el modo en que Exchange Server 2003 conserva los archivos del registro de seguimiento de mensajes. Por ejemplo, puede impedir que se borren los archivos de registro o modificar el tiempo durante el cual se conservan los archivos de registro. El período predeterminado durante el cual se conservan los registros de seguimiento es de siete días. Para obtener más información acerca del seguimiento de mensajes, consulte en Microsoft Knowledge Base el artículo 262162, "XADM: XADM: Using the Message Tracking Center to Track a Message". Message Nota: Los registros de seguimiento de mensajes pueden crecer rápidamente en los servidores cabeza de puente que procesan muchos mensajes entrantes y salientes. Asegúrese úrese de contar con espacio en disco suficiente para los archivos de registro de seguimiento.

Cómo habilitar el registro de diagnósticos para el servicio SMTP en el Administrador del sistema de Exchange Este procedimiento explica cómo habilitar el registro de diagnósticos para el servicio SMTP en el Administrador del sistema de Exchange. Este procedimiento se ejecuta si se desea aumentar la cantidad de información que se escribe en el registro de sucesos del sistema.

331

Antes de empezar Antes de realizar el procedimiento de este tema, tenga en cuenta lo siguiente: Al asignar el valor Máximo al nivel de registro de diagnósticos, es posible que se escriban muchos sucesos en el registro de sucesos de la aplicación. Es recomendable establecer el tamaño del registro de sucesos del sistema y de la aplicación en 30 MB y habilitar la opción para sobrescribir los sucesos cuando sea preciso. Una vez solucionado el problema, vuelva aplicar la configuración predeterminada, Ninguno.

Procedimiento Habilitar el registro de diagnósticos para el servicio SMTP en el Administrador del sistema de Exchange 1. Abra las propiedades del objeto de Exchange Server que contiene los servidores virtuales SMTP. 2. Seleccione la ficha Registro de diagnósticos. 3. En Servicios, seleccione MSExchangeTransport. 4. En Categorías, seleccione todas las categorías que contiene el servicio SMTP, incluidas Servicio o motor de enrutamiento, Categorizador, Motor de cola, Controlador del almacén de Exchange, Controlador del almacén NTFS, Protocolo SMTP y Administrador de conexiones. 5. En Nivel de registro, seleccione el nivel de registro adecuado. Para la solución de problemas, es recomendable aumentar el nivel del registro de sucesos de los servicios MSExchangeTransport al nivel Máximo para obtener la información más detallada posible.

Cómo establecer el nivel de registro de diagnósticos para las categorías de MSExchangeTransport en Ingeniería de campo Este procedimiento explica cómo establecer el nivel de registro de diagnósticos para las categorías de MSExchangeTransport en Ingeniería de campo Este procedimiento se ejecuta para habilitar el registro de los sucesos de nivel de seguimiento en un servicio SMTP, como ayuda para determinar la causa de un problema del flujo de mensajes.

332

Antes de empezar Antes de realizar el procedimiento de este tema, tenga en cuenta lo siguiente: •

La Ingeniería de campo afecta negativamente al rendimiento del servidor. Sólo debe utilizarse bajo la supervisión de los Servicios de soporte técnico de Microsoft para solucionar onar problemas de transporte complejos.

•

Este tema contiene información acerca de la modificación del Registro. Precaución: La modificación incorrecta del Registro puede ocasionar problemas graves que quizás requieran volver a instalar el sistema operativo. Es posible que los problemas derivados de una modificación incorrecta del Registro no se puedan resolver. Antes de modificar el Registro, se recomienda realizar una copia de seguridad de todos los datos importantes.

Procedimiento Establezca el nivel ivel de registro de diagnósticos para las categorías de MSExchangeTransport en Ingeniería de campo 1. Inicie el Editor del Registro y abra la siguiente clave del Registro: HKEY_LOCAL_MACHINE HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeTransport MSExchangeTransport\Diagn ostics.

2. Haga doble clic en cada entrada de las categorías de MSExchangeTransport, una a una, y establezca el valor en 0x7.. Por ejemplo, haga doble clic en la entrada 2 Categorizer en el panel de la derecha y cambie el valor a 0x7. 3. Reinicie el servicio SMTP SMTP.. Normalmente no es preciso reiniciar los servicios por orden para que el cambio surta efecto. No obstante, si modifica el Registro manualmente, es probable que deba realizar este paso.

Para más información Para obtener más información acerca del registro de ingeniería de campo, consulte en Microsoft Knowledge Base el artículo 262308, "XCON: XCON: How to Generate Application Log Events for Non-Delivery Delivery Report Failures". Failures

333

Cómo habilitar el seguimiento seguimiento de mensajes en el Administrador del sistema de Exchange En este tema se describe cómo habilitar el seguimiento de mensajes en el Administrador del sistema de Exchange. Esta función se puede utilizar para realizar el seguimiento de todo tipo de mensajes, sajes, incluidos los del sistema y los mensajes de correo electrónico normales que se envían o se reciben de un sistema de mensajería que no es de Exchange, en la organización de Exchange. Puede utilizar el Centro de seguimiento de mensajes para localizar los mensajes que no han conseguido llegar a los buzones de los usuarios, por ejemplo, los mensajes bloqueados en la cola de mensajes de un conector.

Antes de empezar Antes de realizar el procedimiento de este tema, tenga en cuenta lo siguiente: De forma predeterminada, edeterminada, el seguimiento de mensajes no está habilitado. Debe habilitar esta función en todos los servidores en los que desee realizar el seguimiento de mensajes. Para habilitar el seguimiento de mensajes para varios servidores, puede utilizar una directiva dire de servidor. Nota: Los registros de seguimiento de mensajes pueden crecer rápidamente en los servidores cabeza de puente que procesan muchos mensajes entrantes y salientes. Asegúrese de contar con espacio en disco suficiente para los archivos de registro r de seguimiento.

Procedimiento Habilitar seguimiento de mensajes 1.

Inicie el Administrador del sistema de Exchange y abra las propiedades del servidor en el que desea habilitar el seguimiento de mensajes.

2. En la ficha General, General active la casilla de verificación Habilitar seguimiento de mensajes. 3. Para realizar un seguimiento de la línea de asunto de cada mensaje además de la información del sobre, por ejemplo, Para, De y Fecha de envío, active la casilla de verificación Habilitar Habil presentación y registro del asunto.

334

Referencia Para obtener más información acerca del seguimiento de mensajes, consulte en Microsoft Knowledge Base el artículo 262162, "XADM: Using g the Message Tracking Center to Track a Message".

Arquitectura de transporte X.400 Microsoft Exchange Server 2003 utiliza el Protocolo simple de transferencia de correo (SMTP) para transferir los mensajes nativos. No obstante, los componentes principales de Exchange Server 2003 incluyen un agente de transferencia de mensajes (MTA) que también es compatible con las recomendaciones X.400 adoptadas el año de conformidad de 1988. Por lo tanto, los conectores X.400 pueden utilizarse para crear la columna vertebral verteb de la mensajería de su organización de Exchange o para conectarse a un sistema de mensajería X.400 externo. Si se utilizan los conectores X.400 en lugar de los conectores para SMTP, se agrega una capa adicional de seguridad. Esto se debe a que el estándar estándar X.400 requiere que los MTA se autentiquen para poder transmitir mensajes. Sin embargo, hay que tener presente que el mantenimiento de los MTA X.400 y los conectores X.400 es más complicado que el de los conectores para SMTP. Por ejemplo, las direcciones direcciones de correo electrónico de X.400 no son muy intuitivas porque utilizan muchos atributos. X.400 es un estándar complejo que define la arquitectura de un sistema de tratamiento de mensajes (MHS) basado en las siguientes recomendaciones: X.200, X.217, X.218, X.227, X.228, X.402, X.411, X.413, X.419, X.420, X.435, X.680, X.690, X.880, X.881 y X.882. Originalmente, el estándar X.400 fue creado en la década de los 80 por varias empresas de comunicaciones bajo los auspicios de la organización Consultative Committee Committe for International Telephone and Telegraph (CCITT), que años después se convirtió en Telecommunications Standardization Sector of the International Telecommunication Union (ITU-T). T). Cada cuatro años, ITU-T ITU T publica recomendaciones actualizadas acerca de X.400. X.4 Cada actualización incluye características nuevas, pero sigue siendo compatible con las versiones anteriores. La primera recomendación X.400 oficial fue publicada en 1984 y se conoce como Red Book (Libro rojo) por el color de su portada. La recomendación recomendaci X.400 de 1984 presentaba algunas carencias en lo referente al tratamiento de mensajes. La recomendación X.400 de 1988 incluye partes de cuerpo del mensaje y propiedades del sobre X.400 adicionales. Los identificadores de objeto describen de forma precisa precis los datos adjuntos de los mensajes para que los nombres de los datos adjuntos y otras propiedades del objeto se conserven. El estándar X.400 de 1988 se conoce como Blue Book (Libro azul). Nota: ITU-T T adopta las letras del alfabeto inglés para categorizar categorizar sus estándares: La "X" de X.400 indica que el estándar se utiliza para redes de datos y comunicaciones de sistemas abiertos. Para obtener información acerca de los estándares "X", visite el sitio Web de ITU-T T (http://www.itu.int/). (

335

En esta sección se explican los siguientes conceptos: •

MTA de Exchange en la arquitectura de Exchange Server 2003 Esta sección describe el modo en que el MTA de Exchange se integra con otros componentes de Exchange Server 2003 y ofrece una introducción a la transferencia de mensajes a través de conectores de puerta de enlace X.400 o basados en MAPI.

•

Conectores y pilas de transporte X.400 La transferencia de mensajes X.400 está controlada por protocolos que determinan en modo en que los MTA se comunican entre sí. Los conectores y las pilas de transporte X.400 definen estos parámetros de comunicación para el MTA de Exchange. El correcto conocimiento de estos protocolos y parámetros es importante para configurar los conectores y las pilas de transporte. Debe estar familiarizado con los requisitos previos de la comunicación X.400 para poder solucionar problemas de conectividad de X.400.

•

Conexión de grupos de enrutamiento mediante conectores X.400 Cuando los MTA de Exchange se comunican entre sí a través de conectores X.400, no se ajustan necesariamente a todos los aspectos de X.400. Concretamente, los MTA de Exchange admiten formatos de mensajes que no están definidos en X.400. Intercambian información de estado de vínculos de modo que todos los servidores en los que se ejecuta Exchange Server 2003 en una organización puedan realizar el enrutamiento dinámico de los mensajes, tal como se describe en Arquitectura de enrutamiento de mensajes.

•

MTA de Exchange en una organización en modo mixto Si cuenta con una organización en modo mixto, deberá comprender las distintas tareas que el MTA de Exchange debe realizar para admitir la integración óptima de Exchange Server 2003 con Exchange Server 5.5.

La información de esta sección da por hecho que está familiarizado con el diseño de topologías de enrutamiento de mensajes y la configuración de los conectores X.400. Para obtener más información acerca de la configuración de los conectores X.400, consulte la Exchange Server 2003 Administration Guide.

MTA de Exchange en la arquitectura de Exchange Server 2003 El MTA de Exchange es uno de los componentes principales de Exchange Server 2003 y se encarga de la transferencia de mensajes por medios distintos de SMTP, incluida la transferencia de mensajes a sistemas de mensajería externos X.400 y servidores de Exchange conectados a través de conectores X.400. La transferencia de mensajes a sistemas de mensajería distintos de Exchange, por ejemplo, Lotus Notes y Domino o el Conector de Microsoft Exchange para Novell GroupWise, está controlada el MTA de Exchange a través de conectores basados en MAPI, como el Conector de Microsoft Exchange para Lotus Notes o el Conector de Microsoft Exchange para Novell GroupWise. El

336

MTA de Exchange también se encarga de la comunicación basada en llamadas a procedimiento remoto (RPC) con Exchange Server 5.5. Es aconsejable implementar el MTA de Exchange en todos los servidores en los que se ejecuta Exchange Server 2003.

Socios de comunicación del MTA de Exchange El MTA de Exchange está implementado en un servicio de Microsoft Windows denominado Microsoft Exchange - Pila MTA. Al mostrar las propiedades del servicio Microsoft Exchange Pila MTA en la herramienta Servicios y hacer clic en la ficha Dependencias, se observa que el servicio Microsoft Exchange - Pila MTA depende del Operador de sistema. En el Operador de sistema se aloja el componente Directory Service Access (DSAccess), utilizado por el MTA para obtener la información de configuración y de destinatarios desde Active Directory. No obstante, el Operador de sistema no es la única dependencia, tal y como se muestra en la figura siguiente. Socios de comunicación del MTA

El MTA de Exchange se comunica con los siguientes componentes: •

Active Directory La comunicación con Active Directory es necesaria porque el objeto de configuración del MTA y los objetos del conector X.400 se encuentran en la partición del directorio de configuración de Active Directory. El MTA de Exchange no se puede iniciar si no se puede obtener acceso a Active Directory.

•

Base de datos del Registro No todos los parámetros de configuración del MTA se mantienen en Active Directory. También se almacenan opciones importantes para el servicio Microsoft Exchange - Pila MTA en la siguiente ubicación del Registro del servidor:

337

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeMTA HKEY_LOCAL_MACHINE MSExchangeMTA. En esta sección se describen las diferentes opciones que pueden encontrarse en la clave Parameters.. La configuración manual de los parámetros del Registro mediante el Editor del Registro permite ajustar el rendimiento del MTA. Precaución: El uso del Editor del Registro puede ocasionar problemas graves que quizás requieran reinstalar el sistema operativo. Microsoft no puede garantizar que estos problemas derivados del uso incorrecto del Editor del Registro puedan solucionarse. Utilice tilice el Editor del Registro bajo su propia responsabilidad. •

Servicio SMTP En Exchange Server 2003, el MTA de Exchange no realiza el enrutamiento de los mensajes. Esta tarea es responsabilidad del motor de enrutamiento, que forma parte del servicio SM SMTP. TP. El MTA de Exchange se comunica con el motor de enrutamiento a través de Mtaroute.dll para tomar las decisiones de enrutamiento. Tenga en cuenta que la comunicación con el servicio SMTP es bidireccional. El MTA se comunica con el servicio SMTP para re realizar alizar el enrutamiento de los mensajes. El servicio SMTP inicia la comunicación cuando cambia la topología de enrutamiento para comunicar al MTA que todos los mensajes deben enrutarse de nuevo. Para obtener más información acerca de la interacción entre el MTA y el servicio SMTP, consulte Conexión de grupos de enrutamiento mediante conectores X.400. X.400

•

Almacén de Exchange Como se muestra en la figura siguiente, el servicio SMTP transfiere los mensajes salientes al MTA de Exchange mediante la cola de mensajes del MTA en el almacén de Exchange. El MTA de Exchange también transfiere los mensajes entrantes al servicio SMTP a través del al almacén macén de Exchange. La comunicación con el almacén de Exchange es necesaria si los mensajes deben transferirse a través de conectores de mensajería basados en MAPI de los que se encarga el MTA de Exchange. Los conectores de mensajería basados en MAPI,de for forma ma similar que el servicio SMTP, mantienen colas de mensajes en el almacén de Exchange, tal como se describe en Arquitectura de los conectores de mensajería de puerta de enlace. enlace

338

Comunicación del MTA a través del almacén de Exchange

Para comunicarse con el almacén de Exchange, el MTA utiliza una API interna denominada XAPI, que es un empaquetador de MAPI. Para iniciar correctame correctamente el servicio Microsoft Exchange - Pila MTA, el almacén de Exchange debe contar al menos con un almacén de buzones para poder alojar las colas de mensajes. Más adelante en esta sección se proporciona más información acerca del tratamiento de los mensajes entrantes y salientes. Nota: Si el servidor cabeza de puente en el que se ejecuta Exchange Server 2003 aloja a muchos conectores X.400 o se conecta con sistemas de mensajería distintos de Exchange, por ejemplo, Lotus Notes y Novell GroupWise, se recomienda que coloque los registros de transacciones y archivos de base de datos del almacén de Exchange en discos separados, aunque el almacén de Exchange no contenga buzones de usuarios. Al distribuir los archivos de base de datos entre varios discos físicos, físicos, el rendimiento del sistema mejora. •

Sistema de archivos El MTA de Exchange utiliza dos directorios importantes en el sistema de archivos. Estos directorios se denominan directorio de la base de datos del MTA y directorio de ejecución del MTA. El directorio de la base de datos contiene los mensajes y los archivos de cola durante la transferencia en forma de archivos .dat. Este conjunto de archivos .dat se denomina base de datos del MTA. El directorio de ejecución contiene archivos de plantilla (den (denominados ominados archivos de ejecución). Los archivos de ejecución determinan el modo en que el MTA da formato a los datos mediante Abstract Syntax Notation One (ASN.1). De forma predeterminada, tanto el directorio de la base de datos como el directorio de ejecuci ejecución ón señalan al mismo directorio físico del sistema de archivos. Tal como se indica en la figura 7.2, este directorio es \Archivos Archivos de

339

programa\Exchsrvr\Mtadata. Mtadata. Como se explica más adelante en esta sección, la mejor opción es separar el directorio de la base de datos y el de ejecución. Nota: El directorio de ejecución no contiene el archivo ejecutable real (Emsmta.exe) ni las bibliotecas de vínculos dinámicos (DLL) del servicio Microsoft Exchange Pila MTA. Emsmta.exe y las DLL, como Mtaroute.dll, se almacenan almacenan en el directorio \Archivos Archivos de programa\Exchsrvr\bin. programa •

MTA X.400 remoto El MTA de Exchange se comunica con otros MTA X.400 remotos a través de conectores X.400. Un conector X.400 es un objeto de configuración en Active Directory que describe los parámetros parámetros de comunicación y los formatos de mensaje que el MTA de Exchange debe usar para la transferencia de mensajes. Un MTA X.400 remoto puede ser un MTA de Exchange o no Exchange conectado por medio de un conector X.400. Para obtener más información ace acerca rca de la comunicación X.400, consulte Pilas de transporte del MTA y conectores X.400 X.400.

•

Servidores de Exchange 5.5 en el mismo grupo de enrutamiento nto Los objetos del conector X.400 no son necesarios para que el MTA de Exchange pueda comunicarse con los servidores en los que se ejecuta Exchange Server 5.5 en el grupo de enrutamiento local. Estos tipos de MTA también se denominan MTA de LAN para subrayar rayar el hecho que un conector X.400 explícito no interviene en su comunicación. Los MTA de LAN utilizan RPC para comunicarse entre sí. Para obtener más información acerca de la comunicación entre Exchange Server 2003 y Exchange 5.5, consulte MTA de Exchange en una organización en modo mixto. mixto

Opciones de configuración del MTA de Exchange en Active Directory El MTA de Exchange obtiene sus opciones de configuración del Registro local y del objeto MTA en Active Directory. El objeto de directorio MTA se encuentra en cada objeto del servidor de Exchange en la partición del directorio de configuración. Por ejemplo, éste es el nombre completo de un objeto objeto MTA en un servidor denominado SERVER01 en el dominio tailspintoys.com: CN=Microsoft MTA,CN=SERVER01,CN=Servers,CN=First Administrative Group,CN=Administrative Groups,CN=Tailspin Toys,CN=Microsoft. La ubicación del objeto de configuración del MTA es algo distinta en el Administrador del sistema de Exchange. El objeto de configuración del MTA se encuentra en el contenedor Protocols bajo el objeto de servidor, como se observa en la figura siguiente. El objeto se denomina X.400, aunque en realidad se configu configura ra el MTA y no solamente las opciones de X.400. Puede utilizar el objeto de configuración X.400 para definir el nombre del MTA y su contraseña local. También puede especificar el directorio de la base de datos del MTA en el que se encuentran las colas de mensajes. m En la ficha Opciones predeterminadas de mensajería puede configurar los parámetros generales de la comunicación, como los

340

valores de reintento, que el MTA utiliza para la comunicación con los MTA de LAN. Puede reemplazar esta configuración al configurar los conectores X.400. El objeto de configuración del MTA en el Administrador del sistema de Exchange

Los objetos de configuración del MTA son instancias de la clase de objeto MTA. Por ejemplo, puede utilizar esta información en un filtro del protocolo ligero de acceso a directorios (LDAP) para exportar todas las opciones de todos los MTA de una organización de Exchange a un archivo de texto. El siguiente comando Data Interchange Format Directory Exchange (LDFIDE) de LDAP muestra cómo realizar este paso: ldifde -f c:\AllMTAs.ldf -s localhost -d "CN=First Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=contoso,DC=com" -p subtree -r "(objectClass=mTA)".

Debe tener permisos de lectura en todos los grupos administrativos de

la organización. En la tabla siguiente se enumeran los atributos importantes del objeto de directorio MTA y sus propósitos.

341

Atributos importantes del objeto de directorio MTA Atributo de directorio

Propósito

objectClass

Identifica el objeto de directorio como un objeto MTA.

cn

Contiene el nombre común (cn) del MTA.

transRetryMins

Define el período de tiempo (en minutos) entre los reintentos de transferencia. El valor predeterminado es cinco minutos.

transTimeoutMins

Define el período de tiempo de espera (en minutos) para la transferencia de mensajes. El valor predeterminado es 20 minutos.

mTALocalDesig

Especifica el nombre X.400 del MTA local. Este nombre, de hasta 32 caracteres, se utiliza para identificar el MTA de Exchange local a los MTA remotos y los MTA de LAN.

delivContLength

Define el tamaño máximo de mensajes de entrega, en kilobytes (KB), que puede enviarse a través del MTA.

diagnosticRegKey

Especifica la ubicación de la clave del Registro de diagnósticos. Si esta clave no existe, el MTA utiliza la siguiente clave del Registro: HKEY_LOCAL_MACHINE\SYSTEM\Current ControlSet\Services\MSExchangeMTA\Diagn ostics.

expandDLsLocally

Corresponde al valor Expandir localmente las listas de distribución remotas, en las propiedades del MTA. Si expandDLsLocally es verdadero (True), y un usuario envía un mensaje a una lista de distribución remota, el MTA expande localmente la lista de distribución. A continuación, el MTA de Exchange determina el mejor enrutamiento para el mensaje, en función de la ubicación de los destinatarios de la lista. Este método garantiza el tratamiento más eficaz de los mensajes. No obstante, el procesamiento de listas de distribución grandes puede afectar al rendimiento del servidor.

342

Atributo de directorio

Propósito

msExchHomeRoutingGroupDNBL

Vínculo de retorno al grupo de enrutamiento al que pertenece este MTA.

associationLifetime

Especifica el tiempo en segundos durante el cual el sistema mantiene abierta una asociación a un MTA X.400 remoto una vez enviado un mensaje. El valor predeterminado es 300 segundos.

numOfOpenRetries

Especifica el número máximo de veces que el MTA de Exchange intenta abrir una conexión antes de enviar un informe de no entrega (NDR). El valor predeterminado es 144 veces.

numOfTransferRetries

Especifica el número máximo de veces que el MTA de Exchange intenta transferir un mensaje a través de una conexión abierta. El valor predeterminado es dos veces.

openRetryInterval

Especifica los segundos que el sistema espera después de un error antes de intentar volver a abrir una conexión. El valor predeterminado es 600 segundos.

rTSCheckpointSize

Especifica la cantidad de datos en KB que se transfiere antes de insertar un punto de control. Si se produce un error y hay que volver a enviar el mensaje, el proceso se reinicia desde el punto de control más reciente. El valor cero indica que no se han insertado puntos de control.

rTSRecoveryTimeout

Especifica el tiempo después de cortarse la conexión que el MTA espera para volverse a conectar antes de borrar la información (con sus puntos de control) y reiniciar la transferencia desde el principio.

rTSWindowSize

Especifica el número de puntos de control que se pueden dejar pasar sin confirmar antes de que se suspenda la transferencia de datos. El tamaño de la ventana es irrelevante si el tamaño del punto de control es cero.

343

Atributo de directorio

Propósito

sessionDisconnectTimer

Especifica el tiempo en segundos que el MTA de Exchange espera antes de finalizar una conexión cuando ya han finalizado todas las asociaciones a través de esta conexión.

tempAssocThreshold

Especifica el número máximo de mensajes en cola que puede enviar el mensaje a un sistema remoto. Cuando se excede, el MTA abre otra asociación.

transferRetryInterval

Especifica el número de segundos que el sistema espera después de que fracase una transferencia de mensajes para volver a enviar un mensaje a través de una conexión abierta. El valor predeterminado es 120 segundos.

transferTimeoutNonUrgent

Especifica el tiempo en segundos por kilobyte que el sistema espera antes de enviar un informe de no entrega (NDR) para un mensaje no urgente.

transferTimeoutNormal

Especifica el tiempo en segundos por kilobyte que el sistema espera antes de enviar un informe de no entrega (NDR) para un mensaje normal.

transferTimeoutUrgent

Especifica el tiempo en segundos por kilobyte que el sistema espera antes de enviar un informe de no entrega (NDR) para un mensaje urgente.

msExchMTADatabasePath

Indica la ruta de acceso al directorio de la base de datos del MTA.

msExchResponsibleMTAServerBL

Contiene el nombre completo del servidor en el que se aloja el MTA.

344

Atributo de directorio

Propósito

msExchEncryptedPassword

Especifica la contraseña del MTA que los MTA remotos deben usar para conectarse a este MTA. La contraseña puede tener hasta 64 caracteres de longitud y se almacena de forma cifrada en Active Directory. Nota: La contraseña del MTA se almacena de forma cifrada en Active Directory, pero esto no significa que los nombres y contraseñas de los MTA sean seguros. Los MTA X.400 intercambian sus nombres y contraseñas en texto no cifrado cuando establecen las conexiones.

Arquitectura interna del MTA de Exchange La arquitectura interna del MTA de Exchange está basada en conjuntos de subprocesos, colas de mensajes y colas de base de datos. Los subprocesos realizan el procesamiento real dentro del proceso del MTA de Exchange (Emsmta.exe). Las colas de mensajes, indicadas mediante flechas en la figura siguiente, controlan las interacciones y notificaciones entre los subprocesos. Las colas de base de datos contienen los mensajes que esperan ser procesados por uno de los conjunto conjuntoss de subprocesos. Por ejemplo, la cola de trabajo que se muestra en la figura siguiente es una cola de base de datos que retiene los mensajes hasta que el MTA los ha transferido correctamente o hasta que caducan y se devuelven al remitente con un informe d de e no entrega (NDR). La ejecución de varios subprocesos permite al MTA de Exchange realizar varias tareas simultáneamente. La figura siguiente muestra la arquitectura interna del MTA de Exchange.

345

Arquitectura interna del MTA de Exchange

La arquitectura interna del MTA de Exchange se basa en los siguientes elementos: •

Subprocesos XFER IN y XFER OUT Estos subprocesos controlan la transferencia de entrada y salida real de los mensajes en el proceso MTA. Esta comunicación tiene lugar por medio de los siguientes mecanismos: •

X.400 Comunicación con un MTA X.400 remoto o un servidor de Exchange en un grupo de enrutamiento remoto mediante un conector X.400.

•

RPC Comunicación con un MTA de LAN (es decir, un servidor en el que se ejecuta Exchange Server 5.5 en el grupo de enrutamiento local).

•

XAPI Comunicación con el almacén de Exchange mediante MAPI.

Puede controlar el número de subprocesos de transferencia mediante el siguiente parámetro del Registro. Ubicación

HKEY_LOCAL_MACHINE\System\CurrentControlSe t\Services\ MSExchangeMTA\Parameters

Valor

Transfer threads

Tipo

REG_DWORD

Información del valor

0x1

346

Descripción

Determina el número de subprocesos de transferencia del MTA. Este valor se multiplica por dos para los dos subtipos de subprocesos de transferencia (XFER IN y XFER OUT). El valor predeterminado es 0x1. El valor recomendado es 0x3, si este MTA se comunica con varios MTA remotos, dentro de un grupo de enrutamiento o entre grupos de enrutamiento.

•

Cola de trabajo El MTA de Exchange escribe todos los mensajes en archivos .dat en el directorio de la base de datos del MTA del sistema sistema de archivos. A continuación, crea un puntero para cada archivo .dat de la cola de trabajo. La cola de trabajo mantiene una referencia para cada mensaje cuya responsabilidad recae en el MTA. La base de datos del MTA y los archivos .dat se describen más ad adelante elante en esta sección.

•

Distribuidor El distribuidor se encuentra en el núcleo del proceso MTA y es el encargado del enrutamiento de mensajes y el procesamiento de los resultados. El distribuidor utiliza subprocesos de enrutador, de desplegamiento y de resultados para el procesamiento de mensajes. El distribuidor lleva a cabo las siguientes tareas clave: •

Enrutamiento, despliegue y transferencia de mensajes El distribuidor utiliza un subproceso de enrutamiento para comunicarse con el motor de enrutamiento enruta y determinar el siguiente salto para la transferencia de mensajes. Si un mensaje se dirige a destinatarios en distintas ubicaciones accesibles a través de diferentes conexiones (por ejemplo, dos conectores X.400 instalados en el mismo servidor), el distribuidor utiliza un subproceso de despliegue. El subproceso de despliegue crea varias copias de los mensajes y las coloca en las colas de vínculos apropiadas. A continuación, el distribuidor desencadena subprocesos XFER OUT para procesar las copias de los mensajes desplegados. Nota: El proceso de creación de varias copias de los mensajes en el MTA se denomina despliegue. Es un proceso distinto de la bifurcación, que crea varias copias de los mensajes en el categorizador del subsistema de transporte SMTP. El categorizador se describe con detalle en Arquitectura de transporte SMTP SMTP.

•

Procesamiento de los resultados El distribuidor también elabora informes según s los resultados de las acciones de enrutamiento, despliegue y transferencia. Por ejemplo, si un mensaje se transfiere correctamente a través de un conector X.400, el distribuidor actualiza los indicadores de responsabilidad de los destinatarios del mensaje saje en la cola de trabajo para indicar que la transferencia ha sido correcta.

347

Cada mensaje de la cola de trabajo tiene un mapa de bits formado por un bit por cada destinatario. Inicialmente, el MTA establece los bits de todos los destinatarios para indicar que el mensaje no se ha transferido. Cuando una copia desplegada de un mensaje se transfiere correctamente por medio de un subproceso XFER-OUT, el distribuidor borra los bits correspondientes a los destinatarios de la copia de despliegue. El MTA quita los mensajes de la cola de trabajo cuando el mensaje se transfiere correctamente a los destinatarios o cuando el mensaje caduca. En este punto, el MTA genera un NDR para cada destinatario que no ha recibido el mensaje. Puede controlar el número de subprocesos de distribuidor mediante el siguiente parámetro del Registro. Ubicación

HKEY_LOCAL_MACHINE\System\CurrentControlSe t\Services\ MSExchangeMTA\Parameters

Valor

Dispatcher threads

Tipo

REG_DWORD

Información del valor

0x1

Descripción

Determina el número de subprocesos de distribuidor del MTA, que se encargan del procesamiento de los mensajes. Este valor se multiplica por tres para los tres subtipos de subprocesos de distribuidor (es decir, los subprocesos de enrutador, despliegue y resultados). El valor predeterminado es 0x1. El valor recomendado es 0x3 si el MTA se comunica con más de cinco MTA de LAN.

•

Subprocesos de envío y entrega Estos conjuntos de subprocesos son heredados de Exchange Server 5.5. No se utilizan en Exchange 2000 Server y Exchange Server 2003 en circunstancias normales, ya que en Exchange 2000 Server y Exchange Server 2003 no existe el envío o la entrega directos. Todos los mensajes deben pasar a través del servicio SMTP. El servicio SMTP entrega los mensajes a los destinatarios locales a través del controlador del almacén de Exchange, tal como se describe en Arquitectura de transporte SMTP. El MTA de Exchange trata al servicio SMTP de forma parecida a un conector basado en MAPI con colas de mensajes en el almacén de Exchange. Las puertas de enlace XAPI controlan la transferencia de entrada y salida de los mensajes de la cola de mensajes del almacén de Exchange. Las puertas de enlace XAPI son subprocesos en el almacén de

348

Exchange que intercambian información con los subprocesos XFER IN y XFER OUT MTA. El MTA de Exchange utiliza los siguientes subprocesos para la comunicación entre procesos y para realizar funciones del sistema, por ejemplo, actualizar la información de configuración cuando se producen cambios. •

Pila OSI El MTA de Exchange utiliza varios conjuntos de subprocesos para controlar las tareas de comunicación entre distintas capas de la pila de Interconexión de sistema abierto (OSI). Estos conjuntos de subprocesos incluyen subprocesos de servicio de transferencia confiable (RTS), subprocesos de núcleo, subprocesos RPC, subprocesos de transporte y subprocesos TCP/IP o X.25. Para obtener más información acerca de la finalidad de estos subprocesos, consulte Pilas de transporte del MTA y conectores X.400.

•

Temporizadores El MTA de Exchange ejecuta subprocesos de temporizador en distintas situaciones, por ejemplo, para esperar después de un error en la transferencia de mensajes antes de volver a enviar un mensaje a través de una conexión abierta.

•

Sondeo de Active Directory El MTA de Exchange utiliza un subproceso independiente para sondear Active Directory cada diez minutos para comprobar si hay cambios en la configuración.

•

Subprocesos que no son propiedad del MTA El motor de enrutamiento y el módulo DSAccess son propietarios de subprocesos que se ejecutan en el proceso MTA para informar al MTA de Exchange si se producen cambios. Por ejemplo, el motor de enrutamiento llama a la función RoutingReset () del MTA cuando la topología de enrutamiento cambia para desencadenar un nuevo enrutamiento para todos los mensajes en cola. DSAccess se comunica con el MTA de Exchange para proporcionar información de directorios almacenada en caché.

Base de datos del MTA de Exchange El MTA de Exchange mantiene todos los mensajes que transfiere en la base de datos del MTA. La base de datos del MTA es una base de datos de archivos planos formada por archivos .dat, tal y como se muestra en la figura siguiente. Hay archivos .dat distintos para las colas de base de datos y los mensajes reales. Tenga en cuenta que las colas de base de datos contienen referencias o punteros a los mensajes reales, no los mensajes propiamente dichos. El MTA almacena cada mensaje en un archivo .dat de mensaje distinto en el directorio de la base de datos del MTA. En una base de datos activa existe un archivo DBREFS que contiene recuentos de referencia para los objetos, que proporcionan información de copia de seguridad terciaria. DBREFS se reconstruye cuando se reinicia el MTA o se ejecuta la herramienta de comprobación del MTA. Es difícil distinguir entre los diversos tipos de archivos .dat incluidos en una base de datos del MTA activa. El Kit de recursos de Exchange 2000 Server (disponible en librerías) incluye la herramienta MTAView. Puede utilizar MTAView para ver el contenido de las colas del MTA y los encabezados de los mensajes de estas colas. La figura siguiente muestra la

349

herramienta MTAView con una base de datos del MTA activa abierta. La ventana en primer término muestra los archivos .dat en el directorio de la cola de mensajes del MTA. Colas de mensajes y archivos .dat del MTA de Exchange

Los archivos .dat del MTA se dividen en dos categorías: •

Archivos .dat principales Los archivos .dat principales actúan como filas y columnas de referencia de la base de datos del MTA. En el directorio de la cola de mensajes (\Archivos de programa\Exchsrvr\Mtadata) hay un total de 38 archivos .dat principales. Todos son necesarios para que el MTA de Exchange pueda ejecutarse. La mayoría de archivos .dat principales se incluyen en Exchange Server 2003. Estos archivos se encuentran en el CD del producto, en el directorio \Setup\i386\Exchange\Bootenv. El programa de instalación de Exchange Server 2003 copia estos archivos en el directorio \Archivos de programa\Exchsrvr\Mtadata durante la instalación. Los archivos .dat principales que se incluyen en Exchange Server 2003 están numerados del DB000001.dat al DB000026.dat (en números hexadecimales).

350

El MTA de Exchange crea dinámicamente archivos .dat adicionales para las colas de base de datos importantes. Por ejemplo, el MTA reconstruye la cola de trabajo del MTA cada vez que se reinicia el MTA. Durante esta reconstrucción, no se entregan mensajes porque el MTA debe en primer lugar justificar todos los archivos .dat. Una vez justificados, se inicia la transferencia de mensajes. Los archivos .dat principales más importantes de una base de datos del MTA activa son:

•

•

DB000001.dat Cola de base de datos más importante, denominada cola maestra. La cola maestra contiene una lista de los Id. de objeto de cola y las referencias a otras colas de trabajo. Cada una de estas colas dispone de sus propios archivos .dat.

•

DB000020.dat Cola de trabajo XAPI que mantiene las referencias a los mensajes dirigidos al servicio SMTP o a los conectores de puerta de enlace basados en MAPI, por ejemplo, el Conector para Lotus Notes y el Conector para Novell GroupWise, que disponen de sus propias colas de mensajes en el almacén de Exchange.

•

DB000025.dat Cola de información de ausencia de la oficina que contiene los objetos para las notificaciones de fuera de la oficina.

•

DB000026.dat Cola de datos de referencia. Por motivos de redundancia, en los archivos .dat de la cola se hace referencia más de una vez a los archivos .dat.

•

DB000027.dat Cola de trabajo del MTA que contiene una lista de los mensajes en espera de transferencia.

Archivos .dat de mensaje y de marcador de posición El resto de archivos .dat del directorio de base de datos son archivos de mensaje y de marcador de posición. El MTA crea un archivo .dat de mensaje para cada mensaje que debe transferir. Puesto que la parte numérica del nombre de archivo se asigna aleatoriamente (DB######.dat), pueden existir nombres de archivo duplicados. Para evitar sobrescribir un archivo existente, el MTA de Exchange crea un archivo .dat de marcador de posición junto con cada archivo .dat de mensaje. El archivo .dat de marcador de posición tiene un tamaño de un byte y se utiliza si no se puede crear un archivo .dat de mensaje debido a un nombre de archivo duplicado. La figura anterior muestra un archivo .dat de mensaje de dos megabytes (DB00002D.dat) y un archivo .dat de marcador de posición de cero kilobytes (DB00002E.dat). El MTA crea dos archivos .dat para cada mensaje. Después de transferir un mensaje, el MTA de Exchange borra los datos de los archivos .dat y restablece los archivos en un byte (en lugar de eliminar los archivos .dat). El MTA de Exchange puede reutilizar los archivos .dat para mensajes posteriores. Este mecanismo mejora el rendimiento del MTA porque la creación y eliminación de archivos ocupa mucho tiempo. El número de archivos .dat que encuentre en el directorio de la cola de mensajes refleja el número máximo de mensajes de la cola en cualquier momento. En un servidor cabeza de puente con mucha actividad en el que se ejecute Exchange Server 2003 pueden existir cientos de archivos .dat en el directorio de la base de datos del MTA.

351

Cambio de ubicación del directorio de la base de datos del MTA El Administrador del sistema de Exchange le permite cambiar de ubicación el directorio de la base de datos del MTA en el sistema de archivos (en el contenedor Protocols del servidor, haga clic con el botón secundario del mouse (ratón) en el objeto de configuración X.400, haga clic en Propiedades y, a continuación, en la ficha General, en Directorio de la cola de mensajes, haga clic en Modificar). Al modificar la ubicación del directorio de la cola en el Administrador del sistema de Exchange, los archivos de la base de datos se mueven a la nueva ubicación y el atributo msExchMTADatabasePath del objeto de directorio MTA cambia para señalar a la nueva ubicación. Sin embargo, el atributo msExchMTADatabasePath sólo se utiliza para fines informativos. La siguiente clave del Registro, que el Administrador del sistema de Exchange también actualiza, es más importante. Ubicación

HKEY_LOCAL_MACHINE\System\CurrentControlSe t\Services\ MSExchangeMTA\Parameters

Valor

MTA database path

Tipo

REG_SZ

Información del valor

C:\Program Files\Exchsrvr\Mtadata

Descripción

Señala a la ubicación de los archivos de la base de datos (archivos de cola y archivos de mensaje) del MTA de Exchange. Si la ruta no es válida o señala a un directorio vacío, el MTA no se puede iniciar.

No coloque el directorio de la base de datos del MTA en una partición FAT (tabla de asignación de archivos). Las particiones FAT16 admiten como máximo 65.535 archivos. Este límite de tamaño puede constituir un problema en un servidor cabeza de puente con mucha actividad. Cuando una cola se empieza a llenar, las entradas disponibles con las que se crean archivos nuevos pueden agotarse en un día. Este problema se agrava porque cada mensaje requiere dos archivos .dat. Además, el rendimiento de FAT no es óptimo en grandes volúmenes porque sólo proporciona una tolerancia a errores mínima y una capacidad de recuperación nula cuando se produce una parada inesperada del sistema. En un servidor cabeza de puente X.400 con mucha actividad en el que se ejecute Exchange Server 2003, puede optimizar el rendimiento si coloca el directorio de la base de datos del MTA en un subsistema de disco de alto rendimiento, por ejemplo, una matriz redundante de discos independientes (RAID). Una RAID 0+1 que disponga entre ocho y diez discos es un buen punto de inicio para la transferencia de mensajes de gran volumen. Un controlador

352

RAID con una capacidad de caché de más de 64 megabytes (MB) también contribuye a mejorar el rendimiento. Nota: En la clave del Registro MTA database path encontrará una clave del Registro denominada MTA Run Directory. Directory. Esta clave del Registro señala al directorio donde se encuentran los archivos de ejecución del MTA de Exchange. Se rec recomienda colocar el directorio de la base de datos y el directorio de ejecución en discos distintos.

Copias de mensajes protegidos y no protegidos Los mensajes en la cola de trabajo del MTA se denominan mensajes protegidos porque siempre se guardan en archivos archivos .dat. Estos archivos de datos .dat persisten aunque se produzca una terminación inesperada del proceso del MTA de Exchange. El distribuidor utiliza los mensajes protegidos en la cola de trabajo como archivos de origen y crea copias de mensajes no protegidos. egidos. A continuación, el distribuidor adjunta las colas de vínculos adecuadas para los conectores o los vínculos de siguientes saltos para transferir los mensajes. Si un mensaje se envía a varios destinos accesibles a través de conexiones distintas, el distribuidor istribuidor crea una copia de despliegue para cada conexión. Cada copia de despliegue hace referencia al mensaje protegido en la cola de trabajo del MTA. El MTA quita las copias de los mensajes protegidos y no protegidos de las colas cuando el mensaje se transfiere ransfiere correctamente. Los mensajes en las colas de los vínculos se representan como punteros de referencia a los objetos de mensaje y no como objetos. Los mensajes protegidos están disponibles en archivos .dat, aunque no necesariamente es así para las copias copias no protegidas. Las copias no protegidas se guardan en memoria principalmente para aumentar el rendimiento del MTA. El distribuidor sólo guarda las copias no protegidas en archivos .dat si no hay suficiente espacio en la caché para conservar los objet objetos os en memoria. La caché es un conjunto fijo de búferes de 4 KB y estructuras de objetos basadas en tamaños de conjuntos de subprocesos. Puede ajustar el número de búferes de datos por cada objeto en memoria mediante el siguiente parámetro del Registro. Ubicación

HKEY_LOCAL_MACHINE\System System\CurrentControlSe t\Services\ MSExchangeMTA\Parameters Parameters

Valor

DB data buffers per object

Tipo

REG_DWORD

Información del valor

0x3

353

Descripción

Determina el número de búferes de servidor de base de datos configurados para cada objeto de base de datos. Un mayor número de búferes requiere más memoria, pero hace que sea menos probable que se mueva fuera del disco un objeto de base de datos por falta de espacio en búfer. El valor predeterminado es 0x3. El valor recomendado es 0x6, si este MTA se comunica con varios MTA, dentro de un grupo de enrutamiento o entre grupos de enrutamiento. También debería ajustar este valor si en este servidor hay instalado un conector basado en MAPI.

Base de datos del MTA en un clúster de servidores No se puede dividir la base de datos del MTA y los archivos .dat a fin de que varias instancias del MTA puedan utilizar la base de datos del MTA simultáneamente. Esto es necesario si, por ejemplo, desea ejecutar el MTA en varios nodos de clúster en un clúster de servidores, tomando como base el servicio Clúster de Microsoft Windows Server 2003. Puesto que sólo un MTA puede ser el propietario de la base de datos del MTA, el MTA de Exchange únicamente puede ejecutarse en el primer nodo inicializado del clúster. En la conmutación por error, el servicio de clúster detiene el MTA en el nodo erróneo y lo inicia en otro nodo, que a continuación se recupera a partir de los mismos archivos .dat y vuelve a establecer las conexiones.

Mensajes dañados en las colas de puerta de enlace Exchange Server 2003 transfiere los mensajes destinados a los conectores basados en MAPI al MTA a través del almacén de Exchange. Los mensajes regresan desde el MTA hacia el buzón del conector a través del almacén de Exchange. De forma predeterminada, sólo existen dos subprocesos (uno para las transferencias entrantes y otro para las salientes) que se comunican con el MTA. Esto significa que un mensaje dañado, en la parte superior de una cola de vínculos de puerta de enlace del MTA, puede bloquear todo el flujo de mensajes enviados o procedentes del almacén de Exchange. Para desbloquear la cola de mensajes, puede utilizar el complemento Visor de cola del Administrador del sistema de Exchange para eliminar mensajes críticos.

354

Nota: mine los archivos .dat directamente del directorio de la base de datos del MTA No elimine porque la eliminación accidental de un archivo .dat principal puede dañar toda la base de datos. También puede aumentar el número de subprocesos de entrada y salida de la puerta de enlace en el proceso del almacén de Exchange para cada almacén de buzones mediante los siguientes parámetros del Registro. Si el almacén de Exchange se comunica con el MTA de Exchange mediante varios subprocesos, un mensaje dañado puede bloquear un subproceso, proceso, pero es posible que otro subproceso pueda seguir procesando más mensajes. Si todas las puertas de enlace están bloqueadas por varios mensajes dañados, significa que existe un problema grave (por ejemplo, una avería del controlador del disco duro). Ubicación

HKEY_LOCAL_MACHINE\System System\CurrentControlSe t\Services \MSExchangeIS\<server_name>\Private

Valor

Gateway In Threads Gateway Out Threads

Tipo

REG_DWORD

Información del valor

0x1

Descripción

El valor predeterminado de estos dos parámetros es 0x1. La configuración recomendada es 0x3 si este MTA se comunica con varios MTA de LAN o se encarga de los conectores de mensajería basados en MAPI. Debe agregar estos parámetros a todas las claves del Registro gistro relativas a almacenes de buzones. Cada subproceso de entrada y salida de la puerta de enlace consume aproximadamente 1 MB de memoria virtual. Esto podría ser un problema en los servidores que tienen muchas bases de datos privadas. Por ejemplo, si cuenta cu con diez bases de datos privadas y aumenta estos parámetros de 0x1 a 0x3 (un aumento total de cuatro subprocesos), creará realmente 4 x 10 = 40 subprocesos, que conjuntamente consumen 40 MB de memoria virtual.

355

Corrección de daños en la base de datos del MTA Si al eliminar un mensaje dañado de la cola de mensajes no soluciona todos los problemas relacionados con las colas del MTA, utilice la herramienta Comprobación del MTA (Mtacheck.exe) para analizar y corregir problemas en la base de datos del MTA. Ejecute Comprobación del MTA si sospecha que hay daños en la base de datos del MTA o ve errores escritos en el registro de sucesos. La herramienta Comprobación del MTA debe utilizarse directamente en el servidor; es preciso que detenga el servicio Pila MTA MT de Microsoft Exchange. La herramienta Comprobación del MTA comprueba las referencias en las colas de la base de datos y garantiza que los archivos .dat indicados se encuentran entre los archivos de cola. La herramienta quita los mensajes dañados (es decir, deci los mensajes con referencias incoherentes). Los mensajes dañados se mueven al directorio \Archivos de programa\Exchsrvr\Mtadata Mtadata\Mtacheck.out. Mtacheck.out. Puede utilizar parámetros de línea de comando para eliminar los mensajes de replicación de carpetas públicas y otros mensajes del sistema, pero debe utilizarlos con precaución. Para obtener más información, consulte la documentación de la herramienta Comprobación del MTA. La herramienta de comprobación de MTA y su documentación están disponibles en el sitio Web de Descargas para Exchange Server 2003 (en inglés).

Barrido de la base de datos del MTA En un servidor cabeza de puente ocupado con varios conectores basados en X.400 o MAPI, el directorio de la base de datos del MTA puede llenarse con más de 10.000 archivos .dat. Esta situación se agrava si hay problemas de transferencia debido a mensajes dañados o problemas de red. El límite físico correspondiente al número de archivos .dat que pueden escribirse en ell disco es la cantidad de espacio de disco disponible. El servicio Pila MTA de Microsoft Exchange se apaga cuando el espacio de disco disponible es inferior a diez en el disco duro donde está situada la base de datos del MTA. Para reiniciar el servicio Pil Pila a MTA de Microsoft Exchange, asegúrese de que dispone de más de diez megabytes de espacio en el disco. Es posible que para ello tenga que mover temporalmente todos los archivos .dat del directorio de la base de datos del MTA a otra unidad o a un recurso co compartido mpartido de red. El proceso de mover archivos para crear un directorio de base de datos vacío se conoce como barrido del MTA. Un barrido del MTA sirve de ayuda para solucionar problemas de la base de datos del MTA, por ejemplo, cuando hay muchos mensajes dañados añados que bloquean las colas de la base de datos. Para obtener instrucciones acerca de cómo barrer la base de datos del MTA, consulte Cómo realizar un barrido de la base de datos del MTA MTA. Precaución: Si tiene que barrer una base de datos del MTA, debe contactar con los Servicios de soporte técnico al producto de Microsoft para obtener ayuda y asegurarse de que los pasos se realizan correctamente. Si aplica los pasos de forma incorrecta, es posible

356

que pierda mensajes de correo electrónico que se encuentran en las colas de mensajes del MTA.

Reproducción de archivos DAT Para entregar mensajes que estaban en la base de datos del MTA cuando se realizó el barrido del MTA, debe reproducir los archivos .dat. Puede realizar esto de tres maneras diferentes: •

Puede realizar una reproducción completa La forma más fácil de reproducir los archivos .dat es reproducirlos todos a la vez en el servidor en el que se encontraban originalmente. Para hacerlo, el MTA del servidor de origen de Exchange no debe tener nada en sus colas. Si hay mensajes en las colas del MTA, el MTA deberá poder finalizar el envío de mensajes hasta que todas las colas estén vacías.

•

Puede realizar una reproducción remota Los archivos .dat no tienen porqué reproducirse en el servidor de Exchange en el que se encontraban originalmente. Por ejemplo, si el servidor Exchange original es un servidor cabeza de puente que continuamente transfiere grandes cantidades de mensajes de correo electrónico y no alcanza una cola de trabajo del MTA vacía, puede decidir reproducir los mensajes en otro servidor que ejecute Exchange Server.

•

Puede realizar una reproducción incremental Una reproducción incremental se realiza al dividir los archivos .dat en diversos grupos más pequeños que se reproducen uno por uno. Este método es más complicado que una reproducción completa o remota, pero puede ser de ayuda si tiene que manejar una cifra muy elevada de archivos .dat. Una reproducción incremental también puede ser recomendable cuando hay que entregar mensajes importantes y un mensaje dañado en algún lugar de una cola de mensajes hace que el MTA se detenga inesperadamente. Puede realizar una reproducción incremental en el servidor de Exchange original o en otro servidor de Exchange de la organización.

Para ver instrucciones detalladas acerca de cómo realizar cada uno de estos procedimientos, consulte Cómo reproducir archivos DAT después de un barrido de la base de datos del MTA.

Examen del proceso del MTA de Exchange Las herramientas principales empleadas para supervisar el MTA son el Monitor del sistema (en la herramienta Monitor de rendimiento) y el Visor de sucesos. Puede utilizar el Monitor del sistema para supervisar el comportamiento de los conectores de mensajería en tiempo real. También puede determinar el número de mensajes que esperan en las colas de mensajes entrantes y salientes, así como el número total de mensajes que han sido transferidos por un conector desde que se inició el MTA. Es recomendable comprobar las colas de mensajes utilizando el Monitor del sistema, ya que si hay un gran número de mensajes puestos en cola en un conector de mensajería, eso podría indicar un cuello de

357

botella del rendimiento o el funcionamiento incorrecto de un componente del conector. La herramienta Visor de sucesos le ayudará a identificar y diagnosticar el origen de problemas del sistema, o bien a prever otros posibles inconvenientes. El MTA de Exchange escribe sucesos críticos en el registro de sucesos de la aplicación. Un suceso es una actividad que tiene lugar en el MTA de Exchange y que es posible que requiera la atención del administrador.

Comprobación del MTA de Exchange mediante el Monitor del sistema La supervisión del rendimiento implica el examen de los componentes diferenciados de un sistema. En Windows, un objeto representa un proceso individual, una sección de memoria compartida o un dispositivo físico. Un objeto puede tener asociados varios contadores de rendimiento. Por ejemplo, el objeto MSExchangeMTA posee muchos contadores de rendimiento, entre los que se incluye un contador llamado Longitud de la cola de trabajo, el cual indica el número de mensajes de la cola de trabajo del MTA. Para agregar contadores de rendimiento al Monitor del sistema, inicie la herramienta Monitor de rendimiento y después, en la barra de herramientas, haga clic en Agregar, indicado por un signo más (+). Puede seleccionar el objeto MSExchangeMTA en la lista desplegable Objeto de rendimiento del cuadro de diálogo Agregar contadores. Según su selección, los contadores de rendimiento apropiados se enumeran en la lista Seleccionar contadores. La tabla siguiente enumera los contadores de rendimiento disponibles para el objeto de rendimiento MSExchangeMTA. Contadores de rendimiento de MSExchangeMTA Contador de rendimiento

Descripción

Asociaciones MTA adyacentes

El número de asociaciones que este MTA tiene abiertas con otros MTA.

Mensajes/seg.

La velocidad a la que se procesan los mensajes.

Bytes de mensaje/seg.

La velocidad a la que se procesan los bytes de mensaje.

Elementos libres

El número de elementos de búfer libres en el grupo de MTA.

Encabezados libres

El número de encabezados de búfer libres en el grupo de MTA.

Conexiones de administrador

El número de programas Administrador de Microsoft Exchange conectados con el MTA.

358

Contador de rendimiento

Descripción

Subprocesos en uso

El número de subprocesos utilizados por el MTA. Este número puede utilizarse para determinar la conveniencia de utilizar procesadores adicionales.

Longitud de la cola de trabajo

El número de mensajes pendientes en la cola de trabajo. Esto indica el número de mensajes aún no procesados completamente por el MTA.

Puertas de enlace XAPI

El número de puertas de enlace XAPI conectadas al MTA mediante la interfaz XAPI. Una sola puerta de enlace puede tener múltiples sesiones de puerta de enlace XAPI.

Clientes XAPI

El número de clientes XAPI conectados al MTA mediante la interfaz XAPI. Un solo cliente puede tener múltiples sesiones de cliente XAPI.

Eliminaciones de archivos de disco

El número de operaciones de eliminación de archivos de disco por segundo.

Sincronizaciones de archivos de disco

El número de operaciones de sincronización de archivos de disco por segundo.

Aperturas de archivos de disco

El número de operaciones de apertura de archivos de disco por segundo.

Lecturas de archivos de disco

El número de operaciones de lectura de archivos de disco por segundo.

Escrituras en archivos de disco

El número de operaciones de escritura en archivos de disco por segundo.

Llamadas de lectura ExDS/seg.

La tasa de llamadas al servicio de directorio

Bytes recibidos por XAPI/seg.

La velocidad a la que se reciben los bytes a través de una conexión XAPI.

Bytes transmitidos por XAPI/seg.

La velocidad a la que se transmiten los bytes a través de una conexión XAPI.

Bytes recibidos por la interfaz administrativa/seg.

La velocidad a la que se reciben los bytes a través de una conexión administrativa.

Bytes transmitidos por la interfaz administrativa/seg.

La velocidad a la que se transmiten los bytes a través de una conexión administrativa.

359

Contador de rendimiento

Descripción

Bytes transmitidos por LAN/seg.

La velocidad a la que se transmiten los bytes a los MTA a través de una red LAN.

Bytes recibidos por LAN/seg.

La velocidad a la que se reciben los bytes de los MTA en una red LAN.

Bytes recibidos por RAS/seg.

La velocidad a la que se reciben los bytes en una conexión RAS. Los conectores X.400 basados en RAS no están disponibles en Exchange Server 2003.

Bytes transmitidos por RAS/seg.

La velocidad a la que se transmiten los bytes de una conexión RAS. Los conectores X.400 basados en RAS no están disponibles en Exchange Server 2003.

Bytes recibidos por TCP/IP/seg.

La velocidad a la que se reciben los bytes a través de una conexión TCP/IP.

Bytes transmitidos por TCP/IP/seg.

La velocidad a la que se transmiten los bytes a través de una conexión TCP/IP.

Bytes recibidos por TP4/seg.

La velocidad a la que se reciben los bytes a través de una conexión TP4. Los conectores X.400 basados en TP4 no están disponibles en Exchange Server 2003.

Bytes transmitidos por TP4/seg.

La velocidad a la que se transmiten los bytes a través de una conexión TP4. Los conectores X.400 basados en TP4 no están disponibles en Exchange Server 2003.

Bytes recibidos por X.25/seg.

La velocidad a la que se reciben los bytes a través de una conexión X.25.

Bytes transmitidos por X.25/seg.

La velocidad a la que se transmiten los bytes a través de una conexión X.25.

El MTA de Exchange también le proporciona un objeto de rendimiento para cada conexión establecida por el MTA. En el cuadro de diálogo Agregar contadores, seleccione el objeto Conexiones MSExchangeMTA de la lista desplegable Objeto de rendimiento. Entonces podrá encontrar las instancias de conexión individual en Seleccionar instancias de la lista. Cada instancia de Conexiones MSExchangeMTA describe una sola conexión, pero también puede optar por supervisar todas las instancias a la vez.

360

Contadores de rendimiento para conexiones individuales establecidos por el MTA

La tabla siguiente enumera los contadores de rendimiento disponibles para los objetos de rendimiento Conexiones MSExchangeMTA. Contadores de rendimiento de las conexiones MSExchangeMTA Contador de rendimiento

Descripción

Asociaciones

El número de asociaciones entre el MTA y el MTA conectado. Los MTA pueden abrir varias asociaciones si se precisa una capacidad de transferencia adicional.

Bytes recibidos/seg.

La velocidad a la que se reciben los bytes de la entidad conectada.

Bytes enviados/seg.

La velocidad a la que se envían los bytes a la entidad conectada.

Mensajes recibidos/seg.

La velocidad a la que se reciben los mensajes de la entidad conectada.

Mensajes enviados/seg.

La velocidad a la que se envían los mensajes a la entidad conectada.

361

Nota: Cuando se envían muchos mensajes al MTA de Exchange, el valor Mensajes Mensa enviados/seg. que se visualiza en Conexiones MSExchangeMTA, Servidor SMTP , sube y baja a medida que se transmiten los mensajes. Sin embargo, la Longitud de la cola de trabajo de MSExchangeMTA siempre está a cero. Al enviar mensajes desde Exchang Exchange e a un MTA remoto mediante un conector X.400, tanto la longitud de la cola de trabajo de MS Exchange MTA como el conector X.400 de las conexiones de MS Exchange MTA muestran actividad. Eso se debe al mecanismo distinto utilizado por el MTA para el tratamiento tratamiento de mensajes XAPI entrantes y salientes. Para los mensajes entrantes en el buzón SMTP (una puerta de enlace XAPI), el MTA transfiere inmediatamente los mensajes a la cola de trabajo XAPI (DB000020.dat). Ésta no es la cola de trabajo de MTA (DB000028.dat). (DB000028.dat Sin embargo, para los MTA X.400 o LAN, el MTA coloca el mensaje en la cola de trabajo del MTA y no completa la transferencia hasta que el MTA remoto confirma que se recibió el mensaje. De este modo, el Monitor del sistema puede utilizarse para determinarr detalles del procesamiento interno del MTA.

Registro de sucesos del MTA de Exchange La solución de problemas con el MTA incluye una inspección del registro de sucesos de la aplicación. El MTA de Exchange realiza un seguimiento de los sucesos críticos de forma automática, pero también puede establecer niveles de registro de diagnóstico por categorías para el MTA, con el fin de aumentar el volumen de información que el MTA de Exchange escribe en el registro de sucesos. En el Administrador del sistema de Exc Exchange, muestre las propiedades del servidor que le interesen y luego haga clic en la ficha Registro de diagnóstico. En Servicios, Servicios seleccione MSExchangeMTA y después Categorías para enumerar las categorías del MTA. Cada categoría del MTA posee un nivel de registro r de diagnóstico. Cuando el MTA genera un suceso con un número de significación menor o igual al nivel de registro, el suceso se graba en el registro de sucesos. Si el número de significación del suceso es mayor que el nivel de registro, entonces no se registra. La tabla siguiente enumera las categorías del MTA de Exchange que pueden habilitarse para el registro de diagnóstico. En el funcionamiento normal, todas las categorías del MTA de Exchange deben tener un nivel de registro de Ninguno. En este nivel, nivel, sólo se escriben en el registro de sucesos los sucesos de error y los mensajes críticos. Al aumentar el nivel de registro, seleccione tan sólo aquellas categorías que sean relevantes para el tema en cuestión. Si establece los niveles de registro demasiado iado altos, para demasiadas categorías, el registro de sucesos se llenará rápidamente de información irrelevante. No olvide restablecer el nivel de registro en Ninguno en todas las categorías cuando acabe de examinar el MTA. Sugerencia: También se pueden filtrar sucesos según los orígenes y las categorías de sucesos. En Visor de sucesos, sucesos seleccione el registro Aplicación,, haga clic en Ver y, a

362

continuación, en Filtro. En Origen de suceso, seleccione MSExchangeMTA. Para visualizar todos los sucesos del MTA de Exchange en Visor de sucesos, asegúrese de que Categoría está establecido como Todas. Los registros de sucesos pueden mostrarse de forma local o remota, y pueden guardarse en archivos *.EVT. Categorías de registro de diagnóstico para el MTA de Exchange Categoría

Descripción

Servicio X.400

Notifica sucesos relacionados con el control de protocolos X.400, como por ejemplo, la entrega de mensajes a un MTA remoto.

Recurso

Notifica sucesos relacionados con el uso de los recursos del MTA.

Seguridad

Notifica sucesos relacionados con la seguridad del MTA y las infracciones de seguridad.

Interfaz

Notifica sucesos relacionados con la comunicación entre el MTA y el almacén de Exchange y la comunicación entre los MTA mediante las RPC.

Ingeniería de campo

Notifica sucesos relacionados con la operación del MTA de depuración. Estos sucesos proporcionan detalles sobre el procesamiento interno en el MTA de Exchange y son de utilidad para el especialista de los Servicios de soporte técnico al producto de Microsoft.

Administración de MTA

Notifica sucesos relacionados con las colas de mensajes. Utiliza el complemento Visor de cola, en el Administrador del sistema de Exchange, para trabajar con colas del MTA que generen estos sucesos.

Configuración

Notifica sucesos relacionados con problemas con las opciones de configuración del MTA. Los archivos de ejecución dañados en el directorio \Mtadata o los parámetros del Registro no válidos pueden generar estos sucesos.

Acceso al directorio

Notifica sucesos relacionados con la comunicación con Active Directory.

363

Categoría

Descripción

Sistema operativo

Notifica sucesos relacionados con los servicios del sistema operativo que utiliza el MTA para crear y administrar archivos y subprocesos.

Procesamiento interno

Notifica sucesos relacionados con el procesamiento interno en el MTA de Exchange que pueden ser de utilidad para el especialista de los Servicios de soporte técnico al producto de Microsoft.

364

Categoría

Descripción

Interoperabilidad

Esta categoría no ocasiona la escritura de información en el registro de sucesos suc de la aplicación por parte del MTA. En su lugar, realiza un seguimiento del contenido binario de los mensajes de protocolo. Utilice esta categoría junto con la categoría Interfaz para registrar los mensajes enviados a través de interfaces internas a archivos rchivos AP*.log en el directorio \Archivos de programa\Exchsrvr\Mtadata. Mtadata. Por ejemplo, puede utilizar los archivos AP*.log para crear seguimientos de la pila del MTA y seguimientos XAPI. Los registros de interoperabilidad pueden ser la pieza clave para solucionar cionar los problemas de configuración de los MTA. El aumento de los niveles de registro de diagnóstico a Medio o más en ambas categorías, Interoperabilidad e Interfaz, genera archivos AP*.log. El registro actual siempre se denomina Ap0.log. Los registros anteriores nteriores se denominan AP#.log, y el # aumenta conforme a la antigüedad del registro. Si un registro alcanza los cinco megabytes, se le cambia el nombre y se crea un nuevo AP*.log. Nota: Los archivos AP*.log pueden aumentar con mucha rapidez y producen un impacto sobre el rendimiento del MTA de Exchange.

365

Categoría

Descripción

APDU (Unidad de datos de protocolo de aplicación)

Esta categoría no ocasiona la escritura de información en el registro de sucesos de la aplicación por parte del MTA. En su lugar, realiza un seguimiento del contenido del sobre del mensaje (el P1) de los mensajes que envía y recibe el MTA, así como de las APDU (Unidad de datos de protocolo de aplicación) totalmente codificadas que se transmiten entre los MTA. Utilice esta categoría junto con la categoría Servicio X.400 para registrar información en archivos BF*.log en el directorio \Archivos de programa\Exchasrvr\Mtadata. Mtadata. Los archivos BF*.log son de utilidad para diagnosticar problemas de interoperabilidad o de conformidad, por ejemplo, cuando los mensajes s de los MTA remotos son incorrectos o no tienen el formato correcto. Una herramienta Analizador ASN.1, como la herramienta ASpiriN (incluida en el Kit de recursos de Exchange 2000 Server, disponible en librerías), puede utilizarse para descodificar los datos tos de un BF*.log. El aumento de los niveles de registro de diagnóstico a Medio o más en ambas categorías, APDU y Servicio X.400, genera archivos BF*.log. El registro actual siempre se denomina Bf0.log. Los registros anteriores se denominan BF#.log, y el # aumenta conforme a la antigüedad del registro. Si un registro alcanza un tamaño de 5 megabytes, se le cambia el nombre y se crea un nuevo BF*.log. Nota: Los archivos BF*.log pueden aumentar con mucha rapidez y producen un impacto sobre el rendimiento dell MTA de Exchange.

366

Registro de sucesos de texto Para registrar toda la información de sucesos del MTA en archivos EV*.log del directorio \Exchsrvr\Mtadata, Mtadata, establezca el siguiente parámetro del Registro. Los archivos EV*.log son una copia no localizada en formato de texto de los mismos sucesos de MSExchangeMTA que están registrados en el registro de sucesos de la aplicación. Las categorías y los niveles de los sucesos escritos en los archivos de registro se controlan tal y como se describe en la tabla 7.4. 4. Los archivos EV*.log son más fáciles de leer, buscar y copiar que el correspondiente registro de sucesos de la aplicación cuando hay que solucionar problemas del MTA. Ubicación

HKEY_LOCAL_MACHINE\CurrentControlSet CurrentControlSet\Servi ces\MSExchangeMTA\Parameters Parameters

Valor

TextEventLogging

Tipo

REG_DWORD

Información del valor

0x1

Descripción

Al establecer este valor como 0x1 se habilita el registro de texto en los archivos EV*.log.

Para obtener más información acerca de los diferentes registros que puede crear el MTA de Exchange, consulte el artículo 153188 de Microsoft Knowledge Base, “XCON: “XCON: Descripción de opciones Registro de diagnósticos MTA ".

Registro del nivel de seguimiento Cuanto más elevado o es el nivel de registro de diagnóstico, más sucesos relacionados con el MTA encontrará en el registro de sucesos de la aplicación. Esta información adicional mejora su capacidad de determinar la causa de un problema del flujo de mensajes. Para obtener información formación lo más detallada posible sobre el MTA de Exchange, establezca el nivel de registro de diagnóstico para las categorías del MTA en el nivel de seguimiento. El registro del nivel de seguimiento no se encuentra expuesto en el Administrador del sistema sistem de Exchange y sólo puede establecerse mediante el Editor del Registro. Nota: El registro del nivel de seguimiento menoscaba de forma apreciable el rendimiento del servidor. Utilice el registro del nivel de seguimiento conforme a los consejos de los Servicios vicios de soporte técnico al producto de Microsoft cuando tenga que solucionar problemas complejos del MTA de Exchange. Precaución: El uso del Editor del Registro puede ocasionar problemas graves que quizás requieran reinstalar el sistema operativo. Microsoft Microsoft no puede garantizar que estos

367

problemas derivados del uso incorrecto del Editor del Registro puedan solucionarse. Utilice el Editor del Registro bajo su propia responsabilidad. Para establecer el nivel de registro de diagnóstico de las categorías de MSExchangeMTA en el nivel de seguimiento, lleve a cabo los pasos siguientes: 1. Inicie el Editor del Registro y abra la siguiente clave del Registro: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeMTA\Diagnostics

2. Haga doble clic en cada entrada para las categorías MSExchangeMTA individuales y establezca los valores como 0x7. Por ejemplo, haga doble clic en el panel de la derecha de la entrada Servicio X.400 1 y luego cambie el valor a 0x7. 3. Reinicie el servicio Pila MTA de Microsoft Exchange. Normalmente no es preciso reiniciar los servicios por orden para que el cambio surta efecto. Sin embargo, al modificar manualmente el Registro, es posible que deba realizar este paso.

Registro de comprobación del MTA Una herramienta para la solución de problemas muy poco utilizada es un archivo actual y detallado Mtacheck.log. Este archivo de registro muestra los resultados de la ejecución de Mtacheck.exe. Puede ejecutar la herramienta Comprobación del MTA de forma manual, pero también se ejecuta automáticamente si el servicio Pila MTA de Microsoft Exchange determina que el MTA se ha apagado de forma incorrecta antes. Si la herramienta Comprobación del MTA se ejecuta automáticamente, los sucesos se registran en el registro de sucesos de la aplicación y se genera un archivo Mtacheck.log en el directorio \Archivos de programa\Exchsrvr\Mtadata\Mtacheck.out. Puede utilizar el archivo Mtacheck.log para realizar las siguientes tareas: •

Obtener una lista rápida de todas las colas seguras y sus Id. de objeto asociados.

•

Identificar rápidamente en qué cola se encuentra un objeto de mensaje durante el inicio del MTA.

•

Asociar entre sí los datos y los objetos de referencia que se encuentran en la cola de trabajo durante el inicio.

Para obtener más información acerca del archivo Mtacheck.log, consulte el artículo 163323 de Microsoft Knowledge Base, “XCON: Mtacheck.log".

Id. de objeto e Id. de mensaje Para cada objeto procesado por el MTA de Exchange existe un Id. de objeto asociado de ocho dígitos. Los dos primeros dígitos del Id. de objeto identifican la clase de objeto. Los seis últimos dígitos del Id. corresponden a un archivo DB<6digit>.dat si el objeto está escrito en el disco. Las clases de objeto del MTA en hexadecimales van de 01 a 0E. Las dos clases más importantes son 01 (colas) y 06 (mensajes). Por ejemplo, el siguiente suceso se refiere a un objeto de mensaje con un Id. de 0600002D. Event ID: 272

368

Source: MSExchangeMTA Type: Information Category: X.400 Service received from entity /DC=COM/DC=CONTOSO/CN=CONFIGURATION/CN=SERVICES/CN=MICROSOFT EXCHANGE/CN=FIRST ORGANIZATION/CN=CONNECTIONS/CN=SMTP (SERVER01-{43D5C017 (SERVER01 {43D5C017-4A4B-4AFD85AF-06EAB90057AA}). 06EAB90057AA}). The entity ent is a XAPI-Gateway Gateway

, object is a Normal priority

Message, the MTS identifier is C=US;A= ;P=First Organizati;L=SERVER01-040503155933Z-4, Organizati;L=SERVER01 and content length is 1719. The number of objects sent so far = 1. External trace information (first 100 bytes) bytes = 3080638061801302555300006280130120000013104669727374204F7267616E697A61746900003180800D 3034303530333136303234315A8201008302060000000000. (10)

Nota: No todos los objetos que administra el MTA están escritos en el disco. Los objetos no seguros puede que sólo existan en la memoria. Cada mensaje también posee un Id. asociado, que se conoce como el Id. de mensaje o el identificador del Servicio de Transferencia de Mensajes (MTS). A diferencia de los Id. de objeto, que sólo son utilizados por el MTA de Exchange Exchange local, el Id. de mensaje forma parte del propio mensaje y puede realizarse su seguimiento a través de los MTA. Un Id. de mensaje típico generado por un MTA de Exchange tiene el formato siguiente: C=;A= ;P=;L=<server>-;L=<server> eenich mean time>-<message time>

Hay un ejemplo en negrita en el suceso 272 mostrado anteriormente. Existen diversas variaciones de L= valor, en función del origen del mensaje. Los Id. de mensaje de fuera de Exchange pueden diferir, pero su objetivo es el el mismo. Los identificadores MTS ayudan a asociar copias de mensaje con un origen de mensaje concreto. Por ejemplo, si se envía un mensaje a un grupo de distribución con cientos de destinatarios, cada copia de despliegue del mensaje tiene el mismo Id. de mensaje, mensaje, incluso después de que los mensajes abandonen el MTA. number>

Cómo realizar un barrido de la base de datos del MTA Este procedimiento explica cómo barrer la base de datos del MTA (en concreto, cómo mover archivos para crear un directorio de base de datos vacío). v

Antes de empezar Antes de realizar el procedimiento de este tema, tenga en cuenta lo siguiente: Si necesita barrer una base de datos MTA, debería ponerse en contacto con Microsoft Product Support upport Services para obtener ayuda con el fin de asegurarse de que realiza los

369

pasos correctamente. Si aplica los pasos de forma incorrecta, es posible que pierda mensajes de correo electrónico que se encuentran en las colas de mensajes del MTA.

Procedimiento nto Barrer la base de datos del MTA 1. Utilice la herramienta Servicios (grupo de programas Herramientas administrativas del menú Inicio) para asegurarse de que el servicio Pila MTA de Microsoft Exchange se detuvo. 2. Copie todo el contenido del directorio de la base de datos del MTA (de forma predeterminada, es el directorio \Archivos de programa\Exchsrvr\\Mtadata) en una ubicación diferente. Esto es preferible a mover tan sólo los archivos .dat, pues es posible que los Servicios de soporte técnico al producto de Microsoft necesiten todo el contenido del directorio Mtadata para determinar qué ha ocasionado el problema. Nota: No elimine los archivos .dat originales hasta que haya recuperado los mensajes. 3. Compruebe que ue el proceso de copia se completa correctamente y luego elimine los archivos .dat del directorio de la base de datos del MTA. 4. Copie todos los archivos que se encuentran en el directorio \Setup\i386\Exchange Exchange\Bootenv Bootenv del CD del producto Exchange Server 2003 en el directorio activo de la base de datos del MTA. El servicio Pila MTA de Microsoft Exchange no se puede iniciar sin los archivos .dat básicos. 5. Quite el atributo de archivo de sólo lectura de los archivos copiados. No puede haber archivos de sólo lectura en el directorio de la base de datos del MTA. 6. Reinicie el servicio Pila MTA de Microsoft Exchange. Si el MTA tuvo problemas de mensajes dañados en los archivos .dat, ahora el MTA puede reanudar la transferencia de operaciones y de mensajes.

Para ra obtener más información Una vez realizado un barrido de la base de datos del MTA, los mensajes que contienen los archivos .dat que se hayan movido del directorio de la base de datos del MTA tendrán que reproducirse para poder entregarse. Para obtener in instrucciones strucciones detalladas acerca de cómo reproducir archivos DAT tras haber barrido la base de datos del MTA, consulte Cómo reproducir archivos DAT después de un barrido de la base de datos del MTA MTA.

370

Cómo reproducir archivos DAT después de un barrido de la base de datos del MTA Una vez realizado un barrido de la base de datos del MTA, los mensajes que contienen los archivos .dat que se hayan movido del directorio de la base de datos del MTA tienen que reproducirse para poder entregarse. Este tema proporciona vínculos a los tres procedimientos para reproducir archivos .dat después de un barrido de la base de datos del MTA: •

Una reproducción completa (en la que todos los archivos .dat se reproducen a la vez en el servidor de Exchange en el que se encontraban originalmente).

•

Una reproducción remota (en la que los archivos .dat se reproducen en un servidor de Exchange distinto del que se encontraban originalmente)

•

Una reproducción incremental (en la que los archivos .dat se dividen en varios grupos más pequeños que se reproducen uno a uno).

Antes de empezar Antes de realizar los procedimientos descritos en este tema, debe tener en cuenta las diferencias existentes entre los tres métodos. Para obtener información general acerca de los tres métodos, consulte la sección "Reproducción de archivos DAT" en MTA de Exchange en la arquitectura de Exchange Server 2003.

Procedimiento Para reproducir archivos DAT tras un barrido de la base de datos del MTA •

Seleccione uno de estos tres métodos: •

Cómo reproducir archivos DAT después de un barrido de la base de datos del MTA mediante una reproducción completa

•

Cómo reproducir archivos DAT después de un barrido de la base de datos del MTA mediante una reproducción remota

•

Cómo reproducir archivos DAT después de un barrido de la base de datos del MTA mediante una reproducción incremental

Referencia Para obtener información general acerca de como barrer la base de datos del MTA y reproducir archivos DAT, consulte las secciones "Barrido de la base de datos del MTA" y "Reproducción de archivos DAT" en MTA de Exchange en la arquitectura de Exchange Server 2003.

371

Cómo reproducir archivos DAT después de un barrido de la base de datos del MTA mediante una reproducción completa Este procedimiento explica cómo reproducir archivos DAT tras un barrido de la base de datos del MTA a través de una reproducción completa; en concreto, cómo reproducir todoslos mensajes a la vez en el servidor en el que se encontraban originalmente. Por lo general, ésta es la forma más fácil de reproducir los archivos .dat.

Antes de empezar Antes de realizar el procedimiento de este tema, tenga en cuenta lo siguiente: Cuando se prepare para realizar la reproducción, compruebe que el MTA del servidor de origen de Exchange no tiene nada en sus colas. Si actualmente no hay mensajes en las colas del MTA, éste puede detenerse. Los archivos .dat pueden pueden moverse de forma segura y eliminarse si es preciso, porque no hay mensajes pendientes de entrega. Si hay mensajes en las colas del MTA, el MTA deberá poder finalizar el envío de mensajes hasta que todas las colas estén vacías. Una vez todas las colas están están vacías, el MTA debe detenerse inmediatamente. Una vez detenido el MTA, mueva los archivos .dat actuales a otra ubicación. No deje ningún archivo .dat anterior en el directorio de la base de datos del MTA. Copie los archivos .dat que deben reproducirse al al directorio de la base de datos del MTA.

Procedimiento Para realizar una reproducción completa de archivos .dat tras un barrido de la base de datos del MTA 1. Compruebe si todas las colas del MTA del servidor que ejecuta Exchange Server están vacías. Si llas as colas no están vacías, permita que el MTA finalice el envío de todos los mensajes que hay en las colas. Nota: Puede utilizar la herramienta Monitor de rendimiento (Perfmon.msc) para comprobar que no hay mensajes en las colas del MTA. Por ejemplo, para par comprobar la cola de trabajo, seleccione el objeto de rendimiento MSExchangeMTA y después el contador de rendimiento Longitud de la cola de trabajo trabajo, tal como se muestra en la figura siguiente. Comprobación del número de mensajes de la cola de trabajo del de MTA

372

2. Cuando la cola de trabajo del MTA esté vacía, detenga el servicio Pila MTA de Microsoft Exchange. 3. Copie todo el contenido del directorio de la base de datos del MTA a otra ubicación. Estos archivos se acaban descartando si las colas del MTA estaban a cero antes de detener el MTA. 4. Elimine los archivos .dat del directorio de la base de datos del MTA. 5. Copie los archivos .dat del directorio que contiene el conjunto original de archivos .dat que desee reproducir en el directorio de la base de datos del MTA. 6. Reinicie el servicio Pila MTA de Microsoft Exchange. 7. Supervise las colas del MTA y los registros de sucesos para asegurarse de que todos los mensajes se entregan de forma correcta y el MTA sigue funcionando como es habitual.

Para más información •

Para obtener información acerca de cómo reproducir archivos .dat tras un barrido de la base de datos del MTA a través de una reproducción remota, consulte Cómo reproducir archivos DAT después de un barrido de la base de datos del MTA mediante una reproducción remota.

373

•

Para obtener información acerca de cómo reproducir archivos .dat tras un barrido de la base de datos del MTA a través de una reproducción incremental, consulte Cómo reproducir archivos DAT después de un barrido de la base de datos del MTA mediante una reproducción incremental.

Cómo reproducir archivos DAT después de un barrido de la base de datos del MTA mediante una reproducción remota Este procedimiento explica cómo reproducir archivos DAT tras un barrido de la base de datos del MTA a través de una reproducción remota; en concreto, cómo reproducirlos en un servidor de Exchange que no sea en el que se encontraban originalmente. Por ejemplo, si el servidor Exchange original es un servidor cabeza de puente que continuamente transfiere una gran cantidad de mensajes de correo electrónico y no alcanza una cola de trabajo del MTA vacía, puede decidir realizar este procedimiento por comodidad. El servidor de reproducción remota puede encontrarse en cualquier grupo de enrutamiento de la organización de Exchange.

Antes de empezar Antes de realizar el procedimiento de este tema, tenga en cuenta lo siguiente: •

Los pasos para reproducir los archivos .dat de forma remota son prácticamente iguales a los pasos para realizar una reproducción completa, que reproduce los archivos .dat en el servidor original. Sin embargo, antes de realizar una reproducción remota tiene que establecer una clave del Registro especial en el servidor que ejecuta Exchange Server en el que desee reproducir los archivos .dat

•

Igual que haría para preparar una reproducción completa, antes de realizar una reproducción remota, asegúrese de que el MTA del servidor de origen de Exchange no tiene nada en sus colas. Si actualmente no hay mensajes en las colas del MTA, éste puede detenerse. Los archivos .dat pueden moverse de forma segura y eliminarse si es preciso, porque no hay mensajes pendientes de entrega. Si hay mensajes en las colas del MTA, el MTA deberá poder finalizar el envío de mensajes hasta que todas las colas estén vacías. Una vez todas las colas están vacías, el MTA debe detenerse inmediatamente. Una vez detenido el MTA, mueva los archivos .dat actuales a otra ubicación. No deje ningún archivo .dat anterior en el directorio de la base de datos del MTA. Copie los archivos .dat que deben reproducirse al directorio de la base de datos del MTA.

•

Este tema contiene información acerca de la modificación del Registro.

374

Precaución: La modificación incorrecta del Registro puede ocasionar problemas graves que quizás requieran volver a instalar el sistema operativo. Es posible que los problemas derivados de una modificación incorrecta del Registro no se puedan resolver. Antes de de modificar el Registro, se recomienda realizar una copia de seguridad de todos los datos importantes.

Procedimiento Reproducir los archivos .dat tras un barrido de la base de datos del MTA a través de una reproducción remota 1. Establezca la siguiente clave del Registro en el servidor que ejecuta Exchange Server en el que desee reproducir los archivos .dat. Ubicación

HKEY_LOCAL_MACHINE\System\CurrentControlSet CurrentControlSet\Services MSExchangeMTA\Parameters

Valor

Dispatch remote MTA messages

Tipo

REG_DWORD

Información del valor

0x1

Descripción

Hace que el MTA agregue información adicional de seguimiento a cada mensaje antes del enrutamiento, de modo que los servidores de destino de Exchange que tratan originalmente los mensajes no identifican los mensajes como bucle. Este valor del Registro distingue mayúsculas de minúsculas y debe introducirse exactamente tal y como se muestra arriba. Si el MTA completó correctamente la entrega de todos los mensajes reproducidos, la clave del Registro tro deberá quitarse, o bien establecerse como 0x0.

2. Siga los pasos de este procedimiento: Cómo reproducir archivos DAT después de un barrido de la base de datos del MTA mediante una reproducción completa 3. Si el MTA completa correctamente la entrega de todos los mensajes reproducidos, debe quitarse la clave del Registro que se h ha a configurado para la reproducción remota.

375

Para más información •

Para obtener información acerca de cómo reproducir archivos DAT tras un barrido de la base de datos del MTA a través de una reproducción completa, consulte Cómo reproducir archivos DAT después de un barrido de la base de datos del MTA mediante me una reproducción completa. completa

•

Para obtener información acerca de cómo reproducir archivos DAT tras un barrido de la base de datos del MTA a través de una reproducción incremental, consulte Cómo reproducir archivos DAT después de un barrido de la base de datos del MTA mediante una reproducción incremental. incremental

Cómo reproducir archivos DAT después de un barrido de la base de datos del MTA mediante una reproducción incremental Este procedimiento explica cómo reproducir archivos DAT tras un barrido de la base de datos del MTA A a través de una reproducción incremental. Las reproducciones incrementales son aquellas en que los archivos .dat se dividen en varios grupos más pequeños que se reproducen uno a uno. Este método es más complicado que una reproducción completa o remota, pero ero puede ser de ayuda si tiene que manejar una cifra muy elevada de archivos .dat. Una reproducción incremental también puede ser recomendable cuando hay que entregar mensajes importantes pero un mensaje dañado en algún lugar de una cola de mensajes hace que el MTA se detenga inesperadamente.

Antes de empezar Antes de realizar el procedimiento de este tema, tenga en cuenta lo siguiente: •

Si va a realizar una reproducción incremental en un servidor de Exchange que no sea en el que se encontraban originalmente originalmente los archivos .dat, debe asignar primero el valor 0x1 a la clave del Registro Distribuir mensajes remotos del MTA.. Para obtener instrucciones acerca de cómo configurar esta clave del Registro, consulte Cómo reproducir archivos DAT después de un barrido de la base de datos del MTA mediante una reproducción remota. remota

•

Este tema contiene e información acerca de la modificación del Registro. Precaución: La modificación incorrecta del Registro puede ocasionar problemas graves que quizás requieran volver a instalar el sistema operativo. Es posible que los problemas derivados de una modifica modificación ción incorrecta del Registro no se puedan resolver. Antes de modificar el Registro, se recomienda realizar una copia de seguridad de todos los datos importantes.

376

Procedimiento Para reproducir archivos DAT tras un barrido de la base de datos del MTA a través travé de una reproducción incremental 1. Cree una segunda copia de todo el conjunto de archivos .dat. Guarde un conjunto como copia de seguridad y utilice el otro conjunto durante la reproducción incremental. Lo ideal es que el conjunto que debe reproducirse se s encuentre en la misma unidad que el directorio de la base de datos del MTA. Nota: Es recomendable guardar un conjunto completo de los archivos .dat en otra ubicación, de modo que disponga de una copia de seguridad completa si la reproducción incremental increment fracasa. 2. Compruebe que el servidor de reproducción tiene colas del MTA vacías. 3. Si no hay mensajes residentes en la cola de trabajo del MTA, detenga el servicio Pila MTA de Microsoft Exchange y copie los archivos .dat actuales en otra ubicación. Si es preciso, estos archivos .dat pueden eliminarse, pues no hay mensajes pendientes de transferencia. 4. Elimine todos los archivos .dat del directorio de la base de datos del MTA. 5. Copie todos los archivos que se encuentran en el CD del producto Exchange Server 2003, en el directorio \Setup\i386\Exchange\Bootenv, Bootenv, al directorio activo de la base de datos del MTA. 6. Quite el atributo de archivo de sólo lectura de los archivos copiados. copiado 7. Mueva una parte de los archivos .dat que deben reproducirse al directorio de la base de datos del MTA. Por ejemplo, si tiene que reproducir 30.000 archivos .dat, quizás desee reproducir los mensajes en bloques de 5.000 o 10.000 archivos .dat. Nota: Asegúrese de que mueve los archivos. Si en lugar de moverlos, copia los archivos, se hace difícil distinguir entre los archivos que acaba de reproducir y los archivos que aún tiene que reproducir. La reproducción reiterada de un mensaje conlleva entrega entregas s reiteradas del mensaje. Si la copia de trabajo de los archivos .dat se encuentra en el mismo directorio que el directorio de la base de datos del MTA, la acción de mover los archivos al directorio de la base de datos del MTA se simplifica. 8. Ejecute Mtacheck check /V para comprobar la base de datos del MTA. 9. Inicie el servicio Pila MTA de Microsoft Exchange y supervise la cola de trabajo y los registros de sucesos del MTA para asegurarse de que todos los mensajes se procesan correctamente y de que el MTA funciona funciona con normalidad. 10. Repita los pasos hasta que se hayan reproducido todos los archivos .dat. 11. Si está llevando a cabo una reproducción remota incremental, no olvide quitar la

377

clave del Registro Distribuir mensajes remotos del MTA o establecerla en 0x0 cuando haya acabado.

Para más información •

Para obtener información acerca de cómo reproducir archivos DAT tras un barrido de la base de datos del MTA a través de una reproducción completa, consulte Cómo reproducir archivos DAT después de un barrido de la base de datos del MTA mediante una reproducción completa.

•

Para obtener información acerca de cómo reproducir archivos DAT tras un barrido de la base de datos del MTA a través de una reproducción remota, consulte Cómo reproducir archivos DAT después de un barrido de la base de datos del MTA mediante una reproducción remota.

Pilas de transporte del MTA y conectores X.400 El estándar X.400 se basa en el modelo de referencia Interconexión de Sistemas Abiertos (OSI) tal como se define en la recomendación X.200. El MTA de Exchange contiene el código para los cuatro niveles superiores de la pila OSI (es decir: aplicación, presentación, sesión y transporte). Bajo el nivel de transporte OSI, el MTA utiliza controladores instalados en el sistema operativo. El modelo de referencia OSI está formado por siete niveles, tal como se ilustra en la figura siguiente. Estándares de ITU en el modelo de referencia OSI

Tal como indica esta figura, el protocolo TCP/IP no se ajusta exactamente en la pila OSI. Esto se debe a que el protocolo TCP/IP, a pesar de ser una pila de protocolo organizada por

378

niveles, no es compatible con OSI (aunque la mayoría de elementos de TCP/IP pueden asignarse a OSI). El TCP/IP fue desarrollado originariamente por la Agencia de Proyectos de Investigación Avanzada (ARPA), basado en un modelo de cuatro niveles, denominado el modelo TCP/IP (llamado a veces “el modelo Internet”). Para aceptar la comunicación X.400 mediante TCP/IP conforme al estándar OSI, el MTA de Exchange implementa una interfaz Clase de Protocolo de Transporte 0 (TP0) sobre TCP/IP, tal como se define en la RFC 1006. El MTA de Exchange también puede utilizar las RPC como mecanismo de transporte para comunicarse con los MTA LAN y las puertas de enlace XAPI. Las RPC representan un mecanismo de comunicación en el nivel de aplicación, porque la biblioteca en tiempo de ejecución de la RPC incluye servicios de presentación y sesión. Sin embargo, en el contexto de la pila MTA, las RPC implementan una interfaz bajo el nivel de sesión. Los servicios internos del tiempo de ejecución de la RPC son transparentes para el MTA. El protocolo X.25 es un protocolo compatible compatible con OSI diseñado específicamente para conexiones de una red de área extensa (WAN) en redes de conmutación de paquetes (como por ejemplo, un proveedor X.400 público). El transporte MTA actúa directamente como interfaz con el protocolo X.25, pues el X.25 X.25 posee una interfaz de protocolo Clase de Transporte 0 (TP0) para el nivel de transporte. En el extremo OSI del nivel de vínculo de datos, X.25 utiliza el protocolo HDLC – LAPB (Control de enlace de datos de alto nivel – Procedimiento compensado de acceso acces al enlace). HDLC - LAPB es el protocolo que utiliza la tarjeta X.25 EICON para comunicarse con el módem sincrónico que conecta el servidor a la red X.25 pública. X.25 es el protocolo de red que opera sobre HDLC de forma que el sistema local puede comunicarse arse con el siguiente nodo de la red X.25. Exchange sólo acepta tarjetas X.25 EICON. Nota: El modelo de referencia OSI define cinco protocolos en el nivel de transporte, del TP0 al TP4. Los protocolos aumentan en complejidad de 0 a 4. TP0 realiza tareas de segmentación y reensamblaje sin recuperación de errores. TP1 lleva a cabo segmentación y reensamblaje y recuperación de errores. TP2 posee capacidades de multiplexado y desmultiplexado. TP3 combina todas las características de TP0, TP1 y TP2. TP4 agrega a TP3 servicios de transporte confiables. Principalmente, TP4 es el equivalente OSI de TCP y la mayoría de las veces es utilizado por los MTA X.400 que no pueden utilizar el protocolo TCP/IP (como por ejemplo, la anterior puerta de enlace de Microsoft Mai Mail a X.400). Exchange Server 2003 no es compatible con TP4, porque no se dispone de una pila del protocolo TP4 para Windows Server 2003. Los parámetros del Registro, como bloques de control TP4 y subprocesos TP4, TP4 que puede encontrar en HKEY_LOCAL_MACHINE HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeMT MSExchangeMT A\Parameters,, son parámetros heredados para Exchange Server 5.5 al ejecutar Microsoft Windows NT (donde se disponía de un protocolo TP4). Estas opciones son irrelevantes para Exchange Server 2003.

379

Servicio de transferencia de mensajes Los subprocesos XFER IN y XFER OUT del proceso del MTA anteriormente descrito en esta sección, inician el servicio de transferencia de mensajes del MTA. El Elemento del servicio de transferencia de mensajes (MTSE) utiliza el Elemento de servicio de transferencia confiable (RTSE) para enviar mensajes a través de una conexión a un MTA remoto, y los Elementos del servicio de control de asociación (ACSE) para establecer conexiones y desconectarlas. Los mensajes que los MTSE intercambian entre sí se denominan mensajes P1 para indicar su formato. El protocolo P1 define el formato de un sobre de transferencia de mensajes. El sobre contiene el mensaje real, además de campos de enrutamiento y de control, de forma que los MTSE pueden enrutar y rastrear un mensaje, además de realizar un seguimiento del contenido del mensaje. La figura siguiente ilustra un ejemplo de un sobre de transferencia de mensajes P1 en la herramienta Aspirin. ASpiriN es un analizador ASN.1 que puede encontrar en el Kit de recursos de Exchange 2000 Server (disponible en librerías). En X.400, se aplica formato a los datos mediante la sintaxis ASN.1. Un sobre de transferencia de mensajes P1

El mensaje real se encuentra en la parte X400COM_Content del sobre P1. El mensaje suele formatearse conforme al protocolo P2/P22, el cual describe el formato para mensajes interpersonales. Los MTA de Exchange admiten otros formatos de mensaje, como el P772 o el P42, para mensajes militares. La tabla siguiente enumera los formatos de mensaje admitidos por el MTA de Exchange. Sin embargo, es preciso tener en cuenta que no todos estos formatos se ajustan al estándar X.400. Algunos formatos de mensaje son específicos de Exchange Server.

380

Formatos de mensaje admitidos en Exchange Server 2003 Formato

Tipo de contenido

Identificador de objeto

MDBEF

•

Formato de codificación de la base de datos de Microsoft (MDBEF).

2A864886F7140501

•

Tipo de contenido registrado y definido por Microsoft.

•

También denominado “Contenido MS Exchange”.

•

No se ajusta al X.400. Sólo puede emplearse entre los MTA de Exchange de la misma organización.

•

Tipo de contenido definido por Microsoft para los mensajes de replicación de carpetas públicas.

•

No se ajusta al X.400. Sólo puede emplearse entre los MTA de Exchange de la misma organización.

•

Definido en el X.400 del año de conformidad 1984.

•

Define el formato de un mensaje interpersonal (IPM).

•

Definido en el X.400 del año de conformidad 1988.

•

Extiende el formato de un mensaje interpersonal (IPM) definido en X.40084.

Carpeta pública MDBEF

P2

P22

2A864886F7140502

56010A00

56010A01

381

Formato

Tipo de contenido

Identificador de objeto

P772

•

Mensaje militar.

2B1A00A236000401

•

Extiende el protocolo P22 con extensiones definidas para el Sistema de mensajes de defensa (DMS), en “Allied Communication Publication (ACP) 123”.

•

Estas extensiones (propiedades adicionales) están permitidas por el estándar X.400 y normalmente sólo las exponen clientes compatibles con DMS, así como clientes STANAG 4406 v1.7 y v3.

•

Mensaje militar seguro.

•

Mensaje militar firmado digitalmente, cifrado, o bien firmado y cifrado mediante la versión 3 del Protocolo de seguridad de mensajes (MSP3) (dentro del DMS no se permite sólo el cifrado).

•

Los certificados son X.509 y análogos a un S/MIME V1.

•

También denominado “MSP3”.

P42

60.864.801.650.201.024A

382

Formato

Tipo de contenido

Identificador de objeto

CSP

•

Protocolo de seguridad común.

608648016502010203

•

Utilizado dentro del DMS para definir un mensaje militar seguro.

•

Mensaje militar firmado digitalmente, o bien firmado y cifrado mediante la versión 4 del Protocolo de seguridad de mensajes (MSP4).

•

Los certificados son X.509 y análogos a un S/MIME V3.

•

Dentro del programa DMS, se denomina “ACP120” o “MSP4”.

383

Formato

Tipo de contenido

Identificador de objeto

TNEF

•

Formato de codificación neutro para el transporte (TNEF).

2A864886F7140502

•

Tipo de contenido registrado y definido por Microsoft.

•

También denominado “MAPI”.

•

Se ajusta al X.400 porque el mensaje y todos sus datos adjuntos se encuentran encapsulados y adjuntos al propio mensaje como datos adjuntos binarios.

•

El cliente receptor debe poder descodificar el TNEF, de lo contrario, el cliente verá un dato adjunto inútil denominado Winmail.dat. Para ver una explicación detallada de TNEF, consulte Arquitectura de transporte SMTP.

La figura siguiente ilustra de qué modo los protocolos P1 y P2 se asignan a la arquitectura de Exchange Server 2003. Protocolos de sobre y de mensaje

384

Nota: El estándar X.400 define protocolos para clientes para interactuar con un MTA (P3) y un almacén de mensajes (P7). Sin embargo, estos protocolos no se utilizan en Exchange Server 2003: en él los clientes no se com comunican unican directamente con el MTA ni utilizan las RPC (como el complemento Visor de cola). La comunicación del cliente con el almacén de Exchange se basa en protocolos MAPI o Internet.

Servicio de transferencia confiable Si el MTSE desea enviar un mensaje a o otro tro MTA, utiliza la Interfaz de servicio de transferencia confiable (RTSI) para llamar al RTSE. El MTA contiene una máquina de estados que decide qué paquetes de datos enviar a través del RTSE. Después de eso, el RTSE envía los paquetes. Por ejemplo, el MT MTA A emite una RT_TRANSFER_REQUEST al RTSE y entonces el RTSE intenta transferir el mensaje en cuestión a otro MTA. Una vez se ha enviado el mensaje, el RTSE devuelve una RT_TRANSFER_CONFIRMED al MTSE para que el MTA pueda marcar el mensaje como transferido. Los detalles de las máquinas de estados se indican en X.228. El RTSE ofrece una transferencia de datos confiable transformando los datos en una cadena de octetos. Luego divide la cadena en segmentos denominados APDU (Unidad de datos de protocolo de aplicación) ión) y después ofrece cada APDU al nivel de presentación para su entrega. El RTSE garantiza que las APDU llegan intactas y sin duplicación al ser transferidas entre los MTA. Cuando se interrumpe una conexión por cualquier motivo, el RTSE es el responsable de reintentar la transferencia de datos. El RTSE admite la recuperación inteligente entre las APDU mediante el establecimiento de puntos de control. Los puntos de control permiten al RTSE reanudar la transferencia de APDU en el punto en que se produjo la interrupción, nterrupción, en lugar de retransmitir la APDU completa. La actividad y los dispositivos de sincronización secundarios del nivel de sesión admiten la interrupción y la posible reanudación de la transferencia de datos en caso de que se pierda la conexión con la red subyacente. Nota: Puede configurar el tamaño del punto de control, el tamaño de la ventana y los tiempos de espera de recuperación en los valores RTS de un conector X.400 o del objeto de directorio MTA. Los servicios ofrecidos por el RTSE se divi dividen den en las tres categorías siguientes: •

Establecimiento de asociación Una asociación es una conexión lógica entre dos MTA que se utiliza para la transferencia de mensajes a través de una conexión física. Los MTA pueden establecer múltiples asociaciones asociaciones a través de una sola conexión física para enviar varios mensajes a la vez. El RTSE utiliza una APDU RT RT-OPEN OPEN REQUEST (RTORQ) para establecer una asociación. Una APDU RT-OPEN-ACCEPT RT ACCEPT (RTOAC) se utiliza en una respuesta positiva a la solicitud de establecer una asociación entre dos MTA. Por otro lado, una APDU RT RT-OPEN-REJECT REJECT (RTORJ) se utiliza en una respuesta negativa a la solicitud de establecer una asociación.

385

•

•

Transferencia de datos El RTSE utiliza las APDU RT-TRANSFER para la transferencia de datos. El diálogo puede ser unidireccional o bidireccional alternativo, en función de si los datos se transfieren sólo desde un MTA o sucesivamente en ambas direcciones. Cada asociación, a través de un vínculo bidireccional alternativo, posee un testigo de turno que sólo puede poseer un MTA a la vez. Cuando un MTA tiene que enviar un mensaje pero no tiene el turno en una asociación abierta, debe determinar cuántas asociaciones abiertas hay en el vínculo. Si hay menos de ocho asociaciones, el MTA intenta abrir una nueva asociación en la que tenga el turno. Si ya hay ocho asociaciones abiertas, el MTA envía una solicitud RT_TURN_PLEASE a través de una de las asociaciones. Si el MTA de recepción puede liberar el turno, devuelve una respuesta RT_TURN_GIVE y el MTA de solicitud tiene autorización para transferir el mensaje. Si el MTA de recepción no puede liberar el turno, sencillamente no responde hasta que está preparado para liberar el turno. En una comunicación bidireccional alternativa, el RTSE puede utilizar las APDU RT-TURN-PLEASE y RT-TURN-GIVE para cambiar las direcciones de transferencia de datos como se indica a continuación: •

RT-TURN-PLEASE Si es el turno de un MTA y recibe una solicitud RT-TURNPLEASE de otro MTA, el MTA emite una solicitud P-TOKEN-PLEASE primitiva, de modo que el MTA de solicitud puede convertirse en el MTA de envío. Las solicitudes RT_TURN_PLEASE pueden tener diferentes prioridades, en función de la prioridad del mensaje. La prioridad 0 se reserva para cuando un MTA desea apagar una asociación o cuando un MTA desea enviar información de enrutamiento.

•

RT-TURN-GIVE Si es el turno de un MTA y recibe una solicitud RT-TURN-GIVE primitiva de un MTA de solicitud, el MTA emite una solicitud P-CONTROL-GIVE primitiva y se convierte en el MTA de recepción.

Finalización de asociación El RTSE utiliza las APDU RT-CLOSE, RT-U-ABORT y RTP-ABORT para finalizar una asociación como se indica a continuación: •

RT-CLOSE Un RTSE puede emitir una solicitud RT-CLOSE cuando es su turno si no hay confirmaciones RT-TRANSFER pendientes. Cuando el RTSE recibe una respuesta RT-CLOSE, el RTSE emite un paquete A-RELEASE para finalizar la asociación.

•

RT-U-ABORT Esta es una cancelación iniciada por el MTA que se desencadena cuando el MTA desea cancelar una asociación. Por ejemplo, un MTA del año de conformidad 1984 puede cancelar una asociación si el otro MTA sobrecarga a dicho MTA empleando características X.400 del año de conformidad 1988.

•

RT-P-ABORT Esta es la cancelación de una asociación iniciada por el proveedor que se desencadena cuando no es posible recuperarse de un error de comunicación. Por ejemplo, la recepción de paquetes de datos en estados no válidos (como por ejemplo, enviar una APDU sin establecer primero una asociación) provoca un RT-P-ABORT.

El MTA de Exchange utiliza un grupo de subprocesos RTS para administrar el nivel RTSE de la pila OSI. Puede controlar el número de subprocesos RTS mediante el siguiente parámetro del Registro.

386

Precaución: El uso del Editor del Registro puede ocasionar problemas graves que quizás requieran reinstalar el sistema operativo. Microsoft no puede garantizar que estos problemas derivados del uso incorrecto del Editor del Registro puedan solucionarse. Utilice el Editor del Registro bajo su propia responsabilidad. respo Ubicación

HKEY_LOCAL_MACHINE\System System\CurrentControlSe t\Services\ MSExchangeMTA\Parameters Parameters

Valor

RTS threads

Tipo

REG_DWORD

Información del valor

0x1

Descripción

Determina el número de subprocesos RTS. El valor predeterminado es 0x1. El valor recomendado es 0x3 si este MTA se comunica con varios MTA, tanto dentro de un grupo de enrutamiento como entre grupos de enrutamiento. Nota: Si la configuración de los subprocesos RTS es demasiado elevada, es posible que los subprocesos RTS sobrecarguen otros subprocesos de la pila OSI y de este modo produzcan una ralentización de la transferencia de mensajes.

Servicio de control de asociaciones El Elemento del servicio de control de asociaciones (ACSE) es un componente de toda entidad de aplicación orientada a la conexión del modelo OSI (por ejemplo, un MTA X.400) que debe establecer una asociación de aplicación a aplicación (de MTA a MTA) para la transferencia de datos a través de una conexión. Una asociación asociación establece un contexto para la comunicación entre los MTA. Por ejemplo, si un proceso del MTA envía datos a otro MTA, el otro MTA debe ser capaz de interpretar los datos y responder correctamente. Los MTA pueden establecer múltiples asociaciones a través de una sola conexión física para transferir varios mensajes a la vez. ACSE ofrece dos tipos de servicios al RTSE:

387

•

Establecimiento de asociación El establecimiento de asociación lo proporciona el servicio A-ASSOCIATE. ASSOCIATE.

•

Finalización de asociación La a finalización de asociación la proporcionan tres servicios: •

A-RELEASE Es el mecanismo normal de liberación utilizado para finalizar una asociación.

•

A-ABORT Es una cancelación no confirmada (abrupta) de una asociación.

•

A-P-ABORT Es una cancel cancelación ación no confirmada (abrupta) de una asociación similar a A-ABORT. ABORT. La diferencia es que A-P-ABORT A ABORT indica al MTA remoto que la asociación ha sido interrumpida por los proveedores de servicios en niveles OSI bajos.

Cada conexión entre dos MTA puede tener hasta hasta diez asociaciones, y como cada asociación es en realidad una conversación, se pueden enviar simultáneamente hasta diez mensajes a través de un solo conector X.400. Dos de las diez asociaciones están reservadas para el envío de mensajes urgentes. Cada MT MTA A aguarda turno en una de las dos asociaciones y nunca libera el turno. Si un MTA remoto intenta establecer más de ocho asociaciones simultáneas para mensajes con prioridad normal, el MTA de Exchange rechaza las asociaciones adicionales y registra un suces suceso o con el Id. de suceso 58 en el registro de sucesos de la aplicación. El siguiente es un ejemplo de este suceso: Event Type:

Warning

Event Source:

MSExchangeMTA

Event Category: X.400 Service Event ID:

58

Date:

04/01/2004

Time:

4:27:34 AM

User:

N/A

Computer:

SERVER01

Description: The /O=TAILSPIN TOYS/OU=FIRST ADMINISTRATIVE GROUP/CN=CONFIGURATION/CN=SERVERS/CN= SERVER01/CN=MICROSOFT MTA entity has reached the per-entity per entity receive association limit of 8, equal to 80 percent of the total 10. [MTA XFER-IN XFER IN 36 34] (12)

Nota: El MTA de Exchange posee un límite total de 2.050 asociaciones a través de todas las conexiones (incluidos los conectores X.400, las conexiones RPC a los MTA LAN y las sesiones XAPI). Este lími límite te está codificado y no puede modificarse.

388

Servicios de presentación y sesión El proveedor de servicios de presentación suministra al RTSE un servicio de transferencia de datos básico para entregar las APDU RT-TRANSFER a los MTA remotos. El proveedor de servicios de presentación empaqueta las APDU del nivel más alto en PPDU (Unidades de datos de protocolo de presentación) y el proveedor de servicios en el nivel de sesión agrega información adicional a los paquetes de datos para crear SPDU (Unidades de datos de protocolo de sesión). La primera información enviada a través del nivel de presentación es una indicación PACTIVITY-START. Si el mensaje es largo, es posible que el MTA tenga que enviar más de un paquete P-DATA. Los paquetes P-DATA no son confirmados por el MTA de recepción, de modo que el MTA de envío también envía indicaciones P-MINOR SYNCHRONIZE entre los paquetes P-DATA. El MTA de recepción confirma los puntos de sincronización secundarios utilizando primitivas de confirmación P-MINOR-SYNCHRONIZE. Sin embargo, los puntos de sincronización secundarios no es necesario que se confirmen inmediatamente. Hay un tamaño de la ventana que establece en todo momento cuántos puntos de sincronización secundarios pueden estar pendientes. Una vez transferido todo el mensaje, se envía una solicitud P-ACTIVITY-END. Cuando el MTA de recepción confirma la P-ACTIVITY-END, el RTSE devuelve una primitiva RT_TRANSFER_CONFIRMED al MTA, y el MTA marca los destinatarios como procesados. Este procedimiento de transferencia está controlado por los siguientes sucesos en el nivel de presentación: 1. Solicitud RT-TRANSFER. 2. Indicación P-ACTIVITY-START, seguida de uno o más paquetes P-DATA en cada caso, excepto en el último, seguido de una indicación P-MINOR-SYNCHRONIZE. 3. Confirmación P-MINOR-SYNCHRONIZE. 4. Indicación P-ACTIVITY-END. 5. Confirmación P-ACTIVITY-END. El RTSE también requiere servicios de sincronización suministrados por el nivel de sesión para protegerse contra la pérdida de datos. Concretamente, el RTSE debe diferenciar entre los datos que fueron entregados con éxito al MTA de recepción y los datos que no llegaron a alcanzar su destino, en cuyo caso, es posible que el RTSE tenga que solicitar la retransmisión de los datos. Para administrar los servicios de presentación y de sesión en la pila OSI, el MTA de Exchange utiliza un grupo de subprocesos de núcleo. Puede controlar el número de subprocesos de núcleo mediante el siguiente parámetro del Registro: Ubicación

HKEY_LOCAL_MACHINE\System\CurrentControlSe t\Services\ MSExchangeMTA\Parameters

389

Valor

Kernel threads

Tipo

REG_DWORD

Información del valor

0x1

Descripción

Determina el número de subprocesos de núcleo del MTA que administra el nivel de presentación y de sesión de la pila OSI. El valor predeterminado es 0x1. Ajuste este valor si este MTA se comunica con otros MTA LAN mediante RPC a través de conexiones de red lentas o con mucha latencia. Valor recomendado: •

0x3 La recomendación estándar.

•

0x8 Si el MTA de Exchange Server 2003 pertenece a un grupo de enrutamiento que contiene más de 15 servidores de Exchange 5.5.

•

0xC (12) Si el MTA de Exchange Server 2003 pertenece a un grupo de enrutamiento que contiene más de 30 servidores de Exchange 5.5.

Pilas de transporte del MTA Para permitir que el MTA de Exchange se comunique con otros MTA X.400 remotos, mediante la pila de transporte OSI tiene que definir algunas direcciones OSI en los niveles de red, transporte, sesión y presentación. Esto se consigue mediante las pilas de transporte del MTA. Puede instalar pilas de transporte en el Administrador del sistema de Exchange si hace clic con el botón secundario del mouse (ratón) en el objeto de configuración X.400, seleccione Nuevo y luego haga clic en Pila de transporte del servicio X.400 para TCP/IP o Pila de transporte del servicio X.400 para X.25. Aparece un cuadro de diálogo en el cual especificará una dirección de red (es decir, un nombre de host, dirección IP o dirección X.121), un Punto de acceso al servicio de transporte (TSAP), un Punto de acceso al servicio de sesión (SSAP) y un Punto de acceso al servicio de presentación (PSAP). Introduzca el TSAP, el SSAP y el PSAP en los cuadros Selector T, Selector S y Selector P, respectivamente. TSAP, SSAP y PSAP son parámetros opcionales de un servidor Exchange, pues el servicio Pila MTA de Microsoft Exchange no comparte la pila OSI con otros MTA. Sin embargo, si el MTA remoto utiliza información de la dirección OSI para conectar el MTA local, deberá definir

390

dichos parámetros para el MTA local. De lo contrario, no podrá establecerse la comunicación. Es posible sobrescribir la información de la dirección OSI mediante el conector X.400. Los parámetros de configuración del conector X.400 se tratan más adelante en esta sección. Nota: Los MTA X.400 que operan según el año de conformidad 1984 sólo admiten los TSAP. Los SSAP y los PSAP no deben especificarse. Para admitir conectores X.400, deberá instalar una de las dos pilas de transporte del MTA siguientes: •

Pila de transporte del TCP/IP TCP/IP es una buena opción para la transferencia de mensajes X.400 a través de Internet y de intranets. La pila de transporte del TCP/IP implementa los servicios de transporte ISO basados en TCP/IP, tal como se define en Solicitudes de comentarios (RFC) 1006. Cuando usted instala y configura la pila de transporte del TCP/IP, crea un objeto de configuración en Active Directory que define los puntos de acceso al servicio y otras opciones utilizadas por el MTA. Los objetos de la pila de transporte se encuent encuentran ran en la partición del directorio de configuración, bajo el objeto de directorio MTA. Puede emplear el siguiente comando LDIFDE para exportar todas las pilas de transporte TCP/IP configuradas en todos los servidores de una organización de Exchange a un archivo ar denominado Stacklist.ldf: ldifde -f c:\Stacklist.ldf -s s localhost -d d "CN=First Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=contoso,DC=com" -p p subtree -r "(objectClass= rFC1006Stack)"

La tabla siguiente describe los atributos im importantes portantes de la pila de transporte del TCP/IP.

391

Atributos importantes del objeto de la pila de transporte del TCP/IP

•

Atributo

Descripción

objectClass

Indica la clase del objeto de directorio como rFC1006Stack.

nAddressType

Indica el tipo de información del atributo nAddress. La información de la dirección puede ser un nombre de host o una dirección IP.

nAddress

Especifica el nombre de host o la dirección IP del MTA local de Exchange.

tSelector

Especifica el TSAP en la información de la dirección OSI de la pila.

sSelector

Especifica el SSAP en la información de la dirección OSI de la pila.

pSelector

Especifica el PSAP en la información de la dirección OSI de la pila.

supportingStackBL

Enumera los nombres completos de los conectores X.400 que utilizan esta pila de transporte.

x400SelectorSyntax

Indica el tipo de información de los atributos tSelector, sSelector y pSelector. La información de la dirección OSI puede ser un valor hexadecimal o decimal.

name

Especifica el nombre del objeto de la pila de transporte tal como se muestra en el Administrador del sistema de Exchange.

Pila de transporte del X.25 Tiene que instalar una tarjeta X.25 EICON en el servidor que ejecuta Exchange Server 2003 y los controladores WAN EICON en Windows Server 2003 para admitir conectores X.400 a través de X.25. La configuración del X.25 es muy compleja y sólo puede llevarse a cabo utilizando las utilidades de configuración que acompañan a la tarjeta X.25 EICON. La dirección X.121 (comparable a un número de teléfono) es la información más importante que debe configurarse. Los datos de la dirección X.121, los datos del usuario que realiza la llamada y los datos de dispositivos que usted especifica en la pila de transporte del X.25 deben coincidir con la configuración de la tarjeta EICON especificada por su proveedor de X.25. Puede emplear el siguiente comando LDIFDE para exportar todas las pilas de transporte X.25 configuradas en todos los servidores de una organización de Exchange de Active

392

Directory a un archivo denominado Stacklist.ldf: ldifde -f c:\Stacklist.ldf -s localhost -d "CN=First Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=contoso,DC=com" -p subtree -r "(objectClass= x25Stack)"

La tabla siguiente describe los atributos importantes de la pila de transporte del X.25. Atributos importantes del objeto de la pila de transporte del X.25 Atributo

Descripción

objectClass

Indica la clase del objeto de directorio como x25Stack.

nAddress

Especifica la dirección local X.121.

x25CallUserDataIncoming

Especifica los datos del usuario que realiza la llamada para el adaptador X.25.

x25FacilitiesDataIncoming

Especifica los datos del usuario del dispositivo para el adaptador X.25.

x25LeasedLinePort

Especifica el número de puerto del adaptador X.25.

tSelector

Especifica el TSAP en la información de la dirección OSI de la pila.

sSelector

Especifica el SSAP en la información de la dirección OSI de la pila.

pSelector

Especifica el PSAP en la información de la dirección OSI de la pila.

supportingStackBL

Enumera los nombres completos de los conectores X.400 que utilizan esta pila de transporte.

x400SelectorSyntax

Indica el tipo de información de los atributos tSelector, sSelector y pSelector. La información de la dirección OSI puede ser un valor hexadecimal o decimal.

name

Especifica el nombre del objeto de la pila de transporte tal como se muestra en el Administrador del sistema de Exchange.

393

Ejemplo de comunicación MTA La figura siguiente ilustra cómo un MTA abre una conexión a través de la RTSI y la pila OSI. Cada transferencia de datos entre los MTA debe descender por un lado de la pila OSI, a través de los niveles de sesión y de transporte y hacer copia de seguridad de la pila en el otro MTA. Cuando un MTA envía un mensaje a través de la pila OSI, el MTA envía una solicitud o una respuesta. Una solicitud llega hasta el otro MTA como una indicación, y una respuesta aparece como una confirmación. Establecimiento de conexión entre dos MTA

Para administrar la comunicación a nivel de transporte en la pila OSI, el MTA de Exchange utiliza subprocesos de transporte. Puede configurar el número de subprocesos de transporte utilizados por el MTA mediante el siguiente parámetro del Registro.

394

Ubicación

HKEY_LOCAL_MACHINE\System System\CurrentControlSe t\Services\ MSExchangeMTA\Parameters Parameters

Valor

Transport threads

Tipo

REG_DWORD

Información del valor

0x1

Descripción

Determina el número de subprocesos de transporte. El valor predeterminado es 0x1. El valor recomendado mendado es 0x3 si este MTA se comunica con MTA remotos a través de varios conectores X.400.

Conectores X.400 En un entorno distribuido pueden producirse conflictos de comunicación si los procesos MTA de comunicación no se coordinan con sumo cuidado. Por ejemplo, el MTA de Exchange es un MTA X.400 de 1988, y al comunicarse con un MTA 1984 tiene que utilizar características compatibles con éste. Nota: Todas las versiones de Exchange incluyen MTA X.400 de 1988. La puerta de enlace de Microsoft Mail para redes de PC a X.400 es un ejemplo de un MTA X.400 de 1984.

Configuración de un conector X.400 Para entender las características que admite un MTA X.400 remoto, debe configurar un conector X.400 a dicho MTA remoto. Primero, asegúrese de haber configurado una pila de transporte del MTA apropiada y después, en el Administrador del sistema de Exchange, expanda el grupo de enrutamiento en el que desee agregar el conector X.400, haga clic con el botón secundario del mouse en Conectores, seleccione Nuevo y luego haga clic en Conector X.400 para TCP/IP o Conector X.400 para X.25,, según la configuración de su servidor. La figura siguiente muestra el cuadro de diálogo diál Propiedades de un conector X.400 de ejemplo.

395

Fichas de propiedades de un conector X.400

Verá un cuadro de diálogo como el que se muestra en la figura 7.12, con las siguientes fichas: •

General Esta ficha se utiliza para definir un nombre, el MTA X.400 remoto y la contraseña, así como la pila de transporte. También puede utilizar esta ficha para especificar si los clientes remotos aceptan MAPI y si permiten referencias a carpetas públicas.

•

Programa Esta ficha se utiliza para establecer el programa de comunicación. Puede configurarse Nunca, Siempre (la comunicación es constante), Horas seleccionadas (intervalos de hasta 15 minutos) e Iniciado de forma remota.

•

Pila Esta ficha se utiliza para especificar información de la dirección necesaria, como por ejemplo, el nombre de host remoto o la dirección IP (o dirección X.121) y los puntos de acceso al servicio para el sistema remoto.

•

Reemplazar Esta ficha se utiliza para reemplazar los atributos X.400 predeterminados del MTA local.

396

•

Espacio de direcciones Esta ficha se utiliza para definir el tipo y el formato de las direcciones de enrutamiento. Los valores de costo están asociados con espacios de direcciones para optimizar el enrutamiento. Además, puede especificar si este conector está disponible nible para toda la organización, o bien se encuentra restringido al grupo de enrutamiento local.

•

Avanzadas Esta ficha se utiliza para especificar formatos de mensaje y procedimientos de mensaje de X.400 al enviar mensajes a un sistema X.400 remoto o a un servidor que ejecuta Exchange.

•

Restricciones de contenido Esta ficha se utiliza para especificar qué mensajes pueden atravesar el conector según la prioridad (Alta, Normal o Baja), el tipo de mensaje (Mensajes del sistema o Mensajes no del sistema) y el tamaño del mensaje (Tamaños permitidos).

•

Detalles Esta ficha se utiliza para especificar una nota administrativa con fines informativos.

•

Grupos de enrutamiento conectados Esta ficha se utiliza para especificar los nombres de los grupos de enr enrutamiento utamiento remotos que se pueden alcanzar a través de este conector X.400.

•

Restricciones de entrega Esta ficha se utiliza para especificar quién puede enviar mensajes mediante este conector. De forma predeterminada, se aceptan mensajes de todos.

Información ción de solicitud de conexión Todas las conexiones X.400 son conexiones seguras. Esto significa que un MTA que intenta contactar con otro MTA debe identificarse en la solicitud de conexión. La información de identificación incluye el nombre y la contraseña para el MTA local y remoto. Si esta información no coincide con la configuración del sistema remoto X.400, se rechaza la solicitud de conexión y no se transfieren los mensajes. Puede especificar el nombre y la contraseña del MTA local desde el contenedor Protocolos del servidor, en Propiedades del objeto X.400. El administrador del MTA remoto debe garantizar que esta información también se especifica de forma correcta en el MTA remoto. Además, para configurar su MTA local correctamente, deberá obtener el n nombre y la contraseña del MTA remoto a partir del administrador remoto. Para especificar el nombre y la contraseña del MTA remoto haga clic en Modificar, en la ficha General. Nota: La contraseña del MTA distingue entre mayúsculas y minúsculas. Si no se escribe e correctamente, no podrán establecerse las conexiones. Especialmente cuando se conecta a una red X.400 pública, es posible que se vea obligado a reemplazar el nombre y la contraseña del MTA local por conector. Los operadores X.400 públicos suelen suministrar la información que usted precise utilizar. Para ajustar ajus la configuración por conector, utilice la ficha Reemplazar.. Desde esta ficha también puede

397

ajustar los diversos parámetros del protocolo X.400, como por ejemplo, Máximo de reintentos de apertura y Máximo de reintentos de transferencia,, descritos anteriormente anteri en esta sección.

Información entrante y saliente de la dirección OSI Para especificar cómo debe contactarse un MTA remoto, configure la información de la dirección OSI en las propiedades del conector de la ficha Pila.. Lo más importante es que usted debe especificar la dirección de red del MTA remoto (dirección IP, nombre de host o dirección X.121) y todos los TSAP, SSAP o PSAP, si éstos se encuentran definidos en el MTA remoto. Todos los valores de la ficha Pila hacen referencia al sistema remoto. Tal T y como se explicó anteriormente, la información de la dirección OSI local se encuentra especificada en la pila de transporte del MTA. Si no ha especificado ninguna información de la dirección OSI en la pila de transporte del MTA, el MTA de Exchange espera espe que los valores de TSAP, SSAP o PSAP sean los mismos que se han definido en la información de la dirección OSI saliente para el MTA remoto. Para obtener más información acerca de las configuraciones de direcciones OSI, consulte el artículo 152934 de Microsoft Microsoft Knowledge Base, "XCON: XCON: X.400 Connector Stack Property Page Behavior Behavior".

Direcciones X.400 Los sistemas X.400 utilizan un complejo esquema de direccionamiento para el enrutamiento y la entrega de mensajes. El tipo de dirección X.400 más importante se conoce como nombre mnemotécnico del autor o del destinatario (O/R), o dirección O/R. Una dirección O/R mnemotécnica identifica un destinatario basado en país, dominio de administración pública p (ADMD) y dominio de administración privada (PRMD). El resto de información de la dirección, como el apellido y el nombre, se requiere para formar una dirección completa. Cada dirección X.400 debe contener información del dominio de administración. Un dominio de administración es principalmente una red de mensajería mantenida por una sola organización. Esta organización puede ser una entidad pública (como una empresa de telecomunicaciones) o privada. Según la recomendación de ITU ITU-T, T, los PRMD controlan controla los mensajes internos, y los mensajes externos destinados a otros PRMD siempre son controlados por ADMD públicos (empresas de telecomunicaciones). En teoría, se supone que los PRMD se comunican entre sí mediante los ADMD. Sin embargo, en la práctica, los PRMD suelen eludir los ADMD de telecomunicaciones para comunicarse directamente entre sí (por ejemplo, mediante TCP/IP a través de Internet), lo cual reduce los costos. Nota: Los campos para país, ADMD y PRMD son obligatorios. Si una red de mensajería no posee un ADMD, especifique un carácter de espacio individual en la parte ADMD de sus direcciones X.400. Un espacio en la parte ADMD es sinónimo de “cualquier ADMD”.

398

La tabla siguiente enumera los campos que pueden utilizarse en un nombre O/R. Atributos O/R en una dirección X.400 Etiqueta

Abreviatura

Tipo de atributo

Ejemplo

C

País

País

C=US;

A

ADMD

Nombre ADMD

A=MCI;

P

PRMD

Nombre PRMD

P=TAILSPINTOYS;

S

Apellido

Apellido

S=BREMER;

G

Nombre

Nombre

G=TED;

I

Iniciales

Iniciales

I=TB;

Q

Generación

Calificador de generación

Q=SR;

CN

Nombre común

Common name

CN=TED BREMBER;

X.121

X.121

Dirección X.121

X.121=49309872210 2

N-ID

N-ID N

Id. del agente de usuario

N N-ID=208973240

T-TY

T-TY T

Tipo de terminal

T T-TY=TTY;

T-ID

T-ID T

Identificador de terminal

T T-ID=309;

O

Organización

Organización

O=EXCHANGE;

OU1

Org.Unit.1

Unidad organizativa 1 OU1=IT;

OU2

Org.Unit.2

Unidad organizativa 2 OU2=USA;

OU3

Org.Unit.3

Unidad organizativa 3 OU3=SEA;

OU4

Org.Unit.4

Unidad organizativa 4 OU4=DOWNTOWN;

DDA

DDA

Atributo definido por el dominio (DDA:tipo=valor del atributo)

DDA:SMTP=Ted@tai lspintoys.com

Nota: A excepción del campo DDA, los nombres O/R no distinguen mayúsculas de minúsculas.

399

Espacios de direcciones X.400 Cada conector X.400 debe tener por lo menos un espacio de direcciones asociado que usted puede especificar en la ficha Espacio de direcciones. El motor de enrutamiento utiliza esta información para determinar posibles conectores para un mensaje en concreto, comparando las direcciones del destinatario con la información del espacio de direcciones disponible. Al conectar con un sistema X.400 remoto, usted suele configurar el espació de direcciones X.400. Sin embargo, también puede asociar un conector X.400 con otros tipos de dirección, por ejemplo, especificando información de dirección SMTP, tal como muestra la figura siguiente. Entonces, un mensaje que se envía a un destinatario SMTP coincidente (como [email protected]) se enruta a través del conector X.400. El MTA de Exchange convierte la información de dirección a una dirección X.400 utilizando atributos definidos del dominio (DDA), enumerados en la tabla anterior. Espacios de direcciones para un conector X.400

Al especificar espacios de direcciones que no son X.400, debe asegurarse de que el MTA de recepción puede tratar la información de la dirección que no es X.400. Por ejemplo, si el

400

sistema X.400 de destino no puede tratar información DDA SMTP, se desaconseja asignar un espacio de direcciones SMTP SMTP a un conector X.400 que señale este sistema. Los mensajes no se transfieren correctamente al sistema remoto. Algunos sistemas X.400 esperan información de dirección SMTP encapsulada como la definida en la RFC 2156 “MIXER (Mime Internet X.400 Enhanced Relay)”, Relay)”, que describe un método para asignar formatos de mensajes e información de dirección entre RFC 822/MIME y X.400. La parte de dirección DDA correspondiente presenta el siguiente aspecto: DDA:rfc DDA:[email protected]. Exchange Server 2003 utiliza DDA A SMTP en lugar de DDA RFC822 y no admite MIXER. Nota: Exchange Server 5.5 admite la funcionalidad MIXER. Si precisa esta característica, deberá mantener un servidor cabeza de puente de Exchange 5.5 en su organización.

Año de conformidad y partes del cu cuerpo erpo Mediante la ficha Avanzadas puede especificar características de X.400 que se habilitarán al conectar la organización a un sistema X.400 remoto. Dos opciones importantes son el año de conformidad y las partes del cuerpo de X.400. El año de conformidad del MTA, por ejemplo, debe coincidir con el año de conformidad del sistema externo, pues existen diferencias importantes entre los estándares X.400 de 1984 y 1988. De lo contrario, el MTA local sobrecarga el MTA remoto y se producen problemas de comunicación. comunicación.

401

La ficha Avanzadas de un conector X.400

Mediante la lista Parte del cuerpo X.400 para el texto del mensaje, también puede seleccionar una parte del cuerpo para el texto del mensaje tal como aparecerá en el cuerpo del mensaje. El cuerpo de un mensaje puede estar formado por varias partes, lo cual permite adjuntar datos en mensajes de correo. La tabla siguiente enumera las partes del cuerpo admitidas por Exchange Server 2003. Partes del cuerpo de mensajes interpersonales de X.400 Número de la parte del cuerpo

Parte del cuerpo

0

Texto IA5

1

Télex (ITA2 de 5 bits)

2

Voz

3

Facsímil G3

402

Número de la parte del cuerpo

Parte del cuerpo

4

Formato de intercambio de textos (TIFO)

5

Télex (T.61)

6

Videotexto

7

Definición nacional

8

Cifrado

9

Mensaje IP reenviado

10

Documento sencillo sin formato (SFD)

11

Formato de intercambio de textos 1 (TIF1)

12

Cadena de octetos

13

Texto ISO6937

14

Definida bilateralmente (binaria)

15

Transferencia de archivo binaria (definida por primera vez en 1988)

Al conectarse a un MTA remoto de Exchange en la misma organización, puede seleccionar la casilla de verificación Permitir contenido de Exchange. El formato nativo de Exchange no se ajusta al X.400, pero esto no representa ningún problema entre los MTA de Exchange. Sin embargo, debe desactivar esta casilla de verificación cuando se comunique con un MTA de Exchange externo a la organización local de Exchange, porque el contenido nativo de Exchange incluye información de dirección legacyExchangeDN, la cual sólo tiene validez en la organización local. Los destinatarios especificados mediante direcciones legacyExchangeDN no existen en el directorio del MTA externo de Exchange. Para enviar mensajes en el formato de Exchange a los usuarios de Exchange de organizaciones externas, seleccione la casilla de verificación El cliente remoto admite MAPI de la ficha General del conector. Cuando selecciona esta casilla de verificación, el MTA de Exchange encapsula los mensajes mediante Formato de encapsulación neutro para el transporte (TNEF). El MTA convierte el mensaje en una parte de texto sin formato y un dato adjunto en el TNEF heredado. Para conocer más detalles acerca de TNEF, consulte Arquitectura de transporte SMTP.

Detección de bucles de mensaje X.400 define un concepto de límites organizativos que influye en el modo en que los MTA tratan la información de seguimiento agregada al sobre de transferencia de mensajes P1 para la detección de bucles. Cada MTA miembro de la organización agrega información de seguimiento para indicar que el MTA ya ha transferido el mensaje. Si un mensaje alcanza

403

dos veces el mismo MTA, es posible que el MTA determine que el mensaje esté formando un bucle y lo descarte con un informe de no entrega (NDR). Información de seguimiento en un sobre de transferencia de mensajes P1

Un MTA puede agregar al sobre de transferencia de mensajes P1 los dos tipos de información de seguimiento siguientes: •

Información de seguimiento externa La información de seguimiento externa identifica cada dominio X.400 transferido por el mensaje. El dominio X.400 es definido por un identificador global de dominio que consta de los campos de dirección país, ADMD y PRMD del X.400. El MTA agrega información de seguimiento externa a un mensaje si éste alcanza la organización; por ejemplo, si el almacén de Exchange envía un mensaje al MTA, o si el MTA recibe un mensaje de un MTA de otra organización. Si un MTA recibe un mensaje de una organización externa y encuentra su propio identificador global de dominio local en la información de seguimiento externa, se detecta un bucle de mensaje entre las organizaciones. La presencia del identificador global de dominio local indica que el dominio X.400 local ya ha tratado el mensaje y lo ha enrutado al otro dominio. Si el MTA acepta de nuevo el mensaje, éste vuelve a enrutarse al otro dominio, donde a su vez será enrutado de nuevo al dominio local. Esto constituye un bucle de mensaje, y el MTA debe descartar el mensaje con un NDR.

404

Nota: El MTA de Exchange no quita la información de seguimiento externa de los mensajes. •

Información de seguimiento interna La información de seguimiento interna identifica todos los MTA que transfirieron el mensaje dentro de un límite organizativo. La información de seguimiento interna consiste en el nombre del MTA e información sobre acciones de enrutamiento, como por ejem ejemplo, plo, si el mensaje fue retransmitido o redirección, o si provocó una expansión de la lista de distribución (DL). Si un mensaje entra dos veces en el mismo MTA, es posible que sea descartado con un NDR. Para detectar los bucles de mensaje debidos a la información información de seguimiento interna, el MTA sigue los pasos siguientes: a. El MTA lee la parte TraceInformation del sobre de transferencia de mensajes P1 para determinar si el MTA trató anteriormente el mensaje. b. El MTA determina si el identificador global de dominio coincide con el identificador global de dominio local. De ser así, el MTA compara el nombre del MTA local con los nombres de la información de seguimiento interna. c.

Si el nombre del MTA local no aparece, no se detecta ningún bucle de mensaje. El MTA detiene la comprobación en este momento.

d. Si el nombre del MTA local aparece, el MTA comprueba la información de las acciones de enrutamiento en la información de seguimiento interna. Si no aparece ninguna acción de enrutamiento, el mensaje no se transfirió a través del dominio local y no se detecta ningún bucle de mensaje. El MTA detiene la comprobación en este momento. e. Si la acción de enrutamiento indica que el mensaje fue retransmitido, es posible que exista un bucle de mensaje. En ese caso, el MTA comprueba el otro campo de acciones para determinar si el mensaje se redireccionó o si se expandió la lista de distribución. Si se da cualquiera de estas condiciones, es posible que el mensaje vuelva a un MTA de forma legítima, de forma que no sea descartado con un NDR. El escenario de reproducción remota es otro de los escenarios donde es posible que un mensaje vuelva a un MTA de forma legítima. Este escenario se explica en la sección "Reproducción de archivos DAT" de MTA de Exchange en la arquitectura de Exchange Server 2003. f.

Sin embargo, si el mensaje fue retransmitido y no se especifican otras acciones, el MTA lo marca como un bucle y lo coloca con un NDR para informar al remitente del mensaje que éste no llegó a su destino final.

El MTA agrega información de seguimiento interna al sobre de transferencia de mensajes P1 de todos los mensajes que procesa. Pero cuando el MTA de detecta tecta que el mensaje se transfirió a un dominio X.400 externo, debe quitar toda la información de seguimiento interna del sobre del mensaje, pues entre los dominios X.400, la información de seguimiento externa se utiliza para la detección de bucles. Para determinar determinar cuando hay que quitar la información

405

de seguimiento interna, el MTA compara su identificador global de dominio local con el identificador global de dominio del MTA de destino. Para determinar su identificador global de dominio local, el MTA de Exchange Exchange lee la directiva de destinatario predeterminada. Concretamente, el MTA de Exchange lee la información de país, del ADMD y del PRMD del espacio de direcciones X.400 primario definido en la directiva de destinatario predeterminada para crear el identificador identificador global de dominio local. Puede configurar el identificador global de dominio predeterminado para el MTA de Exchange en el Administrador del sistema de Exchange. Bajo Directivas de destinatarios, destinatarios muestre las propiedades de Directiva predeterminada y edite la entrada de la dirección de correo electrónico del X.400. De forma predeterminada, el identificador global de dominio es c=US;a= ;p=. Nota: El MTA de Exchange determina el identif identificador icador global de dominio local cuando el MTA se está inicializando, es decir, cuando usted inicia el servicio Pila MTA de Microsoft Exchange. Para determinar el identificador global de domino del MTA remoto, el MTA local lee la información de país, del ADM ADMD D y del PRMD del espacio de direcciones asignado al conector X.400 en la ficha Espacio de direcciones, direcciones, pero puede sobrescribir esta información en la ficha Avanzadas si hace clic en Identificador de dominio global.. Haga clic en Identificador de dominio global glo especificado y defina el identificador global de dominio según el país, el ADMD y el PRMD. Bajo ADMD (a), seleccione Cualquiera si desea permitir que el conector X.400 utilice cualquier ADMD, lo cual corresponde a un campo ADMD vacío. Si selecciona Específico ecífico, deberá escribir un valor para el ADMD. Nota: Si en la ficha Avanzadas elige 1984 como conformidad para el conector X.400, deberá configurar de forma explícita el identificador global de dominio.

Objetos del conector X.400 en Active Directory Cuando ndo instala y configura un conector X.400, usted crea un objeto de configuración en Active Directory que define las características y los parámetros del protocolo X.400 que debe utilizar el MTA. Los objetos del conector se encuentran en la partición de directorio dir de configuración, bajo el grupo de enrutamiento del conector, en el contenedor Conexiones. El motor de enrutamiento lee esta información para inicializar la tabla de estado de vínculos, tal como se han tratado en Arquitectura de enrutamiento de mensajes Puede utilizar el siguiente comando LDIFDE para exportar todos los conectores X.400 de una organización de Exchange denominada Primera organización organización a un archivo llamado X400Connectors.ldf: ldifde -f c:\X400Connectors.ldf -s localhost -dd "CN=First Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=contoso,DC=com" -p subtree -r r "(objectClass=x400Link)"

La tabla siguiente describe los atributos importantes de los objetos del conector X.400.

406

Atributos importantes de los objetos del conector X.400 Atributo

Descripción

activationSchedule

Especifica el programa de activación para este conector X.400.

activationStyle

Especifica el estilo de activación para este conector X.400. (0=No programar nunca, 1=Utilizar programa)

aDMD

Especifica la parte ADMD de un identificador global de dominio definido manualmente.

associationLifetime

Especifica el tiempo en segundos durante el cual el sistema mantiene abierta una asociación a un MTA X.400 remoto una vez enviado un mensaje.

c

Especifica la parte correspondiente al país de un identificador global de dominio definido manualmente.

delivEITs

Especifica los tipos de mensaje que se pueden entregar en formato codificado según las restricciones de contenido configuradas para este conector.

delivExtContTypes

Especifica los identificadores de objeto para los tipos de contenido admitidos por este conector.

gatewayLocalDesig

Especifica el nombre del MTA X.400 remoto que utiliza el MTA al establecer una conexión.

homeMTA

Especifica el nombre completo del MTA que utiliza este conector X.400.

lineWrap

Especifica el número de caracteres del texto del mensaje a partir de los cuales el MTA inserta un salto de línea.

localInitialTurn

Especifica si el MTA local o el MTA remoto posee el turno inicial en las asociaciones nuevas.

msExchConnectorType

Designa este objeto de conector como un conector X.400.

407

Atributo

Descripción

msExchEncryptedPassword

Especifica la contraseña de reemplazo reempl para el MTA local. Nota: La contraseña se encuentra protegida en Active Directory, pero los MTA X.400 transmiten los nombres y las contraseñas MTA en texto no cifrado.

msExchEncryptedPassword2

Especifica de forma cifrada la contraseña que el MTA local debe utilizar al establecer una conexión al MTA X.400 remoto. Nota: La contraseña se encuentra protegida en Active Directory, pero los MTA X.400 transmiten los nombres y las contraseñas MTA en texto no cifrado.

msExchNoPFConnection

Especifica si las as referencias a carpetas públicas están autorizadas a través de este conector X.400. Esta configuración sólo es relevante si este conector se utiliza para conectarse a otro grupo de enrutamiento de la misma organización de Exchange.

mTALocalDesig

Especifica ica el nombre de reemplazo para el MTA local.

nAddress

Especifica el nombre de host o la dirección IP del MTA local de Exchange.

nAddressType

Indica el tipo de información del atributo nAddress. La información de la dirección puede ser un nombre de host o una dirección IP.

name

Especifica el nombre del objeto de la pila de transporte tal como se muestra en el Administrador del sistema de Exchange.

408

Atributo

Descripción

numOfOpenRetries

Especifica el número máximo de veces que el MTA de Exchange intenta abrir una conexión antes de enviar un informe de no entrega (NDR).

numOfTransferRetries

Especifica el número máximo de veces que el MTA de Exchange intenta transferir un mensaje a través de una conexión abierta.

objectClass

Indica la clase del objeto de directorio como x400Link. De esta clase derivan las clases de objeto siguientes: •

rFC1006X400Link conectores TCP/IP X.400

•

x25X400Link conectores X.25 X.400

openRetryInterval

Especifica el número de segundos que el sistema esperará después de un error antes de intentar volver a abrir una conexión.

pRMD

Especifica la parte PRMD de un identificador global de dominio definido manualmente.

pSelector

Especifica el PSAP en la información de la dirección OSI de la pila.

routingList

Especifica los espacios de direcciones configurados para este conector X.400.

rTSCheckpointSize

Especifica el volumen de datos (en kilobytes) transferidos antes de insertar un punto de control. Si se produce un error y hay que volver a enviar el mensaje, el proceso se reinicia desde el punto de control más reciente. El valor cero indica que no se han insertado puntos de control.

rTSRecoveryTimeout

Especifica el tiempo después de cortarse la conexión que el MTA espera para volverse a conectar antes de borrar la información (con sus puntos de control) y reiniciar la transferencia desde el principio.

409

Atributo

Descripción

rTSWindowSize

Especifica el número de puntos de control que se pueden dejar pasar sin confirmar antes de que se suspenda la transferencia de datos. El tamaño de la ventana es irrelevante si el tamaño del punto de control es cero.

sessionDisconnectTimer

Especifica el tiempo en segundos que esperará el MTA de Exchange antes de desconectar una conexión después de que se cancelen todas las asociaciones que pasan por esta conexión.

sSelector

Especifica el SSAP en la información de la dirección OSI de la pila.

supportedApplicationContext

Especifica los identificadores de objeto de los contextos de aplicación admitidos por una aplicación OSI, como por ejemplo, el MTA de Exchange.

supportingStack

Especifica el nombre completo de la pila de transporte del MTA que utiliza el MTA para comunicarse a través de este conector.

tempAssocThreshold

Especifica el número máximo de mensajes en cola que puede enviar el mensaje a un sistema remoto. Cuando se excede, el MTA abre otra asociación.

transferRetryInterval

Especifica el número de segundos que el sistema espera después de que fracase una transferencia de mensajes para volver a enviar un mensaje a través de una conexión abierta.

transferTimeoutNonUrgent

Especifica el tiempo en segundos por kilobyte que el sistema espera antes de enviar un informe de no entrega (NDR) para un mensaje no urgente.

transferTimeoutNormal

Especifica el tiempo en segundos por kilobyte que el sistema espera antes de enviar un informe de no entrega (NDR) para un mensaje normal.

410

Atributo

Descripción

transferTimeoutUrgent

Especifica el tiempo en segundos por kilobyte que el sistema espera antes de enviar un informe de no entrega (NDR) para un mensaje urgente.

translationTableUsed

Especifica la tabla de conversión utilizada por el MTA para codificar el texto del mensaje.

transportExpeditedData

Especifica si los datos inmediatos se admiten a través del conector X.400. Los datos inmediatos omiten los procedimientos de control de flujo y proporcionan un medio para acelerar la entrega de datos urgentes, como por ejemplo, una solicitud de desconexión abrupta. Cuando un MTA solicita el servicio de datos inmediatos, el otro MTA debe aceptar su uso en la conexión, de lo contrario, la característica no estará disponible.

tSelector

Especifica el TSAP en la información de la dirección OSI de la pila.

twoWayAlternateFacility

Especifica si la asociación del MTA es unidireccional o bidireccional alternativa.

x400SelectorSyntax

Especifica la sintaxis de los selectores P, S y T. (0 o indefinido=hexadecimal, 1=texto)

Ejecución de varios conectores X.400 El número máximo de conectores X.400 que puede instalar en un sólo servidor que ejecuta Exchange Server varía en función de los límites prácticos de cada servidor, como por ejemplo, el hardware o el ancho de banda de la red. Sin embargo, Exchange 2003 no está optimizado de forma predeterminada para muchos X.400, pues el servidor admite un máximo de 20 conexiones simultáneas por cada tipo de conector (a saber, TCP/IP y X.25). En diez asociaciones por conector, esto equivale a dos conectores X.400 a través de TCP/IP. Si configura 30 o más conectores X.400 TCP/IP en un servidor cabeza de puente y todas las asociaciones están en uso, es posible que aparezca el Id. de suceso 9156 en el registro de sucesos de la aplicación: Event ID: 9156 Source: MSExchangeMTA

411

Type: Warning Category: Resource Description: A resource limit has been reached while attempting to open an association. There are no free control blocks available for network type 1. The configured count is 70. [BASE IL MAIN BASE 1 282] (10)

Para admitir más de dos conectores X.400 en un servidor cabeza de puente, deberá aumentar el número de bloques de control mediante el siguiente parámetro del Registro. Ubicación

HKEY_LOCAL_MACHINE\System\CurrentControlSe t\Services\ MSExchangeMTA\Parameters

Valores

TCP/IP control blocks TP4 control blocks Eicon X.25 connections

Tipo

REG_DWORD

Información del valor

0x14 (20)

Descripción

Determina el número máximo de búfers disponibles para las conexiones X.400. Es mejor proporcionar diez bloques de control para cada conector X.400 más un bloque de control para una conexión entrante si se excede el número máximo de asociaciones. Por ejemplo, si tiene 30 conectores X.400 TCP/IP, establezca los bloques de control TCP/IP a 0x12D (301) para obtener el máximo rendimiento.

Para tratar la carga de comunicación en el nivel TCP/IP, es posible que también deba aumentar el número de subprocesos TCP/IP que utiliza el MTA mediante el siguiente parámetro del Registro. Ubicación

HKEY_LOCAL_MACHINE\System\CurrentControlSe t\Services\ MSExchangeMTA\Parameters

Valor

TCP/IP threads

Tipo

REG_DWORD

Información del valor

0x2

412

Descripción

Determina el número de subprocesos del MTA que tratan conexiones RFC1006. El valor predeterminado es 0x2. Este número se multiplica por dos para los dos subtipos de subprocesos RFC1006 (notificación de controlador y asincrónica).

El número máximo real de bloques de control que puede emplear el MTA de Exchange es 1.250, pero este número se ha obtenido de un grupo de bloques de control para las pilas de transporte de TCP/IP, TP4 y X.25. Los valores del Registro indicados corresponden a los bloques de control TCP/IP, TP4 y X.25, respectivamente. De forma predeterminada, todos estos valores se establecen en el decimal 20, de modo que el valor de los bloques de control TCP/IP puede aumentarse hasta el decimal 1.210 sin crear ningún problema. Esto permite un máximo de 121 conectores X.400 TCP/IP en un sólo servidor, cada uno de los cuales utiliza el número máximo de asociaciones permitidas. Esta cifra es teórica. Es posible que las capacidades del servidor cabeza de puente limiten el número real de conectores X.400. Es improbable que cada conector X.400 procese el correo suficiente como para precisar el número de asociaciones máximo para cada conector. Además, si la pila de transporte X.25 no está en uso, puede reducir el parámetro de conexiones X.25 Eicon al valor cero, incrementando así los bloques de control disponibles para la pila TCP/IP a 20. Sin embargo, Exchange Server 2003 no admite los conectores X.400 basados en TP4 y, al reducir los bloques de control TP4, no se asignan bloques de control adicionales para TCP/IP. Si establece un número máximo de bloques de control agrupados demasiado alto, el servicio Pila MTA de Microsoft Exchange no puede iniciarse y se registra el siguiente suceso en el registro de sucesos de la aplicación: Event ID: 4300 Source: MSExchangeMTA Type: ERROR Category: Configuration

Unable to initialize due to a bad configuration. Contact Microsoft Technical Support. Error code= [1 POP4 MAIN BASE 1] (16)

Conexión de grupos de enrutamiento mediante conectores X.400 Se recomienda utilizar conectores X.400 entre grupos de enrutamiento, en especial a través de vínculos de red no confiables. El X.400 resulta ventajoso porque admite la recuperación sin errores en dos fases de las asociaciones de transferencia. En numerosos casos, la

413

transferencia de mensajes se puede reanudar desde el punto en que se interrumpió. Asimismo el conector X.400 no infla el tamaño del mensaje porque transfiere el contenido del mensaje en el formato nativo de Exchange, sin realizar conversiones. Por el contrario, los conectores para grupo de enrutamiento y los conectores SMTP deben convertir los mensajes a formato RFC 822 y MIME (Extensiones multipropósito de correo Internet). Esto ocasiona un aumento de tamaño del 30%. Para especificar grupos de enrutamiento remotos para un conector X.400 en las propiedades de conector, utilice la ficha Grupos de enrutamiento conectados.

Equilibrio de carga entre grupos de enrutamiento Los MTA locales y remotos de un conector X.400 son los únicos servidores cabeza de puente que puede utilizar el conector en cada grupo de enrutamiento. Si desea utilizar varios servidores cabeza de puente, deberá configurar conectores X.400 adicionales para señalar diferentes MTA remotos en el grupo de enrutamiento de destino. Un sólo servidor puede admitir varios conectores X.400, cada uno de los cuales utilizará la misma u otra pila de transporte del MTA. Sin embargo, también puede configurar varios conectores X.400 en servidores múltiples tal como se ilustra en la figura siguiente. Varios servidores cabeza de puente y conectores X.400 entre dos grupos de enrutamiento

Tenga en cuenta, sin embargo, que Exchange Server 2003 no realiza un verdadero equilibrio de carga mediante varias instancias de conector. Tal y como se explica en Arquitectura de enrutamiento de mensajes, el motor de cola avanzada llama una vez al motor de enrutamiento para determinar un enrutamiento de mensaje, almacena en caché dicha información y, a continuación, transfiere todos los mensajes del mismo tipo a través del

414

mismo conector. Los conectores adicionales sólo se utilizan si falla el primer conector. No obstante, es posible que un un segundo servidor seleccione el segundo conector y que de este modo equilibre la carga hasta cierto punto. Nota: Debido a que el motor de enrutamiento no distingue los conectores locales de los remotos, eso permite que, en un servidor cabeza de puente del grupo de enrutamiento, el motor de cola avanzada transfiera todos los mensajes para el grupo de enrutamiento de destino a otro servidor cabeza de puente del mismo grupo de enrutamiento local, aunque dicho servidor local sea también un servidor cabeza de d puente que pueda transferir el mensaje.

Enrutamiento de mensajes mediante los MTA de Exchange En una organización de Exchange en la que los mensajes se transfieren a través de los MTA de Exchange, el motor de enrutamiento realiza dos veces el enrutamiento enrutamiento de mensajes. El primer suceso de enrutamiento se produce en el motor de cola avanzada. El motor de enrutamiento informa al motor de cola avanzada de que un mensaje debe ser enrutado por el MTA de Exchange a través de un controlador de conexiones y el motor motor de cola avanzada coloca el mensaje en la cola de mensajes para el MTA. El controlador del almacén de Exchange coloca el mensaje en la carpeta MTS-IN MTS IN del MTA, en el almacén de Exchange. Luego el almacén de Exchange pasa el mensaje al MTA mediante una puerta pue de enlace XAPI SMTP. El siguiente ejemplo de suceso muestra un mensaje que se pasa al MTA tal y como se acaba de describir. La información relevante aparece en negrita. Event ID: 272 Source: MSExchangeMTA Type: Information Category: X.400 Service Object 0600002D received from entity /DC=COM/DC=CONTOSO/CN=CONFIGURATION/CN=SERVICES/CN=MICROSOFT EXCHANGE/CN=FIRST ORGANIZATION/CN=CONNECTIONS/CN=

, object is a Normal priority Message, the MTS

identifier is C=US;A= ;P=First Organizati;L=SERVER01-040503155933Z-4, Organizati;L=SERVER01 4, and content length is 1719. The number of objects sent so far = 1. External trace information (first 100 bytes) = 3080638061801302555300006280130120000013104669727374204F7267616E697A61746900003180800D 3034303530333136303234315A82010083020600 3034303530333136303234315A8201008302060000000000. (10)

Puerta de enlace XAPI SMTP Desde el punto de vista del MTA de Exchange, el servicio SMTP funciona de forma similar a un conector de MAPI, como el Conector para Lotus Notes o el Conector para Novell

415

GroupWise. El MTA de Exchange obtiene mensajes de la puerta de enlace XAPI SMTP a través de la carpeta MTS-IN de la puerta de enlace, y enruta los mensajes a dicha puerta a través de la carpeta MTS-OUT de la puerta de enlace. Estas carpetas de cola de mensajes existen en el buzón SMTP. El nombre del buzón SMTP es SMTP (<nombre servidor> {}). En el suceso anterior, el nombre de buzón es SMTP (SERVER01-{43D5C017-4A4B-4AFD-85AF-06EAB90057AA}). En Active Directory existe el objeto de conector correspondiente a la puerta de enlace XAPI, en el contenedor Conexiones, justo en el objeto de organización de Exchange. Este contenedor no se muestra en el Administrador del sistema de Exchange, pero puede verlo a través de ADSI Edit, o bien exportar su contenido mediante LDIFDE. Por ejemplo, puede utilizar la siguiente línea de comandos para exportar todos los objetos de la puerta de enlace XAPI SMTP a un archivo denominado SMTPXAPI.ldf: ldifde -f c:\SMTPXAPI.ldf -s localhost -d "CN=Connections,CN=First Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=contoso,DC=com" -r "(objectClass=mailGateway)".

La tabla siguiente describe los atributos importantes del objeto de la puerta de enlace XAPI SMTP. Atributos importantes de la puerta de enlace XAPI SMTP Atributo

Descripción

objectClass

Identifica el objeto de directorio como un objeto mailGateway y msExchConnector.

Common name

Representa el nombre del objeto de conector en Active Directory respecto a su contenedor primario.

computerName

Señala el servidor cabeza de puente que está ejecutando el servicio SMTP. Este atributo debe coincidir exactamente con el nombre del sistema básico de entrada/salida de red (NetBIOS) para el servidor cabeza de puente; de lo contrario, el complemento Visor de cola del Administrador del sistema de Exchange no es capaz de mostrar las colas de mensajes.

deliveryMechanism

Identifica el mecanismo de entrega empleado por Exchange Server 2003 para pasar mensajes a la puerta de enlace XAPI.

distinguishedName

Representa el nombre completo del objeto del conector en Active Directory.

416

Atributo

Descripción

homeMDB

Identifica el almacén de buzones privado que contiene el buzón del conector.

homeMTA

Identifica el MTA de Exchange responsable del enrutamiento de mensajes a la puerta de enlace XAPI.

legacyExchangeDN

Representa el nombre completo del objeto del conector en el formato de directorios anterior de Exchange Server 5.5. Este atributo debe definirse en el objeto del conector para que el complemento Visor de cola funcione.

delivExtContTypes

Enumera los identificadores de objeto para los tipos de contenido admitidos por este conector.

Name

Representa el nombre del objeto del conector.

canPreserveDNs

Indica si el objeto de conector puede tratar nombres completos en la información de los destinatarios.

Transferencia de mensajes del MTA de Exchange La siguiente figura ilustra el modo en que el servicio SMTP y el MTA de Exchange interactúan.

417

Transferencia de mensajes a través del MTA de Exchange

Después de recibir un mensaje de la puerta de enlace XAPI SMTP, el MTA debe determinar un conector adecuado para transferir el mensaje al siguiente salto. En Exchange 200 Server y Exchange Server 2003, el MTA ya no realiza el enrutamiento de mensajes real, sino que

418

contacta con el motor de enrutamiento a través de MTARoute.dll, el cual enruta el mensaje. No obstante, es posible que el MTA cambie los nombres de destinatario O/R a una forma que pueda pasar al motor de enrutamiento. El MTA no llama al motor de enrutamiento para los mensajes que recibe de los MTA LAN, los MTA X.400 o los conectores MAPI, sino que los pasa directamente a la carpeta MTSOUT de la puerta de enlace XAPI SMTP. Luego el motor de cola avanzada trata a su vez los mensajes y llama al motor de enrutamiento si hay un mensaje que no está dirigido a destinatarios locales. De hecho, es posible que un mensaje sea transferido de vuelta al MTA de Exchange mediante el almacén de Exchange y la puerta de enlace XAPI SMTP si debe ser transferido a otro MTA LAN, MTA X.400 u otro sistema de mensajería que no sea de Exchange. El servicio SMTP coloca una marca en todos los mensajes que transfiere al MTA de Exchange para indicar que el MTA debe llamar al motor de enrutamiento. Para obtener más información acerca del proceso de enrutamiento de los mensajes, consulte Arquitectura de enrutamiento de mensajes. Si el motor de enrutamiento puede determinar un siguiente salto para un mensaje, el MTA determina si se ha alcanzado el siguiente salto a través del servicio SMTP local. Es posible, por ejemplo, que un conector X.400 y un conector para grupo de enrutamiento señalen el mismo grupo de enrutamiento. Si esto sucede, es posible que el motor de cola avanzada pase el mensaje al MTA para que lo transfiera mediante el conector X.400, y luego el MTA podría pasar el mensaje de vuelta al servicio SMTP para transferirlo a través del conector para grupo de enrutamiento, y así sucesivamente. Para evitar esta situación, el MTA llama al motor de enrutamiento por segunda vez si el enrutamiento inicial sugiere que el MTA debería devolver el mensaje al servicio SMTP. El MTA pasa la dirección proxy X.400 del destinatario en la llamada de enrutamiento inicial y el legacyExchangeDN en la segunda llamada de enrutamiento, esperando así que se siga un enrutamiento diferente al empleado a través del servicio SMTP.

Información de estado de vínculos y Redireccionamiento de mensajes Si el motor de enrutamiento puede determinar un siguiente salto para un mensaje, devuelve el nombre de objeto de enrutamiento de un conector o MTA al MTA. El MTA convierte este nombre de objeto de enrutamiento en un nombre completo para determinar el objeto de directorio del conector o MTA que debe utilizar el MTA para la transferencia de mensajes a Active Directory. El objeto de directorio define el mecanismo de entrega y los parámetros de comunicación. Si el motor de enrutamiento no puede determinar un siguiente salto debido a un error del vínculo temporal, dicho motor marca el mensaje para informar al MTA de que tiene que redireccionar el mensaje la próxima vez que cambie la información de estado de vínculos. Tal y como se explica en Arquitectura de enrutamiento de mensajes, la información de estado de vínculos cambia cuando usted cambia la configuración del conector de su organización, cuando el motor de cola avanzada o el MTA marca un conector como activo o

419

desconectado. El algoritmo de estado de vínculos garantiza que las actualizaciones de la información de estado de vínculos se propaguen a todos los servidores de la organización que ejecutan Exchange Server S 2003. Cuando el motor de enrutamiento del servidor local descubre que la información de estado de vínculos ha cambiado, llama a la función RoutingReset() del MTA. Entonces, el MTA llama al motor de enrutamiento de todos los mensajes que están enrutados enrutad pero aún no se han enviado, con el fin de llevar a cabo el redireccionamiento. Mientras el motor de enrutamiento recibe la información actualizada de estado de vínculos de su maestro del grupo de enrutamiento, las llamadas de enrutamiento producen un error error temporal, y el MTA coloca los mensajes en una cola de mensajes pendientes de redireccionar. El redireccionamiento se realiza correctamente cuando la información de estado de vínculos se sincroniza en todo el grupo de enrutamiento. Nota: recuentes de la información de estado de vínculos pueden provocar Los cambios frecuentes problemas de transferencia de mensajes en el MTA de Exchange. Por ejemplo, es posible que los mensajes sean descartados con informes de no entrega (NDR) con la indicación de que no se reconocen reconocen los nombres O/R. En un entorno con conexiones de red no confiables, es posible que tenga que deshabilitar la propagación de la información de estado de vínculos, tal como se describe en Arquitectura de enrutamiento de mensajes. mensajes

Intercambio de información de estado de vínculos entre los grupos de enrutamiento En una organización de Exchange con conectores para grupo de enrutamiento, la información de estado stado de vínculos se intercambia entre los grupos de enrutamiento mediante SMTP. Si se implementan los conectores X.400 para conectar los grupos de enrutamiento, entonces la información de estado de vínculos también deberá intercambiarse a través de X.400.. Para realizar esta tarea, el MTA de Exchange llama al motor de enrutamiento para obtener el código MD5 actual, que es una firma cifrada que representa el número de versión de la tabla de estado de vínculos. En base a esta información, los motores de enrutamiento enru determinan si la información de estado de vínculos que poseen es la misma. Antes de enviar los mensajes, el MTA local envía el atributo GUID de la organización de Exchange y el código MD5 actual en un paquete DIGEST_QUERY al MTA remoto. Cuando el MTA remoto reconoce el paquete DIGEST_QUERY, pasa la información a su motor de enrutamiento. El motor de enrutamiento compara el código con su copia del mismo y pasa los resultados de la comparación a su MTA. Después, el MTA remoto envía la respuesta de vuelta al MTA local.

420

Ejemplo de una consulta de código y una respuesta a la consulta.

Si los códigos MD5 de los servidores que ejecutan Exchange Server difieren, se entablará una conversación más detallada entre los MTA para intercambiar paquetes OrgInfo. El paquete OrgInfo contiene la tabla de estado de vínculos, con todos los detalles y estados de la topología de enrutamiento. Los MTA pasan los paquetes OrgInfo a sus motores de enrutamiento locales, y éstos determinan qué servidor posee la información más actualizada. El servidor con la información más actualizada descarta el paquete OrgInfo recibido. El otro servidor pasa la información actualizada de estado de vínculos a su maestro del grupo de enrutamiento, y éste actualiza la información de estado de vínculos en todos los servidores de su grupo de enrutamiento local. Los MTA de Exchange transfieren consultas de código incluso conectados a MTA externos a la organización local de Exchange. El motor de enrutamiento receptor comprueba el GUID de organización en el paquete DIGEST_QUERY, con el fin de determinar si la información de estado de vínculos procede de la organización local y omite el código MD5 cuando procede de otra organización. La respuesta a la consulta indica que no deben intercambiarse paquetes OrgInfo.

MTA de Exchange en una organización en modo mixto El MTA de Exchange es un componente fundamental en una organización en modo mixto para mantener la compatibilidad con los servidores en los que se ejecuta Exchange Server 5.5. En el sitio local, los MTA de Exchange Server 5.5 se comunican directamente

421

entre sí mediante llamadas a procedimiento remoto (RPC), y Exchange Server 2003 debe utilizar los mismos mecanismos. Los MTA y las RPC también se utilizan en conectores de grupos de enrutamiento con un servidor en el que se ejecuta Exchange Server 5.5 como cabeza de puente remota (es decir, un conector de grupos de enrutamiento funciona como un conector de sitios en Exchange 5.5).

Comunicación MTA basada en RPC Para realizar la comunicación a través de RPC no es necesario configurar una pila de transporte OSI ni un conector X.400. Cuando los componentes de Exchange se comunican directamente entre sí, se conocen todos los parámetros. Por ejemplo, si los MTA de Exchange Server 2003 se comunican con servidores con Exchange 5.5 Server en el grupo de enrutamiento local, no es necesario configurar un conector. El MTA de Exchange también se comunica con el almacén de Exchange a través de XAPI para transferir mensajes al servicio SMTP y a los conectores basados en MAPI cuyas colas de mensajes se encuentran en el almacén de Exchange. Esta comunicación se basa en MAPI, que es una API basada en RPC. Al ver mensajes en colas de mensajes de MTA mediante el complemento Visor de cola en el Administrador del sistema de Exchange, esta comunicación también se basa en RPC. El MTA de Exchange utiliza un conjunto de subprocesos RPC para admitir la comunicación con los MTA de la LAN, con el almacén de Exchange y con las herramientas administrativas. Puede controlar el número mínimo y máximo de subprocesos RPC con los siguientes parámetros del Registro. Ubicación

HKEY_LOCAL_MACHINE\System\CurrentControlSe t\Services\ MSExchangeMTA\Parameters

Valor

Min RPC Threads

Tipo

REG_DWORD

Información del valor

0x4

Descripción

Determina el número mínimo de subprocesos RPC que debe crear y mantener la biblioteca de tiempo de ejecución de RPC para el proceso MTA. El valor predeterminado es 0x4.

422

Ubicación

HKEY_LOCAL_MACHINE\System\CurrentControlSe t\Services\ MSExchangeMTA\Parameters

Valor

Max RPC Calls Outstanding

Tipo

REG_DWORD

Información del valor

0x32

Descripción

Determina el número máximo de subprocesos RPC. Esto limita el número máximo de llamadas RPC que se procesarán a la vez. El valor predeterminado es 0x32 (50). El valor recomendado es 0x80 (128) en escenarios de coexistencia de Exchange Server 5.5 y Exchange Server 2003. El valor de Max RPC Calls Outstanding no debe ser cero y debe ser superior a Min RPC Threads. Si aumenta el número máximo de subprocesos RPC, también debe aumentar el número de subprocesos de entrada y salida de puerta de enlace para cada almacén de buzón en el proceso de almacén de Exchange, mediante los parámetros del Registro Gateway In Threads y Gateway Out Threads bajo HKEY_LOCAL_MACHINE \System\CurrentControlSet \Services\MSExchangeIS\<nombre_servid or>\Private-, tal y como se explica anteriormente en este capítulo.

Impacto sobre el rendimiento de RPC Debe asegurarse de que no hay problemas de comunicación RPC en el servidor cabeza de puente. Por ejemplo, no debe haber servidores en los que se ejecuta Exchange Server 5.5 inactivos con frecuencia en el grupo de enrutamiento del servidor cabeza de puente. Como la comunicación RPC se realiza de forma sincrónica, el MTA debe esperar a que caduque un tiempo de espera antes de poder dar servicio a otras conexiones salientes, que tienen prioridad frente a las conexiones entrantes. Por consiguiente, los problemas de comunicación RPC pueden degradar el rendimiento de todo el MTA, incluidos todos los

423

conectores X.400. Por contra, los conectores X.400 establecen conexiones asincrónicas, que tienen poca o ninguna influencia sobre otros conectores. Nota: El MTA utiliza RPC para transferir mensajes dentro y fuera del almacén almacén de Exchange. Sin embargo, en esta comunicación RPC no deberían surgir problemas durante el funcionamiento normal del servidor ni debería afectar al rendimiento del servidor.

Error de restablecimiento de enlace RPC El establecimiento de una conexión RPC es un proceso de establecimiento y restablecimiento de enlace, en el que el MTA local confirma primero que se está comunicando con el MTA remoto (se comprueban el nombre y la contraseña del MTA remoto) y, a continuación, el MTA remoto confirma la identidad identidad del MTA local (se envían y comprueban el nombre y la contraseña del MTA local). Un MTA de Exchange registra los errores de restablecimiento de enlace RPC al establecer conexiones RPC con un MTA remoto que no pueden resolver el nombre de dominio completo (FQDN) del MTA local. Cuando el MTA remoto intenta restablecer el enlace con la cadena de conexión que se le ha asignado y no puede resolver el FQDN, el restablecimiento del enlace no puede realizarse y se registra el siguiente error en el registro de sucesos: suce Event ID: 9322 Source: MSExchangeMTA Description: An interface error has occurred. An MtaBindBack over RPC has failed. Locality Table (LTAB) index: %1, NT/MTA error code:1722. Comms error %3, Bind error %4,Remote Server Name %5, Protocol String IP Address Add of Server.

Cuando se produce un error de restablecimiento del enlace, el servidor de enlace no recibe una respuesta del sistema remoto. Finalmente, la biblioteca de tiempo de ejecución de RPC encuentra un tiempo de espera y registra el siguiente error en el registro de sucesos: Event ID: 9318 Source: MSExchangeMTA - Interface Description: An RPC communications error occurred. Unable to bind over RPC. Locality Table (LTAB) index: 151, NT/MTA error code: 1722. Comms error 1722, Bind error 1722, Remote Server rver Name SERVERNAME [MAIN BASE 1 500 %10] (14)

Para resolver este problema, debe asegurarse de que ambos MTA puedan resolver los FQDN del otro en direcciones IP.

424

Tabla de enrutamiento de direcciones de la puerta de enlace Para realizar el enrutamiento de los mensajes, los servidores en los que se ejecuta Exchange Server 5.5 utilizan la Tabla de enrutamiento de direcciones de la puerta de enlace (GWART) y los servidores en los que se ejecuta Exchange Server 2003 utilizan la información de estado de vínculos. En una organización en modo mixto, el Servicio de replicación de sitios (SRS) replica la información de directorio de Exchange Server 5.5 con Active Directory. Por consiguiente, los servidores en los que se ejecuta Exchange Server 2003 encuentran todos los conectores en la partición de directorio de configuración. Así, el motor de enrutamiento puede incluir conectores instalados en Exchange Server 5.5 en la tabla de estado de vínculos. Esto proporciona a los usuarios de Exchange Server 2003 la capacidad de utilizar conectores que no están disponibles en Exchange Server 2003, como el Conector para Lotus cc:Mail, el Conector para Professional Office System (PROFS) o el Conector para SNA Distribution System (SNADS). Para que los servidores en los que se ejecuta Exchange Server 5.5 puedan utilizar conectores en Exchange Server 2003, se genera una GWART que incluye toda la información de los conectores. A continuación, los usuarios de Exchange Server 5.5 pueden enviar mensajes a usuarios de Internet a través de conectores para SMTP instalados en Exchange Server 2003. Esto resulta ventajoso porque todos los usuarios de Exchange pueden aprovechar las capacidades de filtrado de la conexión y de correo no deseado de Exchange Server 2003. Para la compatibilidad con versiones anteriores, un MTA de Exchange Server 2003 genera la GWART y se comunica con Active Directory a través de la Interfaz de servicio de Active Directory (ADSI) para escribir el objeto GWART. El MTA escribe la información de enrutamiento en formato binario en el atributo gatewayRoutingTree y actualiza el atributo gWARTLastModified del objeto de directorio para indicar cuándo se actualizó por última vez la GWART. El objeto GWART se encuentra en el grupo administrativo del servidor en el que se ejecuta Exchange Server. El Servicio de replicación de sitios (SRS) replica el objeto GWART en el directorio de Exchange Server 5.5 y Exchange Server 5.5 replica la GWART en todos los servidores en los que se ejecuta Exchange Server 5.5, de forma que todos estos servidores pueden incluir conectores de Exchange Server 2003 en sus decisiones de enrutamiento. Puede utilizar la siguiente línea de comandos para exportar todos los objetos GWART de una organización de Exchange: ldifde -f c:\GWART.ldf -s localhost -d " CN=Administrative Groups,CN=First Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=contoso,DC=com" -p subtree -r "(objectClass=siteAddressing)".

La tabla siguiente describe los atributos importantes del objeto de directorio GWART.

425

Atributos importantes del objeto GWART Atributo

Descripción

objectClass

Identifica el objeto de directorio como objeto GWART, basado en la clase de objeto siteAddressing.

gatewayRoutingTree

Contiene la tabla de enrutamiento en el formato requerido por los MTA de Exchange Server 5.5.

gWARTLastModified

Especifica la fecha y hora de la última actualización del objeto GWART.

ridServer

Señala al servidor que mantiene la GWART para este grupo administrativo.

Bucles de mensajes entre Exchange Server 5.5 y Exchange Server 2003 En una organización de Exchange en modo mixto, no debe especificar servidores en los que se ejecuta Exchange Server 2003 como servidores de expansión para listas de distribución que contengan usuarios de Exchange Server 5.5. Si un usuario de Exchange Server 5.5 envía un mensaje a una lista de distribución de este tipo, el MTA de Exchange Server 5.5 reenvía correctamente el mensaje al servidor de expansión de Exchange Server 2003. En Exchange Server 2003, la expansión de listas de distribución la realiza el categorizador del servicio SMTP. No obstante, el subsistema de transporte SMTP no corrige el atributo TraceInformation del sobre de transferencia de mensajes P1 para marcar el mensaje como lista de distribución expandida. Después de expandir la lista de distribución, Exchange Server 2003 enruta el mensaje a Exchange Server 5.5 para todos los destinatarios de Exchange Server 5.5. Si el mensaje vuelve a un servidor en el que se ejecuta Exchange Server 5.5 que ya ha tratado el mensaje, éste se cancela y se genera un informe de no entrega. Esto ocurre porque se detecta un bucle. SMTP no dispone de información de seguimiento de X.400 y el MTA de Exchange Server 5.5 basado en X.400 debe cancelar el mensaje, ya que el atributo TraceInformation del sobre P1 no indica que es un mensaje de lista de distribución expandida. Para evitar este problema, los servidores con Exchange Server 5.5 deben utilizarse como servidores de expansión para las listas de distribución que contengan usuarios de Exchange Server 5.5.

426

Arquitectura de los conectores de mensajería de puerta de enlace En Microsoft Exchange Server 2003 hay dos tipos de conectores de mensajería: conectores nativos y conectores de puerta de enlace. Los conectores nativos incluyen el Conector para grupo de enrutamiento (en Exchange Server 5.5 se denomina Conector del sitio), el Conector SMTP y el Conector X.400. Puede utilizarlos para conectar grupos de enrutamiento de Exchange entre sí. No obstante, como el conector SMTP y el conector X.400 utilizan protocolos estándar (es decir, SMTP y X.400), también pueden utilizarse como conectores de puerta de enlace a sistemas de mensajería distintos de Exchange. Generalmente, los conectores de puerta de enlace utilizan protocolos no estándar o API propietarias para conectar Exchange con sistemas de mensajería distintos de Exchange, como Novell GroupWise o Lotus Notes. Los conectores de puerta de enlace incluidos en Exchange Server 2003 (es decir, Conector de Exchange para Novell GroupWise y Conector de Exchange para Lotus Notes) admiten la sincronización de directorios y la conversión de mensajes. Sin embargo, hay otros conectores de puerta de enlace disponibles. Otros proveedores distintos de Microsoft utilizan en Kit de desarrollo de Exchange (EDK) para desarrollar sus propios conectores de puerta de enlace para otros tipos de sistemas de mensajería. Los conectores de puerta de enlace basados en el EDK dependen de MAPI. Por este motivo, en esta sección se hace referencia a los conectores de puerta de enlace como conectores basados en MAPI. En esta sección se explican los siguientes conceptos: •

Arquitectura del conector de EDK general Todos los conectores basados en MAPI tienen varias características en común. Para evaluar la forma en que los conectores de Microsoft y de otros fabricantes se integran con Exchange Server 2003 debe comprender la arquitectura del conector de EDK. Para obtener información detallada acerca de la programación de conectores basados en MAPI, consulte la Exchange 2000 Sample Gateway.

•

Arquitectura del Conector para Lotus Notes Este conector basado en MAPI incluye componentes necesarios para la comunicación con Lotus Notes. Debe comprender cómo interactúan entre sí estos componentes para poder entender cómo Exchange Server 2003 realiza la transferencia de mensajes y la sincronización de directorios con Lotus Notes.

•

Arquitectura del Conector para Novell GroupWise Este conector basado en MAPI incluye componentes necesarios para la comunicación con Novell GroupWise. Debe saber cómo interactúan entre sí estos componentes para poder comprender cómo Exchange Server 2003 realiza la transferencia de mensajes y la sincronización de directorios con Novell GroupWise.

•

Arquitectura del Conector de calendario El Conector de calendario de Microsoft Exchange Server 2003 no transfiere mensajes, como hacen otros conectores, sino que proporciona a los usuarios de Exchange Server 2003 y Lotus Notes o Novell GroupWise

427

acceso prácticamente en tiempo real a la información de disponibilidad del calendario de los demás usuarios. Si desea sincronizar información de disponibilidad de Exchange y de otros programas debe saber cómo se integran los componentes del Conector de calendario con el Conector para Lotus Notes y el Conector para Novell GroupWise. En esta sección se trata la arquitectura de los conectores de MAPI disponibles en Exchange Server 2003. Estos conectores se utilizan exclusivamente para conectar una organización de Exchange a un sistema de mensajería que no es de Exchange, como puede ser Lotus Notes o Novell GroupWise. Se presupone que sabe cómo configurar los componentes de los conectores en el Administrador del sistema de Exchange. Para obtener más información acerca de cómo conectar y migrar los sistemas de mensajería distintos de Exchange a Exchange Server 2003, consulte la Exchange Server 2003 Interoperability and Migration Guide.

Arquitectura del conector de EDK Para una interacción óptima entre usuarios de Exchange y de otros programas, los conectores a sistemas de mensajería distintos de Exchange deben habilitar las siguientes tareas fundamentales: •

Transferencia de mensajes bidireccional La transferencia de mensajes de correo electrónico es la tarea de conector más importante. No obstante, los conectores basados en MAPI no realizan el enrutamiento de mensajes en una organización de Exchange. Estos conectores obtienen los mensajes salientes de un servidor cabeza de puente específico de Exchange y transfieren los mensajes entrantes a este mismo servidor. A continuación, se realiza el enrutamiento y la entrega de mensajes en el subsistema de transporte SMTP. Para obtener información detallada acerca del tratamiento de mensajes de Exchange Server 2003, consulte Arquitectura de enrutamiento de mensajes. En la parte no correspondiente a Exchange de una transferencia de mensajes, la entrega y la recuperación de los mensajes dependen de las características y las interfaces de programación proporcionadas por el sistema de mensajería que no es de Exchange. Normalmente sólo se utiliza un único punto de contacto en esta parte de la transferencia de mensajes. Por ejemplo, el Conector para Lotus Notes sólo se conecta a un servidor Lotus Domino. El servidor del sistema de mensajería que no es de Exchange determina cómo enrutar los mensajes a sus destinos finales. La figura siguiente ilustra los pasos que normalmente debe realizar un conector basado en MAPI para efectuar la transferencia de mensajes entrantes y salientes.

428

Transferencia de mensajes a través de un conector basado en MAPI

La transferencia de mensajes desde y hacia un sistema de mensajería que no es de Exchange incluye los pasos siguientes: a. La transferencia de mensajes empieza con la obtención de mensajes del sistema de origen. Los conectores basados en MAPI utilizan MAPI para recuperar mensajes de Exchange. En la parte distinta de Exchange de la transferencia de mensajes, la recuperación de mensajes se basa en las interfaces de programación proporcionadas por el sistema de mensajería que no es de Exchange, como la API del cliente de Lotus Notes o la puerta de enlace API de Novell GroupWise. b. El paso siguiente en la transferencia de mensajes es su conversión al formato del sistema de mensajería de destino. Este paso incluye la asignación de direcciones y la conversión de formatos de mensaje de MAPI a formatos distintos de Exchange y viceversa. c.

El paso final de la transferencia de mensajes es la entrega de los mensajes convertidos al sistema de destino. De nuevo, los conectores de EDK utilizan MAPI para entregar mensajes al almacén de Exchange. En la parte distinta de Exchange de la transferencia de mensajes, se utiliza una interfaz de programación propietaria, como la API del cliente de Lotus Notes o la puerta de enlace API de Novell GroupWise, para realizar la transferencia.

•

Sincronización de directorios La sincronización de directorios es la segunda tarea en cuanto a importancia que realizan los conectores basados en MAPI. La sincronización de directorios es opcional pero resulta muy útil, ya que proporciona a todos los usuarios acceso a listas de direcciones completas que incluyen los destinatarios de los entornos de Exchange y de otros programas. En Exchange Server 2003, la información de directorios se encuentra en el servicio de directorio Microsoft Active Directory y la sincronización de directorios se realiza mediante el protocolo ligero de acceso a directorios (LDAP) y las Interfaces de servicio de Active Directory (ADSI).

•

Realización de funciones de compatibilidad La transferencia de mensajes y la sincronización de directorios son las tareas más importantes que debe realizar un conector basado en MAPI. Además, deben implementarse funciones de compatibilidad para aumentar el nivel de integración con Exchange Server 2003. Entre estas funciones se incluyen las siguientes:

429

•

Supervisión del rendimiento Los conectores basados en MAPI proporcionan contadores de rendimiento que permiten a los administradores crear informes de supervisión del rendimiento mediante la herramienta Rendimiento, disponible en Herramientas administrativas, en el menú Inicio.

•

Registro de sucesos Los conectores basados en MAPI realizan el seguimiento de los sucesos importantes (como inicios, detenciones y conversión y transferencia de mensaje del servicio Conector) en función de diversos niveles de diagnóstico en el registro de sucesos de aplicación. El administrador puede utilizar la herramienta Visor de sucesos, disponible en Herramientas administrativas, para determinar si el conector funciona correctamente. El registro de sucesos de aplicación es una fuente de información esencial para solucionar problemas en la transferencia de mensajes.

•

Tratamiento de errores Por medio de las notificaciones del estado de entrega, los conectores basados en MAPI informan a los remitentes de mensajes acerca de los problemas de transferencia. Por ejemplo, un conector envía un informe de no entrega (NDR) al remitente del mensaje si no puede tratar un destinatario debido a una dirección con un formato incorrecto.

•

Seguimiento de mensajes Los conectores basados en MAPI realizan el seguimiento de la información sobre los mensajes que pasan por el conector en los archivos del registro de seguimiento de mensajes de Exchange Server 2003, lo cual permite a los administradores analizar la ruta completa que sigue un mensaje desde el servidor del remitente hasta el punto en el que el mensaje abandona la organización de Exchange. Para los mensajes entrantes, el seguimiento empieza cuando éstos llegan al conector basado en MAPI y entran en la organización de Exchange. De forma predeterminada, el seguimiento de mensajes no está habilitado. Debe habilitar esta función en todos los servidores en los que desee realizar el seguimiento de mensajes o utilizar una directiva de servidor. En el Administrador del sistema de Exchange, en las Propiedades del servidor o de la directiva de servidor, seleccione la ficha General y, a continuación, active la casilla de verificación Habilitar seguimiento de mensajes.

Componentes de los conectores Los conectores basados en MAPI constan de una serie de componentes que permiten una integración óptima con Exchange Server 2003. Entre ellos se incluyen objetos de configuración de Active Directory que contienen opciones específicas de los conectores y las aplicaciones de conector que realizan la conversión y la transferencia de mensajes. Los conectores basados en MAPI también incorporan complementos de Microsoft Management Console (MMC), que se integran con el Administrador del sistema de Exchange para poder realizar tareas de configuración del sistema por medio de una interfaz de usuario unificada. Los conectores basados en MAPI constan de los siguientes componentes: •

Servicio Conector Normalmente, los conectores basados en MAPI se implementan como servicios de Microsoft Windows que se ejecutan directamente en el servidor

430

cabeza abeza de puente de Exchange Server 2003. Por consiguiente, se inician automáticamente al iniciarse el servidor y se ejecutan en su propio contexto de seguridad. En Exchange Server 2003, todos los servicios, incluidos los servicios de los conectores basados en MAPI, utilizan la cuenta LocalSystem, tal y como se ha explicado en Dependencias de los servicios de Exchange Server 2003. 2003 Nota: Los componentes de los conectores pueden ejecutarse directamente en un servidor en el que se ejecute Exchange Server 2003 o en otro equipo que se comunique con Exchange Server 2003 a través de la red. Normalmente, se obtiene acceso al sistema de mensajería qu que e no es de Exchange a través de la red, aunque si este sistema se encuentra en el servidor de conectores es posible que aumente el rendimiento de los mismos. Por ejemplo, Exchange Server 2003 y Lotus Domino pueden ejecutarse en el mismo servidor. •

DLL de conversión Los conectores basados en MAPI pueden registrar DLL de conversión con la estructura de Exchange Server 2003 para convertir los mensajes, de forma que, al convertir mensajes entrantes o salientes, el conector pueda llamar al código de conversión n adecuado. Estas DLL deben estar registradas en el Registro, bajo la clave HKEY_LOCAL_MACHINE\Software\Classes\MAPI HKEY_LOCAL_MACHINE MAPI Conversions. Conversions Debe haber una subclave para cada DLL de conversión. El nombre de esta subclave debe corresponder al del archivo DLL. Estas DL DLL L deben instalarse en el directorio \System32 del servidor cabeza de puente. Cada clave de DLL contiene una subclave para cada punto de entrada en una DLL de conversión, que el motor de conversión utiliza para realizar la conversión. Nota: nversión son componentes opcionales. El código para realizar las Las DLL de conversión conversiones de mensajes también se puede incrustar directamente en los conectores basados en MAPI; en este caso no se utilizan DLL de conversión. Por ejemplo, el Conector para Lotus Notes y el Conector para Novell GroupWise no dependen de DLL de conversión. Los mecanismos de los que dependen estos conectores para realizar las conversiones de mensajes se tratan en secciones posteriores.

•

DLL de generación de direcciones proxy Las direccioness proxy son direcciones no Exchange que el servicio de actualización de destinatarios asigna a objetos de destinatario de Exchange en Active Directory. Esto permite a los usuarios de otros sistemas de mensajería enviar mensajes de correo electrónico a usuarios usua de Exchange y viceversa. Por ejemplo, el usuario de Exchange Ted Bremer puede tener una dirección de correo electrónico proxy de NOTES de Ted@Exchange. Un usuario de Lotus Notes puede utilizar esta dirección de correo electrónico para enviar un mensaje mensaj a Ted. En un entorno de Lotus Notes, Ted aparece como usuario en un dominio externo de Lotus Notes denominado Exchange, asociado con el Conector para Lotus Notes. Así, Lotus Notes enruta el mensaje dirigido a Ted@Exchange al Conector para Lotus Notes.

431

Cuando ando el Conector para Lotus Notes recupera el mensaje, realiza la conversión de la dirección y sustituye la dirección (de proxy) de Lotus Notes del usuario de Exchange por la dirección real de Exchange (la dirección X.500 del usuario, tal y como se especif especifica en el atributo legacyExchangeDN). De manera similar, el Conector para Lotus Notes sustituye la información de dirección de Exchange de Ted por su información de dirección proxy de Lotus Notes en todos los mensajes salientes hacia Lotus Notes. El formato o de dirección nativo de Exchange Server 2003 es SMTP. Nota: Normalmente, los usuarios de Exchange aparecen en los sistemas de mensajería distintos de Exchange como destinatarios normales existentes en estos sistemas. Para permitir al servicio de actualización actualización de destinatarios generar direcciones proxy en el formato correcto, los conectores basados en MAPI deben instalar una DLL de generación de direcciones proxy adecuada en el servidor en el que se ejecuta Exchange Server 2003. Las DLL de direcciones proxy proxy se encuentran en subdirectorios que corresponden a los tipos de dirección y de procesador de equipo, bajo \Archivos de programa\Exchsrvr\Address. Address. Este subdirectorio está compartido para el acceso de red (nombre del recurso compartido: \\\\<nombre del servidor>\Address), Address), para que el servicio de actualización de destinatarios pueda obtener acceso a las DLL aunque el conector de mensajería esté instalado en otro servidor en el que se ejecute Exchange Server. En Exchange Server 2003 y Active Directory,, encontrará información adicional acerca del servicio de actualización de destinatarios. La figura siguiente ilustra un ejemplo de direcciones proxy asignadas por el servicio de actualización de destinatarios a un usuario de Exchange.

432

Direcciones proxy para un usuario de Exchange

Los usuarios pueden tener direcciones proxy principales y secundarias. Por ejemplo, la figura 8.2 muestra una dirección proxy de Lotus Notes secundaria para Ted. La dirección proxy principal se utiliza como dirección del remitente en todos los mensajes salientes sal hacia el sistema de mensajería que no es de Exchange. Las direcciones proxy secundarias se utilizan para entregar los mensajes entrantes al destinatario adecuado en Exchange Server 2003 cuando estos mensajes no van dirigidos a la dirección de proxy principal. Para seguir con el ejemplo, Ted también puede recibir mensajes de Lotus Notes dirigidos a Ted@Contoso, ya que ésta es la dirección proxy secundaria de NOTES de Ted. Nota: Puede definir direcciones proxy para usuarios de Exchange en las direc directivas de destinatarios en el Administrador del sistema de Exchange. Un usuario de Exchange sólo tiene una dirección proxy principal por tipo de dirección, pero puede tener varias direcciones secundarias. Todas las direcciones proxy

433

(principales y secundarias) deben ser únicas en la organización de Exchange. Por ejemplo, no puede haber dos destinatarios de Exchange con una dirección proxy de NOTES de Ted@Contoso. •

Objeto addrType La inclusión de una DLL de generación de direcciones proxy en un subdirectorio bajo \Archivos de programa\Exchsrvr\Address en un servidor en el que se ejecute Exchange Server 2003 no hace que el servicio de actualización de destinatarios genere direcciones proxy para un tipo de dirección en concreto. Para habilitar un tipo de dirección, el conector también debe registrar el tipo de dirección que admite en un objeto addrType en Active Directory. Todos los objetos addrType se encuentran en la partición del directorio de configuración de Active Directory, en el contenedor Address-Types. Puede ver el contenido de este contenedor mediante ADSI Edit. También puede ver este contenedor en Sitios y servicios de Active Directory al seleccionar la opción Mostrar nodo de servicios en el menú Ver para mostrar el nodo de servicios. La ruta de acceso al contenedor Address-Types es \Services\Microsoft Exchange\<nombre de la organización de Exchange>\Addressing\Address-Types. De forma predeterminada, hay objetos addrType para CCMAIL, GWISE, MS, NOTES, SMTP y X400. En la tabla siguiente se enumeran los atributos importantes de los objetos addrType. Atributos de los objetos addrType

•

Atributos

Descripción

Common-Name

Nombre común del Address-Type utilizado para crear el nombre completo del objeto en Active Directory.

File-Version

Número de versión del archivo DLL de generación de direcciones proxy.

proxyGeneratorDLL

Nombre de la DLL de generación de direcciones proxy utilizada para este tipo de dirección. Por ejemplo, el objeto addrType con el nombre común NOTES:i386 especifica una DLL de generación de direcciones proxy denominada Ntspxgen.dll en este atributo.

name

El nombre del tipo de dirección, como NOTES:i386.

Plantillas de dirección Junto con el objeto addrType, los conectores basados en MAPI también pueden instalar plantillas de dirección y plantillas de opciones para proporcionar una interfaz sencilla que puede utilizarse para crear destinatarios personalizados para el sistema de mensajería que no es de Exchange. Estas plantillas describen las opciones en un cuadro de diálogo con el que se pueden indicar direcciones personalizadas. Las plantillas de dirección funcionan con un programa de sintaxis de direcciones para

434

convertir los datos indicados por el usuario en una cadena de dirección proxy. Las plantillas de dirección pueden personalizarse en el Administrador del sistema de Exchange (en el contenedor Plantillas de dirección, en Destinatarios). Destinatarios Nota: Las plantillas de dirección y los programas de sintaxis de direcciones son componentes opcionales de los conectores. El Conector Conector para Lotus Notes y el Conector para Novell GroupWise no instalan estos componentes. •

Objeto msExchConnector El objeto del conector que todos los conectores basados en MAPI deben tener en Active Directory es más importante que las plantillas de dirección. direc Al iniciar el servidor, el motor de enrutamiento enumera y lee todos los objetos msExchConnector de todos los grupos de enrutamiento para inicializar la tabla de estado de vínculos. Esto se explica en Arquitectura de enrutamiento de mensajes. mensajes Los objetos del conector se encuentran en el contenedor Conectores, Conectores en sus grupos de enrutamiento, en el Administrador del sistema de Exchange. Es necesario disponer d del complemento administrativo correspondiente para configurar las opciones del objeto msExchConnector. Entre éstas se incluyen atributos específicos del tipo de conector, además de atributos generales. Nota: Además del objeto msExchConnector de Active Directory, la información de configuración también puede almacenarse en la base de datos del Registro del servidor cabeza de puente. En la tabla siguiente se enumeran atributos generales importantes comunes a todos los conectores basados en MAPI.

435

Atributos generales importantes de los objetos msExchConnector Atributos

Descripción

Common name

Representa el nombre del objeto del conector en Active Directory, en relación con su contenedor primario.

computerName

Señala al servidor cabeza de puente en el que se ejecuta el conector basado en MAPI. Este atributo debe coincidir exactamente con el nombre del sistema básico de entrada/salida de red (NetBIOS) del servidor cabeza de puente; de lo contrario, el complemento Visor de cola del Administrador del sistema de Exchange no podrá mostrar las colas de mensajes del conector.

deliveryMechanism

Identifica el mecanismo de entrega utilizado por Exchange Server 2003 para transmitir mensajes al conector basado en MAPI.

distinguishedName

Representa el nombre completo del objeto del conector en Active Directory.

homeMDB

Identifica el almacén privado en el que se encuentra el buzón del conector.

homeMTA

Identifica el MTA de Exchange encargado del enrutamiento de mensajes al conector basado en MAPI.

legacyExchangeDN

Representa el nombre completo del objeto del conector en el formato de directorios anterior de Exchange Server 5.5. Este atributo debe definirse en el objeto del conector para que el complemento Visor de cola funcione.

msExchConnectorType

Identifica el tipo de conector. Por ejemplo, el tipo de conector del Conector para Lotus Notes es NOTES y el tipo de conector del Conector para Novell GroupWise es GWISE.

name

Representa el nombre del objeto del conector. El Administrador del sistema de Exchange utiliza este nombre como nombre para mostrar del objeto del conector.

436

Atributos

Descripción

objectClass

Identifica el conector como msExchConnector y mailGateway. Además, se registra una clase de objeto específica para identificar el tipo real de conector. Por ejemplo,, msExchNotesConnector es la clase de objeto del Conector para Lotus Notes y msExchGroupWiseConnector es la clase de objeto del objeto de puerta de enlace del Conector para Novell GroupWise. Nota: Para admitir atributos específicos de conector, los conectores conec basados en MAPI de proveedores distintos de Microsoft deben ampliar el esquema de Active Directory para crear una nueva clase de objeto. Los conectores basados en MAPI deben representarse en Active Directory mediante objetos de una clase heredera de la clase mailGateway. El objeto mailGateway, a su vez, es una subclase de msExchConnector.

routingList

•

Identifica los espacios de direcciones asociados con este conector. Cada conector tiene como mínimo un espacio de direcciones asociado. El motor de enrutamiento tamiento utiliza esta información para determinar posibles conectores para un mensaje concreto; para ello, compara las direcciones de los destinatarios con la información de espacios de direcciones disponible.

Complemento administrativo Los conectores basados en MAPI deben agregar y registrar un complemento de extensión MMC en el Administrador del sistema de Exchange para que los administradores de Exchange puedan configurar el objeto msExchConnector del conector en Active Directory (y probablemente las opciones del Registro) mediante una interfaz de usuario de fácil utilización. Por ejemplo, el Conector para Lotus Notes incorpora un complemento Conector de Exchange para Notes y el Conector para Novell GroupWise incorpora un complemento Conector de Exchange para

437

GroupWise. Ambos complementos están implementados en Exadmin.dll, tal y como se explica en Arquitectura del Administrador Adm del sistema de Exchange. •

Buzón del conector Cuando se crea un objeto msExchConnector en Active Directory para un conector basado en MAPI, Exchange Server 2003 crea un buzón especial para el conector en el almacén de buzones especificado en e ell atributo homeMDB del objeto msExchConnector. El almacén de Exchange crea este buzón especial en el servidor cabeza de puente al iniciar el servicio del conector por primera vez o al enrutar el primer mensaje al conector. Este buzón incluye las colas de mensajes mensajes entrantes y salientes del conector basado en MAPI, denominadas MTS MTS-IN y MTS-OUT OUT y, probablemente, otras carpetas, denominadas Badmail, ReadyIn y ReadyOut, Deferred Action, Spooler Queue y Temp, que el conector puede utilizar durante el procesamient procesamiento o de mensajes. Por ejemplo, el Conector para Lotus Notes y el Conector para Novell GroupWise colocan los mensajes dañados en la carpeta Badmail. La utilización de otras carpetas, además de MTS-IN y MTS-OUT, OUT, depende de la implementación real de los conectores. conector Nota: Como mínimo, el buzón de un conector debe tener una carpeta MTS-IN MTS y una carpeta MTS-OUT. OUT.

Transferencia de mensajes de y a Exchange Server 2003 Mientras que los procesos que se comunican con el sistema de mensajería que no es de Exchange dependen den del tipo de conector individual, todos los conectores de EDK utilizan MAPI para obtener acceso a sus buzones de conector en el almacén de Exchange. Tal y como se ilustra en la figura siguiente, el agente de transferencia de mensajes (MTA) de Exchange coloca oloca los mensajes dirigidos al sistema de mensajería que no es de Exchange en la carpeta MS-OUT OUT y el conector basado en MAPI coloca los mensajes entrantes que ha recuperado y convertido del sistema de mensajería que no es de Exchange en la carpeta MTS-IN. El MTA de Exchange se trata detalladamente en Arquitectura de transporte X.400. X.400 Nota: Como las colas de mensajes del conector están siempre disponibles, los conectores basados en MAPI se marcan siempre como STATE_UP en la tabla de estado de vínculos y el MTA de Exchange sigue entregando los mensajes a un conector basado en MAPI aunque el servicio Conector no esté en ejecución. Esto puede hacer que se recopilen numerosos mensajes en la cola de mensajes MS-OUT. MS

438

Colas del conector en el almacén de Exchange

Transferencia de mensajes salientes Exchange Server 2003 realiza los siguientes pasos para transferir mensajes a un sistema de mensajería que no es de Exchange: 1. Un usuario de Exchange envía un mensaje a un usuario de otro sistema. El mensaje se transmite al servicio SMTP para su enrutamiento y transferencia. 2. El servicio SMTP clasifica y enruta el mensaje, tal y como se explica en Arquitectura de enrutamiento de mensajes. Como este mensaje es para un usuario de un sistema que no es de Exchange, el motor de enrutamiento asigna el mensaje al MTA de Exchange. El MTA de Exchange es el encargado de los conectores basados en MAPI con sistemas distintos de Exchange. 3. El servicio SMTP transmite el mensaje al MTA de Exchange a través del almacén de Exchange. El MTA de Exchange coloca el mensaje en una cola de mensajes interna, que el MTA mantiene independientemente del almacén de Exchange en el sistema de archivos (\Archivos de programa\Exchsrvr\Mtadata). 4. El MTA de Exchange se comunica con el motor de enrutamiento del subsistema de transporte SMTP a través de MTARoute.dll para determinar cuál es el conector basado en MAPI de destino. 5. El motor de enrutamiento identifica, mediante espacios de direcciones, el conector basado en MAPI que se ocupa del destinatario y devuelve esta información al MTA de Exchange. 6. El MTA de Exchange ajusta el mensaje en un sobre de transferencia de mensajes (MTE) y lo coloca en la carpeta de destino MTS-OUT del conector basado en MAPI. El sobre de transferencia de mensajes contiene una lista de destinatarios a los que el conector

439

basado en MAPI debe entregar el mensaje, además del mensaje original en forma de datos adjuntos. Nota: Para determinar cuándo un mensaje saliente llega a su carpeta MTS-OUT, MTS un conector basado en MAPI puede sondear el buzón del conector periódicamente o esperar a que se produzca un suceso Advise en el almacén de Exchange que indique la existencia de un nuevo mensaje saliente.

Transferencia de mensajes entrantes En la parte de Exchange de una transferencia de mensajes, la entrega de mensajes mensaj entrantes requiere menos pasos que la transferencia de mensajes salientes. Cuando un conector basado en MAPI coloca un mensaje entrante en la carpeta MTS-IN, MTS el MTA de Exchange transmite el mensaje directamente al subsistema de transporte SMTP para su clasificación, lasificación, enrutamiento y entrega, sin realizar el enrutamiento del mensaje por sí mismo. Para realizar la transferencia de mensajes entrantes se siguen los siguientes pasos: 1. El conector basado en MAPI obtiene un mensaje del sistema de mensajería q que no es de Exchange, realiza la conversión de direcciones para los destinatarios, convierte el mensaje en formato MAPI y, a continuación, coloca el mensaje en su carpeta MTS MTS-IN del almacén de Exchange. 2. El MTA de Exchange analiza una propiedad de mensaje mensaje especial que sólo se establece cuando el mensaje proviene del servicio SMTP. Como falta este indicador, el MTA reconoce que el mensaje no proviene del sistema SMTP local, lo que indica que es un mensaje entrante para el cual el MTA de Exchange no debe re realizar alizar el enrutamiento. El MTA transmite el mensaje directamente a la carpeta MTS-OUT MTS OUT del servicio SMTP. 3. El controlador del almacén de Exchange coloca el mensaje en la cola de envío previo y el subsistema de transporte SMTP clasifica, enruta y entrega el el mensaje, tal y como se explica en Arquitectura de enrutamiento de mensajes y en Arquitectura de transporte SMTP.

Perfiles MAPI para conectores basados en MAPI De forma similar a los clientes MAPI típicos, como Microsoft Office Outlook, los conectores basados en MAPI requieren un perfil MAPI para obtener acceso a sus buzones del conector. El perfil MAPI define la configuración utilizada por el subsistema MAPI para comunicarse con el almacén de Exchange. Los conectores basados en MAPI utilizan la función MAPILogonEx para crear el perfil necesario de forma dinámic dinámica a y sin tener un cliente MAPI en el servidor. Para obtener información detallada acerca de cómo crear perfiles MAPI de forma dinámica, consulte en Microsoft Knowledge Base el artículo 306962, "How "How to Create MAPI Profiles Without Installing Outlook OutlookCÓMO: CÓMO: Crear perfiles MAPI sin instalar Outlook".

440

Los perfiles MAPI se almacenan en el Registro bajo el subárbol HKEY_USERS. Existen varias subclaves en el servidor cabeza de puente, en función de los identificadores de seguridad (SID) de las cuentas del sistema y de usuario que procesa el servidor activo y que utilizan los administradores para iniciar sesión en el sistema. En Exchange Server 2003, los conectores basados en MAPI deben ejecutarse en el contexto de la cuenta LocalSystem, cuyo SID es S-1-5-18. En consecuencia, el perfil MAPI de un conector basado en MAPI se encuentra en la siguiente ubicación: HKEY_USERS\S-1-5-18\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles. Por ejemplo, si ha instalado e iniciado el Conector para Novell GroupWise en un servidor cabeza de puente denominado Servidor01, en la clave Profiles encontrará una subclave denominada SERVIDOR01-LME-GWISE V5.5. El perfil del conector se puede copiar en la subclave del administrador que tiene iniciada una sesión actualmente y, a continuación, utilizar una herramienta MAPI de bajo nivel para abrir el buzón del conector. Mdbvu32.exe es una herramienta MAPI de bajo nivel cuya descarga está disponible en el sitio Web Downloads for Exchange Server 2003. El archivo Information Store Viewer.doc, incluido en la herramienta, contiene información detallada acerca de cómo utilizar la herramienta Mdbvu32.exe. La figura siguiente muestra la herramienta Mdbvu32.exe en funcionamiento. En el buzón del conector pueden verse todas las carpetas del sistema.

441

Carpetas del sistema en un buzón del conector

Para obtener instrucciones acerca de cómo abrir un buzón del conector con Mdbvu32.exe, consulte Cómo abrir un buzón del conector con Mdbvu32.exe.

Conversión de mensajes Cuando un conector basado en MAPI recupera un mensaje del buzón del conector, debe convertirlo del formato MAPI al formato del sistema de mensajería de destino antes de transferirlo. De forma similar, el conector debe convertir los mensajes entrantes desde el formato del sistema de mensajería que no es de Exchange al formato MAPI antes de colocarlos en su carpeta MTS-IN. La conversión de mensajes incluye los dos procesos independientes siguientes: •

Traducción de direcciones Un conector basado en MAPI debe realizar la traducción de direcciones para el remitente del mensaje y para todos los destinatarios para que el mensaje se transmita al sistema de mensajería de destino con la información de dirección correcta en los formatos admitidos.

442

•

Traducción de mensajes La traducción de mensajes es el proceso mediante el cual un conector de puerta de enlace convierte los mensajes entre el formato de mensaje de MAPI y un formato de mensaje del sistema de mensajería que no es de Exchange. Esta traducción se basa en la información de la clase de mensaje y se realiza tanto para los mensajes entrantes como para los salientes.

Traducción de direcciones Un conector basado en MAPI debe realizar la traducción de direcciones para todos los mensajes entrantes y salientes. Cada mensaje tratado por un conector basado en MAPI tiene asociadas las tres listas de destinatarios siguientes: •

La lista original de destinatarios La lista de destinatarios del mensaje contiene todos los destinatarios a los que éste va dirigido. Puede que algunos de estos destinatarios tengan sus buzones en el servidor de Exchange local o en otro servidor de la organización de Exchange, o bien en un sistema de mensajería no asociado con el conector. En Exchange Server 2003, el subsistema de transporte SMTP procesa la lista original de destinatarios. El mismo principio se aplica a los mensajes entrantes. Un mensaje puede ir dirigido a destinatarios en otros servidores del sistema de mensajería que no es de Exchange, además de a usuarios de Exchange.

•

La lista de destinatarios enviada al MTA El subsistema de transporte SMTP transmite un mensaje al MTA sólo si el mensaje contiene destinatarios a los que el MTA debe entregar el mensaje directamente a través de llamadas a procedimiento remoto (RPC), a través de un conector X.400 o a través de un conector basado en MAPI. La lista de destinatarios que el subsistema de transporte SMTP transmite al MTA puede incluir todos los destinatarios o sólo un subconjunto de la lista original. Por ejemplo, si un usuario envía un mensaje a otro usuario del mismo servidor de Exchange y a un usuario de Lotus Notes, el subsistema de transporte SMTP entregará el mensaje al usuario de Exchange directamente, pero transmitirá otra instancia del mensaje para el usuario de Lotus Notes al MTA.

•

La lista de destinatarios del sobre de transferencia de mensajes El MTA de Exchange sólo transmite al conector basado en MAPI los mensajes que éste debe transferir. Cuando el MTA de Exchange transmite un mensaje a un conector basado en MAPI, crea un sobre de transferencia de mensajes (MTE), al que el MTA agrega el mensaje original como datos adjuntos. El MTA contiene información acerca de los destinatarios a los que el conector debe entregar el mensaje. El MTA de Exchange puede entregar un mensaje por medio de varios conectores. En este caso, un conector en concreto no se encarga de todos los destinatarios de la lista que el subsistema de transporte SMTP ha transmitido al MTA. En la tabla siguiente se enumeran los elementos del MTE.

443

Propiedades del sobre de transferencia de mensajes Propiedades

Descripción

Propiedades por mensaje

Muchas de estas propiedades son propiedades MAPI nativas que definen la fecha y la hora de llegada al conector del mensaje, el Id. de entrada del mensaje, el Id. del asunto, la información del autor y la información de seguimiento. La información de seguimiento indica la ruta del mensaje. Cada vez que el MTA de Exchange enruta un mensaje, agrega el código de país o región, el dominio de administración pública (ADMD) y el dominio de administración privada (PRMD) del dominio local al mensaje. El MTA también agrega marcas de hora y un indicador de acción que indica si el mensaje se ha expandido, redirigido, retransmitido o vuelto a enrutar. La información de seguimiento es fundamental para evitar los bucles de transferencia de mensajes.

Propiedades por destinatario

Para cada destinatario de la tabla de destinatarios del MTE, estas propiedades indican el tipo de destinatario, si se ha solicitado una notificación del estado de entrega para el destinatario, si el remitente del mensaje solicita al MTA adjuntar una dirección de reenvío física para un destinatario, si el remitente del mensaje solicita una prueba de entrega para un destinatario y los códigos de diagnóstico que pueden utilizarse como parte de un informe de no entrega (NDR).

Propiedades de los datos adjuntos

Estas propiedades MAPI identifican el tipo de objeto adjunto y especifican cómo puede obtenerse acceso al contenido de los datos adjuntos.

444

Direcciones proxy y direcciones de uso único La traducción de direcciones para el remitente y los destinatarios de los mensajes se basa en direcciones proxy. Todos los usuarios de Exchange deben disponer de una dirección proxy del tipo necesario, de forma que el conector basado en MAPI pueda realizar una búsqueda en Active Directory e insertar la dirección distinta de Exchange correcta en el sobre del mensaje del mensaje saliente. Para los mensajes entrantes, la traducción se realiza en el sentido contrario. Si no hay información de dirección para un remitente o destinatario que no es de Exchange en Active Directory, el conector basado en MAPI debe crear direcciones de uso único para estos usuarios. El término "uso único" indica que algo se utiliza sólo una vez y que no se conserva permanentemente. Las direcciones de uso único sólo se utilizan en un mensaje y no se conservan para su reutilización en otros mensajes. MAPI define el formato de dirección de uso único de la siguiente forma: Display name[Address type:E-mail address], como Ted Bremer[NOTES:Ted@Exchange]. Las direcciones de uso único también pueden utilizarse para encapsular direcciones distintas de Exchange. Por ejemplo, si un usuario envía un mensaje a un usuario de Lotus Notes y a un usuario de Internet, puede que el usuario de Internet no tenga un objeto de destinatario en Active Directory con una dirección proxy de NOTES; en este caso, el Conector para Lotus Notes no puede asignar el usuario de Internet directamente y debe encapsular la dirección SMTP en una dirección de NOTES de uso único para garantizar que todos los destinatarios especificados en el mensaje saliente de Lotus Notes aparecen en el sistema que no es de Exchange en uno de los formatos admitidos.

Problemas de asignación de direcciones Si un conector basado en MAPI no puede asignar la dirección del remitente o una dirección de destinatario, debe realizar las tareas siguientes: •

Dirección del remitente Si el conector basado en MAPI no puede convertir la dirección de Exchange de un remitente al formato que no es de Exchange, el conector deberá generar un informe de no entrega (NDR). El conector debe marcar cada destinatario del mensaje que debe tratar como "no se puede entregar". Esto se produce porque el conector no puede generar una dirección de devolución para las respuestas al mensaje. El NDR se devuelve al remitente del mensaje para indicar que no se ha podido llegar a los destinatarios.

•

Dirección del destinatario en el sistema de destino Si el conector basado en MAPI no puede determinar la dirección de un destinatario que debe tratar, deberá generar un NDR para este destinatario, para comunicar al remitente del mensaje que éste no ha llegado a todos los destinatarios.

•

Dirección del destinatario fuera del sistema de destino Si el conector basado en MAPI no puede determinar la dirección de un destinatario que no está obligado a tratar (por ejemplo, un destinatario de un sistema de mensajería no conectado por el conector),

445

no generará ará un NDR. El conector debe conservar la mayor cantidad posible de información de la dirección mediante la encapsulación de direcciones. El conector también puede cancelar el destinatario del mensaje o colocar la información del destinatario en un campo d de texto.

Conversión de mensajes Exchange Server 2003 utiliza las clases de mensajes para definir las propiedades que contiene un mensaje, el tipo de información que transmite y cómo puede tratarse. Cada clase de mensaje tiene asociado un conjunto de propiedades propiedades y, como las diferentes clases de mensajes MAPI son compatibles con conjuntos de propiedades diferentes, deben utilizarse varios algoritmos para convertir un mensaje MAPI al formato de mensaje del sistema de mensajería que no es de Exchange. De forma parecida, si el formato de mensaje del sistema de mensajería que no es de Exchange admite sus propias clases de mensajes, deben utilizarse algoritmos de traducción distintos para tratar estas clases de mensajes. Para tratar una clase de mensaje, el conector conector convierte los mensajes salientes a un formato adecuado (si el sistema de mensajería que no es de Exchange tiene una clase de mensaje análoga) y convierte los mensajes entrantes a una clase de mensaje MAPI adecuada. El conector también genera las distintas distintas clases de mensajes REPORT si un mensaje entrante o saliente las necesita. Además de tratar una clase de mensaje, el conector también convierte los datos adjuntos de los mensajes. En la tabla siguiente se enumeran las clases de mensajes que deben tratar los l conectores basados en MAPI. Clases de mensajes que deben tratar los conectores basados en MAPI Clase de mensaje

Descripción

ENVELOPE.{Clase de mensaje}

MTE que contiene el mensaje. La clase de mensaje estándar incluida en el MTE es IPM.NOTE. Este objeto de mensaje puede abrirse con la interfaz MAPI IMessage. Nota: Además de la clase de mensaje ENVELOPE, los conectores basados en MAPI deben tratar las clases de mensajes estándar, como IPM.NOTE, que se incluyen en el MTE para realizar las conversiones conversio de mensajes.

446

Clase de mensaje

Descripción

REPORT.{Clase de mensaje}.NDR

Informe de no entrega (NDR). El conector basado en MAPI genera un NDR cuando se produce un error en la entrega del mensaje. Por ejemplo, es posible que el conector no pueda determinar las direcciones del remitente del mensaje o de los destinatarios necesarios, o bien es posible que no pueda conectarse con el sistema de mensajería que no es de Exchange. O bien, puede que el sistema de mensajería que no es de Exchange devuelva un NDR porque no existe uno de los destinatarios especificados. El NDR se devuelve al remitente original y el mensaje original y su lista de destinatarios se incluyen en el NDR como datos adjuntos al mensaje incrustados.

REPORT.{Clase de mensaje}.DR

Informe de entrega. Los informes de entrega son informes opcionales que proporcionan ciertos datos sobre la entrega del mensaje original, en función del sistema de mensajería que no es de Exchange. Si el sistema de mensajería que no es de Exchange no admite informes de entrega, el conector basado en MAPI puede generar un informe de entrega cuando transfiere correctamente un mensaje al sistema de mensajería que es de Exchange. Este tipo de informe indica al remitente sólo que el sistema de mensajería que no es de Exchange ha aceptado el mensaje.

REPORT.{Clase de mensaje}.IPNRN

Notificación de recepción de nota interpersonal. Las confirmaciones de lectura son mensajes de informe opcionales, parecidos a los informes de entrega. Las confirmaciones de lectura comunican al remitente que un destinatario ha leído un mensaje. El cliente de mensajería del destinatario genera estas confirmaciones. No todos los sistemas de mensajería distintos de Exchange admiten estos informes.

447

Clase de mensaje

Descripción

REPORT.{Clase de mensaje}.IPNNRN

Notificación de no recepción de nota interpersonal. Las confirmaciones de no lectura son parecidas a las confirmaciones de lectura, pero comunican al remitente que un destinatario ha eliminado un mensaje sin abrirlo. El cliente de mensajería del destinatario genera estas confirmaciones. No todos los sistemas de mensajería distintos de Exchange admiten las confirmaciones de no entrega.

Sincronización de directorios Los conectores basados en MAPI, como el Conector para Lotus Notes y Conector para Novell GroupWise, admiten la sincronización de directorios, que establece una lista global de direcciones coherente en todos los sistemas de mensajería. Los conectores basados en MAPI también deben garantizar que la información de directorio está actualizada en ambos directorios. Por ejemplo, si cambia o elimina un usuario en el sistema de mensajería que no es de Exchange, también debe cambiar o eliminar el objeto de destinatario correspondiente en Active Directory. Por consiguiente, el conector basado en MAPI utiliza MAPI para interactuar con el almacén de Exchange, pero utiliza ADSI para interactuar con Active Directory. La sincronización de directorios se compone de dos procesos secuenciales independientes: 1. Sincronización de destinatarios de un sistema de mensajería que no es de Exchange con Active Directory. 2. Sincronización de destinatarios de Active Directory con un sistema de mensajería que no es de Exchange.

Sincronización de directorios de un sistema de mensajería que no es de Exchange con una organización de Exchange La sincronización de directorios de un sistema de mensajería que no es de Exchange con una organización de Exchange implica los siguientes procesos secuenciales: 1. Extracción de información de directorio del sistema de mensajería que no es de Exchange Los conectores basados en MAPI utilizan las interfaces de programación proporcionadas por el sistema de mensajería que no es de Exchange para extraer la información de directorio de este sistema. Por ejemplo, el Conector para Lotus Notes utiliza la API del cliente de Lotus Notes para realizar este paso y el Conector para Novell

448

GroupWise utiliza mensajes del administrador, que transmite a la puerta de enlace API de Novell GroupWise. 2. Preparación de la información de directorio para importarla a Active Directory Los conectores basados en MAPI crean los siguientes tipos de objetos de destinatario para los usuarios de sistemas distintos de Exchange en Active Directory: •

Cuentas de usuario habilitadas para enviar y recibir correo deshabilitadas Ésta es una buena opción si los usuarios de sistemas distintos de Exchange no se encuentran todavía en el entorno de Active Directory, pero estarán en él después de la migración a Exchange Server 2003.

•

Cuentas de usuario habilitadas para enviar y recibir correo habilitadas Ésta es una buena opción para los usuarios de sistemas distintos de Exchange que trabajan en el entorno de Active Directory, aunque no dispongan de un buzón de Exchange.

•

Contactos habilitados para enviar y recibir correo Ésta es una buena opción para los usuarios de sistemas distintos de Exchange que no se encuentran, ni se encontrarán nunca, en el entorno de Active Directory. Un ejemplo serían los usuarios de Internet en sistemas de mensajería externos.

Un conector basado en MAPI puede sincronizar listas de distribución como objetos de contacto. Esto resulta ventajoso, puesto que no es necesario que el conector mantenga la información de pertenencia a listas de distribución en Active Directory. No obstante, los mensajes enviados a una lista de distribución deben transferirse primero al sistema de mensajería anterior para realizar la expansión de la lista de distribución antes de entregarse a los destinatarios individuales. Si la lista de distribución contiene destinatarios que se refieren a usuarios de la organización de Exchange Server 2003, los mensajes deberán volver a la organización de Exchange Server 2003 después de la expansión de la lista de distribución. Para evitar esta transferencia de mensajes innecesaria, es posible decidir no sincronizar las listas de distribución. Si el número de listas de distribución no es excesivo, puede crear grupos habilitados para enviar y recibir correo en Active Directory y especificar directamente los miembros individuales. En este caso, Exchange Server 2003 puede realizar la expansión de las listas de distribución inmediatamente y sin la sobrecarga de tener que realizar una transferencia de mensajes adicional al sistema de mensajería anterior. Los grupos de Active Directory pueden contener cualquier tipo de objetos de destinatario, como cuentas de usuario, contactos u otros grupos. 3. Importación de la información de directorio a Active Directory Los conectores basados en MAPI utilizan ADSI para crear cuentas de usuario o contactos habilitados para enviar y recibir correo. El Conector para Lotus Notes y el Conector para Novell GroupWise importan la información de destinatarios a una unidad organizativa de destino única en Active Directory. La unidad organizativa de destino, en la que el conector basado en MAPI coloca los objetos de destinatario creados durante la sincronización de directorios para usuarios de sistemas distintos de Exchange, también se denomina contenedor de importación. Sólo puede haber un contenedor de importación.

449

Nota: La cuenta de equipo del servidor servidor cabeza de puente de Exchange Server 2003 en el que se ejecuta el conector basado en MAPI debe disponer de permisos para crear y modificar destinatarios en el contenedor de importación seleccionado. La figura siguiente ilustra el proceso general de transferencia transferencia de información de directorio desde un sistema de mensajería que no es de Exchange a una organización de Exchange. Sincronización de directorios de un sistema de mensajería que no es de Exchange con Active Directory

Sincronización de directo directorios de una organización de Exchange con un sistema de mensajería que no es de Exchange La sincronización de directorios de una organización de Exchange con un sistema de mensajería que no es de Exchange sigue el mismo principio que la sincronización de directorios rectorios de un sistema de mensajería que no es de Exchange con una organización de Exchange. El conector basado en MAPI debe extraer información acerca de las cuentas de usuario habilitadas para utilizar el buzón de una o varias unidades organizativas (denominadas nominadas también contenedores de exportación) de Active Directory mediante ADSI, procesar esta información y, a continuación, importarla, actualizarla o eliminarla en el directorio del sistema que no es de Exchange. Para que la sincronización de directorios directori de Active Directory con sistemas distintos de Exchange funcione, el sistema de mensajería que no es de Exchange debe contener información de directorio para los usuarios que se encuentran fuera del sistema de mensajería local. La mayoría de los sistemas de mensajería admiten esta funcionalidad. Por ejemplo, los usuarios de Exchange aparecen en Lotus Notes

450

como usuarios de un dominio externo de Lotus Notes. Además de la exportación desde Active Directory de cuentas de usuario habilitadas para utilizar el buzón, los conectores basados en MAPI también admiten la exportación de contactos y grupos, que aparecen como destinatarios de Exchange normales en el directorio del sistema que no es de Exchange. Nota: La cuenta de equipo del servidor cabeza de puente de de Exchange Server 2003 en el que se ejecuta el conector basado en MAPI debe disponer de permisos para obtener acceso y leer la información de destinatarios en el contenedor de exportación seleccionado. transferencia de información de directorio La figura siguiente ilustra el proceso general de transferencia desde Active Directory a un sistema de mensajería que no es de Exchange, basado en ADSI y en herramientas de información o API no Microsoft, que colocan los objetos de destinatario en el directorio del sistema que no es de Exchange. Las API y herramientas utilizadas por un conector basado en MAPI para importar directamente información a un directorio de un sistema que no es de Exchange dependen del sistema de mensajería que no es de Exchange. Por ejemplo, el Conector p para ara Lotus Notes realiza las importaciones de directorios en Lotus Notes mediante la API del cliente de Lotus Notes y el Conector para Novell GroupWise utiliza mensajes del administrador, que transmite a la puerta de enlace API de Novell GroupWise. Sincronización ización de directorios de Active Directory con un sistema de mensajería que no es de Exchange

451

Cómo abrir un buzón del conector con Mdbvu32.exe Este tema explica cómo utilizar Mdbvu32.exe, una herramienta MAPI de bajo nivel, para abrir el buzón del conector después de haber copiado el perfil del conector a la subclave del administrador que actualmente ha iniciado la sesión.

Antes de empezar Antes de realizar el procedimiento de este tema, tenga en cuenta lo siguiente: •

Mdbvu32.exe se puede descargar desde el sitio Web Downloads for Exchange Server 2003.

•

Este tema contiene información acerca de la modificación del Registro. Precaución: La modificación incorrecta del Registro puede ocasionar problemas graves que quizás requieran volver a instalar el sistema operativo. Es posible que los problemas derivados de una modificación incorrecta del Registro no se puedan resolver. Antes de modificar el Registro, se recomienda realizar una cop copia de seguridad de todos los datos importantes.

Procedimiento Para abrir un buzón del conector con Mdbvu32.exe 1. Asegúrese de que se ha iniciado el conector basado en MAPI. 2. Abra Regedit y busque la subclave del conector bajo HKEY_USERS HKEY_USERS\S-1-518\Software\Microsoft Microsoft\Windows NT\CurrentVersion\Windows Windows Messaging Subsystem\Profiles. Profiles. 3. Haga clic con el botón secundario del mouse (ratón) en la clave que representa el perfil MAPI del conector y seleccione Exportar.. Por ejemplo, exporte la clave SERVIDOR01-LME LME-GWISE V5.5 si desea examinar las colas de mensajes del Conector para Novell GroupWise. 4. Exporte la clave a un archivo .reg y, a continuación, cierre el Editor del Registro. 5. Abra el archivo .reg exportado en el Bloc de notas y reemplace todas las entradas entrad HKEY_USERS\S S-1-5-18 por HKEY_CURRENT_USER. 6. Guarde los cambios y cierre el Bloc de notas. 7. Haga doble clic en el archivo .reg y, en el cuadro de diálogo que le comunica que se dispone a importar la configuración al Registro, haga clic en Sí.. En el cuadro c de diálogo que le comunica que este paso ha finalizado, haga clic en Aceptar. 8. Asegúrese de que la cuenta de administrador con la que trabaja no es miembro de

452

los grupos Administradores de la organización o Administradores de dominio. Agregue temporalmente ralmente su cuenta al grupo Servidores de dominio de Exchange para obtener permisos de acceso al buzón del conector. 9. Inicie Mdbvu32.exe y, en el cuadro de diálogo MAPILogonEx,, haga clic en Aceptar. 10. En el cuadro de diálogo Elegir perfil, seleccione ell perfil MAPI del conector, como SERVIDOR01-LME LME-GWISE V5.5 y, a continuación, haga clic en Aceptar. 11. En el menú MDB, MDB seleccione OpenMessageStore.. En el cuadro de diálogo Select Message Store To Open Open,, compruebe que el conector basado en MAPI está seleccionado onado y, a continuación, haga clic en Abrir. 12. En el menú MDB, MDB seleccione Open Root Folder y, en el cuadro de diálogo MAPI_FOLDER - Root, haga doble clic en la carpeta del sistema que desea examinar, como MTS-IN. 13. Cierre Mdbvu32.exe y quite su cuenta del grupo Servidores de dominio de Exchange.

Arquitectura del Conector para Lotus Notes El Conector para Lotus Notes puede conectar una organización de Exchange con una red de Lotus Notes y Lotus Domino. Exchange Server 2003 Service Pack 1 (SP1) admite las l versiones 3 y 4 de Lotus Notes y las versiones 4.5, 4.6, 5 y 6 de Lotus Domino. Este conector basado en MAPI utiliza la API del cliente de Lotus Notes para comunicarse con un servidor de Lotus Notes o Lotus Domino. Para realizar la comunicación es necesario neces disponer de un cliente de Lotus Notes en el servidor del conector. Debe disponer de una licencia de Lotus Development para utilizar el software de cliente. Para obtener información acerca de cómo configurar el Conector para Lotus Notes, consulte la Exchange Server 2003 Interoperability and Migration Guide Guide. Nota: Como el Conector para Lotus Notes utiliza la API del cliente de Lotus Notes para comunicarse con un servidor de Lotus Notes o Lotus Domino, el conector requiere un Id. de Notes dedicado que disponga de permisos para obtener acceso a las bases de datos de Lotus Notes. En la tabla siguiente se enumeran los componentes importantes del Conector para Lotus Notes.

453

Componentes del Conector para Lotus Notes Componente

Descripción

Buzón del conector

Como conector basado en MAPI, las colas de mensajes del Conector para Lotus Notes se encuentran en un buzón del conector ubicado en el almacén de buzones predeterminado del servidor cabeza de puente. El nombre del buzón es Conector para Lotus Notes (<nombre de servidor>), como Conector para Lotus Notes (SERVIDOR01).

454

Componente

Descripción

Servicio de conector

El archivo ejecutable principal del servicio Conector para Lotus Notes se denomina Dispatch.exe. Es un controlador de procesos que se inicia mediante los parámetros cexchconn.ini -nLME-NOTES pCONTROL-SERVICE -l"C:\Archivos de programa\Exchsrvr\bin" -vLME-NOTES para enviar las diferentes tareas de transferencia de mensajes y sincronización de directorios a otros procesos, en función de la configuración especificada en un archivo denominado Exchconn.ini. Exchconn.ini se crea automáticamente, como parte de la instalación y configuración del conector. Los componentes siguientes participan en el tratamiento de la información: •

Dxanotes.dll Este componente comprueba si hay actualizaciones de destinatarios en el directorio de Lotus Domino. Este componente también transfiere los cambios en la información de dirección de Exchange a la libreta de direcciones de Lotus Domino o Lotus Notes.

•

Dxamex.dll Este componente comprueba si hay actualizaciones de destinatarios en Active Directory. Este componente también transfiere los cambios en la información de dirección de Lotus Domino o Lotus Notes a Active Directory.

•

Lsdxa.exe Administrador de intercambio de directorios que controla tanto Dxanotes.dll como Dxamex.dll.

•

Lsmexin.exe Este componente obtiene los mensajes convertidos de la carpeta READYIN en el buzón del conector, comprueba la validez de los destinatarios y coloca los mensajes en la cola MTS-IN.

•

Lsmexnts.exe Este componente obtiene mensajes de la carpeta READYOUT en el buzón del conector, los convierte de MAPI al formato de Lotus Notes y los copia en la base de datos mail.box del servidor de Domino.

•

Lsmexout.exe Este componente

455

Componente

Descripción

Bases de datos de Lotus Notes

El Conector para Lotus Notes utiliza las siguientes bases de datos en el servidor cabeza de puente de Lotus Notes y Domino: •

Exchange.box Buzón del conector en Lotus Notes y Domino que almacena mensajes que se enrutan desde Lotus Domino a Exchange. Debe crear un documento de dominio externo para registrar la organización de Exchange como dominio externo en el directorio de Lotus Domino y especificar el nombre del buzón del conector en este documento. Todo el correo enrutado desde Lotus Domino a Exchange Server 2003 se enviará al buzón del conector, desde el cual el Conector para Lotus Notes lo recuperará. El conector necesita permisos de administrador con derechos para eliminar para recoger correo de esta base de datos y ejecutar operaciones de mantenimiento de la base de datos.

•

Exchange.bad Buzón del conector para correo con errores que el Conector para Lotus Notes utiliza para almacenar los mensajes que no pueden transferirse a Exchange Server 2003. El conector necesita permisos de administrador con derechos para eliminar para mover el correo con errores a esta base de datos y ejecutar operaciones de mantenimiento de la base de datos.

•

Mail.box Buzón de servidor del servidor de Lotus Domino. El Conector para Lotus Notes utiliza este buzón para depositar todos los mensajes de Exchange Server 2003 que van dirigidos a buzones de Lotus Domino. El conector necesita permisos de depositante para colocar mensajes de correo y realizar operaciones de mantenimiento de la base de datos.

•

Names.nsf Archivo de directorio predeterminado de Lotus Domino que el Conector para Lotus Notes utiliza para la sincronización de directorios. Se pueden especificar libretas de direcciones diferentes o adicionales para los

456

Componente

Descripción

Almacén del conector

El Conector para Lotus Notes utiliza una estructura de carpetas en el sistema de archivos para conservar los archivos de control que se utilizan durante la sincronización de directorios. Los archivos de control son archivos de definición del esquema y archivos de reglas de asignación que determinan cómo se asignan los atributos de un directorio a otro. El almacén del conector se encuentra en el directorio \Archivos de programa\Exchrvr\Conndata. En el Bloc de notas pueden modificarse los siguientes archivos de definición del esquema y de reglas de asignación para determinar cómo se asignan los atributos de un directorio a otro: •

AMAP.TBLen el subdirectorio \Dxamex Define los atributos del buzón de Exchange que se sincronizarán.

•

AMAP.TBLen el subdirectorio \Dxanotes Define los atributos del buzón de Lotus Notes que se sincronizarán.

•

MAPMEX.TBLen el subdirectorio \Dxanotes Determina la asignación de atributos de Exchange Server 2003 a Lotus Notes.

•

MAPNOTES.TBLen el subdirectorio \Dxamex Determina la asignación de atributos de Lotus Notes a Exchange Server 2003.

Para obtener más información acerca de cómo personalizar la sincronización de directorios entre Lotus Domino and Exchange Server 2003, consulte el artículo 180517 de Microsoft Knowledge Base "XFOR: Customizing Directory Synchronization Between Exchange and Notes".

457

Componente

Descripción

Configuración del Registro

La configuración del Conector para Lotus Notes se almacena en la siguiente ubicación del Registro: HKEY_LOCAL_MACHINE\SYSTEM\Current ControlSet\Services\LME-NOTES.

DLL de generación de direcciones proxy

La DLL de generación de direcciones proxy del Conector para Lotus Notes se denomina Ntspxgen.dll y se encuentra en el directorio \Archivos de programa\Exchsrvr\address\notes\i386.

Objeto addrType

El nombre común del objeto addrType del Conector para Lotus Notes en Active Directory es NOTES:i386.

458

Componente

Descripción

Objeto msExchConnector

El objeto msExchConnector del Conector para Lotus Notes, que se encuentra en la partición del directorio de configuración de Active Directory, almacena la mayoría de las opciones de configuración del conector. Los siguientes atributos son específicos de la clase de objeto msExchNotesConnector, derivada de las clases de objetos msExchConnector y mailGateway: •

exportCustomRecipients Especifica si los contactos habilitados para enviar y recibir correo se propagan a Lotus Notes mediante la sincronización de directorios.

• msExchServer1AlwaysCreateAs Especifica cómo se sincronizan los objetos X.500. •

msExchDeliveryOrder Especifica el orden de procesamiento de los mensajes en la cola del conector. Las opciones son FIFO, Prioridad (predeterminada) y Tamaño.

•

msExchExportDLs Especifica si los grupos de distribución habilitados para enviar y recibir correo se propagan a Lotus Notes mediante la sincronización de directorios.

•

msExchPartnerLanguage Especifica el idioma (página de códigos) del servidor de Lotus Notes y Domino conectado.

•

msExchDirsyncSchedule Especifica cuándo se realiza automáticamente la sincronización de directorios.

•

msExchDirsyncStyle Especifica si se realiza una sincronización de directorios completa o incremental.

•

msExchNotesNotesServer Especifica el nombre del servidor de Lotus Notes y Domino (en formato Notes) que el conector utiliza como servidor cabeza de puente que no es de Exchange.

• msExchNotesForeignDomain Esp ecifica el nombre del dominio no Exchange de Lotus Notes que representa

459

Componente

Descripción

Complemento administrativo

El complemento de extensión para el Conector para Lotus Notes se denomina Conector de Exchange para Notes. Este complemento amplía el nodo para el conector, que se encuentra en el Administrador del sistema de Exchange, bajo /Grupos administrativos//Grupos de enrutamiento//Conectores.

Transferencia de mensajes La figura siguiente ilustra el proceso utilizado para enviar mensajes desde Exchange Server 2003 a Lotus Domino. Envío de mensajes desde Exchange Server 2003 a Lotus Domino

El proceso utilizado para la transferencia de mensajes entre Exchange Server 2003 y Lotus Domino se compone de los tres pasos siguientes: 1. Exchange 2003 determina que el destinatario es un usuario de Lotus Domino (en función de la dirección de destino del usuario) y envía el mensaje al agente de transferencia de mensajes (MTA). 2. El MTA entrega el mensaje al directorio MTS-OUT, desde el cual el proceso LSMEXOUT lo recupera, convierte la dirección de una dirección basada en X.400 a una dirección de Lotus Domino y, a continuación, lo entrega al directorio READYOUT. 3. El proceso LSMEXNTS convierte el mensaje al formato de Lotus Domino y lo entrega para su enrutamiento al archivo mail.box del servidor de Lotus Domino.

460

La figura siguiente ilustra el proceso utilizado para enviar mensajes desde Lotus Domino a Exchange Server 2003. Envío de mensajes desde Lotus Domino a Exchange Server 2003

El proceso utilizado para la transferencia de mensajes entre Lotus Domino y Exchange Server 2003 se compone de los tres pasos siguientes: 1. Lotus Domino recibe un mensaje enviado a un usuario de Exchange Server 2003 por un usuario de Lotus Notes y lo coloca en la base de datos mail.box del enrutador de correo. El enrutador de correo identifica el mensaje enviado a Exchange Server 2003 y, a continuación, lo deposita en el archivo exchange.box. 2. El Conector para Lotus Notes recupera el mensaje de la base de datos exchange.box, lo convierte al formato de Exchange Server 2003 mediante el proceso LSNTSMEX y, a continuación, lo entrega a la carpeta READYIN ubicada en el servidor en el que se ejecuta Exchange Server 2003. 3. El proceso LSMEXIN recibe el mensaje, convierte la dirección de una dirección de Lotus Domino a una dirección X.400 y lo coloca en la carpeta MTS-IN. A continuación, el MTA de Exchange procesa el mensaje de la carpeta MTS-IN y lo coloca en la carpeta MTSOUT del servicio SMTP (Protocolo simple de transferencia de correo), desde la cual finalmente se enruta.

Conversión de mensajes Exchange Server 2003 y Lotus Domino admiten varios tipos de mensaje, incluidos convocatorias de reunión, tareas, solicitudes de tareas y correo electrónico. El Conector para Lotus Notes admite la asignación de varios tipos de mensaje entre Exchange Server 2003 y Lotus Domino. No obstante, la conversión de un formato a otro puede provocar algunos cambios en las características de los mensajes. Por ejemplo, ciertas características de un mensaje de Lotus Domino, como la fecha de caducidad, se pierden cuando el mensaje se convierte al formato de Exchange. Los mensajes que no pueden asignarse a un tipo de

461

mensaje correspondiente en el dominio de destino se convierten en men mensajes sajes de correo electrónico. Nota: El Conector para Lotus Notes no está diseñado para convertir mensajes en formato HTML. Si tiene previsto enrutar mensajes en formato HTML entre Exchange Server 2003 y Lotus Notes (por ejemplo, porque desea enrutar todos los mensajes de y para destinatarios de Internet a través de Exchange Server 2003), puede implementar un conector SMTP en lugar del Conector para Lotus Notes. La tabla siguiente ilustra cómo se convierten diferentes tipos de mensaje entre Exchange Server 2003 y Lotus Domino. Conversión de mensajes entre Lotus Domino y Exchange Server 2003 Característica de

Característica de

Lotus Domino a

Exchange Server 2003

Exchange Server 2003

Lotus Domino

Exchange Server 2003

a Lotus Domino

Mensajes de correo electrónico

Mensajes de correo electrónico

Sí

Sí

Confirmación de entrega de mensaje

Confirmación de entrega de mensaje

Sí

Sí

Confirmación de lectura de mensaje

Confirmación de lectura de mensaje

Sí

Sí

Informe de no entrega

Informe de no entrega

Sí

Sí

Importancia

Importancia

Sí

Sí

Botones de votación

Sin característica

No

No

Objeto OLE incrustado

Objeto OLE incrustado

Sí

Sí

Archivo adjunto incrustado

Archivo adjunto incrustado

Sí

Sí

Fecha de caducidad del mensaje

Fecha de caducidad del mensaje

No

No

Sin característica

Responder antes del

No

No

Dirección URL de sitio Web

Dirección URL de sitio Web

Sí

Sí

Sin característica

Zona activa de dirección URL

No

No

462

Característica de

Característica de

Lotus Domino a

Exchange Server 2003

Exchange Server 2003

Lotus Domino

Exchange Server 2003

a Lotus Domino

Convocatorias de reunión

Citas

Sí

Sí

Reunión aceptada

Reunión aceptada

Sí

Sí

Reunión rechazada

Reunión rechazada

Sí

Sí

Reunión aceptada provisionalmente

Reunión aceptada

Aparece como aceptada

Aparece como aceptada

Confirmación de lectura de convocatoria de reunión

Confirmación de lectura de convocatoria de reunión

Sí

Sí

Entrega de convocatoria de reunión

Entrega de convocatoria de reunión

Sí

Sí

Actualizaciones de reuniones

Actualizaciones de reuniones

Aparecen como nuevas convocatorias de reunión que contienen la palabra "Actualizada" en la línea Asunto

Aparecen como nuevas convocatorias de reunión que contienen la palabra "Actualizada" en la línea Asunto

Cancelación de reunión

Cancelación de reunión

Sí

Sí

Solicitudes de tareas

Tareas

Las solicitudes de tareas aparecen como mensajes de correo electrónico o tareas

Las solicitudes de tareas aparecen como mensajes de correo electrónico

Convocatorias de reunión con una duración de todo el día

Sin característica

No

Aparecen como reuniones con la medianoche como hora de inicio y de fin

Sin característica

Mensajes telefónicos

Aparecen como mensajes de correo electrónico

No

463

Característica de

Característica de

Lotus Domino a

Exchange Server 2003

Exchange Server 2003

Lotus Domino

Exchange Server 2003

a Lotus Domino

Otros mensajes

Otros mensajes

De forma predeterminada, mensajes de correo electrónico

De forma predeterminada, mensajes de correo electrónico

Nota: El Conector para Lotus Notes no admite mensajes mensajes firmados o cifrados.

Conversión del tipo de mensaje de correo electrónico Los mensajes de correo electrónico cuyo origen se encuentra en Exchange o Lotus Domino se convierten al formato del sistema de mensajería de destino. El Conector para Lotus Notes también realiza el seguimiento de la entrega de mensajes mediante informes de confirmación de entrega, confirmaciones de lectura e informes de no entrega. El Conector para Lotus Notes trata las convocatorias de reunión y los mensajes telefónicos de la siguiente forma: •

Convocatorias de reunión y citas El Conector para Lotus Notes sincroniza las convocatorias de reunión de Exchange y las citas de Lotus Domino. Las convocatorias de reunión actualizadas se identifican como actualizadas en la línea de asun asunto. Debido a una limitación en la API de Lotus Domino, las convocatorias de reunión enviadas por usuarios de Exchange Server 2003 a usuarios de Lotus Domino no se actualizan automáticamente en Lotus Domino. El usuario debe actualizarlas manualmente.

•

Convocatorias ocatorias de reunión con una duración de todo el día Las convocatorias de reunión con una duración de todo el día generadas en Exchange Server 2003 aparecen con una hora de inicio y de fin de medianoche.

•

Mensajes telefónicos Los mensajes telefónicos de Lotus Notes aparecen como mensajes de correo electrónico en Exchange Server 2003.

Asignación de propiedades de mensajes de correo electrónico Los objetos incrustados en mensajes enviados por el cliente de Exchange Server 2003 (Outlook) al cliente de Lotus Lotus Domino (Lotus Notes) se convierten en datos adjuntos. Los objetos incrustados aparecen siempre como datos adjuntos al mensaje principal, independientemente de su posición en la secuencia original. La tabla siguiente ilustra las características de mensaj mensajes es de correo electrónico de Lotus Notes que se convierten correctamente a Microsoft Outlook.

464

Conversión de mensajes de correo electrónico entre Lotus Notes y Microsoft Outlook Lotus Notes

Microsoft Outlook

Tamaño

Se convierte correctamente.

Color

Se convierte correctamente.

Negrita

Se convierte correctamente.

Subrayado

Se convierte correctamente.

Cursiva

Se convierte correctamente.

Tachado

Se convierte correctamente.

Tablas

Se convierten correctamente si se utiliza Microsoft Word como editor de correo electrónico principal en Outlook, pero se pierde el formato. No se convierten correctamente si Outlook es el editor de correo electrónico.

Objetos OLE incrustados, incluyendo gráficos Se convierten correctamente y se pueden modificar. Doble tachado

Se omiten.

Superíndice

Se omiten.

Subíndice

Se omiten.

Sombra

Se omiten.

Esquema

Se convierte a cursiva.

Relieve

Se omiten.

Grabado

Se omiten.

Versales Se omite.

Se omiten.

Se omiten.

Se omiten.

Se omite.

Se omiten.

Se omite.

Oculto Omitido; el texto es visible.

Subrayado no sencillo

Se omiten.

Mapas de bits no incrustados como objetos OLE

No se migran; se pierde el formato.

Viñetas

Se omiten.

465

Sincronización de directorios En la figura siguiente se representa la conexión de directorios entre Exchange Server 2003 y Lotus Domino. Como se menciona en la tabla anterior, el proceso Lsdxa.exe se encarga de controlar los procesos reales de sincronización de directorios Dxamex.dll y Dxanotes.dll. Lsdxa.exe se inicia automáticamente al iniciar el serv servicio icio Conector de Microsoft Exchange para Lotus Notes. Para obtener información acerca de cómo configurar la sincronización de directorios, consulte la Exchange Server 2003 Interoperability and Migration ation Guide. Guide Nota: El Conector para Lotus Notes crea contactos habilitados para enviar y recibir correo en Active Directory para destinatarios del sistema de mensajería Lotus Notes. La primera parte de la dirección legacyExchangeDN (es decir, la dirección X.500 del usuario de Exchange en formato de Exchange 5.5) coincide con la legacyExchangeDN del conector. La primera parte es la parte de la dirección X.500 que identifica el grupo administrativo del conector (es decir, /O=<nombre de la organización>/OU=<nombre ón>/OU=<nombre del grupo administrativo>). Sincronización de directorios entre Lotus Domino y Exchange Server 2003

En la parte de Exchange, Dxamex.dll se comunica con Active Directory a través de ADSI para extraer la información de destinatarios de los contenedores de exportación especificados en la configuración del conector. Dxamex.dll asigna los atributos de los destinatarios tal y como se define en Amap.tbl y Mapmex.tbl y coloca los resultados en un archivo temporal denominado Dxanotes.text en format formato o de intercambio de mensajes (MIF) en el directorio \Archivos Archivos de programa programa\Exchsrvr\Conndata\Temp. Temp. A continuación, Dxanotes.dll analiza el archivo Dxanotes.txt, procesa las direcciones y las coloca en el directorio de destino del servidor de Lotus Domino. Para Para comunicarse con Lotus Domino, Dxanotes.dll utiliza la API del cliente de Lotus Notes. La lista siguiente es un ejemplo de un archivo Dxanotes.txt: Load A FULLNAME:Administrator MAILDOMAIN:Exchange

466

COMPANY: DEPARTMENT: FIRSTNAME: LASTNAME:Administrator LOCATION: SHORTNAME:Administrator UNID:DBC07527-91C1F649-8427525F-902428E2 DN:CN=Administrator,CN=Users,DC=contoso,DC=com USNCreated:8194 Initials: Title: Phone: MobilePhn: Fax: Resource: CALDOM:Exchange MAILSRV: EndOfBuffer

Dxanotes.dll también realiza la sincronización de directorios de Lotus Notes a Active Directory. El proceso utiliza la API del cliente de Lotus Notes para leer el directorio de Lotus Domino. Dxanotes.dll asigna los atributos de los destinatarios tal y como se define en Amap.tbl y Mapnotes.tbl y copia la información de los destinatarios en el archivo Dxamex.txt del directorio \Archivos de programa\Exchsrvr\Conndata\Temp. Dxamex.dll procesa el archivo Dxamex.txt y coloca la información de los destinatarios en el contenedor de importación especificado en la configuración del conector. La lista siguiente es un ejemplo de un archivo Dxamex.txt: Load U DN:admin TA:NOTES:admin@Notes ALIAS:admin NAME:admin FULLNAME:admin FIRSTNAME: Initials: LASTNAME:admin NOTESADDR:admin@Notes UNID:4a12766d-8684ea55-3e551cde-3bac7ae9 COMPANY: DEPARTMENT: TITLE: OFFICE: PHONE: FAX: MOBILEPHN: USNCREATED: EndOfBuffer

467

Arquitectura del Conector para Novell GroupWise El Conector para Novell GroupWise admite la transferencia bidireccional de mensajes y la sincronización de directorios entre una organización de Exchange y un entorno Novell GroupWise. Las versiones 4.2, 5.0 y 5.5 de Novell GroupWise son compatibles. Este conector basado en MAPI utiliza la puerta de enlace API de Novell GroupWise para comunicarse con Novell GroupWise. Para obtener información acerca de cómo configurar el Conector para Novell GroupWise, consulte la Exchange Server 2003 Interoperability and Migration Guide. Nota: Oficialmente, Microsoft no admite Novell GroupWise 6.0 o posterior. No obstante, como las tecnologías subyacentes son las mismas que las de versiones anteriores, los Servicios ios de soporte técnico de Microsoft ofrecen una compatibilidad "con un esfuerzo comercial razonable". Una alternativa al uso del Conector para Novell GroupWise para interoperabilidad y sincronización de directorios es el uso de la Puerta de enlace de Novell Novell GroupWise para Microsoft Exchange. Si tiene previsto migrar de Novell GroupWise 6.0 o posterior a Exchange Server 2003, debería utilizar este conector de Novell. En la tabla siguiente se enumeran los componentes importantes del Conector para Novell GroupWise. Componentes del Conector para Novell GroupWise Componente

Descripción

Buzón del conector

Como conector basado en MAPI, las colas de mensajes del Conector para Novell GroupWise se encuentran en un buzón del conector ubicado en el almacén de buzones predeterminado redeterminado del servidor cabeza de puente. El nombre del buzón es Conector para Novell GroupWise (<nombre (< de servidor>), >), como Conector para Novell GroupWise (SERVIDOR01).

468

Componente

Descripción

Servicio de conector

El servicio Conector para Novell GroupWise utiliza el mismo archivo ejecutable principal denominado Dispatch.exe que el Conector para Lotus Notes. Esto es posible porque Dispatch.exe no realiza el procesamiento real de los mensajes. Dispatch.exe se inicia con los parámetros -cexchconn.ini -nLMEGWISE -pCONTROL-SERVICE l"C:\Archivos de programa\Exchsrvr\bin" vLME-GWISE y envía los procesos necesarios para llevar a cabo las tareas de transferencia de mensajes y sincronización de directorios con Novell GroupWise. Dispatch.exe inicia los procesos reales en función de las opciones especificadas en el archivo Exchconn.ini. Exchconn.ini se crea automáticamente, como parte de la instalación y configuración del conector. Tres de los procesos activos del conector son los mismos que los del Conector para Lotus Notes: Lsmexin.exe, Lsmexout.exe y Dxamex.dll, que se comunican con Exchange Server 2003. Los componentes específicos del Conector para Novell GroupWise son Mex2gw.exe, Gw2mex.exe y Dxagwise.dll. Los componentes siguientes participan en el tratamiento de la información: •

Dxagwise.dll Este componente comprueba si hay actualizaciones de destinatarios en el directorio de Novell GroupWise. Este componente también transfiere los cambios en la información de dirección de Exchange al directorio de Novell GroupWise.

•

Dxamex.dll Este componente comprueba si hay actualizaciones de destinatarios en Active Directory. Este componente también transfiere los cambios en la información de dirección de Novell GroupWise a Active Directory.

•

Lsdxa.exe Administrador de intercambio de directorios que controla tanto Dxagwise.dll como Dxamex.dll.

•

Lsmexin.exe Este componente obtiene los mensajes convertidos de la carpeta READYIN en el buzón del conector,

469

Componente

Descripción

Servicio Enrutador de Exchange para Novell GroupWise

El Conector para Novell GroupWise utiliza un servicio denominado Enrutador de Microsoft Exchange para Novell GroupWise (Gwrouter.exe), que transfiere los mensajes en forma de archivos de encabezado y cuerpo entre el almacén del conector y una puerta de enlace API de Novell GroupWise.

470

Componente

Descripción

Almacén del conector

El almacén del conector, ubicado en el directorio \Archivos de programa\Exchrvr\Conndata, actúa como medio de comunicación entre el Conector para Novell GroupWise y el Enrutador para Novell GroupWise. El Conector para Novell GroupWise utiliza los siguientes subdirectorios del almacén del conector: •

\GwrouterEste directorio tiene más subdirectorios sondeados por el Enrutador para Novell GroupWise. Los subdirectorios son repositorios temporales para los archivos de encabezado de mensaje, con la extensión .api, y para los archivos de cuerpo del mensaje y datos adjuntos, con la extensión .bdy, que el Enrutador para Novell GroupWise transfiere de y a la puerta de enlace API de Novell GroupWise. Los archivos de encabezado y cuerpo son archivos de texto basados en palabras clave que la puerta de enlace API de Novell GroupWise puede convertir en mensajes en formato de Novell GroupWise. El directorio \Gwrouter tiene los siguientes subdirectorios: •

\Archive Este directorio sólo existe cuando se ha activado el archivo de datos para el Conector para Novell GroupWise. Para habilitar el archivo de datos, debe configurar el REG_DWORD parámetro del Registro llamado Archive que se encuentra en la siguiente ubicación: HKEY_LOCAL_MACHINE\SYSTEM\CurrentC ontrolSet\Services\LMEGWISE\Parameters.

Debe asignar a este parámetro el valor 0x1. A continuación, Exchange 2003 crea el directorio \Archive en el directorio \Archivos de programa\Exchsrvr\Conndata\Gwrout er al reiniciar el servicio Enrutador de Exchange para Novell GroupWise. El

471

Componente

Descripción

Puerta de enlace API de Novell GroupWise

El Conector para Novell GroupWise utiliza la puerta de enlace API de Novell GroupWise para comunicarse con el entorno Novell GroupWise. Es una puerta de enlace de GroupWise universal que utiliza archivos de texto basados en palabras clave para comunicarse con sistemas de mensajería distintos de Novell Groupwise, como Exchange Server 2003. La puerta de enlace API de Novell GroupWise mantiene una estructura de carpetas con los siguientes directorios: •

\API_IN Recibe archivos de encabezado de mensaje entrantes de sistemas distintos de GroupWise

•

\API_OUT Contiene los archivos de encabezado de mensaje salientes para sistemas distintos de GroupWise

•

\ATT_IN Recibe archivos de cuerpo de mensaje y datos adjuntos entrantes de sistemas distintos de GroupWise

•

\ATT_OUT Contiene archivos de cuerpo de mensaje y datos adjuntos salientes para sistemas distintos de GroupWise

•

\WPCSIN La cola entrante del MTA de GroupWise, en la que se colocan los mensajes entrantes después de su procesamiento mediante la puerta de enlace API

•

\WPCSOUT La cola saliente del MTA de GroupWise, en la que se ubican los mensajes salientes antes de convertirse en archivos de texto basados en palabras clave y colocarse en API_OUT y ATT_OUT mediante la puerta de enlace API

472

Componente

Descripción

Configuración del Registro

La configuración del Conector para Novell GroupWise se almacena en la siguiente ubicación del Registro: HKEY_LOCAL_MACHINE\SYSTEM\Curren tControlSet\Services\LME-GWISE.

DLL de generación de direcciones proxy

La DLL de generación de direcciones proxy del Conector para Novell GroupWise se denomina Gwxpxgen.dll y se encuentra en el directorio \Archivos de programa\Exchsrvr\address\gwise\i386.

Objeto addrType

El nombre común del objeto addrType del Conector para Novell GroupWise en Active Directory es GWISE:i386.

473

Componente

Descripción

Objeto msExchConnector

El objeto msExchConnector del Conector para Novell GroupWise, que se encuentra en la partición del directorio de configuración de Active Directory, almacena la mayoría de las opciones de configuración del conector. Los siguientes atributos son específicos de la clase de objeto msExchGroupWiseConnector, derivada de las clases de objetos msExchConnector y mailGateway: •

exportCustomRecipients Especifica si los contactos habilitados para enviar y recibir correo se propagan a Novell GroupWise mediante la sincronización de directorios.

• msExchServer1AlwaysCreateAs Especifica cómo se sincronizan los objetos X.500. •

msExchDeliveryOrder Especifica el orden de procesamiento de los mensajes en la cola del conector. Las opciones son FIFO, Prioridad (predeterminada) y Tamaño.

•

msExchExportDLs Especifica si los grupos de distribución habilitados para enviar y recibir correo se propagan a Novell GroupWise mediante la sincronización de directorios.

•

msExchPartnerLanguage Especifica el idioma (página de códigos) de la oficina de correos de Novell GroupWise conectada.

•

msExchDirsyncSchedule Especifica cuándo se realiza automáticamente la sincronización de directorios.

•

msExchDirsyncStyle Especifica si se realiza una sincronización de directorios completa o incremental.

• msExchGWiseAPIGatewayPath E specifica la ruta de acceso al directorio de la puerta de enlace API de Novell GroupWise. •

msExchGWiseUserId Especifica el nombre de la cuenta utilizada por el

474

Componente

Descripción

Complemento administrativo

El complemento de extensión para el Conector para Novell GroupWise se denomina Conector de Exchange para GroupWise. Este complemento amplía el nodo para el conector, que se encuentra en el Administrador del sistema de Exchange, bajo /Grupos administrativos//Grupos de enrutamiento//Conectores.

Transferencia de mensajes La figura siguiente ilustra el proceso utilizado para enviar mensajes desde Exchange Server 2003 a Novell GroupWise.

475

Envío de mensajes desde Exchange Server 2003 a Novell GroupWise

El proceso utilizado para la transferencia de mensajes entre Exchange Server 2003 y Novell GroupWise se compone de los cuatro pasos siguientes: 1. Exchange Server 2003 determina que el destinatario es un usuario de Novell GroupWise (en función de la dirección de destino del usuario) y envía el mensaje al MTA de Exchange. 2. El MTA entrega el mensaje al directorio MTS-OUT, desde el cual el proceso Lsmexout.exe lo recupera, comprueba Active Directory, reemplaza la información de destinatarios de destino con las direcciones de GroupWise correspondientes y, a continuación, lo entrega al directorio READYOUT. 3. El proceso Mex2gw.exe convierte el mensaje al formato de Novell GroupWise antes de copiarlo como archivos de encabezado y cuerpo en el almacén del conector que se encuentra en el servidor en el que se ejecuta Exchange Server 2003.

476

Nota: Los archivos de encabezado y cuerpo son archivos de texto basados en palabras clave que utilizados por la puerta de enlace API de GroupWise para comunicarse con el Conector para Novell GroupWise. Puede utilizar un editor de texto, como el Bloc de notas de Microsoft, para leer y escribir archivos de texto basados en palabras clave en la estructura de directorios de la puerta de enlace API. 4. El servicio Enrutador de Exchange para Novell GroupWise (Gwrouter.exe) coloca el mensaje en los directorios API_IN y ATT_IN de la puerta de enlace API de Novell GroupWise. La puerta de enlace trabaja junto con un MTA de Novell GroupWise para realizar la entrega en la organización de GroupWise. La figura siguiente ilustra el proceso proceso utilizado para enviar mensajes desde Novell GroupWise a Exchange Server 2003. Envío de mensajes desde Novell GroupWise a Exchange Server 2003

477

El proceso utilizado para la transferencia de mensajes desde Novell GroupWise a Exchange Server 2003 se compone de los cuatro pasos siguientes: 1. El servicio Enrutador para Novell GroupWise obtiene el mensaje de los directorios API_OUT y ATT_OUT de la puerta de enlace API de Novell GroupWise en forma de archivos de encabezado y cuerpo y los coloca en el almacén del conector. 2. El proceso Gw2mex.exe convierte los archivos de encabezado y cuerpo en un mensaje en formato de Exchange Server 2003 antes de colocarlo en la carpeta READYIN. 3. El proceso Lsmexin.exe obtiene el mensaje convertido de la carpeta READYIN, comprueba la validez del destinatario (y convierte la dirección al formato de Exchange, si es necesario) y entrega el mensaje a la carpeta MTS-IN. 4. A continuación, el MTA de Exchange procesa el mensaje de la carpeta MTS-IN y lo coloca en la carpeta MTS-OUT del servicio SMTP, desde la cual finalmente se enruta a su destino en la organización de Exchange.

Conversión de mensajes Novell GroupWise admite varios tipos de mensaje específicos, como mensajes de correo electrónico, citas, notas, tareas, formularios, presentaciones y documentos. Los tipos de mensaje MAPI se asignan a los tipos de mensaje correspondientes en Novell GroupWise siempre que resulta posible. Es decir, los mensajes de correo electrónico aparecen como mensajes de correo electrónico, las convocatorias de reunión como citas, etc. Los tipos de mensaje no admitidos en Exchange Server 2003, como los mensajes telefónicos de Novell GroupWise, se convierten en mensajes de correo electrónico normales. El Conector para Novell GroupWise puede realizar el seguimiento de los informes de confirmación de entrega, las confirmaciones de lectura y los informes de no entrega. Conversión de mensajes entre Novell GroupWise y Exchange Server 2003 Característica de

Característica de

GroupWise a

Exchange Server 2003

Exchange Server 2003

GroupWise

Exchange Server 2003

a GroupWise

Mensajes de correo electrónico

Mensajes

Sí

Sí

Confirmación de lectura de mensaje

Confirmación de lectura de mensaje

Sí

Sí

Informe de no entrega

Informe de no entrega

Sí

Sí

Importancia

Importancia

Sí

Sí (la prioridad baja no está representada en GroupWise)

Carácter

Carácter

Sí

Sí

478

Característica de

Característica de

GroupWise a

Exchange Server 2003

Exchange Server 2003

GroupWise

Exchange Server 2003

a GroupWise

Convocatorias de reunión

Citas

Sí

Sí

Reunión aceptada

Reunión aceptada

Sí

Sí

Reunión rechazada

Reunión rechazada

Sí

Sí

Reunión aceptada provisionalmente

Reunión aceptada

Aparece como aceptada

Aparece como aceptada

Confirmación de lectura de convocatoria de reunión

Confirmación de lectura de convocatoria de reunión

Sí

Sí

Entrega de convocatoria de reunión

Entrega de convocatoria de reunión

Sí

Sí

Actualizaciones de reuniones

Actualizaciones de reuniones

Aparecen como nuevas convocatorias de reunión que contienen la palabra "Actualizada" en la línea Asunto

Aparecen como nuevas convocatorias de reunión que contienen la palabra "Actualizada" en la línea Asunto

Horas de aviso de reunión

Horas de aviso de reunión

No

No

Cancelación de reunión

Cancelación de reunión

No

Sí

Solicitudes de tareas

Tareas

Las solicitudes de tareas aparecen como mensajes de correo electrónico

Las tareas aparecen como mensajes de correo electrónico

479

Característica de

Característica de

GroupWise a

Exchange Server 2003

Exchange Server 2003

GroupWise Group

Exchange Server 2003

a GroupWise

Convocatorias de reunión con una duración de todo el día

Convocatorias de reunión

Sí

Aparecen como convocatorias de reunión; no obstante, si la reunión tiene una duración de varios días, se coloca como omo instancia única en el primer día, con el intervalo de fechas en el campo del mensaje

No

Mensajes telefónicos

Aparecen como mensajes de correo electrónico

No

Otros mensajes

Otros mensajes

De forma predeterminada, mensajes de correo electrónico

De forma predeterminada, mensajes de correo electrónico

Nota: El Conector para Novell GroupWise no admite mensajes firmados o cifrados.

Conversión del tipo de mensaje de correo electrónico Los mensajes de correo electrónico cuyo origen se encuentra en Exchange Exchange o Novell GroupWise se convierten al formato del sistema de destino. El Conector para Novell GroupWise también realiza el seguimiento de la entrega de mensajes mediante informes de confirmación de entrega, confirmaciones de lectura e informes de no en entrega. trega. El Conector para Novell GroupWise trata las convocatorias de reunión y los mensajes telefónicos de la siguiente forma: •

Convocatorias de reunión y citas Las convocatorias de reunión de Exchange y las citas de Novell GroupWise se transfieren a ttravés ravés del Conector para Novell GroupWise. Las convocatorias de reunión actualizadas se identifican como actualizadas en la línea de asunto. Debido a una limitación de la puerta de enlace API de GroupWise, las solicitudes de reunión enviadas por usuarios de Exchange Server 2003 a usuarios de GroupWise no se pueden actualizar automáticamente en Novell GroupWise y el usuario deberá actualizarlas manualmente.

480

Nota: La puerta de enlace API no admite las convocatorias de reunión periódicas de GroupWise que utilizan la característica de fecha automática. Estas convocatorias de reunión periódicas no se transfieren a Exchange Server 2003. Las reuniones periódicas transferidas de Exchange Server 2003 a Novell GroupWise se agregan al calendario de Novell GroupWise GroupWise una sola vez y la información de periodicidad aparece al principio del cuerpo del mensaje. Es responsabilidad del usuario recordar cuándo tienen lugar las reuniones o especificar varias instancias de las reuniones individualmente en el calendario. •

Convocatorias ocatorias de reunión con una duración de todo el día Las convocatorias de reunión con una duración de todo el día generadas en Exchange Server 2003 aparecen como solicitudes de reunión en Novell GroupWise. No obstante, si la reunión tiene una duración de varios días, el conector crea una instancia única en el primer día, con el intervalo de fechas en el campo del mensaje.

•

Mensajes telefónicos Los mensajes telefónicos de Novell GroupWise aparecen como mensajes de correo electrónico en Exchange Server 2003.

Conversión de propiedades de mensajes de correo electrónico El conector descarta la información en formato de texto enriquecido (RTF) del cuerpo del mensaje de los mensajes de Exchange, ya que la puerta de enlace API sólo admite texto sin formato. Loss objetos incrustados en mensajes enviados por clientes de Exchange Server 2003 (Microsoft Office Outlook) se convierten en datos adjuntos. Estos datos adjuntos, si están incrustados a una profundidad de más de un nivel, aparecen como datos adjuntos del mensaje nsaje principal. Si un usuario de Novell GroupWise envía un mensaje que incluye un mensaje adjunto que, a su vez, contiene otros datos adjuntos, todos los datos adjuntos aparecen en Exchange Server 2003 como datos adjuntos individuales del mensaje principal. Conversión de mensajes de correo electrónico entre Novell GroupWise y Microsoft Outlook Novell GroupWise

Microsoft Outlook

Tamaño

Se convierte correctamente.

Color

Se omiten.

Negrita

Se omiten.

Subrayado

Se omiten.

Cursiva

Se omiten.

Tachado

Se convierte correctamente.

481

Novell GroupWise

Microsoft Outlook

Tablas

Se convierten correctamente si se utiliza Microsoft Word como editor de correo electrónico principal en Outlook. No se convierten correctamente en Outlook.

Objetos OLE incrustados, incluyendo gráficos Se convierten correctamente amente y se pueden modificar. Doble tachado

Se omiten.

Superíndice

Se omiten.

Subíndice

Se omiten.

Sombra

Se omiten.

Esquema

Se convierte a cursiva.

Relieve

Se omiten.

Grabado

Se omiten.

Versales Se omite.

Se omiten.

Se omiten.

Se omiten.

Se omite.

Se omiten.

Se omite.

Omitido, el texto es visible.

Subrayado no sencillo

Se omiten.

Mapas de bits no incrustados como objetos OLE

No se migran; se pierde el formato.

Viñetas

Se omiten.

Nota: Si un usuario de Exchange especifica un usuario de GroupWise varias veces en un mensaje de correo electrónico (si el destinatario aparece más de una vez en los campos Para, CC o CCO o si se encuentra en varios de los grupos de distribución especificados), el usuario de GroupWise recibe mensajes de correo electrónico duplicados.

Sincronización de directorios La sincronización de directorios con Novell GroupWise sigue un modelo parecido a la sincronización de directorios con Lotus Notes. El proceso Lsdxa.exe se encarga de controlar los procesos reales de sincronización sincronización de directorios. Sin embargo, en lugar de Dxanotes.dll,

482

el proceso LSDXA utiliza Dxagwise.dll (es decir, el Agente DX de Novell GroupWise) para la sincronización de directorios con Novell GroupWise. Dxagwise.dll se comunica con Novell GroupWise por medio de la puerta de enlace API de Novell GroupWise, el servicio Enrutador de Exchange para Novell GroupWise y los mensajes del administrador de GroupWise (Msg(Msg Type= Admin). Para obtener más información acerca de cómo configurar la sincronización de directorios, consulte la Exchange Server 2003 Interoperability and Migration Guide. Guide Nota: El Conector para Novell GroupWise crea contactos habilitados para enviar y recibir correo en Active Directory Directory para destinatarios del sistema de mensajería Novell GroupWise. La primera parte de la dirección legacyExchangeDN (es decir, la dirección X.500 del usuario de Exchange en formato de Exchange 5.5) coincide con la legacyExchangeDN del conector. La primera parte es la parte de la dirección X.500 que identifica el grupo administrativo del conector (es decir, /O=<nombre de la organización>/OU=<nombre del grupo administrativo>). El Conector para Novell GroupWise lleva a cabo las siguientes operaciones para sincronizar directorios con Novell GroupWise: 1. Dxamex.dll se comunica con Active Directory a través de ADSI para extraer la información de destinatarios de los contenedores de exportación especificados en la configuración del conector. 2. Dxamex.dll asigna los atributos de los destinatarios tal y como se define en Amap.tbl y Mapmex.tbl y coloca los resultados en un archivo temporal denominado Dxagwise.text en formato de intercambio cambio de mensajes (MIF) en el directorio \Archivos Archivos de programa\Exchsrvr\Conndata Conndata\Togwise. Togwise. A continuación se muestra un ejemplo de archivo Dxagwise.txt: Load A DOMAIN: POSTOFFICE: OBJECT: LASTNAME: FIRSTNAME:Administrator DESCRIP:Administrator ACCOUNTID: TITLE: DEPARTMENT: PHONE: FAX: GWADDR:Exchange.First Administrative Group.Administrator EXCHANGEID:Microsoft Exchange Connector for Novell GroupWise EndOfBuffer

3. Dxagwise.dll analiza el archivo Dxagwise.txt, procesa las direcciones y coloca un mensaje del administrador para realizar la operación de actualización (agregar, modificar o eliminar objetos de destinatario) en el directorio de Novell GroupWise, ubicado en el

483

directorio \Archivos de programa\Exchsrvr\Conndata\Gwrouter\Togwise. A continuación se muestra un ejemplo de un mensaje del administrador para actualizar objetos de destinatario en el directorio de Novell GroupWise: WPC-API= 1.2; Msg-Type= Admin; DS-External-Post-Office= Operation= Add; Domain= EXCHANGE; Post-Office= FIRST ADMINISTRATIVE GROUP; Time-Zone= gmt; ; DS-User= Operation= Modify; Visibility= System; Domain= Exchange; Post-Office= First Administrative Group; Object= Administrator; Last-Name= \\; First-Name= Administrator; Description= Administrator; Account-ID= \\; Title= \\; Department= \\; Phone= \\; Fax= \\; Network-ID= \\; User-Def-5= Microsoft Exchange Connector for Novell GroupWise; ; -END-

4. El servicio Enrutador de Exchange para Novell GroupWise transfiere el mensaje del administrador al directorio API_IN de la puerta de enlace API de Novell GroupWise. 5. La puerta de enlace API de Novell GroupWise analiza el mensaje del administrador y realiza la acción especificada. 6. Si la puerta de enlace API de Novell GroupWise recibe un mensaje del administrador para solicitar información de directorio, devuelve la información solicitada en forma de mensaje del administrador. El mensaje del administrador se coloca en el directorio API_OUT como archivo .api. A continuación se muestra un ejemplo de un mensaje del administrador para solicitar información de directorio del directorio de Novell GroupWise: WPC-API= 1.2; Msg-Type= Admin; -GET-DIRECTORY-END-

7. El servicio Enrutador de Exchange para Novell GroupWise recupera el archivo .api y lo coloca en el directorio \Archivos de programa\Exchsrvr\Conndata\Gwrouter\Dirsync. 8. Dxagwise.dll analiza el archivo .api, extrae la información de destinatarios y escribe las actualizaciones o la lista completa (Carga completa) en Dxamex.txt.

484

9. Dxamex.dll procesa el archivo Dxamex.txt y coloca la información de los destinatarios en el contenedor de importación especificado en la configuración del conector.

Arquitectura del Conector de calendario El Conector de calendario admite la sincronización de información de disponibilidad entre Exchange Server 2003 y Lotus Notes o Novell GroupWise, de forma que los usuarios de estos sistemas de mensajería pueden consultar la información de disponibilidad respectiva res al crear convocatorias de reunión. Los requisitos para el Conector de calendario son parecidos a los del Conector para Lotus Notes y el Conector para Novell GroupWise. Estos conectores deben instalarse en el mismo grupo administrativo que el Conect Conector or de calendario y deben configurarse antes que éste. Para obtener información acerca de cómo instalar y configurar el Conector de calendario, consulte la Guía de interoperabilidad y migración de Exchange E Server 2003. Nota: El Conector de calendario no puede encontrarse en un grupo administrativo sin servidores (es decir, un grupo administrativo que contenga un grupo de enrutamiento para definir administradores específicos), porque no hay ningún servidor servidor que contenga información de disponibilidad. El Conector de calendario debe instalarse en un servidor que ejecute Exchange Server 2003 con una instancia de la carpeta pública de disponibilidad para el grupo administrativo local.

Información de dispo disponibilidad La disponibilidad se refiere a cierta información publicada por un cliente de mensajería para un usuario. Esta información se compone de los datos de disponibilidad personal del usuario, determinados por el contenido de la carpeta Calendario de su su buzón. Como es de esperar, los datos de disponibilidad se utilizan ampliamente al programar reuniones. Los datos de disponibilidad se almacenan como mensajes en una carpeta pública del sistema dedicada. Cada grupo administrativo de la organización de Exc Exchange hange incluye una carpeta de disponibilidad. El Conector de calendario debe instalarse en un servidor que ejecute Exchange Server y que contenga una réplica de la carpeta del sistema de disponibilidad para el grupo administrativo. Los datos de disponibilidad disponibilidad pueden replicarse dentro de la organización de Exchange a cualquiera de los servidores de carpetas públicas o pueden encontrarse en un único servidor que ejecute Exchange Server. Dentro de la organización, los datos de disponibilidad se replican por medio io de la replicación de carpetas públicas estándar. Puede comprobar si un servidor que ejecuta Exchange Server contiene una réplica de la carpeta del sistema de disponibilidad para el grupo administrativo. Para obtener instrucciones detalladas, consulte Cómo comprobar si un servidor en ell que se ejecuta

485

Exchange Server contiene una réplica de la carpeta del sistema de disponibilidad para el grupo administrativo. Nota: El Conector de calendario requiere permisos de lectura y creación de elementos en la carpeta del sistema de disponibilidad. disponibilidad. En las propiedades de la carpeta de disponibilidad para su grupo administrativo local, seleccione la ficha Permisos y, a continuación, haga clic en Permisos de cliente.. En el cuadro de diálogo Permisos de cliente,, asegúrese de que la cuenta Predeterminado tiene asignada la función Editor.

Publicación de datos de disponibilidad La publicación de datos de disponibilidad es una operación de cliente realizada por Outlook y Outlook Web Access. El almacén de Exchange no participa en este proceso, a excepción excepció de una carpeta pública del sistema que se encuentra en un almacén de carpetas públicas y se utiliza para almacenar y publicar datos. Nota: Para replicar los datos de disponibilidad entre organizaciones de Exchange, se utiliza la herramienta Exchsync junto con algunas opciones adicionales. Primero, Outlook recibe una referencia enviada desde el servidor de buzón para la carpeta pública de disponibilidad asociada. Después de ubicar el servidor, las propiedades del objeto de usuario en Active Directory sse e utilizan para buscar el mensaje de disponibilidad en la carpeta pública.

Mensajes de disponibilidad Cada mensaje de disponibilidad es una representación de los días y las horas disponibles y no disponibles para una persona o recurso. Se representa median mediante te una secuencia de números en el servidor de disponibilidad (un servidor de carpetas públicas con carpetas públicas que contienen réplicas de una o varias de las carpetas del sitio de disponibilidad). Una representación es 002222000033333333, donde cada número número representa un incremento de X minutos (tal y como se especifica en la convocatoria, con la granularidad más baja de 6 minutos). Esta interpretación de los números se trata en la tabla siguiente. Mensajes de disponibilidad Número

Significado

0

Libre

1

Provisional

2

Ocupado

486

Número

Significado

3

Fuera de la oficina (OOF)

Cuando hay varias citas a la misma hora, se selecciona la cita con el número más alto de estado. Por ejemplo, una hora que contenga una cita OOF (3) y una cita provisional (1) se codifica como OOF (3). Más concretamente, los datos de disponibilidad se almacenan en varios grupos de matrices de enteros con múltiples valores. Cada grupo representa una de las clasificaciones de ocupación (ocupado, provisional o OOF) y cada elemento del grupo representa un mes de datos. La matriz en sí misma es un grupo de pares de datos, en el que cada par es el número de minutos del mes en el que empieza y finaliza el período de ocupación, cuya zona horaria está ajustada a la Línea de fecha internacional. Por consiguiente, no se almacenan datos para el tiempo libre, ya que el tiempo libre se calcula de forma implícita como todo el tiempo no marcado como ocupado. La cita también almacena el mes de inicio y el recuento de meses, de forma que los clientes puedan realizar los cálculos adecuadamente.

Generación de datos de disponibilidad Existen varias formas de generar datos de disponibilidad. Por ejemplo, Outlook modifica los elementos de disponibilidad de un usuario a medida que se guardan los elementos de calendario y publica periódicamente este mensaje mediante MAPI en su servidor, que ejecuta Exchange Server. Outlook Web Access y Outlook Mobile Access también generan elementos de disponibilidad a medida que se guardan los elementos de calendario. A partir de este punto, Outlook Web Access u Outlook Mobile Access envían el mensaje a través de objetos de datos de colaboración (CDO) y WebDAV al Operador de sistema, que se encarga del procesamiento posterior del mensaje y de su publicación en el servidor que ejecuta Exchange Server.

Publicación de disponibilidad en Outlook Outlook publica los datos de disponibilidad de un usuario periódicamente (de forma predeterminada, cada 15 minutos) y al apagar. Cada vez que se publica información de disponibilidad, se actualiza todo el elemento de disponibilidad (no sólo los cambios). El usuario puede especificar el número de meses de información de disponibilidad futura que se publicarán en el servidor. El valor predeterminado es dos meses y la duración máxima es de 36 meses. De forma predeterminada, los datos de disponibilidad se publican para el mes anterior. Cuando Outlook debe realizar la publicación, primero determina la carpeta en la cual debe publicar los datos de disponibilidad, en función del legacyExchangeDN del usuario. El elemento legacyExchangeDN se compone de dos partes. La primera parte determina la ruta de acceso de la carpeta de disponibilidad (así como el grupo administrativo en que se creó

487

inicialmente el usuario, porque legacyExchangeDN no cambia al mover buzones de usuario entre grupos administrativos) y la segunda parte es el asunto del mensaje de disponibilidad. Por ejemplo, la ubicación de datos de disponibilidad de un usuario con un valor de legacyExchangeDN de /o=Contoso/ou=CorpUsers/cn=Destinatarios/cn=nombreDeUsuario es la carpeta "EX:/o=Contoso/ou=CorpUsers" y el asunto del mensaje es "Usuario/cn=Destinatarios/cn=nombreDeUsuario". La carpeta de disponibilidad es un subdirectorio de la carpeta de disponibilidad de Schedule+, bajo NON_IPM_SUBTREE. El asunto del mensaje es USUARIO/cn=DESTINATARIOS/cn=nombreUsuario. Si se crea un mensaje de disponibilidad duplicado, el almacén de información anexa automáticamente el sufijo -2 a la dirección URL del mensaje. Por consiguiente, USUARIO-/cn=DESTINATARIOS/cn=nombreDeUsuario se convierte en USUARIO-/cn=DESTINATARIOS/cn=nombreDeUsuario-2. Esta duplicación de mensajes no es habitual, pero puede producirse a causa de errores del cliente, errores de replicación, etc. Si Outlook descubre entradas duplicadas para un usuario al publicar datos, las elimina. El agente de publicación de disponibilidad del Operador de sistema también elimina las entradas duplicadas al actualizar información de disponibilidad en nombre de Outlook Web Access u Outlook Mobile Access. Una vez que Outlook ha determinado dónde publicar el mensaje en el almacén de carpetas públicas, elige un servidor de disponibilidad. Los pasos son los siguientes: 1. Al iniciar sesión por primera vez, el servidor indica al cliente cuál es el servidor de jerarquía predeterminado con el que debe ponerse en contacto. Esta información se almacena en el perfil del usuario. Si el administrador cambia esta opción en el Administrador del sistema de Exchange, el usuario debe cerrar la sesión y volverla a iniciar para obtener el nuevo valor. A continuación, el cliente realiza una conexión inicial con este servidor y mantiene la conexión durante toda la sesión del usuario. 2. El cliente MAPI solicita una tabla de "jerarquía" para la raíz del almacén de carpetas públicas. Esta solicitud se envía al almacén de carpetas públicas predeterminado configurado y las carpetas almacenadas en la raíz de este almacén se devuelven al cliente. 3. El cliente enumera las entradas de las carpetas en esta tabla y busca la carpeta en cuestión. Si resulta necesario, a continuación, el cliente abre subcarpetas, abre su tabla de subcarpetas y enumera las subcarpetas de nuevo. 4. Una vez que el cliente MAPI ha identificado la carpeta en cuestión, solicita la tabla de contenido de dicha carpeta. 5. El proveedor de servicios consulta al servidor la lista de réplicas de contenido de la carpeta. 6. El servidor obtiene la lista de réplicas de la carpeta de la base de datos y la ordena en función de los costos de conector del grupo de enrutamiento de dicho servidor. El valor del costo de conector de otras réplicas de contenido del mismo grupo de enrutamiento que el servidor solicitado es cero.

488

7. La lista ordenada se devuelve al cliente, junto con el número de elementos en el grupo de los servidores de menor costo. 8. Si el servidor al que ya está conectado el cliente se encuentra en el conjunto de réplicas (su costo es también cero), la búsqueda de réplicas de contenido ha finalizado. Continúe en el paso 10. resultado se divide por el número de 9. El legacyDN del usuario se convierte en "hash" y su resultado servidores de menor costo. El resto de la división se utiliza para indizar la lista de servidores devuelta y para elegir un servidor al que conectarse. 10. El proveedor de servicios intenta conectarse con el servidor elegido. elegido. Si la conexión se realiza correctamente, el proceso ha terminado y el servidor devuelve la tabla de contenido al cliente MAPI. 11. Si la conexión no puede realizarse o el servidor devuelve "I'm not a replica" (No soy una réplica) (puede que el conjunto d de e réplicas haya cambiado y que dicho cambio no se haya replicado todavía en el servidor del cual proviene la lista de réplicas), el proveedor de servicios elimina este servidor de la lista, hace disminuir el número de servidores "de menor costo" y, si el n número no es cero, vuelve al paso 9. 12. Si la lista de servidores de menor costo se agota, el número se restablece al tamaño de los servidores que quedan en la lista y el proceso vuelve al paso 9. Si toda la lista se agota, se devuelve un error al cliente MAPI. Nota: Estos pasos son idénticos, independientemente de la carpeta que desee el cliente (Libreta de direcciones sin conexión, Disponibilidad u otra carpeta) o del motivo por el que desea el contenido de la carpeta.

Publicación de disponibilidad en O Outlook utlook Web Access y Outlook Mobile Access Al no utilizar MAPI, Outlook Web Access y Outlook Mobile Access no pueden publicar datos de disponibilidad directamente en el almacén de carpetas públicas. En lugar de esto, dependen de un agente de publicación de disponibilidad (MadFB) que se ejecuta en el proceso del Operador de sistema (Mad.exe). MadFB tiene dos funciones: •

Publicación de mensajes de disponibilidad para Outlook Web Access y Outlook Mobile Access

•

Eliminación de mensajes de disponibilidad duplicados d

Como parte de la transacción empleada en la creación, eliminación o actualización de una cita que afecta a la hora de inicio o de fin, una llamada de servidor envía un mensaje de actualización de disponibilidad al buzón del Operador de sistema. MadFB, MadFB, que se encuentra dentro del Operador de sistema, procesa estos mensajes y actualiza los datos de disponibilidad en la carpeta pública MAPI. En función del intervalo de sondeo de mensajes

489

del Operador de sistema, puede haber un retraso de hasta 15 min minutos utos hasta la publicación de los datos de disponibilidad actualizados. El proceso de publicación de MadFB es idéntico al proceso de publicación de Outlook descrito anteriormente. Por consiguiente, si hay mensajes duplicados, se les anexa un número. Aunque Outlook Web Access y Outlook Mobile Access siguen un proceso parecido al seguido por Outlook, los procesos de Outlook Web Access y Outlook Mobile Access suelen ser más confiables, ya que todo el procesamiento se produce entre servidores en los que se ejecuta ta Exchange Server.

Búsqueda de datos de disponibilidad A la hora de buscar datos de disponibilidad, Outlook funciona de forma diferente que Outlook Web Access y Outlook Mobile Access, tal y como se describe a continuación. No obstante, para todos los clientes, ntes, este proceso implica: •

Outlook Antes de buscar la carpeta pública de disponibilidad, Outlook recibe una referencia del servidor de buzón para el almacén de carpetas públicas asociado, en la que el servidor de disponibilidad realiza la consulta (el (el proceso de referencia y consulta es parecido al proceso de publicación). Los datos de disponibilidad se almacenan como mensajes en la carpeta de sitios ubicada en la carpeta de disponibilidad principal. Outlook, mediante Active Directory y Exchange Server, er, determina el legacyExchangeDN de un usuario y lo analiza en dos partes. La primera parte es el nombre de la carpeta de sitios. La segunda parte es el asunto del mensaje.

•

Outlook Web Access y Outlook Mobile Access Estos clientes efectúan una consulta consult DAV para el otro usuario, obtienen la información de disponibilidad y, a continuación, la muestran al usuario. La consulta DAV se inicia desde el servidor que aloja el servicio Outlook Web Access u Outlook Mobile Access (con frecuencia, el servidor de aplicaciones licaciones para el usuario) y se realiza al servidor de buzón del usuario (servidor de servicios de fondo), en el que se realiza la búsqueda real de disponibilidad. Nota: Para que las búsquedas de disponibilidad funcionen, la información de destinatarios s debe estar disponible en Active Directory, de forma que pueda determinarse la carpeta del sistema de disponibilidad de destino. Así, deberá habilitar la sincronización de directorios con Lotus Notes o Novell GroupWise si desea sincronizar información de disponibilidad con el Conector de calendario. Como se menciona anteriormente en esta sección, el Conector para Lotus Notes y el Conector para Novell GroupWise crean contactos habilitados para enviar y recibir correo con una dirección de legacyExchangeDN que que corresponde al grupo administrativo local del conector. Debido a esta dependencia, el Conector de calendario debe instalarse en el mismo grupo administrativo que el Conector para Lotus Notes o el Conector para Novell GroupWise. Deberá instalar el Conectorr de calendario en el mismo servidor que el Conector para Lotus Notes y el Conector para Novell GroupWise.

490

Agente de publicación de disponibilidad (MadFB) MadFB permite a Outlook Web Access y Outlook Mobile Access publicar datos de disponibilidad. Como función secundaria, MadFB también purga los datos de disponibilidad obsoletos. De forma predeterminada, MadFB intenta mantener los datos de disponibilidad en todos los servidores que no sean de aplicaciones para el usuario en los que se ejecute Exchange Server rver cada día a las 2:00 a.m. MadFB mantiene en cada servidor los almacenes de carpetas públicas asociados con los almacenes de buzones locales de cada servidor (incluso aunque estos almacenes de carpetas públicas estén ubicados en otro servidor). MadFB se ejecuta dentro del proceso del Operador de sistema. El proceso de mantenimiento de MadFB incluye lo siguiente: •

Reparación de las direcciones URL de los elementos de disponibilidad Un elemento de disponibilidad debe tener un formato "canónico", es de decir, cir, el elemento debe tener una dirección URL que acabe en un asunto normalizado, como USUARIOUSUARIO /CN=DESTINATARIOS/CN=TED. Puede que haya elementos que no tengan un formato "canónico" a causa de la existencia de duplicados. Por ejemplo, una de las direcciones direccione URL puede tener agregada una ""-x" x" para evitar un nombre duplicado o puede señalar a un elemento actualizado o replicado desde Exchange Server 5.5, en cuyo caso la dirección URL incluirá un GUID. El asunto normalizado se determina por medio de la última parte arte del legacyDN (por ejemplo, CN=DESTINATARIO,CN=TED).

•

Eliminación de mensajes de disponibilidad duplicados Outlook puede crear un mensaje de disponibilidad duplicado. Para evitar el reemplazo de mensajes existentes, el almacén de Exchange anexa ""-X" (sin las comillas, donde X es un contador incremental para el duplicado) al asunto normalizado. MadFB elimina los mensajes que tienen líneas de asunto en forma no canónica.

MadFB conserva el mensaje con la fecha más antigua y elimina los mensajes restantes, restante lo que garantiza una replicación determinista, en la que las entradas duplicadas se eliminan siempre. Por ejemplo, si MadFB conserva el mensaje más reciente y elimina el resto de los mensajes, el mensaje en conflicto [X [X-2] se mantiene en la replicación. Esto ocurre porque X en PF1 y X-2 2 en PF2 se eliminan primero y las versiones más recientes de X-2 X en PF1 y de X en PF2 se replican, por lo que se convierten en las entradas más recientes y el ciclo se repite. Nota: MadFB es igual que MSExchangeFBPublish, MSExchangeFBPublish, el registro Nombre de origen del registro de sucesos utilizado para registrar sucesos en el registro de sucesos.

Limpieza de datos de disponibilidad Existen varias formas de eliminar datos de disponibilidad no deseados. Puede utilizar un modificador de inicio nicio de la línea de comandos de Outlook, llevar a cabo un proceso de

491

servidor en el servidor que ejecuta Exchange Server o utilizar Outlook Web Access para eliminar los elementos manualmente.

Modificador de inicio de Outlook El modificador de inicio de la línea de comandos de Outlook /cleanfreebusy se utiliza para solucionar problemas de programación de reuniones. Este modificador no sirve para solucionar problemas generales de citas, ya que no elimina el elemento de disponibilidad del almacén de carpetas públicas, sino que elimina el mensaje de disponibilidad local (LocalFreeBusy) generado por el cliente de Outlook. El mensaje LocalFreeBusy es un elemento oculto en la carpeta Calendario del usuario en el buzón ubicado en el servidor. Este elemento contiene un objeto binario de gran tamaño con la información de disponibilidad del usuario, información acerca de delegados autorizados para programar citas para el usuario y opciones de aceptación automática. Normalmente, los buzones de recursos están configurados para aceptar convocatorias de reunión automáticamente si no hay ningún conflicto con una cita existente. El elemento LocalFreeBusy se replica en el almacén de carpetas públicas para que todos los usuarios de la organización de Exchange puedan ver la información de disponibilidad y utilizarla para programar reuniones. Si los delegados reciben un mensaje de error al intentar modificar el calendario del administrador, la ejecución de /cleanfreebusy en el calendario del administrador mientras los delegados tienen Outlook cerrado restablece determinadas propiedades del almacén de carpetas públicas del administrador. La próxima vez que los delegados inicien Outlook, recuperarán los datos de disponibilidad del elemento LocalFreeBusy del administrador, lo que solucionará la mayoría de los errores de los delegados. Este problema de programación de reuniones por parte de los delegados surge originalmente porque el cliente del delegado (por diversos motivos) vuelve a crear el mensaje de disponibilidad, lo que hace que los punteros señalen al mensaje eliminado. Si el administrador ejecuta /cleanfreebusy de Outlook en este estado, su cliente vuelve a crear el mensaje de disponibilidad local y marca las carpetas raíz con el Id. de la nueva entrada, lo que permite a todos obtener acceso de nuevo al mensaje de disponibilidad.

Limpieza mediante Outlook Web Access Los mensajes de disponibilidad se encuentran en una carpeta pública, bajo el contenedor de disponibilidad de Schedule+, en el subárbol no IPM de la jerarquía de carpetas públicas. El subárbol no IPM es un árbol oculto, pero puede utilizar Outlook Web Access para obtener acceso a él y abrir la carpeta de disponibilidad de un grupo administrativo. Una vez hecho esto, se pueden eliminar manualmente los elementos de disponibilidad. Por ejemplo, para obtener acceso al subárbol no IPM de un servidor denominado Servidor01, utilice la siguiente dirección URL: http://servidor01/public/subárbol_no_ipm/. El contenedor de disponibilidad de Schedule+ aparece como una carpeta pública normal. Las carpetas de disponibilidad se encuentran en este contenedor.

492

Componentes del Conector de calendario Como el Conector de calendario no transfiere mensajes de correo electrónico entre Exchange y Lotus Notes o Novell GroupWise, este conector no dispone de un buzón del conector en el almacén de Exchange, ni de una DLL de generación de direcciones proxy, ni de un objeto adrType en Active Directory. No obstante, el Conector de calendario es un conector basado en MAPI, ya que depende de MAPI para la comunicación con el almacén de Exchange y de ADSI (interfaces del servicio Active Directory) para la comunicación con Active Directory. En la tabla siguiente se enumeran los componentes importantes del Conector de calendario.

493

Componentes del Conector de calendario Componente

Descripción

494

Componente

Descripción

Servicio de conector

El archivo ejecutable principal del servicio Conector de calendario se denomina CalCon.exe. CalCon.exe, a su vez, carga varios componentes, denominados proveedores, que realizan las tareas de sincronización de información de disponibilidad. Todos los archivos se encuentran en el directorio \Archivos de programa\Exchsrvr\Bin. •

Adminsvc.dll El Conector de calendario carga Adminsvc.dll para realizar tareas administrativas, como sondear los proveedores eedores de forma periódica para informar acerca del estado del conector y recopilar estadísticas y datos de rendimiento que pueden mostrarse mediante la herramienta Rendimiento.

•

Calsync.dll El Conector de calendario carga Calsync.dll al inicio para buscar bus en Active Directory los destinatarios de sistemas distintos de Exchange que el Conector para Lotus Notes o el Conector para Novell GroupWise crea durante la sincronización de directorios. El conector basado en MAPI utilizado por el Conector de calendario io como base para esta búsqueda está especificado en el Administrador del sistema de Exchange, en la configuración del Conector de calendario, en la ficha General. Calsync.dll garantiza que haya un registro de disponibilidad en la carpeta del sistema de disponibilidad sponibilidad para cada destinatario de sistemas distintos de Exchange encontrado en Active Directory. Los registros de disponibilidad están vacíos en la primera inicialización. Nota: Se recomienda programar el Conector de calendario después de cada ciclo o de sincronización de directorios, de forma que Calsync.dll pueda crear elementos de disponibilidad para

495

Componente

Descripción

Complemento Conector de calendario de Exchange

El complemento Conector de calendario de Exchange (ExCalCon.exe) es un componente que debe instalarse en el servidor de Lotus Notes y Domino y que el Conector para Lotus Notes y el Conector de calendario utilizan como su servidor cabeza de puente que no es de Exchange. ExCalCon.exe recibe solicitudes de disponibilidad por parte de Lotus Notes a través de Schedule Manager de Lotus Notes y las reenvía a la instancia del Conector de calendario que se ejecuta en un servidor con Exchange Server.

Configuración del Registro

La configuración del Conector de calendario se almacena en la siguiente ubicación del Registro: HKEY_LOCAL_MACHINE\SYSTEM\Curren tControlSet\Services\MSExchangeCalCon.

496

Componente

Descripción

Objeto msExchConnector

El objeto msExchConnector del Conector de calendario, que se encuentra en la partición del directorio de configuración de Active Directory, almacena la mayoría de las opciones de configuración del conector. Los atributos siguientes son específicos de la clase de objeto msExchCalendarConnector, derivada de las clases de objetos msExchConnector y mailGateway. El objeto msExchCalendarConnector tiene los siguientes atributos específicos del Conector de calendario: • msExchCalConQueryWindow Esp ecifica el tiempo durante el cual el Conector de calendario espera a que el sistema de mensajería que no es de Exchange devuelva una respuesta a una solicitud de disponibilidad. Si este tiempo se supera, el Conector de calendario devuelve al usuario de Exchange la información actualmente disponible en el registro de disponibilidad. Si las respuestas se retrasan, Exchange Server 2003 devuelve los datos existentes al cliente de Outlook. Cuando se reciben finalmente los datos nuevos, el Conector de calendario actualiza el registro de disponibilidad para el usuario del sistema que no es de Exchange. La información actualizada no se devuelve al cliente de Outlook y el usuario no recibe ninguna indicación de que es posible que la información de disponibilidad no incluya las actualizaciones más recientes o de que podría obtenerse información más actualizada con una consulta posterior. • msExchCalConRefreshInterval Es pecifica el período de tiempo dentro del cual el Conector de calendario considera que los registros de disponibilidad para usuarios de sistemas distintos de Exchange son los más recientes. Dentro de msExchCalConRefreshInterval, el Conector de calendario devuelve los

497

Componente

Descripción

Complemento administrativo

El complemento de extensión para el Conector de calendario se denomina Conector de calendario de Exchange. Este complemento se implementa en Exadmin.dll y amplía el nodo para el conector, que se encuentra en el Administrador del sistema de Exchange, bajo /Grupos administrativos//Grupos de enrutamiento//Conectores.

Búsquedas de disponibilidad hacia y desde Lotus Notes La figura siguiente ilustra cómo se integra el Conector de calendario con un entorno de mensajería de Lotus Notes. Sincronización de información de disponibilidad con Lotus Notes

498

En el Conector de calendario, Notescal.dll se comunica con Lotus Notes y Domino a través de la API del cliente de Lotus Notes para transferir las solicitudes de información de disponibilidad de Lotus Notes a la tarea Schedule Manager de Lotus Notes. Schedule Manager es una tarea que se ejecuta en un servidor de Lotus Domino, que administra una base de datos de Lotus Notes denominada Busytime.nsf. La base de datos Busytime.nsf contiene información de disponibilidad para todos los usuarios del servidor y para los recursos, como salas de conferencias, identificados en la libreta de direcciones pública del servidor. Nota: El Conector de calendario sólo puede conectarse a un entorno de Lotus Notes. La integración de varios sistemas de mensajería Lotus Notes dispares con Exchange Server 2003 mediante el Conector de calendario no se admite.

Búsquedas de disponibilidad desde Exchange 2003 El Conector de calendario lleva a cabo las operaciones siguientes para realizar búsquedas de disponibilidad para usuarios de Lotus Notes desde Exchange Server 2003: 1. Mapical.dll intercepta la solicitud de disponibilidad y comprueba si existen exis registros de disponibilidad en la carpeta del sistema de disponibilidad. Si el registro se ha actualizado dentro del período de tiempo especificado en la opción de Exchange Antigüedad máxima en minutos de datos de disponibilidad externos en Exchange qu que e se pueden usar sin consultar un calendario externo, en la configuración del Conector de calendario, Mapical.dll devuelve estos datos inmediatamente. Nota: Este mecanismo sólo funciona si el Conector de calendario se ejecuta en el servidor en el que sse e encuentra la carpeta de disponibilidad. Por ejemplo, se puede replicar la carpeta de disponibilidad en otros servidores de grupos administrativos remotos, en cuyo caso es posible que los usuarios que realicen consultas en estas instancias de carpetas púb públicas licas reciban información obsoleta. Exchange Server 2003 sólo devuelve la información actualmente disponible en los mensajes de disponibilidad solicitados. Para evitar este problema, deberá instalar instancias distintas del Conector de calendario en cada rréplica éplica de la carpeta de disponibilidad. 2. Si no existe un registro de disponibilidad o supera el límite temporal máximo, Mapical.dll transmite la consulta de disponibilidad a Notescal.dll para actualizar el registro de disponibilidad del usuario de destin destino o en la carpeta de disponibilidad de Exchange. 3. Notescal.dll recibe la consulta de disponibilidad de Mapical.dll y la transmite a la tarea Schedule Manager de Lotus Notes.

499

4. La tarea Schedule Manager busca la información de los usuarios locales en la base b de datos Busytime.nsf. En el caso de los usuarios en los servidores de Lotus Domino que siguen en la cadena, Schedule Manager se comunica con la tarea Calendar Connector de Lotus Notes que también se ejecuta en el servidor de Lotus Domino para ubicar la l información de disponibilidad. 5. La tarea Calendar Connector de Lotus Notes determina el dominio del usuario de destino y lee el campo Calendar Server Name del documento del dominio. A continuación, se comunica con el servidor de calendario remoto para realizar la consulta de disponibilidad. 6. La tarea Calendar Connector de Lotus Notes devuelve la información a la tarea Schedule Manager. 7. Ésta devuelve la información a Notescal.dll. 8. Notescal.dll transmite la información a Mapical.dll, que actualiza actualiza el registro de disponibilidad del usuario de Lotus Notes en la carpeta del sistema. 9. Mapical.dll devuelve la información al usuario de Outlook. Nota: Si el sistema que no es de Exchange responde dentro del período de tiempo especificado en Número máximo áximo de segundos que se va a esperar respuesta de calendarios externos, externos, en la configuración del Conector de calendario, los datos se copian en el registro de disponibilidad del usuario de destino, ubicado en la carpeta de disponibilidad de Exchange, y se devuelven al cliente. Si el sistema que no es de Exchange no responde dentro del período de tiempo permitido (o si el Conector de calendario no está en ejecución), Exchange Server 2003 devuelve al cliente los datos existentes del registro de disponibilidad,, sin actualizar primero el registro de disponibilidad del usuario de destino.

Búsquedas de disponibilidad desde Lotus Notes El Conector de calendario lleva a cabo las operaciones siguientes para realizar búsquedas de disponibilidad para usuarios de Exchange Exchan Server 2003 desde Lotus Notes: 1. El cliente de Lotus Notes transmite la consulta de disponibilidad a la tarea Schedule Manager. 2. La tarea Schedule Manager determina que la solicitud se refiere a un usuario no local y la transmite a la tarea Calenda Calendar Connector. 3. La tarea Calendar Connector lee el documento de persona para el usuario de Exchange y determina que el usuario se encuentra en un dominio externo. La tarea Calendar Connector comprueba el campo Sistema de calendario en el documento de dominio io externo para la organización de Exchange Server 2003. El campo Sistema de

500

calendario identifica el nombre del programa complemento que administra las búsquedas de disponibilidad en el servidor de Lotus Domino, que es el complemento de Conector de calendario ario de Exchange (ExCalCon.exe). 4. La tarea Calendar Connector transmite la solicitud de disponibilidad a ExCalCon.exe. 5. ExCalCon.exe transmite la solicitud al componente Notescal.dll, que procesa la solicitud y se comunica con Mapical.dll para obtener la información de disponibilidad para el usuario de Exchange de la carpeta del sistema de disponibilidad. 6. Notescal.dll transmite ransmite la respuesta a ExCalCon.exe, que, a su vez, transmite la información a la tarea Calendar Connector. 7. La tarea Calendar Connector transmite los datos a Schedule Manager. 8. Schedule Manager entrega la información de disponibilidad al usuario de L Lotus Notes. Nota: Como Lotus Notes identifica todos los usuarios de Exchange como pertenecientes a un dominio distinto de Lotus Notes, todas las solicitudes de información de disponibilidad de Exchange se reciben desde la tarea Calendar Connector de Lotus Lotu Notes.

Búsquedas de disponibilidad hacia y desde Novell GroupWise Como se indica en la figura siguiente, Gwisecal.dll se comunica con Novell GroupWise a través del Conector para Novell GroupWise y la puerta de enlace API de Novell GroupWise. Las solicitudes des de disponibilidad se transfieren dentro de Novell GroupWise como mensajes del sistema. La arquitectura del Conector para Novell GroupWise se trata anteriormente en esta sección.

501

Sincronización de información de disponibilidad con Novell GroupWise

El Conector de calendario lleva a cabo las operaciones siguientes para realizar búsquedas de disponibilidad para usuarios de Novell GroupWise desde Exchange Server 2003: 1. Mapical.dll intercepta la solicitud de disponibilidad y comprueba si existen registros de disponibilidad en la carpeta del sistema de disponibilidad. Si el registro se ha actualizado dentro del período de tiempo especificado en la opción de Exchange Antigüedad máxima en minutos de datos de disponibilidad externos en Exchange que se pueden usar sin consultar un calendario externo, en la configuración del Conector de calendario, Mapical.dll devuelve estos datos inmediatamente. 2. Si no existe un registro de disponibilidad para el usuario de Novell GroupWise o el registro supera el límite temporal máximo, Mapical.dll transmite la consulta de disponibilidad a Gwisecal.dll para actualizar el registro de disponibilidad del usuario de destino en la carpeta de disponibilidad de Exchange. 3. Gwisecal.dll traduce la solicitud a un archivo de texto basado en palabras clave de tipo SEARCH y lo coloca en el directorio \Archivos de programa\Exchsrvr\Conndata\GWRouter\Togwise. El remitente de este mensaje tipo SEARCH es el Operador de sistema. El mensaje va dirigido al usuario de Novell GroupWise para el cual el Conector de calendario solicita la información de disponibilidad. A continuación se muestra un ejemplo de una solicitud de tipo SEARCH:

502

WPC-API= 1.2; MSG-TYPE= Search; Msg-ID= AAIMIDMI:2003.12.2.21.28:2004.1.31.21.28:2003.12.3.5.28.51; From= WPD= CONTOSO_DOM; WPPO= Exchange Gateway; WPU= Microsoft System Attendant; CDBA= CONTOSO_DOM.Exchange Gateway.Microsoft System Attendant; ; To= WPD= CONTOSO_DOM; WPPO= CONTOSO_PO; WPU= FrankM; CDBA= CONTOSO_DOM.CONTOSO_PO.FrankM; ; Begin-Time= 2/12/2003 21:28; End-Time= 31/1/2004 21:28; -END-

4. El Enrutador para Novell GroupWise obtiene el mensaje del directorio \Togwise y lo coloca en el directorio API_IN de la puerta de enlace API de Novell GroupWise. 5. La puerta de enlace API procesa el mensaje en función de la palabra clave MSG-TYPE y lo coloca en el directorio WPCSIN del MTA de Novell GroupWise. 6. El MTA de Novell GroupWise enruta el mensaje a la oficina de correos principal del usuario de GroupWise y lo transmite al Agente de oficina de correos (POA) de Novell GroupWise correspondiente. 7. El POA de Novell GroupWise procesa la solicitud y devuelve la información de disponibilidad resultante al MTA de GroupWise en forma de mensaje SEARCH. 8. El MTA de GroupWise transfiere el mensaje al directorio WPCSOUT del directorio de la puerta de enlace API y ésta lo transfiere al directorio API_OUT. 9. El Enrutador para Novell GroupWise obtiene el mensaje SEARCH del directorio API_OUT y lo coloca, en función de la palabra clave MSG-TYPE, en el directorio \Archivos de programa\Exchsrvr\Conndata\GWRouter\freebusy. A continuación se muestra un ejemplo de una respuesta a una consulta de disponibilidad: WPC-API= 1.2; Header-Char= T50; Msg-Type= SEARCH; Orig-Msg-ID= AAIMIDMI:2003.12.2.21.28:2004.1.31.21.28:2003.12.3.5.28.51; To= CDBA= CONTOSO_DOM.Exchange Gateway.Microsoft System Attendant;

503

; Busy-For= CDBA= CONTOSO_DOM.CONTOSO_PO.FrankM; Busy-Report= Start-Time= 11/12/03 17:00; End-Time= 12/12/03 8:00; , Start-Time= 12/12/03 17:00; End-Time= 15/12/03 8:00; , Start-Time= 15/12/03 17:00; End-Time= 16/12/03 8:00; , Start-Time= 16/12/03 17:00; End-Time= 17/12/03 8:00; , Start-Time= 17/12/03 17:00; End-Time= 18/12/03 8:00; , Start-Time= 18/12/03 17:00; End-Time= 19/12/03 8:00; , ; Send-Options= None; -END-

10. Gwisecal.dll recupera el mensaje y lo traduce al formato de Exchange. A continuación, Gwisecal.dll transmite los datos a Mapical.dll. 11. Mapical.dll actualiza el registro de disponibilidad para el usuario de Novell GroupWise en la carpeta del sistema de disponibilidad. 12. Exchange Server 2003 devuelve la información de disponibilidad al usuario de Outlook que ha realizado la solicitud.

Búsquedas de disponibilidad desde Novell GroupWise El Conector de calendario lleva a cabo las operaciones siguientes para realizar búsquedas de disponibilidad para usuarios de Exchange Server 2003 desde Novell GroupWise: 1. Un usuario de Novell GroupWise realiza una búsqueda de disponibilidad para un usuario de Exchange. El cliente de Novell GroupWise genera un mensaje SEARCH, que el sistema Novell GroupWise transfiere a la puerta de enlace API. 2. La puerta de enlace API transfiere el mensaje SEARCH desde el directorio WPCSOUT al directorio API_OUT, donde el Enrutador para Novell GroupWise lo recupera y lo coloca en función de la palabra clave MSG-TYPE en el directorio \Archivos de programa\Exchsrvr\Conndata\GWRouter\FreeBusy. El mensaje va dirigido al usuario de

504

Exchange para el cual el usuario de Novell GroupWise solicita la información de disponibilidad. La estructura del mensaje es parecida a la generada por Gwisecal.dll para consultas realizadas por usuarios de Exchange Server. 3. Gwisecal.dll obtiene el mensaje SEARCH del directorio \FreeBusy, FreeBusy, lo traduce al formato de Exchange Server y, a continuación, transmite la solicitud a Mapical.dll. 4. Mapical.dll procesa la consulta de disponibilidad y devuelve la información solicitada a Gwisecal.dll. 5. Gwisecal.dll traduce la solicitud a una respuesta de tipo SEARCH y la coloca en el directorio \Archivos Archivos de programa\Exchsrvr\Conndata\GWRouter\Togwise. programa Togwise. La estructura del mensaje es parecida arecida a la generada por el sistema Novell GroupWise para respuestas a consultas realizadas por usuarios de Exchange. 6. El Enrutador para Novell GroupWise obtiene el mensaje del directorio \Togwise y lo coloca en el directorio API_IN de la puerta de enlace enla API. 7. El sistema Novell GroupWise enruta la respuesta al usuario que ha emitido la consulta de disponibilidad. Nota: Los usuarios de GroupWise deben tener configurada la opción de visibilidad con el valor System o superior, para poder recibir la información de calendario de Exchange.

Cómo comprobar si un servidor en el que se ejecuta Exchange Server contiene una réplica de la carpeta del sistema de disponibilidad para el grupo administrativo En este tema se explica cómo determinar si un servidor en en el que se ejecuta Exchange Server contiene una réplica de la carpeta del sistema de disponibilidad para el grupo administrativo local. Esto debe hacerlo cuando decida dónde instalar el Conector de calendario, ya que sólo se puede instalar en un servidor que contenga una réplica de dicha carpeta.

Antes de empezar Antes de realizar el procedimiento descrito en este tema, asegúrese de que dispone de los permisos correctos. El Conector de calendario requiere permisos de lectura y creación de elementos en la carpeta arpeta del sistema de disponibilidad. En las propiedades de la carpeta de disponibilidad para su grupo administrativo local, seleccione la ficha Permisos y, a

505

continuación, haga clic en Permisos de cliente. En el cuadro de diálogo Permisos de cliente, asegúrese de que la cuenta Predeterminado tiene asignada la función Editor.

Procedimiento Para comprobar si un servidor en el que se ejecuta Exchange Server contiene una réplica de la carpeta del sistema de disponibilidad para el grupo administrativo local. 1. En el Administrador del sistema de Exchange, haga clic en el contenedor Carpetas. 2. Haga clic con el botón derecho del mouse en Carpetas públicas. 3. Seleccione Ver carpetas del sistema. Las carpetas de disponibilidad se denominan según su grupo administrativo y se encuentran en el contenedor DISPONIBILIDAD DE SCHEDULE+. 4. Muestre las propiedades de la carpeta del sistema para su grupo administrativo local y seleccione la ficha Replicación. Asegúrese de que el almacén de carpetas públicas del servidor con Exchange Server en el que se ejecuta el Conector de calendario se incluye en la lista de almacenes de carpetas públicas.

Servidores virtuales de protocolos de Exchange Server 2003 Microsoft Exchange Server 2003 incluye servidores virtuales de protocolos, varios de los cuales proporcionan acceso de clientes. Los servidores virtuales de protocolos dependen de los Servicios de Internet Information Server (IIS) y del servicio de directorio Active Directory para sus operaciones y servicios. De forma predeterminada el programa de instalación de Exchange Server 2003 crea los siguientes servidores virtuales de protocolos: •

Servidor virtual de Exchange Habilitado de forma predeterminada, este servidor virtual incluye varios directorios virtuales: Exadmin, Exchange, Microsoft-ServerActiveSync, Microsoft Office Outlook Mobile Access y public. Proporciona acceso WebDAV a los datos del buzón y de las carpetas públicas de Exchange de usuarios de Outlook Web Access, Microsoft Outlook Mobile Access y Exchange ActiveSync.

•

Servidor virtual IMAP4 Deshabilitado de forma predeterminada, este servidor virtual proporciona acceso de clientes IMAP4 a los datos del buzón y de las carpetas públicas de Exchange.

•

Servidor virtual NNTP Deshabilitado de forma predeterminada, este servidor virtual proporciona acceso de clientes NNTP a los datos de las carpetas públicas de Exchange.

•

Servidor virtual POP3 Deshabilitado de forma predeterminada, este servidor virtual proporciona acceso de clientes POP3 a los datos del buzón de Exchange.

506

•

Servidor virtual SMTP Habilitado de forma predeterminada, este servidor virtual proporciona servicios de mensajería SMTP.

Exchange Server 2003 instala y administra los protocolos de acceso de clientes de POP3 y del Protocolo de acceso a correo de Internet versión 4rev1 (IMAP4), pero utiliza las pilas de protocolos SMTP y NNTP proporcionadas por IIS. SMTP se trata detalladamente en Arquitectura de transporte SMTP. Esta sección se centra en los demás protocolos de acceso de clientes de Internet: HTTP, IMAP4, POP3 y NNTP. En esta sección se explican los siguientes conceptos: •

Integración de Exchange 2003 con IIS IIS y Exchange 2003 están sólidamente integrados mediante el uso de códigos auxiliares de protocolo y de una cola de memoria compartida. En esta sección se tratan las consecuencias de esta integración relacionadas con la implementación, la administración y la solución de problemas de servicios de mensajería.

•

Protocolos de acceso de clientes estándar de Internet, incluidos HTTP, NNTP, IMAP4 y POP3 Debe comprender cómo los servidores virtuales de protocolos de Exchange Server 2003 utilizan los protocolos de Internet para el acceso de clientes a los datos y servicios de Exchange.

•

Arquitectura de RPC a través de HTTP La llamada a procedimiento remoto (RPC) a través de HTTP permite a los clientes de Microsoft Office Outlook 2003 conectarse de forma segura con un servidor de Exchange a través de Internet mediante los servicios de transporte MAPI de Microsoft Exchange. En esta sección se trata el funcionamiento de RPC a través de HTTP y cómo implementarlo en su organización.

•

Características de movilidad de Exchange Exchange 2003 incluye nuevas características de movilidad, como Outlook Mobile Access y Exchange Server ActiveSync, que también se implementan como servidores virtuales de protocolos. En esta sección se trata el funcionamiento de estas características y cómo implementarlas en su organización.

Integración con IIS En Exchange Server 2003, todos los protocolos de acceso de clientes basados en Internet se ejecutan como parte de IIS. Al instalar Exchange Server 2003, éste amplía, en lugar de sustituir, las pilas de protocolos SMTP y NNTP en IIS mediante el uso de verbos de comandos adicionales y componentes de enrutamiento avanzados. Las pilas de protocolos de Internet de Exchange Server 2003 son: •

POP3 POP3 es el protocolo más básico de recuperación de mensajes. POP3 sólo puede obtener acceso a la carpeta Bandeja de entrada del usuario. Exchange 2003 admite POP3 para acceso por parte de clientes POP3.

•

IMAP4 IMAP4 se utiliza para obtener acceso a la información de buzón. IMAP4 es más avanzado que POP3, ya que admite capacidades en línea básicas y acceso a otras

507

carpetas, además de a la Bandeja de entrada. Además de proporcionar acceso limitado a los buzones de los usuarios, la implementación en Exchange 2003 de IMAP4 ofrece lo siguiente:

•

•

•

•

Acceso a carpetas públicas.

•

Acceso delegado al buzón de otro usuario.

•

Acceso anónimo a nombres de cuentas IMAP específicos.

SMTP SMTP es el protocolo de mensajería principal de Exchange Server 2003. SMTP se utiliza para mover mensajes entre servidores que pertenecen al mismo grupo de enrutamiento y el protocolo preferido para mover mensajes entre grupos de enrutamiento. Entre las mejoras realizadas por Exchange Server 2003 a la pila SMTP de IIS se incluyen: •

Comandos que admiten enrutamiento tolerante a errores.

•

Motor de cola avanzada.

•

Agente de categorización de mensajes mejorado.

NNTP La implementación en Exchange Server 2003 de NNTP agrega la siguiente funcionalidad a NNTP: •

La indización de contenido proporciona funcionalidad de búsqueda a las carpetas públicas.

•

Aceptación completa de suministro de noticias, independientemente del lugar de almacenamiento (sistema de archivos o carpetas públicas) en el servidor de servicios de fondo.

•

Los clientes MAPI o NNTP pueden leer o publicar mensajes en los grupos de noticias admitidos por el servicio Almacén de información de Microsoft Exchange.

WebDAV WebDAV es una extensión de HTTP que proporciona una interfaz Web al servicio Almacén de información de Microsoft Exchange.

Examen de la comunicación entre procesos entre IIS y el servicio Almacén de información de Microsoft Exchange A excepción de MAPI, los protocolos de acceso de clientes de Exchange Server 2003 no forman parte del servicio Almacén de información de Microsoft Exchange, sino que están alojados en IIS. La separación de estos protocolos del servicio Almacén de información de Microsoft Exchange aumenta la confiabilidad, flexibilidad y escalabilidad de Exchange Server 2003. Sin embargo, los protocolos deben poder transferir datos rápidamente entre IIS y el servicio Almacén de información de Microsoft Exchange. Para facilitar la transferencia rápida de datos, Exchange Server 2003 contiene una capa de colas denominada capa de Comunicación entre procesos de Exchange (ExIPC), también denominada EPOXY porque se implementa en Epoxy.dll.

508

Como se ilustra en la figura siguiente, ExIPC funciona junto con el Sistema de archivos instalable de Exchange (ExIFS) para mover mensajes entre IIS y Exchange Server 2003. ExIPC ofrece una funcionalidad de comunicación entre procesos de alto rendimiento. Como las llamadas ligeras a procedimiento remoto (LRPC), ExIPC utiliza memoria compartida (secciones de memoria asignada de 32 KB), creada según el modelo Cola circular de memoria compartida (SMQ), para comunicarse entre los procesos INETINFO y STORE, y la caché DSAccess. Esto garantiza que la caché está disponible para todos los procesos que ejecutan DSAccess. ExIPC incluye el servicio Almacén de información de Microsoft Exchange y una DLL de protocolo que proporciona una herramienta de enlace (comunicación rápida y confiable entre IIS y el servicio Almacén de información de Microsoft Exchange), un montón de memoria compartida y un par de colas basadas en la memoria compartida. Arquitectura de almacenamiento y protocolos de Exchange Server 2003

Sistema de archivos instalable de Exchange ExIPC funciona junto con el Sistema de archivos instalable de Exchange (ExIFS) para mover mensajes entre IIS y Exchange. ExIFS proporciona acceso al servicio Almacén de información de Microsoft Exchange mediante API del sistema de archivos Microsoft Win32. ExIFS hace IIS vea el archivo de secuencias como muchos archivos pequeños, denominados archivos virtuales. IIS obtiene un identificador de un archivo virtual y copia los datos entrantes directamente en el archivo de secuencias mediante ExIFS. De forma parecida, los mensajes salientes se leen directamente del archivo de secuencias mediante ExIFS. Un mensaje se convierte en una lista de páginas (con los números de página en el archivo .edb) en el archivo de secuencias y las propiedades necesarias pasan desde el archivo .stm al archivo .edb.

509

Arquitectura de ExIFS

Un mensaje se convierte en una lista de páginas (con los números de página en el archivo .edb) en el archivo de secuencias. Las propiedades necesarias pasan desde el archivo .stm al archivo .edb. Esta figura ilustra la transferencia por secuencias de archivos entre IIS y ExIFS. ExIFS representa los archivos por secuencias transmitidos a IIS como archivos virtuales de menor tamaño. Los datos, como, por ejemplo, los datos de suma de comprobación y la promoción de e datos de propiedades, se trasladan primero desde ExIFS al Motor de almacenamiento extensible y, a continuación, al almacén de información de Exchange. IIS y el almacén de información de Exchange también intercambian información, como los números de página págin en los que ExIFS ha colocado un mensaje, para que los números de página se registren y se almacenen en el registro que representa al mensaje en el almacén de información de Exchange.

Mensajes entrantes Cuando un mensaje entra en el sistema, IIS crea un archivo archivo nuevo en ExIFS. Los datos se copian al archivo nuevo en páginas reservadas. A continuación, ExIFS devuelve la lista de páginas al almacén de Exchange. El almacén de información de Exchange procesa las páginas y las almacena en un registro que representa representa al mensaje. Después, el Motor de almacenamiento extensible confirma los datos incluidos en las páginas reservadas; para ello, registra la información en los archivos de registro de transacciones del grupo de almacenamiento. En este punto, las páginas cambian de estado reservado a estado confirmado. Nota: Si el grupo de almacenamiento tiene activado el registro circular, el Motor de almacenamiento extensible no copia los datos provenientes de los datos del archivo de secuencias a los archivos de registro de transacciones. En este caso, los datos del archivo de secuencias se colocan primero en el archivo de secuencias. Estos datos sólo son necesarios en los registros de transacciones para la recuperación y el registro de avance después de una restauración. restauración. Como el registro de avance sólo

510

puede producirse si el registro circular está desactivado, los datos del archivo de secuencias sólo resultan útiles en los registros de transacciones cuando el registro circular está desactivado.

Mensajes salientes Cuando se recupera un mensaje del sistema, el proceso del almacén de Exchange recibe la lista de páginas a las que le mensaje hace referencia. Esta lista de páginas se transmite a IIS. A continuación, IIS abre un archivo en ExIFS mediante la lista de páginas. El mensaje se transmite rápidamente por secuencias fuera del almacén de información de Exchange, sin conversión.

Semántica del sistema de archivos ExIFS refleja las llamadas de archivos Win32 al almacén de Exchange. Por consiguiente, puede utilizar la API del sistema de archivos Win32 para obtener acceso a datos de Exchange Server. Por ejemplo, algunas llamadas, como FindFileFirst, pueden obtener acceso a una carpeta pública para obtener una lista de mensajes. Además, puede asignar una unidad a su propio buzón y utilizar las funciones convencionales de la línea de comandos para obtener acceso a su Bandeja de entrada. ExIFS muestra el contenido de una base de datos de Exchange como archivos normales. Interacción de ExIFS con el Explorador de Microsoft Windows y el almacén de Exchange

Esta figura ilustra que la interacción con el almacén se consigue mediante ExWin32.dll. ExIFS.sys también admite todas las funciones relacionadas con el sistema de archivos exportadas desde kernel32.dll, además de la interacción con el almacén de Exchange conseguida por medio de ExWin32.dll.

Herramienta de enlace de ExIPC La herramienta de enlace de ExIPC permite la creación y conexión de un número arbitrario de colas entre dos procesos como INETINFO y STORE. Esta herramienta de enlace incluye el Administrador central de colas para realizar el seguimiento de las colas y los procesos con los que se comunica un proceso concreto. Esta herramienta se utiliza para cancelar el enlace y limpiar las colas si se produce un error en el otro proceso.

511

Cada cola de protocolos es circular y tiene un tamaño fijo. Durante las comunicaciones entre procesos, los datos se almacenan en el montón de memoria compartida y se hace referencia a ellos mediante un identificador de datos. El identificador de datos se pone en cola y se quita de la cola. A continuación, IIS o el almacén de Exchange hace referencia a una parte de memoria compartida del identificador.

Códigos auxiliares de protocolo de ExIPC Cada protocolo tiene una interfaz de ExIPC en STORE.exe. Por ejemplo, el código auxiliar de protocolo de ExIPC para POP3 es expop.dll. Este componente transmite parámetros (por ejemplo, un puntero a un mensaje o acción) de STORE.exe a la interfaz de ExIPC (drviis.dll) en INETINFO.exe.

MAPI y RPC a través de HTTP Si el servicio de transporte de Exchange Server está configurado en Microsoft Outlook, Outlook utiliza MAPI para comunicarse con el servicio Almacén de información de Exchange. Estas llamadas MAPI se basan en RPC. Aunque las llamadas RPC funcionan bien en un entorno LAN o WAN, no se recomienda utilizarlas en Internet a causa de los servidores de seguridad y otros problemas de seguridad. En versiones anteriores de Exchange, los usuarios externos de Outlook que deseaban acceso a Exchange mediante MAPI tenían que establecer primero conexiones VPN con la red privada de su organización. El servidor proxy RPC se ejecuta en un equipo con IIS. Acepta solicitudes RPC provenientes de Internet, se conecta eficazmente a través de Internet con programas de servidor RPC y ejecuta llamadas a procedimiento remoto sin necesitar primero una conexión VPN. También realiza las comprobaciones de autenticación, validación y acceso en estas solicitudes sin tener que abrir varios puertos en el servidor de seguridad. Esto se hace con ayuda de un intermediario denominado servidor proxy RPC a través de HTTP, o servidor proxy RPC. Si la solicitud supera todas las pruebas, el servidor proxy RPC envía la solicitud al servidor RPC que realiza el procesamiento real. Con RPC a través de HTTP, el cliente y el servidor RPC no se comunican directamente. En lugar de esto, utilizan el proxy RPC como intermediario.

RPC a través de HTTP RPC a través de HTTP permite a los programas de cliente utilizar Internet para ejecutar procedimientos proporcionados por programas de servidor en redes lejanas. RPC a través de HTTP enruta sus llamadas a través de un puerto HTTP establecido. Por consiguiente, sus llamadas pueden atravesar los servidores de seguridad de red tanto en la red del cliente como en la red del servidor. El servidor proxy RPC se encuentra en la red del servidor RPC. El servidor proxy RPC establece y mantiene una conexión con el servidor RPC. Actúa como

512

proxy: envía las llamadas a procedimiento remoto al servidor RPC y devuelve las respuestas del servidor a través de Internet al programa de cliente. RPC a través de HTTP tiene requisitos de cliente y servidor, detallados en la tabla siguiente: Requisitos para implementar RPC a través de HTTP Requisitos del cliente

Microsoft Windows XP Professional con Service Pack 1 o posterior Revisión 331320 de Microsoft Knowledge Base Microsoft Office Outlook 2003

Requisitos del servidor

Microsoft Windows Server 2003 en el servidor de Exchange Exchange Server 2003 en todos los servidores de aplicaciones para el usuario y de servicios de fondo Windows Server 2003 en los servidores de catálogo global Windows Server 2003 en los servidores proxy RPC

Cuando el programa de cliente emite una RPC con HTTP como transporte, la biblioteca de tiempo de ejecución de RPC del cliente se pone en contacto con el servidor proxy RPC. En función de si el cliente RPC debe utilizar HTTP o HTTPS, se utilizará el puerto TCP 80 ó 443, respectivamente. El servidor proxy RPC se pone en contacto con el programa de servidor RPC y establece una conexión TCP/IP. El cliente y el servidor proxy RPC mantienen su conexión HTTP o HTTPS a través de Internet. La conexión HTTP o HTTPS con el servidor proxy RPC puede atravesar un servidor de seguridad (en función de los permisos de acceso adecuados), si existe. A continuación, el servidor puede ejecutar la RPC y utilizar la conexión a través del servidor proxy RPC para responder al cliente. Si el cliente o el servidor se desconectan por cualquier motivo, el servidor proxy RPC detecta que la conexión se ha interrumpido y finaliza la sesión RPC. Mientras continúa la sesión, el servidor proxy RPC mantiene sus conexiones con el cliente y el servidor. Envía las RPC del cliente al servidor y envía las respuestas del servidor al cliente. El programa de cliente RPC puede enrutar sus llamadas RPC a través de Internet mediante la creación de una cadena de enlace con el formato siguiente: [object_uuid@]ncacn_http:rpc_server[endpoint,HttpProxy=proxy_server:http_port,'rpcprox y'=rpc_proxy:rpc_port]

Donde: •

object_uuid

especifica un identificador único universal (UUID) del objeto RPC.

513

•

ncacn_http

selecciona la especificación de secuencia de protocolos para RPC a través

de HTTP. •

rpc_server

•

endpoint

es la dirección de red del equipo en el que se ejecuta el proceso de servidor de RPC. La dirección del servidor debe especificarse en un formato visible y comprensible por parte del equipo del servidor proxy RPC, en lugar de por parte del cliente. Como el cliente no se conecta directamente con el servidor, no resuelve el nombre del servidor ni establece una conexión al mismo. El servidor proxy RPC establece la conexión en nombre del cliente. Por consiguiente, servidor_rpc debe ser un nombre reconocible por parte del servidor proxy RPC. especifica el puerto TCP/IP en el que el proceso del servidor RPC escucha para detectar llamadas RPC.

•

especifica de forma opcional un servidor proxy HTTP en la red del cliente RPC, como Microsoft Proxy Server. Si se selecciona un servidor proxy y no se especifica ningún número de puerto, el código auxiliar de RPC utiliza el puerto 80 de forma predeterminada si no se solicita SSL y el puerto 443 si se especifica SSL.

•

especifica la dirección y el número de puerto del equipo con IIS que actúa como proxy del servidor RPC. Sólo deberá especificar esta opción si el proceso del servidor RPC se encuentra en un equipo diferente del servidor proxy RPC. Si no especifica un número de puerto, de forma predeterminada, el código auxiliar de RPC utiliza el puerto 80 si no se especifica SSL y el puerto 443 si se especifica SSL (HTTPS).

HttpProxy

RPCProxy

Directorio virtual de RPC Aunque RPC a través de HTTP es una característica de Windows Server 2003 y no de IIS, se implementa como una extensión de Interfaz de programación de aplicaciones para servidores de Internet (ISAPI) que se ejecuta dentro de un servidor virtual de protocolos. El directorio virtual de RPC se crea bajo Sitio Web predeterminado al instalar el servicio de servidor proxy RPC. SSL debe utilizarse junto con la autenticación básica.

RPC a través de HTTP y el servicio Almacén de información de Microsoft Exchange Aunque RPC a través de HTTP se implementa como servidor virtual de protocolos, ExIPC no participa en el proceso de comunicación. Los clientes de Outlook que utilizan RPC a través de HTTP se tratan como clientes MAPI convencionales y se comunican con el servicio Almacén de información de Microsoft Exchange mediante la interfaz MAPI con el almacén de información de Exchange.

514

Detalles de los protocolos de Internet Como se ha mencionado, Exchange 2003 admite varios protocolos de cliente basados en estándares de Internet, incluidos HTTP, POP3, IMAP4 y NNTP. Estos protocolos se tratan más detalladamente en las subsecciones siguientes.

HTTP El servicio Almacén de información de Microsoft Exchange incluye acceso HTTP nativo a datos. Se puede obtener acceso a los objetos del servicio Almacén de información de Microsoft Exchange mediante direcciones URL, con nombres cortos y fácilmente comprensibles. Como se puede obtener acceso mediante direcciones URL a todos los objetos del almacén de información de Microsoft Exchange, los usuarios tienen diferentes formas de obtener acceso a los objetos ubicados en buzones o en jerarquías de carpetas públicas. La dirección URL de un objeto se basa en su ubicación en la jerarquía y normalmente contiene el asunto del elemento. Cuando un usuario abre un mensaje a través de Microsoft Outlook Web Access, el procesador de solicitudes IIS llama a la aplicación ISAPI HTTP de Exchange que analiza la información de la solicitud y determina lo siguiente: •

La acción que debe realizarse La ISAPI HTTP de Exchange determina si el usuario abre un buzón o una carpeta, si lee o crea correo electrónico, etc.

•

Información del explorador La ISAPI HTTP de Exchange determina el tipo de explorador, la versión y la información de presentación.

A continuación, el servidor determina si el usuario dispone de permisos para obtener acceso al elemento. Si el usuario dispone de derechos de acceso, se determina el estado del objeto (leído, no leído), el tipo de objeto (carpeta, mensaje, etc.) y el tipo de elemento (mensaje, cita, contacto). La extensión de ISAPI HTTP de Exchange empareja el atributo del objeto con su definición de formulario correspondiente. Si no existe una definición de formulario para un atributo de objeto concreto, se utiliza el formulario predeterminado (el utilizado para leer un elemento de correo electrónico). Luego, la extensión de ISAPI HTTP de Exchange analiza el formulario y realiza una consulta al almacén de información para enlazar con los datos. Después de recibir los datos desde el servicio Almacén de información de Microsoft Exchange, la extensión de ISAPI HTTP de Exchange presenta los datos en HTML o XML, en función del tipo y la versión del explorador, y el cliente muestra el mensaje. Los pasos siguientes muestran este proceso más detalladamente: 1. El explorador envía una solicitud de un mensaje de correo electrónico. 2. El explorador emite una solicitud GET para una dirección URL, como http://servidor/vroot/usuario/carpeta/mensaje.eml. Esta dirección URL no tiene cadenas de consulta adjuntas, que se procesarían primero, por lo que el servidor devuelve una

515

presentación de este recurso en función de su Message-Class (clase de mensaje) y de la acción predeterminada configurada para esta clase. 3. La ISAPI de Exchange procesa la solicitud. 4. Cuando IIS recibe la solicitud, se transmite al componente de la ISAPI de Exchange Davex.dll. Este componente analiza la solicitud de la información siguiente y, a continuación, envía la solicitud al almacén de Exchange. La tabla siguiente ilustra el elemento transmitido y su finalidad. 5. A continuación, el servicio Almacén de información de Microsoft Exchange determina el tipo de elemento. 6. El servidor comprueba si el usuario tiene acceso al elemento, determina el tipo de objeto (carpeta, mensaje, tarea, etc.) y devuelve este tipo de elemento y su estado (leído, no leído, etc.) a la aplicación ISAPI. 7. La ISAPI de Exchange selecciona el formulario. 8. El programa ISAPI toma los atributos del objeto y busca una definición de formulario en el registro de formularios que coincida con el tipo de objeto. Si no se encuentra una definición de formulario coincidente, se utiliza un formulario predeterminado almacenado en Wmtemplates.dll. Si el idioma del explorador no es inglés, se cargan las cadenas específicas de idioma desde otras bibliotecas de plantillas en el directorio \Exchsrvr\Res\. 9. El servicio Almacén de información de Microsoft Exchange recupera los datos para el formulario. 10. Después de encontrar una definición de formulario, el programa ISAPI analiza el formulario y llama al servicio Almacén de información de Exchange para recuperar los datos a los que hace referencia. 11. La ISAPI de Exchange presenta el formulario. 12. Cuando el servicio Almacén de información de Microsoft Exchange devuelve los datos, el formulario se presenta en HTML o XML y, a continuación, se envía al cliente. Elementos transmitidos por Davex.dll y su utilización Elemento transmitido

Se utiliza para

Encabezado de campo HTTP User-Agent

Determinar el tipo de explorador, la versión, el sistema operativo y cómo presentar el contenido

Encabezado HTTP Accept-Language

Determinar el idioma del contenido presentado

Encabezado HTTP Translate

Determinar si el contenido se mostrará en un explorador o si debe volver sin presentación a una aplicación WebDAV

Cadena de consulta

Determinar una acción concreta que debe realizarse

516

WebDAV y XML Creación y control de versiones distribuidas en Web (WebDAV) es una extensión del protocolo HTTP 1.1 (RFC 2518). HTTP y WebDAV permiten una interacción de colaboración enriquecida con el almacén de información de Exchange 2003. La compatibilidad con HTTP de Exchange 2003 permite agregar, modificar, copiar, mover y buscar carpetas y elementos y manipular atributos en cualquier objeto del almacén de información. WebDAV crea un rendimiento y una experiencia de usuario mejorados en el cliente Microsoft Outlook Web Access básico mediante la explotación del enlace y la presentación de datos de cliente. Por ejemplo, cuando hace clic en el encabezado de una columna, puede ordenar la Bandeja de entrada de varias formas diferentes, con vistas basadas en el nombre del remitente, la línea de asunto del mensaje o la fecha de recepción. El explorador almacena en caché los elementos de la interfaz de usuario, como los componentes HTML de Internet Explorer, las bibliotecas Microsoft Jscript, XSL y los archivos de Formato de intercambio de gráficos (GIF). Cuando el usuario cambia los criterios de ordenación, el explorador puede volver a dar formato a los elementos de la interfaz de usuario de forma local y enviar una consulta al servidor sobre los datos de la vista. El proceso siguiente muestra cómo los clientes obtienen acceso a los elementos de su Bandeja de entrada mediante WebDAV: •

El cliente emite una solicitud HTTP GET para la Bandeja de entrada del cliente.

•

IIS recibe la solicitud en el puerto 80 (a menos que cambie esta configuración) y envía la solicitud a Davex.dll para su procesamiento mediante ExIPC.

•

La solicitud se reenvía mediante ExIPC al controlador OLE DB del almacén de Exchange, Exoledb.dll.

•

Exoledb.dll presenta la solicitud en un formato que el almacén de Exchange pueda procesar, envía la solicitud al almacén de Exchange y, a continuación, recupera las propiedades de la Bandeja de entrada del cliente desde el almacén de Exchange.

•

Después de recuperar las propiedades de la Bandeja de entrada del cliente, Exchange 2003 enruta la información hacia el cliente mediante los mismos componentes utilizados para procesar la solicitud del cliente.

POP3 Exchange Server 2003 implementa una pila de protocolo POP3 que cumple con RFC 1725, RFC 1734 y RFC 1939. Exchange 2003 admite los diez comandos POP3 enumerados en la tabla siguiente.

517

Verbos de comandos del protocolo POP3 Comando

Descripción

List

Se utiliza para mostrar el número de identificador y el tamaño (en bytes) de los mensajes del buzón o para mostrar el número y el tamaño de un mensaje en concreto. El comando list utiliza la sintaxis siguiente, donde n es el número del mensaje devuelto por el comando list: list o list n.

Uidl

Se utiliza para devolver una lista numérica de todos los mensajes del buzón y de sus Id. únicos asociados o el Id. único de un mensaje en concreto. El comando uidl utiliza la sintaxis siguiente, donde n es el número del mensaje (devuelto por el comando list) de la uidl que desea ver: uidl o uidl n.

Retr

Se utiliza para recuperar un mensaje del servidor. Este comando no puede utilizarse para recuperar un mensaje marcado como eliminado. El comando retr utiliza la sintaxis siguiente, donde n es el número del mensaje devuelto por el comando list: retr n.

Stat

Devuelve el número total de mensajes del buzón y el tamaño total (en bytes) de los mensajes. Este comando no puede utilizarse para mostrar más información acerca de mensajes individuales. Para hacerlo, deberá utilizar los comandos list o retr, según corresponda.

Dele

Se utiliza para seleccionar un mensaje para su eliminación. Cuando selecciona un mensaje para su eliminación, el mensaje se elimina después de utilizar el comando quit para desconectar el cliente del servidor. Si la conexión se interrumpe de forma inesperada, los mensajes no se eliminan. El comando dele utiliza la sintaxis siguiente, donde n es el número del mensaje devuelto por el comando list: dele n.

518

Comando

Descripción

Rset

Se utiliza para cancelar la selección de todos los mensajes seleccionados para su eliminación.

Noop

Se traduce como "sin operación". Aunque este comando no realiza ninguna acción, si tiene un resultado correcto, el servidor contesta con una respuesta positiva (OK+). Este comando puede utilizarse para comprobar si el servidor está conectado y recibe solicitudes de los clientes.

Top

Se utiliza para mostrar el encabezado del mensaje y un número concreto de líneas del mensaje. Utiliza la sintaxis siguiente, donde x es el número del mensaje que desea ver e y es el número de líneas del mensaje que desea mostrar: top xy.

Auth

Comando IMAP que forma parte de la especificación POP3, tal y como se detalla en la Solicitud de comentarios (Request for Comments, RFC) 1734 del Grupo de trabajo de ingeniería en Internet (Internet Engineering Task Force, IETF). Le permite utilizar mecanismos de autorización IMAP4 alternativos.

Quit

Se utiliza para salir de la sesión POP3 actual y eliminar los mensajes seleccionados para su eliminación.

POP3 se considera un protocolo de sólo lectura. Sólo incluye mensajes para solicitar, leer y eliminar mensajes. Para enviar mensajes, los clientes POP3 utilizan el protocolo SMTP. Los pasos siguientes ilustran los pasos de comunicación entre procesos que sigue ExIPC cuando un cliente como Microsoft Outlook obtiene acceso a un buzón en el servidor de Exchange mediante el protocolo POP3.

519

Arquitectura de memoria compartida de IIS y Exchange Server

1. El cliente inicia sesión en el servidor y emite un comando para comprobar si hay correo electrónico. 2. Se crea un comando de solicitud de mensaje de correo 1 en IIS. 3. IIS asigna memoria compartida del montón de memoria compartida a la solicitud. Se asigna un identificador correspondiente a parte de la memoria compartida. El indicador, que actúa como marcador de posición o puntero a una parte de la memoria a la que se hace referencia, se coloca en la cola de memoria circular (puesto en cola) en la dirección del almacén de información de Exchange. 4. En el almacén de Exchange, ExIPC.DLL para POP3 comprueba si existen solicitudes POP3 entrantes. La DLL recibe la solicitud de mensaje de correo y quita el identificador de la cola de memoria circular. El código auxiliar POP3 del almacén de Exchange hace referencia al identificador de los datos en el montón de memoria compartida. 5. Si no hay errores ni problemas de rendimiento en el almacén de Exchange, el proceso ExIPC finaliza y los datos se comunican correctamente desde IIS al almacén de Exchange. Si la cola está llena o el almacén de Exchange se ha detenido, se devuelve un mensaje de error. 6. En el almacén de Exchange se genera una respuesta (el mensaje de correo). El almacén de información de Exchange asigna la memoria compartida adecuada a la respuesta desde el montón de memoria compartida. Se asigna un identificador correspondiente dicha memoria compartida. A continuación, el identificador se pone en cola, en la dirección de IIS. 7. IIS quita el identificador de la cola circular, hace referencia a la memoria compartida y los enlaza. Si no hay errores ni problemas de rendimiento en IIS, la respuesta finaliza y los datos se comunican correctamente desde el almacén de Exchange a IIS.

IMAP4 Exchange 2003 cumple con IMAP4 rev 1, de acuerdo con RFC 2060, RFC 2088 y RFC 1731. IMAP se compone de más de 30, mediante los cuales se pueden buscar, recuperar y eliminar mensajes del servidor de Exchange. IMAP funciona bien tanto con

520

conexión como sin conexión. IMAP puede conectarse a varios buzones (si se dispone de los permisos correspondientes) y carpetas públicas y puede utilizarse para fines distintos del correo electrónico, como servicios de noticias. IMAP4 sobrepasa la funcionalidad disponible con POP3. IMAP4 permite a los usuarios obtener acceso a cualquiera de sus carpetas, no sólo a la Bandeja de entrada. Por este motivo, es más complejo que POP3. No obstante, también es un protocolo de sólo lectura. Como POP3, IMAP4 también utiliza SMTP para enviar correo electrónico. Exchange 2003 admite los comandos IMAP4 enumerados en la tabla siguiente. Comandos IMAP4 admitidos por Exchange Server 2003 Comando

Descripción

APPEND

Anexa el argumento literal como nuevo mensaje al final del buzón de destino especificado. Este argumento debe estar en formato de mensaje RFC-822.

AUTHENTICATE

Indica un mecanismo de autenticación al servidor (por ejemplo, AUTHENTICATE KERBEROS_V5).

CAPABILITY

Se utiliza para solicitar una lista de capacidades admitidas por el servidor.

CHECK

Se utiliza para solicitar un punto de control del buzón seleccionado actualmente. Punto de control se refiere a cualquier detalle dependiente de la implementación asociado con el buzón (por ejemplo, resolver el estado en memoria del buzón del servidor con el estado en su disco) que no se ejecuta como parte de cada comando.

CLOSE

Elimina permanentemente del buzón seleccionado actualmente todos los mensajes que tienen definido el indicador \Deleted y vuelve al estado autenticado desde el estado seleccionado.

COPY

Se utiliza para copiar los mensajes especificados al final del buzón de destino especificado. Los indicadores y la fecha interna de los mensajes se conservan en la copia.

521

Comando

Descripción

CREATE

Se utiliza para crear un buzón con un nombre concreto. Se devuelve una respuesta correcta sólo si se crea un buzón nuevo con dicho nombre concreto.

DELETE

Elimina permanentemente un buzón con un nombre concreto. Se devuelve una respuesta etiquetada como correcta sólo si se elimina el buzón.

EXAMINE

Funciona igual que SELECT y devuelve el mismo resultado. No obstante, el buzón seleccionado se define como de sólo lectura. No se permiten cambios en el estado permanente del buzón, incluido el estado por usuario.

EXPUNGE

Elimina permanentemente del buzón seleccionado actualmente todos los mensajes que tienen definido el indicador \Deleted.

FETCH

Recupera los datos asociados con un mensaje en el buzón.

LIST

Devuelve un subconjunto de nombres del conjunto completo de todos los nombres disponibles para el cliente.

LOGIN

Identifica el cliente en el servidor y lleva la contraseña de texto sin formato que autentica a este usuario.

LOGOUT

Comunica al servidor que el cliente ha finalizado la conexión.

LSUB

Devuelve un subconjunto de nombres del conjunto de nombres que el usuario ha declarado como "activos" o "suscritos".

522

Comando

Descripción

NOOP

Se traduce como "sin operación". Aunque este comando no realiza ninguna acción, si tiene un resultado correcto, el servidor contesta con una respuesta positiva (OK+). Este comando puede utilizarse para comprobar si el servidor está conectado y recibe solicitudes de los clientes.

RENAME

Cambia el nombre de un buzón. Se devuelve una respuesta etiquetada como correcta sólo si se cambia el nombre del buzón.

SEARCH

Busca en el buzón mensajes que coincidan con los criterios de búsqueda especificados. Los criterios de búsqueda constan de una o varias claves de búsqueda.

SELECT

Selecciona un buzón, para poder obtener acceso a los mensajes del mismo.

STATUS

Solicita el estado del buzón indicado. No cambia el buzón seleccionado actualmente ni afecta al estado de los mensajes del buzón en el que se ha realizado la consulta.

STORE

Cambia los datos asociados con un mensaje en el buzón.

SUBSCRIBE

Agrega el nombre del buzón especificado al conjunto devuelto por el comando LSUB de buzones "activos" o "suscritos" del servidor. Este comando devuelve una respuesta etiquetada como correcta sólo si la suscripción se realiza correctamente.

UID

Este comando tiene dos formatos: En el primero, toma como argumento un comando COPY, FETCH o STORE con los argumentos adecuados para el comando asociado. En el segundo, el comando UID toma un comando SEARCH con argumentos de dicho comando.

523

Comando

Descripción

UNSUBSCRIBE

Elimina el nombre del buzón especificado del conjunto devuelto por el comando LSUB de buzones "activos" o "suscritos" del servidor. Este comando devuelve una respuesta etiquetada como correcta sólo si la cancelación de la suscripción se realiza correctamente.

NNTP El Protocolo de transferencia de noticias a través de la red (NNTP) es un protocolo TCP/IP basado en cadenas de texto que se envían de forma bidireccional a través de canales TCP ASCII de siete bits. El protocolo NNTP es propiedad de IETF y se define en RFC 977. NNTP se denomina habitualmente Protocolo de noticias de Internet, porque contiene las reglas utilizadas para transportar artículos de noticias de un equipo a otro. NNTP se trata aquí como protocolo cliente-servidor. También engloba la transferencia de noticias basada en servidor a servidor. El servicio NNTP de Windows está diseñado para admitir un servidor independiente de grupos de noticias que puede crear fácilmente discusiones en grupo. Cuando instala Exchange 2003, el servicio NNTP se mejora con la capacidad de conexión con otros servidores de noticias mediante suministros de noticias. El servicio NNTP puede comunicarse con servidores NNTP externos para poner los grupos USENET más conocidos a disposición de los usuarios. La ubicación de almacenamiento estándar del servicio NNTP se encuentra en uno o varios directorios del sistema de archivos. Con Exchange Server 2003, el servicio NNTP también puede almacenar grupos de noticias en las carpetas públicas de cualquier árbol de carpetas públicas disponible. La carpeta Grupos de noticias de Internet es la ubicación predeterminada de los grupos de noticias. El servicio NNTP utiliza directorios virtuales para hacer referencia a estas ubicaciones. Puede organizar varios servidores de noticias en un diseño servidor maestro-servidor subordinado. Esto permite a los clientes conectarse con un gran grupo de servidores y seguir manteniendo vistas precisas del contenido de los grupos de noticias. Un banco o grupo de servidores proporciona escalabilidad adicional para muchos clientes y tolerancia a errores si un servidor subordinado se desconecta. La implementación en Exchange Server 2003 de NNTP ofrece las siguientes características adicionales para este protocolo: •

La indización de contenido proporciona características de búsqueda a las carpetas públicas.

524

•

Se aceptan suministros de noticias completas independientemente del almacenamiento del servidor de servicios de fondo.

•

Los clientes MAPI o NNTP pueden leer o publicar mensajes en los grupos de noticias admitidos por el almacén de información de Exchange.

Opciones de configuración en Active Directory Aunque Exchange se integra con IIS, una vez instalado Exchange 2003, el Administrador del sistema de Exchange administra los servidores virtuales d de e protocolos en lugar del Administrador de servicios Internet. Al agregar, quitar o configurar un elemento en el Administrador del sistema de Exchange, los cambios en la configuración se almacenan primero en el servicio de directorio Microsoft Active Directory tory y, a continuación, la función de sincronización de servicio de directorio directorio-metabase metabase (DS2MB) que se ejecuta en el proceso Operador de sistema replica estos cambios en la metabase de IIS, en el servidor de Exchange 2003 correspondiente. Nota: semi gráfica de la información de configuración de Puede ver una representación semi-gráfica Exchange 2003 almacenada en Active Directory en el artículo 252370 de Microsoft Knowledge Base, "Layout Layout of Exchange Configuration in Active Directory". Directory

Opciones de configuración en la metabase La metabase de IIS es una metabase jerárquica utilizada para almacenar valores de configuración para IIS y Exchange 2003. Es un mecanismo de almacenamiento y un conjunto de interfaz de programación de aplicaciones (API) utilizado para realizar cambios en los os parámetros de configuración. La finalidad del proceso DS2MB es transferir información de configuración desde Active Directory a la metabase de IIS local del servidor de Exchange. Por motivos de rendimiento y escalabilidad, esta configuración se almacena almacena en la metabase de IIS local en lugar de en el Registro. Nota: En equipos con Windows 2000 Server, la metabase de IIS se encuentra en System32\Inetsrv\Metabase.bin. Metabase.bin. En equipos con Windows Server 2003, la metabase de IIS se encuentra en metabase.xml. La metabase de IIS puede manipularse con diversas herramientas. En equipos con Windows Server 2003, puede utilizarse la herramienta integrada IISCNFG. En equipos con Windows 2000 Server, una buena opción es la herramienta MetaEdit 2.2 o posterior, incluida en n el Kit de recursos de IIS. Puede descargar el Kit de recursos de IIS 6.0 en el sitio Web Internet Information Services (IIS) 6.0 Resource Kit Tools. Tools Las rutas de acceso de la metabase se denominan denominan claves. Cada clave puede tener definidas propiedades y cada propiedad puede tener atributos que la personalicen. Todos los

525

identificadores existentes en la imagen del servicio de directorio del subárbol son obligatorios en la metabase, incluidos identificadores identificadores como KeyType. Además, el nombre completo relativo (RDN) del objeto del directorio se asigna directamente al nombre de la clave en la metabase.

Actualizaciones de la metabase de IIS mediante DS2MB DS2MB es un subproceso que se inicia al iniciar el Operador Operador de sistema y que se reproduce cada 15 minutos posteriormente. DS2MB copia todos los subárboles de Active Directory sin cambiar su forma. Es una escritura de un sentido, desde Active Directory a la metabase; la metabase nunca escribe en Active Directory. tory. No agrega ni calcula ningún atributo al realizar la copia. Nota: El proceso DS2MB sobrescribe los cambios realizados en los directorios y servidores virtuales de Exchange mediante el complemento de IIS con la información contenida en Active Directory. El funcionamiento de SMTP, POP3, IMAP4 y HTTP depende de la replicación realizada por DS2MB. No todas las opciones se sincronizan desde Active Directory, sino que algunas se escriben en la metabase directamente durante la instalación de Exchange. Al crear ear las instancias, DS2MB se registra con el controlador de dominio de configuración. El controlador de dominio de configuración informa a DS2MB, en un plazo de 15 segundos, de cualquier cambio realizado en la configuración de Exchange. Tan pronto como el cambio se replica en el controlador de dominio de configuración, DS2MB debe replicarlo en la metabase.

Marcas de agua máxima Las marcas de agua máxima son entradas en la metabase que permiten a DS2MB realizar el seguimiento de los cambios sincronizados des desde Active Directory. Las entradas de marcas de agua máxima se indican en la metabase de IIS en forma de GUID. Estos GUID aparecen en el nodo [/DS2MB/HighWaterMarks] de la metabase, tal y como se ilustra a continuación: [/DS2MB/HighWaterMarks] KeyType : (STRING) "Ds2mbHighwatermarks" [/DS2MB/HighWaterMarks/{BE583A06 [/DS2MB/HighWaterMarks/{BE583A06-9083-400F-954C-CF4ACCA78B04}] [/DS2MB/HighWaterMarks/{028C8F78 [/DS2MB/HighWaterMarks/{028C8F78-8CF0-43D9-9B35-9819D538849F}] [/DS2MB/HighWaterMarks/{84ECD394 [/DS2MB/HighWaterMarks/{84ECD394-05BB-4661-BA1D-81D3E32BF804}]

Como DS2MB controla trola la entrada y la sincronización de marcas de agua máxima en la metabase, normalmente no será necesario ajustar o administrar esta información. No obstante, en algunos casos conocidos, la solución incluye la eliminación de las entradas de marca de agua máxima de la metabase para reiniciarlas.

526

Arquitectura del servidor de aplicaciones para el usuario Un servidor de aplicaciones para el usuario es un servidor en el que se ejecuta Exchange Server 2003 que no aloja una base de datos (excepto cuando también actúa como servidor SMTP), sino que reenvía solicitudes de los clientes al servidor de servicios de fondo para su procesamiento. El servidor de aplicaciones para el usuario utiliza el protocolo ligero de acceso a directorios (LDAP) para enviar una consulta a Active Directory destinada a determinar cuál es el servidor de servicios de fondo que aloja el buzón del usuario. Un servidor de servicios de fondo es un servidor en el que se ejecuta Exchange Server 2003 y que mantiene como mínimo una base de datos. Esta arquitectura está disponible sólo para clientes RPC a través de HTTP, HTTP/WebDAV, POP3 e IMAP4. No está pensada para clientes MAPI o NNTP. Los clientes admitidos se conectan con un servidor de aplicaciones para el usuario que actúa como proxy para los comandos de los clientes dirigidos al servidor de servicios de fondo del usuario, que aloja un almacén de información de Exchange. Esta división funcional entre un servidor de aplicaciones para el usuario y un servidor de servicios de fondo ofrece varias ventajas. Por ejemplo: •

Espacio de nombres único Como varios servidores de servicios de fondo están configurados para tratar buzones adicionales, se recomienda identificar todos los servidores con un único nombre. Puede hacer referencia a un servidor de aplicaciones para el usuario con un único nombre y puede actuar como proxy para las solicitudes de usuario y dirigirlas al servidor de servicios de fondo correcto que contiene el buzón de dicho usuario. Si se configuran varios servidores de aplicaciones para el usuario para administrar un gran número de solicitudes, se mantiene un único espacio de nombres para estos servidores si se configura el Sistema de nombres de dominio (DNS) con un nombre asignado a la dirección IP del servidor. No importa a qué servidor de aplicaciones para el usuario se conecta el cliente.

•

Descarga de SSL Cifrar y descifrar el tráfico de mensajes ocupa muchos ciclos de CPU. Un servidor de aplicaciones para el usuario puede realizar tareas de cifrado, lo que proporciona al servidor de servicios de fondo más ciclos para administrar los almacenes de información de buzones y carpetas públicas.

•

Referencias a carpetas públicas para clientes IMAP4 Muchos clientes IMAP4 no admiten referencias. Con esta arquitectura, el servidor de aplicaciones para el usuario puede recuperar las carpetas públicas de un servidor distinto del servidor de correo electrónico del usuario.

•

Ubicación de los servidores Puede aumentar la protección de los servidores de servicios de fondo que contienen las bases de datos mediante un servidor de seguridad. Puede configurar el servidor de seguridad para permitir sólo el tráfico proveniente del servidor de aplicaciones para el usuario. Además, puede colocar un servidor proxy inverso (como ISA Server) enfrente del servidor de aplicaciones para el usuario y sólo publicar este último. No es necesario publicar los servidores de buzones de servicios de

527

fondo en Internet. Por consiguiente, puede configurar los servidores de seguridad y los servidores proxy inversos para permitir sólo el tráfico proveniente del servidor de aplicaciones para el usuario.

Consideraciones acerca del uso de servidores de aplicaciones para el usuario Puede configurar Exchange Server 2003 Standard Edition o Exchange Server 2003 Enterprise Edition para su uso como servidor de aplicaciones para el usuario en una configuración de servidor de aplicaciones para el usuario y servidor de servicios de fondo. Al configurar cualquiera de estas dos ediciones como servidor de aplicaciones para el usuario, tenga en cuenta lo siguiente: •

Si el servidor de aplicaciones para el usuario acepta correo SMTP de Internet, deberá iniciar el servicio Almacén de información de Microsoft Exchange y montar como mínimo un almacén de buzones. En ciertas situaciones (principalmente en la generación de informes de no entrega), el servicio SMTP necesita un almacén de buzones para realizar la conversión.

•

Si el almacén de buzones no está montado, los mensajes que deben convertirse se bloquean en la cola de entrega local. Por motivos de seguridad, asegúrese de que los buzones de los usuarios no se encuentran en el almacén de buzones de un servidor de aplicaciones para el usuario. Si hay servidores en los que se ejecuta Exchange Server 5.5 en el mismo sitio (grupo de enrutamiento), deberá configurar el servicio Microsoft Exchange - Pila MTA para que se ejecute en el servidor de aplicaciones para el usuario. En esta configuración, los MTA pueden enlazar y transferir correo mediante RPC.

•

Si hay conectores X.400 o conectores de puerta de enlace del Kit de desarrollo de Exchange (EDK) en el servidor de aplicaciones para el usuario, el servicio MTA también debe ejecutarse en este servidor. Si elimina todos los almacenes de carpetas públicas y buzones, no podrá cambiar la configuración mediante el Administrador de servicios Internet.

•

Si debe cambiar la configuración mediante el Administrador de servicios Internet, por ejemplo, al cambiar la configuración del cifrado SSL, asegúrese de que realiza los procedimientos descritos en esta guía antes de eliminar los almacenes o deje el almacén de información privada sin cambios en el servidor de aplicaciones para el usuario.

•

Cuando cree un servidor de aplicaciones para el usuario, no elimine el objeto Primer grupo de almacenamiento en el Administrador del sistema de Exchange. El servicio Almacén de información de Microsoft Exchange y los servicios relacionados con éste dependen del objeto Administrador del sistema de Exchange.

528

Exchange ActiveSync y Exchange 2003 Exchange ActiveSync permite sincronizar datos entre un dispositivo móvil y Exchange Server 2003. Se puede sincronizar el correo electrónico, los contactos y la información de calendario (datos del Administrador de información personal o PIM). Esta característica estaba disponible anteriormente mediante Mobile Information Server y se denominaba Microsoft Server ActiveSync. Ahora está integrada en Exchange Server 2003. Con Mobile Information Server, los dispositivos con Microsoft Windows Powered Pocket PC 2002, Microsoft Windows Powered Pocket PC 2002 Phone Edition y Microsoft Windows Powered Smartphone tenían el componente de cliente Server ActiveSync instalado y eran compatibles. Con Exchange ActiveSync, los dispositivos que ejecutan Pocket PC 2002, Pocket PC 2002 Phone Edition y Smartphone todavía son compatibles. Además, también son compatibles los dispositivos con Microsoft Windows Powered Pocket PC 2003. Los dispositivos Pocket PC 2003 permiten una mayor granularidad a la hora de programar la sincronización y también admiten la funcionalidad Siempre actualizado introducida en Exchange Server 2003. Exchange ActiveSync se implementa en los archivos siguientes: •

Massync.dll

DLL de extensión ISAPI de sincronización OMA

•

Masperf.dll

DLL de contador de rendimiento de sincronización OMA

•

MasPerf.ini

INI de contador de rendimiento de sincronización OMA

•

Masperf.h

Encabezado de contador de rendimiento de sincronización OMA

Arquitectura del protocolo Exchange ActiveSync El protocolo de sincronización es un protocolo de solicitud y respuesta creado a partir de un modelo de comunicaciones cliente-servidor. Se basa en el protocolo HTTP y utiliza la solicitud y el mecanismo de respuesta HTTP POST y el comando HTTP OPTIONS. El encabezado HTTP POST especifica un comando de protocolo y, si el comando lo necesita, los datos del mismo se envían en el cuerpo de HTTP POST. Normalmente, los datos están en formato XML binario inalámbrico (WbXML) comprimido, que realiza un uso eficaz del ancho de banda limitado de los clientes móviles. El cliente inicia la comunicación mediante la publicación de una solicitud. Cuando el servidor recibe la solicitud, la analiza y, a continuación, envía una respuesta HTTP POST que contiene los datos solicitados en el cuerpo. El protocolo de sincronización necesita una conexión TCP/IP entre el cliente y el servidor. No obstante, las capas de red subyacentes son específicas de cada implementación. Tres capas de transporte habituales que admiten el protocolo son GPRS, CDMA 1xRTT e IEEE 802.11. Al utilizar el protocolo de sincronización, el software de red debe tratar los errores de

529

transmisión y los mensajes de protocolo enviados entre el cliente y el servidor deben ser completos y no deben tener errores. El protocolo de sincronización está diseñado para permitir a cualquier cliente móvil sincronizar eficazmente datos PIM con datos almacenados en un servidor de Exchange. Para ello, el cliente utiliza el protocolo de sincronización para comunicarse con el componente de servidor de aplicaciones para el usuario de Exchange, que proporciona la sincronización como medio para obtener datos del almacén de Exchange. La figura siguiente muestra los componentes funcionales del modelo de comunicaciones cliente-servidor utilizado por el protocolo de sincronización. Comunicación de Exchange ActiveSync entre el cliente y el servidor

Para todos los comandos que el cliente envía al servidor se llevan a cabo las siguientes operaciones: 1. El cliente crea una solicitud y la envía al servidor de sincronización como HTTPS POST. 2. El servidor de sincronización procesa la solicitud y se comunica con el servidor de servicios de fondo de Exchange para obtener acceso a los datos PIM del usuario. 3. El servidor de sincronización crea una respuesta y la envía al cliente como respuesta HTTPS POST. 4. El cliente procesa la respuesta y, si resulta necesario, actualiza los datos PIM locales. Cuando el cliente envía un comando de sincronización se llevan a cabo las siguientes operaciones: 1. El cliente identifica los cambios realizados en los datos PIM locales desde la última sincronización. 2. El cliente crea un comando de sincronización (Sync) que contiene estos cambios. 3. El cliente envía el comando al servidor de sincronización como HTTPS POST.

530

4. El servidor de sincronización identifica los cambios realizados en los datos del servidor desde la última sincronización y se comunica con el servidor de servicios de fondo de Exchange para obtener acceso a los datos del usuario. 5. El servidor de sincronización resuelve cualquier conflicto entre los cambios realizados en elementos del cliente y del servidor. 6. El servidor de sincronización crea una respuesta que contiene los cambios del servidor que deben replicarse en el cliente. 7. El servidor de sincronización la respuesta como respuesta HTTPS POST. 8. El cliente procesa la respuesta y actualiza los datos PIM locales.

Versiones del protocolo de sincronización y compatibilidad con dispositivos Exchange ActiveSync requiere que el cliente y el servidor utilicen la misma versión de protocolo. Microsoft Mobile Information Server utiliza el protocolo ActiveSync v1.0 para Exchange ActiveSync. Exchange Server 2003 utiliza el protocolo nuevo y mejorado ActiveSync v2.0 para Exchange ActiveSync, pero también admite el protocolo ActiveSync v1.0 para compatibilidad con versiones anteriores. Protocolos ActiveSync admitidos por Mobile Information Server 2002 y Exchange Server 2003 Servidor

Protocolos admitidos

Mobile Information Server 2002

1.0

Exchange Server 2003

1.0 y 2.0

El cliente Pocket PC 2002 utiliza el protocolo ActiveSync v1.0 para Exchange ActiveSync. Puede utilizarse con Mobile Information Server y Exchange Server 2003 mediante la versión 1.0. El cliente Pocket PC 2003 admite las versiones 1.0 y 2.0 del protocolo. Puede negociar el protocolo que se utilizará. Tabla 9.6 Protocolos ActiveSync admitidos por dispositivos Pocket PC 2002 y Pocket PC 2003 Dispositivo

Protocolos admitidos

Pocket PC 2002

1.0

Pocket PC 2003

1.0 y 2.0

Por consiguiente, los dispositivos Pocket PC 2002 y Pocket PC 2003 pueden utilizarse con Mobile Information Server y Exchange 2003.

531

Comandos del protocolo de sincronización Con el protocolo ActiveSync v 1.0, una sesión de sincronización normal incluye los siguientes comandos: •

GetHierarchy Este comando se utiliza para recuperar toda la jerarquía de carpetas.

•

GetItemEstimate El cliente utiliza este comando para calcular el número de elementos que deben sincronizarse. El cliente transmite una lista de carpetas para las que desea realizar el cálculo. Este cálculo facilita la visualización de la barra de progreso en el dispositivo.

•

Sync Este comando se utiliza para iniciar una sincronización. El comando Sync también tiene otros comandos incrustados (como Add y Change).

La versión 2.0 del protocolo ActiveSync admite dos comandos adicionales: Folder sync y AUTD (Siempre actualizado): •

Folder Sync Se utiliza este comando en lugar del comando GetHierarchy. El comando FolderSync sincroniza la jerarquía de la colección de la misma forma que se sincronizan las carpetas individuales.

•

AUTD Este comando permite al usuario sincronizar automáticamente el dispositivo móvil con el servidor a medida que se reciben elementos nuevos en el servidor. Para obtener más información, consulte la sección "Notificaciones de actualización", más adelante en este tema.

Formato del comando de sincronización Los comandos del protocolo se envían mediante el mecanismo HTTP POST. En el Identificador unificado de recursos (URI) de la solicitud del cliente se incluyen algunos comandos sencillos y los comandos más complejos utilizan el cuerpo HTTP para transmitir más información acerca del comando. A menudo, una sesión de sincronización se compone de varios comandos. En este caso, la sesión consistirá en varios pares de solicitudes de comandos y respuestas enviadas entre el cliente y el servidor. Una solicitud consta de tres partes: •

URI Esta parte incluye la dirección del servidor y varios parámetros, incluido el nombre del comando.

•

Encabezado HTTP Esta parte incluye parámetros adicionales utilizados por el servidor y que se transmiten en formato HTTP estándar.

•

Cuerpo HTTP Esta parte incluye los datos requeridos por el comando. El formato depende del comando y algunos comandos no tienen cuerpo.

URI El siguiente ejemplo incluye un URI de solicitud de sincronización típico:

532

POST /Microsoft-Server-ActiveSync?User=johndoe& DeviceId=789123456789012345&DeviceType=PocketPC&Cmd=Sync

El cliente envía parámetros como Cmd, User y DeviceId con cada solicitud. El parámetro más importante es Cmd. El parámetro Cmd indica al servidor qué operación debe realizar. En este ejemplo, el argumento Sync transmitido en el parámetro Cmd indica al servidor que debe realizarse una operación de sincronización. El cuerpo HTTP POST contiene datos adicionales.

Encabezado HTTP Además del URI, el cliente también envía información general en el encabezado HTTP. El siguiente ejemplo muestra el encabezado completo de la solicitud HTTP POST, junto con el URI: POST Microsoft-Server-ActiveSync?User=johndoe& DeviceId=789123456789012345&DeviceType=PocketPC&Cmd=Sync Accept-Language: en-us MS-ASProtocolVersion: 2.0 Content-Type: application/vnd.ms-sync.wbxml

El servidor responde con información general en el encabezado. La entrada siguiente contiene el encabezado de respuesta HTTP POST: HTTP/1.1 200 OK Content-Length: 114 Date: Mon, 15 Mar 2004 11:07:44 GMT Content-Type: application/vnd.ms-sync.wbxml Server: Microsoft-IIS/6.0 MicrosoftOfficeWebServer: 5.0_Pub X-Powered-By: ASP.NET Pragma: no-cache MS-Server-ActiveSync: 2.0.3273.0

Cuerpo HTTP El cuerpo de la solicitud contiene datos enviados al servidor. El tipo y el formato de los datos dependen del comando. El formato más habitual es XML y los detalles dependen del comando. Los comandos que envían mensajes de correo electrónico utilizan el formato RFC 822 en lugar de XML. Algunos comandos no requieren datos adicionales. En ese caso, el cuerpo está vacío. El cuerpo de la respuesta contiene datos devueltos por el servidor. Como en el caso del cuerpo de la solicitud, el formato depende del comando. Normalmente, está en formato WbXML. Si el cuerpo contiene datos adjuntos de correo electrónico, el formato depende del tipo de archivo adjunto. Algunos comandos no utilizan el cuerpo. Datos de multidifusión independientes de protocolo en el dispositivo móvil

533

Los datos de multidifusión independientes de protocolo se almacenan en "colecciones": una para los contactos, una para el calendario y una para cada una de las carpetas de correo electrónico. El protocolo de sincronización admite la sincronización de varias carpetas de correo electrónico. Para cada colección, el software cliente almacena una SyncKey (clave de sincronización). La SyncKey contiene de 39 a 48 caracteres, 38 para el identificador único global (GUID) y de una a diez para el número de incremento. El cliente también almacena un CollectionId (Id. de colección). El CollectionId es una cadena de unos 40 caracteres para cada carpeta y es un identificador único de la carpeta. El cliente envía la SyncKey al servidor con cada solicitud de sincronización. Cada objeto que se sincroniza, ya sea un mensaje, un contacto o un elemento de calendario, tiene un identificador único asignado por el servidor. Este ServerId es una cadena de 48 caracteres que se almacena en el cliente. El identificador se utiliza durante la sincronización para identificar los objetos que se almacenan tanto en el cliente como en el servidor.

Perfil de Exchange ActiveSync El estado de sincronización se almacena en una carpeta oculta del buzón del usuario en el servidor de Exchange. El estado de sincronización para el correo electrónico, el calendario y los contactos y FolderSync se encuentran en la carpeta Microsoft-ServerActiveSync/PocketPC/DeviceId del NON_IPM_SUBTREE del buzón de un usuario. La carpeta Search, que contiene la jerarquía de carpetas, también se almacena aquí.

Notificaciones de actualización Exchange ActiveSync está configurado en el dispositivo para sincronizarse con el servidor a intervalos, con una frecuencia de hasta cinco minutos. No obstante, ActiveSync no proporciona información actualizada acerca del dispositivo. El usuario también puede incurrir en gastos adicionales por las frecuentes sesiones de sincronización. Notificaciones de actualización es una nueva característica de Exchange Server 2003 que permite al usuario sincronizar automáticamente un dispositivo Pocket PC 2003 o Microsoft Windows Mobile 2003 con el servidor cuando éste recibe nuevos elementos. Notificaciones de actualización es una característica de Exchange ActiveSync que se instala con Exchange Server 2003. Cuando llega un mensaje nuevo, se genera un suceso en la cuenta de Exchange del usuario. Este suceso hace que se envíe una notificación SMS al dispositivo del usuario. El dispositivo se sincroniza en segundo plano. Los datos del usuario se actualizan a la información más reciente, sin intervención por parte del usuario. La notificación se envía como mensaje de control SMS al dispositivo. Es diferente de una notificación SMS normal, porque no aparece como mensaje SMS en la Bandeja de entrada.

534

El enrutador de SMS y Exchange ActiveSync en el dispositivo procesan la notificación. La notificación no incluye datos confidenciales. Las notificaciones pueden enviarse desde Exchange Server 2003 directamente a la dirección SMS del dispositivo o a través de un agregador (por ejemplo, un proveedor de servicios corporativos) configurado por el administrador de Exchange. Para que las notificaciones se envíen a la dirección SMS del dispositivo, el administrador debe crear un operador SMTP en el Administrador del sistema de Exchange.

Agregadores Las organizaciones pueden decidir enviar notificaciones a los dispositivos a través de un agregador. El único agregador disponible actualmente es MSN Internet Access. Para establecer un agregador, la organización debe iniciar sesión en un sitio Web seguro mediante una cuenta de Passport y seleccionar los operadores que desea utilizar mediante MSN. A continuación, la organización puede obtener credenciales de MSN para la entrega de notificaciones seguras. Después deberá crearse el operador de MSN en Active Directory. Se incluye un archivo diferente, MSNCarrierConfigurator.zip. Este archivo contiene CreateMSNCarrier.cmd y CarrierConfig.LDF, que se utilizan para configurar el operador de MSN. Después de crear el operador de MSN en Active Directory, el administrador crea un conector SMTP para la entrega de notificaciones seguras a MSN con las credenciales recibidas cuando el usuario se suscribe. Cuando un administrador configura un operador SMTP para enviar notificaciones directamente a la dirección SMS del dispositivo, la notificación pasa por la puerta de enlace SMTP en el operador móvil y, a continuación, al Centro SMS (SMS-C) del operador. Las puertas de enlace SMTP de los operadores se asocian con frecuencia con latencias altas de los mensajes y los plazos de entrega de SMS a veces son superiores a una hora. Esto anula las ventajas de las notificaciones de actualización y no ofrece una experiencia actualizada al usuario. También hay problemas de seguridad a la hora de reenviar mensajes a través de un operador de puerta de enlace SMTP. Puede utilizar un agregador para conectarse a través de Seguridad de nivel de transporte (TLS) a Microsoft Mobile Services. Esto permite a una empresa conectar uno o varios de los operadores con los que Microsoft Mobile Services ha creado asociaciones actualizadas.

Outlook Mobile Access y Exchange 2003 Microsoft Exchange Server 2003 incluye una solución de exploración móvil denominada Outlook Mobile Access. Outlook Mobile Access genera código HTML, xHTML y cHTML para su visualización en dispositivos móviles de la lista de dispositivos aprobados. También se genera Lenguaje de marcado inalámbrico (WML) pero Microsoft no ha probado WML para

535

todas las configuraciones de dispositivos y puertas de enlace. Por consiguiente, WML no se admite. No obstante, la mayoría de dispositivos son compatibles con Outlook Mobile Access. Outlook Mobile Access se instala de forma predeterminada, pero está deshabilitado globalmente (aunque todos los usuarios están habilitados para acceso móvil). La experiencia del usuario es similar a Microsoft Outlook Web Access. La conexión a Outlook Mobile Access se realiza mediante una dirección URL, normalmente http://nombre-de-servidor/oma. Sin embargo, al contrario que Microsoft Outlook Web Access, no se puede especificar una cuenta de usuario específica en la dirección URL. Esto se debe a que Outlook Mobile Access agrega un identificador único a la dirección URL como parte de la administración del estado de sesión. Outlook Mobile Access admite las siguientes características de mensajería y colaboración: •

Correo electrónico Leer, Responder, Reenviar, Eliminar, Marcar, Redactar mensajes, desplazamiento por varias carpetas y búsqueda del remitente o de otros destinatarios.

•

Calendario Aceptar y Rechazar convocatorias de reunión, convocatorias de reunión provisionales, desplazamiento por el control de selección de fecha y redacción y modificación de citas con compatibilidad para asistentes.

•

Contactos Ver, Crear, Modificar contactos personales, búsqueda de contactos en listas globales de direcciones (GAL), guardar contactos GAL en contactos personales y enviar correo electrónico y llamar a contactos.

•

Tareas Ver, Crear y Modificar tareas.

Dependencias de Outlook Mobile Access Outlook Mobile Access tiene varias dependencias, incluidos .NET Framework, la administración del estado de sesión de IIS y un Id. de sesión de dirección URL modificado. El programa Outlook Mobile Access se basa en .NET Framework. De forma predeterminada, Windows Server 2003 instala .NET Framework, mientras que en Windows 2000 Server se debe agregar. Si .NET Framework no está instalado, el programa de instalación de Exchange se encarga de hacerlo. Outlook Mobile Access también requiere el método de autenticación básica, OMA.ASPX como documento predeterminado y que la ruta de acceso ejecutable del directorio virtual de Outlook Mobile Access se configure como aspx,C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\aspnet_isapi.dll,1,GET,HEAD,POST,DEB UG.

Outlook Mobile Access y .NET Outlook Mobile Access es el único componente de Exchange 2003 que utiliza .NET Framework. Es imposible comprender la base de Outlook Mobile Access sin conocimientos básicos de .NET Framework. Outlook Mobile Access permite ver el buzón con un explorador móvil. Esta sección ofrece una explicación básica de .NET Framework y ASP.NET relativa a su aplicación a Exchange 2003 Outlook Mobile Access y a la movilidad en general.

536

.NET Framework .NET Framework tiene dos componentes principales: Common Language Runtime y la biblioteca de clases de .NET Framework. Common Language Runtime es la base de .NET Framework. Es un agente que administra el código en tiempo de ejecución. Proporciona servicios básicos, como administración de memoria y administración de subprocesos y exige seguridad estricta de tipos y otras formas de precisión del código que contribuyen a solucionar problemas de seguridad y de solidez. De hecho, el concepto de administración de código es un principio fundamental del tiempo de ejecución. El código destinado al tiempo de ejecución se denomina código administrado y el código no destinado al tiempo de ejecución se denomina código no administrado. La biblioteca de clases es una colección completa orientada a objetos de tipos reutilizables que se utilizan para desarrollar aplicaciones que van desde aplicaciones convencionales de línea de comandos o de interfaz gráfica de usuario (GUI) a aplicaciones basadas en las innovaciones más recientes proporcionadas por los Formularios Web de ASP.NET y los servicios Web XML.

ASP.NET ASP.NET permite a los programadores utilizar .NET Framework para dirigirse a aplicaciones basadas en Web. ASP.NET es más que un host de tiempo de ejecución. ASP.NET es una arquitectura completa para desarrollar sitios Web y objetos distribuidos por Internet mediante código administrado. Tanto los Formularios Web como los servicios Web XML utilizan IIS y ASP.NET como mecanismo de publicación para las aplicaciones. Ambos tienen una colección de clases auxiliares en .NET Framework. .NET Framework también proporciona una colección de clases y herramientas para ayudar en el desarrollo de controles móviles. Los controles móviles se utilizan para desarrollar aplicaciones para dispositivos portátiles y dependen del dispositivo. Los controles móviles reducen el tiempo de programación y garantizan que se devuelve el lenguaje de marcado correcto al dispositivo cliente. ASP.NET Framework 1.1 proporciona una abstracción de una interfaz de usuario con objetos que representan los componentes fundamentales de una representación gráfica, como etiquetas de texto y cuadros de entrada de datos. El tiempo de ejecución debe convertir esta representación abstracta en lenguaje de marcado específico del dispositivo. ASP.NET proporciona controles de Formularios Web móviles que representan componentes individuales de la interfaz de usuario. Estos componentes se utilizan para definir una interfaz de usuario en una página Web. ASP.NET entrega el contenido en el lenguaje de marcado correspondiente al dispositivo que realiza la solicitud. Hay dos protocolos de cliente principales que utilizan los exploradores: cHTML y xHTML. ASP.NET presenta automáticamente los elementos correctos para el dispositivo inalámbrico especificado.

537

Administración de sesiones Como se mencionó al principio de esta sección, Outlook Mobile Access requiere la administración de estados de sesión para poder funcionar correctamente. En realid realidad, el protocolo HTTP no contiene información sobre el estado, ya que no proporciona ningún mecanismo para identificar o mantener sesiones entre un servidor Web y un cliente. Este problema se soluciona en ASP mediante un objeto Session que permite identifi identificar de forma inequívoca a un usuario y almacenar información específica de la interacción de ese usuario con un servidor Web. ASP.NET ofrece una versión actualizada y mejorada del objeto Session. Este objeto permite realizar las siguientes tareas: •

Identificar tificar a un usuario a través de un Id. de sesión exclusivo

•

Almacenar información específica de la sesión de un usuario

•

Administrar la sesión mediante métodos de controlador de sucesos

•

Liberar datos de la sesión tras agotarse el tiempo de espera especificado especificado

Outlook Mobile Access utiliza el tratamiento predeterminado de estados de sesión en curso y el método de URL modificada de administración de sesiones de ASP.NET.

Id. de sesión de URL modificada Una dirección URL modificada es aquélla que contiene un Id. de sesión. Este Id. adopta el formato de la dirección URL estándar con un identificador exclusivo agregado entre la aplicación y la página Web (como http://servidor/oma/(a5db038hclb4b1g5ukhrsu55)/oma.aspx). Cuando el servidor Web recibe la solicitud,, analiza el Id. de sesión de la dirección URL modificada. A continuación, el motor de tiempo de ejecución utiliza el Id. de sesión como si se tratara de un Id. de sesión obtenido de una cookie. Si el cliente no admite cookies, el motor de tiempo de ejecución ejecuc no utiliza automáticamente direcciones URL modificadas. Nota: Puede haber problemas con los dispositivos móviles que no admiten direcciones URL modificadas para un Id. de sesión. Algunos exploradores de equipos inalámbricos tienen problemas al tratar con direcciones URL relativas una vez que éstas se han redirigido a una URL modificada. El problema se produce porque estos exploradores admiten longitudes de direcciones URL mucho más cortas que las que admiten los exploradores de equipos de sobremesa. Una Una aplicación profundamente anidada en una jerarquía podría requerir direcciones URL con una longitud superior a la admitida por algunos exploradores.

Actualizaciones de dispositivos de ASP.NET Las actualizaciones de dispositivos móviles se incorporan en Actualizaciones de dispositivos de .NET Framework. Al fin y al cabo, Outlook Mobile Access se deriva de estas clases base.

538

Las Actualizaciones de dispositivos (DU) están programadas de manera provisional para aplicarse cada trimestre. Todas las modificaciones necesarias para permitir el procesamiento adecuado en un dispositivo determinado se incluyen en el archivo web.config en la raíz del directorio de exploración. Este archivo se actualiza durante las actualizaciones de dispositivos, y se sobrescriben todas las modificaciones. No es aconsejable que los administradores y programadores modifiquen la configuración de web.config para un dispositivo que Microsoft no haya probado. Normalmente, no habrá problemas de interoperabilidad entre el dispositivo móvil y Exchange, pero no se ofrece soporte para tales modificaciones, y podría ocurrir que se eliminara la utilidad de depuración de Outlook Mobile Access.

Arquitectura de Outlook Mobile Access Para el procesamiento y el acceso a los datos, se utiliza CDOEX, DAV, las plantillas de Microsoft Outlook Web Access y los servicios de system.directory incluidos en el proceso de Outlook Mobile Access. Para obtener las opciones de configuración se lee Active Directory, el Registro, la metabase de IIS y el archivo web.config. Outlook Mobile Access debe recibir las credenciales de usuario en texto sin cifrar mediante la autenticación básica. Outlook Mobile Access no es compatible ni funciona con la autenticación integrada de Windows aunque el dispositivo o explorador admita este modo de autenticación. ASP.NET funciona junto con IIS, .NET Framework y los servicios de seguridad subyacentes proporcionados por el sistema operativo, para ofrecer una serie de mecanismos de autenticación y autorización.

Plantillas de Outlook Mobile Access y Microsoft Outlook Web Access Web Distributed Authoring and Versioning (WebDAV) proporciona acceso sin cifrar a la mayoría de los datos alojados en Exchange. Algunas tareas comunes, como la aceptación o la creación de convocatorias de reunión y la resolución de destinatarios de correo electrónico ambiguos, son difíciles de implementar con WebDAV. Normalmente, Microsoft Outlook Web Access responde a una solicitud del usuario con una página HTML. El motor de tiempo de ejecución no utiliza automáticamente direcciones URL modificadas si el cliente no admite cookies. El formato de la página de respuesta viene determinado por las plantillas. Outlook Mobile Access aprovecha la funcionalidad de Microsoft Outlook Web Access. Utiliza plantillas personalizadas para controlar la información y el formato de la información devuelta por las funciones de Microsoft Outlook Web Access. Estas plantillas devuelven los datos en un formato similar a una respuesta de WebDAV. De esta forma, se permite la unificación del formato de los datos devueltos por las funciones que utilizan Microsoft Outlook Web Access para la recuperación de los datos y por las que utilizan WebDAV.

539

WebDAV es el componente base para la mayoría de las operaciones del Proveedor de datos de Exchange de Outlook Mobile Access. El protocolo WebDAV, diseñado para el acceso general a los datos, amplía HTTP a HTTP 1.1, con lo que se permite el almacenamiento de los datos en el servidor y su recuperación por el cliente HTTP. Las operaciones básicas son: •

Desplazarse por las carpetas

•

Enumerar los elementos de las carpetas

•

Buscar elementos en las carpetas

•

Obtener detalles de los elementos

•

Modificar los atributos de mensajes, contactos y tareas

•

Enviar mensajes redactados

Las clases del Proveedor de datos de Exchange proporcionan la interfaz con el servidor Exchange para las funciones que no se obtienen de Microsoft Outlook Web Access.

Orígenes de datos de Outlook Mobile Access Outlook Mobile Access recupera la configuración y otros datos de una serie de orígenes, entre los que se incluyen Active Directory, la metabase de IIS, el Registro de Windows y Web.config. Para recuperar datos de un usuario a través de WebDAV y de las plantillas de Microsoft Outlook Web Access es necesario que Outlook Mobile Access cree la dirección URL de WebDAV/OWA del modo siguiente: http://<nombreServidor>/<nombreDirectorioVirtual>/. En este caso, el valor de <nombreServidor> se recupera del objeto User del usuario que ha iniciado sesión. En topologías de bosques cruzados, esta información se lee de la cuenta de usuario deshabilitada en el bosque de recursos. El <nombreDirectorioVirtual> se recupera del Registro de ExchangeVDir. Determinar el correcto es más complejo. La única forma de determinar el nombre del buzón de un usuario es buscar la dirección SMTP del usuario para el buzón. Encontrará este valor en el objeto User. Sin embargo, este método presenta un problema. Puede que el atributo contenga varias direcciones SMTP para el usuario. La dirección SMTP correcta viene determinada por el dominio SMTP del buzón en cuestión. El dominio SMTP se configura mediante el Administrador del sistema de Exchange para cada directorio virtual de Microsoft Outlook Web Access, Outlook Mobile Access y Exchange ActiveSync. Esto permite que en el mismo servidor de aplicaciones para el usuario pueda haber varios directorios virtuales de Outlook Mobile Access y que cada uno de ellos represente un dominio de SMTP exclusivo. Esta configuración se almacena en el directorio con un dominio SMTP para cada directorio virtual y para cada servidor Exchange. Outlook Mobile Access, así como Exchange ActiveSync y Microsoft Outlook Web Access, no tienen acceso de lectura a este atributo. Los derechos de acceso están restringidos porque es una configuración de administrador. El proceso DS2MB no tiene acceso de lectura. El proceso de resolución del buzón es el siguiente:

540

1. El Administrador del sistema de Exchange escribe un valor de dominio SMTP en Active Directory para un determinado directorio virtual de un servidor específico. 2. DS2MB en ese servidor recupera la configuración y la replica en la metabase de IIS en el equipo. 3. Outlook Mobile Access lee el dominio SMTP del directorio virtual en el que se está ejecutando. 4. Outlook Mobile Access busca las direcciones SMTP en el objeto User de Active Directory (en las topologías de bosques cruzados, esta información se lee de la cuenta de usuario deshabilitada en el bosque de recursos de Exchange). 5. Outlook Mobile Access recupera de la lista la dirección SMTP que utiliza el dominio SMTP. 6. La dirección SMTP tiene el formato <nombreBuzón>@<dominio SMTP>, Outlook Mobile Access extrae el <nombreBuzón>. Los valores de <nombreServidor>, <nombreDirectorioVirtual> y juntos proporcionan la dirección URL de DAV/OWA necesaria para el servidor de servicios de fondo.

Configuración de directorios de Outlook Mobile Access Outlook Mobile Access lee las opciones de configuración de Active Directory siempre que se crea una nueva sesión (y sólo cuando se crea una nueva sesión). En las dos tablas siguientes, se describen las opciones de configuración de Outlook Mobile Access de todo el bosque y específicas del usuario en Active Directory. Opciones de configuración de Outlook Mobile Access de todo el bosque Configuración de directorios

Descripción

Outlook Mobile Access

El nodo raíz de Outlook Mobile Access bajo la configuración de Active Directory de Exchange. Contiene atributos globales de Outlook Mobile Access y contenedores para más opciones de Outlook Mobile Access.

541

Configuración de directorios

Descripción

msExchOmaAdminWirelessEnable

Control de administración para los servicios móviles disponibles: Bit 0: Inserción OMA Bit 1: Exploración de OMA Bit 2: Sincronización OMA Bit 30: Exploración con dispositivos no probados Bit 31: Inserción a través de la dirección SMTP especificada por el usuario 0 = Habilitado. 1 = Deshabilitado. El valor predeterminado establecido por el programa de instalación de Exchange está deshabilitado.

msExchOmaExtendedProperties

Reservada para la ampliación de características en el futuro (sin necesidad de cambiar el esquema de Active Directory).

Configuración de directorios de Outlook Mobile Access para cada usuario Configuración de directorios

Descripción

msExchOmaAdminExtendedSettings

Espacio para la configuración de un usuario controlada por el administrador. Ejemplo: Permitir/impedir el acceso a características como el calendario o los contactos en Outlook Mobile Access.

msExchOmaExtendedProperties

Reservada para la ampliación de características en el futuro (sin necesidad de cambiar el esquema de Active Directory).

Los atributos del objeto de usuario heredan tres listas de control de acceso (ACL) del contenedor del objeto de usuario: Administradores del dominio, Sistema local en controladores de dominio y Operadores de cuentas. Cada uno de estos principales de seguridad tiene permisos completos de lectura y escritura en la configuración del usuario. Asimismo, los dos atributos mostrados en la tabla 9.8 forman parte del conjunto de propiedades de información pública, que otorga a los usuarios autenticados acceso de lectura. Los atributos del contenedor de configuración de Outlook Mobile Access se heredan del nodo Organización y, a continuación, se agrega el acceso de lectura para los usuarios autenticados.

542

Puesto que esta configuración de directorios sólo se lee al inicio de una nueva sesión, si se cambia, las sesiones en curso no resultan afectadas. Por ejemplo, al deshabilitar a un usuario para Outlook Mobile Access, ese usuario no queda inmediatamente bloqueado en la sesión en curso. El usuario no advertirá que el acceso se ha deshabilitado hasta que intente establecer una nueva sesión de Outlook Mobile Access.

Outlook Mobile Access y DS2MB DS2MB en Exchange 2003 afecta a todas las aplicaciones basadas en Web de Exchange. Entre éstas se incluyen Outlook Web Access, Outlook Mobile Access y Exchange ActiveSync. Outlook Mobile Access tiene algunos valores de configuración que dependen del directorio, pero eliminar el directorio virtual de Outlook Mobile Access es un método habitual para solucionar los problemas de replicación del directorio en la metabase. IIS obtiene la configuración correcta de la metabase local. La información relacionada con IIS se almacena en Active Directory y el proceso DS2MB la replica en una dirección desde el directorio hasta la metabase. DS2MB se ejecuta con el Operador de sistema en cada equipo que ejecuta Exchange 2000 o una versión posterior. DS2MB recibe notificaciones de los cambios en el directorio y se encarga de realizar el trabajo. Si descubre que la metabase local no está sincronizada con el directorio, puede forzar una actualización manual del directorio manipulando la siguiente clave de metabase. LM\DS2MB\HighWaterMarks\{056BE186-E73F-4EBD-A92D-2D985BC97C63}\61472

Al cambiar los datos de este valor a 0 (cero) o al eliminar la clave y reiniciar el Operador de sistema, se replica toda la información de directorios en la metabase. Cuando se inicia el Operador de sistema, la clave se agrega a la metabase con el valor predeterminado. La metabase se puede manipular mediante varias herramientas. Si Exchange 2003 se ejecuta en Windows Server 2003, se puede utilizar la herramienta IISCNFG integrada. Si Exchange se ejecuta en Windows 2000, se puede utilizar MetaEdit 2.2 o una versión posterior.

Outlook Mobile Access y el Registro de Windows Outlook Mobile Access utiliza cinco claves del Registro. Una se utiliza para los contadores de rendimiento y las otras cuatro para la configuración. Una clave se comparte con Exchange ActiveSync y las otras tres se comparten con Outlook Web Access. Estas claves se encuentran en HKLM\SYSTEM\CurrentControlSet\Services. Las claves del Registro se describen en la tabla siguiente.

543

Valores del Registro relevantes para Outlook Mobile Access Clave

Valor

Descripción

MasSync\Parameters\Exchan /Exchange u otra cadena que geVDir empiece por /

Especifica el directorio virtual que ActiveSync y Outlook Mobile Access deben utilizar para tener acceso a las plantillas de Outlook Web Access y a WebDAV en los servidores de servicios de fondo de Exchange en los que se encuentran los buzones de los usuarios. Si este clave no existe o es nula, se utiliza el valor predeterminado /Exchange. De lo contrario, esta clave contiene el nombre del directorio virtual, incluida la barra diagonal (/).

MSExchangeWEB\OWA\Use RegionalCharset

Si esta clave está establecida en '1', Outlook Web Access y Outlook Mobile Access utilizan los juegos de caracteres regionales cuando envían correo electrónico. Si no existe o está establecida en otro valor, Outlook Web Access y Outlook Mobile Access utilizan UTF-8 para el envío de correo electrónico. El juego de caracteres regionales utilizado se determina en función del idioma del cliente especificado por el usuario.

1 o nada

MSExchangeWEB\OWA\UseI 1 o nada SO8859_15

Cuando está establecida en '1', se utiliza el juego de caracteres iso-8859-15 allí donde se utilizaría iso-88591.

544

Clave

Valor

Descripción

MSExchangeWEB\OWA\Use GB18030

1 o nada

Cuando está establecida en '1', se utiliza el juego de caracteres GB18030 allí donde se utilizaría GB2312.

MSExchangeOMA\Performan N/D ce

Utilizada para publicar los objetos y contadores de rendimiento de Outlook Mobile Access.

Outlook Mobile Access y Web.Config En la sección del archivo Web.config se encuentra la configuración de Outlook Mobile Access para los distintos exploradores móviles y versiones de Internet Explorer. No ajuste esta configuración, ya que está incluida en las Actualizaciones de dispositivos de .NET Framework. Hay algunas opciones en el archivo web.config que el usuario puede configurar, que se describen en la tabla siguiente. Configuración de Web.config para Outlook Mobile Access Sección

Opción

Descripción





Define el número de minutos que Outlook Mobile Access conserva los vales Kerberos en la memoria caché para el acceso a DAV y a las plantillas de Outlook Web Access.

Outlook Mobile Access puede abrir en un servidor de servicios de fondo.

545

<system.web>



Indica a Outlook Mobile Access cuántos milisegundos debe esperar para las respuestas procedentes del servidor de servicios de fondo antes de que se agote el tiempo de espera.

/OMAD evices">

Cuando se define este mensaje, se muestra texto adicional en la advertencia de incompatibilidad y en las páginas de errores de incompatibilidad. Esta clave es nula de forma predeterminada.

<sessionState mode="InProc" cookieless="true" timeout="20" />

Especifica la configuración del estado de sesión utilizada por Outlook Mobile Access.

<mobileControls SessionStateHistorySize="8" >

Especifica cuántas páginas anteriores debe controlar el estado de la sesión (lo que permite al usuario definir el botón Atrás del dispositivo y hacer que los vínculos a las páginas funcionen).



Define el juego de caracteres predeterminado que Outlook Mobile Access utiliza para enviar respuestas HTTP e interpretar las solicitudes de entrada que no tienen un juego de caracteres especificado.

El valor de tiempo de espera indica cuántos minutos se conserva en memoria el estado de la sesión después de que llega la última solicitud para la sesión.

546



supportsBackNavWithExpires Determina si Outlook Mobile Header Access envía el encabezado Caduca en todas las solicitudes con un valor de 10/08/2000 10:28. La finalidad de enviar una fecha y hora pasadas es obligar a que el contenido caduque. preferredResponseCharset

Establece Response.Charset en este valor para todas las solicitudes.

preferredResponseCodePag e

Establece Response.ContentEncoding en el entero especificado. El valor de tiempo es el mismo que el de Response.Charset.

preferredRequestCodePage

Establece Request.ContentEncoding en el entero especificado. Debe tener el mismo valor de tiempo establecido que el de Response.Charset.

supportsOpenwaveUniversal LocalSrc

Indica a Outlook Mobile Access que inserte claves de acceso delante de los vínculos.

defaultTextboxMaxlength

Establece la longitud máxima de las cadenas permitida en los controles de cuadro de texto. P800, por ejemplo, se establecerá de forma predeterminada en 64 si no se especifica este valor.

Solicitudes del cliente de Outlook Mobile Access Cuando un cliente de Outlook Mobile Access envía una solicitud Web, se produce la siguiente secuencia de sucesos de autenticación y autorización:

547

1. La solicitud Web HTTP(S) se recibe desde la red. Se puede utilizar SSL para comprobar la identidad del servidor. SSL proporciona también un canal de seguridad para ayudar a proteger los datos confidenciales transferidos entre cliente y servidor. 2. IIS autentica al usuario que realiza la llamada mediante la autenticación básica. IIS crea un testigo de acceso a Windows para el usuario autenticado. 3. IIS autoriza el acceso al recurso solicitado al usuario que realiza la llamada. Para autorizar el acceso se utilizan los permisos del sistema de archivos NTFS definidos por las listas de control de acceso (ACL) asociadas al recurso solicitado. 4. IIS pasa el testigo de acceso de Windows Server del usuario autenticado a ASP.NET.

Arquitectura de seguridad de Outlook Mobile Access La arquitectura de seguridad que subyace a Outlook Mobile Access varía en función de si Exchange 2003 se ejecuta en Windows Server 2003 o Windows 2000 Server. En Windows Server 2003, Outlook Mobile Access se ejecuta en su propio proceso en un grupo de programas dedicado, ExchangeMobileBrowseApplicationPool. Outlook Mobile Access se ejecuta como la cuenta de servicio de red en un proceso de trabajo de ASP.NET (W3WP.EXE). En un equipo basado en Windows 2000, Outlook Mobile Access se ejecuta en un proceso junto con otras aplicaciones de ASP.Net en el mismo equipo. Outlook Mobile Access se ejecuta como la cuenta ASPNET en un proceso de trabajo de ASP.NET (ASPNET_WP.EXE). La extensión ISAPI de ASP.NET, ASPNET_ISAPI.DLL, se ejecuta en un proceso bajo Inetinfo.exe. Este proceso se controla mediante la entrada de la metabase InProcessIsapiApps. ASPNET_ISAPI.DLL es responsable de enviar las solicitudes al proceso de trabajo de ASP.NET. A continuación, los programas de ASP.NET se ejecutan en el proceso de trabajo de ASP.NET, en el que los dominios del programa proporcionan límites de aislamiento. IIS 6.0 aísla los programas de ASP.NET configurando grupos de programas, en los que cada grupo tiene su propia instancia de aplicación (Outlook Mobile Access está incluido en el grupo ExchangeMobileBrowseApplication).

Arquitectura del servicio Almacén de información de Exchange El repositorio principal de almacenamiento de datos de Microsoft Exchange Server 2003 es el servicio Almacén de información de Microsoft Exchange, que contiene datos de almacén de buzones y de almacén de carpetas públicas. El servicio Almacén de información de Microsoft Exchange utiliza un motor de base de datos llamado Motor de almacenamiento extensible (ESE), una tecnología de base de datos basada en transacciones.

548

En esta sección se explica la función que desempeña el servicio Almacén de información de Microsoft Exchange en el sistema de mensajería de Exchange Server 2003. El servicio Almacén de información de Microsoft Exchange, como su nombre indica, implementa el almacén de Exchange. Este almacén contiene buzones y carpetas públicas. El almacén de Exchange también es responsable de la replicación de carpetas públicas, responsabilidad que se describe en una sección aparte debido a su complejidad. En esta sección se explican los siguientes conceptos: •

Arquitectura de almacenamiento de Exchange Exchange Server 2003 utiliza una arquitectura de almacenamiento basada en transacciones que incluye un archivo de base de datos, un archivo de contenido nativo, registros de transacciones y otros archivos, como archivos de punto de control y registros reservados. Debe comprender cómo Exchange Server 2003 utiliza estos archivos para almacenar los datos de mensajería.

•

Arquitectura del Motor de almacenamiento extensible El Motor de almacenamiento extensible es el componente básico del almacén de Exchange. Debe estar familiarizado con el Motor de almacenamiento extensible para comprender la arquitectura del almacén de Exchange.

•

Responsabilidades del almacén de Exchange En la arquitectura cliente/servidor de Exchange Server 2003, el servicio Almacén de información de Microsoft Exchange tiene acceso exclusivo a las bases de datos de mensajería. El acceso exclusivo a las bases de datos implica una serie de responsabilidades con las que debe estar familiarizado para comprender la función que desempeña el servicio Almacén de información de Microsoft Exchange.

•

Replicación de carpetas públicas La replicación de carpetas públicas permite mantener varias instancias de la misma carpeta pública en distintos servidores Exchange y mantener estas instancias sincronizadas. Esta característica se utiliza para proporcionar a los usuarios de un organización de Exchange distribuida acceso a una copia local de las carpetas públicas. Las carpetas públicas replicadas sirven también para aumentar la tolerancia a errores de las soluciones de grupos de trabajo. Debe saber cómo el almacén de Exchange replica los datos de las carpetas públicas en una organización de Exchange.

Para obtener información acerca de la administración del almacén de Exchange, así como sobre la copia de seguridad y la recuperación tras un desastre, consulte Exchange Server 2003 Administration Guide.

Arquitectura de almacenamiento de Exchange Los servidores de Exchange almacenan los datos en dos archivos: un archivo .edb y un archivo .stm. Juntos, el archivo .edb y el archivo .stm forman un repositorio de almacén de

549

Exchange. Por ejemplo, el almacén de buzones predeterminado de un servidor Exchange utiliza los archivos Priv1.edb y Priv1.stm. El almacén de carpetas públicas predeterminado utiliza los archivos Pub1.edb y Pub1.stm. El archivo .edb contiene muchas tablas que albergan metadatos de todos los mensajes de correo electrónico y otros elementos del almacén de Exchange, así como el conten contenido ido de los mensajes MAPI. El archivo .edb es una base de datos ESE y, como se utiliza principalmente para almacenar mensajes y datos adjuntos MAPI, se denomina también base de datos basada en MAPI. El archivo .stm, sin embargo, almacena contenido de Internet Internet nativo. Puesto que el contenido de Internet se escribe en formato nativo, no es necesario convertir los mensajes ni demás elementos al formato de Exchange (como ocurría en Exchange 5.5 y versiones anteriores). El archivo .stm es también una base de dato datoss ESE, denominada base de datos de secuencias. Los archivos .edb y .stm funcionan a la par, y la firma de base de datos (un número aleatorio de 32 bits combinado con la hora de creación de la base de datos) se almacena como encabezado en ambos archivos. El esquema interno de las páginas .stm se almacena en el archivo .edb. Nota: Puede cambiar el nombre de las bases de datos .edb y .stm y moverlas a directorios distintos en el Administrador del sistema de Exchange. Puesto que los archivos .edb y .stm juntos s crean un repositorio completo del almacén de Exchange, debe mantenerlos juntos y asignarles un nombre común con extensiones distintas (.edb y .stm). Exchange Server 2003 utiliza transacciones para controlar los cambios en los grupos de almacenamiento. Estas transacciones se recogen en un registro de transacciones, de forma similar a como se almacenan las transacciones en las bases de datos tradicionales. Los cambios se validan o se deshacen en función del éxito de la transacción. Si se produce un error, se utilizan los registros de transacciones (juntos con los archivos de base de datos y, en algunas ocasiones, el archivo de punto de control) para restaurar la base de datos. La utilidad que administra las transacciones es el servicio Almacén de información informaci de Microsoft Exchange (Store.exe). Todas las entradas no validadas del registro de transacciones se consideran también parte de una base de datos Exchange actual, como se ilustra en la figura siguiente. Base de datos actual de Exchange Server 2003

Hayy dos tipos de bases de datos disponibles en Exchange Server 2003: •

Bases de datos de almacén privado Estas bases de datos almacenan buzones y colas de mensajes para los conectores de mensajería basados en MAPI.

550

•

Bases de datos del almacén público Estas bases de datos almacenan jerarquías y contenido de carpetas públicas.

En la figura siguiente se ilustra la arquitectura interna del almacén de Exchange. El servicio Almacén de información de Microsoft Exchange (Store.exe) utiliza el Motor de almacenamiento extensible (ESE) para obtener acceso a los archivos de base de datos en el sistema de archivos, y proporciona acceso a los datos a través de distintas interfaces, como MAPIsvr, ExPOP, ExIMAP, ExSMTP y ExOLEDB. Las interfaces de programación de aplicaciones y aplicaciones cliente, como Objetos de datos de colaboración para Exchange (CDOEX), pueden utilizar estas interfaces o comunicarse con el módulo de base de datos de mensajería (MDB). Arquitectura del almacén de Exchange

Grupos de almacenamiento Cada grupo de almacenamiento está formado por un conjunto de archivos de registro y archivos auxiliares (bases de datos temporales internas, el archivo de punto de control y los registros reservados) para todas las bases de datos (archivos .edb y .stm) del grupo. Exchange Server 2003 admite varios grupos de almacenamiento y varias bases de datos en cada grupo de almacenamiento. En Exchange Server 2003, un servidor admite hasta cuatro grupos de almacenamiento y un grupo de almacenamiento admite hasta cinco bases de datos. Gracias a la compatibilidad con varias bases de datos, se puede distribuir un gran número de buzones y carpetas públicas entre muchas bases de datos más pequeñas y, de ese modo, facilitar la administración de las bases de datos. Exchange 2000 Server y Exchange Server 2003 admiten hasta 20 bases de datos de buzones y carpetas públicas en un único servidor.

Arquitectura de los grupos de almacenamiento Como se ilustra en la figura siguiente, todos los grupos de almacenamiento se alojan desde el mismo proceso Store.exe. Cada grupo de almacenamiento se representa por una instancia de ESE.

551

Arquitectura de los grupos de almacenamiento

Dentro de cada grupo de almacenamiento, cada pareja de bases de datos .edb y .stm representa un almacén de buzones buzones o un almacén de carpetas públicas. Como se muestra en la figura 10.3, todos los almacenes de buzones y carpetas públicas de un determinado grupo de almacenamiento comparten un conjunto común de archivos de registro y otros archivos del sistema. Estos archivos rchivos permiten el procesamiento orientado a transacciones. Los archivos de registro y otros archivos del sistema de cada grupo de almacenamiento tienen los siguientes fines: •

xxx.chk Éste es el archivo de punto de control (por ejemplo, E00.chk) que determina qué transacciones deben procesarse para moverlas desde los archivos de registro de transacciones a las bases de datos. Los archivos de punto de control se actualizan cuando ESE escribe una determinada transacción en un archivo archi de base de datos de un disco. Esta actualización hace que el archivo de punto de control apunte siempre a la última transacción que se ha transferido correctamente a la base de datos, lo que proporciona un mecanismo rápido de recuperación. Sin embargo, los archivos de punto de control no son necesarios para validar transacciones en las bases de datos. ESE tiene la capacidad de procesar directamente archivos de registro de transacciones y determinar por sí mismo qué transacciones aún no se han transferido. transferido Este proceso es bastante más lento que utilizar puntos de control. Nota: El Motor de almacenamiento extensible garantiza que las transacciones no se escriban varias veces en una base de datos.

•

Exx.log Éste es el archivo actual del registro de transacciones del grupo de almacenamiento. Los archivos de registro de transacciones permiten que ESE administre el almacenamiento de datos con gran rapidez. ESE almacena las nuevas transacciones, como la entrega entrega de un mensaje, en memoria caché y en el registro de transacciones a la vez. Los datos se escriben secuencialmente. Los nuevos datos se agregan a los existentes sin necesidad de operaciones de bases de datos complejas. Posteriormente, las transacciones se transfieren en grupo desde la memoria caché a las bases de datos reales, que las actualizan. De forma predeterminada, el grupo de almacenamiento predeterminado, llamado Primer grupo de almacenamiento, utiliza el prefijo E00, lo que produce un archivo de registro de

552

transacciones denominado E00.log. El archivo E00.log se utiliza para todos los almacenes de buzones y carpetas públicas de este grupo de almacenamiento. Si crea otros grupos de almacenamiento, el número de prefijo se incrementa en E01, E02 y E03. E0 •

XXXXX.log Éstos son los archivos de registro de transacciones que no contienen más espacio para otros datos. De forma predeterminada, los archivos de registro de transacciones tienen un tamaño exacto de 5.242.880 bytes (cinco megabytes). egabytes). En teoría, es posible, aunque no recomendable, cambiar el tamaño de los archivos de registro. Cuando un registro está lleno, se cambia de nombre para permitir la creación de un nuevo archivo de registro de transacciones vacío. Los archivos de registro gistro de transacciones renombrados se denominan archivos de registro anteriores. El formato de nombre de los archivos de registro anteriores es XXXXX.log (como E00XXXXX.log), donde XXXXX representa un número hexadecimal de cinco dígit dígitos os desde 00000 a FFFFF. Los archivos de registro anteriores residen en los mismos directorios que el archivo de registro de transacciones actual.

•

Res1.log y Res2.log Éstos son archivos de registro de transacciones reservados para el grupo de almacenamiento. almacenamiento. Los archivos de registro reservados son un repositorio de emergencia de las transacciones. Proporcionan espacio en disco suficiente para escribir una transacción desde la memoria al disco duro, aunque el disco de un servidor esté demasiado lleno para admitir nuevas transacciones en un archivo de registro. Los archivos de registro reservados se encuentran en el directorio de registro de transacciones. Se crean automáticamente cuando se inicializan las bases de datos. No se pueden crear posteriormente. ESE sólo utiliza estos archivos para realizar un proceso de transacción actual. A continuación, envía una notificación de error a Store.exe para desmontar de forma segura el almacén de Exchange. El registro de sucesos de aplicación contiene una entrada que e indica el problema. En esta situación, deberá crear espacio libre adicional en el disco duro (por ejemplo, deberá agregar un nuevo disco duro) antes de volver a montar la base de datos.

•

Tmp.edb Ésta es un área de trabajo temporal para el procesamiento procesamiento de transacciones. Tmp.edb contiene información temporal que se elimina cuando se desmontan todos los almacenes del grupo de almacenamiento o cuando se detiene el servicio Almacén de información de Exchange. Nota: Tmp.edb no se incluye en las copias d de seguridad en línea.

•

<nombre de archivo>.edb Éstos son archivos de base de datos de texto enriquecido para almacenes privados o públicos. El archivo de base de datos de texto enriquecido del almacén privado predeterminado se llama Priv1.edb. El archivo archivo del almacén público predeterminado se llama Pub1.edb.

•

<nombre de archivo>.stm Éstos son archivos de contenido de secuencias de Internet para bases de datos individuales. El archivo de base de datos de secuencias del

553

almacén privado predeterminado se llama Priv1.stm. El archivo del almacén público predeterminado se llama Pub1.stm.

Atributos del grupo de almacenamiento en Active Directory Puede determinar la ruta de acceso de un archivo de registro de transacciones de un grupo de almacenamiento y su nombre en el Administrador del sistema de Exchange. Haga clic con el botón secundario del mouse (ratón) en el grupo de almacenamiento que desee, seleccione Propiedades y, en la ficha General, examine la información de los campos Ubicación del registro de transacciones y Prefijo del archivo de registro. Mediante los botones Examinar, puede mover los archivos de registro de transacciones y del sistema a una nueva ubicación, como otra unidad física. Las opciones de configuración de los grupos de almacenamiento se almacenan en Active Directory. Si desea utilizar Edición de ADSI para localizar el objeto de directorio de un grupo de almacenamiento, debe abrir el contexto de nomenclatura de configuración, expandir los nodos de los servicios, expandir CN=Microsoft Exchange y después expandir el objeto de organización de Exchange, el grupo administrativo y el contenedor de servidores. Debajo encontrará un contenedor llamado CN=InformationStore, que incluye los grupos de almacenamiento, como CN=First Storage Group. La clase de los objetos de grupo de almacenamiento es msExchStorageGroup. Si piensa utilizar secuencias de comandos personalizadas para administrar los recursos del almacén de Exchange, puede tener acceso a los objetos msExchStorageGroup mediante las interfaces de servicio de Active Directory (ADSI). El siguiente código de ejemplo muestra cómo tener acceso al grupo de almacenamiento predeterminado en un servidor llamado SERVER01 en una organización de Exchange llamada Contoso. Muestra la ruta de acceso actual a los archivos de registro de transacciones de ese grupo de almacenamiento. strStorageGroupDN = "CN=First Storage Group," _ & "CN=InformationStore," _ & "CN=SERVER01,CN=Servers," _ & "CN=First Administrative Group," _ & "CN=Administrative Groups," _ & "CN=Contoso,CN=Microsoft Exchange," _ & "CN=Services,CN=Configuration," _ & "DC=Contoso,DC=com" Set oStorageGroup = GetObject("LDAP://" & strStorageGroupDN) MsgBox oStorageGroup.Get("msExchESEParamLogFilePath")

A continuación, se incluyen los atributos relevantes de los objetos msExchStorageGroup que se pueden utilizar en secuencias de comandos personalizadas basadas en ADSI: •

msExchESEParamCircularLog Éste es un indicador booleano que determina si el registro circular está habilitado o deshabilitado. El valor de 0 indica que el registro circular está deshabilitado y el valor de 1 indica que está habilitado.

554

El registro circular lar hace que ESE descarte las transacciones cuando los cambios validados se transmiten al archivo de base de datos del disco. El archivo de punto de control indica los archivos de registro y las entradas de transacciones que se han validado correctamente e en n la base de datos. Todos los registros anteriores se eliminan, y las transacciones del archivo de registro de transacciones actual se marcan como obsoletas. Las nuevas transacciones sobrescribirán las entradas obsoletas en el registro de transacciones actual actual antes de que se cree un nuevo archivo de registro. Nota: Mediante la depuración de transacciones, el registro circular reduce el consumo de espacio en disco. Sin embargo, el registro circular no es compatible con configuraciones de tolerancia a errores errores complejas ni con algunos tipos de copia de seguridad en línea que dependen de la existencia de registros de transacciones. Cuando el registro circular está habilitado, sólo puede realizar copias de seguridad completas. No puede realizar copias de seguridad segu que dependan de archivos de registro de transacciones, como copias de seguridad diferenciales o incrementales. Cuando recupere los datos, no podrá reproducir los archivos de registro de transacciones, por lo que no será posible restaurar datos posteriores iores a la copia de seguridad más reciente. Por el contrario, si las transacciones no se eliminan automáticamente mediante el registro circular, podrá recuperar datos posteriores a la copia de seguridad más reciente reproduciendo transacciones que aún existan existan en un disco duro. Mientras que el registro circular está habilitado de forma predeterminada en Exchange Server 5.5, está deshabilitado de forma predeterminada en Exchange 2000 Server y Exchange Server 2003. •

msExchESEParamEventSource Ésta es una cadena ena del descriptor de procesos independiente del lenguaje que apunta a la clave del servicio Almacén de información de Microsoft Exchange (MsExchangeIS) en el Registro bajo HKEY_LOCAL_MACHINE HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services.

•

msExchESEParamLogFilePath Este atributo determina la ruta de acceso a archivos de registro de transacciones de un grupo de almacenamiento, como C: C:\Archivos de programa\Exchsrvr\mdbdata. mdbdata.

•

msExchESEParamLogFileSize Este atributo especifica el tamaño del archivo de registro en kilobytes obytes (KB). El valor predeterminado es 5.120. Este valor no debe cambiarse nunca.

•

msExchESEParamSystemPath Este atributo especifica la ruta de acceso al archivo de punto de control, como C:\Archivos C: de programa\Exchsrvr\mdbdata, mdbdata, así como la ruta de acceso ceso a todas las bases de datos temporales que puedan existir.

•

msExchESEParamZeroDatabaseDuringBackup Éste es un indicador booleano que determina si los registros eliminados y los valores de tipo Long se sobrescriben con ceros durante las operaciones de d copia de seguridad. El valor de 0 indica que los

555

registros no se sobrescriben. El valor de 1 indica que las bases de datos se sobrescriben con ceros. •

msExchESEParamEnableOnlineDefrag Éste es un indicador booleano que determina si el servicio Almacén de información de Microsoft Exchange debe realizar la desfragmentación en línea de bases de datos. El valor de 0 indica que no debe realizarse la desfragmentación en línea. El valor de 1 indica que debe realizarse la desfragmentación en línea durante los ciclos ciclos de mantenimiento programados. Nota: La desfragmentación en línea libera espacio en las bases de datos, pero no reduce el tamaño de los archivos de base de datos. Las incoherencias de la base de datos se corrigen al iniciar y apagar el servidor en un proceso denominado recuperación de software.

•

msExchESEParamEnableIndexChecking Éste es un indicador booleano que determina si deben comprobarse los índices Unicode en la versión del sistema operativo. El valor de 0 indica que no se realiza la comp comprobación robación de índices. El valor de 1 indica que se realiza la comprobación de índices. Este parámetro detecta los cambios en el sistema operativo resultantes de actualizar a una versión más reciente o de aplicar un Service Pack. Este indicador determina si el criterio de ordenación de Unicode ha cambiado. Siempre que se produce este cambio en el sistema operativo, se efectúa automáticamente una nueva indización.

•

msExchESEParamBaseName Este atributo especifica el nombre base de los archivos de registro de este grupo de almacenamiento. Por ejemplo, un nombre base de E00 produce el nombre del archivo de registro de transacciones E00.log.

•

msExchESEParamDbExtensionSize Este atributo especifica el tamaño de extensión de la base de datos en páginas. El valor predeterminado es 2 megabytes (MB).

•

msExchESEParamPageTempDBMin Este atributo especifica el tamaño mínimo de la base de datos temporal en páginas. El valor predeterminado es 0.

•

msExchESEParamCheckpointDepthMax Este atributo especifica la profundidad profundid de punto de control máxima preferida (no de hardware) en bytes.

Requisitos de espacio mínimo en disco de los grupos de almacenamiento Cada grupo de almacenamiento consume alrededor de 50 MB de espacio en disco libre. Los archivos que el grupo de almacen almacenamiento amiento necesita anteriormente indicados utilizan un mínimo de 11 MB de espacio en disco. El espacio en disco mínimo para los almacenes privado y público es de 5 MB y 8 MB, respectivamente. Aunque el total de espacio en disco utilizado es alrededor de 24 MB, B, se necesita espacio en disco adicional para la creación real del grupo de almacenamiento y para las operaciones de lectura y escritura. Cuando trabaje con grupos de almacenamiento, tenga en cuenta lo siguiente:

556

•

Un servidor que ejecuta Exchange Server 2003 puede contener hasta cinco grupos de almacenamiento. Dado que uno de estos grupos está reservado para las operaciones de recuperación de base de datos, sólo se pueden utilizar los cuatro restantes para alojar bases de datos que estén accesibles a los clientes. Si se intentan crear más de cuatro grupos de almacenamiento, aparecerá un mensaje de error.

•

Sólo se pueden crear cinco bases de datos en un grupo de almacenamiento. Si se intentan crear más bases de datos, aparecerá un mensaje de error.

Bases de datos del almacén de Exchange Exchange Server utiliza ESE como un motor de base de datos integrado que determina la estructura de las bases de datos y administra la memoria. El motor de base de datos almacena en caché las bases de datos en memoria transfiriendo fragmentos de datos (páginas) de cuatro kilobytes dentro y fuera de la memoria. Actualiza las páginas en memoria y vuelve a escribir páginas nuevas o actualizadas en el disco. Cuando llegan solicitudes al sistema, el motor de base de datos puede almacenar los datos en memoria en un búfer para que no sea necesario tener acceso al disco constantemente. Con esto se aumenta la eficacia del sistema, ya que escribir en memoria es aproximadamente 200.000 veces más rápido que escribir en disco. Cuando los usuarios realizan solicitudes, el motor de base de datos empieza a cargar las solicitudes en memoria y marca las páginas como sucias. Una página sucia es una página en memoria que contiene datos. Estas páginas sucias se almacenan posteriormente en las bases de datos del servicio Almacén de información de Microsoft Exchange del disco. Aunque el almacenamiento en caché de los datos en memoria es la forma más rápida y eficaz de procesar los datos, implica que mientras Exchange se encuentra en ejecución, la información del disco nunca se actualiza completamente. La última versión de la base de datos está en memoria y, puesto que muchos cambios en memoria aún no están en el disco, la base de datos y la memoria no están sincronizadas. Si hay alguna página sucia en memoria que no se ha transferido y escrito en disco, las bases de datos se marcan como incoherentes. Las bases de datos de Exchange sólo se sincronizan cuando todas las páginas sucias en memoria se transfieren a disco. Esto ocurre cuando se cierra correctamente el servicio Almacén de información de Microsoft Exchange. Durante el proceso de cierre, el servicio Almacén de información de Microsoft Exchange vuelca todas las páginas a disco.

Archivo de base de datos MAPI El archivo de base de datos MAPI de Exchange Server 2003 contiene las tablas que albergan los metadatos de todos los mensajes de correo electrónico, otros objetos de la base de datos y el contenido de los mensajes MAPI. Cada carpeta mostrada en Microsoft Office Outlook es una tabla de base de datos distinta del almacén de Exchange. Cada criterio de ordenación utilizado para ver estas carpetas se representa mediante un índice distinto en esa tabla. El proceso Store.exe administra estos criterios de ordenación.

557

Los mensajes de los clientes MAPI, como Outlook, se almacenan en la base de datos MAPI, del mismo modo que se almacenaban en las versiones anteriores de Exchange Server. Los clientes basados en MAPI pueden tener acceso entonces a estos mensajes sin conversión. Sin embargo, si un cliente basado en el protocolo de Internet intenta leer un mensaje de esta base de datos, el mensaje se convierte al formato solicitado. El archivo .edb tradicional y el archivo .stm que lo acompaña forman una única unidad. Uno de estos archivos apenas sirve para nada sin el otro archivo. Es importante comprender que una sola base de datos del servicio Almacén de información de Microsoft Exchange contiene dos archivos, el archivo .edb y el archivo .stm. Un registro del archivo .edb contiene una columna (del tipo de datos JET_coltypSLV) que hace referencia a una lista de páginas del archivo de secuencias que contiene los datos sin procesar. Los datos de uso de espacio (cuatro kilobytes de páginas como máximo) y de suma de comprobación de los datos del archivo de secuencias se almacenan en el archivo .edb.

Archivo de base de datos de secuencias En Exchange Server 5.5 y versiones anteriores, los mensajes se almacenan en formato encapsulado de base de datos de mensajes (MDBEF). Éste es el formato nativo para los clientes de Outlook. Cuando un cliente que no se basa en MAPI solicita un mensaje, el servicio Almacén de información de Microsoft Exchange convierte el contenido de MDBEF al formato correspondiente en el que el cliente lo solicita. Esta conversión consume ancho de banda del procesador y reduce el rendimiento del servidor. Las últimas versiones de ESE permiten que los clientes de mensajería de Internet almacenen los datos sin procesar en formato nativo. El repositorio de estos datos sin procesar recibe el nombre de base de datos de secuencias o, simplemente, de archivo de secuencias. El archivo de secuencias no tiene sobrecarga de árbol equilibrado (árbol B), sino que contiene dos páginas de cuatro kilobytes de información de encabezado y páginas de cuatro kilobytes de datos sin procesar. Esta estructura de datos plana está diseñada para los objetos binarios grandes (BLOB) de datos que probablemente no necesitan conversión de contenido y que pueden recibirse y transmitirse muy rápidamente.

Promoción de propiedades La promoción de propiedades determina dónde se almacenan los datos en una base de datos ESE y, por tanto, es un concepto importante que debe conocerse. El servicio Almacén de información de Microsoft Exchange admite la promoción de propiedades de los datos incluidos en el archivo .stm y el archivo .edb. La promoción de propiedades permite mantener de forma eficaz las vistas de carpeta y los índices. Por ejemplo, las propiedades de un mensaje distribuido al archivo .stm, como el remitente, el asunto y la fecha de envío y recepción, se promueven a los registros que representan el mensaje en el archivo .edb.

558

Cuando un cliente MAPI, como Microsoft Outlook, envía un mensaje al servicio Almacén de información de Microsoft Exchange, el contenido de ese mensaje se almacena en el archivo .edb. Si un cliente no basado en MAPI abre el mensaje, el servicio Almacén de información de Microsoft Exchange realiza una conversión inmediata del contenido MAPI al formato de Internet efectuando parte de la conversión y llamando a IMAIL que, a su vez, llama a RTFHTML para completar la conversión. Ninguna parte de esta conversión es permanente, lo que significa que los datos no se extraen del archivo .edb ni se escriben en el archivo .stm. Si un cliente de Internet envía un mensaje al servicio Almacén de información de Microsoft Exchange, el contenido de ese mensaje se almacena en el archivo .stm. Algunos encabezados del mensaje de Internet se duplican en el archivo .edb para que el servicio Almacén de información de Microsoft Exchange pueda encontrar el mensaje. Este proceso se denomina conversión de estado 0. Si un cliente pide una propiedad, como PR_Subject, o uno de sus muchos alias, el servicio Almacén de información de Microsoft Exchange promueve toda la información del encabezado del mensaje de Internet a Properties. Este proceso se denomina conversión de estado 1. Si un cliente pide información sobre los datos adjuntos, el servicio Almacén de información de Microsoft Exchange crea un pseudoduplicado (en formato MAPI) del mensaje de Internet. Al principio, el mensaje continúa en el archivo .stm. Sin embargo, muchos de los datos necesarios para el acceso MAPI se encuentran en el archivo .edb. Si un cliente altera el mensaje de forma que cambia las extensiones multipropósito de correo Internet (MIME), la versión del archivo .stm del mensaje se descarta y se conserva el archivo .edb del mensaje. Este proceso se denomina conversión de estado 2. Independientemente de cómo se envíe un mensaje al servicio Almacén de información de Microsoft Exchange, si Exchange Server recibe contenido de Internet que incluye contenido Aplicación/ms-tnef, el mensaje pasa inicialmente al archivo .stm, pero inmediatamente después se descodifica y se mueve al archivo .edb. Lo mismo ocurre con los mensajes con datos adjuntos winmail.dat codificados mediante UUEncode. El formato de encapsulamiento neutro para el transporte (TNEF) y Winmail.dat son métodos de encapsulamiento de mensajes MAPI que conservan las propiedades MAPI en transportes que no admiten MAPI. Por tanto, el principio general de que los mensajes MAPI residen en el archivo .edb y los mensajes de Internet residen en el archivo .stm es correcto. En el modo de funcionamiento actual, el TNEF está descodificado antes de que se lea alguna de las propiedades MAPI.

Configuración y administración del límite del tamaño de la base de datos Antes de Microsoft Exchange Server 2003 Service Pack 2 (SP2), no había forma de configurar los límites de tamaño de la base de datos en Exchange Server 2003. Exchange Server 2003 SP2 presenta las siguientes novedades:

559

•

Para Standard Edition, el límite del tamaño de la base de datos configurado predeterminado será de 18 GB, 2 GB más que el límite anterior, con un nuevo tamaño máximo de 75 GB.

•

Para Enterprise Edition, no existe existe límite de tamaño de la base de datos configurado predeterminado, ni tamaño máximo establecido de software.

•

Ambas versiones de Exchange Server 2003 con SP2 ofrecen la posibilidad de configurar un límite, un umbral de advertencia y un intervalo de advertencia advertencia a través de las claves del Registro.

•

La comprobación de tamaño realizada en relación a la base de datos utiliza ahora el tamaño de la base de datos lógica. Los registros vacíos y los espacios en blanco no cuentan en el límite de tamaño configurado de la base de datos; por lo tanto, no es necesario desfragmentar sin conexión para una recuperación que exceda el límite configurado de la base de datos o el especificado en la licencia.

•

El proceso de almacenamiento controla ahora las comprobaciones comprobaciones de límite, realizadas en intervalos regulares, en lugar de hacerlo JET. El intervalo de tiempo predeterminado es de 24 horas; este intervalo se puede configurar a través del Registro.

Configuración del Registro •

Las claves del Registro de límite d de e tamaño de la base de datos se leen cuando se monta la base de datos (no cuando se inicia el servicio) y cuando se ejecutan las tareas de comprobación de límite.

Para modificar el límite de tamaño de una base de datos debe configurar los parámetros del Registro. gistro. Las entradas del Registro deberían ubicarse bajo cada entrada de base de datos en el Registro del servidor local. Por consiguiente, si es necesario reconstruir el servidor mediante el modificador de instalación /disasterecovery tendrá que restablec restablecer las claves del Registro manualmente. Nota: La modificación incorrecta del Registro puede ocasionar problemas graves que quizás requieran volver a instalar el sistema operativo. Es posible que los problemas derivados de una modificación incorrecta del Registro no se puedan resolver. Antes de modificar el Registro, se recomienda realizar una copia de seguridad de todos los datos importantes. Todos los valores del Registro explicados en este tema se crean en la siguiente ubicación del Registro: HKEY_LOCAL_MACHINE _MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS MSExchangeIS\\Private Private-013e2e46-2cd7-4a8e-bfec-0e4652b94b00 El GUID de esta clave (Private (Private-013e2e46-2cd7-4a8e-bfec-0e4652b94b00) 0e4652b94b00) es un ejemplo y debería coincidir con el valor del atributo objectGUID del objeto de Active Directory de la base de datos.

560

Nota: Las entradas del Registro mencionadas en este artículo no están disponibles de forma predeterminada; si crea la entrada, reemplazará el valor predeterminado establecido en el código. Nota: Los s valores de todos los registros mencionados en este artículo están en anotación decimal, no hexadecimal. •

Con SP2 están disponibles los siguientes valores nuevos del Registro:

•

Límite de tamaño de la base de datos en GB

•

Advertencia de búfer de tamaño de la base de datos en porcentaje

•

Hora de inicio de comprobación de tamaño de la base de datos en horas desde la medianoche

Límite de tamaño de la base de datos en GB El valor Límite de tamaño de la base de datos en GB es el tamaño máximo que se puede configurar onfigurar para que una base de datos no exceda el tamaño máximo especificado en su licencia. Para Standard Edition, puede establecer el límite de tamaño de la base de datos entre 1 y 75 GB. De forma predeterminada, el límite es 18 GB. Para Enterprise Edition, Editi puede establecer el límite de tamaño de la base de datos entre 1 y 8.000 GB. De forma predeterminada, no hay ningún límite. El siguiente valor del Registro controla el límite de tamaño que se puede configurar para la base de datos: Tipo de datos

Nombre

Valor (en GB)

Predeterminado (en GB)

REG_DWORD

Database Size Limit in GB

Estándar: 1-75

Estándar: 18

Enterprise: 1-8000

Enterprise: 8.000 ilimitado

Advertencia de búfer de tamaño de la base de datos en porcentaje El valor Advertencia de búfer de tamaño de la base de datos en porcentaje es un umbral de error configurable que le advertirá con una entrada del registro de sucesos cuando la base de datos esté al límite de su capacidad o la haya sobrepasado; se cerrará a las 24 horas de haber registrado el suceso. De forma predeterminada, Exchange Server 2003 SP2 registra sucesos cuando la base de datos aumenta su tamaño un 10 por ciento del límite de

561

tamaño configurado. Este umbral se puede configurar. El búfer más pequeño es un 1 por ciento del límite de tamaño configurado. El siguiente valor del Registro controla la Advertencia de búfer de tamaño de la base de datos: Tipo de datos

Nombre

Valor (en %)

Predeterminado (en %)

REG_DWORD

Database Size Buffer Warning in Percentage

1 - 100

10

Hora de inicio de comprobación de tamaño de la base de datos en horas desde la medianoche El valor Hora de inicio de comprobación de tamaño de la base de datos en horas desde la medianoche permite configurar la hora en que el sistema comprobará la base de datos para ver si ha finalizado el Límite de tamaño de la base de datos configurado. De forma predeterminada, la comprobación de tamaño de la base de datos tiene lugar diariamente a las cinco de la mañana. Esta hora se puede cambiar. Si se modifica, la siguiente tarea se programa a la nueva hora de compensación. Las comprobaciones en el Intervalo de comprobación del tamaño de la base de datos no se realizan hasta que se establece una nueva hora de inicio. La primera comprobación de tamaño de la base de datos desconectará la base de datos si se ha excedido el límite de tamaño. Como no se desconecta la base de datos, se aseguran 24 horas de disponibilidad como mínimo después de que se exceda el límite establecido en los valores predeterminados. Tipo de datos

Nombre

Valores

Predeterminado

Descripción

REG_DWORD

Database Size Check Start Time in Hours from Midnight

1 - 24

5

Determina la hora en la que tendrá lugar la primera comprobación de tamaño tras montar la base de datos.

562

Comportamiento cuando se alcanza el límite de tamaño configurado de la base de datos o el establecido en la licencia Cuando se monta una base de datos, el proceso de almacén compara el tamaño físico de la base de datos en relación al Límite de tamaño configurado de la base de datos en GB. Si el tamaño físico es menor o excede el Búfer de advertencia de tamaño de la base de datos configurado, el almacén realiza un cálculo lógico del tamaño de la base de datos. Si el tamaño está por debajo del búfer de advertencia no hay necesidad de calcular el espacio libre porque el tamaño lógico nunca sobrepasará al tamaño físico. Por lo general, el tamaño físico es menor que el umbral de advertencia; de modo que la comprobación de tamaño no debería tardar más de un milisegundo en completarse. Si es necesario calcular el espacio, la comprobación de tamaño podría necesitar varios segundos para analizar la base de datos y generar el cálculo lógico de tamaño. Si se alcanza o excede el Búfer de advertencia de tamaño de la base de datos en porcentaje, se registrará un suceso de error, Id. de suceso 9688, en el registro de sucesos de la aplicación. Con Exchange Server 2003 SP2 o posterior, el servidor realiza las tareas siguientes cuando se alcanza el límite de tamaño de la base de datos configurable (o configurado de forma predeterminada): •

Si la primera comprobación tras montar la base de datos encuentra que el tamaño supera el límite, la base de datos no se desconectará pero se registrará un suceso de error (Id. 9689) en el registro de sucesos de la aplicación.

•

Si se trata de la segunda comprobación, se registrará un suceso de error en el registro de sucesos de la aplicación y la base de datos se desconectará.

Una vez que el administrador monte de nuevo la base de datos, él o ella tendrá 24 horas (o bien hasta la siguiente comprobación de tamaño o hasta las cinco de la mañana con la configuración predeterminada) para tomar medidas de corrección.

Límite de tamaño de la base de datos establecido en la licencia Exchange Server 2003 Standard Edition está limitado a un único grupo de almacenamiento con una única base de datos de almacén de información privada y una única base de datos de carpetas públicas. Con anterioridad a SP2, cada base de datos estaba limitada a 16 GB del tamaño físico total. SP2 aumenta el límite de tamaño de la base de datos establecido en la licencia para Exchange Server 2003 Standard Edition de 16 GB a 75 GB; el límite de tamaño configurado de la base de datos predeterminado será de 18 GB. El grupo de almacenamiento de Exchange Server 2003 Enterprise Edition y las opciones de almacén de Exchange no cambian con la aplicación de SP2. Sin embargo, se ha agregado un límite de tamaño configurable de almacén de Exchange a Enterprise Edition.

563

versión Exchange Server 2003

Límite de la licencia

Límite de configuración predeterminada

Standard Edition anterior a SP2

16 GB

No aplicable

Standard Edition con SP2

75 GB

18 GB

Enterprise Edition anterior a SP2

8.000 GB (ilimitado)

No aplicable

Enterprise Edition con SP2

8.000 GB (ilimitado)

8.000 GB

Nota: El límite codificado actual de la base de datos de JET es 8.192 GB, u 8 terabytes (TB).

Consideraciones sobre el diseño de recuperación de desastres Si cambia el límite de tamaño de las bases de datos de Exchange, es posible que desee hacer volver a evaluar de la copia de seguridad de la base de datos de Exchange y del diseño de recuperación. En concreto, si aumenta el límite de tamaño de las bases de da datos de Exchange, asegúrese de probar las operaciones de copia de seguridad y de recuperación mediante los nuevos límites para asegurarse de que puede cumplir los acuerdos de nivel de servicio. Por ejemplo, si el almacén de buzones era de 15 GB y podía cumplir cump el acuerdo de nivel de servicio recuperando los datos en menos de 8 horas, tenga en cuenta que si amplía el almacén a 20 GB o más ya no podrá recuperar la base de datos en ese tiempo. Para obtener más información acerca de los acuerdos de nivel de serv servicio, icio, consulte "Establecimiento de un acuerdo de nivel de servicio" en "Establecimiento de objetivos de disponibilidad" en la Guía de alta disponibilidad de Exchange Server 2003. 2003 Para obtener información rmación acerca de como configurar las opciones de límite de tamaño de la base de datos, consulte "Configurar los límites de tamaño de la base de datos" en la Ayuda en línea de Exchange Server 2003 SP2.

Arquitectura del Motor de almacenamiento extensible El almacén de Exchange se asienta sobre una base de datos llamada Motor de almacenamiento extensible (ESE). ESE es un administrador de tablas multiusuario del Método de acceso secuencial indizado (ISAM) con todas las capacidades del Lenguaje de

564

manipulación de datos (DML) y del Lenguaje de definición de datos (DDL). ESE permite que las aplicaciones almacenen registros y creen índices para tener acceso a esos registros de distintas formas. Existen tres versiones de ESE: •

ESE97 El motor de base de datos de Exchange Server 5.5.

•

ESENT El motor de base de datos de Active Directory y de muchos componentes de Microsoft Windows. A diferencia de otras versiones de ESE (que utilizan archivos de registro de cinco MB y tamaños de página de cuatro KB), la implementación implemen de Active Directory de ESENT utiliza archivos de registro de diez MB y páginas de ocho KB.

•

ESE98 El motor de base de datos de Exchange 2000 Server y Exchange Server 2003. Nota: ESE se denominaba anteriormente Joint Engine Technology (JET) Blue. Blue JET Blue no es lo mismo que la versión de JET de Access (denominada JET Red).

Transacciones ESE es un motor complejo de base de datos basado en transacciones. Una transacción es un conjunto de operaciones que se tratan como una unidad atómica (indivisible). (indivisibl Todas las operaciones de una transacción se realizan y se guardan permanentemente, o no se lleva a cabo ninguna de ellas. Considere, por ejemplo, las operaciones implícitas cuando mueve un mensaje de la Bandeja de entrada a la carpeta Elementos enviados. enviados. El mensaje se elimina de una carpeta, se agrega a otra y se actualizan las propiedades de las carpetas. Si se produce un error, no deseará disponer de dos copias del mensaje, ni ninguna copia en absoluto, ni querrá que los valores de las propiedades de la carpeta (como el número de elementos) sean incoherentes con el contenido real de la carpeta. Para evitar que se produzcan problemas de este tipo, ESE agrupa las operaciones en una transacción. ESE se asegura de que ninguna de las operaciones se aplique permanentemente hasta que la transacción se valide en el archivo de base de datos. Cuando la transacción se valida en el archivo de base de datos, todas las operaciones se aplican permanentemente. En caso de que se bloquee el sistema, ESE administra también también la recuperación automática durante el arranque y deshace las transacciones no validadas. Si ESE produce un error antes de que se valide una transacción, se deshace toda la transacción y es como si la transacción nunca se hubiera producido. Si ESE se bloq bloquea uea después de que se valide la transacción, toda la transacción se mantiene y los cambios son visibles a los clientes.

Transacciones ACID Las transacciones que son así de confiables se denominan normalmente transacciones ACID. Las transacciones ACID se ca caracterizan racterizan por los siguientes atributos:

565

•

Unicidad Este término indica que un cambio en el estado de una transacción se produce totalmente o no se produce. Los cambios de estado atómicos incluyen cambios de base de datos y mensajes y acciones en los transductores.

•

Coherencia Este término indica que una transacción es una transformación correcta del estado. Las acciones realizadas como grupo no infringen ninguna de las restricciones de integridad asociadas al estado. Para ello es necesario que la transacción sea un programa correcto.

•

Aislamiento Este término indica que aunque las transacciones se ejecuten simultáneamente, cada transacción percibirá que las otras se ejecutan antes o después que ella, pero no ambas cosas.

•

Durabilidad Este término indica que en cuanto se ejecute correctamente una transacción (se valida), cambia el estado para resistir cualquier error.

El almacén de versiones El almacén de versiones permite que ESE realice un seguimiento de las transacciones actuales y las administre, de forma que pueda superar los requisitos de aislamiento y coherencia de la prueba ACID. El almacén de versiones mantiene una lista en memoria de las modificaciones realizadas en la base de datos. El almacén de versiones se utiliza en las siguientes situaciones: •

Recuperación Si debe deshacerse una transacción, se consulta el almacén de versiones para obtener la lista de operaciones realizadas. La transacción se puede deshacer revirtiendo todas las operaciones.

•

Detección de conflictos de escritura Si dos sesiones diferentes tratan de modificar el mismo registro, el almacén de versiones advierte este conflicto y rechaza la segunda modificación.

•

Lecturas repetibles Cuando una sesión inicia una transacción, siempre encuentra la misma vista de base de datos, aunque otras sesiones modifiquen los registros que está consultando. Cuando una sesión lee un registro, se realiza una consulta en el almacén de versiones para determinar qué versión del registro debe ver la sesión. Las lecturas repetibles proporcionan un nivel de aislamiento que permite que cuando un cliente inicia una transacción vea el estado de la base de datos tal como estaba cuando comenzó la transacción, independientemente de las modificaciones realizadas por otros clientes o sesiones. Las lecturas repetibles se implementan mediante el almacén de versiones. Con una lista en memoria de las modificaciones realizadas en la base de datos, se puede determinar la vista de un registro que debe ver una determinada sesión.

•

Registro diferido antes de imagen Ésta es una optimización compleja que permite a ESE registrar menos datos que otros motores de base de datos equiparables.

566

Aislamiento de instantáneas Después de iniciarse una transacción, ESE garantiza que la sesión vea una imagen única y coherente de la base de datos, tal como era al iniciarse la transacción, más los cambios realizados. Como otras sesiones pueden modificar también los datos y validar sus transacciones, estos cambios son invisibles a cualquier transacción que se inicie antes de la validación. Un usuario sólo puede modificar un registro si ve la última versión. De lo contrario, la actualización produce un error con JET_errWriteConflict. Las versiones anteriores a la última transacción se descartan automáticamente. ESE dispone de un nivel de aislamiento de transacciones denominado Aislamiento de instantáneas. El nivel de aislamiento de instantáneas permite a los usuarios tener acceso a la última fila validada mediante una vista coherente entre transiciones de la base de datos. El aislamiento de instantáneas es un algoritmo de control de concurrencia descrito por primera vez en A Critique of ANSI SQL Isolation Levels (Crítica de los niveles de aislamiento SQL de ANSI). ESE implementa el aislamiento de instantáneas mediante el uso de lecturas repetibles.

Estructura de la base de datos de ESE Todos los datos incluidos en el archivo de base de datos de texto enriquecido se almacenan en árboles B. La "B" de árbol B es la abreviatura de "balanced" (equilibrado). "Árbol" hace referencia a una disposición similar a una estructura de carpetas de un sistema de archivos, donde hay una raíz que es el nodo principal de los elementos (las páginas de la base de datos), que a su vez son nodos principales de otros elementos. Los árboles B están diseñados para proporcionar un rápido acceso a los datos en disco. Como las operaciones de lectura y escritura en un disco son mucho más lentas que en memoria, un árbol B se divide en páginas de cuatro KB, lo que permite a ESE obtener los datos que necesita mediante el número mínimo de operaciones de E/S de disco. Una base de datos ESE puede contener hasta 2^32 (2 elevado a la 32ª potencia) páginas o 16 terabytes. En realidad, el tamaño de la base de datos está limitado únicamente por la capacidad de realizar copias de seguridad, restauraciones y otras operaciones de mantenimiento de la base de datos (como la desfragmentación sin conexión y las reparaciones de base de datos) en un tiempo aceptable.

Páginas de base de datos El tamaño de página en ESE lo define la aplicación que utiliza este motor. Por ejemplo, ESE97 (Exchange Server 5.5) y ESE98 (Exchange 2000 Server y Exchange Server 2003) utilizan páginas de cuatro KB, mientras que ESENT (Active Directory) utiliza páginas de ocho KB. Cada una de estas páginas de cuatro u ocho KB contienen punteros a otras páginas o a los datos reales almacenados en el árbol B. El puntero y las páginas de datos están entremezclados en el archivo.

567

Para aumentar el rendimiento allí donde es posible, las páginas se almacenan en un búfer de memoria durante todo el tiempo posible, con lo que se reduce la necesidad de tener acceso al disco. Cada página comienza con un encabezado de 40 bytes que incluye los siguientes valores: •

pgnoThis Este valor indica el número de la página.

•

DbtimeDirtied Este valor indica la hora (Dbtime) en que se modificó la página por última vez.

•

pgnoPrev Este valor indica el número de la página izquierda contigua en el mismo nodo.

•

pgnoNext Este valor indica el número de la página derecha contigua en el mismo nodo.

•

ObjidFDP Este valor indica el Id. de objeto de una página especial de la base de datos, denominada Padre de la página de datos (FDP), que indica el árbol B al que pertenece esta página. La página FDP se utiliza durante las operacione operacioness de reparación.

•

cbFree Este valor indica el número de bytes disponibles en la página.

•

cbUncommittedFree Este valor indica el número de bytes no validados disponibles (bytes que están libres pero disponibles para usarlos en la recuperación) en la página.

•

ibMicFree Este valor indica la posición de página para el siguiente byte disponible al principio de la página.

Suma de comprobación de ECC Exchange Server 2003 Service Pack 1 (SP1) presenta una nueva característica denominada Suma de comprobación ón de código de corrección de errores (ECC). La suma de comprobación de ECC es un nuevo formato de suma de comprobación que permite la corrección de errores de un solo bit en páginas de base de datos (en el archivo .edb, en al archivo .smt y en los archivos archivos de registro de transacciones). Este nuevo formato de suma de comprobación utiliza 64 bits, mientras que el formato anterior utiliza 32 bits. Las bases de datos con el formato anterior se pueden utilizar con el nuevo código, pero las bases de datos con el formato actual no se pueden utilizar con versiones anteriores de ESE. Una vez actualizado el motor de base de datos, todas las páginas que se escriban en la base de datos tendrán el nuevo formato de suma de comprobación. Las páginas que se lean y no se modifiquen difiquen no tendrán el formato de suma de comprobación actualizado. Nota: Después de implementar el nuevo archivo ESE.dll, al realizar una desfragmentación sin conexión, se actualiza el formato de suma de comprobación de todas las páginas de la base de datos. atos. Esto podría aumentar sustancialmente el tiempo empleado en desfragmentar la base de datos, por lo que no es una práctica recomendable. Asimismo, tampoco se recomienda ejecutar eseutil con el modificador /k, que realiza una suma de comprobación de todas todas las páginas de la base de datos.

568

Las páginas de base de datos con el formato anterior de suma de comprobación empiezan con una suma de comprobación de cuatro bytes seguida de un número de página de cuatro bytes, que se utiliza para comprobar que la página solicitada se lee realmente del disco. En el nuevo formato de suma de comprobación no se incluye el número de página de cuatro bytes, sino que se empieza con una suma de comprobación de ocho bytes. El número de página se utiliza como parámetro de entrada al calcular la suma de comprobación. Por tanto, si se lee la página incorrecta del disco, habrá una discrepancia de suma de comprobación. El formato de suma de comprobación actual se compone en realidad de dos sumas de comprobación de 32 bits. La primera es una suma de comprobación XOR, calculada de forma muy similar a como se calcula en el formato anterior. El número de página se utiliza como un valor de inicialización en el cálculo de esta suma de comprobación. La segunda suma de comprobación de 32 bits es una suma de comprobación de ECC, que permite la corrección de errores de un solo bit en la página.

Coherencia de la base de datos y errores -1018 •

Cuando se lee una página, ESE examina un indicador de la misma para ver si tiene el formato de suma de comprobación actual. A continuación, se calcula la suma de comprobación correspondiente (con el formato actual o anterior). Si hay una discrepancia entre la suma de comprobación y la suma de comprobación del formato actual, ESE intenta corregir el error. Si el error no se puede corregir automáticamente, Exchange genera un error -1018.

El almacén de Exchange puede ser el responsable de autogenerar un error -1018, si realiza alguna de las siguientes operaciones: •

Crea una página con la suma de comprobación incorrecta.

•

Crea una página correctamente, pero indica al sistema operativo que escriba la página en un lugar incorrecto.

Si un administrador del sistema encuentra un error -1018 o ejecuta las pruebas de hardware de diagnóstico en el servidor y estas pruebas no informan de ningún problema, puede llegar a la conclusión de que Exchange Server debe ser el responsable del problema, ya que el hardware ha superado el análisis inicial. En muchos casos, gracias a investigaciones exhaustivas realizadas por Microsoft u otros proveedores de hardware, se han sacado a la luz problemas imperceptibles en el hardware, firmware o controladores de dispositivos que son en realidad los responsables de los daños sufridos por el archivo de base de datos. Las pruebas de diagnóstico habituales a veces no detectan todos los errores transitorios producidos por diversos motivos. Puede que los programas de diagnóstico no sean capaces de detectar los problemas del firmware o del software de los controladores. Las pruebas de diagnóstico pueden no ser capaces de simular adecuadamente procesos de ejecución prolongados o cargas complejas. Además, la incorporación de control de diagnóstico o registro de depuración podría cambiar el sistema para evitar que el problema vuelva a aparecer.

569

La simplicidad y estabilidad de los mecanismos de Exchange Server que generan las sumas de comprobación y escriben páginas en el archivo de base de datos sugieren que la causa del error -1018 hay que buscarla probablemente en algún elemento externo de Exchange Server. Los mecanismos de suma de comprobación y detección de páginas incorrectas son simples y confiables y, esencialmente, siguen siendo los mismos desde que se publicó por primera vez Exchange, excepto algunos pequeños cambios para adaptar las modificaciones del formato de las páginas de base de datos entre las distintas versiones de base de datos. Una suma de comprobación se genera para una página que se va a escribir en disco después de que todos los datos se escriban en la página, incluido el propio número de página. Cuando Exchange Server agrega la suma de comprobación a la página, indica al sistema operativo Microsoft Windows Server que escriba la página en disco mediante las API estándar publicadas de Windows Server. La suma de comprobación podría generarse correctamente para una página, pero la página podría escribirse en la ubicación incorrecta del disco duro. Esto puede deberse a un error de memoria transitoria, como una "mutación de bits". Suponga, por ejemplo, que Exchange crea una nueva versión de la página 70. La propia página no experimenta ningún error, pero la copia del número de página utilizado por el controlador de disco o el sistema operativo se modifica aleatoriamente. Este problema se puede producir si 70 (binario 1000110) se ha cambiado a 6 (binario 000110) por una celda de memoria inestable. La suma de comprobación de la página sigue siendo correcta, pero la ubicación de la página en la base de datos es incorrecta. Exchange Server genera un error -1018 para la página cuando detecta que el número de la página lógica no coincide con la ubicación física de la página. Se puede producir otro tipo de error de numeración de páginas (causado por Exchange Server) si Exchange Server escribe el número de página incorrecto en la propia página, pero este problema causa otros errores, no el error -1018. Si Exchange Server escribe 71 en la página 70 y después realiza correctamente la suma de comprobación en la página, la página se escribe en la ubicación 71 y supera las pruebas de número de página y suma de comprobación. Normalmente, un único error -1018 registrado en una base de datos de Exchange Server no causa una parada de la base de datos ni produce más síntomas que la presencia del propio error -1018. La página podría estar en una carpeta a la que no se tiene acceso frecuentemente (por ejemplo, las carpetas Elementos enviados y Elementos eliminados), o en un archivo adjunto que rara vez se abra o incluso esté vacío. Aunque es improbable que un único error -1018 cause una pérdida de datos importante, los errores -1018 siguen siendo causa de preocupación porque ponen de manifiesto que el sistema de almacenamiento no ha podido almacenar o recuperar datos de forma confiable al menos una vez. Aunque el error -1018 puede ser un problema transitorio que no se vuelva a repetir nunca, es más probable que este error sea una advertencia de un problema que podría ir agravándose con el tiempo. Aunque el primer error -1018 se produzca en una página vacía de la base de datos, no es posible saber cuál será la siguiente página que podría resultar dañada. Si una tabla global crítica resulta dañada, puede que la base de

570

datos no se inicie, y su reparación podría ser una solución parcial o totalmente insatisfactoria. Cuando se registre un error -1018, deberá considerar iderar la posibilidad de que se produzca un error inminente u otro daño aleatorio en la base de datos, hasta que encuentre y elimine la causa primigenia.

Equilibrio del árbol de base de datos Una de las funciones principales de ESE es mantener el árbol de base de datos equilibrado en todo momento. El proceso de equilibrar el árbol termina cuando se dividen o se combinan todas las páginas. Como se ilustra en la siguiente figura, el nivel raíz del árbol siempre contiene el mismo número de nodos que el nivel de de hoja y, por tanto, el árbol está equilibrado. Árbol equilibrado

Nota: Aunque los árboles incluidos en una base de datos ESE se denominan normalmente árboles B, en realidad son árboles B+. Los árboles B+ incluyen todas las características de los árbo árboles les B, pero además cada página de datos del árbol B+ contiene punteros a la página contigua anterior o siguiente en la hoja. Aunque, para mantener estos punteros actualizados, hay una sobrecarga durante las operaciones de inserción o división y combinación, combinación, los punteros permiten búsquedas secuenciales más rápidas a través de los datos de la estructura de árbol B+. Desde el punto de vista de ESE, una tabla de base de datos es un conjunto de árboles B. Cada tabla está formada por un árbol B que contiene los datos, datos, si bien puede haber muchos árboles B de índices secundarios utilizados para proporcionar diferentes vistas de los datos. Si una columna o campo de una tabla es demasiado grande para almacenarse en el árbol B, se divide y se coloca en un árbol B disti distinto, nto, denominado árbol de valores largos. La definición de estas tablas y sus árboles B asociados se almacena en otro árbol B, que recibe el nombre de catálogo del sistema. La pérdida del catálogo del sistema es un

571

problema grave. Por ello, ESE conserva dos copias idénticas de este árbol B en cada base de datos: una que comienza en la página cuatro y otra que comienza en la página 24.

División Cuando una página está a punto de llenarse, alrededor de la mitad de los datos se colocan en una página secundaria y se incluye una clave adicional en la página principal de esta página. Este proceso se realiza salvo que la página principal también esté llena. En ese caso, la página principal se divide y se agrega un puntero a la página principal de esta página. En última instancia, podría ser necesario dividir cada página de puntero hasta el bloque raíz. Si hay que dividir el bloque raíz, se inserta un nivel adicional de páginas en el árbol. Metafóricamente hablando, el árbol crece en altura.

Combinación Cuando una página está casi vacía, se combina con una página contigua, se actualizan los punteros de la página principal y, si es necesario, se combina la página. En última instancia, si se combina cada página de puntero hasta el bloque raíz, el árbol disminuye en altura. Para llegar hasta una hoja (a los datos), ESE comienza en el nodo raíz y sigue los punteros de página hasta llegar al nodo de hoja deseado.

Despliegue La estructura de un árbol B de ESE tiene un despliegue muy alto, lo que permite a ESE tener acceso a cualquier fragmento de datos de una tabla de 50 GB con cuatro lecturas de disco como máximo (tres páginas de puntero y la propia página de datos). ESE almacena más de 200 punteros de página para cada página de cuatro KB, por lo que utiliza árboles con un número mínimo de niveles principales y secundarios (llamados también árboles superficiales). ESE almacena también una clave del árbol actual que le permite buscar rápidamente por dicho árbol. El diagrama anterior es un árbol con tres niveles principal/secundarios; un árbol con cuatro niveles principal/secundarios puede almacenar muchos gigabytes de datos.

Índices Un árbol B tradicional sólo se indiza de un modo en concreto. Utiliza una clave, y los datos deben recuperarse mediante esa clave. Por ejemplo, los registro de la tabla de mensajes se indizan en un identificador exclusivo del mensaje, llamado Id. del servicio de transferencia de mensajes (MST). Sin embargo, es probable que un usuario desee ver los datos de la tabla de mensajes ordenados de una forma más sencilla. Para recuperar los datos se utilizan índices, o más concretamente, índices secundarios. Cada índice secundario es otro árbol B que asigna la clave secundaria elegida a la clave

572

principal. Con ello se obtiene un árbol B pequeño en comparación con los datos que se indizan. Para comprender cómo se utiliza un índice secundario, piense en lo que sucede cuando un usuario cambia el modo en que se presentan los mensajes en una carpeta de mensajes. Si cambia la vista de carpeta en Outlook para que se ordene por el asunto en lugar de por la hora de recepción, Outlook hará que el almacén y ESE creen un nuevo índice secundario en la tabla de carpetas de mensajes. Cuando cambie por primera vez las vistas en una carpeta de gran tamaño, observará que esta operación tarda algún tiempo. Si examina atentamente el servidor, apreciará un pequeño pico en la actividad de disco. Cuando vuelva a cambiar a esa vista, el índice ya se habrá creado y la respuesta será mucho más rápida. Los árboles B de índice secundario de los servicios Almacén de información Microsoft Exchange se conservan durante ocho días. Si no se utilizan, el servicio los elimina mediante una operación en segundo plano.

Valores largos Una columna o registro de ESE no puede abarcar una página en el árbol B de datos. Hay valores (como PR_BODY, que es el cuerpo de un mensaje) que superan el límite de 4 KB de una página. Se denominan valores largos. El árbol B de valores largos de una tabla se utiliza para almacenar dichos valores. Si se introduce un fragmento de datos en una tabla ESE demasiado grande para incluirse en el árbol B de datos, se divide en páginas de cuatro KB y se almacena en el árbol B de valores largos de la tabla. El registro del árbol B de datos contiene un puntero al valor largo. Este puntero se denomina Id. del valor largo (LID) e indica que el registro tiene un puntero a LID 256.

Formato de registros Un conjunto de árboles B representa una tabla, y una tabla es un conjunto de filas. Las filas se denominan también registros. Un registro se compone de muchas columnas. El tamaño máximo de un registro y, por tanto, el número de columnas que aparecen en un único registro, está regido por el tamaño de página de la base de datos menos el tamaño del encabezado. ESE tiene páginas con un tamaño de cuatro KB. Por tanto, el tamaño máximo del registro es aproximadamente 4.050 bytes (4.096 bytes menos el tamaño del encabezado de página).

Tipos de datos de columna Cada definición de columna debe especificar el tipo de datos que se almacenan en la columna. ESE admite los tipos de datos que se describen en la tabla siguiente.

573

Tipos de datos de columna del Motor de almacenamiento extensible Tipos de datos de columna

Descripción

Bit

NULO, 0 o distinto de 0

Bytes sin signo

Entero de 1 bytes sin signo

Short

Entero de 2 bytes con signo

Short sin signo

Entero de 2 bytes sin signo

Long

Entero de 4 bytes con signo

Long sin signo

Entero de 4 bytes sin signo

LongLong

Entero de 8 bytes con signo

Moneda

Entero de 8 bytes con signo

IEEE Single

Número de 4 bytes de punto flotante

IEEE Double

Número de 8 bytes de punto flotante

Date Time

Fecha-hora de 8 bytes (fecha íntegra, hora fraccionaria)

GUID

Identificador exclusivo de 16 bytes

Binario

Cadena binaria, longitud <= 255

Texto

Cadena ANSI o Unicode, longitud <= 255 bytes

Binario largo

Cadena binaria de valores largos, longitud < 2 GB

Texto largo

Cadena ANSI o Unicode de valores largos, longitud < 2 GB

Los tipos de datos de columna se dividen en dos clases. La primera clase la componen las columnas fijas y variables. La segunda clase son las columnas etiquetadas. Cada columna se define como una estructura FIELD de 16 bytes más el tamaño del nombre de columna. Cuando se crea una tabla en una base de datos ESE, la tabla se define mediante una matriz de estructuras FIELD. Esta matriz identifica las distintas columnas de la tabla. Dentro de esta matriz, cada columna se representa mediante un valor de índice, llamado Id. de columna. Es similar a una matriz normal en la que se puede hacer referencia a miembros de la matriz por el Id., como matriz[0], matriz[1], etc. A las columnas se tiene acceso rápidamente mediante el Id., pero una búsqueda por nombre de columna requiere un examen lineal de toda la matriz de estructuras FIELD.

574

Columnas fijas y variables Las columnas fijas tienen una longitud de datos fija. Cada registro ocupa una cantidad definida de espacio de registro, aunque no se defina ningún valor. Los Id. de tipos de datos del 1 al 10 se pueden definir como columnas fijas. Cada tabla puede definir hasta 126 columnas fijas (Id. de columna del 1 al 127). Las columnas variables pueden tener hasta 256 bytes de datos. En el registro se almacena una matriz de posiciones con el conjunto mayor de columnas variables. Cada columna requiere dos bytes. Los Id. de tipos de datos 10 y 11 se pueden definir como columnas variables. Cada tabla puede definir hasta 127 columnas variables (Id. de columna del 128 al 256).

Columnas etiquetadas ESE define las columnas que rara vez aparecen o que aparecen varias veces en un solo registro como columnas etiquetadas. Las columnas etiquetadas no definidas no producen sobrecarga de espacio. Una columna etiquetada puede aparecer varias veces en el mismo registro. Si una columna etiquetada está representada en un índice secundario, este índice se utiliza para hacer referencia a cada aparición de la columna. Las columnas etiquetadas pueden contener una longitud variable e ilimitada de datos. El Id. y la longitud de la columna se almacenan con los datos. Todos los tipos de datos se pueden definir como columnas etiquetadas. Cada tabla puede definir hasta 64.993 columnas etiquetadas.

Responsabilidades del almacén de información La responsabilidad principal del almacén de Exchange es mantener las bases de datos de Exchange y administrar las transacciones para proporcionar a otros servicios y a los clientes de mensajería acceso a los buzones y a las carpetas públicas. El almacén de Exchange también es responsable de la administración del espacio (la administración de los archivos físicos de base de datos) y del búfer (la administración del uso de memoria del proceso Store.exe).

Interacción con otros servicios de Exchange El almacén de Exchange funciona conjuntamente con algunos otros servicios para realizar operaciones típicas de Exchange. En la tabla siguiente se ofrece un resumen de los servicios esenciales para las operaciones típicas de Exchange. Tenga en cuenta que los servicios que estén disponibles en un determinado servidor Exchange variarán en función de su configuración.

575

Servicios esenciales para las operaciones de Exchange Server 2003 Nombre del servicio

Descripción

Coordinador de transacciones distribuidas

Coordina las transacciones que se distribuyen a varias bases de datos, colas de mensajes y sistemas de archivos.

Registro de sucesos

Registra la información de sucesos, avisos y mensajes de error emitidos por Exchange Server y otras aplicaciones.

Servicio de administración de IIS

Permite administrar el servidor virtual HTTP de Exchange en el complemento IIS.

Sucesos de Microsoft Exchange

Supervisa las carpetas y genera sucesos para las aplicaciones de Exchange Server 5.5.

IMAP4 de Microsoft Exchange

Proporciona los servicios IMAP4 de Exchange.

Almacén de información de Microsoft Exchange

Administra el almacenamiento de información de Exchange.

Pila MTA de Microsoft Exchange

Proporciona los servicios de Exchange X.400.

POP3 de Microsoft Exchange

Proporciona los servicios POP3 de Exchange.

Motor de enrutamiento de Microsoft Exchange

Procesa la información de enrutamiento de mensajes y de estado de vínculos de Exchange.

Servicio de replicación de sitios de Microsoft Exchange

Replica la información de Exchange en la organización.

Servicio Operador de sistema de Microsoft Exchange

Supervisa Exchange y proporciona servicios esenciales.

Protocolo de transferencia de noticias a través de la red (NNTP)

Transporta los mensajes de grupos de noticias por la red.

Protocolo simple de transferencia de correo (SMTP)

Transfiere los mensajes de correo electrónico a través de la red de mensajería.

576

Nombre del servicio

Descripción

Servicio de publicación World Wide Web

Proporciona servicios HTTP para Exchange Server (Microsoft Outlook Web Access, Microsoft Outlook Mobile Access y Microsoft Exchange ActiveSync), además de Servicios de Internet Information Server (IIS).

Administración del espacio Hay dos tipos de espacio en un archivo de base de datos: espacio con propietario y espacio disponible. Cada tabla, índice y árbol B de valores largos tiene su propia lista de páginas con propietario y páginas disponibles. El espacio disponible es una lista de las páginas que se pueden utilizar para almacenar nuevos datos. El espacio disponible es siempre un subconjunto del espacio con propietario. •

Espacio con propietario ESE organiza el espacio con propietario en una jerarquía de tres niveles. Los niveles son la raíz, las tablas y los índices y valores largos de la base de datos. La raíz posee todo el espacio de la base de datos. Las tablas solicitan porciones de espacio, de las que se convierten en propietarios (como ocurre con la raíz de base de datos). Los índices y árboles de valores largos solicitan espacio de la tabla que, a su vez, posee una porción de espacio de la raíz de base de datos. Para reducir el número de solicitudes y evitar la fragmentación del espacio, las solicitudes de espacio adicional se realizan por fragmentos (normalmente, 16 páginas o 64 KB).

•

Espacio disponible El espacio disponible es ligeramente diferente. Una página puede estar disponible en la raíz de base de datos, en el nivel de tabla o como índice o valor largo. Una página sólo está disponible en un nivel.

Desfragmentación de la base de datos La desfragmentación es el proceso mediante el cual ESE recorre las páginas del final (las páginas de hoja) de cada base de datos de árbol B. ESE determina si puede combinar cadenas de páginas contiguas en una sola página. De esta forma, se liberan las páginas y se devuelven al espacio disponible de la tabla. La ubicación y contigüidad de las páginas relacionadas dentro del archivo de base de datos se maximiza siempre que es posible. La desfragmentación se puede realizar en dos modos: •

Desfragmentación en línea Se ejecuta como parte del mantenimiento del sistema que, de forma predeterminada, se realiza entre la 1:00 a.m. y las 6:00 a.m. Si ESE no puede recorrer toda la base de datos, registra el lugar donde se paró y se reanuda desde ese punto cuando se abre la siguiente ventana de mantenimiento del almacén de Exchange. La desfragmentación en línea tiene las siguientes limitaciones:

577

•

•

El espacio libre del archivo de base de datos (.edb) no se devuelve al sistema de archivos, sino que al finalizar la desfragmentación en línea, el servicio Almacén de información ción de Microsoft Exchange registra un suceso en el registro de sucesos de la aplicación (Id. de suceso 1221) que indica la cantidad de espacio libre disponible de la base de datos. Este espacio libre se utiliza si se necesita, antes de que aumente de tamaño tama el archivo físico de base de datos.

•

El espacio disponible de la base de datos tiene el formato de lista de páginas que se pueden utilizar para almacenar nuevos datos. El espacio disponible se denomina árbol de espacio. El árbol de espacio se guarda co como mo un árbol B que se examina cada vez que debe agregarse un bloque de datos nuevos a la base de datos. Los árboles de espacio no se eliminan durante la desfragmentación en línea y permanecen fragmentados hasta que se realiza una desfragmentación sin conexión. conexi

•

Los Id. de columna y de valor largo eliminados no se recuperan.

•

Los índices secundarios se reordenan pero no se regeneran (si resultan dañados, no se reparan).

•

No es posible realizar una combinación vertical en el archivo de base de datos (.edb) (los niveles de árbol no se contraen).

Desfragmentación sin conexión Se trata de un proceso manual que realiza un administrador ejecutando la utilidad ESEUTIL contra las bases de datos. Eseutil.exe es una utilidad de línea de comandos ubicada en el dir directorio \Archivos Archivos de programa\Exchsrvr\Bin. Bin. Nota: Si se monta un buzón o una carpeta pública mientras intenta utilizar ESEUTIL.exe para compactar las bases de datos, aparece el código de error 1032 (JET_errFileAccessDenied). No olvide realizar una copi copia a de seguridad completa antes y después de desfragmentar sin conexión las bases de datos.

Administración del búfer Un objetivo de diseño fundamental de ESE es evitar el acceso a disco. Para ello, ESE utiliza un administrador de búfer muy completo. El administrador administrador de búfer realiza las dos tareas siguientes: •

Decide cuánta memoria debe utilizar la caché del búfer. Para ello se utiliza una característica interna llamada Asignación dinámica de búfer (DBA).

•

Decide qué páginas deben permanecer en la caché del del búfer. Esta decisión se toma con el algoritmo LRU-K.

Asignación dinámica de búfer La Asignación dinámica de búfer (DBA), característica incluida por primera vez en Exchange Server 5.5, se ha convertido en un factor primordial en el uso de memoria del se servicio

578

Almacén de información de Microsoft Exchange. ESE supervisa continuamente el estado de la caché. Comprueba los requisitos del sistema y realiza ajustes en el tamaño de la caché cuando es necesario. La asignación dinámica de búfer utiliza cuatro reglas para determinar el tamaño de la caché: •

Cuanta más memoria haya disponible, más rápidamente aumentará el conjunto de trabajo del almacén de Exchange.

•

Cuanta más memoria caché haya, más rápidamente disminuirá el conjunto de trabajo del almacén de Exchange.

•

Cuanto mayor sea la carga de memoria, más rápidamente aumentará el conjunto de trabajo del almacén de Exchange.

•

Cuanto mayor sea la carga de memoria disponible, más rápidamente disminuirá el conjunto de trabajo del almacén de Exchange.

DBA utiliza una fórmula patentada para determinar cómo debe aumentar o disminuir el tamaño de la caché del búfer a lo largo del tiempo.

El algoritmo de sustitución LRU-K DBA administra el tamaño del búfer. Con el tiempo, el búfer se llena con páginas de base de datos almacenadas en caché. Para dejar espacio para más páginas, las páginas antiguas deben quitarse de la caché. DBA proporciona un mecanismo para determinar qué páginas permanecen en la caché. Tradicionalmente, los sistemas de base de datos utilizan el algoritmo LRU (el menos recientemente utilizado), descrito por primera vez por Denning en 1968 (P. J. Denning, Resource Allocation In Multiprocess Computer Systems, Instituto de tecnología de Massachusetts, Cambridge, MA, 1968). Cuando se necesita espacio de búfer, LRU borra del búfer de memoria la página a la que no se ha tenido acceso desde hace más tiempo. Sin embargo, el algoritmo LRU tiene un defecto. Decide qué página debe borrarse de la memoria en función únicamente de la hora de la última referencia. En realidad, LRU no es capaz de diferenciar las páginas que tienen referencias relativamente frecuentes de las que apenas tienen referencias. Por ejemplo, si a una página se ha tenido acceso 100 veces, seguida de otra página a la que sólo se ha tenido acceso una vez, según LRU se borraría la página a la que se ha tenido acceso 100 veces, sin tener en cuenta el hecho de que esta página es más popular que la otra a la que sólo se ha tenido acceso una vez. Para optimizar el almacenamiento en búfer de disco de base de datos, en 1993 se presentó el algoritmo LRU-K (Elizabeth J. O'Neil, Patrick E. O'Neil, Gerhard Weikum, The LRU-K Page Replacement Algorithm For Database Disk Buffering. Conferencia de SIGMOD, 1993). Este algoritmo supone una mejora con respecto a los algoritmos de búfer convencionales, ya que distingue entre páginas con referencias frecuentes e infrecuentes. Exchange Server 2003 utiliza el algoritmo LRU-K. El algoritmo LRU-K realiza un seguimiento de las horas de las últimas K referencias a páginas en memoria (ESE establece el valor predeterminado de K en 2) y utiliza esta

579

información estadística para clasificar las páginas de acuerdo con las previsiones sobre su comportamiento futuro. A partir de esta información estadística, ESE puede decidir qué página residente en memoria se borra para dejar espacio a una página de reciente acceso que debe leerse en memoria. Dado que la información estadística sobre las páginas utilizadas se recopila constantemente, el algoritmo LRU-K se adapta en tiempo real para cambiar los patrones de acceso. Este algoritmo es muy simple y apenas produce sobrecarga de mantenimiento de registros. Utiliza las dos o más últimas referencias, normalmente las últimas K referencias (donde K es mayor o igual a 2) de cada página para decidir cuál de ellas debe borrarse.

Replicación de carpetas públicas La raíz de un árbol de carpetas públicas, desde el punto de vista del Administrador del sistema de Exchange, constituye la jerarquía de nivel superior. En Exchange Server 2003, puede haber varias jerarquías de nivel superior. La jerarquía de nivel superior de carpetas públicas (denominada también jerarquía de nivel superior MAPI) sólo es uno de los muchos árboles de carpetas públicas. La jerarquía de nivel superior MAPI de Exchange Server 2003 realiza las mismas tareas que en versiones anteriores de Exchange y replica además un árbol de carpetas públicas de Exchange 2000 o de Exchange 5.5. Exchange Server 2003 admite también árboles adicionales, llamados habitualmente jerarquías de nivel superior de aplicaciones. Cada jerarquía de nivel superior tiene una entrada de directorio. La entrada contiene un vínculo de retroceso a los nombres completos de todos los almacenes públicos de la jerarquía de nivel superior. La jerarquía de nivel superior MAPI se encuentra en el directorio bajo el Primer grupo administrativo de la organización de Exchange. Un único servidor sólo puede alojar una base de datos de almacenes de carpetas públicas en una jerarquía de nivel superior. Para los clústeres activo/activo, esto significa que sólo puede haber una instancia de una base de datos de jerarquía de nivel superior en los servidores virtuales de Exchange (EVS) debido a la posibilidad de que ambos EVS se ejecuten en el mismo nodo físico. Exchange Server 2003 Service Pack 1 admite ahora el alojamiento de varias instancias de un árbol de carpetas públicas en un clúster activo/activo, ya que un único nodo físico no puede alojar más de un EVS.

Árboles de base de datos de carpetas públicas La base de datos de carpetas públicas se divide en dos árboles: el IPM_Subtree y el nonIPM_Subtree. El IPM_Subtree contiene carpetas visibles a los usuarios y clientes. Por ejemplo, el árbol IPM_Subtree contiene una carpeta creada por Microsoft Outlook. En las carpetas del IPM_Subtree se pueden realizar búsquedas, tener acceso a ellas directamente y utilizarlas para almacenar datos de usuario. El árbol non-IPM_Subtree contiene carpetas a los que no tienen acceso directo los usuarios. Estas carpetas se replican del mismo modo que las carpetas de IPM_Subtree, pero los usuarios no pueden manipularlas directamente. El árbol non-IPM_Subtree incluye las siguientes carpetas:

580

•

Carpetas de sitios Son carpetas como Información de disponibilidad de Schedule+, Registro de sucesos, Formularios MAPI y Lista de direcciones sin conexión.

•

Restricciones Estas carpetas no se replican.

•

Vistas Estas carpetas no se replican.

Las carpetas de sitios son visibles cuando se examinan las carpetas del sistema en el Administrador del sistema de Exchange Exchange.. Se replican del mismo modo que las carpetas normales, y sus listas de replicación se pueden modificar de la misma forma que estas carpetas. El primer servidor que ejecuta Exchange Server 2003 en un grupo administrativo contiene copias de las listas de dirección dirección sin conexión, los datos de disponibilidad y las réplicas de otras carpetas de sitios. La ubicación de estas carpetas (es decir, el almacén de carpetas públicas que contiene estas carpetas) se puede cambiar con el Administrador del sistema de Exchange. ge. Cada grupo administrativo tiene un servidor de carpetas de sitios (el primer servidor del sitio), que se almacena como un atributo de la entrada de directorio del grupo administrativo. Este atributo determina qué servidor es el encargado de garantizar que existen carpetas del sitio.

Introducción a la replicación La replicación de carpetas públicas es la transferencia de datos de carpetas públicas entre almacenes de carpetas públicas de la misma jerarquía de nivel superior mediante un motor de replicación n basado en correo electrónico. El proceso es el mismo para las jerarquías de nivel superior MAPI y para las jerarquías de nivel superior de aplicaciones. La jerarquía de carpetas se replica mediante mensajes de replicación de jerarquías, y el contenido de las carpetas se replica mediante mensajes de replicación de contenido entre réplicas de las distintas carpetas. Asimismo, hay solicitudes de reposición y mensajes de respuesta, y mensajes de estado y de solicitudes de estado, que mantienen sincronizada la replicación entre almacenes. Nota: Internamente, el almacén controla las carpetas mediante un Id. de carpeta (FID), que es un Id. hexadecimal; por ejemplo 1 1-2A45. 2A45. Un FID es una fila de la tabla de carpetas en el almacén de carpetas públicas. De igual forma, forma, a los mensajes se hace referencia mediante un Id. de mensaje (MID), que es una fila de la tabla MsgFolder. Los mensajes de replicación de jerarquías, por ejemplo, son un tipo especial de mensajes de replicación de contenido para una carpeta con el Id. La replicación utiliza medios de transporte estándar para enviar los mensajes de replicación a otros almacenes de carpetas públicas. Si hay que aplicar una actualización a varios almacenes de carpetas públicas, entonces se genera un único mensaje de replicación, replic dirigido a los distintos almacenes de carpetas públicas (es decir, a la lista de réplicas de la carpeta, ya que para una jerarquía esto es todo lo que almacena la carpeta pública en el nivel superior). El motor de transporte SMTP debe clasificar y bifurcar bifurcar el mensaje para llevarlo hasta cada uno de los almacenes de carpetas públicas. Para obtener más

581

información acerca de la clasificación y bifurcación de mensajes, consulte Arquitectura de transporte SMTP. La replicación de carpetas públicas se basa en el correo electrónico. Los mensajes de replicación son mensajes de correo electrónico enviados entre los almacenes de carpetas públicas de cada jerarquía de nivel superior. Por tanto, debe haber una ruta de acceso de correo electrónico entre los almacenes de carpetas públicas para que la replicación sea posible. Las carpetas se replican mediante el envío de correo electrónico entre los almacenes de carpetas públicas. Por tanto, los almacenes de carpetas públicas requieren direcciones de correo electrónico (agregadas por el servicio de actualización de destino).

Empaquetado y desempaquetado El proceso de incluir datos de replicación en el mensaje de replicación listo para el envío se denomina empaquetado. El proceso de recuperar los datos de replicación del mensaje de replicación se denomina desempaquetado. En un único mensaje de replicación se pueden empaquetar varias actualizaciones de jerarquías o varias actualizaciones de contenido para la misma carpeta. De esta forma, se reduce el tráfico de correo, ya que un solo mensaje puede contener varias actualizaciones (es decir, hay una sobrecarga menor de encabezados de mensaje y sobre de mensaje). Las actualizaciones de jerarquías no se pueden empaquetar en el mismo mensaje de replicación que las actualizaciones de contenido, y las actualizaciones de contenido de distintas carpetas no se pueden empaquetar en el mismo mensaje de replicación.

Números de cambio Todas las actualizaciones (crear, eliminar y modificar) tienen números de cambio asignados. Los números de cambio los utiliza el motor de replicación para realizar un seguimiento de las actualizaciones. Cada modificación realizada en una carpeta recibe un número de cambio. Cuando las actualizaciones se replican en otro servidor, los números de cambio de los cambios específicos se incluyen con la actualización. Los números de cambio los utiliza entonces el servidor de destino para determinar si se trata de un nuevo cambio. El mensaje de replicación transporta también una copia del conjunto completo de números de cambio existentes en la carpeta del servidor de origen, para que el servidor de destino pueda determinar si faltan datos. Un grupo de números de cambio recibe el nombre de conjunto de números de cambio (CNset).

Tipos de mensajes de replicación Hay seis tipos de mensajes de replicación. Los seis tipos son mensajes de replicación de jerarquías (la replicación de contenido de FID 1-1), mensajes de replicación de contenido (la replicación de contenido entre réplicas de carpetas individuales), mensajes de solicitud de

582

reposición, mensajes de respuesta de reposición, mensajes de estado y mensajes de solicitud de estado. Cada uno de estos tipos de mensajes se describe en la tabla siguiente. Tipos de mensajes de replicación Tipo de mensaje

Descripción

Uso

Mensajes de replicación de jerarquías (0x2)

Un mensaje de replicación de jerarquías es un mensaje de replicación entre réplicas de una carpeta especial con el Id. 1-1 (FID 1-1).

Replica los cambios en la jerarquía desde un almacén de carpetas públicas a todos los demás almacenes de carpetas públicas en la misma jerarquía de nivel superior.

Mensajes de replicación de contenido (0x4)

Los mensajes de replicación de contenido replican las actualizaciones de contenido entre réplicas de carpetas individuales. Un almacén de carpetas públicas sólo envía una replicación de contenido a otro almacén de carpetas públicas que contiene una réplica de la carpeta.

Replica los cambios de contenido desde una réplica a todas las demás réplicas de contenido de esa carpeta.

583

Tipo de mensaje

Descripción

Uso

Mensajes de solicitud de reposición (0x8)

La reposición es el proceso mediante el cual los almacenes de carpetas públicas a los que les faltan actualizaciones de replicación pueden solicitar un reenvío de los datos que faltan. El proceso de reposición se compone de dos partes: la solicitud de reposición y la respuesta de reposición. Cuando un almacén de carpetas públicas determina que no está sincronizado, envía una solicitud de reposición al detectar una discrepancia entre el CNSet de una carpeta y el CNSet de algún correo de replicación recibido recientemente. Este proceso se realiza mediante replicación o mediante mensajes de estado enviados por otros almacenes de carpetas públicas.

Los mensajes de solicitud de reposición solicitan los datos que faltan (en CNSet) a otro almacén de carpetas públicas (de jerarquías y de contenido). Los mensajes de solicitud de reposición sólo se envían a otras réplicas de contenido de la carpeta (a todos los miembros de la jerarquía de nivel superior, si se trata de una jerarquía).

584

Tipo de mensaje

Descripción

Uso

Mensajes de respuesta de reposición (0x80000002 o 0x80000004)

Las respuestas de reposición tienen una estructura idéntica a sus equivalentes estándar, pero se envían en respuesta a una solicitud de reposición y sólo se dirigen al solicitante. Contienen los cambios específicamente solicitados. Se pueden enviar varias respuestas para una sola solicitud, si todos los datos solicitados son demasiado grandes para una sola respuesta. Asimismo, una respuesta puede no contener ningún dato.

Los mensajes de respuesta de reposición envían los datos que faltan a un almacén de carpetas públicas que solicita actualizaciones que faltan (CNSet).

585

Tipo de mensaje

Descripción

Uso

Mensajes de estado (0x10)

Un mensaje de estado se envía en respuesta a una solicitud de estado. Contiene el CNSet completo de los cambios con propietario en este servidor. Este conjunto no representa necesariamente todos los cambios que se han producido realmente, ya que puede que no todos los cambios se repliquen en este almacén de carpetas públicas específico.

Envía los CNSet actuales de una carpeta a otra réplica de esa carpeta. Se utiliza para las jerarquías (réplicas de carpeta 1-1) y para el contenido (replicas de contenido específico).

En versiones anteriores a Exchange 2000 Server, se difundían mensajes de estado para todas las carpetas del almacén de carpetas públicas cada 24 horas. Esto daba lugar a una sobrecarga de la red, por lo que esta difusión periódica se ha eliminado en Exchange 2000 Server.

586

Tipo de mensaje

Descripción

Uso

Mensajes de solicitud de estado (0x20)

Envía el CNSet actual de la carpeta a todas las demás réplicas. Al mismo tiempo, solicita que algún subconjunto de esas réplicas devuelva sus propios CNSet. Esta respuesta llega como un mensaje de estado. El servidor de destino no responde si el CNSet del servidor de origen no es un subconjunto estricto del conjunto del servidor de destino.

El almacén de Exchange envía un mensaje de solicitud de estado en las siguiente situaciones: •

Faltan mensajes de replicación en una réplica existente de una carpeta pública o puede que estos mensajes se hayan restaurado desde una copia de seguridad obsoleta. Un almacén de carpetas públicas envía un mensaje de solicitud de estado a otro almacén de carpetas públicas para determinar si falta algún cambio local.

•

Se ha agregado una nueva réplica de una carpeta pública a un almacén de carpetas públicas. Una nueva réplica de una carpeta genera una solicitud de estado del contenido.

•

Se ha creado y asociado un nuevo almacén de carpetas públicas a una jerarquía de carpetas públicas específica. Un nuevo almacén de carpetas públicas genera un solicitud de estado para la jerarquía, porque se ha creado una nueva carpeta de jerarquías (FID 1-1).

•

Se ha quitado una réplica existente de una carpeta pública de un almacén de carpetas públicas. Una carpeta pública eliminada genera también una solicitud de estado porque el contenido de la carpeta de jerarquías

587

Proceso de replicación Los almacenes de carpetas públicas se envían mensajes de replicación entre sí mediante el correo electrónico. Por tanto, debe haber una ruta de acceso de correo electrónico entre los almacenes de carpetas públicas para que puedan recibir los mensajes de replicación. En el proceso Store.exe se ejecuta continuamente un subproceso, que busca sucesos de replicación. Los sucesos de replicación se producen a intervalos de tiempo específicos. Cuando tiene lugar este suceso programado, el subproceso de replicación genera un nuevo subproceso, que realiza la tarea de replicación especificada. Los intervalos de tiempo de replicación predeterminados son los siguientes: •

Los sucesos de replicación de jerarquías se producen cada cinco minutos.

•

Los sucesos de replicación de contenido se producen cada 15 minutos.

•

Se difunde un mensaje de estado 24 horas después de la última difusión de replicación normal.

Replicación de jerarquías Cada vez que se modifica una jerarquía se genera un mensaje de replicación de jerarquías. Éstos son algunos ejemplos de modificación de jerarquías: •

Crear, eliminar o cambiar de nombre una carpeta

•

Modificar los permisos o las descripciones de carpeta

•

Cambiar la configuración de programación y prioridad de la replicación

•

Agregar contenido a una carpeta o eliminarlo

•

Modificar las listas de réplicas

•

Mover la carpeta en la jerarquía

La siguiente figura ilustra el proceso de replicación de jerarquías. Proceso de replicación de jerarquías

En esta ilustración, las Carpetas 1, 2 y 3 se agregan al Servidor A. A continuación, el Servidor A replica los cambios de jerarquía en el Servidor B para que éste último conozca la existencia de estas carpetas públicas en la jerarquía. Los usuarios del Servidor B ahora

588

pueden desplazarse por la jerarquía y seleccionar cualquiera de estas carpetas, pero sólo el Servidor A tiene el contenido de las carpetas públicas. Cuando un cliente intenta tener acceso a las Carpetas 1, 2 o 3, el Servidor B redirige el cliente al Servidor A que, a su vez, devuelve el contenido al cliente para que éste pueda mostrarlo. El proceso de redireccionamiento es transparente para el usuario.

Replicación de contenido El contenido de las carpetas se replica entre réplicas de carpetas individuales. Cuando se modifica el contenido de una carpeta, el cambio se controla mediante números de cambio. Cuando llega el momento de la replicación, los cambios se replican en todos los demás almacenes de carpetas públicas que tienen una réplica de la carpeta. La siguiente figura ilustra el proceso de replicación de contenido. Proceso de replicación de contenido

En esta ilustración, el Elemento 1 se publica en una carpeta del Servidor A, que tiene una réplica en el Servidor B. El almacén de carpetas públicas del Servidor A replica el cambio en el almacén de carpetas públicas del Servidor B. De manera similar, se publican y se replican los Elementos 2 y 3.

Reposición Las carpetas permanecen sincronizadas durante todo el proceso de reposición. Las carpetas sólo se reponen cuando falta contenido. Por tanto, para que una carpeta envíe una solicitud de reposición primero debe determinar que le falta una actualización. Para ello, se determina la secuencia que falta en los CNSet de las distintas carpetas. La reposición de contenido y de jerarquías funciona del mismo modo. Se envía un mensaje de reposición de jerarquías cuando hay una diferencia en los CNSet de la carpeta 1-1. Se solicita una reposición de contenido para las diferencias existentes en cualquier otra carpeta. El proceso de reposición puede tardar mucho tiempo, especialmente si un almacén de carpetas públicas está inactivo y falta la actualización de replicación original y el subsiguiente mensaje de estado. Podría no advertir que falta contenido hasta recibir otros mensajes de replicación.

589

Matriz de reposición La matriz de reposición se utiliza para almacenar solicitudes de reposición pendientes. Cuando el almacén de carpetas públicas determina que una carpeta no está sincronizada, escribe una entrada en la matriz de reposición. Esta entrada es una solicitud pendiente de los datos que faltan de otra réplica de la carpeta. La entrada permanece en la matriz de reposición hasta que se agota el tiempo de espera, momento en el que se envía un solicitud de reposición. Los tiempos de espera de reposición predeterminados se incluyen en la tabla siguiente. Tiempos de espera de reposición predeterminados Reposiciones

Dentro del sitio

Entre sitos

Reposición inicial

6 horas

12 horas

Primer reintento de la reposición

12 horas

24 horas

Siguientes reintentos de la reposición

24 horas

48 horas

Si el primer intento de reposición no recibe respuesta, pasa mucho tiempo hasta que se envían los siguientes intentos de reposición. Estos períodos de tiempo son prolongados para evitar que se produzca una reposición innecesaria. El mensaje de replicación podría estar en tránsito, llegar con retraso o estar a la espera de una programación del conector. Si el tiempo de espera de la reposición fuera demasiado breve, los almacenes de carpetas públicas empezarían a emitir solicitudes de reposición para mensajes que ya están en tránsito.

Estado de la replicación Hay dos clases de mensajes de estado: solicitudes de estado y mensajes de estado. Los mensajes de solicitud de estado se envían desde un almacén de carpetas públicas a otro para solicitar el estado actual de los demás almacenes de carpetas públicas de una determinada carpeta. Los mensajes de estado se envían desde un almacén de carpetas públicas a otro para indicar el estado actual de una determinada carpeta en el servidor de origen. Si el mensaje de estado indica que el almacén de carpetas públicas de origen tiene más información actualizada sobre la carpeta, el almacén de destino escribe una entrada en su matriz de reposición para solicitar una reposición. Si resulta que los CNSet son iguales (o el servidor de destino es más reciente), no se realiza ninguna acción. Un almacén de carpetas públicas genera un mensaje de estado en las siguientes circunstancias: •

En respuesta a una solicitud de estado Si un almacén de carpetas públicas recibe una solicitud de estado de otro almacén de carpetas públicas, devuelve un mensaje de

590

estado. Esto ocurre cuando la lista de réplicas de carpetas cambia (por ejemplo, cuando se quita una carpeta de un servidor). •

24 horas después del último cambio local en una carpeta Éste es un cambio importante con respecto a las versiones anteriores de Exchange. Cuando se realiza un cambio en una carpeta, se establece un tiempo de caducidad para un mensaje de estado en dicha carpeta. Si se realiza otro cambio en esa carpeta, el tiempo de caducidad se restablece en 24 horas.

Cuando se agota el tiempo de caducidad, se genera un mensaje de estado para esa carpeta. A continuación, se borra el tiempo de caducidad y no se generan otros mensajes de estado para esa carpeta salvo que se realice otro cambio, en cuyo caso el tiempo de caducidad se restablece en 24 horas.

Subproceso de estado de replicación El subproceso que determina si debe enviarse un mensaje de estado se ejecuta de forma predeterminada a las 12:15 a.m. y a las 12:15 p.m. (hora del meridiano de Greenwich). Cuando se ejecuta, comprueba si se ha agotado el tiempo de espera de alguna carpeta, en cuyo caso difunde un mensaje de estado. Por tanto, podrían transcurrir hasta 36 horas sin ningún cambio hasta que se generara un mensaje de estado. Los tiempos del subproceso de estado de replicación se pueden modificar con las siguiente opciones del Registro: •

Envío de replicación - Tiempo de espera de estado

•

Replication Send Status Alignment

•

Replication Send Status Alignment Skew

Con el número reducido de mensajes de estado enviados por Exchange Server 2003, no debería ser necesario modificar los valores predeterminados. Para obtener más información acerca de esta configuración, consulte el artículo 203170 de Microsoft Knowledge Base, "XADM: Controlling Public Folder Hierarchy Status Messages".

Solicitudes de estado de replicación Las solicitudes de estado se producen cuando un almacén de carpetas públicas requiere el estado de un servidor remoto para una determinada carpeta. En función de las circunstancias, una solicitud de estado podría activar un mensaje de estado de devolución. Las solicitudes de estado se generan en la siguientes circunstancias: •

Cuando se monta por primera vez un nuevo almacén público Cuando se monta por primera vez un almacén público, se genera una solicitud de estado de jerarquías para la carpeta 1-1 (no se pueden asignar réplicas de contenido a este almacén de carpetas públicas, ya que lo único que falta es la jerarquía). Esto da lugar a que otro almacén de carpetas públicas envíe un mensaje de estado para la jerarquía, con la consiguiente incorporación de varias entradas en la matriz de reposición del nuevo servidor. Al poco

591

rato, se envían solicitudes de reposición para los cambios que faltan, lo que origina que otros servidores envíen mensajes de replicación con las actualizaciones que faltan. •

Cuando la lista de réplicas de una carpeta sufre algún cambio Cuando se modifica la lista de réplicas de una carpeta, se genera un mensaje de solicitud de estado. Al agregar una nueva réplica, eliminar una réplica o reubicar temporalmente una réplica se generan solicitudes de estado.

•

Cuando se restaura una base de datos de almacenes públicos de una copia de seguridad Cuando una base de datos restaurada permanece fuera del bucle de replicación durante una cantidad de tiempo indeterminada, se difunde una solicitud de estado de la jerarquía y de todas las réplicas de contenido de la jerarquía. Esta solicitud realiza dos operaciones. Todos los demás servidores obtienen una imagen revisada de la información de números de cambio de este servidor, y se produce una actualización masiva de la información de números de cambio en la base de datos recién restaurada. Esto hace que se creen entradas de reposición y, en última instancia, que se envíen solicitudes de reposición.

Modificación de la lista de réplicas La modificación de la lista de réplicas es un cambio de jerarquía. Sin embargo, puesto que la lista de réplicas ha cambiado (se han creado o quitado réplicas de carpetas en un servidor), se utilizan también mensajes de estado y solicitudes de estado.

Agregar una réplica Cuando se agrega una nueva réplica a una carpeta, se realizan los siguientes pasos: 1. Se envía un mensaje de replicación de jerarquías para replicar el cambio en la lista de réplicas de la carpeta. 2. El servidor que se acaba de agregar como réplica envía un mensaje de solicitud de estado a todos los demás servidores de réplicas de contenido. 3. Como este servidor tiene un CNSet vacío, es un subconjunto estricto de los CNSet de todas las demás réplicas de contenido, por lo que todas ellas responden con un mensaje de estado. 4. Se crean entradas de reposición, se envían solicitudes de reposición a los servidores correspondientes y los servidores responden con contenido. 5. En cualquier momento después del paso 1, otras réplicas de contenido podrían enviar difusiones de replicación de contenido normales al nuevo servidor de réplicas. Puede que los pasos 1 y 2 no se produzcan siempre en el mismo orden: dependerá del almacén de carpetas públicas en el que se haya realizado el cambio original. Si el administrador efectúa el cambio en un servidor que tiene una réplica de contenido, los pasos tendrán lugar en el orden anterior. Si el administrador efectúa el cambio en el servidor que contiene la nueva réplica, los pasos 1 y 2 se pueden producir en el orden inverso.

592

Eliminar una réplica Cuando una réplica se quita de un servidor, la carpeta no se elimina inmediatamente, sino que se coloca en el estado pendiente de eliminación. Cuando una carpeta se encuentra en este estado, no puede ser examinada ni administrada por un cliente (el Administrador del sistema de Exchange no muestra la carpeta en la lista de carpetas alojadas en el almacén de carpetas públicas). El estado pendiente de eliminación existe para que otras réplicas puedan replicar a partir de ella cualquier dato que falte. Una vez que la carpeta pendiente de eliminación recibe mensajes de estado de todas las demás réplicas, lo que indica que las carpetas están sincronizadas, la réplica se elimina. Este proceso garantiza que si se cambia la única réplica de una carpeta de un servidor a otro, no se pierda el contenido. Al eliminar una réplica, se producen las siguientes operaciones: 1. La carpeta se quita de la lista de réplicas. 2. Un mensaje de jerarquía se replica, que indica el cambio en el estado de la carpeta (por ejemplo, Activo -> Pendiente de eliminación). 3. El servidor que contiene la carpeta pendiente de eliminación envía una solicitud de estado, que requiere una respuesta. 4. Un servidor con una réplica responde a la solicitud de estado con un mensaje de estado. Si el mensaje de estado indica que los CNSet son al menos tan actuales como la réplica que se va a eliminar, el almacén de carpetas públicas realiza el paso 5. En caso contrario, continúa enviando solicitudes de estado hasta que recibe la respuesta correcta. 5. La carpeta que se va a eliminar cambia su estado de pendiente de eliminación a eliminar ahora y se elimina.

Tablas de estado de replicación Cada carpeta replicada (incluida la jerarquía) tiene un conjunto de filas en la tabla de estado de replicación, que contiene información sobre el estado de replicación de cada carpeta. Cada fila del conjunto de filas de una carpeta representa un réplica de esa carpeta. La fila del servidor local contiene, entre otros datos, el número de cambio que se difundió por última vez, el CNSet con propietario local, la matriz de reposición y la hora en que debe producirse la siguiente difusión de estado. Las filas de las otras réplicas contienen, entre otros datos, la última información de CNSet que el servidor local ha recibido de cada uno de los demás servidores (uno por fila), el tiempo medio de transmisión para el correo electrónico de replicación de cada uno de los demás servidores y la última hora en que se envió una solicitud de reposición a cada uno de los demás servidores. Cada vez que se envía un mensaje de replicación, el CNSet de la tabla de estado de replicación de la réplica local de la carpeta se incluye con el mensaje.

593

Las propias tablas de estado de replicación no se replican. La replicación la generan los datos de los CNSet. Así es cómo los almacenes de carpetas públicas determinan los datos que contienen otras réplicas de una carpeta. Nota: Cada servidor realiza un seguimiento de las actualizaciones de los demás servidores mediante un Id. de replicación (ReplID). Los ReplID se calculan localmente. Por tanto, los almacenes de carpetas públicas no tienen los mismos Repl ReplID en distintos servidores.

Programación de sucesos de replicación predeterminados En la tabla siguiente se ilustran algunos de los tiempos de espera predeterminados más comunes asociados a sucesos de replicación. El subproceso principal de tareas de replicación cación genera subprocesos de trabajo adicionales que se encargan de las tareas de replicación cuando se agotan estos tiempo de espera predeterminados. Si no hay nada que replicar, el subproceso simplemente está ahí y no se genera ningún mensaje de replicación. replicac Tiempos predeterminados de sucesos de replicación Suceso de replicación

Tiempo de espera

Comentarios

predeterminado

Caducidad de replicación

24 horas

Indica la frecuencia con la que se comprueba la caducidad de las carpetas.

Envío de replicación Siempre

15 minutos

Éste es el valor predeterminado de Replicar siempre. Indica la frecuencia con la que almacén comprueba si es necesario replicar contenido. Este valor se puede ajustar con el Administrador del sistema de Exchange.

Envío de replicación - Árbol de carpetas

5 minutos

Indica la frecuencia con la que el almacén de carpetas públicas comprueba si es necesario enviar un mensaje de replicación de jerarquías.

594

Suceso de replicación

Tiempo de espera

Comentarios

predeterminado

Envío de replicación - Tiempo 24 horas de espera de estado

Indica la frecuencia con la que el almacén de carpetas públicas comprueba si debe enviarse un mensaje de estado para una carpeta.

Tiempo de espera de replicación

5 minutos

Indica la frecuencia con la que el almacén de carpetas públicas comprueba si se ha agotado el tiempo de espera de alguna entrada de reposición.

Replicación - Intervalo de tiempo de solicitud de reposición de nueva réplica

15 minutos

Es el intervalo de tiempo antes de enviar una solicitud de reposición de una nueva réplica de una carpeta cuando los datos están disponibles en el mismo sitio.

Replicación - Intervalo de tiempo corto de solicitud de reposición

6 horas

Es el intervalo de tiempo antes de enviar una solicitud de reposición cuando los datos están disponibles en el mismo sitio.

Replicación - Intervalo de tiempo largo de solicitud de reposición

12 horas

Es el intervalo de tiempo antes de enviar una solicitud de reposición cuando los datos no están disponibles en el mismo sitio.

Replicación - Tiempo de espera corto de solicitud de reposición

12 horas

Es el valor de tiempo de espera utilizado al reintentar enviar una solicitud de reposición cuando los datos están disponibles en el mismo sitio.

595

Suceso de replicación

Tiempo de espera

Comentarios

predeterminado

Replicación - Tiempo de espera largo de solicitud de reposición

24 horas

Es el valor de tiempo de espera utilizado al reintentar enviar una solicitud de reposición cuando los datos no están disponibles en el mismo sitio.

Replicación - Reintento de tiempo de espera corto de solicitud de reposición

24 horas

Es el valor de tiempo de espera que se utiliza al enviar una solicitud de reposición cuando los datos están disponibles en el mismo sitio y esta solicitud es un reintento de una solicitud de reposición anterior.

Replicación - Reintento de tiempo de espera largo de solicitud de reposición

48 horas

Es el valor de tiempo de espera que se utiliza al enviar una solicitud de reposición cuando los datos no están disponibles en el mismo sitio y esta solicitud es un reintento de una solicitud de reposición anterior.

Valores de replicación predeterminados En la tabla siguiente se ilustran algunos de los demás valores predeterminados utilizados en la replicación de carpetas públicas. Valores de replicación predeterminados Descripción

Valor

Número límite de carpetas de 20 replicación

Comentarios

Número máximo de carpetas que se pueden empaquetar en un mensaje de replicación de jerarquías.

596

Descripción

Valor

Comentarios

Número límite de carpetas eliminadas de replicación

500

Número máximo de eliminaciones de carpetas que se pueden empaquetar en un mensaje de replicación de jerarquías.

Número límite de mensajes de replicación

100

Número máximo de mensajes que se pueden empaquetar en un mensaje de replicación de contenido.

Tamaño límite de mensajes de replicación

300 KB

Tamaño máximo de los mensajes de replicación. Este valor se puede ajustar con el Administrador del sistema de Exchange. Si es necesario, un mensaje de replicación podría superar este límite. Este valor representa el tamaño en el que la función de empaquetado debe detener el empaquetado. Si un solo elemento para exponer de una carpeta supera este límite, se envía sólo, en su totalidad.

Arquitectura de clústeres de Exchange Server 2003 En Microsoft Windows Server 2003, un clúster de servidores es una organización de equipos individuales, cada uno de los cuales ejecuta el servicio Microsoft Windows Cluster. Los equipos que forman el clúster de servidores están conectados entre sí a través de una red y un sistema de discos compartidos. Los clústeres de servidores ofrecen dos ventajas importantes. En primer lugar, el servicio Cluster Server controla los servidores que pertenecen a un clúster. Si un servicio deja de funcionar en un servidor, el servicio Cluster Server vuelve a activar el servicio rápidamente enrutándolo a través de otro servidor. Con esto se reduce el tiempo de inactividad del sistema. En segundo lugar, los clústeres de servidores simplifican las tareas de mantenimiento de hardware y software. Puede realizar

597

una actualización sucesiva moviendo recursos del clúster, denominados comúnmente servidores virtuales, a otros nodos y realizando después después actualizaciones de hardware o software en el nodo original. Puede evitar el tiempo de inactividad y simplificar el mantenimiento del sistema implementando Microsoft Exchange Server 2003 en un clúster de servidores Windows Server 2003. Nota: Para instalar Exchange 2003 en un clúster de servidores con un máximo de ocho nodos, debe utilizar Windows Server 2003 Enterprise Edition o Datacenter Edition y Exchange Server 2003 Enterprise Edition. Puede encontrar un estudio comparativo de características cas de la familia de productos Windows Server 2003 en http://go.microsoft.com/fwlink/?LinkId=33135 (en inglés). En esta sección se describe la arquitectura del servicio Cluster Server de Windows, a así como la interacción entre Exchange Server 2003 Enterprise Edition y dicho servicio. Se incluye información sobre las tareas que deben realizarse en los servidores Exchange que se ejecutan en un clúster de servidores. Se ofrece información detallada sobre sobr los siguientes temas: •

Arquitectura del servicio Cluster Server de Windows En esta sección se describen las características generales de los sistemas organizados por clústeres que ejecutan Windows Server 2003. Las soluciones de alta disponibilidad de los servidores de buzones de Exchange 2003 exigen conocer la arquitectura del servicio Cluster Server de Windows y cómo este servicio interactúa con las aplicaciones compatibles con clústeres como Exchange 2003.

•

Servidores virtuales de Exchange Un servidor virtual de Exchange es una instancia de Exchange 2003 Enterprise Edition configurada para ejecutarse en un clúster de servidores. Las características de los servidores virtuales determinan cómo se conectan los clientes a Exchange 2003 en un clústerr de servidores, independientemente del nodo físico que ejecute Exchange 2003.

•

Interacción entre Exchange 2003 Enterprise Edition y el servicio Cluster Server El servicio Cluster Server de Windows controla los nodos físicos de un clúster y los recursos alojados en dichos nodos. Hay una interacción continua entre el servicio Cluster Server y los distintos recursos del clúster de Exchange que componen un servidor virtual de Exchange en un clúster.

•

Configuraciones específicas del clúster Aunque ejecutarr Exchange 2003 en un clúster de servidores Windows es muy similar a ejecutar un servidor de Exchange independiente (es decir, fuera del clúster), hay algunas consideraciones que son exclusivas a los clústeres. Por ejemplo, determinados recursos de Exchange Exchang 2003 que se ejecutan en un clúster requieren configuraciones específicas para comunicarse en un servidor de clúster.

Para obtener más información sobre las tecnologías de organización por clústeres, consulte Clustering Technologies (en inglés).

598

Arquitectura de clústeres de Windows Microsoft Cluster Server (MSCS) de Microsoft Windows NT Server 4.0 Enterprise Edition fue la primera tecnología de clústeres de servidores que ofreció Microsoft. Los distintos servidores que componen un clúster se denominan nodos. Un servicio de Cluster Server es un conjunto de componentes en cada nodo que realizan tareas específicas del clúster. Los componentes de hardware y software del clúster administrados por el servicio de Cluster Server se denominan recursos. Los clústeres de servidores proporcionan el mecanismo de instrumentación para administrar recursos a través de DLL de recursos, que definen abstracciones de recursos (es decir, abstraen un recurso de un clúster de un nodo físico específico para que pueda moverse de un nodo a otro), interfaces de comunicación y operaciones de administración. Los recursos son elementos de un clúster que: •

Se conectan (en servicio) y se desconectan (fuera de servicio)

•

Se administran en un clúster de servidores

•

Son propiedad de un solo nodo cada vez

Un grupo de recursos es un conjunto de recursos administrados por el servicio de Cluster Server como una única unidad lógica. Esta unidad lógica recibe a menudo el nombre de unidad de conmutación, porque todo el grupo se mueve como una sola unidad de un nodo a otro. Los recursos y los elementos del clúster se agrupan lógicamente en función de los recursos agregados a un grupo de recursos. Cuando se realiza una operación del servicio de Cluster Server en un grupo de recursos, resultan afectados todos los recursos individuales incluidos en el grupo. Normalmente, se crea un grupo de recursos que contiene los recursos individuales necesarios para el programa del clúster. Los recursos del clúster pueden incluir dispositivos de hardware físicos, como unidades de disco y tarjetas de red, y elementos lógicos, como direcciones IP, nombres de red y componentes de aplicación. Los clústeres incluyen también recursos comunes, como matrices de almacenamiento de datos externas y redes de clústeres privadas. Todos los nodos del clúster tienen acceso a los recursos comunes. Un recurso común es el recurso de quórum, que desempeña una función crítica en las operaciones del clúster. El recurso de quórum debe estar accesible para todas las operaciones del nodo, incluidas la formación, unión o modificación de un clúster.

Clústeres de servidores Windows Server 2003 Enterprise Edition proporciona dos tipos de tecnologías de clústeres para Exchange Server 2003 Enterprise Edition. La primera son los servicios Cluster Server, que permiten la conmutación por error de los servidores de buzones de servicios de fondo que requieren un alto nivel de disponibilidad. La segunda es el equilibrio de carga de red (NLB), que complementa los clústeres de servidor al permitir clústeres con una gran

599

disponibilidad y escalabilidad de servidores virtuales de protocolo de Exchange de aplicaciones para el usuario (por ejemplo, HTTP, IMAP4 y POP3). Los clústeres de servidores utilizan un modelo de clúster sin elementos compartidos. Los tipos de modelos definen cómo los servidores de un clúster administran y utilizan los dispositivos y recursos del clúster locales y comunes. En un clúster sin elementos compartidos, cada servidor posee y administra sus dispositivos locales. Los dispositivos comunes al clúster, como las matrices de disco comunes y los medios de conexión, son propiedad de un sólo nodo y son administrados por un solo nodo cada vez de forma selectiva. Los clústeres de servidores utilizan controladores de Windows estándar para conectar con dispositivos y medios de almacenamiento locales. Los clústeres de servidores permiten varios medios de conexión para los dispositivos comunes externos, a los que deben tener acceso todos los servidores del clúster. Los dispositivos de almacenamiento externo son compatibles con las conexiones SCSI basadas en el bus PCI estándar, SCSI a través de Fibre Channel y SCSI con varios interlocutores. Las conexiones de fibra son dispositivos SCSI alojados en un bus Fibre Channel en lugar de en un bus SCSI. En la figura siguiente se ilustran los componentes de un clúster de servidores de dos nodos, formado por servidores que ejecutan Windows Server 2003 Enterprise Edition, con conexiones de dispositivos de almacenamiento compartidos que utilizan SCSI o SCSI a través de Fibre Channel. Ejemplo de un clúster de Windows con dos nodos

Arquitectura de clústeres de servidor Arquitectura del clúster de servidores Los clústeres de servidores están diseñados como conjuntos de componentes aislados e independientes, que funcionan conjuntamente con Windows Server 2003. Se pueden realizar modificaciones en el sistema operativo una vez instalado el servicio de Cluster Server. Estas modificaciones son las siguientes: •

Compatibilidad con la creación y eliminación dinámicas de nombres y direcciones de red

•

Modificaciones en el sistema de archivos, para permitir el cierre de archivos abiertos cuando se desmontan las unidades de disco

600

•

Modificaciones en el subsistema de almacenamiento, para permitir el uso compartido de discos y volúmenes entre varios nodos

Aparte de estas y de otras modificaciones menos importantes, un servidor con el servicio de Cluster Server de Windows se ejecuta de la misma forma que un servidor sin este servicio. El servicio de Cluster Server es el componente básico de los clústeres de servidores. Este servicio está formado por varias unidades funcionales, entre las que se incluyen el Administrador de nodos, el Administrador de conmutación por error, el Administrador de bases de datos, el Administrador de actualizaciones globales, el Administrador de puntos de control, el Administrador de registros, el Administrador de replicación de registros de sucesos y el Administrador de copias de seguridad y restauraciones.

Componentes del servicio de Cluster Server El servicio de Cluster Server se ejecuta en Windows Server 2003 Enterprise Edition mediante procesos de instrumentación de controladores de red, controladores de dispositivos y recursos especialmente diseñados para clústeres de servidores y sus procesos integrantes. El servicio de Cluster Server incluye los siguientes componentes: •

Administrador de puntos de control Este componente guarda las claves del Registro de aplicaciones en un directorio del clúster almacenado en el recurso de quórum. Para garantizar que el servicio de Cluster Server pueda recuperarse tras un error de un recurso, el Administrador de puntos de control comprueba las claves del Registro cuando se conecta un recurso y escribe datos de punto de control en el recurso de quórum cuando se desconecta un recurso. El Administrador de puntos de control admite también recursos con árboles de Registro específicos de la aplicación con una instancia en el nodo del clúster, donde se conectan. Un recurso puede tener uno o varios árboles de Registro asociados. Cuando el registro está conectado, el Administrador de puntos de control supervisa los cambios realizados en estos árboles del Registro. Si detecta algún cambio, transfiere el árbol del Registro al nodo propietario del recurso. A continuación, transfiere el archivo al nodo propietario del recurso de quórum. El Administrador de puntos de control realiza transferencias por lotes, para que los cambios frecuentes en los árboles del Registro no supongan una carga demasiado grande para el servicio de Cluster Server.

•

Administrador de bases de datos El Administrador de bases de datos mantiene información de configuración sobre todas las entidades físicas y lógicas de un clúster. Estas entidades incluyen el propio clúster, la pertenencia al nodo de clúster, los grupos de recursos, los tipos de recursos y las descripciones de recursos específicos, como discos y direcciones IP. La información permanente y volátil almacenada en la base de datos de configuración controla el estado actual y deseado de un clúster. Cada instancia del Administrador de bases de datos que se ejecuta en cada nodo del clúster ayuda a mantener información de configuración coherente en todo el clúster y a garantizar la coherencia de las copias de base de datos de configuración en todos los nodos.

601

El Administrador de bases de datos proporciona también una interfaz que utilizan otros componentes ntes del servicio de Cluster Server, como el Administrador de conmutación por error y el Administrador de nodos. Esta interfaz es similar a la interfaz del Registro de las API Win32 de Microsoft. Sin embargo, la interfaz del Administrador de bases de datos escribe los cambios realizados en las entidades del clúster en el Registro y en el recurso de quórum. El Administrador de bases de datos permite actualizaciones transaccionales de la sección del Registro del clúster y sólo presenta interfaces a los comp componentes internos del servicio de Cluster Server. El Administrador de conmutación por error y el Administrador de nodos suelen utilizar esta compatibilidad con las transacciones para obtener transacciones replicadas. La API del servicio de Cluster Server presenta pr todas las funciones del Administrador de bases de datos a los clientes, salvo las funciones de compatibilidad con transacciones. Para obtener información adicional acerca de la API del servicio de Cluster Server, consulte Cluster API en MSDN. Nota: El Administrador de puntos de control registra los datos y los cambios de la clave del Registro de aplicaciones en archivos de registro de quórum en el recurso de quórum. •

Servicio de sucesos El Servicio de sucesos actúa como una centralita, que envía sucesos desde y hacia aplicaciones y a los componentes del servicio de Cluster Server en cada nodo. El componente Procesador de sucesos del Servicio de sucesos ayuda a los componentes del servicio servicio de Cluster Server a diseminar la información sobre sucesos importantes entre todos los demás componentes. El componente Procesador de sucesos es compatible con el mecanismo de sucesos de la API del servicio de Cluster Server. Realiza además otros servic servicios, ios, como la entrega de sucesos de señal a aplicaciones compatibles con clústeres y el mantenimiento de objetos de clúster.

•

Administrador de replicación de registro de sucesos Este administrador replica las entradas del registro de sucesos de un nodo e en n los demás nodos del clúster. De forma predeterminada, el servicio de Cluster Server interactúa con el servicio Registro de sucesos de Windows del clúster para replicar las entradas del registro de sucesos en todos los nodos del clúster. Cuando el servicio servicio de Cluster Server se inicia en el nodo, llama a una API privada del servicio local Registro de sucesos y solicita al servicio Registro de sucesos que se enlace con el servicio de Cluster Server. A continuación, el servicio Registro de sucesos se enlaza ccon on la interfaz CLUSAPI mediante llamadas a procedimientos remotos locales (RPC). Cuando el servicio Registro de sucesos recibe un suceso que debe registrarse, lo registra localmente, lo vuelca en una cola de lotes permanente y programa un subproceso de temporizador temporizador para que se ejecute al cabo de 20 segundos, si aún no hay ningún subproceso de temporizador activo. Cuando se activa el subproceso de temporizador, éste procesa la cola de lotes y envía los sucesos, como un búfer consolidado, a la interfaz API de dell servicio de Cluster Server, en la que se ha enlazado previamente el servicio Registro de sucesos. La interfaz envía a continuación el suceso al servicio de Cluster Server.

602

Cuando el servicio de Cluster Server recibe los sucesos por lotes del servicio Registro de sucesos, los vuelca en una cola de salida local y regresa de la llamada RPC. El subproceso de difusión de sucesos del servicio de Cluster Server procesa entonces esta cola y envía los sucesos, mediante la RPC interna del clúster, a todos los nodos del clúster activos. La API del servidor vuelca entonces los sucesos a una cola de entrada. A continuación, un subproceso de escritura de registros de sucesos procesa esta cola y solicita, mediante una RPC privada, que el servicio Registro de sucesos local escriba los sucesos localmente. El servicio de Cluster Server utiliza la llamada ligera a procedimiento remoto (LRPC) para llamar a las interfaces RPC privadas del servicio Registro de sucesos. Este servicio utiliza también LRPC para llamar a la interfaz API del servicio de Cluster Server y, a continuación, solicita que el servicio de Cluster Server replique los sucesos. •

Administrador de conmutación por error Este administrador realiza la administración de recursos e inicia las acciones correspondientes, como el arranque, el reinicio y la conmutación por error. El Administrador de conmutación por error detiene e inicia recursos, administra las dependencias de recursos e inicia la conmutación por error de grupos de recursos. Para realizar estas operaciones, el Administrador de conmutación por error recibe información de los recursos y del estado del sistema de los monitores de recursos y de los nodos del clúster. Este administrador decide también qué nodos del clúster deben ser propietarios de los grupos de recursos. Cuando finaliza el arbitraje de grupos de recursos, los nodos que poseen un grupo de recursos individual devuelven el control de los recursos del grupo al Administrador de nodos. Si un nodo no puede hacerse cargo de un error de uno de sus grupos de recursos, los administradores de conmutación por error de cada nodo funcionan conjuntamente para reasignar el propietario del grupo de recursos. Si un recurso produce un error, el Administrador de conmutación por error reinicia el recurso o desconecta el recurso y sus recursos dependientes. Si desconecta el recurso, esto indica que la propiedad del recurso se ha movido a otro nodo. Entonces se reinicia el recurso en el nuevo nodo propietario. Este proceso se denomina conmutación por error y se describe en la sección "Conmutación por error del clúster" más adelante en este tema.

•

Administrador de actualizaciones globales El Administrador de actualizaciones globales proporciona el servicio de actualizaciones globales utilizado por los componentes del clúster. Este administrador lo utilizan los componentes internos del clúster, como el Administrador de conmutación por error, el Administrador de nodos y el Administrador de bases de datos, para replicar los cambios realizados en la base de datos del clúster en los nodos. Las actualizaciones realizadas por este administrador se inician normalmente a partir de una llamada a la API del servicio de Cluster Server. Cuando se inicia una de estas actualizaciones en un nodo cliente, en primer lugar se solicita a un nodo de bloqueo que obtenga un bloqueo global. Si el bloqueo no está disponible, el cliente espera hasta que haya uno disponible.

603

Cuando el bloqueo está disponible, el nodo de bloqueo otorga el bloqueo al cliente y emite la actualización localmente (en el nodo de bloqueo). A continuación, el cliente emite la actualización a todos los demás nodos en buen estado, incluido el suyo propio. Si la actualización se realiza correctamente en el nodo de bloqueo, pero no se puede realizar en algún otro nodo, ese nodo se retira de la pertenencia al clúster actual. Si la actualización produce un error en el propio nodo de bloqueo, este nodo simplemente devuelve el error al cliente. •

Administrador de registros El Administrador de registros escribe los cambios en los registros de recuperación que están almacenados en el recurso de quórum. El Administrador de registros, junto con el Administrador de puntos de control, garantiza que el registro de recuperación del recurso de quórum contenga los datos de configuración y los puntos de control de cambios más recientes. Si alguno de los nodos del clúster está inactivo, los cambios de configuración se pueden realizar en los nodos restantes. Mientras estos nodos están inactivos, el Administrador de bases de datos utiliza el Administrador de registros para registrar los cambios de configuración en el recurso de quórum. Cuando se reactivan los nodos que han dejado de funcionar, leen la ubicación del recurso de quórum de las secciones del Registro de su clúster local. Como los datos de la sección pueden estar anticuados, existen mecanismos para detectar los recursos de quórum no válidos que se leen de una base de datos de configuración del clúster anticuada. A continuación, el Administrador de bases de datos solicita al Administrador de registros que actualice la copia local de la sección del clúster, mediante el archivo de punto de control de recurso de quórum. El archivo de registro se reproduce entonces en el disco de quórum, empezando por el número de secuencia del registro de punto de control. El resultado es una sección del clúster totalmente actualizada. Siempre que se reinicia el registro de quórum y una vez cada cuatro horas se toman instantáneas de la sección del clúster.

•

Administrador de pertenencia El Administrador de pertenencia supervisa la pertenencia al clúster y el estado de todos los nodos del clúster. Este administrador (llamado también Motor de reagrupación) mantiene una imagen coherente de los nodos del clúster que están actualmente activos o inactivos. El núcleo del componente Administrador de pertenencias es un algoritmo de reagrupación que se invoca siempre que existen indicios de un error en algún nodo. Una vez aplicado el algoritmo, todos los nodos participantes tienen la misma información sobre la nueva pertenencia al clúster.

•

Administrador de nodos El Administrador de nodos asigna la pertenencia del grupo de recursos a los nodos, en función de listas de preferencia de grupos y de la disponibilidad de los nodos. Este administrador se ejecuta en cada nodo y conserva una lista local de los nodos que pertenecen al clúster. Periódicamente, el Administrador de nodos envía mensajes, denominados latidos, a sus homólogos que se ejecutan en otros nodos del clúster para detectar errores en los nodos. Todos los nodos del clúster deben tener exactamente la misma información sobre la pertenencia al clúster.

604

Si un nodo del clúster detecta un error de comunicación con otro nodo del clúster, transmite un mensaje de multidifusión a todo el clúster. Este suceso de reagrupación permite que todos los miembros comprueben su información de pertenencia actual al clúster. Durante el suceso de reagrupación, el servicio de Cluster Server impide que se realicen operaciones de escritura en los dispositivos de disco comunes a todos los nodos del clúster hasta que se estabilice la pertenencia. Si una instancia del Administrador de nodos en un determinado nodo no responde, el nodo se quita del clúster, y sus grupos de recursos activos se mueven a otro nodo activo. Para realizar este cambio, el Administrador de nodos identifica los posibles propietarios (nodos) que poseen recursos individuales y el nodo en el que un grupo de recursos prefiere ejecutarse. A continuación, selecciona el nodo y mueve el grupo de recursos. En un clúster de dos nodos, el Administrador de nodos simplemente mueve los grupos de recursos del nodo que ha experimentado errores al otro nodo. En un clúster formado por tres o más nodos, el Administrador de nodos distribuye selectivamente los grupos de recursos entre los demás nodos. El Administrador de nodos actúa también como guardián, permitiendo la incorporación de nodos en el clúster y procesando las solicitudes para agregar o desalojar un nodo. •

Monitor de recursos El monitor de recursos comprueba el estado de cada recurso del clúster mediante devoluciones de llamada a los archivos DLL de recursos. Los monitores de recursos ejecutan un proceso independiente y se comunican con el servicio de Cluster Server a través de RPC. De esta forma, se protege al servicio de Cluster Server de los errores experimentados por recursos individuales del clúster. Los monitores de recursos proporcionan la interfaz de comunicación entre los archivos DLL de recursos y el servicio de Cluster Server. Cuando el servicio de Cluster Server debe obtener datos de un recurso, el monitor de recursos recibe la solicitud y la reenvía al archivo DLL de recursos correspondiente. De modo inverso, cuando un archivo DLL de recursos debe informar de su estado o notificar un suceso al servicio de Cluster Server, el monitor de recursos reenvía la información del recurso al servicio de Cluster Server. El proceso del monitor de recursos (RESRCMON.EXE) es un proceso secundario del proceso de servicio de Cluster Server (CLUSSVC.EXE). El monitor de recursos carga los archivos DLL de recursos que supervisan los recursos del clúster en su espacio de procesamiento. La carga de los archivos DLL de recursos en un proceso independiente del proceso del servicio de Cluster Server ayuda a aislar los errores. Se pueden crear instancias de varios monitores de recursos al mismo tiempo. Cada monitor de recursos funciona como un servidor LRPC para el proceso del servicio de Cluster Server. Cuando este servicio recibe una llamada a la API de Cluster Server que requiere comunicación con el archivo DLL de recursos, utiliza la interfaz LRPC para invocar a la RPC del monitor de recursos. Para recibir las respuestas del monitor de recursos, el servicio de Cluster Server crea un subproceso de notificación para cada proceso del monitor de recursos. Este subproceso de notificación llama a la RPC ubicada permanentemente en el monitor de recursos. El subproceso obtiene las

605

notificaciones a medida que se generan. El subproceso sólo se lanza cuando el monitor de recursos deja de funcionar o cuando un comando de cierre del servicio de Cluster Server detiene manualmente el subproceso. El monitor de recursos no conserva un estado permanente por sí solo. Conserva un estado en memoria limitado de los recursos, pero el servicio de Cluster Server proporciona toda la información de su estado inicial. El monitor de recursos se comunica con los archivos DLL de recursos a través de los puntos de entrada correctos que estos archivos deben contener. El monitor de recursos realiza las siguientes operaciones por sí solo: •

Sondea los archivos DLL a través de los puntos de entrada IsAlive y LooksAlive, comprobando alternativamente los sucesos de error señalados por los archivos DLL de recursos.

•

Para supervisar los tiempos de espera pendientes de los archivos DLL de recursos, genera subprocesos que devuelven ERROR_IO_PENDING desde los puntos de entrada Online u Offline de los archivos DLL.

•

Detecta los bloqueos del servicio de Cluster Server y cierra los recursos.

Las demás acciones que realiza son el resultado de las operaciones solicitadas por el servicio de Cluster Server a través de la interfaz RPC. El servicio de Cluster Server no realiza ninguna operación de detección de interrupciones. Sin embargo, supervisa los bloqueos y reinicia un monitor si detecta el bloqueo de un proceso. El servicio de Cluster Server y el proceso del monitor de recursos comparten una sección asignada en memoria respaldada por el archivo de paginación. El control de la sección se pasa al monitor de recursos al arrancar. El monitor de recursos duplica entonces el control y registra el número de punto de entrada y el nombre del recurso en esta sección justo antes de llamar a un punto de entrada del archivo DLL de recursos. Si el monitor de recursos se bloquea, el servicio de Cluster Server lee la sección compartida para detectar el recurso y el punto de entrada que han originado el bloqueo. •

Administrador de copias de seguridad y restauraciones Este administrador funciona con el Administrador de conmutación por error y el Administrador de bases de datos para hacer una copia de seguridad o restaurar el archivo de registro de quórum y todos los archivos de punto de control. El servicio de Cluster Server utiliza la API BackupClusterDatabase para la copia de seguridad de la base de datos. En primer lugar, la API BackupClusterDatabase se pone en contacto con el nivel del Administrador de conmutación por error. Este nivel reenvía la solicitud al nodo que es actualmente propietario del recurso de quórum. Ese nodo llama entonces al Administrador de bases de datos, que hace una copia de seguridad del archivo de registro de quórum y de todos los archivos de punto de control. El servicio de Cluster Server se registra también a sí mismo durante el arranque como responsable de la copia de seguridad con el servicio de instantáneas de volumen. Cuando un cliente de copia de seguridad llama al servicio de instantáneas de volumen para realizar una copia de seguridad del estado del sistema, llama también al servicio de Cluster Server a través de una serie de llamadas de puntos de entrada, para realizar la

606

copia de seguridad de la base de datos del clúster. El código de servidor del servicio de Cluster Server llama al Administrador de conmutación por error para realizar la copia de seguridad, y el resto de la operación se efectúa a través de la API BackupClusterDatabase. El servicio de Cluster Server utiliza la API RestoreClusterDatabase para restaurar la base de datos del clúster desde la ruta de acceso de copia de seguridad. Esta API sólo puede llamarse localmente desde uno de los nodos del clúster. Cuando se llama a la API RestoreClusterDatabase API, ésta detiene el servicio de Cluster Server, restaura la base de datos del clúster a partir de la copia de seguridad, define un valor del Registro que contiene la ruta de acceso de la copia de seguridad y vuelve a iniciar el servicio de Cluster Server. Durante el arranque, el Servicio de Cluster Server detecta que se ha solicitado una restauración y restaura la base de datos del clúster desde la ruta de copia de seguridad del recurso de quórum.

Conmutación por errores de clúster Conmutación por error del clúster La conmutación por error se puede producir automáticamente debido a un error imprevisto de hardware o software, o la puede iniciar manualmente un administrador. El algoritmo y el comportamiento en ambos casos es prácticamente idéntico. Sin embargo, en una conmutación por error iniciada manualmente, los recursos se cierran de manera ordenada, mientras que en la conmutación por error no planeada los recursos se cierran de forma repentina y traumática (por ejemplo, se apaga el equipo o un componente de hardware crucial deja de funcionar). Cuando se produce un error en un nodo completo del clúster, sus grupos de recursos se transfieren a uno o varios nodos disponibles en el clúster. La conmutación por error automática es similar a la reasignación administrativa planeada de pertenencia de recursos. Sin embargo, es más compleja, porque los pasos ordenados de un cierre planeado se pueden interrumpir o no realizarse en absoluto. Por tanto, se requieren pasos adicionales para evaluar el estado del clúster cuando se produce el error. Cuando la red experimente una conmutación por error automática, es importante determinar los grupos que se estaban ejecutando en el nodo que ha sufrido el error y los nodos que deben tomar posesión de los distintos grupos de recursos. Todos los nodos del clúster son capaces de alojar los grupos de recursos cuya posesión es objeto de negociación. Esta negociación se basa en la capacidad de los nodos, la carga actual, la información suministrada por las aplicaciones, la lista de preferencias de nodos o el uso de la propiedad AntiAffinityClassNames, descrita en Configuraciones específicas del clúster. Una vez realizada la negociación del grupo de recursos, todos los nodos del clúster actualizan sus bases de datos y controlan a qué nodo pertenece el grupo de recursos. En los clústeres con más de dos nodos, la lista de preferencias de nodos de cada grupo de recursos puede especificar un servidor preferente y una o más alternativas ordenadas por prioridad. Esto permite la conmutación por error en cascada, con la que un grupo de

607

recursos puede sobrevivir a varios errores de servidor al cambiar cada vez que se produce un error al siguiente servidor de su lista de preferencias de nodos. Una alternativa a la conmutación por error automática es la llamada conmutación por error N+I. Este método establece las listas de preferencias de nodos de todos los grupos del clúster. La lista de preferencias de nodos identifica los nodos del clúster en espera, a los que se mueven los recursos durante la primera conmutación por error. Los nodos en espera son servidores del clúster que están la mayor parte del tiempo inactivos o que tienen cargas de trabajo que pueden relegarse fácilmente si la carga de trabajo de un servidor que ha producido un error debe moverse al nodo en espera. La conmutación por error en cascada asume que todos los demás servidores del clúster tienen capacidad suficiente y pueden asumir una parte de la carga de trabajo del servidor que ha dejado de funcionar. La conmutación por error N+I asume que los servidores en espera +I son los destinatarios principales del exceso de capacidad.

Conmutación por recuperación del clúster Cuando un nodo vuelve a estar conectado, el Administrador de conmutación por error puede decidir mover uno o varios grupos de recursos al nodo recuperado. Este proceso recibe el nombre de conmutación por recuperación. Las propiedades de un grupo de recursos deben tener definido un propietario preferente para que realicen la conmutación por recuperación a un nodo recuperado o reiniciado. Los grupos de recursos cuyo propietario preferente es el nodo recuperado o reiniciado se mueven del propietario actual a dicho nodo. Las propiedades de conmutación por recuperación de un grupo de recursos pueden incluir las horas del día durante las que se permite la conmutación por recuperación y un límite en el número de intentos de conmutación por recuperación. De esta forma, se permite que el servicio de Cluster Server impida la conmutación por recuperación de grupos de recursos durante horas de procesamiento con mucha actividad o en nodos que no se hayan recuperado o reiniciado correctamente.

Quórum de clúster Cada clúster tiene un recurso especial denominado recurso de quórum. Un recurso de quórum puede ser cualquier recurso que proporcione lo siguiente: •

Un medio de arbitrar las decisiones de pertenencia y de estado del clúster

•

Almacenamiento físico para alojar la información de configuración

Un registro de quórum es una base de datos de configuración de todo el clúster de servidores. Este registro contiene información sobre la configuración del clúster, como los servidores que forman parte del clúster, los recursos instalados en el clúster y el estado de dichos recursos (por ejemplo, sin están o no conectados). El quórum es importante en un clúster por los dos motivos siguientes: •

Coherencia Un clúster se compone de varios servidores físicos que actúan con un único servidor virtual. Es esencial que cada uno de los servidores físicos tenga una

608

imagen coherente de la configuración del clúster. El quórum actúa como repositorio definitivo de toda la información de configuración relativa al clúster. Si el servicio de Cluster Server no es capaz de tener acce acceso so al quórum y leer su información, no se puede iniciar. •

Desempate El quórum se utiliza como mecanismo para resolver empates con el fin de evitar que se produzcan divisiones del clúster. Una división del clúster se produce cuando todos los vínculos de comunicación de la red entre dos o más nodos del clúster dejan de funcionar. Si esto ocurre, el clúster debe dividirse en dos o más particiones que no pueden comunicarse entre sí. El quórum garantiza que los recursos del clúster se conecten en un único nodo. nodo. Para ello, se permite que la partición que posee el quórum siga existiendo, mientras que las demás particiones se desalojan del clúster.

Quórum estándar Como se mencionó anteriormente en esta sección, el quórum es una base de datos de configuración para el Servicio de Cluster Server que se almacena en el archivo de registro de quórum. Un quórum estándar utiliza un archivo de registro de quórum, situado en un disco alojado en la matriz de almacenamiento compartido, al que tienen acceso todos los miembros del clúster. Cada miembro se conecta al almacenamiento compartido mediante SCSI o Fibre Channel. El almacenamiento se compone de discos duros externos (normalmente configurados como discos RAID) o de una SAN cuyos sectores lógicos se presentan como discos físicos. Nota: Es importante que el quórum utilice un recurso de disco físico en lugar de una partición de disco, ya que durante la conmutación por error se mueve todo el recurso de disco físico. Asimismo, se pueden configurar los clústeres de servidores servidor de forma que utilicen el disco duro local de un servidor para almacenar el quórum. Este tipo de implementación, que recibe el nombre de clúster "lone wolf", sólo se admite para fines de comprobación y desarrollo. No se deben utilizar clústeres "lone wolf" wol para organizar por clústeres Exchange 2003 en un entorno de producción ya que, dada su singularidad, no son capaces de proporcionar conmutación por error.

Quórums de conjunto de nodos mayoritario Desde el punto de vista de un clúster de servidores, un quórum quórum de conjunto de nodos mayoritario (MNS) es un único recurso de quórum. Los datos se almacenan de forma predeterminada en el disco local de cada nodo del clúster. El recurso MNS garantiza que los datos de configuración del clúster que tiene almacenados son coherentes entre los distintos discos. La implementación de MNS proporcionada en Windows Server 2003 utiliza un directorio en el disco local de cada nodo para almacenar los datos del quórum. Si la configuración del clúster cambia, ese cambio se reflej refleja a en el disco local de cada nodo. El cambio se considera validado, o permanente, si se realiza en: (número de nodos/2) + 1.

609

El quórum de MNS se asegura de que la mayoría de los nodos tengan una copia actualizada de los datos. El servicio de Cluster Server se inicia y conecta los recursos sólo si una mayoría de los nodos que se han configurado como parte del clúster están activos y en ejecución en el servicio de Cluster Server. Si el quórum de MNS determina que tal mayoría no existe, se considera que el clúster no tiene quórum y el servicio de Cluster Server permanece a la espera en un bucle de reinicio hasta que se incorporan más nodos. Si hay mayoría o quórum de nodos, el servicio de Cluster Server se inicia y conecta los recursos. Dado que la configuración actualizada se almacena en una mayoría de los nodos, independientemente de los errores que se produzcan en los nodos, el clúster siempre está seguro de disponer de la configuración más actual durante el arranque. Si se produce un error en el clúster, o una situación de división de clúster, todas las particiones que no contienen una mayoría de nodos se desconectan. De esta forma se garantiza que si hay una partición en ejecución que contiene una mayoría de los nodos, pueda iniciar cualquier recurso que no se está ejecutando en esa partición, ya que es la única partición de clúster que ejecuta recursos. Debido a las diferencias en el modo de comportamiento de los clústeres de quórum de disco compartido frente al de los clústeres de quórum de MNS, debe analizar detalladamente el modelo que va a utilizar. Por ejemplo, si el clúster sólo contiene dos nodos, no se recomienda usar el modelo MNS. En este escenario, el error de un nodo produciría un error en todo el clúster, ya que no puede haber una mayoría de nodos. Los quórums de conjunto de nodos mayoritario (MNS) están disponibles en los clústeres de Windows Server 2003 Enterprise Edition y Windows Server 2003 Datacenter Edition. La única ventaja que los clústeres MNS proporcionan a los clústeres de Exchange es eliminar la necesidad de tener un disco dedicado en una matriz de almacenamiento compartido en la que almacenar el recurso de quórum.

Recursos de clúster El servicio de Cluster Server administra todos los objetos de recursos mediante monitores de recursos y archivos DLL de recursos. La interfaz del monitor de recursos proporciona una interfaz de comunicación estándar que permite al servicio de Cluster Server iniciar los comandos de administración de recursos y obtener los datos de estado de los recursos. El monitor de recursos obtiene las funciones de comando reales y los datos a través de archivos DLL de recursos. El servicio de Cluster Server utiliza los archivos DLL de recursos para conectar los recursos, administrar su interacción con otros recursos del clúster y supervisar su estado. Para permitir la administración de recursos, los archivos DLL de recursos utilizan algunas interfaces y propiedades de recursos simples. El monitor de recursos carga un archivo DLL de recursos determinado en su espacio de direcciones, como código privilegiado que se ejecuta bajo la cuenta SYSTEM. La cuenta SYSTEM (es decir, LocalSystem) es una cuenta principal de seguridad que representa el sistema operativo. El servicio de Cluster Server, que

610

se ejecuta en un contexto de seguridad de usuario, utiliza la cuenta SYSTEM para realizar funciones de seguridad dentro del sistema operativo. Cuando los recursos dependen de la disponibilidad de otros recursos para que funcionen, estas dependencias se pueden definir mediante el archivo DLL de recursos. Cuando un recurso depende de otros recursos, el servicio de Cluster Server sólo conecta el recurso dependiente después de conectar los recursos de los que depende en el orden correcto. Los recursos se desconectan de la misma forma. El servicio de Cluster Server sólo desconecta los recursos después de desconectar todos los recursos dependientes. De esta forma se evitan las dependencias circulares al cargar los recursos. Cada archivo DLL de recursos puede definir también el tipo de equipo y conexión de dispositivo necesarios para el recurso. Por ejemplo, un recurso de disco podría exigir pertenecer únicamente a un nodo que esté conectado físicamente al dispositivo de disco. También se pueden definir en el archivo DLL de recursos las directivas de reinicio locales y las acciones deseadas durante los sucesos de conmutación por error.

Administración del clúster Los clústeres se administran mediante el Administrador de clústeres. El Administrador de clústeres es una herramienta de administración gráfica que permite a la herramienta de línea de comandos de Cluster.exe realizar tareas de mantenimiento, supervisión y administración de la conmutación por error. Los clústeres de servidores proporcionan también una interfaz de automatización. Esta interfaz sirve para crear herramientas de secuencias de comandos personalizadas para administrar recursos del clúster, nodos y el propio clúster. Las aplicaciones y las herramientas de administración, como el Administrador de clústeres, tienen acceso a esta interfaz mediante llamadas a procedimientos remotos, independientemente de si la herramienta se ejecuta en un nodo del clúster o en un equipo externo.

Formación y operaciones del clúster Cuando el servicio de Cluster Server está instalado y ejecutándose en un servidor, el servidor puede participar en un clúster. Las operaciones de clúster reducen los errores puntuales y otorgan gran disponibilidad a los recursos del clúster. En las siguientes secciones se describe brevemente el comportamiento de los nodos durante la creación y las operaciones del clúster.

Creación de un clúster Los clústeres de servidores incluyen una utilidad de instalación de clústeres que sirve para instalar el software del clúster en un servidor y crear un nuevo clúster. Para crear un nuevo clúster, la utilidad se ejecuta en el equipo seleccionado como primer miembro del clúster. Este primer paso define el nuevo clúster al establecer un nombre de clúster y crear la base de datos y la lista de pertenencia inicial del clúster.

611

El siguiente paso para crear un clúster consiste en agregar los dispositivos de almacenamiento de datos comunes que estarán disponibles a todos los miembros del clúster. Este paso establece el nuevo clúster con un único nodo y sus propios dispositivos de almacenamiento de datos locales y recursos comunes del clúster (normalmente recursos de almacenamiento de datos o disco y medios de conexión). El paso final para crear un clúster consiste en ejecutar la utilidad de instalación en cada equipo adicional que vaya a formar parte del clúster. Conforme se agrega cada nuevo nodo al clúster, éste recibe automáticamente una copia de la base de datos del clúster existente del miembro original del clúster. Cuando se une un nuevo nodo a un clúster o un nodo forma un clúster, el servicio de Cluster Server actualiza la copia privada del nodo de la base de datos de configuración.

Formación de un clúster Un servidor puede formar un clúster si ejecuta el servicio de Cluster Server y no es capaz de encontrar otros nodos del clúster. Para formar el clúster, un nodo debe ser capaz de adquirir la propiedad exclusiva del recurso de quórum. Cuando se forma un clúster, el primer nodo contiene la base de datos de configuración del clúster. Cuando un nodo adicional se une al clúster, éste recibe y conserva su propia copia local de la base de datos de configuración del clúster. El recurso de quórum almacena la versión más reciente de la base de datos de configuración como registros de recuperación. Los registros contienen datos de configuración y estado del clúster independientes de los nodos. Durante las operaciones de clúster, el servicio de Cluster Server utiliza los registros de recuperación de quórum para lo siguiente: •

Garantizar que sólo un conjunto de nodos activos pueda formar un clúster

•

Permitir que un nodo forme un clúster sólo si puede hacerse con el control del recurso de quórum

•

Permitir que un nodo se una a un clúster existente o permanezca en él sólo si puede comunicarse con el nodo que controla el recurso de quórum.

Cuando se forma un clúster, cada nodo del clúster puede tener uno de tres estados distintos. Estos estados los registra el procesador de sucesos (descrito a continuación) y se replican mediante el Administrador de registros de sucesos en los demás nodos del clúster. Los tres estados del servicio de Cluster Server son los siguientes: •

Desconectado El nodo no es un miembro activo del clúster. Puede que el nodo y su servicio de Cluster Server no estén funcionando.

•

Conectado El nodo es un miembro activo del clúster. Participa en las actualizaciones de base de datos del clúster, aporta datos al algoritmo de quórum, mantiene latidos de red y de almacenamiento del clúster y puede poseer y ejecutar grupos de recursos.

•

En pausa El nodo es un miembro activo del clúster. Participa en las actualizaciones de base de datos del clúster, aporta datos al algoritmo de quórum y mantiene latidos de red

612

y de almacenamiento del clúster, pero no puede aceptar grupos de recursos. Sólo admite los grupos de recursos de los que es actualmente propietario. El estado en pausa permite realizar tareas de mantenimiento. La mayoría de los componentes del clúster de servidores consideran equivalentes los estados conectado y en pausa.

Unión a un clúster Para unirse a un clúster existente, un servidor debe ejecutar el servicio de Cluster Server y ser capaz de encontrar otro nodo del clúster. Después de encontrar otro nodo del clúster, debe autenticarse la pertenencia al clúster del servidor que se va a unir y debe recibir una copia replicada de la base de datos de configuración del clúster. El proceso de unión a un clúster existente comienza cuando el Administrador de control de servicios de Windows inicia el servicio de Cluster Server en el nodo. Durante el proceso de arranque, el servicio de Cluster Server configura y monta los dispositivos de datos locales del nodo. No intenta conectar los dispositivos de datos comunes del clúster como nodos, porque puede que el clúster existente los esté utilizando. Para localizar otros nodos, se inicia un proceso de detección. Cuando el nodo detecta algún miembro del clúster, ejecuta una secuencia de autenticación. El primer miembro del clúster autentica el nuevo nodo y devuelve un estado de éxito si el nuevo nodo se autentica correctamente. Si la autenticación no se realiza correctamente, debido por ejemplo a que no se reconoce el nuevo nodo como miembro del clúster o éste tiene una contraseña de cuenta incorrecta, se deniega la solicitud de unión al clúster. Una vez realizada correctamente la autenticación, el primer nodo en línea del clúster comprueba la copia de la base de datos de configuración del nuevo nodo. Si está anticuada, el nodo del clúster envía al nuevo nodo una copia actualizada de la base de datos. Después de recibir la base de datos replicada, el nodo que se va a unir al clúster puede utilizarla para encontrar los recursos compartidos y conectarlos a medida que los necesite.

Abandono de un clúster Un nodo puede abandonar un clúster cuando se apaga o cuando se detiene el servicio de Cluster Server. Sin embargo, también puede ser expulsado de un clúster cuando no puede realizar las operaciones del clúster (por ejemplo, cuando no puede validar una actualización de la base de datos de configuración del clúster). Cuando un nodo abandona un clúster, como en un cierre planeado, envía un mensaje ClusterExit a todos los demás miembros del clúster para notificarles que va a abandonar el clúster. El nodo no espera a recibir ninguna respuesta y procede inmediatamente a apagar los recursos y a cerrar todas las conexiones del clúster. Como los demás nodos reciben este mensaje de salida, no realizan el proceso de reagrupación para restablecer la pertenencia al clúster que tiene lugar cuando se produce un error inesperado de un nodo o se detiene la comunicación de red.

613

Detección de errores La detección y prevención de errores son importantes ventajas que proporcionan los clústeres de servidores. Cuando se produce algún error en un nodo o aplicación de un clúster, los clústeres de servidores responden reiniciando la aplicación que ha producido un error o distribuyendo el trabajo del sistema que ha dejado de funcionar a los demás nodos del clúster. Las funciones de detección y prevención de errores del clúster de servidores incluyen la conmutación por error bidireccional, la conmutación por error de aplicaciones, la recuperación en paralelo y la conmutación por recuperación automática. Cuando el servicio de Cluster Server detecta errores en alguno de los recursos o en todo un nodo, mueve y reinicia dinámicamente los recursos de aplicaciones, datos y archivos en un servidor disponible y en buen estado del clúster. Esto permite que recursos tales como las bases de datos, los recursos compartidos de archivos y las aplicaciones permanezcan totalmente disponibles a los usuarios y a las aplicaciones cliente. Los clústeres de servidores están diseñados con dos mecanismos diferentes de detección de errores: •

Latidos para detectar errores en los nodos De forma periódica, cada nodo intercambia mensajes basados en el protocolo de datagramas de usuario con otros nodos del clúster a través de la red privada del clúster. Estos mensajes se denominan latidos. El intercambio de latidos permite a cada nodo comprobar la disponibilidad de los demás nodos y sus recursos. Si un servidor no responde a un intercambio de latidos, los servidores que permanecen activos inician procesos de conmutación por error, incluido el arbitraje de la pertenencia de los recursos y aplicaciones propiedad del servidor que ha dejado de funcionar. El arbitraje se realiza mediante un protocolo de desafío y defensa. Al nodo que parece que ha dejado de funcionar se le otorga un límite de tiempo para que demuestre, de alguna forma, que sigue ejecutándose correctamente y que puede comunicarse con los demás nodos. Si no puede responder, se retira del clúster. El hecho de no poder responder a un mensaje de latidos puede deberse a varios motivos, como un error del equipo, un error de la interfaz de red, un error de la red o incluso períodos inusuales de gran actividad. Normalmente, cuando todos los nodos se comunican, el Administrador de la base de datos de configuración envía actualizaciones de la base de datos de configuración global a cada nodo. Cuando se produce un error en el intercambio de latidos, el Administrador de registros guarda los cambios de la base de datos de configuración en el recurso de quórum. Con esto se asegura de que los demás nodos tengan acceso a la configuración y a los datos del registro de nodos locales más reciente durante los procesos de recuperación. El algoritmo de detección de errores es muy conservador. Si la causa de no poder responder a los latidos es temporal, lo mejor es evitar las posibles molestias que podría causar una conmutación por error. Sin embargo, no hay forma de saber si el nodo responderá al milisegundo siguiente o si sufrirá un error catastrófico. Por tanto, transcurrido el período de tiempo de espera se inicia la conmutación por error.

614

•

Monitor de recursos y archivos DLL de recursos para detectar errores de recursos El Administrador de conmutación por error y el monitor de recursos funcionan conjuntamente para detectar errores en los recursos y permitir la recuperación. Los monitores de recursos realizan un seguimiento del estado de los recursos mediante archivos DLL de recursos que sondean periódicamente los recursos. El sondeo consta de dos pasos: una consulta LooksAlive rápida y una consulta IsAlive más larga y definitiva. Cuando el monitor de recursos detecta un error en un recurso, se lo notifica al Administrador de conmutación por error y continúa supervisando el recurso. El Administrador de conmutación por error conserva el estado de los recursos y del grupo de recursos. Realiza también una recuperación cuando un recurso produce un error y llama a los monitores de recursos en respuesta a las acciones del usuario o a los errores. Después de detectar que se ha producido un error en un recurso, el Administrador de conmutación por error realiza acciones de recuperación, como reiniciar un recurso y sus recursos dependientes o mover todo el grupo de recursos a otro nodo. La acción de recuperación que se realiza viene determinada por las propiedades del recurso y del grupo de recursos, además de por la disponibilidad de los nodos. Durante la conmutación por error, el grupo de recursos se trata como la unidad de conmutación por error. Esto sirve para garantizar que las dependencias de los recursos se recuperan correctamente. Cuando un recurso se recupera de un error, el monitor de recursos lo notifica al Administrador de conmutación por error. A continuación, este administrador realiza una conmutación por recuperación automática del grupo de recursos, en función de la configuración de las propiedades de conmutación por recuperación del grupo de recursos.

Servidores virtuales de Exchange Un servidor virtual de Exchange es una instalación de Exchange organizada por clústeres. Cuando se instala Exchange en un clúster de Windows Server 2003, se configura como un servidor virtual de Exchange capaz de atravesar los nodos del clúster sin que lo perciban los clientes de Exchange. Cuando instale Exchange en un nodo del clúster, el programa de instalación de Exchange copiará los archivos de programa al disco local de dicho nodo. En un clúster con dos nodos, como Nodo A y Nodo B, el programa de instalación copia los archivos de programa de Exchange en el disco duro del Nodo A. A continuación, se ejecuta el programa de instalación por segunda vez para instalar los archivos de programa de Exchange en el disco duro local del segundo nodo. Después de copiar los archivos de programa de Exchange en los discos duros de cada nodo, se configura un grupo de recursos para los recursos de Exchange. Como se mencionó anteriormente, un grupo de recursos se define como un contenedor lógico que incluye los recursos de una instancia del servidor virtual de Exchange. Muchos de los recursos de esta

615

instancia del servidor virtual de Exchange son los mismos que los de los servidores de Exchange físicos, como: omo: •

Un nombre de red

•

Una dirección IP

•

Almacenamiento (SCSI o Fibre Channel)

Una vez creado un mínimo de los recursos del servidor virtual de Exchange anteriores, debe crear un recurso Operador de sistema. El recurso Operador de sistema crea los demás recursos que componen un servidor virtual de Exchange. Estos recursos se puede desconectar, imitando así la detección del servicio, o conectar, imitando el inicio del servicio. También puede cambiar el propietario del recurso actual (el nodo del clúster). clús Por ejemplo, puede configurar el Nodo B para que posea y ejecute este recurso en lugar del Nodo A. El recurso Operador de sistema siempre se crea manualmente. Otros recursos de Exchange relacionados con servicios se crean automáticamente después de crear crear el recurso Operador de sistema. Por último, estos cambios se escriben en el servicio de directorio de Microsoft Active Directory® y se incluye un objeto para este servidor basado en Exchange en el contenedor Servidores del grupo administrativo. Nota: Exchange Server 2003 presenta varios cambios relativos a la seguridad que afianzan el modelo de seguridad con respecto al de Exchange 2000 Server. Por ejemplo, cuando se crea un servidor virtual Exchange Server 2003 en un entorno de clúster, los recursos del clúster IMAP4 y POP3 no se crean de forma predeterminada. Si desea utilizar estos servicios en un clúster, debe iniciar el servicio correspondiente en el nodo del clúster y crear después manualmente el recurso. Para obtener más información, consulte e ell artículo 824127 de Microsoft Knowledge Base, "HOW HOW TO: Create an IMAP4 or a POP3 Cluster Resource on an Exchange Server 2003 Virtual Server". Server Un servidor virtual de Exchange es un conj conjunto unto de recursos de Exchange. Cada recurso tiene propiedades, como dependencias de recursos, posibles propietarios y valores de reintento. Cada recurso de un servidor virtual de Exchange representa un componente que no es de Exchange.

Componentes de Exchange Exchange en un clúster Los componentes y servidores virtuales que se ejecutan dentro de un clúster Windows Server 2003 admiten la funcionalidad activo/activo, activo/pasivo o ambas. En la tabla siguiente se incluyen los recursos específicos de Exchange disponibles disponibles para clústeres de Windows Server 2003.

616

Componentes de Exchange Server 2003 en un clúster de servidores Componente

Funcionalidad

Notas

Servicio Operador de sistema Activo/activo de Microsoft Exchange

Varios servidores virtuales por nodo en clústeres de dos o menos nodos. Los clústeres con más de dos nodos sólo admiten recursos de Operador de sistema activo/pasivo.

Servicio Almacén de información de Microsoft Exchange

Activo/activo

Máximo de cuatro grupos de almacenamiento por nodo.

Agente de transferencia de mensajes

Activo/pasivo

Una instancia por clúster; siempre es propiedad del primer servidor virtual de Exchange creado en un clúster.

Motor de enrutamiento

Activo/activo

POP3

Activo/activo

Varios servidores virtuales por nodo. Debe crearlo manualmente el administrador.

IMAP4

Activo/activo

Varios servidores virtuales por nodo. Debe crearlo manualmente el administrador.

SMTP

Activo/activo

Varios servidores virtuales por nodo.

HTTP

Activo/activo

Varios servidores virtuales por nodo.

Microsoft Search

Activo/activo

NNTP

No compatible

Sigue siendo necesario el componente de Protocolo de transferencia de noticias a través de la red (NNTP) de Servicios de Internet Information Server (IIS) para la instalación de Exchange.

617

Componente

Funcionalidad

Conector de Exchange para Novell GroupWise

No compatible

Conector de Exchange para Lotus Notes

No compatible

Sucesos de Microsoft Exchange

No compatible

Notas

Clústeres activo/activo Exchange 2003 admite configuraciones de clústeres activo/activo en clústeres de dos nodos. Los clústeres con más de dos nodos deben utilizar la organización por clústeres activo/pasivo. En un clúster de Exchange activo/activo, son varios los servidores virtuales de Exchange que se pueden mover, con algunas restricciones, entre los distintos nodos que pertenecen al clúster y que pueden ejecutarse simultáneamente en un solo nodo. En los clústeres activo/activo, puede haber varias instancias de aplicaciones y recursos en un clúster. Por tanto, ambos nodos puede dar servicio de forma activa a los clientes. En los clústeres activo/activo de Exchange 2003, el número de servidores virtuales de Exchange de un clúster es igual o mayor que el número de nodos físicos del clúster. Los clústeres de Exchange activo/activo sólo se pueden crean en clústeres formados por dos o menos nodos. Si hay más de dos nodos en un clúster, debe utilizar el modelo de clúster activo/pasivo. En la mayoría de los casos, cada servidor virtual de Exchange del clúster se ejecuta en un nodo distinto. Si el hardware deja de funcionar o se desconecta un nodo, el otro nodo detecta el cambio y realiza las acciones correspondientes de acuerdo con las directivas configuradas de conmutación por error. Normalmente, esto significa que el nodo restante asume los recursos propiedad del servidor virtual de Exchange que se estaba ejecutando en el primer nodo. En un clúster de dos nodos (por ejemplo, Nodo A y Nodo B), cuando el Nodo A está desconectado, el Nodo B asume la posesión del servidor virtual de Exchange. El Nodo B posee entonces los dos sistemas de discos compartidos, las dos direcciones IP, los dos nombres de red y todos los demás recursos de Exchange del clúster. Cuando el Nodo A vuelve a conectarse, se puede realizar o no la acción de conmutación por recuperación, según las directivas de conmutación por recuperación configuradas. Aunque se ofrece compatibilidad con los clústeres activo/activo, debe utilizar clústeres de Exchange activo/pasivo por los siguientes motivos: •

Escalabilidad En un clúster de Exchange activo/activo, cada nodo físico no puede tener más de 1.900 conexiones MAPI simultáneas ni usar de un modo coherente más del 40 por ciento del tiempo total de CPU disponible.

•

Fragmentación de la memoria virtual Los clústeres activo/activo son más proclives a la fragmentación de memoria que los clústeres activo/pasivo o los servidores de

618

Exchange no organizados por clústeres. Esto es debido a que en el modelo de clúster activo/activo se ejecutan varias instancias del Motor de almacenamiento extensible (ESE) en el mismo proceso STORE.EXE. •

Rendimiento Cuando se produce una conmutación por error en un clúster de Exchange activo/activo, el nodo restante posee más de un servidor virtual de Exchange. Esto produce una merma del rendimiento para los usuarios de ambos servidores virtuales de Exchange hasta que el nodo desconectado reanuda su carga de trabajo.

Para obtener más información acerca de cómo crear clústeres con Windows Server 2003 y Exchange 2003, consulte Using Clustering with Exchange 2003: An Example.

Clústeres activo/pasivo En un clúster activo/pasivo, los clientes se conectan a un servidor virtual de Exchange que pertenece actualmente a un nodo del clúster (por ejemplo, el Nodo A). El nodo controla el sistema de discos compartidos que contiene las bases de datos de Exchange. Si el Nodo A sufre un error de hardware o se desconecta por algún otro motivo, el Nodo B detecta este error y asume la posesión del servidor virtual de Exchange y de todos sus recursos asociados. En el modelo de clúster activo/pasivo, las aplicaciones se ejecutan como una sola instancia en un clúster. Esto significa que normalmente un nodo sigue inactivo (pasivo) hasta que se produce la conmutación por error. En el contexto de los clústeres de Exchange 2003, la agrupación por clústeres activo/pasivo indica que el número de servidores virtuales de Exchange en el clúster es menor que el número de nodos físicos del clúster. En la figura siguiente se muestra un ejemplo del modelo de clúster activo/pasivo. Configuración de clústeres de servidores Exchange 2003 activo/pasivo de cuatro nodos

619

Activo/pasivo es, sin lugar a dudas, el modelo de agrupación por clústeres recomendado para Exchange 2003. Las configuraciones de clústeres activo/pasivo son muy escalables y requieren menos trabajo administrativo que los clústeres activo/activo por varios motivos: •

Los clústeres activo/activo están limitados a 1.900 conexiones simultáneas con clientes MAPI por nodo.

•

Los clústeres activo/activo deben supervisarse continuamente para garantizar que el proceso STORE.EXE no supera el 40 por ciento del tiempo total de CPU disponible en cada nodo.

•

Los clústeres activo/activo son más proclives a la fragmentación de memoria virtual porque varias instancias de ESE se ejecutan en el mismo proceso STORE.EXE.

Los clústeres de Exchange activo/pasivo, sea cual sea su tamaño, deben incluir al menos un nodo pasivo. Asimismo, en un momento dado, cada nodo sólo debe ejecutar un servidor virtual de Exchange.

Dependencias de recursos Como se muestra en la figura siguiente, los recursos relacionados con Exchange dependen directamente del recurso Operador de sistema. Este recurso, a su vez, depende de los recursos Disco Físico y Nombre de red, y el recurso Nombre de red depende del recurso Dirección IP. Cuando un servidor virtual de Exchange incluye varios recursos Disco físico, todos ellos deben depender del recurso Operador de sistema.

Servicio Operador de sistema de Microsoft Exchange Las dependencias predeterminadas mostradas en la figura siguiente se crean cuando se genera el servicio Operador de sistema de Microsoft Exchange. Operador de sistema es el recurso principal que controla la creación y la eliminación de todos los recursos del servidor virtual de Exchange.

620

Dependencias de recursos de Exchange en el servidor virtual de Exchange

Estos recursos se crean cuando se genera el recurso Operador de sistema. Para eliminar el servidor y sus objetos de Active Directory, debe quitar el servidor virtual de Exchange mediante el Administrador de clústeres. La llamada IsAlive al servicio Operador de sistema realiza una consulta al Administrador de control de servicios para obtener el estado inmediato del servicio Operador de sistema.

Servicio Almacén de información de Microsoft Exchange Cuando el servicio Almacén de información de Microsoft Exchange está conectado, se inicia el servicio (STORE.exe) y comienza a montar los grupos de almacenamiento. Cuando todos los grupos de almacenamiento están montados, y el almacén ha procesado los registros de transacciones existentes, se considera que el recurso está conectado. La llamada IsAlive al servicio Almacén de información de Microsoft Exchange envía una llamada RPC al proceso STORE.exe. En lo que respecta al proceso del almacén, la comprobación sólo confirma que el nombre del servidor virtual está incluido en la lista de servidores virtuales activos.

Agente de transferencia de mensajes El recurso Agente de transferencia de mensajes (MTA) es un recurso activo/pasivo. Solamente puede haber un MTA por clúster. El MTA se crea en el primer servidor virtual de Exchange de un clúster y no se puede mover a otro servidor virtual de Exchange. Por este motivo, el primer servidor virtual de Exchange que se crea en un clúster es además el último servidor virtual de Exchange que se puede quitar del clúster. Aunque el MTA es un recurso activo/pasivo, hace las funciones de todos los servidores virtuales del clúster mientras está conectado. La llamada IsAlive al Agente de transferencia de mensajes realiza una consulta al Administrador de control de servicios para obtener el estado inmediato del MTA.

621

Protocolos La llamada IsAlive funciona de igual forma para todos los protocolos. EXRES.DLL abre un puerto TCP para el protocolo mediante los enlaces proporcionados por la metabase de Servicios de Internet Information Server (IIS). Espera una respuesta en forma de encabezado. Si el principio del encabezado coincide con el valor previsto, se considera que el recurso está conectado. Si no se devuelve el encabezado antes de agotarse el tiempo de espera, el servicio Cluster Server determina que el servidor virtual del protocolo no está disponible y la llamada IsAlive no produce ningún resultado. Ninguno de los protocolos se puede definir para que rechace todas las conexiones de todos los servidores, ya que en ese caso el servidor virtual del protocolo rechazaría las llamadas IsAlive que él mismo origina. Por este motivo, cada servidor virtual de protocolo debe aceptar las conexiones de su propia dirección IP. En el caso del protocolo HTTP, EXRES.DLL envía un comando WebDAV Track para obtener una respuesta. Cuando un servidor virtual de Exchange está desconectado, todas las instancias del servidor virtual del protocolo SMTP del nodo se detienen unos instantes y se reinician para asegurarse de que el controlador del almacén se registra correctamente. Esto significa que los recursos SMTP de todos los servidores virtuales de Exchange del nodo se desconectan y reinician rápidamente. Los recursos SMTP no se reinician automáticamente si la opción No reiniciar está seleccionada en sus propiedades.

Microsoft Search El recurso MSSearch proporciona índices de contenido para el servidor virtual de Exchange. La llamada IsAlive al proceso MSSearch devuelve un puntero a la estructura de datos de la base de datos que se va a indizar. Si el puntero es válido, se determina que el recurso funciona correctamente. Para volver a crear el recurso MSSearch después de eliminarlo, debe eliminar y volver a crear después el recurso del servicio Almacén de información de Microsoft Exchange para el servidor virtual de Exchange en cuestión. Para obtener más información, consulte el artículo 830189 de Microsoft Knowledge Base, "Exchange Server 2003 computer cannot bring the Microsoft Search resource online".

Interacción de clústeres de Exchange Exchange 2003 es compatible con la organización por clústeres y proporciona su propio archivo DLL de recursos de clúster, llamado EXRES.DLL, para la comunicación e interacción con el servicio Cluster Server de Windows. Este servicio se comunica a través del monitor de recursos con EXRES.DLL, y EXRES.DLL se comunica a su vez con los componentes de Exchange. EXRES.DLL convierte las acciones del clúster en acciones de servicios relacionados con Exchange. EXRES.DLL supervisa también la detención de estos recursos y

622

envía una notificación al servicio Cluster Server si la operación no se realiza con éxito. En la figura siguiente, se ilustra la relación entre EXRES.DLL y el servicio Cluster Server. Interacción de ExRes.dll con el servicio Cluster Server de Windows

En un clúster, el servicio Cluster Server es responsable de iniciar y detener los servicios de Exchange a través de EXRES.DLL. Por esta razón, el administrador no debe detener un servicio desde la línea de comandos, desde el complemento Servicios de Windows, con una herramienta del Kit de recursos ni con una aplicación de otro fabricante. Cuando se detiene un servicio desde fuera del servicio Cluster Server, la llamada IsAlive a dicho servicio produce un error, que da lugar a que el servicio Cluster Server intente reiniciar el servicio detenido. La función IsAlive devuelve el último valor obtenido del subproceso de supervisión del estado de los recursos. La función LooksAlive tiene la misma implementación que IsAlive. No se llama a la función LooksAlive, porque EXRES.DLL proporciona identificadores de sucesos de error de recursos al monitor de recursos del clúster, que indica cuándo un recurso produce un error. El subproceso de supervisión del estado comprueba los recursos cada diez segundos. Esta comprobación de recursos no se puede configurar. EXCLUADM.DLL proporciona la interfaz asociada a Exchange y a los asistentes específicos del clúster.

Funciones ExchangeOpen/ExchangeClose Siempre que los recursos de Exchange se mueven al nodo actual, se llama a las funciones ExchangeOpen y ExchangeClose. Dentro de las funciones ExchangeOpen, la memoria se inicializa o se asigna para la información básica del recurso. Estas funciones controlan también la carga y descarga de archivos DLL utilizados por el archivo DLL de recursos. Este proceso se controla mediante contadores de referencias.

623

Funciones ExchangeOnline y ExchangeOffline Las funciones ExchangeOnline y ExchangeOffline crean nuevos subprocesos de trabajo OnlineWrapperThread y OfflineWrapperThread y devuelven inmediatamente un ERROR_IO_PENDING al monitor de recursos del clúster. Cuando el subproceso contenedor devuelve un error al monitor de recursos, éste intenta reiniciar el recursos dos veces más. Durante estos intentos de reinicio, la función ExchangeOnline determina si el subproceso de conexión/desconexión ha terminado de ejecutarse. Si no ha terminado de ejecutarse, se reinicia la función ExchangeOnline. Para OfflineWrapperThread, si el subproceso ExchangeOffline no termina de ejecutarse en el límite PendingTimeOut establecido para los recursos Almacén, Operador de sistema y MTA, el monitor de recursos termina el proceso correspondiente. Para evitar situaciones que originen un bloqueo de las llamadas a procedimientos remotos, estos dos subprocesos de trabajo crean el subproceso real de conexión/desconexión. Los subprocesos contenedores actúan como monitores del subproceso de conexión/desconexión y utilizan temporizadores para supervisar el funcionamiento de este subproceso. Si el subproceso de conexión/desconexión no termina de ejecutarse en el tiempo definido por el valor de PendingTimeOut establecido en el Administrador de clústeres, el subproceso contenedor determina que la operación no tuvo éxito y establece el estado del recurso en error. A continuación, devuelve un error. Las únicas excepciones a este comportamiento se producen en las operaciones de actualización o en las operaciones de conexión de recursos del almacén. En ambos casos, el subproceso contenedor espera a que finalice la actualización o a que se conecte el recurso del almacén sin tiempos de espera. Las funciones ExchangeOnlineThread y ExchangeOfflineThread dan servicio a los siguientes recursos de Exchange: •

Servicio Operador de sistema de Microsoft Exchange, servicio Almacén de información de Microsoft Exchange y Enrutamiento Cada uno de estos recursos inicia el servicio (si aún no se ha iniciado) y, a continuación, realiza llamadas RPC a cada uno de estos servicios para indicarles que inicien o detengan el servidor virtual de Exchange correspondiente.

•

Recursos de protocolo Los recursos de protocolo establecen el bit de comando en la metabase de IIS y, a continuación, inician el servicio, si aún no se ha iniciado. El servicio correspondiente recupera el comando e inicia o detiene el servidor virtual. La única excepción a este comportamiento se produce en el servidor virtual SMTP. En este caso, cuando una instancia del servidor virtual se desconecta debe detenerse todo el servicio SMTP. La función IsAlive comprueba los demás servidores virtuales que se ejecutan en el mismo equipo físico, detecta que el servicio SMTP subyacente se ha detenido y, a continuación, reinicia el servidor virtual.

624

ExchangeIsAlive y ExchangeLooksAlive La función ExchangeOnline devuelve un identificador de sucesos al monitor de recursos y éste se detiene con una llamada a la función ExchangeLooksAlive. Por el contrario, el monitor de recursos llama a la función ExchangeIsAlive a intervalos definidos en el intervalo de encuesta Looks Alive del Administrador de clústeres. Siempre que se conecta un recurso, EXRES.DLL crea dos subprocesos para supervisar el estado de dicho recurso. El primer subproceso, llamado ExchangeIsAliveMonitor, comprueba el estado del recurso cada diez segundos activando el segundo subproceso, llamado ExchangeCheckIsAliveWrapper. ExchangeCheckIsAliveWrapper es el que realmente realiza la comprobación IsAlive. Si el subproceso ExchangeCheckIsAliveWrapper no termina de ejecutarse en el límite de tiempo definido por PendingTimeOut, o si la comprobación IsAlive es infructuosa, el subproceso ExchangeIsAliveMonitor notifica un suceso de error del recurso en cuestión al monitor de recursos. La función ExchangeIsAlive devuelve el estado de la última comprobación IsAlive.

ExchangeTerminate Esta función termina el subproceso ExchangeIsAliveMonitor existente. Para los recursos Almacén, Operador de sistema y MTA de Exchange, realiza también el procedimiento de desconexión correspondiente para asegurarse de que la base de datos está desmontada. Si el procedimiento de desconexión no se realiza correctamente en el límite de tiempo PendingTimeOut, EXRES.DLL termina también el proceso correspondiente.

Creación de recursos El usuario primero crea un recurso y después crea una llamada a EXCLUADM.DLL, solicitando información. EXCLUADM.DLL obtiene la información necesaria para el recurso y la transfiere al servicio Cluster Server. El monitor de recursos crea una llamada a la función ExchangeResourceControl en EXRES.DLL. Esta llamada contiene la información que se ha transferido desde EXCLUADM.DLL y Clusctl_Resource_Set_Private_Properties como código de control. ExchangeSetPrivateResProperties se utiliza para manejar este código de control. En primer lugar, guarda la información en la base de datos del clúster bajo la clave del Registro Parameters de ese recurso y, después, realiza una llamada a EXSETDATA.DLL para que cree objetos en Active Directory. En algunos casos, puede surgir algún problema y parte de la información de configuración puede modificarse en el Administrador del sistema de Exchange, sin sincronizar los cambios con la base de datos del clúster.

Configuraciones específicas del clúster En las siguientes secciones se describen los cambios que deben realizarse en la configuración para admitir operaciones de algunos componentes cuando se ejecutan en un clúster de Exchange. Cuando se instala Exchange en un entorno de clúster, debe realizar

625

algunas tareas de Exchange de forma diferente a como las realizaría para un servidor Exchange instalado en un entorno no organizado por clústeres.

MTA de Exchange De forma predeterminada, un servidor de Exchange 2003 supervisa el servicio MTA. En las configuraciones con clúster, MTA sólo se ejecuta en uno de los nodos físicos (equipos). Como resultado, el proceso de supervisión informará de que los nodos que no ejecuten el servicio MTA tienen un estado de error, lo que, a su vez, puede provocar problemas problem si Exchange 2003 se instala en un clúster con dos o más servidores virtuales de Exchange. Para evitar que el proceso de supervisión informe de forma equivocada de que los servidores virtuales de Exchange que no ejecutan el servicio MTA tienen un estado de error es aconsejable deshabilitar la supervisión de MTA en el segundo servidor virtual de Exchange (y, si conviene, en cualquier otro servidor virtual de Exchange) de un clúster. Para ver pasos detallados, consulte How to Disable MTA Monitoring on an Exchange Virtual Server. Nota: No es necesario que deshabilite la supervisión de MTA en el primer servidor virtual de Exchange de un clúster.

Registro SMTP de IIS Los servidores virtuales del protocolo SMTP de IIS crean y rellenan archivos de registro que se utilizan para recopilar información estadística sobre el uso de los servidores. El registro SMTP no está habilitado de forma prede predeterminada terminada porque reduce el rendimiento de Exchange. Cuando se habilita, IIS crea archivos de registro en la unidad de sistema del equipo local (como C:\Windows Windows\System32\Logfiles, Logfiles, donde C es la letra de la unidad del sistema). Para configurar de manera segu segura ra el registro SMTP de IIS, debe especificar una carpeta en un disco compartido. Para obtener instrucciones detalladas, consulte How w to Enable SMTP Logging and Log the Files to a Shared Disk Disk.

AntiAffinityClassNames Una de las limitaciones de los clústeres de servidores basados en Windows 2000 es que no disponen de un mecanismo para una conmutación por error condicional. Por ejemplo, no se puede configurar un servidor virtual de Exchange para que se mueva a un nodo cuando se produzca un error y a otro nodo cuando se produzca un error diferente. Tampoco se puede configurar un servidor virtual de Exchange para que realice la conmutación por error a un segundo nodo en caso de que el primero esté demasiado ocupado. En los clústeres de Windows Server 2003, esta limitación se resuelve con una nueva propiedad de grupo de clústeres llamada AntiAffinityClassNames. El valor de esta propiedad es una cadena

626

arbitraria. Sin embargo, esta cadena suele ser específica del programa. Por ejemplo, Exchange 2003 establece este valor en Servidor virtual de Microsoft Exchange. La propiedad AntiAffinityClassNames se utiliza para designar un nodo como posible propietario de un grupo de recursos determinado en un clúster que contiene tres o más nodos. En un clúster Windows Server 2003, si se produce un error de un recurso que afecta al grupo de recursos, el Administrador de conmutación por error comprueba el valor de AntiAffinityClassNames. Por ejemplo, cuando un recurso del servidor virtual de Exchange produce un error, el Administrador de conmutación por error del clúster determina si los grupos de recursos de alguno de los otros nodos, designados como posibles propietarios del servidor virtual de Exchange, tienen Servidor virtual de Microsoft Exchange definido como el valor de la propiedad AntiAffinityClassNames. Sólo los nodos que contienen actualmente un servidor virtual de Exchange tienen definido este valor. Por tanto, un nodo sin este valor es el mejor destino posible para el grupo con el recurso que ha producido el error. En los siguientes escenarios se muestra cómo se puede utilizar la propiedad AntiAffinityClassNames: •

La propiedad se puede utilizar en un clúster de servidores de Exchange N+1. En este caso, Exchange debería configurar cada grupo que admita una partición con la propiedad AntiAffinityClassNames establecida en un valor específico de Exchange (el mismo valor para cada grupo). Si se produce un error, el Administrador de conmutación por error puede intentar separar las particiones seleccionando nodos que no contengan grupos con el mismo valor de servidor virtual de Exchange de AntiAffinityClassNames.

•

La propiedad se puede utilizar en una consolidación de servidores en la que deban mantenerse apartados varios programas. En estos casos, los grupos que representan los distintos programas deben modificarse manualmente con el mismo valor de la propiedad AntiAffinityClassNames.

Esta propiedad sólo se puede configurar mediante la herramienta de línea de comandos de CLUSTER.EXE. Un ejemplo de sintaxis correcta para el primer escenario anteriormente descrito es: cluster group "Name of Group" /prop AntiAffinityClassNames="Microsoft Exchange Virtual Server"

Este comando crea la siguiente clave de Registro: Ubicación

HKLM\Cluster\Groups\\

Valor

AntiAffinityClassNames

Tipo

REG_MULTI_SZ

Información del valor

Microsoft Exchange Virtual Server

Una vez definida esta propiedad, se configuran las directivas de conmutación por error y conmutación por recuperación mediante la opción Óptimo del Administrador de clústeres, en lugar de definir nodos específicos para una directiva. Para obtener más información, consulte

627

el artículo 299631 de Microsoft Knowledge Base, "Comportamiento de conmutación por error en clúster de tres o más nodos".

Almacenes públicos MAPI En versiones anteriores al Service Pack 1, los clústeres de Exchange 2003 sólo podían alojar un almacén de información MAPI público, denominado también base de datos de carpetas públicas, por clúster. Este diseño evita que se produzcan problemas si el clúster realiza la conmutación por recuperación en otro servidor de un clúster activo/activo. Como Exchange 2003 debe ejecutarse en una configuración activo/pasivo siempre que haya más de dos nodos en el clúster, no es posible encontrar una situación en la que un único proceso Store.exe se encargue de varios almacenes de información MAPI públicos del mismo TLH. Por tanto, en Exchange 2003 Service Pack 1, se ha eliminado la limitación de almacenes de información MAPI públicos existentes en el clúster. Las instalaciones que ejecutan SP1 o una versión posterior están limitadas a un almacén de información MAPI público para cada servidor virtual de Exchange (la misma restricción que se aplica a los servidores Exchange 2003 independientes).

Eseutil Hay algunas consideraciones especiales que debe tener en cuenta cuando ejecute la utilidad de integridad de base de datos Eseutil con el modificador /CC. Este modificador se utiliza para realizar una recuperación de hardware de un almacén de información de Exchange. La recuperación de hardware es el proceso mediante el cual se aplican registros de transacciones y archivos de revisión de base de datos a una base de datos que se ha restaurado a partir de una copia de seguridad en línea. Para obtener más información, consulte el artículo 266689 de Microsoft Knowledge Base, "XADM: El comando "/CC ESEUTIL" no funciona en Cluster Server".

Instalación de actualizaciones Antes de instalar alguna actualización en los nodos del clúster de Exchange, consulte el archivo LÉAME que se incluye con el Service Pack, la corrección o la actualización. En la mayoría de los casos, primero se actualiza el nodo pasivo del clúster. A continuación, se mueven los servidores virtuales de Exchange al nodo pasivo y se actualizan los demás nodos. No debe instalar nunca ninguna actualización en más de un nodo al mismo tiempo.

628

How to Disable MTA Monitoring on an Exchange Virtual Server De forma predeterminada, un servidor de Exchange 2003 supervisa el servicio MTA. En las configuraciones con clúster, MTA sólo se ejecuta en uno de los nodos físicos (equipos). Para impedir que el proceso de supervisión informe incorrectamente que los servidores virtuales de Exchange que no ejecutan el servicio MTA tienen un estado de error, deshabilite la supervisión del MTA en el segundo servidor virtual de Exchange (y, si es aplicable, en cualquier otro servidor virtual de Exchange adicional) de un clúster. No tiene que deshabilitar la supervisión del MTA en el primer servidor virtual virtual de Exchange de un clúster. Este procedimiento describe cómo deshabilitar la supervisión de MTA en un servidor virtual de Exchange.

Antes de empezar Antes de comenzar la administración del clúster de Exchange quizás desee revisar los elementos que componen ponen un servidor virtual de Exchange y sus recursos asociados en Exchange. También le interesará familiarizarse más con el Administrador de clústeres, la herramienta principal utilizada para configurar y administrar clústeres. Nota: Antes de realizar lass tareas de administración de clústeres que se explican en este capítulo, debe estar familiarizado con los conceptos sobre clústeres que se describen en "Checklist: Checklist: Preparation for installing a clu cluster"" de la Ayuda en pantalla de Microsoft Windows Server™ 2003, Enterprise Edition, y en Windows Server 2003 Technical Reference. Reference Además, asegúrese de leer "Using Server Clustering" en Planning an Exchange Server 2003 Messaging System y "Deploying Exchange 2003 in a Cluster" en Exchange Server 2003 Deployment Guide.

Procedimiento Para deshabilitar la supervisión de MTA en un servidor virtual de Exchange 1. En el Administrador del sistema de Exchange, en el árbol de consola, expanda Servidores,, haga clic con el botón secundario del mouse en el servidor virtual de Exchange apropiado y, después, haga clic en Propiedades. 2. En el cuadro de diálogo Propiedades del >Nombre de servidor<,, haga clic en la ficha Supervisión. Supervisión 3. En la ficha Supervisión, Supervisión seleccione Servicios predeterminados de Microsoft Exchange de la lista de servicios y haga clic en Detalles. 4. En el cuadro de diálogo Servicios predeterminados de Microsoft Exchange, Exchange

629

seleccione Pila MTA de Microsoft Exchange y, a continuación, haga clic en Quitar. 5. Haga clic dos veces en Aceptar.

How to Enable SMTP Logging and Log the Files to a Shared Disk Si desea recopilar información estadística sobre el uso del servidor, habilite el registro del recurso SMTP. Sin embargo, tenga en cuenta que al habilitar el registro SMTP disminuye el rendimiento de Exchange. A menos que esté solucionando problemas o necesite datos estadísticos, deshabilite el registro, que es el valor predeterminado. Este procedimiento describe cómo habilitar el registro SMTP y registrar los archivos en un disco compartido

Antes de empezar Cuando está habilitado, los Servicios de Internet Information Server (IIS) crean archivos de registro SMTP en la unidad de sistema del equipo local (por ejemplo, en C:\Winnt\System32\Logfiles, donde C es la ubicación de la instalación de Windows Server 2003 o Windows 2000). Para configurar el registro SMTP de forma segura en un entorno de clústeres, debe cambiar la ubicación predeterminada de los archivos de registro (es decir, el equipo local) a una carpeta de un disco compartido.

Procedimiento Para habilitar el registro SMTP y registrar los archivos en un disco compartido 1. En el Administrador del sistema de Exchange, en el árbol de consola, expanda Servidores y, a continuación, expanda el servidor en el que desee habilitar el registro de IIS para SMTP. 2. En el árbol de consola, expanda Protocolos y, a continuación, SMTP. 3. En el árbol de la consola, haga clic con el botón secundario del mouse en Servidor virtual SMTP predeterminado y, luego, haga clic en Propiedades. 4. En el cuadro de diálogo Propiedades de Servidor virtual SMTP predeterminado, en la ficha General, haga clic en Habilitar registro y, a continuación, en Propiedades. 5. En el cuadro de diálogo Propiedades de registro extendidas, en la ficha Propiedades generales, en Directorio del archivo de registro, cambie la ubicación del archivo de registro SMTP por una carpeta de un disco compartido. 6. Haga clic dos veces en Aceptar.

630

How to Create an HTTP Virtual Server in Exchange System Manager Al crear un servidor virtual de Exchange, durante la creación del recurso Operador de sistema de Exchange, Exchange crea un recurso de servidor virtual HTTP. En este tema se explica cómo utilizar el Administrador del sistema de Exchange para crear un servidor virtual HTTP.

Antes de empezar Deben repetirse los pasos siguientes en cada servidor virtual de Exchange del clúster.

Procedimiento Para crear un servidor virtual HTTP en el Administrador del sistema de Exchange 1. Abra el Administrador del sistema de Exchange. 2. En el árbol de la consola, expanda Servidores, expanda el servidor que desea configurar como servidor de servicios de fondo y, a continuación, expanda Protocolos. 3. Haga clic con el botón secundario del mouse en HTTP, seleccione Nuevo y, a continuación, haga clic en Servidor virtual HTTP. 4. En Propiedades, en el cuadro Nombre, escriba el nombre del servidor de aplicaciones para el usuario. 5. Junto a la lista Dirección IP, haga clic en Opciones avanzadas. 6. En Opciones avanzadas, en Identidades, seleccione la entrada predeterminada y, a continuación, haga clic en Modificar. 7. En Identificación, en la lista Dirección IP, seleccione la dirección IP de este servidor virtual de Exchange (servidor de servicios de fondo). Esta dirección IP debe coincidir con el valor del recurso Dirección IP que se configuró anteriormente en el servidor de servicios de fondo. Cuadro de diálogo Identificación

631

8. En el cuadro Nombre de host host,, escriba el encabezado del host del servidor de aplicaciones para el usuario. Éste es el nombre mediante el que los clientes tienen acceso al servidor de aplicaciones para el usuario. El encabezado de host del servidor virtual de Exchange debe asignarse a all encabezado de host del servidor de aplicaciones para el usuario. Nota: Las solicitudes de los clientes al servidor de aplicaciones para el usuario utilizan un host específico, como http://mail.contoso.com. Un servidor virtual de aplicaciones para el usuario usuario debe tener configurado el encabezado de host "mail.contoso.com". El servidor de aplicaciones para el usuario envía a través del proxy la solicitud al servidor de servicios de fondo, que también debe tener el encabezado de host configurado en un servidor servidor virtual. 9. Compruebe que el puerto TCP está establecido en 80 y, a continuación, haga clic en Aceptar. 10. En Opciones avanzadas avanzadas,, si desea agregar otra identidad, haga clic en Agregar y realice de nuevo los pasos 6 al 8. Nota: Considere la posibi posibilidad lidad de agregar algunas identidades al servidor virtual que muestren todos los caminos con los que el usuario puede obtener acceso al servidor de aplicaciones para el usuario. Por ejemplo, si un servidor de aplicaciones para el usuario se utiliza tanto de forma interna como externa, considere la posibilidad de mostrar un nombre del host y un nombre de dominio completo, como "mail" para el acceso interno y "mail.contoso.com" para el acceso externo. 11. En Opciones avanzadas avanzadas, haga clic en Aceptar dos veces para crear el nuevo servidor virtual HTTP.

632

How to Create Virtual Directories for an Exchange Virtual Server in a Windows Server Cluster Al crear un servidor virtual de Exchange, durante la creación del recurso Operador de sistema de Exchange, Exchange crea un recurso de servidor virtual HTTP. En este tema se explica cómo crear directorios virtuales para un servidor virtual de Exchange en un clúster de servidor de Windows. Antes de crear un directorio virtual, debe crear un servidor virtual HTTP en el Administrador del sistema de Exchange. Para ver instrucciones detalladas, consulte How to Create an HTTP Virtual Server in Exchange System Manager. Después de crear el servidor virtual HTPP, debe agregar directorios virtuales al servidor o servidores de servicios de fondo que coincidan con los directorios virtuales configurados en el servidor de aplicaciones para el usuario. Una instalación típica de Exchange contiene directorios virtuales denominados Exchange y Públicos. En el Administrador del sistema de Exchange, los directorios virtuales de los servidores virtuales HTTP aparecen como objetos secundarios del servidor virtual HTTP.

Antes de empezar En cualquier directorio virtual que apunte a los buzones, compruebe que el dominio SMTP seleccionado en Propiedades del directorio virtual coincide con el dominio SMTP de los usuarios que utilizan este servidor de aplicaciones para el usuario. Si el dominio correcto no está seleccionado, los usuarios de este dominio no podrán utilizar este servidor virtual para iniciar sesión. La lista de dominios se compila a partir de los dominios de las direcciones SMTP de las directivas de destinatario de la organización de Exchange. Si dispone de varias directivas de destinatario para el mismo dominio, aparecerán duplicados. En este caso, no importa la que seleccione.

Procedimiento Para crear directorios virtuales para un servidor virtual de Exchange en un clúster de servidor de Windows 1. Abra el Administrador del sistema de Exchange 2. En el árbol de la consola, expanda Servidores, expanda el servidor que desea configurar como servidor de servicios de fondo, expanda Protocolos y, a continuación, HTTP. 3. Haga clic con el botón secundario del mouse en , seleccione Nuevo y, a continuación, haga clic en Directorio virtual. 4. En Propiedades, en el cuadro Nombre, escriba Exchange.

633

5. En Ruta de acceso de Exchange, la opción Buzones dedominio SMTP está seleccionada de forma predeterminada. Mantenga esta configuración, ya que los usuarios utilizan el directorio virtual Exchange para obtener acceso a sus buzones de Exchange. Haga clic en Aceptar para crear el primer directorio virtual. 6. En el árbol de la consola, haga clic con el botón secundario del mouse en de nuevo, seleccione Nuevo y, a continuación, haga clic en Directorio virtual. 7. En Propiedades, en el cuadro Nombre, escriba Público. 8. Bajo Ruta de acceso de Exchange, haga clic en Carpeta pública y, a continuación, en Modificar. 9. En Selección de carpeta pública, haga doble clic en Carpetas públicas. Después de unos segundos, Exchange resuelve el nombre del servidor de la carpeta pública y lo anexa al nombre del contenedor Carpetas públicas. Cuadro de diálogo Selección de carpeta pública

10. Haga clic en Aceptar para cerrar el cuadro de diálogo Selección de carpeta pública. 11. En Propiedades, haga clic en Aceptar. 12. Si hay directorios virtuales adicionales configurados en el servidor de aplicaciones para el usuario, debe crear también estos directorios virtuales. Para crear directorios virtuales adicionales, repita los pasos 5 al 10 en cada directorio virtual.

634

Información adicional Para obtener más información acerca de la creación de directorios virtuales, consulte "Configurar el directorio virtual del servidor" en la Ayuda de Exchange 2003.

How to Create an HTTP Virtual Server Resource for an Exchange Virtual Server in a Windows Server Cluster Para que el servicio Cluster Server administre todos los servidores virtuales HTTP, debe crear un nuevo recurso de servidor HTTP en cada servidor virtual HTTP. En este tema se explica cómo crear un recurso de servidor virtual HTTP para un servidor virtual de Exchange en un clúster de servidor de Windows.

Antes de empezar Debe realizar los pasos siguientes en cada servidor virtual de Exchange en el que agregue un nuevo servidor virtual HTTP.

Procedimiento Para crear un recurso de servidor virtual HTTP para un servidor virtual de Exchange en un clúster de servidor de Windows 1. Abra el Administrador de clústeres. 2. Haga clic con el botón secundario del mouse en el servidor virtual de Exchange, seleccione Nuevo y, a continuación, haga clic en Recurso. 3. Se iniciará el Asistente para recurso nuevo. En el cuadro Nombre, escriba Servidor virtual HTTP de Exchange - (), donde NombreEVS es el nombre del servidor de aplicaciones para el usuario. 4. En la lista Tipo de recurso, haga clic en Instancia del servidor HTTP de Microsoft Exchange. Compruebe que la lista Grupo contiene el nombre del servidor virtual de Exchange y, a continuación, haga clic en Siguiente. 5. En Posibles propietarios, bajo Posibles propietarios, compruebe que aparecen todos los nodos y, a continuación, haga clic en Siguiente. 6. En Dependencias, agregue el recurso Operador de sistema de Exchange al cuadro Dependencias de recursos y, a continuación, haga clic en Siguiente. 7. En Instancia del servidor virtual, en la lista Instancia del servidor, seleccione el servidor virtual HTTP que se ha creado recientemente para el recurso y, a continuación, haga clic en Finalizar.

635

8. En el Administrador de clústeres, haga clic con el botón secundario del mouse en las instancias del servidor virtual HTTP que acaba de crear y haga clic en Poner en conexión.

Copyright La información contenida en este documento representa la visión actual de Microsoft Corporation acerca de los asuntos tratados hasta la fecha de su publicación. Como Microsoft debe responder a condiciones de mercado variables, no debe interpretarse como un compromiso por parte de Microsoft y Microsoft no puede garantizar la precisión de la información que se presenta después de la fecha de publicación. Este documento se proporciona con propósito informativo únicamente. MICROSOFT NO OTORGA NINGUNA GARANTÍA, YA SEA EXPLÍCITA, IMPLÍCITA O ESTATUTARIA, CON RESPECTO A LA INFORMACIÓN CONTENIDA EN ESTE DOCUMENTO. Es responsabilidad del usuario el cumplimiento de todas las leyes de derechos de autor aplicables. Ninguna parte de este documento puede ser reproducida, almacenada o introducida en un sistema de recuperación, o transmitida de ninguna forma, ni por ningún medio (ya sea electrónico, mecánico, por fotocopia, grabación o de otra manera) con ningún propósito, sin la previa autorización por escrito de Microsoft Corporation, sin que ello suponga ninguna limitación a los derechos de propiedad industrial o intelectual. Microsoft puede ser titular de patentes, solicitudes de patentes, marcas, derechos de autor, u otros derechos de propiedad industrial o intelectual sobre los contenidos de este documento. El suministro de este documento no le otorga ninguna licencia sobre estas patentes, marcas, derechos de autor, u otros derechos de propiedad intelectual, a menos que ello se prevea en un contrato por escrito de licencia de Microsoft. A menos que se indique lo contrario, las compañías, organizaciones, productos, nombres de dominios, direcciones de correo electrónico, logotipos, personas, lugares y acontecimientos utilizados en los ejemplos son ficticios. No se pretende ni se debe inferir de ningún modo relación con ninguna compañía, organización, producto, nombre de dominio, dirección de correo electrónico, logotipo, persona, lugar o acontecimiento real. © 2006 Microsoft Corporation. Reservados todos los derechos. Microsoft, MS-DOS, Windows, Windows Server, Windows Vista, Active Directory, ActiveSync, ActiveX, Entourage, Excel, FrontPage, Hotmail, JScript, Microsoft Press, MSDN, MSN, Outlook, SharePoint, Visual Basic, Visual C++, Visual Studio, Win32, Windows Mobile, Windows NT y Windows Server System son marcas registradas o marcas comerciales de Microsoft Corporation en los EE.UU. y/o en otros países. Todas las demás marcas son propiedad de sus respectivos propietarios.