Exportar (0) Imprimir
Expandir todo
Expandir Minimizar

La migración y las aplicaciones que no son de Microsoft

 

Última modificación del tema: 2007-12-20

Publicación: 2 de marzo de 2005

Por Ed Beck

Al migrar desde versiones anteriores de Microsoft Exchange Server o Microsoft Windows, puede que algunas aplicaciones que no son de Microsoft no funcionen o no lo hagan correctamente. Este problema suele presentarse debido a uno de los siguientes motivos:

  • Las aplicaciones se basan en los Objetos de datos de colaboración para Microsoft Windows NT Server (CDONTS).
  • Las restricciones de seguridad impiden las aplicaciones el acceso a los recursos necesarios.

En este artículo se explican estos dos escenarios.

Este artículo no contiene ejemplos de código que le ayuden a migrar a aplicaciones que no sean de Microsoft. No obstante, en la sección “Para obtener más información”, que encontrará más adelante en esta página, se ofrecen vínculos a artículos de Microsoft Knowledge Base que contienen esa información. Asimismo, no pretendemos profundizar en los detalles sobre la forma de modificar la configuración de seguridad, pero ofrecemos vínculos a páginas que abordan la configuración de seguridad.

Recientemente he revisado un volumen de información recopilada durante seis meses de casos de compatibilidad de clientes que desarrollaron aplicaciones para Exchange Server. Un 10% de los casos se trataba de clientes que tenían problemas con aplicaciones que no son de Microsoft y que no funcionaban después de actualizar una versión anterior de Windows o Exchange Server. En el 30% de los casos, las aplicaciones no funcionaban (o lo hacían de forma incorrecta) porque utilizaban CDONTS o porque las actualizaciones de seguridad impedían que las aplicaciones tuvieran acceso a los recursos necesarios.

CDONTS se incluyó en Windows NT. CDONTS utiliza SMTP como interfaz de correo electrónico, y suele utilizarse con un script de páginas ASP. El script se ejecuta en un servidor con Microsoft Internet Information Services (IIS) para enviar mensajes de correo sencillos. Aunque CDONTS no es muy sólido, es ligero y fácil de utilizar. Estas características han contribuido en gran medida a su gran éxito.

Cuando se publicó Windows 2000 Server, incluyó Objetos de datos de colaboración para Windows 2000 (CDOSYS) y CDONTS. CDOSYS ofreció a los desarrolladores una API más sólida, pero no obligaba a los desarrolladores a crear aplicaciones que tuvieran que ejecutarse en un equipo con Exchange Server. Windows 2000 Server incluyó CDONTS para mantener la compatibilidad con versiones anteriores.

Microsoft Windows Server 2003 introdujo código administrado y, con él, un empaquetador administrado para CDOSYS. Ese empaquetador administrado se denomina System.Web.Mail.

Windows Server 2003 no incluye CDONTS, por lo que las instalaciones limpias de Windows Server 2003 no contienen CDONTS. No obstante, al actualizar Windows 2000 Server a Windows Server 2003, CDONTS no se elimina. Por lo tanto, una aplicación CDONTS puede ejecutarse en un servidor con Windows Server 2003 si el servidor se actualizó desde Windows 2000 Server, pero no podrá ejecutarse en un servidor con una instalación limpia de Windows Server 2003.

A medida que más personas actualizan Windows NT 4.0 a Windows Server 2003, este problema es menos frecuente. Los usuarios experimentan este problema cuando las empresas de hospedaje web instalan nuevos servidores con instalaciones limpias de Windows Server 2003 y, a continuación, mueven las páginas web de los clientes a los nuevos servidores. Con frecuencia, algunas de las páginas migradas usan CDONTS. La mejor forma de mantener una configuración compatible es actualizar los servidores con Windows 2000 Server a Windows Server 2003.

Instamos a que los desarrolladores conviertan las aplicaciones CDONTS existentes en CDOSYS o, preferentemente, System.Web.Mail. En la sección “Para obtener más información” que encontrará más adelante en este artículo, hemos añadido vínculos a algunos artículos útiles de Knowledge Base.

Es posible que las aplicaciones que no son de Microsoft no funcionen (o no lo hagan correctamente) después de ciertos tipos de actualizaciones porque las nuevas restricciones de seguridad impiden que las aplicaciones tengan acceso a los recursos necesarios. Estas actualizaciones contienen versiones más recientes de Windows, Exchange Server o Microsoft Office, así como la instalación de un service pack.

En estos casos, el desarrollador de la aplicación que no es de Microsoft no ha hecho nada para que una actualización de seguridad cierre la aplicación. Más bien, durante el transcurso de la revisión continua de Microsoft sobre el código fuente, hemos identificado problemas de seguridad potenciales, y los hemos resuelto con actualizaciones y varios service pack. Estos service pack y actualizaciones suelen cerrar rutas en las que se basan aplicaciones que no son de Microsoft. Nos gustaría hacer hincapié en que los desarrolladores de software no están sentados en sus despachos buscando posibles errores en nuestro software. Sus aplicaciones no funcionan (o no lo hacen correctamente) porque no tuvieron acceso a los recursos necesarios después de que una actualización de software cerrara una ruta concreta.

Veamos un ejemplo. Antes del lanzamiento de Exchange 2000 Server Service Pack 3 (SP3), el grupo Todos tenía acceso de lectura a la metabase IIS. Un método común para enviar correo SMTP era pedir que la aplicación consultara el nombre del servidor SMTP predeterminado en la metabase IIS. Este método funcionaba bien porque el grupo Todos tenía acceso de lectura a la metabase IIS. No obstante, Exchange 2000 Server SP3 eliminó el acceso de lectura a la metabase IIS para el grupo Todos, lo que provocó que las aplicaciones que utilizaban los permisos anteriores dejaran de funcionar.

Microsoft trata este problema concreto en un artículo de la Knowledge Base. Dos métodos se centran en asegurarse de que la aplicación se ejecuta bajo una cuenta que dispone de los derechos adecuados para tener acceso a la metabase IIS. En el entorno actual, diseñar los derechos adecuados de la arquitectura de una aplicación es muy importante. Las aplicaciones deben tener los suficientes derechos para tener acceso a los recursos necesarios, pero no más.

No es adecuado ejecutar todas las aplicaciones bajo la cuenta Administradores o permitir el acceso anónimo a todos los recursos. Deberá determinar los recursos que necesita su aplicación, y configurarla para que se ejecute bajo la cuenta que tiene esos derechos.

Hoy en día, lo que genera mayor número de llamadas a soporte técnico sobre configuración de seguridad son los problemas asociados a permisos en el directorio de recogida al utilizar el método sendusingpickup. Para obtener más información sobre la forma de configurar correctamente los permisos para el método sendusingpickup, consulte el siguiente artículo de Microsoft Knowledge Base:

 
¿Te ha resultado útil?
(Caracteres restantes: 1500)
Gracias por sus comentarios
Mostrar:
© 2014 Microsoft