E 2 K 3 Techref

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 exchdocs@microsoft.com.
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
una reproducción remota ............................................................................................... 373
Antes de empezar.......................................................................................................... 373
Procedimiento................................................................................................................ 374
una reproducción incremental ........................................................................................ 375
Antes de empezar.......................................................................................................... 375
Procedimiento................................................................................................................ 376
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
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 del tipo de mensaje de correo electrónico .................................................... 463
Asignación de propiedades de mensajes de correo electrónico ...................................... 463
Arquitectura del Conector para Novell GroupWise ............................................................. 467

Transferencia de mensajes ............................................................................................ 474
Conversión del tipo de mensaje de correo electrónico .................................................... 479
Conversión de propiedades de mensajes de correo electrónico ..................................... 480
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 enenviar
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, todosdos 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 ded 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

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 cliente-
servidor, 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
dee 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 valoresvalores 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
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
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.
registra el error y
muestra un mensaje pero
continúa con la operación
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.
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
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
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
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 ExchanExchangege 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
\SYSTEM\CurrentControlSet\Services\IISAdmin.
HKEY_LOCAL_MACHINE\ 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
• 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
\SYSTEM\CurrentControlSet\Services\SMTPSvc.
HKEY_LOCAL_MACHINE\ 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
\SYSTEM\CurrentControlSet\Services\POP3Svc.
HKEY_LOCAL_MACHINE\ 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
\SYSTEM\CurrentControlSet\Services\NNTPSvc.
HKEY_LOCAL_MACHINE\ 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 dee 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
\SYSTEM\CurrentControlSet\Services\IMAP4Svc.
HKEY_LOCAL_MACHINE\ 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 El Operador de sistema debe

dominio en la red y buscar controladores de
proporcionar a otros servicios dominio y catálogos globales
de Exchange información de en la red, de manera que los
Active Directory 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 DSProxy Conectar a través de proxy El componente DSProxy de

los clientes MAPI heredados Operador de sistema
a Active Directory (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 de Mantener la información de El Operador de sistema

disponibilidad disponibilidad para los interviene cuando se publica
usuarios de Outlook Web información de disponibilidad
Access 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 Administrar buzones El componente Administrador

de buzones 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
Servicio de actualización de Replicar configuraciones de El servicio de actualización

la metabase Active Directory a la del Servicio de directorio a la
metabase de IIS 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
Active Directory.
67
Generador de libretas de Generar libretas de El Generador de libretas de

direcciones sin conexión direcciones sin conexión 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 Aplicar directivas de El Servicio de actualización

destinatarios destinatarios y generar de destinatarios (Abv_dg.dll)
direcciones proxy 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
Active Directory.
68
Componente Monitor de Supervisar los recursos de El Operador de sistema

servidores servidor 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 Operador de Comprueba la configuración La cuenta de equipo de un

sistema de cuenta de equipo 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

dee 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 aarchivos
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 20032003, 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
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
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
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\ MSExchangeMTA.
\System\CurrentControlSet\Services\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
Bin. La clave del Registro es
HKEY_LOCAL_MACHINE\ MSExchangeGWRtr.
\System\CurrentControlSet\Services\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
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 esteeste 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, todosos 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.

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.

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

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.

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

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
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
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 consultata 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
siguientee 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
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:
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.
\CurrentControlSet\Services\MSExchangeDSAc
cess
Valor DisableNetLogonCheck
Tipo REG_DWORD
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 PDCDC 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\<Name
of DC>
Valor IsGC
Tipo REG_DWORD
of DC>
Valor HostName
Tipo REG_SZ
Información del valor <name of DC>
of DC>
Valor DSType
Tipo REG_SZ
Información del valor 0
of DC>
92
Valor PortNumber
Tipo REG_DWORD
Información del valor 0x00000185 (389)
of GC>
Valor IsGC
Tipo REG_DWORD
of GC>
Valor HostName
Tipo REG_SZ
Información del valor <name of GC>
of GC>
Valor DSType
Tipo REG_SZ
Información del valor 0
of GC>
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 <Name of config DC>
Valor ConfigDCPortNumber
Tipo REG_DWORD
• 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
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
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
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
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
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 Seguimiento de los cambios del directorio

(DS2MB) mediante el número de secuencia de
actualización (USN)
Motor de enrutamiento de Exchange Consultas de usuarios y de configuración

(RESVC)
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.
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é
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.
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é
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:
quizás requieran volver a instalar el sistema operativo. Es posible que los problemas
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 Sitio de Active ¿En uso por Puntos totales por

Directory DSAccess? valor de restricción
DominioUsuario GC1 Sitio de Active No 16+8+4=28

Directory cliente (1, 2, 3)
DominioUsuario GC2 Sitio de Active No 16+8+4=28

Directory cliente (1, 2, 3)
108
Servidor Sitio de Active ¿En uso por Puntos totales por

Directory DSAccess? valor de restricción
DominioUsuario GC3 Sitio B de Active No 16+8+4=28

Directory (1, 2, 3)
DominioUsuario GC4 Sitio B de Active No 16+8+4=28

Directory (1, 2, 3)
Dominio GC1 de Sitio de Active Sí 16+8+2+1=27

Exchange Directory de (1, 2, 4, 5)
Exchange
Dominio GC2 de Sitio de Active Sí 16+8+2+1=27

Exchange Directory de (1, 2, 4, 5)
Exchange
Dominio GC3 de Sitio A de Active No 16+8=24

Exchange Directory (1, 2)
Dominio de Sitio A de Active No 16+8=24

Exchange GC4 Directory (1, 2)
Dominio de Sitio B de Active No 16+8=24

Dominio de Sitio B de Active No 16+8=24

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 Ted@contoso.com, 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 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 clclaves. 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:
• HKEY_CLASSES_ROOT\CLSID 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-10BA-
11d2-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.
• HKEY_LOCAL_MACHINE\Software\Microsoft\MMC\SnapIns 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
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-10BA-
11d2-9F28-
00C04FA37610}
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
{CLSID} NameStringIndirect REG_SZ 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
{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
{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
• KEY_LOCAL_MACHINE\Software\Microsoft\MMC\NodeTypes 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.
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 Descripción

complemento proceso
Centro de No aplicable Exadmin.dll Proporciona

seguimiento de obtención de acceso
mensajes de al centro de
Exchange seguimiento de
mensajes. Éste es un
complemento
autónomo.
Protocolos de No aplicable Exadmin.dll Implementa el

Exchange 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 proceso
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
NNTP.
POP3 de Exchange Pop3mgr.dll Permite la

administración del
protocolo POP3 y de
POP3.
SMTP de Exchange Exps.dll Permite la

administración del
Protocolo simple de
transferencia de
correo (SMTP) y de
SMTP.
127

complemento proceso
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.
Servidores Exchange 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 proceso
DXA de Exchange Exadmin.dll 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 proceso
Almacén de Exadmin.dll Permite la

información de administración de
Exchange grupos de
almacenamiento,
almacenes de
buzones y almacenes
de carpetas públicas.
Supervisión de Exadmin.dll Le permite examinar

Exchange el estado de los
conectores de
mensajería y
servidores Exchange
entre los grupos de
enrutamiento.
Protocolos de Exadmin.dll Como se ha

Exchange mencionado
anteriormente en
esta tabla, este
complemento
implementa el
contenedor
Protocolos y
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 proceso
Visor de colas de Exadmin.dll Proporciona

Exchange 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.
Sistema de No aplicable Exadmin.dll El complemento

Exchange 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 proceso
Listas de direcciones Exadmin.dll Permite la

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

direcciones de administración de
Exchange plantillas de
direcciones.
Conector de Exadmin.dll Permite la

calendario de administración de las
Exchange 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 proceso
cc:Mail para Exadmin.dll Permite la

Exchange 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 proceso
DXA de Exchange Exadmin.dll 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 proceso
Carpetas de Exadmin.dll Permite la

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

Exchange para administración del
GroupWise Conector para Novell
GroupWise.
Almacén de Exadmin.dll Permite la

información de administración de
Exchange grupos de
almacenamiento,
almacenes de
buzones y almacenes
de carpetas públicas.
Centro de Exadmin.dll Proporciona

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

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

complemento proceso
Supervisión de Exadmin.dll Proporciona

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

complemento proceso
MSMail para Exadmin.dll Permite la

Exchange 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 Proporciona

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

complemento proceso
Protocolos de Exadmin.dll Como se ha

Exchange mencionado
anteriormente en
esta tabla, este
complemento
implementa el
contenedor
Protocolos y
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 Exadmin.dll Proporciona

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 proceso
Directivas de Exadmin.dll Permite la

destinatario de administración de
Exchange 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 proceso

Exchange para la comprobación de los
disponibilidad de valores de
Schedule+ 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 proceso
Servidores Exchange Exadmin.dll 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 NetBNetBIOS
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\ der. El valor
\SOFTWARE\Microsoft\Exchange\Exchange Provider
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=Default-
CN=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 ExcExchange
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ónunció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 Sí Sí Sí
de Exchange
Administrador de No Sí Sí
Exchange
Administrador con No No Sí
permiso de vista de
Exchange
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:
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 • Crear propiedades con Ninguno

ANÓNIMO nombre en el almacén de
información
• Crear carpeta pública
• Ejecutar
• Mostrar contenido
• Mostrar objeto
• Leer
• Permisos de lectura
• Propiedades de lectura
Usuarios autenticados • Propiedades de lectura Ninguno

• Mostrar objeto
151
Administradores de dominio • Leer • Recibir como

(dominio raíz) • Escribir • Enviar como
• Ejecutar
• Eliminar
• Cambiar permisos
• Tomar posesión
• Crear secundarios
• Agregarse o quitarse a sí
mismo
• Propiedades de escritura
• Mostrar objetos
• 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
Administradores de • Control total • Recibir como

organización • Enviar como
Todos • Crear propiedades con Ninguno

nombre en el almacén de
información
• Ejecutar
• Mostrar objetos
• Leer
Servidores de dominio de • Control total Ninguno

Exchange
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
dee 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
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
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
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
dee 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
Exchangege 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 <AAAAMMDD>.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 <NOMBRESERVIDOR>.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
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:
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 SecurePipeServers.
SYSTEM\CurrentControlSet\Control\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 opopciones
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
SYSTEM\CurrentControlSet\Control\Services de un servidor de
HKEY_LOCAL_MACHINE\SYSTEM
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.

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.
• 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

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
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
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
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 Indica que el motor de transporte debe pasar
de enrutamiento local 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 Indica que el motor de transporte debe pasar
de enrutamiento local 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 Indica que el motor de transporte debe pasar
fuera de la organización de Exchange 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 Indica que existe una ruta de destino, pero
se puede obtener acceso en este momento 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 Indica que no existe ninguna ruta de destino
se puede obtener acceso 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
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 Exchangenge 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-9B8F-
4403F20CAD0D ( 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 El GUID que está registrado

(objectGUID de organización) 32642 en el atributo objectGUID del
objeto de organización de
Exchange en
Active Directory.
MD5 Digest (código MD5) d037d6eaf2fa7cd10934aca4333 Un código MD5 o valor hash.

90623 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.
Routing Group objectGUID 489416bfa3a4ff459b8f4403f20 El GUID que está registrado

(objectGUID de grupo de cad0d en el atributo objectGUID del
enrutamiento) 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
Routing Group Master 1650c1fe32aef740be236e1089e El GUID que está registrado

objectGUID (objectGUID de 0da6a en el atributo objectGUID del
maestro de grupo de servidor que actúa de
enrutamiento) maestro de grupo de
enrutamiento de este grupo
de enrutamiento.
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
Version Info (Información de 8 0 2 Los valores 8 0 2 son las

versión) c2da71f9b39ec748aaf44119a2b versiones principal,
dcb36 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:
• 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
Routing Group Addresses {26}*.489416BF-A3A4-FF45- Asigna información de

(Direcciones de grupos de 9B8F-4403F20CAD0D SMTP, X.400, X.500 y
enrutamiento) {4c}c=DE;a= direcciones a cada GUID de
;p=TailspinToys;o=Exchange; grupo de enrutamiento. El
cn=489416BF-A3A4-FF45-9B8F- motor de enrutamiento usa
4403F20CAD0D;* esta información para
{55}/o=TailspinToys/ou=Firs generar una caché del
t administrative servidor interna, que sirve
Group/*/489416BF-A3A4-FF45- para identificar el grupo de
9B8F-4403F20CAD0D enrutamiento de cada
servidor en la topología de
enrutamiento. La caché del
servidor es una tabla interna
del motor de enrutamiento.
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-9B8F-
4403F20CAD0D.
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
Routing Group Members ( Contiene una lista de todos

(Miembros de grupo de 1650c1fe32aef740be236e1089e los servidores que
enrutamiento) 0da6a YES 1 1b20 pertenecen al grupo de
{10}0701000000000101 ) 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.
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
Connectors in Routing Group ( A partir del siguiente

(Conectores del grupo de aa582d35e9621c4ca8ae57aa33d paréntesis de apertura, cada
enrutamiento) 953a1 ( CONFIG )) 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.
La información de
configuración del conector de
la tabla de estados de
vínculos contiene los campos
siguientes:
Connector objectGUID aa582d35e9621c4ca8ae57aa33d El GUID que identifica al

(objectGUID de conector) 953a1 conector de forma exclusiva
en la organización de
Exchange.
194
Connector Type (Tipo de {4}SMTP Este campo identifica el tipo

conector) 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
Source Bridgehead Address {} Este campo puede tener uno

(Dirección de servidor cabeza de estos tres valores:
de puente de origen) • 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
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
Destination Bridgehead {23}_aa582d35e9621c4ca8ae57 Al igual que con el campo

Address (Dirección de aa33d953a1_D Source Bridgehead Address,
servidor cabeza de puente de este campo puede tener uno
destino) 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
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
Legacy Distinguished Name {63}/o=TailspinToys/ou=Firs Éste es el nombre completo

(Nombre completo heredado) t administrative del conector en formato de
Group/cn=Configuration/cn=C directorio heredado de
onnections/cn=RGC RG A <-> Exchange 5.5. El valor
RG B corresponde al atributo
legacyExchangeDN del
objeto de conector de
Active Directory.
Schedule ID (Id. de 0 El campo Schedule ID no se

programación) 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
Restrictions (Restricciones) 0 0 0 ffffffff ffffffff 0 1 El campo Restrictions

0 () 0 () 0 () 0 () identifica el ámbito del
conector, las restricciones
restri de
tamaño de mensajes y otras
restricciones como sigue:
• 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
Address Spaces (Espacios ARROWS ( {2}RG Cada conector tiene como

de direcciones) {20}83bd0e29fad06d4eb8b00fa mínimo un espacio de
ab3265cd5 1 {4}X400 direcciones asociado. El
{23}c=DE;a= motor de enrutamiento utiliza
;p=TailspinToys;o=Exchange; esta información para
1 ) determinar posibles
conectores para un mensaje
concreto; para ello, compara
las direcciones de los
destinatarios con la
información de espacios de
direcciones disponible.
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
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
enrutamiento, el tipo de
es RG, que indica un
objectGUID de grupo de
enrutamiento.
• Espacio de
direcciones El espacio
200
Source Bridgeheads BH () El campo BH incluye los

(Servidores cabeza de servidores cabeza de puente
puente de origen) 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
Destination Bridgeheads TARGBH ( Al igual que con la lista BH (),

(Servidores cabeza de 766a192b43bfc3459ee85608d65 la lista TARGBH () contiene
puente de destino) a98a9 CONN_AVAIL los servidores cabeza de
{19}server01.TailspinToys.c puente de destino de un
om ) conector. Esta lista es
especialmente importante
para conectores para grupo
de enrutamiento, que pueden
tener varios servidores
cabeza de puente remotos.
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
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
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
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 dee 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 muesmuestra
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
dee 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 rutarutass 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.
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.
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 estos tipos de conectores, el motor de

con varios servidores cabeza de puente de enrutamiento devuelve el GUID de conector
origen o de destino, o ambos. 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 origenn 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 En este tipo de configuración, no se logra un
direcciones (o grupo de enrutamiento verdadero equilibrio de carga. El equilibrio de
conectado), el mismo peso (costo) y cada carga
ga se realiza únicamente con el propósito
uno con un único servidor cabeza de puente de seleccionar un conector inicialmente para
de origen y de destino 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 Si desea configurar conectores para que
direcciones (o grupo de enrutamiento conmuten por error automáticamente, puede
conectado), diferentes
rentes pesos (costo) y cada crear dos conectores distintos en servidores
uno con un único servidor cabeza de puente cabeza de puente diferentes, cada uno con
de origen y de destino 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
esoss 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 ded
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. Cuandodo 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 dde
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:
Cuando o se vinculan grupos de enrutamiento mediante un conector X.400, se
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
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

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.
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

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

y notifica el cambio a todos los servidores del grupo de enrutamiento.
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\
StateChangeDelay
Valor
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.
SuppressStateChanges
Valor
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
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.
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 X-
LINK2STATE 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
• 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 prproceso
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.
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
crearear 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
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\binbin\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
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
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
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
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
msExchSmtpInboundCommandSupportOptio Controla los comandos SMTP que se

ns 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
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 Especifica una lista de conectores de grupos

grupo
BL 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:
<IIsSmtpService Location ="/LM/SmtpSvc"
ConnectionTimeout="600"
251
DefaultDomain="server01.TailspinToys.com"
DomainRouting=""
EnableReverseDnsLookup="FALSE"
FullyQualifiedDomainName="server01.TailspinToys.com"
...
SmtpRemoteProgressiveRetry="15,30,60,240"
SmtpRemoteRetryThreshold="3"
>
<Custom
Name="AuthFlags"
ID="6000"
Value="AuthBasic | AuthAnonymous | AuthNTLM"
Type="DWORD"
UserType="IIS_MD_UT_SERVER"
Attributes="INHERIT"
/>
...
<Custom
Name="UnknownName_61537"
ID="61537"
Value="0"
Type="DWORD"
UserType="IIS_MD_UT_SERVER"
Attributes="NO_ATTRIBUTES"
/>
</IIsSmtpService>
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.
<IIsSmtpServer Location ="/LM/SmtpSvc/1"
... property definitions that apply only to the
particular virtual server ...
>
<Custom
252
... custom property defintion...
/>
</IIsSmtpServer>
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-46c4-
705260ab
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:
<IIsConfigObject Location ="/LM/SmtpSvc/1/EventManager/
EventTypes/{283430C9-1850-11D2-9E03-00C04FA322BA}/
Bindings/{A928AD15-1610-11D2-9E02-00C04FA322BA}/
SinkClass"
>
<Custom
Name="MD_0"
ID="0"
Value="Exchange.Router"
Type="STRING"
UserType="UNKNOWN_UserType"
Attributes="NO_ATTRIBUTES"
/>
</IIsConfigObject>
Este enlace asocia el GUID de un suceso concreto, como 283430C9-1850-11D2-9E03-

00C04FA322BA, 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-9E03-

00C04FA322BA 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
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 (<IIsSmtpServerLocation ="/LM/SmtpSvc/1">) para
impedir revelar información de versión específica de Exchange en las
comunicaciones SM SMTP, tal y como sigue:
<IIsSmtpServer 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
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 Esta cola contiene mensajes en cola para su
diferida 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:
• 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".
Cola de reintento de mensajes 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
ange\TransportAVAPI
Valor Enabled
Tipo REG_DWORD
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
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:ted@fabrikam.com)
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:ted@fabrikam.com)". Si la dirección SMTP de Ted
"(proxyAddresses=smtp:ted@fabrikam.com)".
es Ted@fabrikam.com, 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:Ted@fabrikam.com) (proxyAddresses=smtp:Birgit@fabrikam.com))
(proxyAddresses=smtp:Birgit@fabrikam.com))
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:Ted@fabrikam.com)
(proxyAddresses=smtp:Birgit@fabrikam.com))". Si la dirección SMTP de Ted
(proxyAddresses=smtp:Birgit@fabrikam.com))".
es Ted@fabrikam.com y la de Birgit es Birgit@fabrikam.com, 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

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
usuario_no_existe@fabrikam.com, 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
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
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.

• 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
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.

• 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 dde
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 lasla 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 ententrega
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 no entrega se redirigen a fin

los informes de entrega están configurados de informar al propietario configurado del
para enviarse a este propietario 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 Se envía una notificación de estado de

para enviarse al autor del mensaje 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 Se suprimen todas las notificaciones de

para suprimir los informes de entrega para ausencia de la oficina, las respuestas
los miembros del grupo a fin de evitar la automáticas y cualquier tipo de notificaciones
divulgación de información
informació de los miembros de estado de entrega (como las
del grupo 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
directamentee 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 enviadosviados 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
Exchange\nn\EnableTnef
ange\StoreDriver\Exchange
Valor Disabled
Tipo REG_DWORD

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 cadcadaa 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
Utilice el Editor del Registro bajo su propia
p responsabilidad.
291
t\Services\SMTPSVC\Parameters
Valor LdapResultTimeout
Tipo REG_DWORD
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).
Valor LdapRequestTimeLimit
Tipo REG_DWORD
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
Valor MaxConnectionRetries
Tipo REG_DWORD
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
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úmeroro 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.
Parameters
Valor MaxLdapConnections
Tipo REG_DWORD
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
dee 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.
Valor MaxSearchBlockSize
Tipo REG_DWORD
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.
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
t\Services\SMTPSVC\Queuing\
Valor ResetMessageStatus
Tipo REG_DWORD
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 comcomoo 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 esteste
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: Ted@contoso.com
x-receiver:
receiver: Birgit@fabrikam.com
From: Ted@contoso.com
To: Birgit@fabrikam.com
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
procesadodo 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. IISIIS 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-b0dd-
96b9c605364\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 hhasta
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 loloss 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
devuelveve 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
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 produceproduc 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 dee 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
AUTH, AUTH GSSAPI NTLM LOGIN y Indica que el servidor virtual SMTP local
AUTH=LOGIN 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
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
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 <Ted@TailspinToys.com>
318
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, X-
X X-EXPS
EXPS es un comando exclusivo de
EXPS=LOGIN 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:
• 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.
X-LINK2STATE 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 enen 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
321
Extensiones de protocolo para el comando XEXCH50
Receptor de sucesos Suceso de protocolo Comentarios
Receptor Exchange SMTP OnBeforeData Notifica al receptor XEXCH50

Protocol XEXCH50 Before que el comando de protocolo
Data 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 OnInboundCommand Notifica al receptor XEXCH50

Protocol XEXCH50 Inbound que se ha recibido un
EHLO comando EHLO.
Receptor Exchange SMTP OnInboundCommand Implementa el comando

Protocol XEXCH50 Inbound XEXCH50 para iniciar una
XEXCH50 conversación XEXCH50.
Receptor Exchange SMTP OnInboundCommand Implementa el comando

Protocol XEXCH50 Inbound MAIL en una conversación
MAIL XEXCH50.
Receptor Exchange SMTP OnInboundCommand Permite al servidor virtual

Protocol XEXCH50 Inbound SMTP local recibir
RCPT información del destinatario
en una comunicación
XEXCH50 entrante.
Receptor de sucesos OnPerRecipient Permite al servidor virtual

Exchange SMTP Protocol SMTP local enviar
XEXCH50 Per Recipient información del destinatario
en una comunicación
XEXCH50 saliente.
322
Receptor Exchange SMTP OnServerResponse Permite al servidor virtual

Protocol XEXCH50 Ehlo SMTP local recibir una
Response 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).

Protocol XEXCH50 SMTP local recibir una
Response 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

Protocol XEXCH50 RCPT SMTP local recibir
Response 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
administrator@tailspintoys.co
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
324
Extensiones de protocolo para el comando X-LINK2STATE
Receptor EHLO Inbound OnInboundCommand Notifica a los receptores de

Command Handler para sucesos de X-LINK2STATE
XLSA que se ha recibido un
comando EHLO entrante.
Receptor X-LSA Inbound OnInboundCommand Notifica a los receptores de

Command Handler sucesos de X-LINK2STATE
que se ha recibido un
comando X-LINK2STATE
entrante.
Receptor X-LSA OnMessageStart, Indica el inicio (comando

OnSessionEnd 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 OnServerResponse Responde a un comando X-

Handler LINK2STATE 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 EHLO Response OnServerResponse Responde a un comando

Handler para X-LSA 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 Exchange SMTP OnInboundCommand Indica el final de la

Protocol Security EXPS-EOD transferencia de datos (
_EOD).
Receptor Exchange SMTP OnInboundCommand Indica un comando AUTH

Protocol Security EXPS-Aux entrante.
Receptor Exchange SMTP OnInboundCommand, Indica un comando EHLO

Protocol Security EHLO OnServerResponse entrante y responde a EHLO
mostrando el comando X-
EXPS en la respuesta del
servidor.
Receptor Exchange SMTP OnInboundCommand, Indica el inicio de la

Protocol Security Mail OnServerResponse, transferencia de datos. Este
OnMessageStart 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 OnInboundCommand, Indica el inicio de una sesión

Protocol Security EXPS OnServerResponse, X-EXPS. Este receptor de
OnSessionStart sucesos se implementa para
todos los escenarios de
comandos X-EXPS
importantes. Este receptor de
sucesos procesa los sucesos
que indican un comando X-
EXPS 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 RCPT Inbound OnInboundCommand Indica un comando RCPT

Command Handler entrante con una dirección de
destinatario que debería
comprobarse.
Receptor MAIL Inbound OnInboundCommand Indica un comando MAIL

Command Handler para entrante con una dirección de
TURF remitente que debería
comprobarse.
Receptor EOD Inbound OnInboundCommand Indica un comando _EOD

Command Handler 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 estestablecer
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ónn 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
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
• 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:
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
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: Usingg 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

• 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

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:
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 rerealizar
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
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
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
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
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

un mensaje normal.
transferTimeoutUrgent Especifica el tiempo en segundos por

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
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 ddee 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
t\Services\
MSExchangeMTA\Parameters
Valor Transfer threads
Tipo REG_DWORD

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 adadelante
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úns 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
t\Services\
Valor Dispatcher threads
Tipo REG_DWORD

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).
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.
t\Services\
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
t\Services\
Parameters
Valor DB data buffers per object
Tipo REG_DWORD

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.
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).
t\Services
\MSExchangeIS\<server_name>\Private-
<database_guid>
Valor Gateway In Threads Gateway Out Threads
Tipo REG_DWORD
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
Pilaa 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
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

Lecturas de archivos de disco El número de operaciones de lectura de

Escrituras en archivos de disco El número de operaciones de escritura en

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 La velocidad a la que se reciben los bytes a

administrativa/seg. través de una conexión administrativa.
Bytes transmitidos por la interfaz La velocidad a la que se transmiten los bytes

administrativa/seg. a través de una conexión administrativa.
359
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
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
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
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
<GUID>, 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 ExcExchange, 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
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
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
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
APDU (Unidad de datos de protocolo de Esta categoría no ocasiona la escritura de

aplicación) 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
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:
requieran reinstalar el sistema operativo. Microsoft
Microsoft no puede garantizar que estos
367
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-4AFD-
85AF-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=<country>;A= ;P=<organization>;L=<server>-<date><greenich
;P=<organization>;L=<server> eenich mean time>-<message
time>
number> 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.
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
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
MTA mediante una reproducción remota
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

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
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 alal 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 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.

mediante una reproducción remota
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
Antes de empezar
• 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.
374
Precaución:
resolver. Antes de
de modificar el Registro, se recomienda realizar una copia de
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
Valor Dispatch remote MTA messages
Tipo REG_DWORD
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 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
me
una reproducción completa.
completa
base de datos del MTA a través de una reproducción incremental, consulte Cómo
una reproducción incremental.
incremental

mediante una reproducción incremental
datos del MTAA 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
• 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
una reproducción remota.
remota
• Este tema contiene
e información acerca de la modificación del Registro.
Precaución:
problemas derivados de una modifica
modificación
ción incorrecta del Registro no se puedan
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 ses 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.

base de datos del MTA a través de una reproducción completa, consulte Cómo
una reproducción completa.
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 accesoacces 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 comunicarsearse 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 2A864886F7140501

de la base de datos de
Microsoft (MDBEF).
• 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.
Carpeta pública MDBEF • Tipo de contenido 2A864886F7140502

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.
P2 • Definido en el X.400 del 56010A00

año de conformidad
1984.
• Define el formato de un
mensaje interpersonal
(IPM).
P22 • Definido en el X.400 del 56010A01

año de conformidad
1988.
• Extiende el formato de un
mensaje interpersonal
(IPM) definido en X.400-
84.
381
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.
P42 • Mensaje militar seguro. 60.864.801.650.201.024A

• 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.
“MSP3”.
382
CSP • Protocolo de seguridad 608648016502010203

común.
• 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
TNEF • Formato de codificación 2A864886F7140502

neutro para el transporte
(TNEF).
• Tipo de contenido
registrado y definido por
Microsoft.
“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 MTMTA 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-TURN-
PLEASE 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 RT-
P-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:
respo
t\Services\
Parameters
Valor RTS threads
Tipo REG_DWORD
Descripción Determina el número de subprocesos RTS.

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 P-
ACTIVITY-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:
t\Services\
389
Valor Kernel threads
Tipo REG_DWORD

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

pSelector Especifica el PSAP en la información de la

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
• 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
"(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

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.



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.

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
t\Services\
Parameters
Valor Transport threads
Tipo REG_DWORD

transporte.
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 Q=SR;

generación
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 N
N-ID=208973240
usuario
T-TY T-TY
T Tipo de terminal T
T-TY=TTY;
T-ID T-ID
T Identificador de T
T-ID=309;
terminal
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 DDA:SMTP=Ted@tai

el dominio lspintoys.com
(DDA:tipo=valor del
atributo)
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
Ted@tailspintoys.com) 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:rfc-
822=Ted@tailspintoys.com. 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
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=<las 16 primeras letras del nombre de la organización de Exchange>.
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

Cuandondo 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
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
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.

408
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.

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.

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
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.

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

un mensaje no urgente.
transferTimeoutNormal Especifica el tiempo en segundos por

un mensaje normal.
410
transferTimeoutUrgent Especifica el tiempo en segundos por

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.

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
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.
t\Services\
Valores TCP/IP control blocks
TP4 control blocks
Eicon X.25 connections
Tipo REG_DWORD
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
t\Services\
Valor TCP/IP threads
Tipo REG_DWORD

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
Type: ERROR
Category: Configuration
Unable to initialize due to a bad configuration. Contact Microsoft Technical Support.

Error code=<variable> [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
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> -
{<GUID del almacén de buzones>}). 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
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
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 MTS-
OUT 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.
t\Services\
Valor Min RPC Threads
Tipo REG_DWORD
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
t\Services\
Valor Max RPC Calls Outstanding
Tipo REG_DWORD
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-<guid_base_datos>, 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
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
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
"(objectClass=siteAddressing)".
La tabla siguiente describe los atributos importantes del objeto de directorio GWART.
425
Atributos importantes del objeto GWART
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.
• 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
quee 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
DLLL 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
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
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 dependenden 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 MTSMTS-IN del
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 dde texto.
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
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
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
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
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.
La figura siguiente ilustra el proceso general de transferencia
transferencia de información de directorio
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
• Mdbvu32.exe se puede descargar desde el sitio Web Downloads for Exchange
Server 2003.
Precaución:
resolver. Antes de modificar el Registro, se recomienda realizar una cop
copia de
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-5-
18\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-LMELME-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
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
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
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
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
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
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
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
<Nombre de organización>/Grupos
administrativos/<Nombre del grupo
administrativo>/Grupos de
enrutamiento/<Nombre del grupo 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
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 MTS-
OUT del servicio SMTP (Protocolo simple de transferencia de correo), desde la cual
finalmente se enruta.
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 Mensajes de correo Sí Sí

electrónico electrónico
Confirmación de Confirmación de Sí Sí
entrega de mensaje entrega de mensaje
lectura de mensaje lectura de mensaje
Informe de no Informe de no Sí Sí
entrega entrega
Importancia Importancia Sí Sí
Botones de votación Sin característica No No
Objeto OLE Objeto OLE Sí Sí

incrustado incrustado
Archivo adjunto Archivo adjunto Sí Sí

incrustado incrustado
Fecha de caducidad Fecha de caducidad No No

del mensaje del mensaje
Sin característica Responder antes del No No
Dirección URL de Dirección URL de Sí Sí

sitio Web sitio Web
Sin característica Zona activa de No No

dirección URL
462

Convocatorias de Citas Sí Sí
reunión
Reunión aceptada Reunión aceptada Sí Sí
Reunión rechazada Reunión rechazada Sí Sí
Reunión aceptada Reunión aceptada Aparece como Aparece como

provisionalmente aceptada aceptada
lectura de lectura de
convocatoria de convocatoria de
reunión reunión
Entrega de Entrega de Sí Sí
reunión reunión
Actualizaciones de Actualizaciones de Aparecen como Aparecen como

reuniones reuniones nuevas convocatorias nuevas convocatorias
de reunión que de reunión que
contienen la palabra contienen la palabra
"Actualizada" en la "Actualizada" en la
línea Asunto línea Asunto
Cancelación de Cancelación de Sí Sí
reunión reunión
Solicitudes de tareas Tareas Las solicitudes de Las solicitudes de

tareas aparecen tareas aparecen
como mensajes de como mensajes de
correo electrónico o correo electrónico
tareas
Convocatorias de Sin característica No Aparecen como

reunión con una reuniones con la
duración de todo el medianoche como
día hora de inicio y de fin
Sin característica Mensajes telefónicos Aparecen como No

mensajes de correo
electrónico
463

Otros mensajes Otros mensajes De forma De forma

predeterminada, predeterminada,
mensajes de correo mensajes de correo
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 No se migran; se pierde el formato.

OLE
Viñetas Se omiten.
465
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
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
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 -nLME-
GWISE -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
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
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
Servicio Enrutador de Exchange para Novell El Conector para Novell GroupWise utiliza un
GroupWise 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
Almacén del conector El almacén del conector, ubicado en el

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\LME-
GWISE\Parameters.
Debe asignar a este parámetro el

valor 0x1. A continuación, Exchange
2003 crea el directorio \Archive en el
programa\Exchsrvr\Conndata\Gwrout
er al reiniciar el servicio Enrutador de
Exchange para Novell GroupWise. El
471
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
• \ATT_IN Recibe archivos de cuerpo de
mensaje y datos adjuntos entrantes de
• \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
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
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
Objeto msExchConnector El objeto msExchConnector del Conector

para Novell GroupWise, que se encuentra en
la partición del directorio de configuración de
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
• 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
• 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

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 <Nombre de organización>/Grupos
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.
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 Mensajes Sí Sí

electrónico
lectura de mensaje lectura de mensaje
Informe de no Informe de no Sí Sí
entrega entrega
Importancia Importancia Sí Sí (la prioridad baja

no está representada
en GroupWise)
Carácter Carácter Sí Sí
478

Exchange Server 2003 GroupWise Exchange Server 2003 a GroupWise
Convocatorias de Citas Sí Sí
reunión
Reunión aceptada Reunión aceptada Sí Sí
Reunión rechazada Reunión rechazada Sí Sí
Reunión aceptada Reunión aceptada Aparece como Aparece como

provisionalmente aceptada aceptada
lectura de lectura de
reunión reunión
Entrega de Entrega de Sí Sí
reunión reunión
Actualizaciones de Actualizaciones de Aparecen como Aparecen como

reuniones reuniones nuevas convocatorias nuevas convocatorias
de reunión que de reunión que
contienen la palabra contienen la palabra
"Actualizada" en la "Actualizada" en la
línea Asunto línea Asunto
Horas de aviso de Horas de aviso de No No

reunión reunión
Cancelación de Cancelación de No Sí
reunión reunión
Solicitudes de tareas Tareas Las solicitudes de Las tareas aparecen

tareas aparecen como
como mensajes de mensajes de correo
correo electrónico electrónico
479

Exchange Server 2003 GroupWise
Group Exchange Server 2003 a GroupWise
Convocatorias de Convocatorias de Sí Aparecen como

reunión con una reunión convocatorias de
duración de todo el reunión; no obstante,
día 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 No

mensajes de correo
electrónico
Otros mensajes Otros mensajes De forma De forma

predeterminada, predeterminada,
mensajes de correo mensajes de correo
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 No se migran; se pierde el formato.

OLE
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.
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 ExcExchange
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úmeronú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.
9. El legacyDN del usuario se convierte en "hash" y su resultado
resultado se divide por el número de
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
dee 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 USUARIO-
USUARIO
/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-22 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
494
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
• 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 calendarioio 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 cicloo de sincronización
de directorios, de forma que
Calsync.dll pueda crear
elementos de disponibilidad para
495
Complemento Conector de calendario de El complemento Conector de calendario de

Exchange 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
Objeto msExchConnector El objeto msExchConnector del Conector de

calendario, que se encuentra en la partición
del directorio de configuración de
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
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

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 <Nombre de
organización>/Grupos
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 quee 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
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
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
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
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

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-Server-
ActiveSync, 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.
• 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
dee 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 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.
• endpoint especifica el puerto TCP/IP en el que el proceso del servidor RPC escucha
para detectar llamadas RPC.
• HttpProxyespecifica 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.
• RPCProxy 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).
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
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
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
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
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
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:
Puede ver una representación semi-gráfica
semi gráfica de la información de configuración de
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-Server-
ActiveSync/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. UnaUna 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>/<buzón>. 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 <buzón> 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 <buzón> 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
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
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 Especifica el directorio virtual

geVDir empiece por / 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 1 o nada Si esta clave está establecida

RegionalCharset 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.
MSExchangeWEB\OWA\UseI 1 o nada Cuando está establecida en

SO8859_15 '1', se utiliza el juego de
caracteres iso-8859-15 allí
donde se utilizaría iso-8859-
1.
544
Clave Valor Descripción
MSExchangeWEB\OWA\Use 1 o nada Cuando está establecida en

GB18030 '1', se utiliza el juego de
caracteres GB18030 allí
donde se utilizaría GB2312.
MSExchangeOMA\Performan N/D Utilizada para publicar los

ce objetos y contadores de
rendimiento de Outlook
Mobile Access.
Outlook Mobile Access y Web.Config

En la sección <browserCaps> 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
<appSettings> <add Define el número de minutos

key="CredentialsTimeout" que Outlook Mobile Access
value="60"></add> conserva los vales Kerberos
en la memoria caché para el
acceso a DAV y a las
plantillas de Outlook Web
Access.
<add Define el número máximo de

key="DefaultConnectionLimit" conexiones simultáneas que
value="500"></add> Outlook Mobile Access
puede abrir en un servidor de
servicios de fondo.
545
<add Indica a Outlook Mobile

key="MaxServicePointIdleTi Access cuántos milisegundos
me" value="60000"></add> debe esperar para las
respuestas procedentes del
servidor de servicios de
fondo antes de que se agote
el tiempo de espera.
<add Cuando se define este

key="UnsupportedMessage" mensaje, se muestra texto
value="http://<server>/OMAD adicional en la advertencia
evices"></add> de incompatibilidad y en las
páginas de errores de
incompatibilidad. Esta clave
es nula de forma
predeterminada.
<system.web> <sessionState Especifica la configuración

mode="InProc" del estado de sesión utilizada
cookieless="true" por Outlook Mobile Access.
timeout="20" /> 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.
<mobileControls Especifica cuántas páginas

SessionStateHistorySize="8" 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).
<globalization Define el juego de caracteres

requestEncoding="utf-8" predeterminado que Outlook
responseEncoding="utf-8" /> Mobile Access utiliza para
enviar respuestas HTTP e
interpretar las solicitudes de
entrada que no tienen un
juego de caracteres
especificado.
546
<browserCAPs> 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 Establece
e 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 Indica a Outlook Mobile

LocalSrc 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.
• 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
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 datodatoss 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:
• <Prefijo de registro>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
• <Prefijo de registro>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 <Prefijo de
registro>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 quee 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 ded 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
dee 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:
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\<NOMB
RE SERVIDOR>\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 Estándar: 1-75 Estándar: 18

in GB 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 1 - 100 10

Buffer Warning in
Percentage
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 1 - 24 5 Determina la

Check Start hora en la que
Time in Hours tendrá lugar la
from Midnight 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 16 GB No aplicable

SP2
Standard Edition con SP2 75 GB 18 GB
Enterprise Edition anterior a 8.000 GB (ilimitado) No aplicable

SP2
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 todastodas 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 Administra el almacenamiento de información

Exchange 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 Procesa la información de enrutamiento de

Exchange mensajes y de estado de vínculos de
Exchange.
Servicio de replicación de sitios de Microsoft Replica la información de Exchange en la

Exchange organización.
Servicio Operador de sistema de Microsoft Supervisa Exchange y proporciona servicios

Exchange esenciales.
Protocolo de transferencia de noticias a Transporta los mensajes de grupos de

través de la red (NNTP) noticias por la red.
Protocolo simple de transferencia de correo Transfiere los mensajes de correo electrónico

(SMTP) 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
Archivos de
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
• 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 non-
IPM_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
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 Un mensaje de replicación de Replica los cambios en la

jerarquías (0x2) jerarquías es un mensaje de jerarquía desde un almacén
replicación entre réplicas de de carpetas públicas a todos
una carpeta especial con el los demás almacenes de
Id. 1-1 (FID 1-1). carpetas públicas en la
misma jerarquía de nivel
superior.
Mensajes de replicación de Los mensajes de replicación Replica los cambios de

contenido (0x4) de contenido replican las contenido desde una réplica
actualizaciones de contenido a todas las demás réplicas
entre réplicas de carpetas de contenido de esa carpeta.
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.
583
Mensajes de solicitud de La reposición es el proceso Los mensajes de solicitud de

reposición (0x8) mediante el cual los reposición solicitan los datos
almacenes de carpetas que faltan (en CNSet) a otro
públicas a los que les faltan almacén de carpetas
actualizaciones de públicas (de jerarquías y de
replicación pueden solicitar contenido). Los mensajes de
un reenvío de los datos que solicitud de reposición sólo
faltan. El proceso de se envían a otras réplicas de
reposición se compone de contenido de la carpeta (a
dos partes: la solicitud de todos los miembros de la
reposición y la respuesta de jerarquía de nivel superior, si
reposición. Cuando un se trata de una jerarquía).
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.
584
Mensajes de respuesta de Las respuestas de reposición Los mensajes de respuesta

reposición (0x80000002 o tienen una estructura idéntica de reposición envían los
0x80000004) a sus equivalentes estándar, datos que faltan a un
pero se envían en respuesta almacén de carpetas
a una solicitud de reposición públicas que solicita
y sólo se dirigen al actualizaciones que faltan
solicitante. Contienen los (CNSet).
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.
585
Mensajes de estado (0x10) Un mensaje de estado se Envía los CNSet actuales de

envía en respuesta a una una carpeta a otra réplica de
solicitud de estado. Contiene esa carpeta. Se utiliza para
el CNSet completo de los las jerarquías (réplicas de
cambios con propietario en carpeta 1-1) y para el
este servidor. Este conjunto contenido (replicas de
no representa contenido específico).
necesariamente todos los
cambios que se han
producido realmente, ya que
puede que no todos los
cambios se repliquen en este
públicas 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
Mensajes de solicitud de Envía el CNSet actual de la El almacén de Exchange

estado (0x20) carpeta a todas las demás envía un mensaje de solicitud
réplicas. Al mismo tiempo, de estado en las siguiente
solicita que algún situaciones:
subconjunto de esas réplicas • Faltan mensajes de
devuelva sus propios CNSet. replicación en una réplica
Esta respuesta llega como un existente de una carpeta
mensaje de estado. El pública o puede que
servidor de destino no estos mensajes se hayan
responde si el CNSet del restaurado desde una
servidor de origen no es un copia de seguridad
subconjunto estricto del obsoleta. Un almacén de
conjunto del servidor de carpetas públicas envía
destino. 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
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 12 horas 24 horas

reposición
Siguientes reintentos de la 24 horas 48 horas

reposición
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 - 15 minutos Éste es el valor

Siempre 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 5 minutos Indica la frecuencia con la

de carpetas que el almacén de carpetas
públicas comprueba si es
necesario enviar un mensaje
de replicación de jerarquías.
594

predeterminado
Envío de replicación - Tiempo 24 horas Indica la frecuencia con la

de espera de estado que el almacén de carpetas
públicas comprueba si debe
enviarse un mensaje de
estado para una carpeta.
Tiempo de espera de 5 minutos Indica la frecuencia con la

replicación 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 15 minutos Es el intervalo de tiempo

tiempo de solicitud de antes de enviar una solicitud
reposición de nueva réplica 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 6 horas Es el intervalo de tiempo

tiempo corto de solicitud de antes de enviar una solicitud
reposición de reposición cuando los
datos están disponibles en el
mismo sitio.
Replicación - Intervalo de 12 horas Es el intervalo de tiempo

tiempo largo de solicitud de antes de enviar una solicitud
reposición de reposición cuando los
datos no están disponibles
en el mismo sitio.
Replicación - Tiempo de 12 horas Es el valor de tiempo de

espera corto de solicitud de espera utilizado al reintentar
reposición enviar una solicitud de
reposición cuando los datos
están disponibles en el
mismo sitio.
595

predeterminado
Replicación - Tiempo de 24 horas Es el valor de tiempo de

espera largo de solicitud de espera utilizado al reintentar
reposición enviar una solicitud de
no están disponibles en el
mismo sitio.
Replicación - Reintento de 24 horas Es el valor de tiempo de

tiempo de espera corto de espera que se utiliza al
solicitud de reposición enviar una solicitud de
están disponibles en el
mismo sitio y esta solicitud es
un reintento de una solicitud
de reposición anterior.
Replicación - Reintento de 48 horas Es el valor de tiempo de

tiempo de espera largo de espera que se utiliza al
solicitud de reposición enviar una solicitud de
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 Comentarios
Número límite de carpetas de 20 Número máximo de carpetas

replicación que se pueden empaquetar
en un mensaje de replicación
de jerarquías.
596
Descripción Valor Comentarios
Número límite de carpetas 500 Número máximo de

eliminadas de replicación eliminaciones de carpetas
que se pueden empaquetar
en un mensaje de replicación
de jerarquías.
Número límite de mensajes 100 Número máximo de

de replicación mensajes que se pueden
empaquetar en un mensaje
de replicación de contenido.
Tamaño límite de mensajes 300 KB Tamaño máximo de los

de replicación 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, aasí 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
componentesntes 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, "HOWHOW 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 Varios servidores virtuales

de Microsoft Exchange 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 Activo/activo Máximo de cuatro grupos de

información de Microsoft almacenamiento por nodo.
Exchange
Agente de transferencia de Activo/pasivo Una instancia por clúster;

mensajes 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 Notas
Conector de Exchange para No compatible

Novell GroupWise
Conector de Exchange para No compatible

Lotus Notes
Sucesos de Microsoft No compatible

Exchange
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 Howw 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\<Guid>\
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
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
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 <Nombre del servidor virtual
HTTP>, 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 <Nombre
del servidor virtualHTTP> 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 - (<NombreEVS>), 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.

E 2 K 3 Techref

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

E 2 K 3 Techref

Enviado por

Direitos autorais:

Formatos disponíveis

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

Guía de referencia técnica de

Introducción a la Guía de referencia técnica de Exchange Server 2003 ............................... 17

Introducción a la Biblioteca técnica de Exchange Server 2003 ............................................ 20

Exchange Server 2003 como sistema de tratamiento de mensajes ..................................... 21

Integración de directorios .................................................................................................... 24

El transporte de mensajes ................................................................................................... 28

El almacén de mensajes de Exchange ................................................................................ 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

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

Exchange Server 2003 y Active Directory ............................................................................ 76

Integración de directorios y Exchange Server 2003 ............................................................. 77

Proxy del servicio de directorio (DSProxy) ......................................................................... 102

El categorizador SMTP ..................................................................................................... 110

Servicio de actualización de destinatarios y Exchange Server 2003 .................................. 113

Servicio de actualización de la metabase .......................................................................... 116

Arquitectura del Administrador del sistema de Exchange................................................... 117

Integración con Microsoft Management Console ............................................................... 118

Administración de la información de configuración en Active Directory .............................. 142

Administración de recursos de almacén de Exchange ....................................................... 154

Cómo mostrar toda la información obtenida de un almacén de buzón o almacén de carpetas

Cómo conectar a un servidor de Exchange específico en el Administrador del sistema de

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

Propagación de estado de vínculos ................................................................................... 218

Compatibilidad con Exchange Server 5.5 .......................................................................... 229

Arquitectura de transporte SMTP ...................................................................................... 232

Diseño del servicio SMTP ................................................................................................. 234

Cómo habilitar la característica Habilitar la modificación directa de archivos de metabase en

El motor de cola avanzada ................................................................................................ 259

ºComponentes del transporte SMTP ................................................................................. 269

Controladores de almacén del servicio SMTP ................................................................... 299

Extensiones del protocolo SMTP ....................................................................................... 313

Registro de protocolos, registro de sucesos y seguimiento de mensajes ........................... 327

Cómo habilitar el registro de diagnósticos para el servicio SMTP en el Administrador del

Cómo establecer el nivel de registro de diagnósticos para las categorías de

Cómo habilitar el seguimiento de mensajes en el Administrador del sistema de Exchange 333

Arquitectura de transporte X.400 ....................................................................................... 334

MTA de Exchange en la arquitectura de Exchange Server 2003........................................ 335

Cómo realizar un barrido de la base de datos del MTA ...................................................... 368

Pilas de transporte del MTA y conectores X.400 ............................................................... 377

Conexión de grupos de enrutamiento mediante conectores X.400 ..................................... 412

MTA de Exchange en una organización en modo mixto .................................................... 420

Arquitectura de los conectores de mensajería de puerta de enlace ................................... 426

Arquitectura del conector de EDK ..................................................................................... 427

Cómo abrir un buzón del conector con Mdbvu32.exe ........................................................ 451

Arquitectura del Conector para Lotus Notes ...................................................................... 452

Arquitectura del Conector para Novell GroupWise ............................................................. 467

Arquitectura del Conector de calendario ............................................................................ 484

Servidores virtuales de protocolos de Exchange Server 2003 ............................................ 505

Integración con IIS ............................................................................................................ 506

MAPI y RPC a través de HTTP ......................................................................................... 511

Detalles de los protocolos de Internet ................................................................................ 514

Exchange ActiveSync y Exchange 2003 ............................................................................ 528