(0) exportieren Drucken
Alle erweitern
Erweitern Minimieren

Nicht von Microsoft stammende Anwendungen und Migration

 

Letztes Änderungsdatum des Themas: 2007-12-20

Veröffentlicht: 02. März 2005

Von Ed Beck

Bei der Migration von früheren Versionen von Microsoft Exchange Server oder Microsoft Windows ist es möglich, dass manche nicht von Microsoft stammende Anwendungen nicht mehr oder nicht mehr korrekt funktionieren. Dieses häufig auftretende Problem hat eine der folgenden Ursachen:

  • Die Anwendungen wurden basierend auf Collaboration Data Objects für Microsoft Windows NT Server (CDONTS) erstellt.
  • Aufgrund von Sicherheitsbeschränkungen konnten die Anwendungen nicht auf die erforderlichen Ressourcen zugreifen.

Im vorliegenden Artikel werden diese beiden Szenarien erläutert.

In diesem Artikel sind keine Codebeispiele für die Migration von nicht von Microsoft stammenden Anwendungen enthalten. Allerdings finden Sie im Abschnitt "Weitere Informationen" weiter unten auf dieser Seite Links zu Microsoft Knowledge Base-Artikeln, die Aufschluss darüber geben. Außerdem wird nicht detailliert auf das Ändern von Sicherheitseinstellungen eingegangen. Aber auch hierzu finden Sie Links zu weiteren Informationen.

Kürzlich habe ich die Supportfälle der letzten sechs Monate geprüft, bei denen es um Kunden geht, die Anwendungen für Exchange Server entwickeln. In zehn Prozent der Fälle hatten Kunden Probleme mit nicht von Microsoft stammenden Anwendungen, die nach dem Upgrade von einer früheren Version von Windows oder Exchange Server nicht mehr funktionierten. In 30 Prozent der Fälle funktionierten die Anwendungen nicht mehr oder nicht mehr korrekt, da die Anwendungen CDONTS verwendeten oder aufgrund von Sicherheitsupdates nicht auf die erforderlichen Ressourcen zugreifen konnten.

CDONTS ist ein Bestandteil von Windows NT. CDONTS nutzt SMTP als E-Mail-Schnittstelle und wird normalerweise mit einem ASP-Skript (Active Server Pages) verwendet. Das Skript wird auf einem Server ausgeführt, auf dem Microsoft-Internetinformationsdienste (IIS) zum Senden einfacher E-Mail-Nachrichten verwendet wird. CDONTS ist zwar nicht sehr stabil, dafür aber einfach und benutzerfreundlich. Diese Merkmale haben maßgeblich zum Erfolg dieser Technologie beigetragen.

Mit Windows 2000 Server zusammen wurde Collaboration Data Objects für Windows 2000 (CDOSYS) und CDONTS veröffentlicht. Entwickler erhielten mit CDOSYS eine stabilere API, aber es war nicht erforderlich, dass sie Anwendungen erstellten, die auf Computern mit Exchange Server ausgeführt werden mussten. Windows 2000 Server enthielt CDONTS aus Gründen der Abwärtskompatibilität.

Mit Microsoft Windows Server 2003 wurde der verwaltete Code eingeführt und damit ein verwalteter Wrapper für CDOSYS. Dieser verwaltete Wrapper wird als System.Web.Mail bezeichnet.

In Windows Server 2003 ist CDONTS nicht enthalten, d. h., Neuinstallationen von Windows Server 2003 weisen CDONTS nicht auf. Wenn Sie jedoch von Windows 2000 Server auf Windows Server 2003 aktualisieren, wird CDONTS nicht entfernt. Daher kann eine CDONTS-Anwendung auf einem Server mit Windows Server 2003 ausgeführt werden, wenn der Server von Windows 2000 Server aktualisiert wurde. Aber sie kann nicht auf einem Server mit einer Neuinstallation von Windows Server 2003 ausgeführt werden.

Je mehr Upgrades von Windows NT 4.0 auf Windows Server 2003 ausgeführt werden, desto häufiger tritt dieses Problem auf. Beispielsweise tritt dieses Problem auf, wenn Webhostinganbieter neue Server installieren, auf denen Neuinstallationen von Windows Server 2003 ausgeführt werden, und dann die Webseiten ihrer Kunden auf die neuen Server verschieben. Oftmals verwenden die migrierten Seiten CDONTS. Um jedoch auf jeden Fall eine unterstützte Konfiguration beizuhalten, wird empfohlen, Server mit Windows 2000 Server auf Windows Server 2003 zu aktualisieren.

Entwicklern wird dringend empfohlen, vorhandene CDONTS-Anwendungen in CDOSYS oder, besser noch, System.Web.Mail zu konvertieren. Im Abschnitt "Weitere Informationen" weiter unten in diesem Artikel finden Sie Links zu hilfreichen Knowledge Base-Artikeln.

Nicht von Microsoft stammende Anwendungen funktionieren aber auch nicht mehr oder nicht mehr korrekt nach der Ausführung bestimmter Typen von Upgrades, weil die Anwendungen aufgrund neuer Sicherheitsbeschränkungen nicht mehr auf die erforderlichen Ressourcen zugreifen können. Zu den Upgrades zählen neuere Versionen von Windows, Exchange Server und Microsoft Office oder die Installation eines Service Packs.

In diesen Fällen hat der Entwickler der nicht von Microsoft stammenden Anwendung nicht vorsätzlich dafür gesorgt, dass die Anwendung aufgrund eines Sicherheitsupdates beendet wird. Im Gegenteil: Im Zuge der fortwährenden Überprüfung des Quellcodes durch Microsoft konnten mögliche Sicherheitsprobleme identifiziert und in Updates und Service Packs behoben werden. Aufgrund dieser Upgrades und Service Packs werden manchmal Pfade zugemacht, die nicht von Microsoft stammende Anwendungen benötigen. Es ist ja absolut nicht so, als würden Softwareentwickler in ihren Büros hocken und ihre ganze Zeit darauf verwenden, Schwachstellen in unserer Software zu finden und auszunutzen. Ihre Anwendungen funktionieren nicht oder nicht mehr korrekt, weil die Anwendungen nicht auf erforderliche Ressourcen zugreifen können, nachdem durch ein Softwareupgrade ein bestimmter Pfad zugemacht wurde.

Hier ist ein Beispiel. Vor der Veröffentlichung von Exchange 2000 Server Service Pack 3 (SP3) hatte die Gruppe Jeder Lesezugriff auf die IIS-Metabasis. Es war allgemein üblich, dass zum Senden von SMTP-Nachrichten die Anwendung den Namen des standardmäßigen SMTP-Servers in der IIS-Metabasis nachschlug. Das hat gut funktioniert, weil die Gruppe Jeder Lesezugriff auf die IIS-Metabasis hatte. In Exchange 2000 Server SP3 wurde jedoch der Lesezugriff auf die IIS-Metabasis für die Gruppe Jeder entfernt, sodass Anwendungen, von denen die früheren Berechtigungen verwendet wurden, nicht mehr funktionierten.

Microsoft hat dieses Problem zum Gegenstand eines Knowledge Base-Artikels gemacht. In zwei Problemumgehungen geht es darum sicherzustellen, dass die Anwendung unter einem Konto ausgeführt wird, das über die erforderlichen Rechte zum Zugreifen auf die IIS-Metabasis verfügte. Heutzutage ist das Planen der geeigneten Rechte für die Architektur einer Anwendung sehr wichtig. Anwendungen müssen über ausreichende Rechte zum Zugreifen auf die Ressourcen verfügen, die sie benötigen, aber mehr nicht.

Es ist nicht angebracht, jede Anwendung unter dem Administratorkonto auszuführen oder den anonymen Zugriff auf alle Ressourcen zuzulassen. Sie sollten die Ressourcen festlegen, die von Ihrer Anwendung benötigt werden, und die Anwendung so konfigurieren, das sie unter einem Konto mit diesen Rechten ausgeführt werden kann.

Bei den am häufigsten eingehenden Supportanrufen zur Sicherheitskonfiguration handelt es sich um Probleme im Zusammenhang mit Berechtigungen für das PICKUP-Verzeichnis bei Verwendung der sendusingpickup-Methode. Weitere Informationen zum korrekten Konfigurieren der Berechtigungen für die sendusingpickup-Methode finden Sie im folgenden Microsoft Knowledge Base-Artikel:

 
Fanden Sie dies hilfreich?
(1500 verbleibende Zeichen)
Vielen Dank für Ihr Feedback.
Anzeigen:
© 2014 Microsoft