Bereitstellen von Microsoft Dynamics CRM 4.0

Aaron Elder

Auf einen Blick:

• Softwarekomponenten eines CRM-Systems
• Der Entwicklungslebenszyklus
• Elemente einer CRM-Lösung
• Ein Blick auf die Mehrinstanzenfähigkeit

Inhalt

Der Entwicklungslebenszyklus von Lösungen
Elemente einer CRM-Lösung
Mehrinstanzenfähigkeit
Überlegungen zum Entwurf
Wichtige Schlussfolgerungen

CRM ist nicht einfach ein Tool für die Vertriebs- und Marketingverwaltung. Microsoft Dynamics Customer Relationship Management ist eine Plattform für das Entwickeln von Anwendungen, die auf reale Objekte bezogene Informationen und Prozesse verwalten und nachverfolgen. Diese Objekte können Kunden sein, aber es kann sich dabei auch um beliebige Entitäten (und verwandte Aktivitäten) handeln, die von Ihnen verwaltet werden müssen.

Wie bei jeder umfassenden benutzerdefinierten Lösung gibt es einige Grundlagen hinsichtlich der Bereitstellung, die verstanden werden müssen. In diesem Artikel werden einige grundlegende Konzepte in Bezug auf die Bereitstellung von Microsoft Dynamics CRM behandelt. Dazu gehört auch die Untersuchung der Frage, wie diese Konzepte verwendet werden können, um eine vollständige Produktlebenszyklusbereitstellung zu unterstützen. Außerdem werden das Verwalten mehrerer Bereitstellungen als Teil einer Einzellösungsveröffentlichung sowie die Frage erläutert, wie die Mehrinstanzenfähigkeit als Teil des gesamten Lösungslebenszyklus verwendet werden bzw. nicht verwendet werden sollten.

Gleich zu Anfang soll verdeutlicht werden, dass mit einer Microsoft Dynamics CRM-„Lösung“ die Gesamtheit aller Anpassungen, Erweiterungen, benutzerdefinierter Codes, Schemaänderungen usw. gemeint ist. Eine Lösung ist nicht nur eine einzige Sache, sie besteht aus der Gesamtheit Ihrer Änderungen.

Im Hintergrund ist eine Microsoft Dynamics CRM-Lösung eine standardmäßige datengesteuerte ASP.NET 2.0- und Microsoft .NET Framework 3.5-Webanwendung. Das Dreistufensystem enthält die folgenden Hauptkomponenten:

Datenstufe SQL Server 2005- oder SQL Server 2008-Datenbank. Die Verwendung von SQL Server 2008 erfordert einen Hotfix, wie im Knowledge Base-Artikel Unterstützung für das Ausführen von Microsoft Dynamics CRM 4.0 zusammen mit Microsoft SQL Server 2008 beschrieben.

Mittlere Stufe Microsoft-Internetinformationsdienste (IIS) 6.0 oder ein höheres Web-Front-End; SQL Server Reporting Services (SRS) 2005 oder SRS 2008; ASP.NET 3.5; benutzerdefinierte Windows-Dienste.

Clientstufe Client mit Microsoft Internet Explorer 6.0 oder höher; ASP.NET 2.0 oder höher; Client mit Microsoft Office Outlook 2003 oder Office 2007 (mit optionalem Offlinezugriff); andere Clients wie z. B. SDK-Nutzer und mobile Clients von Drittanbietern.

Microsoft Dynamics CRM beruht außerdem auf verschiedenen externen Systemen, einschließlich Microsoft Exchange Server 2003 oder höher und Active Directory.

Der Entwicklungslebenszyklus von Lösungen

Eine Microsoft Dynamics CRM-Lösung durchläuft denselben Lebenszyklus wie ein benutzerdefiniertes Anwendungsentwicklungsprojekt, das in etwa dem in Abbildung 1 dargestellten Prozess ähnelt.

Abbildung 1 Der Anwendungsentwicklungszyklus

Der gesamte Prozess wird von mehreren Umgebungen unterstützt, die alle zusammen die Entwicklungs-, Test- und Produktionssysteme umfassen. Bei einer vielfältigen Unternehmensanwendung kann sich dies selbstverständlich als erstaunlicherweise komplex erweisen. Wenn Sie zum Beispiel Ihre Umgebungen spiegeln möchten, könnte das Ergebnis etwa so wie in Abbildung 2 aussehen.

Abbildung 2 Spiegeln der Entwicklungs-, Test- und Produktionsumgebungen

Das sind drei Domänen, drei Domänencontroller, drei E-Mail-Server, drei Webserver und drei Datenbankserver, wobei bei diesem Modell davon ausgegangen wird, dass sich SRS und CRM im selben Paket befinden und so etwas wie Lastenausgleich nicht berücksichtigt wird. Stellen Sie sich jetzt vor, dass Sie Redundanz und einige externe Dienste, wie z. B. Microsoft Office SharePoint Services (MOSS), hinzufügen, und das Ergebnis könnte etwa so wie in Abbildung 3 aussehen.

Abbildung 3 Zunehmende Komplexität

Aus Kosten- und Komplexitätsgründen werden möglicherweise Kompromisse erwogen, um den Bedarf an Umgebungsisolierung mit der Anforderung, die Kosten niedrig und die Verwaltbarkeit aufrecht zu erhalten, in Einklang zu bringen. Organisationen haben folglich verschiedene Verfahren, wie z. B. Virtualisierung und die integrierten Features zur Mehrinstanzenfähigkeit von Microsoft Dynamics CRM in Erwägung gezogen, um diese Herausforderungen zu meistern.

Beim Entwerfen eines Satzes von Umgebungen zur Unterstützung des Lebenszyklus Ihres CRM-Projekts gibt es mehrere Denkschulen, und je nach dem, welche Prinzipien für Sie wichtig sind, können Sie sich für den einen oder anderen Weg entscheiden. An einem Ende des Spektrums sprechen sich Designer für die totale Isolierung mittels genauer Replikation aus. Diese Leute glauben, dass eine Testumgebung, die zu 100 % mit der Produktionsumgebung identisch ist, die einzige Möglichkeit darstellt, um zu überprüfen, ob etwas außerhalb der Produktion funktionieren wird. Jeder Server, jedes Bit und jede Einstellung müssen identisch und von der Entwicklung und Produktion vollständig isoliert sein, damit die Tester und IT-Mitarbeiter akzeptieren und glauben, dass etwas in der Produktion funktionieren wird.

Im Gegensatz dazu denken andere, dass diese Art der Isolierung überhaupt nicht wichtig ist. Wenn sie könnten, würden sie direkt in der Produktionsumgebung entwickeln und testen. Sie neigen dazu, die Redundanz als eine Zeit- und Geldverschwendung anzusehen, und sie sind sich sicher, dass die Bereitstellung einfacher wäre, wenn sie die Dinge einfach nur zum Laufen bringen würden.

Hoffentlich finden Sie sich irgendwo zwischen diesen Extremen wieder und sind offen für den Gedanken, dass es bei einer Microsoft Dynamics CRM-basierten Lösung möglich ist, eine Mischung zu entwickeln, die ein Gleichgewicht zwischen Komplexität, Kosten, Isolierung und Verwaltbarkeit bietet.

Elemente einer CRM-Lösung

Microsoft Dynamics CRM-Lösungskomponenten können in vier Hauptkategorien eingeteilt werden, und Ihre Lösung wird möglicherweise eine, zwei, drei oder alle vier Kategorien enthalten.

Anpassungen Sie enthalten Änderungen des Formulars, Rasters, Schemas und der Metadaten, Sicherheitsrollen, Workflows, Systemeinstellungen und Vorlagen. Microsoft Dynamics CRM-Anpassungen werden als eine oder mehrere (in der Regel eine oder zwei) gezippte XML-Dateien bereitgestellt. Sie werden über den Outlook- oder Webclientbereich „Einstellungen“ | „Anpassung“ in eine CRM-Bereitstellung importiert und dann „veröffentlicht“, um sie zu aktivieren. All dies kann mittels Code, der mit dem Microsoft Dynamics CRM SDK geschrieben wird, automatisiert werden.

Erweiterungen Diese enthalten Berichte und benutzerdefinierten Code wie z. B. Plug-Ins, die separat von den Anpassungen bereitgestellt werden müssen. Die Informationen zur Plug-In-Registrierung werden als XML-Datei gespeichert und können über eine von Microsoft zur Verfügung gestellte Befehlszeile oder Windows Form-Anwendung bereitgestellt werden. Auch dies kann durch Code, der mit dem Microsoft Dynamics CRM SDK geschrieben wird, automatisiert werden.

Benutzerdefinierter Code Dies umfasst alles, was als Teil Ihrer Lösung entwickelt wurde, und kann aus externen Webdiensten, benutzerdefinierten Webanwendungskomponenten usw. bestehen. Die Regeln und Methoden für das Bereitstellen des benutzerdefinierten Codes sollten sich nicht von den Regeln und Methoden für eine beliebige andere benutzerdefinierte Webanwendung unterscheiden.

Daten Alle Informationen, die in eine Umgebung importiert werden müssen, damit diese Umgebung funktioniert. Diese können Domänendaten (wie z. B. eine Liste der Produktcodes) oder Benutzer enthalten. Die von Ihrer Lösung benötigten Daten können in Ihrer Microsoft Dynamics CRM-Instanz bereitgestellt werden, indem ein Skriptcode, das CRM-Massenimportfeature oder eine Art externer Prozesses verwendet wird, bei dem BizTalk oder ein anderes ETL-Tool (Extrahieren, Transformieren, Laden) zum Einsatz kommt. Einige Daten, z. B. zu Benutzern, müssen manuell oder durch Microsoft Dynamics CRM SDK-Aufrufe erstellt werden.

Für mich sind Bereitstellungen einer CRM-Lösung wie benutzerdefinierte Anwendungsentwicklungsbereitstellungen. Dies bedeutet, dass in der Entwicklungs- und Testphase jeder neue Build der Lösung von einem sauberen Basissystem installiert wird und dass der Prozess so wiederholbar und geskriptet wie möglich ist.

Mehrinstanzenfähigkeit

Im Folgenden wird untersucht, wie die Umgebung, in der Sie die Builds bereitstellen, aussehen sollte. Sie haben wahrscheinlich von der Unterstützung in der Enterprise Edition von Microsoft Dynamics CRM 4.0 für ein Feature namens „Mehrinstanzenfähigkeit“ gelesen, mit dem Sie mehrere Instanzen von Microsoft Dynamics CRM innerhalb einer einzigen Bereitstellung partitionieren können. Dies bedeutet, dass mehrere vollständig verschiedene Organisationen mit ihren eigenen Berichten, dem eigenen Workflow, den eigenen Anpassungen und Schemas auf demselben Satz von Hardware ausgeführt werden können, indem dieselben physischen Server, Datenbankinstanzen und IIS-Websites verwendet werden.

Auf den ersten Blick erscheint dies vielleicht als das Allheilmittel, das alle ungelösten Fragen in Bezug auf Verwaltbarkeit, Isolierung und Kosten löst. Eine solche Lösung könnte so wie in Abbildung 4 veranschaulicht werden.

Abbildung 4 Eine Lösung ausschließlich mit Mehrinstanzenfähigkeit

Dies scheint logisch, weil jede Organisation auf dem freigegebenen SQL Server oder der Instanz (der bzw. die Anpassungen, Workflows, Benutzer, Rollen und Einstellungen enthält) ihre eigene physische Datenbank und ihren eigenen SQL Reporting Services-Ordner erhält.

Dieses Modell funktioniert sehr gut, wenn diese verschiedenen Organisationen Teil unterschiedlicher Team- oder Abteilungslösungen sind. Das ist immerhin genau das, wofür die Mehrinstanzenfähigkeit entworfen wurde. Es ist zwar richtig, dass jede Organisation (oder Instanz) ihre eigene Datenbank erhält, aber sie verwenden alle dieselbe Organisationseinheit und dieselben Active Directory-Gruppen, und außerdem nutzen sie alle dieselben Plattformdienste und dieselbe Front-End-Anwendung. Dies bedeutet, dass von den Organisationen derselbe asynchrone Dienst und dieselbe IIS-Website verwendet werden. Die Front-End-Server können diese verschiedenen Organisationen durch einen URL-Anbieter „hosten“, der anhand der URL festlegt, welche Organisation gehostet wird.

Nehmen Sie diese URLs als Beispiel: crmserver/ContosoDevOrg/loader.aspx und crmserver/ContosoTestOrg/loader.aspx. Der CRM-Server überprüft das Stammverzeichnis, um den Namen der Organisation zu bestimmen. Wenn kein Name für die Stammorganisation gefunden wird, wie im Fall von crmserver/loader.aspx, der Server standardmäßig auf die erste Organisation zurückgesetzt, die in der Bereitstellung erstellt wurde oder auf die der aufrufende Benutzer Zugriff hat.

Weil dieselbe Website für beide Organisationen verwendet wird, wird sie – wenn Ihre Lösung benutzerdefinierten Code enthält – auch von beiden Organisationen verwendet, z. B. crmserver/ContosoDevOrg/ISV/mycustomdialog.aspx und crmserver/ContosoTestOrg/ISV/mycustomdialog.aspx.

Beide zeigen auf dieselbe physische Datei auf dem Datenträger, wie z. B. C:\inetpub\wwwroot\isv\mycustomdialog.aspx. Da es wahrscheinlich ist, dass die Version einer benutzerdefinierten Erweiterung zwischen der Entwicklung, dem Testen und der Produktion verschieden ist, kann dies ein ernstes Problem darstellen. Angenommen, Build 11 Ihrer Anwendung wird derzeit entwickelt, während Build 9 Benutzerakzeptanztests unterzogen wird. Wenn Sie versuchen, die Mehrinstanzenfähigkeit zu verwenden, um Ihr Umgebungsproblem zu lösen, werden Sie große Schwierigkeiten haben, die beiden Builds zu isolieren. In solchen Situationen kann es sein, dass einige von Ihnen erwägen, die in Abbildung 5 gezeigte Lösung auszuprobieren.

Abbildung 5 Versuch, verschiedene IIS-Server zu verwenden, um benutzerdefinierten Lösungscode zu trennen

Bei diesem Modell (falls Sie die Adresse für den Netzwerklastenausgleich nicht mehr verwenden) stoßen die Benutzer möglicherweise auf eine URL, die folgendermaßen aussieht:

Entwicklung 192.168.1.100/ContosoDevOrg/loader.aspx

Test 192.168.1.105/ContosoTestOrg/loader.aspx

Produktion 192.168.1.110/Contoso/loader.aspx

Dieses Modell ermöglicht drei separate Front-End-Server und das Hosten von drei verschiedenen Organisationen mit drei verschiedenen Codebasen auf dem Datenträger. Solange ein Benutzer nicht versehentlich die falsche Organisation auf dem falschen Server aufruft, müsste alles gut klappen.

Da jedoch alle Front-End-Server als Teil derselben Bereitstellung angesehen werden, entstehen nach einer Weile Schwierigkeiten, und zwar viel später im Prozess als Sie vielleicht auf den ersten Blick annehmen. Dies entpuppt sich wirklich als eine Herausforderung, wenn Ihre Lösung asynchrone Plug-Ins oder Workflows verwendet, denn Sie können zwar kontrollieren, welche Server Ihre Benutzer aufrufen, aber Sie können nicht kontrollieren, welcher asynchrone Dienst die Ereignisse und Anforderungen für welche Organisationen verarbeiten wird.

Das liegt daran, dass alle asynchronen Dienste in einer Bereitstellung in einer Roundrobinweise funktionieren, und der asynchrone Dienst Ihres Entwicklungsservers verarbeitet daher vielleicht einen Workflow, einen Systemauftrag oder eine asynchrone Plug-In-Antwort auf eine Anforderung Ihres Testservers und hebt folglich die Isolierungsanforderung regelrecht auf. Hinzu kommt Folgendes: Wenn Ihr benutzerdefinierter Code, der durch diesen asynchronen Prozess ausgeführt wird, auf Dateien beruht, die für den Server auf einem Datenträger bereitgestellt werden müssen (wie z. B. eine Konfigurationsdatei oder eine Datei im globalen Assemblycache, GAC), treten Versionskonflikte auf.

Es ist wichtig zu beachten, dass diese Herausforderungen größtenteils nur entstehen, wenn Sie benutzerdefinierten Code schreiben, der auf einem Datenträger bereitgestellt werden muss, oder wenn Ihr benutzerdefinierter Code auf Ressourcen beruht, die nur auf oder von einem bestimmten Server verfügbar sind. Wenn Ihre Lösung einfach gehalten ist und nur Anpassungen (Schemas, Formulare, Ansichten usw.), Workflows und Berichte verwendet, werden Sie beim Verwenden des Ansatzes in Abbildung 4 keine Probleme haben.

Es stellt sich die Frage, wozu die Mehrinstanzenfähigkeit dient und wann sie eine gute Lösung für Produktlebenszyklusumgebungen darstellt. Die Mehrinstanzenfähigkeit wurde ursprünglich entworfen, um ein Hardwareproblem zu lösen, das sich auf das Hosten mehrerer eindeutiger Instanzen in einer Produktionsumgebung bezieht, und sie leistet sehr gute Arbeit dabei. Früher musste in Microsoft Dynamics CRM 3.0 jede Bereitstellung ihren eigenen dedizierten SQL Server oder ihre SQL Server-Instanz sowie einen Front-End-Server haben.

Dies war aus vielen Gründen richtig so, einschließlich der Tatsache, dass bereitstellungsspezifische Einstellungen in der Registrierung und auf Datenträgern gespeichert wurden. Alle diese Konfigurationen wurden jetzt zur Datenbank verschoben. Deshalb kann ein einziger Anwendungsserver mehreren Organisationen dienen. Die Mehrinstanzenfähigkeit ist bei gehosteten Versionen von CRM, einschließlich Microsoft Dynamics CRM Online, sehr nützlich.

Überlegungen zum Entwurf

Nachdem jetzt einige der potenziellen Probleme erläutert wurden, soll im Folgenden besprochen werden, was Sie beim Entwerfen Ihrer Bereitstellung im Auge behalten müssen. Die Antwort lautet natürlich: „Das kommt ganz darauf an.“ Es ist sicherlich möglich, eine vollständige CRM-Umgebung (einschließlich des Domänencontrollers, SQL Server und Webserver) auf einem einzigen Computer auszuführen, wie Sie im Demo „Virtueller Microsoft Dynamics CRM 4.0-Computer“ sehen können (siehe URL in der Randleiste „CRM-Ressourcen“). Es kommt sehr häufig vor, dass ein virtuelles Abbild eines einzigen Computers für eine Entwicklungsumgebung verwendet wird. Für Testzwecke ist es jedoch wichtig, die wichtigsten Herausforderungen der Produktionsumgebung zu überprüfen, und aus diesem Grund empfehle ich, dass Ihre Produktionsumgebung von der Testumgebung hinsichtlich der Struktur und nicht der Kapazität widergespiegelt wird. Ihre Umgebung sieht möglicherweise so wie die in Abbildung 6 gezeigte Umgebung aus.

Abbildung 6 Die Testumgebungsstruktur soll die Produktionsstruktur widerspiegeln

Bei diesem Ansatz wird versucht, die physische Hardware der Infrastruktur mittels Virtualisierung zu minimieren, und außerdem wird versucht, die Virtualisierungsressourcen zu minimieren, indem nur die wichtigsten Szenarios, die getestet werden müssen, virtualisiert werden. Sie werden Ihren Entwicklern ermöglichen können, auf einem einzigen Serverabbild zu entwickeln (oder auf Abbildern, falls die Entwickler auf ihren persönlichen Desktops über ihren eigenen virtuellen Computer verfügen), sofern Sie sicherstellen, dass sie die Umgebung, in der ihre Lösung bereitgestellt wird, berücksichtigen und sich ihrer bewusst sind. Die Probleme, die von Entwicklern berücksichtigt werden müssen, sind dieselben Probleme, zu deren Überprüfung Sie die Testumgebung erstellen sollten. Dazu gehören folgende:

Für konfigurierbare Einstellungen sorgen Nehmen Sie z. B. nicht an, dass der Server auf Localhost oder einen bestimmten Port antworten wird.

Mehrere Server berücksichtigen Gehen Sie nicht davon aus, dass alles gut laufen wird, ohne Proxybenutzer oder Vertrauenswürdigkeit für Delegierungszwecke einzurichten.

Auf Lastenausgleich achten Gehen Sie mit dem Sitzungszustand und der Zwischenspeicherung sehr vorsichtig um. Beachten Sie, dass Microsoft Dynamics CRM als vollständig statusfrei entworfen wurde und mit einem Roundrobin-Lastenausgleich gut funktioniert.

Mehrinstanzenfähigkeit erwägen Wenn mehrere Instanzen auf einem einzigen Computer gehostet werden, verwenden sie denselben Prozessraum. Dies bedeutet, dass Elemente, wie z. B. Caches, mit dem Organisationsnamen identifiziert werden müssen, damit die Benutzer einer Organisation nicht versehentlich die Daten einer anderen Organisation verwenden. Zudem ist Folgendes zu beachten: Bei clientseitigem Code, der Links enthält oder einen Rückruf an den Server durchführt, müssen Sie sicher sein, dass die Aufrufe den Organisationsnamen in der URL behalten. Andernfalls kann es sein, dass Sie bei der Standardorganisation oder einer unerwarteten Organisation landen.

CRM-Ressourcen

Microsoft Dynamics CRM 4.0-Implementierungshandbuch

Microsoft Dynamics CRM 4.0 als Entwicklungsplattform für Geschäftsanwendungen

Microsoft Dynamics CRM-Teamblog

Virtueller Microsoft Dynamics CRM 4.0-Computer

Optimieren und Verwalten von Microsoft Dynamics CRM 4.0

Wichtige Schlussfolgerungen

Isolierung ist wichtig Bedenken Sie beim Entwerfen einer Lösung, welcher Ansatz (siehe Abbildungen 4, 5 und 6) sich am besten für Ihre Zwecke eignet, und behalten Sie im Auge, wann und wo der benutzerdefinierte Code möglicherweise ausgeführt wird. Es lohnt sich außerdem zu beachten, wann Sie sich aufgrund der Art der Erweiterungen, die in Ihrer Lösung verwendet werden, keine Gedanken um solche Probleme machen müssen.

Virtualisierung Virtualisierung trägt dazu bei, die Komplexität beim Erstellen einer Umgebung zu verringern, die die wichtigsten Testszenarios der Produktion widerspiegelt. Hier ist ein Leitfaden für das Setup. Stellen Sie CRM und SQL Server auf separaten Servern bereit. Dadurch können Sie die Vertrauenswürdigkeit für Delegierungszwecke und andere verwandte Probleme überprüfen. CRM-Server müssen einen Lastenausgleich aufweisen. Dadurch können Sitzungs-, Zwischenspeicherungs- und serverübergreifende Probleme identifiziert werden. Stellen Sie abschließend die Domänencontroller und die E-Mail-Funktionalität auf separaten Servern bereit. Dies hilft beim Identifizieren von Konnektivitätsproblemen.

Aktualisieren der Umgebung für jeden Build In der Regel empfiehlt es sich, entweder von den virtuellen Umgebungen oder einfach von den Microsoft Dynamics CRM-Datenbanken (Data und Config) Sicherungen zu erstellen, die dann wiederhergestellt werden können, um den Server in den ursprünglichen Zustand zu versetzen. Sie führen dann jedes Mal eine vollständige saubere Bereitstellung in einer aktualisierten Umgebung durch, einschließlich benutzerdefinierten Codes, Anpassungen, Plug-Ins und Domänendaten.

Redundanz-/Leistungstests können separat erfolgen Außer bei sehr großen Organisationen können Sie Failover- und Leistungstests meist durch isolierte Simulationen erreichen, und nicht durch wirklichkeitsgetreue Testumgebungen. Dies bedeutet, dass es nicht notwendig ist zu versuchen, eine Testumgebung zu erstellen, die ein Testen dieser Szenarios ermöglicht. Alternativ können Sie sich auf Tests entweder in der Produktion oder in separaten Einmalumgebungen verlassen.

Abschließend ist anzumerken, dass Microsoft Dynamics CRM ein skalierbares System für Unternehmen ist, das bei entsprechender Konfiguration und Bereitstellung kleine Teams, unternehmensweite Lösungen und jede Option dazwischen bewältigen kann. Bei dem Versuch zu bestimmen, welche Produktlebenszyklusumgebung die richtige für Sie ist, wird die Antwort von verschiedenen Faktoren abhängen.

Im Allgemeinen ist die Mehrinstanzenfähigkeit keine ideale Möglichkeit, die Herausforderungen der Produktlebenszyklusentwicklung komplexer Lösungen zu behandeln, und wird am besten nur dann verwendet, wenn sie vollständig verstanden wird. Einfache Lösungen, die nur eine grundlegende Anpassung erfordern oder richtig kodierte und isolierte benutzerdefinierte Erweiterungen verwenden, die nicht auf Datenträgerressourcen oder serverspezifischem Zugriff basieren, sind entsprechend dem in Abbildung 4 dargestellten Modell gut geeignet.

Wenn Ihre Lösung mehr Isolierung, serverspezifische Ressourcen oder Zugriff (vielleicht wird einem externen Dienst der Weg durch Ihr VLAN nur von einem bestimmten Server zu einem anderen ermöglicht) und so weiter erfordert, empfiehlt sich das in Abbildung 6 dargestellte Modell. Ich würde außerdem empfehlen, den in Abbildung 5 dargestellten Ansatz zu vermeiden, da es sich dabei bestenfalls um eine Hybridmethode handelt.

Letzten Endes kann Microsoft Dynamics CRM in Tausenden von Konfigurationen bereitgestellt werden, und welche davon sich am besten für Ihre Zwecke eignet, hängt davon ab, was Ihre Lösung erfordert. Mit einem besseren Verständnis von Mehrinstanzenfähigkeit, Einzelserver-Entwicklungsumgebungen, virtuellen Testumgebungen sowie der Frage, welche testbaren Szenarios für Sie wichtig sind, müssten Sie in der Lage sein, eine Produktlebenszyklusbereitstellung zu entwerfen, die sowohl funktional als auch kostengünstig ist.

Aaron Elder (Microsoft Dynamics CRM MVP) arbeitet für Ascentium, eine Agentur für technologische Beratung und interaktives Marketing. Besuchen Sie den Ascentium-Blog unter ascentium.com/blog/crm.