Analizador de conectividad remota de Microsoft (ExRCA) | Herramientas de solución de problemas de detección automática | Parte 2#4 | Parte 22#36
En el presente artículo, aprenderemos a conocer la herramienta basada en web ExRCA, también conocida como Microsoft Remote Connectivity Analyzer (MRCA), que sirve como su nombre lo indica para probar y analizar información relacionada con las “relaciones” de diferentes clientes de Exchange con su servidor Exchange.
Analizador de conectividad remota de Microsoft (MRCA)
P: ¿Cuál es el propósito del Analizador de conectividad remota de Microsoft (MRCA)?
R: El Analizador de conectividad remota de Microsoft es en realidad una “colección de herramientas basadas en web” que nos permiten simular el canal de comunicación entre los diferentes clientes de Exchange y un entorno diferente. Por ejemplo, Exchange local frente a Exchange Online y herramientas de solución de problemas adicionales que no tienen vínculos directos y reales con el cliente de Exchange, como la herramienta de análisis de mensajes.
A lo largo de los años, la herramienta basada en web Microsoft Remote Connectivity Analyzer evolucionó hasta convertirse en una herramienta muy útil e “imprescindible”, con la que todo administrador de Exchange local o Exchange Online debería estar familiarizado.
En el artículo actual, aprenderemos a conocer y comprender la interfaz y la lógica de la herramienta Microsoft Remote Connectivity Analyzer, pero es importante enfatizar que usaremos solo una herramienta muy particular de la variedad de herramientas que ofrece Microsoft Remote Connectivity. Incluye analizador.
Nuestro enfoque principal está en la prueba específica denominada: Pruebas de conectividad de Microsoft Office Outlook | Detección automática de Outlook
En el artículo actual, no revisaremos en detalle los detalles del flujo de detección automática que aparecen en los resultados de la prueba de la herramienta Microsoft Remote Connectivity Analyzer, sino que examinaremos solo los conceptos generales como: cómo leer los resultados, la estructura lógica de los resultados de las pruebas, etc.
Detección automática en un entorno de Active Directory versus detección automática en un entorno que no es de Active Directory
vs. una herramienta de solución de problemas de detección automática como la herramienta Autoconfiguración de correo electrónico de prueba de Outlookque sabe cómo "funcionar" en los dos entornos diferentes, la herramienta Microsoft Remote Connectivity Analyzer como su nombre implica (Conectividad Remota), saber inspeccionar y analizar el flujo de Autodiscover que se implementa en un entorno no Active Directory.
En palabras simples, podemos utilizar la herramienta Microsoft Remote Connectivity Analyzer para el escenario de solución de problemas de detección automática en el caso de un "cliente de correo externo" que intenta acceder a un servidor Exchange público.
Infraestructura local de Exchange versus infraestructura de Exchange Online y Office 365
La herramienta Microsoft Connectivity Analyzer se puede utilizar para probar el acceso remoto del cliente de Exchange en un escenario en el que el buzón del usuario está alojado en la infraestructura local de Exchange o en la infraestructura de Exchange Online.
En la siguiente captura de pantalla, podemos ver la interfaz web de la herramienta Microsoft Connectivity Analyzer.
1. Diferentes entornos de Exchange
La prueba que ofrece la herramienta Microsoft Connectivity Analyzer se puede implementar probando un entorno local de Exchange frente a un entorno de Office 365 (Exchange Online).
Podemos ver que las diferentes opciones de prueba están “agrupadas” usando una pestaña diferente.
- A - En la pestaña “Exchange Server”, podemos encontrar todas las pruebas disponibles que se pueden utilizar cuando necesitamos probar los servicios Exchange On-Premise.
- B - En la pestaña “Office 365”, podemos encontrar todas las pruebas disponibles que se pueden utilizar cuando necesitamos probar la infraestructura de Exchange Online.
2. Diferentes tipos de prueba de conectividad remota
En las siguientes capturas de pantalla, podemos ver que la prueba de conectividad de detección automática aparece en la pestaña “Servidor Exchange” (Exchange local).
Por ejemplo, podemos implementar una prueba de conectividad para el cliente de correo Outlook (RPC\HTTPS), ActiveSync (cliente Exchange móvil), etc.
Tenga en cuenta que en la sección “Pruebas de conectividad de Microsoft Office Outlook”, tenemos dos pruebas de conectividad diferentes.
Por ejemplo, existen dos tipos diferentes de pruebas de conectividad de Outlook.
- Detección automática de Outlook: pruebe el flujo y la infraestructura de detección automática implementados por el cliente Outlook.
- Conectividad de Outlook: una prueba "combinada" que incluye la prueba de conectividad remota de detección automática + la prueba de conectividad remota RPC\HTTPS.
3. Herramienta Microsoft Connectivity Remote Analyzer y entorno Office 365
Como se mencionó, la herramienta Microsoft Connectivity Remote Analyzer nos permite probar el entorno de Office 365 y el entorno local de Exchange.
La prueba que se puede implementar en el entorno local de Exchange también existe para el entorno de Office 365, pero la herramienta Microsoft Connectivity Analyzer incluye pruebas adicionales que son relevantes solo para el entorno de Office 365.
Herramienta analizadora de conectividad de Microsoft | Probando diferentes servicios de Exchange
Como se mencionó, la herramienta Microsoft Connectivity Analyzer incluye muchos tipos de "pruebas de Exchange".
Por ejemplo:
- Pruebas de conectividad de Microsoft Office Outlook: una prueba de conectividad que inspecciona la sesión del cliente Outlook que utiliza el servicio Outlook Anywhere. Esta prueba examina el proceso de comunicación completo que se basa en los servicios de detección automática y luego pasa a la "siguiente capa", al proceso de creación del enlace de comunicación RPC\HTTPS.
- Pruebas de conectividad de Microsoft Exchange ActiveSync: nos permiten simular la sesión de conectividad entre clientes móviles que utilizan el protocolo ActiveSync.
En la siguiente captura de pantalla, podemos ver que la "interfaz" del entorno de Office 365 incluye siete pruebas de conectividad diferentes frente a la pestaña Exchange local que incluye cuatro pruebas de conectividad.
4. Otro tipo de pruebas de conectividad
La herramienta Microsoft Remote Connectivity Analyzer incluye una prueba para infraestructuras adicionales de Microsoft, como Lync On-Premise, Lync Online y servicios SSO (inicio de sesión único) como ADFS.
En la siguiente captura de pantalla, podemos ver que hay "pestañas" adicionales al lado de la prueba que se relacionan con Exchange.
5. El “cliente de prueba” Herramienta de análisis de conectividad remota de Microsoft | El “Host” que realiza la prueba
El tema del “Anfitrión que realiza la prueba” es un tema imperativo y un poco confuso.
La herramienta Microsoft Remote Connectivity Analyzer es un servidor público de Microsoft que podemos utilizar para simular el acceso a varios servicios de intercambio como Autodiscover.
Es fundamental que comprendamos los estatutos específicos de la herramienta Microsoft Remote Connectivity Analyzer porque la forma en que Microsoft Remote Connectivity Analyzer Tool realiza la prueba de detección automática no cubrirá todos los escenarios posibles.
Cuando nos enfrentamos a un escenario de solución de problemas de detección automática, no podemos estar seguros de si el problema está relacionado con:
- El escritorio de un usuario en particular desde el cual el usuario intenta acceder al punto final de detección automática.
- Una red particular desde la cual el usuario intenta acceder al punto final de detección automática.
- Un "problema general" en la infraestructura de detección automática que afecta a todos los "clientes de correo externo" que necesitan acceder a su punto final de detección automática.
La herramienta Microsoft Remote Connectivity Analyzer se implementó mediante el uso de un servidor público de Microsoft que realiza las diferentes pruebas de conectividad.
El servidor "Servidor público" para simular sesiones de clientes de Exchange con el servidor de Exchange.
Debemos tener en cuenta el hecho importante de que la prueba de detección automática de la herramienta Analizador de conectividad remota de Microsoft solo se puede utilizar para probar un escenario muy específico, un escenario en el que el cliente de Exchange (cliente de detección automática) se dirige a la "interfaz pública" del servidor Exchange. .
En otras palabras, un escenario en el que el cliente Exchange está ubicado en una red pública y el servidor Exchange está configurado como servidor Exchange público.
La opción de probar el flujo de detección automática desde un "cliente Exchange externo" es adecuada para muchos escenarios, pero en algunos escenarios de solución de problemas de detección automática, necesitaremos realizar la prueba de conectividad de detección automática desde una "dirección diferente".
El significado es: realizar la prueba de detección automática utilizando el escritorio de un usuario en particular o realizar la prueba de detección automática desde una red específica, como la red privada de la organización.
En caso de que queramos realizar la prueba de detección automática desde una red interna o, desde una red específica en la que se encuentra el cliente Exchange, podemos descargar e instalar el - “Cliente Microsoft Connectivity Analyzer”.
En la siguiente captura de pantalla, podemos ver la “pestaña cliente” que podemos usar para descargar: Cliente Microsoft Connectivity Analyzer.
Realización: pruebas de conectividad de Microsoft Office Outlook | Descubrimiento automático de Outlook
Para poder demostrar el uso de la herramienta Microsoft Remote Connectivity Analyzer, optaremos por realizar la prueba de detección automática de Outlook.
Descripción del escenario
Los personajes de nuestro escenario son los siguientes:
El nombre de dominio público de la organización es: o365info.com
Un usuario llamado John que se encuentra en la red pública externa y desea crear un nuevo perfil de correo de Outlook. La dirección de correo electrónico de John es: John@o365info.com
Queremos verificar que el servidor local de Exchange se haya "publicado" correctamente y que esté accesible y disponible para el "cliente externo".
Realizar la prueba de detección automática de Outlook
Para verificar la configuración de detección automática requerida en nuestro servidor Exchange On-Premise, seguiremos los siguientes pasos:
1. Acceda a Microsoft RCA - Herramienta de análisis de conectividad remota utilizando la siguiente URL: https://testconnectivity.microsoft.com/
Un pequeño consejo: si tiene problemas para recordar la “dirección URL completa”, puede abrir cualquier motor de búsqueda y escribir la palabra - ExRCA.
El primer resultado que aparecerá en el resultado de la búsqueda lo “conducirá” a Microsoft RCA: página del Analizador de conectividad remota.
2. Haga clic en la pestaña Servidor Exchange y en Prueba de conectividad de Microsoft Office Outlook, elija la opción - < fuerte>Detección automática de Outlook
3. En la esquina inferior derecha, haga clic en la opción Siguiente
En la siguiente pantalla, necesitaremos proporcionar las “credenciales de usuario”.
Las credenciales utilizadas por ExRCA para "suplantarse a sí mismo" ante un cliente de Exchange, intentar conectar el servidor local de Exchange, completar el proceso de detección automática y obtener la respuesta de detección automática requerida.
1. Dirección de correo electrónico: ingrese la dirección de correo electrónico del destinatario. En nuestro escenario, la dirección de correo electrónico del destinatario es: John@o365info.com
2. Dominio \Nombre de usuario (o UPN): en este cuadro debemos proporcionar el Active Directory local o las credenciales de usuario del dominio. La mayoría de las veces, la “convención estándar” se basa en el formato de -
(Para ser más precisos, solo la parte izquierda del nombre de dominio interno de Active Directory).
En caso de que la cuenta de usuario de Active Directory local también se haya configurado con un sufijo de nombre de dominio público, la autenticación se puede realizar utilizando la convención de nomenclatura UPN (nombre principal de usuario). Por ejemplo: John@o365info.com
En nuestro escenario usaremos la convención de nomenclatura estándar: o365info\john
3. Contraseña: esta es la "contraseña de usuario del dominio", es decir, la contraseña que utiliza el usuario cuando inicia sesión en el dominio corporativo.
4. Aprobación de la prueba de detección automática: elija la opción de:
Entiendo que debo usar las credenciales de una cuenta funcional de mi dominio de Exchange para poder probar la conectividad con él de forma remota. También reconozco que soy responsable de la administración y seguridad de esta cuenta.
Este es un requisito obligatorio.
Al elegir esta opción, aprobamos que "confiamos en Microsoft" (le proporcionamos al servidor ExRCA nuestro "secreto", las credenciales de usuario del dominio privado).
5. Verificación: necesitaremos completar el proceso de verificación volviendo a escribir las letras que aparecen (así es como Microsoft verifica que somos un factor humano y no un código malicioso).
Para completar el proceso, haga clic en < botón fuerte verificar
En la siguiente captura de pantalla, podemos ver que el proceso de verificación se completó con éxito.
Para iniciar la prueba de detección automática, haga clic en la opción Siguiente
Análisis de los resultados de la prueba de detección automática de Outlook
Esta es la parte en la que ExRCA "brilla".
Sé que puede sonar "geek", pero creo que ExRCA está haciendo un excelente trabajo al presentar los "hallazgos" de una manera muy clara y "humana". -como "forma".
Por mi parte, he resuelto muchos "problemas de detección automática" utilizando estas herramientas que me brindan información clara e informativa sobre el proceso de detección automática.
RCA: estructura y lógica de resultados de la herramienta de análisis de conectividad remota
A primera vista, el resultado que proporciona la herramienta Analizador de conectividad remota parece un poco confuso. Por esta razón, es importante que comprendamos la forma en que ExRCA utiliza para mostrar los resultados.
Un proceso de detección automática consta de varias partes.
Los resultados incluyen una parte dedicada para cada una de las "partes" o "pasos" involucrados en el proceso de detección automática.
Al inicio de cada “sección”, podemos ver la tarea y el resultado (éxito o fracaso) y debajo del encabezado, podemos ver una descripción detallada de cada uno de los “subpasos” que se implementaron y el resultado (éxito o fracaso). falla).
Interfaz de resultados ExRCA
Esta parte en la que repasamos “cómo leer” los resultados mostrados de la prueba de conectividad ExRCA Autodiscover puede parecer “innecesaria”, pero a pesar de que todos saben cómo utilizar el resultado, es importante dedicar un minuto a comprender la forma en que Se muestran los resultados ExRCA.
Debido a que el proceso o flujo de detección automática puede ser relativamente sencillo o contener una enorme cantidad de información, ExRCA utiliza el método de "expandir y contraer".
La lógica se basa en un “concepto de Jerarquía” comenzando con el “primer nivel” de información y la capacidad de visualizar (ampliar) cada uno de los subprocesos o pruebas que se implementaron en la prueba Autodiscover.
Una metáfora que podemos utilizar es la “babushka rusa”.
La primera “babushka” puede estar abierta y dentro, podemos encontrar otra babushka cuando abrimos la babushka que está dentro, podemos sacar otra babushka y así sucesivamente.
La misma lógica implementada en el resultado de la prueba ExRCA Autodiscover.
Cada uno de los pasos se puede ampliar para que podamos ver el contenido de los pasos adicionales que se incluyen en el “paso padre” y así sucesivamente.
Para demostrar el "concepto de jerarquía" de la interfaz de resultados de ExRCA, usemos un ejemplo de resultados de pruebas de detección automática de ExRCA que simulan el acceso de detección automática a un servidor Exchange CAS público local.
Nivel 1
En este nivel, podemos ver una “respuesta clara” para los Resultados ExRCA. En nuestro ejemplo, la prueba se completa con éxito.
Nivel 2
Al elegir la opción - "expandir" en Pasos de prueba, podemos ver un "nivel adicional" de información.
En nuestro ejemplo, podemos ver que la prueba de detección automática se inició buscando el host llamado o365info.com y el resultado es: fallo.
La siguiente prueba de detección automática se realizó utilizando el host denominado
autodiscover.o365info.com y el resultado es: Éxito
Nivel 3
El siguiente nivel (“Nivel 3”) es el nivel en el que podemos revisar todos los pasos que se incluyen en el flujo de detección automática.
En el siguiente diagrama podemos ver la lógica de los resultados mostrados.
En la siguiente captura de pantalla, podemos ver una breve descripción de cada uno de los pasos que se incluyen en el proceso de detección automática.
Paso 1: descrito como: Intentar resolver los nombres de host autodiscover.o365info.com en DNS.
Paso 2: descrito como - Probar el puerto TCP 443 en el host autodiscover.o365info.com para garantizar que esté escuchando y abierto”.
Paso 3: descrito como: Probar el certificado SSL para asegurarse de que sea válido.
Paso 4: descrito como: Verificar la configuración de IIS para la autenticación del certificado del cliente.
Paso 5: descrito como: Intentar enviar una solicitud POST de detección automática a posibles URL de detección automática.
Nivel 4
Este es el "nivel más profundo" de información que nos permite analizar con mayor profundidad el paso de detección automática en particular.
En el siguiente ejemplo, hemos ampliado los pasos de "Resolución de nombres" en los que el cliente de detección automática accede al servidor DNS y solicita la dirección IP del punto final de detección automática.
En nuestro escenario, podemos ver que la dirección IP que regresó al cliente es: 212.25.80.239 y, el tiempo de “ida y vuelta” que tomó completar el proceso es: 221 ms
Un flujo de descubrimiento automático: mezcla de eventos de éxito y fracaso | Revolviendo el misterio
Uno de los problemas más confusos en un flujo de detección automática estándar puede describirse como la combinación de eventos de éxito y fracaso.
Un problema confuso adicional es el resultado de ExRCA que puede describirse como “Prueba de conectividad exitosa con advertencias. "
La “confusión” es que no está claro si la prueba se completó con éxito o no. En otras palabras, no hay opción de obtener una respuesta clara en blanco o negro.
Al mirar la captura de pantalla, podemos ver que el ícono del resultado de la prueba es verde, pero al mismo tiempo podemos ver que vemos un ícono amarillo con un signo de exclamación.
Entonces, la pregunta más obvia es: ¿es bueno o malo?
¿Podemos entender que nuestra infraestructura de detección automática está configurada correctamente o necesitamos solucionar algunos problemas?
La respuesta simple es: "Sí, esto es bueno".
El motivo de la notificación: "Prueba exitosa con advertencias" es que el proceso de detección automática se basa en un concepto de prueba y error.
Mientras busca el "resultado final", el cliente de detección automática está programado para ejecutar un par de métodos y el 99% de las veces, algunos de estos "métodos" o pruebas fallarán.
Lo que importa es el "resultado" que responde a la pregunta: ¿el cliente pudo o no encontrar la "respuesta", es decir, la respuesta de detección automática?
El motivo del icono amarillo con un signo de exclamación es el siguiente:
1. Dominio raíz
La causa más popular del resultado: "Prueba exitosa con advertencias" es que, de forma predeterminada, el cliente de detección automática está programado para buscar el punto final de detección automática "extrayendo" el nombre de dominio del correo electrónico del destinatario. dirección de correo electrónico (la "parte derecha" que incluye el nombre de dominio SMTP del destinatario) y cree una consulta DNS utilizando el "nombre de dominio" como nombre de host.
Por ejemplo, en el caso de que el nombre del destinatario sea - John@o365info.com, el cliente de detección automática, como Outlook, creará una consulta DNS buscando el nombre de host - o365info.com
La mayoría de las veces, este método fallará, porque es un escenario muy raro en el que el nombre de dominio público de la organización esté "asignado" en el DNS para la dirección IP del servidor Exchange.
El resultado es que la mayoría de las veces el primer paso del proceso de detección automática aparecerá como "fallido".
En términos generales, el método de “buscar el nombre de host del punto final de detección automática utilizando el nombre de dominio raíz” puede incluso causar problemas menores o mayores.
En caso de que la organización utilice un sitio web público y además asigne la dirección del nombre de dominio del sitio web, el cliente de detección automática obtendrá una "respuesta positiva" del DNS con respecto a la dirección IP del nombre de dominio raíz. Cuando intenta comunicarse con el "Punto final de detección automática aparente" mediante HTTPS, la comunicación fallará.
Entonces, aparte del tiempo que se dedica a implementar este método, no hay ningún daño.
En menos escenarios buenos, en caso de que el "host de destino" (el sitio web) tenga un certificado problemático, como un certificado que indique que su fecha expiró, etc., el cliente de detección automática detendrá el proceso de detección automática porque el cliente de detección automática "entiende" que Hay un problema con el punto final de detección automática.
Para ser honesto, creo que el método de detección automática de “buscar el nombre de host del punto final de detección automática usando el nombre de dominio raíz” debería eliminarse porque, por mi parte, no veo ninguna ventaja en usar este método.
Un ejemplo de búsqueda del nombre de host del punto final de detección automática utilizando el nombre de dominio raíz
En la siguiente captura de pantalla, podemos ver un ejemplo de los resultados de la prueba ExRCA:
El cliente de detección automática conecta el servidor DNS buscando la dirección IP del nombre de dominio raíz (o365info.com en nuestro ejemplo), obtiene la dirección IP del nombre de host-
Intentando resolver el nombre de host o365info.com en DNS. El nombre del host se resolvió correctamente. Direcciones IP devueltas: 104.28.12.85, 104.28.13.85
Cuando el cliente de detección automática intenta verificar si el host está "listado" para la comunicación HTTPS, la prueba falla porque el host de destino no puede comunicarse mediante HTTPS.
Los resultados en ExRCA aparecen como-
Probando el puerto TCP 443 en el host o365info.com para garantizar que esté escuchando y abierto. El puerto especificado está bloqueado, no escucha o no produce la respuesta esperada.
2. Cadenas de certificados
Una razón adicional para el resultado de - “Prueba exitosa con advertencias” es el proceso que se describe como - “prueba de las cadenas de certificados”
El cliente de Autodiscover, solicita al Autodiscover Endpoint probar su identidad, proporcionando un certificado.
La infraestructura de certificados públicos se basó en un concepto jerárquico.
El certificado de servidor público proporcionado por una “autoridad superior” y, muchas veces, la “autoridad superior” es un subordinado de una “autoridad superior” adicional.
En este escenario, hay al menos "dos elementos" involucrados: el elemento que proporciona el certificado (descrito como CA-Autoridad de certificación) y el "cliente que usa el certificado" (servidor Exchange, por ejemplo).
Parte de la prueba de seguridad que realizará el cliente Autodiscover es: verificar el "elemento" que proporciona el certificado, es decir, la CA y el certificado de CA.
La capacidad del cliente de detección automática de verificar el certificado de CA se basa en la suposición de que la CA es "bien conocida" y que el cliente (el cliente de detección automática) tiene el certificado de CA en su almacén de certificados.
Cuando realizamos la prueba de detección automática utilizando la herramienta ExRCA, incluso cuando la fase de - “probar las cadenas de certificados” se completa con éxito, la herramienta ExRCA nos notifica que el hecho de que “él” (el ExRCA), logra verificar el certificado cadenas. Esto no significa que un "escritorio de usuario" también logrará completar con éxito la prueba de las cadenas de certificados porque dependen del almacén de certificados de escritorio en particular.
Al mirar los resultados de la prueba ExRCA, podemos ver este tipo de notificación:
Analizando las cadenas de certificados para detectar problemas de compatibilidad con versiones de Windows. Posibles problemas de compatibilidad identificados con algunas versiones de Windows. Detalles adicionales
El Analizador de conectividad de Microsoft solo puede validar la cadena de certificados utilizando la funcionalidad de actualización del certificado raíz de Windows Update. Es posible que Windows no confíe en su certificado si la función "Actualizar certificados raíz" no está habilitada.
Solo para resumir, a pesar de que la fase de detección automática de prueba de las cadenas de certificados aparece con un signo de exclamación amarillo, el problema no es un problema y no hay nada que podamos hacer para evitar que esta información aparezca en los resultados de la prueba de detección automática. .
Guardar los resultados de la prueba ExRCA para su posterior análisis
El resultado de la prueba que obtenemos al usar la herramienta ExRCA se puede usar para análisis en tiempo real o para enviar los datos a un equipo de soporte técnico (como el equipo de soporte de Office 365) para un análisis continuo.
La herramienta ExRCA, nos permite guardar el resultado de la prueba de Autodescubrimiento, utilizando tres opciones diferentes:
1. Copiar al portapapeles
Esta opción copiará el resultado de la prueba ExRCA al portapapeles del escritorio local usando un formato XML. Personalmente, prefiero el otro método, como guardar el resultado de la prueba de detección automática en formato HTML porque la lectura del resultado es mucho más clara.
2. Guarde el resultado en un archivo HTML
Este es mi método preferido. La opción de guardar el archivo HTML del resultado de la prueba ExRCA es idéntica al resultado que aparece en la pantalla. El uso de los íconos verdes y rojos, no permite encontrar el "área de problemas" muy fácilmente y, además, la opción de "expandir y contraer" nos permite navegar a través de los datos con mucha facilidad.
3. Guarde el resultado en un archivo XML
La posibilidad de guardar los datos en formato XML es interesante porque al utilizar la opción XML, podemos utilizar herramientas como Microsoft Excel para “presentar” los datos en un formato personalizado.
En caso de que guardemos el resultado de la prueba ExRCA Autodiscover en un formato de archivo XML y usemos Excel para abrir el archivo XML, aparecerá el siguiente mensaje: “seleccione cómo desea abrir este archivo. "
Elegiremos la opción de - Como tabla XML
En la siguiente ventana emergente, haga clic en Aceptar.
En la siguiente captura de pantalla podemos ver los resultados.
Excel "sabe" cómo poner los datos XML en un formato de tabla y podemos usar la opción de Excel, como Filtro, para mostrar u ocultar "datos" específicos. "
Una opción adicional es abrir el archivo XML usando un editor de texto avanzado como Notepad++.
En la siguiente captura de pantalla, podemos ver el resultado de abrir un archivo XML con Notepad++. Podemos ver que el editor de texto "entiende" el formato XML particular y muestra los datos usando un color, jerarquía de etiquetas XML, etc.
