Esos errores 8197 de Free/Busy
Esos errores 8197 de Free/Busy
Por: Patricia Reyes
Le reportan errores 8197 en el Log de Aplicación cada 25 minutes?
Como el siguiente ejemplo:
Event Type: Error
Event Source: MSExchangeFBPublish
Event Category: General
Event ID: 8197
User: N/A
Computer: servername
Description: Error initializing session for virtual machine US-VS1. The error number is 0x80040111
Una razón muy común de este error es la tarea del fondo que hace las encuestas a la carpeta de sistema de free/busy para procesar actualizaciones no puede unirse al servidor catalogo global(GC).
Esta tarea de free/busy no utiliza el mecanismo de DSACCESS como la mayoria de los procesesos de Exchange para localizar los GC’s.
“DSACCESS & Windows referral “ usan un algoritmos diferentes para determinar el orden de preferencia de los GC’s y tareas de free/busy, por eso algunas veces no usan el mismo GC que la mayoría los procesos de Exchange.
Es por eso que esta tarea tiende a fallar aun cuando Exchange este funcionando normalmente. Para investigar estos errores se deben seguir los siguientes pasos.
1. Determine que Global Catalog el hilo de free/busy esta tratando de unirse. Esta información puede ser encontrada dentro del registro la cual se puede observar solo cuando el "System Attendant" esta ejecutándose.
HKEY_USERS\.DEFAULT\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\ExchangeAdmin<server name> <some GUID>
Notese que la llave del registro arriba mencionalda es diferente de:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Exchange\Exchange Provider\DS
Esta llave algunas veces es configurada estáticamente para que DSACCESS use cierto Domain Controller o Global Catalog. En ocasiones esta llave a sido configurada erróneamente para descartar problemas de conectividad a GC’s. Esto es solo relevante para acceso a directorio que envuelve el componente de DSACCESS. Ya una ves que se estableció que GC esta usándose para la tarea de free/busy, siga el troubleshooting general de conectividad de red para asegurarse que este GC este respondiendo y funcionando normalmente.
2. Si el GC esta respondiendo y todo funciona normalmente, verifique que no tenga entradas erróneas (una causa muy común de los errores 8197).
Para verificarlo ejecute el siguiente commando desde un ventana de DOS:
ldifde -f output.ldf -d "dc=mydomain,dc=com" -t 3268 -p subtree -r "(&(objectclass=*)(name=myserver))”
Por supuesto substituya el nombre de su server por "myserver" y el nombre de su dominio por "mydomain". El resultado será guardado en el archivo output.ldf como el siguiente ejemplo:
dn: CN=MYSERVER,CN= Computers ,DC=mysubdomain,DC=mydomain,DC=com
…
distinguishedName: CN=MYSERVER,CN=Computers,DC=na,DC=mydomain,DC=com
En muchos casos reportados se a encontrado que la causa común del problema a sido entradas invalidas de servidores o GC’s encontrados en unidades organizacionales incorrectamente. Por ejemplo; domain controllers o global catalogs debe de residir en la unidad organizacional de “domain controllers” dentro de Active Directory, en muchas de estas ocasiones se encontraron GC’s en la unidad organizacional “computers”.
dn: CN=MYSERVER,OU= Domain Controllers ,DC=mydomain,DC=com
…
distinguishedName: CN=MYSERVER,OU=Domain Controllers,DC=mydomain,DC=com
Cuando las 2 entradas existen la buena como la mala dentro de "Active Directory", las búsquedas de DNS" de myserver reciben la respuesta incorrecta y cualquier atentado de unirse a "myserver" fallaria. Para resolver este problema simplemente remueva la entrada incorrecta y ejecute "flush dns". Este tipo de entradas incorrectas generalmente son creadas cuando se instala un servidor en un dominio como un sub-domain como "member server" y luego este es promovido a DC/GC en otro dominio diferente.
Si estos errores aun persisten en el lóg. de aplicación después de hacer el paso 1 y 2 es muy posible que tenga un problema diferente. Otra razón común de los errores 8197 es cuando se instala el cliente Outlook en el servidor de Exchange. Esto no debe de hacerse ni como prueba para no tener conflictos entre las versiones de las librerías de Exchange y Outlook (mapi32.dll, emsabp32.dll and emsmdb32.dll).
Como una nota adicional "Exchange Mailbox Manager" también usa el mismo algoritmo que free/busy utiliza para localizar los GC's. Usualmente cuando la tarea de free/busy falla reporta los errores 8197, "Mailbox Manager" reporta los errores siguientes:
Event Type: Error
Event Source: MSExchangeSA
Event ID: 9175
Description: The MAPI call 'OpenMsgStore' failed with the following error:
The information store could not be opened.
The logon to the Microsoft Exchange Server computer failed.
MAPI 1.0 ID no: 80040111-0286-00000000
Event Type: Error
Event Source: MSExchangeSA
Event Category: Mailbox Management
Event ID: 9200
Description: Failed to perform MAPI logon.
No es una sorpresa pero instalar Outlook en el Servidor de Exchange afecta “Mailbox Manager” también.
Cual es la razon poque diferentes componentes de exchange usan mecanismos separados para localizar los servidores o catalogo globales en directorio activo?
La intencion de Microsoft fue: instalar la consola de administracion de Exchange(ESM) en computadores sin los servicios de Exchange o independientes del componente de "Directory Access".
De esta forma algunos procesos de "Free/Busy" fueron desarrollados para usar el mecanismo de localización del GC que existe dentro del propio sistema operativo.
Usted debe de estar preguntándose por que todos los componentes no usan el mismo mecanismo de localización de GC's del sistema operativo. La respuesta es simple: por cuestiones de rendimiento.
Si los componentes de Exchange usaran los mismos mecanismos para localizar los GC's el rendimiento no seria optimo.
El componente de "Directory Access" esta optimizado para hacer las consultas de Exchange a Active Directory, y guarda en “cache” los resultados de esas consultas. El tenerlo en “cache” aumenta el rendimiento de Exchange substancialmente y reduce la carga de los servidores DC/GC's.
Patricia Reyes
Fuente utilizadas: https://blogs.technet.com/exchange/archive/2005/07/29/408394.aspx