Was bei der serverseitigen Automatisierung von Office zu beachten ist

Entwickler können die Automatisierungsfunktion von Microsoft Office einsetzen, um benutzerdefinierte Lösungen zu erstellen, bei denen die Möglichkeiten und Features des jeweiligen Office-Produkts bestmöglich genutzt werden. Während eine solche programmatische Bereitstellung auf einem Clientsystem relativ einfach ist, können jedoch diverse Komplikationen auftreten, wenn die Automatisierung über einen serverseitigen Code erfolgen soll, wie zum Beispiel Active Server Pages (ASP), DCOM oder einen NT-Dienst.

In diesem Artikel werden die Komplikationen erläutert, mit denen Entwickler konfrontiert sein können, es werden Alternativen zur Automatisierung aufgezeigt, durch die die Leistung gesteigert werden kann, und es werden Vorschläge dazu unterbreitet, wie Office konfiguriert werden kann, wenn eine serverseitige Automatisierung nicht zu vermeiden ist. Entwickler werden jedoch ausdrücklich darauf hingewiesen, dass die nachstehenden Vorschläge nur Informationszwecken dienen. Eine serverseitige Automatisierung von Office wird von Microsoft weder empfohlen noch unterstützt.

Hinweis: In diesem Kontext bezieht sich der Begriff "serverseitig" auch auf Code, der auf einer Microsoft Windows NT- oder Microsoft Windows 2000-Arbeitsstation ausgeführt wird, sofern dieser Code von einer WinStation aus ausgeführt wird, bei der es sich nicht um die interaktive Station handelt, bei der der Benutzer angemeldet ist. So wird beispielsweise ein durch den Taskplaner unter dem Systemkonto gestarteter Code in dem gleichen Umfeld ausgeführt wie "serverseitiger" ASP- oder DCOM-Code. Die möglicherweise auftretenden Probleme sind also weitgehend die gleichen. Mehr Informationen zu WinStations und COM finden Sie in den nachstehenden Abschnitten "Weitere Informationen" und "Informationsquellen":

Alle aktuellen Versionen von Microsoft Office wurden entwickelt, getestet und konfiguriert, um als Endbenutzerprodukte auf einer Clientarbeitsstation ausgeführt zu werden. Bei diesen Produkten werden ein interaktiver Desktop und das Vorhandensein eines Benutzerprofils vorausgesetzt. Sie bieten daher nicht den Grad an Ablaufinvarianz und Sicherheit, der erforderlich ist, um die Anforderungen an serverseitige Komponenten zu erfüllen, die darauf ausgelegt sind, unbeaufsichtigt ausgeführt zu werden.

Die Automatisierung von Microsoft Office-Anwendungen unter Verwendung unbeaufsichtigter, nicht interaktiver Clientanwendungen oder Clientkomponenten (wie ASP, DCOM und NT-Dienste) kann von Microsoft zum jetzigen Zeitpunkt weder empfohlen noch unterstützt werden, weil Office bei einer Ausführung in einer solchen Umgebung instabil werden kann und/oder sich die Anwendungen eventuell gegenseitig sperren.

Wenn Sie eine Lösung erstellen, die in einem serverseitigen Kontext ausgeführt wird, sollten Sie (so weit möglich) Komponenten verwenden, die auch bei unbeaufsichtigter Ausführung sicher sind, oder nach Alternativen suchen, bei denen zumindest ein Teil des Codes auf der Clientseite ausgeführt werden kann. Wenn Sie eine Office-Anwendung von einer serverseitigen Lösung aus verwenden, werden Sie feststellen, dass der Anwendung viele der Fähigkeiten fehlen, um erfolgreich ausgeführt werden zu können. Außerdem gehen Sie dabei erhebliche Risiken in Bezug auf die Stabilität Ihrer Gesamtlösung ein.

Probleme bei der serverseitigen Automatisierung von Office

Wenn Entwickler Office in einer serverseitigen Lösung verwenden möchten, gibt es fünf Hauptproblembereiche, in denen sich Office wegen der Serverumgebung anders als erwartet verhält. Wenn Ihr Code erfolgreich ausgeführt werden soll, müssen Sie diese Problembereiche bei der Entwicklung berücksichtigen, um deren negative Auswirkungen auf ein Minimum zu begrenzen. Sie können nicht alle diese fünf Probleme bei der Entwicklung Ihrer Anwendung vollständig eliminieren. Daher müssen Sie auf der Basis der Anforderungen, die Ihre Lösung erfüllen soll, sinnvolle Prioritäten setzen.

1. Benutzeridentität: Office-Anwendungen nehmen eine Benutzeridentität an, wenn sie ausgeführt werden. Dies gilt auch dann, wenn Sie mithilfe der Automatisierung gestartet werden. Die Anwendungen versuchen, Symbolleisten, Menüs, Optionen, Drucker und bestimmte Add-Ins auf der Basis der Einstellungen zu initialisieren, die in der Registrierungsstruktur für den Benutzer festgelegt sind, der die Anwendung startet. Viele Dienste werden unter Konten ausgeführt, für die keine Benutzerprofile definiert sind (zum Beispiel unter den Konten SYSTEM oder IWAM_[Servername]). Daher wird Office beim Start eventuell nicht korrekt initialisiert, und es kann ein Fehler für die Funktionen CreateObject oder CoCreateInstance zurückgegeben werden. Selbst wenn die Office-Anwendung gestartet werden kann, funktionieren viele andere Funktionen ohne Benutzerprofile eventuell nicht korrekt. Sollten Sie planen, Office von einem Dienst aus zu automatisieren, müssen Sie entweder Ihren Code oder Office so konfigurieren, dass die Ausführung mit einem geladenen Benutzerprofil erfolgt.
2. Interaktivität mit dem Desktop: Office-Anwendungen sind darauf ausgelegt, unter einem interaktiven Desktop ausgeführt zu werden, und müssen unter gewissen Umständen sichtbar gemacht werden, damit bestimmte Automatisierungsfunktionen einwandfrei funktionieren können. Für den Fall, dass ein unerwarteter Fehler auftritt oder ein nicht angegebener Parameter benötigt wird, um eine Funktion erfolgreich auszuführen, ist Office darauf ausgelegt, dem Benutzer ein modales Dialogfeld anzuzeigen, in dem der Benutzer gefragt wird, was er tun möchte. Ein modales Dialogfeld auf einem nicht interaktiven Desktop kann nicht geschlossen werden, was zur Folge hat, dass der Thread nicht mehr reagiert (hängt). Die Wahrscheinlichkeit, dass ein derartiges Ereignis eintritt, kann zwar durch bestimmte Codierungsverfahren reduziert werden, völlig ausschließen können Sie ein solches Ereignis jedoch nicht. Schon diese Tatsache allein hat zur Folge, dass die Ausführung von Office-Anwendungen in einer serverseitigen Umgebung riskant ist und nicht unterstützt werden kann.
3. Ablaufinvarianz und Skalierbarkeit: Serverseitige Komponenten müssen hochgradig ablaufinvariante Multithread-COM-Komponenten mit minimaler Belastung und hohem Durchsatz für mehrere Clients sein. Office-Anwendungen sind in nahezu jeder Hinsicht das exakte Gegenteil. Sie sind nicht ablaufinvariant. Office-Anwendungen sind STA-basierte Automatisierungsserver, die dafür konzipiert wurden, eine Vielzahl ressourcenintensiver Funktionen für einen einzigen Client zu ermöglichen. Als serverseitige Lösungen sind sie daher nur begrenzt skalierbar und unterliegen in Bezug auf wichtige Elemente festen Beschränkungen; so kann der Umfang des Speichers beispielsweise nicht durch einfache Konfigurationsschritte geändert werden. Noch wichtiger ist, dass sie globale Ressourcen verwenden (z. B. im Speicher zugeordnete Dateien, globale Add-Ins oder Vorlagen und gemeinsam genutzte Automatisierungsserver), welche die Anzahl der Instanzen begrenzen können, die gleichzeitig ausgeführt werden können. In einer Umgebung mit mehreren Clients führt dies dazu, dass die verschiedenen Instanzen um die verfügbaren Ressourcen konkurrieren. Wenn Entwickler mehr als eine Instanz einer beliebigen Office-Anwendung gleichzeitig ausführen lassen möchten, müssen Sie ein "Pooling" in Erwägung ziehen oder eine bestimmte Reihenfolge für den Zugriff auf die Office-Anwendung festlegen, um ein mögliches gegenseitiges Blockieren oder Beschädigungen von Daten zu verhindern.
4. Flexibilität und Stabilität: Office 2000, Office XP, Office 2003 und Office 2007 verwenden Microsoft Windows Installer-Technologie (MSI-Technologie), um Installation und Selbstreparatur für den Endbenutzer einfacher zu machen. Mit MSI wurde das Konzept des "Installierens bei der ersten Verwendung" eingeführt, das ein dynamisches Installieren oder Konfigurieren von Features zur Laufzeit ermöglicht (entweder für das gesamte System oder, was häufiger vorkommt, für einen bestimmten Benutzer). In einer serverseitigen Umgebung verlangsamt dies die Ausführung und erhöht die Wahrscheinlichkeit, dass Dialogfelder angezeigt werden, durch die der Benutzer aufgefordert wird, die Installation zu genehmigen oder den Installationsdatenträger einzulegen. Die in Office implementierten MSI-Funktionen erhöhen zwar die Flexibilität von Office als Endbenutzerprodukt, sind in einer serverseitigen Umgebung jedoch kontraproduktiv. Außerdem kann auch die allgemeine Stabilität von Office bei einer serverseitigen Ausführung nicht garantiert werden, da Office für diese Art der Verwendung weder konzipiert noch getestet wurde. Die Verwendung von Office als Dienstkomponente auf einem Netzwerkserver kann die Stabilität des Servers und somit auch die Ihres Netzwerks insgesamt beeinträchtigen. Falls Sie eine serverseitige Automatisierung von Office planen, versuchen Sie, das betreffende Programm von einem nur diesem Zweck dienenden Computer aus steuern zu lassen, der sich nicht negativ auf wichtige Funktionen auswirken und bei Bedarf neu gestartet werden kann.
5. Sicherheit auf der Serverseite: Office-Anwendungen waren nie für den Einsatz auf der Serverseite gedacht. Die Sicherheitsprobleme, die bei verteilten Komponenten zu beachten sind, wurden bei ihrer Entwicklung daher auch nicht berücksichtigt. Office authentifiziert eingehende Anforderungen nicht und bietet keinen Schutz vor dem unberechtigten Ausführen von Makros oder dem Starten eines anderen Servers, der Makros ausführen könnte. Öffnen Sie keine Dateien, die von einem anonymen Web auf den Server geladen wurden! Auf der Basis der zuletzt festgelegten Sicherheitseinstellungen kann der Server Makros im Kontext des Administrator- oder Systemkontos mit umfassenden Berechtigungen ausführen und Ihr Netzwerk kompromittieren! Außerdem verwendet Office eine Vielzahl clientseitiger Komponenten (wie Simple MAPI, WinInet und MSDAIPP), die Informationen zur Clientauthentifizierung zwischenspeichern können, um die Verarbeitung zu beschleunigen. Wenn Office serverseitig automatisiert wird, bedient eine Instanz eventuell mehr als einen Client. Da Authentifizierungsinformationen für die betreffende Sitzung zwischengespeichert worden sind, ist es möglich, dass ein Client die Anmeldeinformationen eines anderen Clients verwenden kann und somit ihm nicht zustehende Zugangsberechtigungen erhält, indem er die Identität eines anderen Benutzers annimmt.

Neben den technischen Problemen müssen Sie auch bedenken, ob ein Design mit serverseitiger Automatisierung überhaupt mit den geltenden Lizenzierungsvorschriften vereinbar ist. Die Lizenzierungsrichtlinien verbieten die Verwendung von Office-Anwendungen auf einem Server zur Bearbeitung von Clientanforderungen, sofern nicht die Clients selbst über lizenzierte Versionen der jeweiligen Office-Produkte verfügen. Die Bereitstellung von Office-Funktionalität für nicht lizenzierte Arbeitsstationen mithilfe der serverseitigen Automatisierung ist durch den Endbenutzerlizenzvertrag (EULA) nicht gedeckt.

Neben diesen größeren Problemen werden viele Kunden zudem feststellen, dass bei dem Versuch, Office serverseitig zu automatisieren, eine der folgenden Fehlermeldungen angezeigt wird, wenn Sie ihre Standardinstallation von Office unverändert lassen:

• CreateObject/CoCreateInstance gibt eine der folgenden Laufzeitfehlermeldungen zurück und kann nicht für die Automatisierung gestartet werden:
  
  In Microsoft Visual Basic (VB) oder ASP:
  • Fehlermeldung 1
    Laufzeitfehler '429': Objekterstellung durch ActiveX-Komponente nicht möglich
  • Fehlermeldung 2
    Laufzeitfehler '70': Zugriff verweigert
  In Microsoft Visual C oder Visual C++:
  • Fehlermeldung 1
    CO_E_SERVER_EXEC_FAILURE (0x80080005) Ausführen des Servers fehlgeschlagen.
  • Fehlermeldung 2
    E_ACCESSDENIED (0x80070005): Zugriff verweigert
  Diese Fehlermeldungen werden angezeigt, weil der serverseitige Code ohne Benutzerprofil ausgeführt wird oder die Benutzeridentität, die für den Startkontext festgelegt ist, nicht über die erforderlichen DCOM-Berechtigungen verfügt.
• Das Öffnen eines Office-Dokuments führt zu einer der folgenden Fehlermeldungen:
  • Fehlermeldung 1
    Laufzeitfehler '5981' (0x800A175D): Makrospeicher konnte nicht geöffnet werden
  • Fehlermeldung 2
    Laufzeitfehler '1004': Die Methode '~' für das Objekt '~' ist fehlgeschlagen
  Typischerweise ist diese Fehlermeldung das Resultat einer fehlgeschlagenen Initialisierung von VBA wegen unzureichender Berechtigungen oder der nicht erfolgten Registrierung einer VBA-Komponente. Diese beiden Probleme sind häufig zu beobachten, wenn ein Benutzer Code unter einem Konto ohne Benutzerprofil ausführt (1. Problem), oder der Benutzertoken die interaktive Sicherheitskennung (SID) nicht enthält (2. Problem).
  
  
• CreateObject/CoCreateInstance hängt und wird entweder nie erfolgreich abgeschlossen oder benötigt lange Zeit, um ein Ergebnis zurückzugeben. Auf manchen Servern erfolgt die Erstellung zwar schnell, es werden jedoch Fehler des Typs 1004 im Windows (NT)-Ereignisprotokoll gespeichert.
  
  Dieses Problem hat seine Ursache häufig in einem modalen Dialogfeld, das auf dem nicht interaktiven Desktop angezeigt wird, auf dem der serverseitige Code ausgeführt wird (3. Problem). Wird das Dialogfeld wegen Problemen beim Installieren einer MSI-Komponente angezeigt (fehlender Registrierungseintrag oder beschädigtes Dateiabbild), fordert es den Benutzer zur Bereitstellung der Installations-CD auf, falls der Installationspunkt nicht gefunden werden konnte, und installiert eine oder mehrere Komponenten neu (4. Problem).
• Manche Funktionen schlagen unerwartet fehl oder hängen auf unbestimmte Zeit.
  
  Bei einem nicht interaktiven Desktop (2. Problem), sind bestimmte Ressourcen, wie z. B. Drucker, zugeordnete Laufwerke, eingebettete OLE-Objekte und die Zwischenablage eventuell nicht verfügbar oder befinden sich in einem nicht definierten Zustand. Ohne ein Benutzerprofil (1. Problem) sind Netzwerkressourcen ebenfalls nicht verfügbar und die Berechtigungen stark eingeschränkt.
• Das Ausführen mehrerer Anforderungen oder eines Belastungstests kann dazu führen, dass der Code hängt oder beim Erstellen bzw. beim Beenden einer Office-Anwendung abstürzt. Wenn dies geschieht, wird der Prozess entweder weiterhin im Speicher ausgeführt und kann nicht beendet werden, oder es schlagen von diesem Punkt an alle Instanzen der automatisierten Anwendung fehl.
  
  Da Office-Anwendungen bestimmte globale Ressourcen gemeinsam nutzen (3. Problem), muss für den Zugang zu Office-Anwendungen für bestimmte Aktionen eine Reihenfolge festgelegt werden (Serialisierung). Dies gilt zum Beispiel für Aktionen wie Starten, Herunterfahren, Drucken, Exportieren und das Aktualisieren von OLE-Links (einschließlich DDE-Benachrichtigungen).

Zusätzlich zu den hier beschriebenen können noch weitere Probleme und Fehlermeldungen auftreten, auch diese sind jedoch in der Regel die Folge eines der fünf zuvor beschriebenen Probleme. Zur Vermeidung dieser Fehler sollten Entwickler das Anwendungsumfeld von Office so konfigurieren, dass ein clientseitiger Zustand simuliert wird, oder die Office-Anwendung aus serverseitigem Code entfernen und stattdessen besser skalierbare Komponenten (oder eine clientseitige Automatisierung) verwenden.

Alternativen zur Automatisierung bei serverseitiger Ausführung verwenden

Microsoft empfiehlt Entwicklern dringend, Alternativen zur Automatisierung von Office zu suchen, wenn sie serverseitige Lösungen entwickeln müssen. Wegen der grundlegenden Beschränkungen des Designs von Office können nicht alle geschilderten Probleme durch Änderungen der Office-Konfiguration behoben werden. Microsoft empfiehlt eine Reihe von Alternativen, bei denen eine serverseitige Installation von Office nicht erforderlich ist, und mit denen die Ausführung der gebräuchlichsten Aufgaben schneller und effizienter möglich ist als bei der Automatisierung. Bevor Sie Office als serverseitige Komponente in Ihr Projekt einbeziehen, sollten Sie mögliche Alternativen erwägen.

Bei den meisten serverseitigen Automatisierungsaufgaben geht es um das Erstellen von Dokumenten. Da Office 2000 und spätere Versionen HTML als natives Dokumentformat unterstützen, können die meisten Dokumente im HTML-Format erstellt (bei Bedarf unter Verwendung von XML) und dann mithilfe eines MIME-Typs (MIME = Multipurpose Internet Mail Extensions) an den Client übermittelt werden, sodass der aus dieser Operation resultierende Text in Office angezeigt wird. Dieses Dokument kann bearbeitet, gespeichert und bei Bedarf sogar an den Server zurückgesendet werden. Und dazu müssen Sie auf dem Server nur ASP verwenden. In Verbindung mit früheren Office-Versionen können zu diesem Zweck andere, leicht zu bearbeitende Textformate verwendet werden (zum Beispiel RTF).

Einige systemeigene Binärformate können mithilfe der Office Web Components (OWC) oder ActiveX Data Objects (ADO) bei wesentlich höherer Geschwindigkeit und Skalierbarkeit bearbeitet werden. Dokumenteigenschaften können so auch ohne Automatisierung eingesehen und geändert werden. Datei- und Versionsverwaltung sind auch mit den FrontPage-Servererweiterungen oder Distributed Authoring and Versioning (Verteilte Dokumentenerstellung und Versionsverwaltung, DAV) möglich. Wenn die Automatisierung unumgänglich ist, können die meisten Aufgaben auf den Client übertragen werden, wodurch Stabilität und Skalierbarkeit für das System verbessert werden, weil jeder Benutzer die jeweilige Aufgabe in seinem eigenen Kontext und mit seinen eigenen Einstellungen ausführt.

Weitere Informationen zu diesen Themen und entsprechende Implementierungsbeispiele finden Sie in den folgenden Artikeln der Microsoft Knowledge Base: Wenn in Ihrem Unternehmen die serverseitige Erstellung von binären Office-Dateien erforderlich ist, gibt es Fremdanbieter, die entsprechende hilfreiche Komponenten anbieten. Die folgende Liste nennt einige namhafte Anbieter auf diesem Gebiet. Diese Liste dient lediglich zur Information. Die Liste ist nicht vollständig. Andere Anbieter können möglicherweise Dienste zur Verfügung stellen, die für Ihre Zwecke besser geeignet sind. Sie sollten alle möglichen Fremdanbieter-Lösungen prüfen, um den für Ihre Geschäftsanforderungen am besten geeigneten Anbieter zu finden. Die folgenden Hersteller bieten zurzeit einige Lösungen zur programmatischen Erstellung und Bearbeitung von nativen Office-Dateiformaten. Weitere Informationen finden Sie auf den folgenden Fremdanbieter-Websites:

Aia Software B.V. Polar SoftArtisans SyncFusion Keylogix Hinweis: Die in diesem Artikel genannten Fremdanbieterprodukte stammen von Herstellern, die von Microsoft unabhängig sind. Microsoft gewährt keine implizite oder sonstige Garantie in Bezug auf die Leistung oder Zuverlässigkeit dieser Produkte.

Konfigurieren von Office auf die serverseitige Ausführung

Falls keine andere Lösung möglich ist und Sie sich für eine Automatisierung von Office auf der Serverseite entscheiden, müssen Sie Maßnahmen gegen viele der zuvor beschriebenen Probleme ergreifen, um eine erfolgreiche Ausführung in einer solchen Umgebung zu gewährleisten. Da es bei den meisten Problemen einen Zusammenhang mit der Konfiguration gibt, ist es nicht möglich, ein einheitliches Verfahren zu benennen, durch das eine serverseitige Automatisierung von Office in allen Fällen und auf allen Systemen funktioniert. Einige Konfigurationseinstellungen können Konflikte mit anderen Optionen verursachen und jede Vorgehensweise hat ihre Vorteile und Nachteile. Sie müssen eventuell ein wenig experimentieren, um die Vorgehensweise zu ermitteln, die in Ihrer Umgebung die besten Resultate gewährleistet.

In der Regel müssen Sie Folgendes tun, um eine Automatisierung von Office auf der Serverseite zu ermöglichen:

• Gestalten Sie Ihr Projekt so, dass Office isoliert und verkapselt ist.
• Codieren Sie Ihr Projekt so, dass mögliche Probleme bereits berücksichtigt sind und gegebenenfalls dynamisch behoben werden können.
• Definieren Sie für Ihr Projekt eine spezifische Benutzeridentität und ein Benutzerprofil für die Verwendung in Office.

Bei Ihrem Projektdesign sollten die Probleme in Bezug auf serverseitige Sicherheit und die fehlende Ablaufinvarianz von Office berücksichtigt sein, wenn Sie die Office-Automatisierung verwenden möchten. Beschränken Sie die Nutzung von Office auf eine bestimmte Instanz, die von einem Serialisierungsobjekt (benutzerdefiniertes oder Mutex-Stammelement) kontrolliert wird, oder fassen Sie einen eng definierten Satz von Instanzen aus einem Objekthandler (oder Objektbroker) zu einem Pool zusammen, der bei Bedarf Anwendungsobjekte ausgeben kann. Steuern Sie jedoch sorgfältig die Aspekte, die eine Serialisierung erfordern. Office erfordert eine gewisse Stetigkeit, sodass bei gleichzeitiger Ausführung bestimmter Aktionen (wie Starten, Herunterfahren, Drucken und so weiter) durch mehrere Clients Konflikte entstehen können und möglicherweise einer oder mehrere der aufrufenden Threads gesperrt sind, weil Fehlermeldungen angezeigt werden und der Benutzer weitere Informationen eingeben muss, oder weil globale Ressourcen, die von allen Instanzen genutzt werden, nicht freigegeben werden.

Der erste Schritt besteht deshalb darin, die Verwendung der Office-Automatisierung in Ihrer serverseitigen Lösung auf ein Minimum zu begrenzen und den Prozess auf einem Computer zu isolieren, der nicht von entscheidender Bedeutung für das Gesamtsystem ist und bei Bedarf neu gestartet werden kann. Auch der Aufrufkontext muss isoliert werden, damit ein "hängender" Aufrufclient nicht die Leistung eines wichtigen Systemdienstes beeinträchtigt. Automatisieren Sie zum Beispiel nicht direkt aus IIS mithilfe eines Systemthreads; isolieren Sie den Code lieber so, dass er in seinem eigenen Thread ausgeführt wird, damit er bei einem etwaigen Fehlschlagen nicht die IIS-Funktionalität insgesamt negativ beeinflusst. Bedenken Sie auch, wie bei Ihrem Konzept Sicherheit und eine angemessene Authentifizierung gewährleistet werden können. Da Office die Sicherheit auf der Serverseite nicht erzwingt, muss Ihr Code sicherstellen, dass nur "vertrauenswürdige" Codemodule, wie ASP-Seiten, Skriptdateien und so weiter, eine Automatisierungsinstanz einer Office-Anwendung erstellen und deren Methoden aufrufen dürfen. Außerdem muss gewährleistet sein, dass Dokumente sicher sind, bevor Sie sie durch Office öffnen lassen. Office-Anwendungen auf einem Server sollten immer mit der Sicherheitsstufe "Hoch" ausgeführt werden. Sollte Ihr Design nicht angemessene Sicherheitsvorkehrungen erzwingen, besteht ein erhebliches Risiko für Ihren Server!

Nachdem Sie Ihr Design entworfen haben, sollten Sie bei der Codierung eine eher defensive Strategie wählen, um mögliche Probleme zu vermeiden und Fehler angemessen behandeln und beheben zu können, wenn sie auftreten. Stellen Sie sicher, dass Ihr Code Werte für optionale Parameter übergibt, weil fehlende oder Konflikte verursachende Werte es zuweilen erforderlich machen, dass Office den Benutzer zur Eingabe weiterer Informationen auffordert. Verwenden Sie in allen Funktionen Fehlersuchroutinen, um Fehlerbedingungen ordnungsgemäß behandeln zu können und diese Fehler unter Verwendung eines Protokollierungscodes protokollieren zu lassen, der durch eine benutzerdefinierte Einstellung (in der Registrierung oder einer INI-Datei) aktiviert und deaktiviert werden kann. Wenn Sie eine Aktion ausführen, die zur Anzeige eines von Office unabhängigen Dialogfeldes mit einer Fehlermeldung führen kann (beim Drucken kann zum Beispiel der Druckertreiber ein Dialogfeld anzeigen lassen, wenn sich im Drucker kein Papier mehr befindet), seien Sie darauf vorbereitet, mögliche gegenseitige Sperrungen zu behandeln, indem Sie einen Zeitüberschreitungswert oder einen zweiten Thread verwenden, um die Ausführung dieser Aktion zu überwachen. Weitere Informationen finden Sie im folgenden Artikel der Microsoft Knowledge Base: Verwenden Sie ihren Protokollierungscode zur Fehlerverfolgung und zum Debuggen Ihres Programms. Falls Sie einen benutzerdefinierten Objektpool verwenden, können Sie Leistungs- und Skalierbarkeitstests hinzufügen, um Auslastung und Protokollierungsprobleme zu überwachen, die Auswirkungen auf Clients haben. Mithilfe eines zentralen Controllers können Sie ebenfalls fehlerhafte Instanzen von Office beenden und neu erstellen lassen, wenn dies erforderlich ist, um die Stabilität des Gesamtsystems zu erhöhen.

Wenn das Programm so weit fertig ist, dass es bereitgestellt werden kann, vergewissern Sie sich, dass Office auf dem Server so konfiguriert ist, dass es in einem geeigneten Benutzerkontext ausgeführt werden kann. Office erfordert ein Benutzerprofil. Für eine erfolgreiche Automatisierung muss Office mit einem solchen Benutzerprofil geladen werden. In einer serverseitigen Umgebung gibt es drei Wege, dieses Ziel zu erreichen.

• Konfigurieren Sie alle Instanzen der Office-Anwendung, die durch die Automatisierung gestartet wird, auf eine Ausführung im Kontext des interaktiven Benutzers.
• Konfigurieren Sie alle Instanzen der Office-Anwendung, die durch die Automatisierung gestartet wird, auf eine Ausführung im Kontext eines bestimmten Benutzers.
• Konfigurieren Sie Ihren Code mithilfe eines MTS/COM+-Pakets auf die Ausführung im Kontext eines bestimmten Benutzers, und lassen Sie im Code die Möglichkeit zu, dass die Office-Anwendung die Identität des Benutzers übernimmt, der die Anwendung startet.

Bei der ersten Option verfügt Office über die Identität und die Interaktivität eines bestimmten Desktops. Diese Option ist die für ein Debuggen am besten geeignete (weil Office sichtbar gemacht werden kann und etwaige Dialogfelder oder Fehlermeldungen zu allgemeinen Schutzverletzungen dem Benutzer angezeigt werden und von dem Benutzer protokolliert werden können, der lokal angemeldet ist). Bei dieser Option ist es für eine erfolgreiche Ausführung nicht erforderlich, dass der interaktive Benutzer angemeldet bleibt. Diese Option ist daher nicht für alle Situationen geeignet. Weitere Informationen finden Sie im folgenden Artikel der Microsoft Knowledge Base: Bei der zweiten Option wird zwar ein bestimmter Benutzer definiert, die Interaktivität ist jedoch nicht gegeben. Office startet im Kontext des festgelegten Benutzers auf einer neuen WinStation und mit einem unsichtbaren Desktop. Diese Option macht einige weitere Konfigurationsschritte erforderlich, um zu gewährleisten, dass die Registrierungsstruktur geladen wird, weil COM/DCOM diese Struktur nicht standardmäßig lädt. Diese Einstellung gilt für das gesamte System und kann daher Konflikte mit anderen Programmen verursachen. Weitere Informationen zu einer derartigen Konfiguration von Office finden Sie im folgenden Artikel der Microsoft Knowledge Base: Bei der dritten Option haben Sie die Möglichkeit, einer bestimmten Website oder einem spezifischen Codemodul eine Identität zuzuweisen. So können Sie es vermeiden, eine Identität festzulegen, die für Office in seiner Gesamtheit gilt. Office wird im Kontext dieser Identität ausgeführt und korrekt geladen, sofern die Identität bereits zuvor für den betreffenden Computer konfiguriert wurde und die Registrierungsstruktur geladen worden ist. Diese Option ist die flexibelste und am besten zu sichernde, bietet jedoch wie die zuvor beschriebene zweite Option keine Interaktivität mit einem sichtbaren Desktop und erfordert einige weitere Konfigurationsschritte. Weitere Informationen zu einer derartigen Konfiguration von Office finden Sie im folgenden Artikel der Microsoft Knowledge Base: Sie müssen sorgfältig abwägen, welche der vorstehenden Optionen Ihre Anforderungen bestmöglich erfüllt und wie Sie Ihre Lösung bereitstellen können. Es kann keine Gewähr dafür gegeben werden, dass mithilfe der Informationen aus diesem Artikel alle Probleme für alle Clients behoben werden können. Microsoft empfiehlt, vor der Bereitstellung ausführliche Tests durchzuführen.

Weitere Informationen zur serverseitigen Automatisierung finden Sie in den folgenden Artikeln der Microsoft Knowledge Base: