Wir möchten diverse Anpassungen am CRM-System vornehmen (z. B. Masken) und auch Daten per Import hinzufügen. Diese Anpassungen und Imports möchten wir natürlich nicht im Livesystem/Echtsystem durchführen, sondern zuvor erst einmal testen, ohne das Livesystem/Echtsystem in irgendeiner Art und Weise zu gefährden.
Welche Möglichkeiten gibt es nun, diese Aufgabenstellung zu lösen? 1. Zweite CRM-Installation: Dies erscheint uns sehr aufwändig bzw. auch sehr schwierig 2. Zweite Instanz der CRM-Datenbank: Würde das helfen, und wie würde man vorgehen? 3. Mandant duplizieren? Würde das überhaupt helfen? Die Anpassungen an vorhandenen Masken wären doch vermutlich für beide Mandanten wirksam, da diese ja in der selben Datenbank liegen, oder? 4. ? welche möglichkeiten gäbe es noch?
für eine dauerhafte Test- und Entwicklungsumgebung würde ich auf jeden Fall das CRM und den SQL-Server von der Produktivumgebung trennen, z.B. durch virtuelle Server über Hyper-V.
Denkt aber in so einem Fall daran, das auch für eine Test- und Entwicklungsumgebung Lizenzkosten anfallen können.
Wenn ihr keine tieferen Entwicklungen mit PlugIns oder anderen tiefgreifenderen Programmierungen vornehmt, könnt ihr auch einfach eine weitere Organisation einrichten. Anpassungen an den Masken und die Daten sind zu 100 Prozent getrennt und stehen in getrennten Datenbanken.Viele Grüße
Michael Sulz
axcentro GmbH
MVP für Microsoft Dynamics CRM
Als Antwort markiertCSN22Montag, 31. August 2009 12:15
Also meiner Meinung nach ist der schnellste Weg mittels z. B. VMware Converter ein P2V Abbild des Produktivsystems zu ziehen und das dann in einer VM bzw. auf dem ESX(i) laufen zu lassen ohne Netzwerkverbindung. Somit hast Du ohne viel Installationsaufwand eine identische MSCRM Entwicklungsumgebung.
wenn ihr eine Enterprise-Installation des CRM-Servers habt, also beliebig viele Organisationen (Mandanten) anlegen könnt, ist der einfachste weg, einfach einen 2. Organisation anzulegen, die bisherigen Anpassungen aus dem Produktivsystem zu exportieren und anschließend in den neuen Mandanten zu importieren.
Anpassungen sind immer Organisationsspezifisch und sind nicht automatisch in anderen Organisationen vorhanden.
Best Practice ist es, eine eigene Test- und Entwicklungsumgebung aufzubauen, die idealerweise auf einem eigenen CRM-Server und einem eigenen SQL-Server liegt. Da gibt es die verschiedensten Varianten, die alle ihre Vor- und Nachteile haben.
Es hängt unter anderem davon ab, ob ihr die Umgebung dauerhaft benötigt, oder nur für den Übergang.Viele Grüße
Michael Sulz
axcentro GmbH
MVP für Microsoft Dynamics CRM
@Wizard_Aut Hmm, aber nur den CRM-Server zu konvertieren, wird ja nicht reichen. Es muss ja auch ein Domänencontroller, ein ActiveDirectory, etc. vorhanden sein.
@Michael Sulz Wir haben CRM 4.0 Enterprise im Einsatz. Das mit dem Mandanten wäre evtl. eine Möglichkeit, wenn die Anpassungen immer organisationsspezifisch sind.
für eine dauerhafte Test- und Entwicklungsumgebung würde ich auf jeden Fall das CRM und den SQL-Server von der Produktivumgebung trennen, z.B. durch virtuelle Server über Hyper-V.
Denkt aber in so einem Fall daran, das auch für eine Test- und Entwicklungsumgebung Lizenzkosten anfallen können.
Wenn ihr keine tieferen Entwicklungen mit PlugIns oder anderen tiefgreifenderen Programmierungen vornehmt, könnt ihr auch einfach eine weitere Organisation einrichten. Anpassungen an den Masken und die Daten sind zu 100 Prozent getrennt und stehen in getrennten Datenbanken.Viele Grüße
Michael Sulz
axcentro GmbH
MVP für Microsoft Dynamics CRM
Als Antwort markiertCSN22Montag, 31. August 2009 12:15
