Cola de Exchange & R: Obtenga el mensaje adecuado
Este mes, nuestra cola de intercambio regular & Un columnista está unido por un colaborador invitado para resolver sus problemas más acuciantes de Exchange.
Henrik Walther
Con colaborador invitado George Hinterhofer
Seguimiento de mensajes
P. ¿Puede compartir una sugerencia o dos sobre cómo mensaje de seguimiento? Nos encontramos con la GUI de uso limitado. Nosotros estamos buscando consejos sobre cómo conseguir la información requerida de los registros de seguimiento de mensajes.
**R:**Uso de Windows PowerShell para seguimiento de mensajes es el enfoque preferible. Le da más control sobre los parámetros de consulta y es mucho más rápido. Una línea típica sería:
Get-TransportServer | Get-Messagetrackinglog –sender test@contoso.com –Start "03/18/2012 09:00AM"
Esto sería obtener todos los registros de seguimiento de mensajes de todos los servidores de transporte en su entorno que tienen una dirección de envío de test@contoso.com, 18 de marzo de 2012, a partir a las 9 a.m. Si desea exportar los resultados a uno de sus clientes o usuarios, los resultados de tubería en el CSVcmdlet de exportación:
Get-TransportServer | Get-Messagetrackinglog –sender test@contoso.com –Start "03/18/2012 09:00AM" | Export-CSV –Path c:\temp\messagetracking.csv
¿Quieres excavar en los resultados para solucionar problemas? Añadir el formato listcmdlet para el comando:
Get-TransportServer | Get-Messagetrackinglog –sender test@contoso.com –Start "03/18/2012 09:00AM" | fl
Para facilidad de uso y de sobra escribir mucho, es una buena idea para escribir su propia pequeña función de Windows PowerShell. Esto permite la búsqueda rápida y eficaz. En este ejemplo será buscar registros de todos los servidores de transporte de concentradores, aceptar –sender como parámetro y buscar en las últimas 24 horas por valor de datos:
functionmt {param ($sender) $SDate = (get-date).adddays(-1) get-transportserver | get-messagetrackinglog -sender $sender -start $SDate }
Siéntase libre de adaptar esta función a sus necesidades. También puede poner este fragmento de código en el archivo de PS1 $perfil así obtiene cargado al inicio. Luego de sólo tendría que escribir:
mt –sender test@contoso.com
Versiones de uso de paquetes acumulativos de actualizaciones
P. Hemos oído que podemos utilizar la carpeta de actualizaciones en los medios de origen de instalación de Exchange 2010 para instalar paquetes acumulativos de actualizaciones durante la instalación. ¿Es este exacta?
**R.**Sí, eso es exacto, al menos parcialmente. Puede utilizar el directorio de actualizaciones para instalar un paquete de correspondencia durante una instalación nueva de Exchange 2010 y reducir el tiempo necesario para la instalación. Sólo colocar el archivo .msp en el directorio correspondiente, como se muestra en figura 1.
.jpg)
Figura 1 Agregar el MSP en el directorio de actualizaciones le permite instalar un paquete coincidente.
No intente esto para una instalación de la actualización, como el lanzado a la fabricación del segundo service pack, o el primer service pack para el segundo service pack. Esto no funcionará y se producirá un error en la instalación. Actualizaciones deben realizarse secuencialmente y no puede combinarlos de esa manera. Hay más información en la página de la biblioteca TechNet, "instalar el paquete de actualizaciones más reciente para Exchange 2010."
¿SP1 o SP2?
P. Hemos actualizado nuestros servidores de Exchange 2010 Edge para el segundo service pack. La instalación ha finalizado sin error. Sin embargo, al mirar los números de compilación con Get-ExchangeServer, todavía muestran como 14.1.xx, aka SP1. ¿Qué salió mal aquí?
**R.**Esto es un poco engañoso, pero comportamiento realmente esperado. Una vez que una suscripción perimetral, Microsoft no actualiza los números de compilación como parte del proceso regular de EdgeSync. Si alguna vez necesita rehacer la suscripción completa (por ejemplo, si el certificado utilizado para EdgeSync caduca), verá que los números de compilación se actualizarán así.
Retrasos de permisos
P. Cuando estoy tratando de conceder permisos de buzón de correo completo a un buzón en Exchange 2010, la lista de buzones tarda mucho tiempo para rellenar (desde varios minutos hasta horas). ¿Hay algo que se puede hacer eso?
**R.**Esta es una pregunta común. La razón de la ventana de "Seleccionar cuentas" llenar tan lentamente es consultas LDAP incorrecta. Estamos buscando todos los buzones y aplicar el filtro después. Si estabas buscando un buzón denominado a "Fred", por ejemplo, primero obtendrá una lista de todos los directores de seguridad. Luego comprobaría después para ver si uno de ellos es de Fred. Este proceso es dolorosamente lento, especialmente en instalaciones de gran número de usuarios.
Por suerte lo suficiente, mejoras de seguridad para Microsoft Exchange, o Exchange(SE), decidieron solucionar este problema en el paquete más grande y más reciente para Exchange 2010 Service Pack 2, es decir el paquete acumulativo de actualizaciones 1. El enlace directo a la revisión aquí.
Autenticación integrada
P. Estamos tratando de habilitar la autenticación integrada de Windows para splits Outlook Web App (OWA) para obtener una única inicio de sesión experiencia decente para nuestros clientes internos, Unidos a un dominio. Los clientes tienen acceso a una URL de equilibrado de carga de red (NLB) llamada https://mail.contoso.com.
Hemos desactivado el primer agente de arranque y había habilitada la autenticación integrada de Windows en los directorios virtuales de OWA. Sin embargo, al intentar acceder a https://mail.contoso.com/owa, nos estamos todavía obtener solicita credenciales. Cuando tenemos acceso a las páginas OWA introduciendo directamente una URL de servicio de acceso de cliente (CAS), como https://cas1.contoso.com/owa o https://cas2.contoso.com/owa, nos estamos conectados con ninguna mensajes. Hacer incluso weirder, si escribe la IP resuelve mail.contoso.com, en nuestro caso https://10.1.1.150/owa, nosotros estamos también conectados con ninguna autenticación. ¿Podrían ayudarme?
R. Después de trabajar mi camino hacia arriba y hacia abajo a través de huellas Netmon y violinista, finalmente noté un cambio en los métodos de autenticación utilizado (se pueden ver en violinista) cuando cambié de https://10.1.1.150/owa (trabajando, no preguntar) a https://mail.contoso.com/owa (pedir).
Resulta que al acceder a la IP resuelve, estábamos usando Windows NT LAN Manager para autenticar contra OWA. Cuando se cambia a la NLB nombre de dominio completo, se empezó a utilizar Kerberos para ir contra el CAS.
Un poco más inteligente y cavar uso de – l setspn.exe reveló que alguien ha agregado una entrada de nombre Principal de servicio (SPN) llamada http/mail.contoso.com a una cuenta de equipo totalmente independientes. Este a su vez hicieron los equipos ir para un vale de Kerberos (porque se encontró una entrada correspondiente en Active Directory) y luego presentan el billete al cuadro de CAS. El cuadro de CAS, evidentemente, no tenía idea qué hacer con un vale de Kerberos que emitió algún cuadro completamente diferente, por lo que lanzó un mensaje de autenticación repetidas.
Una vez que se ha eliminado la entrada SPN falsa, autenticación integrada de Windows comenzó a trabajar al instante contra la URL de NLB y el símbolo de autenticación se había ido.
Discordia de descargo de responsabilidad
P. Estamos tratando de crear una regla de transporte para agregar una renuncia a todo el correo saliente. Durante las pruebas, hemos descubierto que las cajas de transporte parecen ignorar la regla. No añade las renuncias deseadas, incluso después de reiniciar todos los cuadros de concentrador para asegurarse de que realmente cargan la regla. Sin embargo, la misma regla funciona como un encanto en nuestro entorno de prueba. ¿Tienes alguna idea?
R. La regla real para realizar esta función parece que se muestra en figura 2.
.jpg)
Figura 2 esta regla iba a agregar una renuncia al final de los mensajes salientes.
Después de comprobar los sospechosos habituales como la replicación, servicio de transporte no consciente de cualquier cambio y así sucesivamente, todo parecía correcto. Luego comprobamos seguimiento ExTRA para capturar un .etl del motor de reglas durante el procesamiento de mensajes de correo electrónico salientes.
El .etl reveló que el servicio de transporte era plenamente consciente de la nueva regla de transporte, pero por algún motivo no reconoce los correos salientes como "saliente". Por alguna razón, ellos fueron tratados como interno.
Seguimiento ulterior reveló el motor de reglas considerado la entrada de "Dominio remoto predeterminado" en los dominios remotos como interno. Por lo tanto, no aplica la regla de exención de responsabilidad.
Mientras estudiando el tema, me di cuenta que dice IsInternal:$ true para el dominio remoto predeterminado. Esto indica a Exchange para tratar todo el correo a un espacio de direcciones * como interna — y por lo tanto no aplica la renuncia. Hemos cambiado hacia el valor predeterminado de false. Ahora las renuncias se aplican correctamente.
.jpg)
.jpg)
Henrik Walther es un Microsoft Certified Master: Exchange 2007 y Exchange con más de 16 años de experiencia en el campo de TI. Trabaja como un arquitecto de tecnología para un Microsoft Gold Certified Partner en Dinamarca y como un escritor técnico de Biblioso Corp. (una empresa norteamericana que se especializa en administrar servicios de documentación y localización). También es un proveedor contratado trabajando en diversos equipos de producto (incluyendo los equipos Exchange y Lync) de Microsoft.
Georg Hinterhofer es un maestro de la certificación de Microsoft para Exchange 2010. Trabaja como ingeniero senior campo premier, centrando únicamente en Microsoft Exchange. Está basado en Austria, cerca de Viena.