Probleme nach inplace upgrade einer 2003 Standard CA auf 2008 Enterprise CA

Wir haben gerade an einer Anfrage gearbeitet und sind dabei (aller Wahrscheinlichkeit nach) auf einen Bug gestoßen. Da ein Fix in Form eines Update-Paketes vermutlich nicht in absehbarer Zeit erscheinen wird (dazu später mehr) möchten ich dies hier kurz beschreiben. Und um es gleich Vorweg zu nehmen: das Problem als solches und eine mögliche Lösung sind schon im PKI-Blog eines Kollegen beschrieben – Kudos gehen also direkt a ihn und allen PKI-Interessenten kann ich diesen Blog wärmstens empfehlen. Ich werde aus diesem Grund das Problem auch nur noch ganz knapp hier erneut beschreiben:

Wird ein inplace upgrade (dabei wird das Setup manuell aus der laufenden Windows-Sitzung gestartet und nicht von der CD gebootet) von einem Server 2008 Standard Edition mit einer CA auf einen Server 2008 Enterprise Edition mit der entsprechenden Enterprise CA durchgeführt, dann sind die V2- und V3-Vorlagen nicht verfügbar. Diese sind nicht für ein Standard CA implementiert aber eben im Umfang der Enterprise CA. Der Fehler scheint hier in der Setup-Routine zu liegen da ein Flag nicht korrekt gesetzt wird. Dadurch wird die CA nicht als Enterprise CA erkannt und folglich sind die Vorlagen nicht zugänglich.
Mit dem folgenden certutil-Kommando wird das Flag korrekt gesetzt (der CertSvc-Dienst muss abschließend neu gestartet werden, damit die Änderungen übernommen werden):

certutil -setreg ca\setupstatus +512

Das Problem wird derzeit noch untersucht und von daher schreibe ich gerade recht vage. Aber solange wir hier noch nichts genaueres wissen, müssen wir eben etwas schwammig bleiben.

Was bisher geschah: besagter Kollege ist über das beschriebenen Verhalten gestolpert, hat sich über seine Wege an die Spezialisten bei der Produktgruppe gewandt und dort wurde dies recht schnell als Bug klassifiziert und entsprechend in die Datenbanken eingetragen. Nun kam – völlig unabhängig von diesen Geschehnissen – eine Supportanfrage eines Kunden zu uns, welches exakt dieses Verhalten beschreibt. In unseren internen Datenbanken war dies bisher noch nicht dokumentiert und mehr zufällig sind wir auf den Blog-Eintrag gekommen. Die dort beschriebene Vorgehensweise hat das Problem dann auch direkt behoben. 

Was uns neben dem Bugeintrag eben noch gefehlt hat ist eine Dokumentation zu diesem Problem. Denn der Bug alleine – in seiner bisherigen Form – bringt nicht automatisch einen Fix. Nach meiner Einschätzung hat ein Fix (in Form eines Paketes) schlechte Karten, denn der Fehler liegt – Stand heute – ja in der Setup-Routine des Upgrades. Somit müsste dies auch auf dem Installationsmedium behoben werden. Solche Änderungen kommen erfahrungsgemäß dann bei Neuauflagen der Datenträge, wenn z.B. ein Service Pack integriert wurde. Einem Update-Paket, welches nach dem Upgrade installiert werden muss räume ich auch nur geringe Chancen ein, denn die (im oben verlinkten PKI-Blog) beschriebene Lösung ist ein Dreizeiler in einer (elevated) CMD. Dies umzusetzten nimmt mit Sicherheit weniger Zeit in Anspruch, als sich den Patch herunterzuladen und auf dem betroffenen System zu installieren. Ganz abgesehen davon, dass das Update im Kern nichts anderes machen würde…  ;)

Daher haben wir einen KB-Artikel dazu verfasst, denn sowas wird von Kunden eher als “offiziell” bewertet als ein Blog-Eintrag. Dieser Artikel-Entwurf durchläuft jetzt die üblichen Prozesse und wird dann hoffentlich auch veröffentlicht werden. Das entscheidet letztenendes die Produktgruppe, die dies derzeit auch recherchiert. Einen aktuellen Status dazu werden wir an dieser Stelle posten.

.olaf

 Nachtrag:
(03. Feb. 2009)
Der KB-Artikel musste einige Hürden nehmen und ist nun als rapid publishing article verfügbar:

https://support.microsoft.com/kb/967332

 .olaf