Upgrade 2011 --> 2013 - Mit vorhandener Bereitstellung...

... verbinden oder upgraden.

Ich bin es mal wieder. Ich weiß nicht, ob ich falsch suche oder ob es wirklich kaum Erfahrungsmomente/Guidelines zur besagten Installation gibt.
Ganz davon abgesehen, dass ich derzeit Verbindungsprobleme mit dem SQL Cluster habe (was wohl auf einen Konfigrationsfehler zurückzuführen ist), habe ich Bedenken, was dann passiert.
Kann ich beide Systeme parallel betreiben und sie "teilen" sich die config-DB und Organisations-DBs? Kann ich solange E-Mail-Router und Reporting Service auf der 2011er Version stehen lassen, ehe ich das 2013er für die Mitarbeiter bekanntgebe und erst kurz zuvor auch diese upgraden?

Mein Hauptproblem ist dabei: Wir haben nur diese eine SQL Server Instanz und da liegt das 2011er CRM bereits drin. Das setup weigert sich jedoch die Config-DB ggf. umzubenennen, falls bereits eine Datenbank mit dem Namen CRM_Config vorhanden ist.
Einen Ausfall für mehr als ein paar Stunden (wenn überhaupt) kann ich mir allerdings auch nicht leisten...

Hallo,

du kannst auf einem SQL Server in einer SQL Instanz nur eine CRM Version betreiben, da diese sich die COnfig DB teilen.
Allerdings kannst du ja auf einem SQL Server mehrere SQL-Instanzen anlegen und in einer anderen Instanz wird dann eine neue Config DB angelegt.

Den Email Router kannst du auf der 2011er Version stehen lassen, das ist kein Problem. Was ich dir nicht beantworten kann ist die Frage mit den Reporting Services auf einem SQL Cluster, da habe ich keine Erfahrung. Du könntest aber die eine zweite Installation auf einem anderen Server der Reporting Services vornehmen und diese übergangsweise für das neue CRM verwenden, dann sollte auch hier ein parallelbetrieb möglich sein.

Zunächst einmal vielen Dank Michael!

Wir haben es zwischenzeitlich, sagen wir mal, vielleicht etwas unkonventionell gelöst.
Irgendjemand hatte auf der Testmaschine gleich in die Vollen gegriffen und die Developer Edition installiert. Das beißt sich allerdings etwas mit unserer Standard-Edition auf dem Cluster. Also haben wir, wie hier gehandelt: viewtopic.php?f=65&t=24597 und die Datenbanken entsprechend durch das Skript anpassen lassen.
Erst nur als Testlauf gedacht, habe ich dann die Unternehmens-DBs auf dem Cluster wiederhergestellt und sie wie beschrieben: https://community.dynamics.com/crm/f/117/t/120322.aspx dem CRM bekannt gemacht.
Kommen wir nun zum sicherlich nicht supporteten Teil: Der Config-DB. Die wurde natürlich auch auf dem Cluster wiederhergestellt. Nur ohne Eingriff in die Registry des (neuen) CRM kann ich keine zwei Instanzen auf einer SQL-Instanz laufen lassen.
Der Trick ist: Die zweite, neue Config-DB direkt umzubenennen und diesen Namen im Registry-Eintrag anzugeben.
Ich befürchte allerdings deswegen, dass es unsupportet ist, da die Config-DB ja nicht mehr dem Namensschema folgt, Eingriffe in die Registry nötig waren und damit weitere Upgrades möglicherweise nicht sauber durchlaufen, sofern sie nicht der Registry folgen, sondern einem einprogrammierten Namensschema.

Weiteres Manko an dieser Stelle: Ich habe noch immer nicht herausgefunden, wie ich die Servernamen im Bereitstellungsmanager ändere. Dort steht noch immer der zu Beginn verwendete SQL-Server und nicht der aktuelle.

Hallo,

das umbenennen der Config DB wird mit Sicherheit dazu führen, das du kein Update auf eine höhere Version durchführen kannst.
Auch werden wahrscheinlich Standard Updates Probleme bekommen.

Wenn möglich würde ich diese so schnell wie möglich ändern. Spätestens bei einem Support-Call bei MS wird sich der Support sofort zurückziehen und auf die unsupportete Anpassung verweisen.

Dass der Spaß nicht supportet sein wird, habe ich bereits geahnt.
Derweil ist es auch nur übergangsmäßig geplant. Sobald die alte Instanz abgeschaltet wurde, wird auch wieder nach Namenskonvention gearbeitet.