none
Zertifikatsproblem bei Installation von Exchange 2013 auf WS DC 2008 R2 RRS feed

  • Frage

  • Hallo liebe Community

     

    Bei der Installation von Exchange Server 2013 RTM auf einem virtuellen Rootserver von Hosteurope mit Windows Server 2008 R2 Datacenter erhalte ich einen merkwürdigen Fehler. Das Internet gibt mir leider keinen Lösungsansatz für dieses Problem.

     

    Ausgangslage:

    -          Der Server wurde neu installiert mit Windows Server R2

    -          Alle Updates von Microsoft Stand 14.11.12 wurden installiert

    -          Filterpack und SP1 für das Filterpack installiert.

    -          Aktuelle Version von Framework ist auch drauf

     

    Folgende Rollen und Feautures habe ich über die Shell installiert:

     

    Import-Module ServerManager

    Add-WindowsFeature Desktop-Experience, NET-Framework, NET-HTTP-Activation, RPC-over-HTTP-proxy, RSAT-Clustering, RSAT-Web-Server, WAS-Process-Model, Web-Asp-Net, Web-Basic-Auth, Web-Client-Auth, Web-Digest-Auth, Web-Dir-Browsing, Web-Dyn-Compression, Web-Http-Errors, Web-Http-Logging, Web-Http-Redirect, Web-Http-Tracing, Web-ISAPI-Ext, Web-ISAPI-Filter, Web-Lgcy-Mgmt-Console, Web-Metabase, Web-Mgmt-Console, Web-Mgmt-Service, Web-Net-Ext, Web-Request-Monitor, Web-Server, Web-Stat-Compression, Web-Static-Content, Web-Windows-Auth, Web-WMI, RSAT-ADDS

     

    -          Der Server wurde mit dcpromo als neuen DC konfiguriert auf Basis für Server 2008 R2

    -          Das Schema wurde erweitert anhand der Installationsdaten für Exchange Server 2013 mit dem Befehl: setup /prepareshema (erfolgreich)

    -          Die AD wurde vorbereitet mit: setup /p /on:ORGANISATIONSNAME

    -          Alle Domänen (1x) wurden vorbereitet mit: setup /pad

    Nach den Vorbereitungen habe ich die Installation des Exchange Servers über die GUI gestartet. Es sollten alle Rollen und Funktionen installiert werden. Vor der Installation gibt die GUI 3 Warnungen:

     

    2x Das die Filterpacks vorhanden sein müssen

    1x Das der Benutzer, welcher das Setup ausführt, Admin sein muss.

     

    Anschliessend habe ich die Installation gestartet, da die erwähnten Punkte der Warnungen bereits erfüllt waren. Die Installation bleibt bei Punkt 7 von 14 stehen (Transport Service) und gibt den folgenden Fehler aus:

     

    Error:

    The following error was generated when "$error.Clear();

                    Install-ExchangeCertificate -DomainController $RoleDomainController -Services SMTP

     

    " was run: "The certificate is expired.".

     

    Den ErrorLog mit der notwendigen Stelle habe ich angeführt  (siehe unter).

     

    Hat jemand diesbezüglich eine Idee?

     

    Ein Freund hat die Installation genau gleich auf einem anderen VServer erfolgreich implementieren können (anderen Anbieter). Ich habe die Installation 2x auf komplett neu aufgesetztem OS versucht und einmal mit Exchange 2010. Bei Exchange 2010 hat die Installation auf anhieb geklappt!

     

    [11.15.2012 07:07:59.0306] [2] Active Directory session settings for 'Install-ExchangeCertificate' are: View Entire Forest: 'True', Configuration Domain Controller: 'sr1.iprouting.ch', Preferred Global Catalog: 'sr1.iprouting.ch', Preferred Domain Controllers: '{ sr1.iprouting.ch }'

    [11.15.2012 07:07:59.0322] [2] Beginning processing Install-ExchangeCertificate -DomainController:'sr1.iprouting.ch' -Services:'SMTP'

    [11.15.2012 07:07:59.0666] [2] Installing certificate signed by 'CN=sr1' for site 'CN=sr1'.  Certificate is valid from 11/15/2012 8:07:59 AM until 11/15/2017 8:07:59 AM.

    [11.15.2012 07:07:59.0666] [2] [ERROR] The certificate is expired.

    [11.15.2012 07:07:59.0666] [2] [ERROR] The certificate is expired.

    [11.15.2012 07:07:59.0666] [2] Ending processing Install-ExchangeCertificate

    [11.15.2012 07:07:59.0666] [1] The following 1 error(s) occurred during task execution:

    [11.15.2012 07:07:59.0666] [1] 0.  ErrorRecord: The certificate is expired.

    [11.15.2012 07:07:59.0666] [1] 0.  ErrorRecord: System.Security.Cryptography.CryptographicException: The certificate is expired.

       bei Microsoft.Exchange.Configuration.Tasks.Task.ThrowError(Exception exception, ErrorCategory errorCategory, Object target, String helpUrl)

       bei Microsoft.Exchange.Configuration.Tasks.Task.WriteError(Exception exception, ErrorCategory category, Object target)

       bei Microsoft.Exchange.Management.SystemConfigurationTasks.InstallExchangeCertificate.InternalProcessRecord()

       bei Microsoft.Exchange.Configuration.Tasks.Task.ProcessRecord()

    [11.15.2012 07:07:59.0666] [1] [ERROR] The following error was generated when "$error.Clear();

                    Install-ExchangeCertificate -DomainController $RoleDomainController -Services SMTP

     

    " was run: "The certificate is expired.".

    [11.15.2012 07:07:59.0666] [1] [ERROR] The certificate is expired.

    [11.15.2012 07:07:59.0681] [1] [ERROR-REFERENCE] Id=TransportCommonComponent___463307cc238945d98188471d1f64bc84 Component=EXCHANGE14:\Current\Release\Shared\Datacenter\Setup

    [11.15.2012 07:07:59.0681] [1] Setup is stopping now because of one or more critical errors.

    [11.15.2012 07:07:59.0681] [1] Finished executing component tasks.

    [11.15.2012 07:07:59.0681] [1] Ending processing Install-BridgeheadRole

    Donnerstag, 15. November 2012 07:47

Antworten

Alle Antworten

  •  
    > [11.15.2012 07:07:59.0666] [2] Installing certificate signed by
    > 'CN=sr1' for site 'CN=sr1'.Certificate is valid from 11/15/2012
    > 8:07:59 AM until 11/15/2017 8:07:59 AM.
     
    Da stimmt was mit der Zeit nicht... Das Zertifikat ist selfsigned, aber
    erst eine Stunde nach der Installation gültig.
     

    NO THEY ARE NOT EVIL, if you know what you are doing: Good or bad GPOs?
    Wenn meine Antwort hilfreich war, freue ich mich über eine Bewertung! If my answer was helpful, I'm glad about a rating!
    Donnerstag, 15. November 2012 16:43
  • Dank für deinen Lösungsansatz!

    Das Problem scheint zwischenzeitlich eindeutig zu sein. Ich habe die Systemzeit versuchshalber eine Stunde vorgeschoben und in einem weiteren versuch mehrere Stunden. Exchange reagiert darauf immer nach gleichem Schema:

    Die Installation führt sich gemäss Log immer genau eine Stunde vor der Systemzeit aus, erstellt jedoch das Zertifikat zur entsprechend der Systemzeit. Beispiel: Ich stelle die Systemzeit auf 18.00 Uhr und starte die Installation. Laut Log habe ich die Installation um 17.00 gestartet, das Zertifikat wird jedoch korrekt auf die Systemzeit 18.00 Uhr erstellt.

    Nun kann ich die Installation trotzdem nicht fortsetzen, da er nicht das bereits erstellte Zertifikat nimmt, sondern dieses jeweils immer neu erstellt.  Nun frage ich mich, warum Exchange immer eine Stunde hinter der Systemzeit sich ausführt, jedoch das Zertifikat entsprechend dieser Systemzeit erstellt.

    Hat jemand eine Idee?

    Donnerstag, 15. November 2012 17:31
  •  
    > Die Installation führt sich gemäss Log immer genau eine Stunde vor der
    > Systemzeit aus, erstellt jedoch das Zertifikat zur entsprechend der
    > Systemzeit. Beispiel: Ich stelle die Systemzeit auf 18.00 Uhr und
    > starte die Installation. Laut Log habe ich die Installation um 17.00
    > gestartet, das Zertifikat wird jedoch korrekt auf die Systemzeit 18.00
    > Uhr erstellt.
     
    Setz mal die Zeitzone auf UTC (Greenwich) und achte darauf, daß DST
    nicht aktiv ist...
     

    NO THEY ARE NOT EVIL, if you know what you are doing: Good or bad GPOs?
    Wenn meine Antwort hilfreich war, freue ich mich über eine Bewertung! If my answer was helpful, I'm glad about a rating!
    Donnerstag, 15. November 2012 19:30
  • Nun ist er über den Schritt mit dem Zertifikat hinweg, hat jedoch während der restlichen Installation die Zeitzone zurückgestellt L Dies passiert nun permanent und die Installation kommt gar nicht mehr zum Laufen. Rebuild steht wohl an.

    Nun muss ich es nur noch hinbiegen, dass die Zeitzone bleibt, wie ich dies gern hätte. Denn dann läuft das Teil J Hast du vielleicht hierbei auch gleich eine Idee? (Ich versuche es noch über die Regedit: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation)

    NACHTRAG: Bei der Regestry konnte ich die Einträge ändern, jedoch switchen die auch nach 1 Min zurück :( Folgende Einträge für UTC hatte ich verwendet:

    DaylightName auf "@tzres.dll,-931" setzen
    StandardName auf "@tzres.dll,-932" setzen
    TimeZoneKeyName auf "UTC" setzen



    NACHTRAG 2: Habe es soeben auch mit den Ländereinstellungen versucht. Anschliessend fallen die Einstellungen wieder zurück..
    • Bearbeitet AP-Comps Donnerstag, 15. November 2012 21:05
    Donnerstag, 15. November 2012 20:21

  • Nun ist er über den Schritt mit dem Zertifikat hinweg, hat jedoch während der restlichen Installation die Zeitzone zurückgestellt L Dies passiert nun permanent und die Installation kommt gar nicht mehr zum Laufen. Rebuild steht wohl an.


    Ist der Server schon in einer Domäne? Dann holt er sich die Zeit von den DCs...
    w32tm /syncfromflags:manual könnte das temporär abschalten, hinterher wieder /syncfroflags:domhier - aber ohne Gewähr...

    NO THEY ARE NOT EVIL, if you know what you are doing: Good or bad GPOs?
    Wenn meine Antwort hilfreich war, freue ich mich über eine Bewertung! If my answer was helpful, I'm glad about a rating!
    Freitag, 16. November 2012 09:01
  • Danke für dein Feedback.

    Der Server ist zugleich der einzige DC dieser Domäne. Wenn der Server ausserhalb einer Domäne ist, lässt sich die Zeit auch nicht anpassen. Ich werde daher in diesem Fall mal mit Hosteurope in Kontakt treten. Auf einem anderen VServer von denen habe ich dieses Problemnämlich nicht :)

    Sobald ich ein Feedback erhalte, werde ich den Post aktualisieren.
    Freitag, 16. November 2012 15:04
  • Das Problem konnte nun gelöst werden: Hosteurope hatte eine Fehlkonfig auf dem Wirtsystem. Nach dessen korrektur klappte alles mit der Installation auf anhieb.

    Danke nochmals für die Unterstützung!

    Sonntag, 25. November 2012 13:10