All posts by Gregor Reimling

Verlust der MySQL-DB`s

Durch die Migration von 32 auf 64Bit sind die MySQL-DB`s verloren gegangen. Das Backup hat leider nicht geklappt und erst danach wurde festgestellt, dass die DB`s beschädigt sind. Der Versuch einer Wiederherstellung auf dem Volume schlug fehl.

Glücklicherweise sind kaum Daten verloren gegangen. Allerdings hat der Serverblog ordentlich gelitten, da ausgerechnet hier der größte Zeitraum fehlt und in diesem Zeitraum einiges passiert ist.

Es wird mit verschiedenen Tools versucht, die DB`s noch wiederherzustellen. Ob dies klappt, ist ungewiss.

Entfernen von Exchange 2003

1. Zunächst musste der Connector WE2K7 -> WEB1 entfernt werden

2. Danach wurden die Empfängerrichtlinie auf den vorhandenen Exchange 2007 und auf den DC 2008 umgestellt.

Nach den beiden genannten Schritten kann der Exchange 2003 über Systemsteuerung -> Software entfernt werden. Bevor der Computer endgültig heruntergestuft und gelöscht wird, sollte noch eine Funktionsprüfung des vorhandenen Exchange 2007 durchgeführt werden.

Voila der gute Exchange 2003 ist entfernt.

Gesamtstrukturebene auf 2003 heraufgestuft

Soeben wurde die Gesamtstrukturfunktionsebene auf 2003 heraufgestut. Bisher war nur die Domänenstrukturfunktionsebene heraufgestuft.  Vorgegangen wurde nach dem Microsoft KB-Artikel: http://support.microsoft.com/kb/322692/de

  • Klicken Sie in der Konsolenstruktur mit der rechten Maustaste auf Active Directory-Domänen und Vertrauensstellungen, und klicken Sie auf Gesamtstrukturfunktionsebene heraufstufen.
  • Klicken Sie unter Wählen Sie eine verfügbare Gesamtstrukturfunktionsebene auf Windows Server 2003 und dann auf Heraufstufen
  • SAN Zertifikate mit der eigenen CA

    Folgender Befehl wurde auf Zertifikatsserver ausgeführt:

    certutil -setreg policyEditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2

    Ergebnis:

    S:DomainTools>certutil -setreg policyEditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2

    SYSTEMCurrentControlSetServicesCertSvcConfigurationF1NaL-CAPolicyModulesC
    ertificateAuthority_MicrosoftDefault.PolicyEditFlags:

    Alter Wert:
      EditFlags REG_DWORD = 11014e (1114446)
        EDITF_REQUESTEXTENSIONLIST — 2
        EDITF_DISABLEEXTENSIONLIST — 4
        EDITF_ADDOLDKEYUSAGE — 8
        EDITF_BASICCONSTRAINTSCRITICAL — 40 (64)
        EDITF_ENABLEAKIKEYID — 100 (256)
        EDITF_ENABLEDEFAULTSMIME — 10000 (65536)
        EDITF_ENABLECHASECLIENTDC — 100000 (1048576)

    Neuer Wert:
      EditFlags REG_DWORD = 15014e (1376590)
        EDITF_REQUESTEXTENSIONLIST — 2
        EDITF_DISABLEEXTENSIONLIST — 4
        EDITF_ADDOLDKEYUSAGE — 8
        EDITF_BASICCONSTRAINTSCRITICAL — 40 (64)
        EDITF_ENABLEAKIKEYID — 100 (256)
        EDITF_ENABLEDEFAULTSMIME — 10000 (65536)
        EDITF_ATTRIBUTESUBJECTALTNAME2 — 40000 (262144)
        EDITF_ENABLECHASECLIENTDC — 100000 (1048576)
    CertUtil: -setreg-Befehl wurde erfolgreich ausgeführt.
    Der Dienst “CertSvc” muss neu gestartet werden, damit die Änderungen wirksam wer
    den.

    Weitere Domaenencontroller Basis 2008 R2

    Es wird ein weiterer Domaenencontroller aufgesetzt um existierende Probleme mit Direct Access evtl. zu loesen. In dem Zuge wird die Domaene darauf vorbereitet, in dem auf dem DC2 ein adprep32 /forestprep und ein adprep32 /domainprep ausgefuehrt wird.

    Meldungen:

    Die aktuelle Schemaversion ist 44.
    Schema wird auf Version 47 aktualisiert.
    Verbindung mit “DC2” wird hergestellt

    Adprep hat die gesamtstrukturweiten Informationen erfolgreich aktualisiert.

    Adprep hat die domänenweiten Informationen erfolgreich aktualisiert.

    Installation DirectAccess auf F1NaLWDA1

    Windows Server 2008 R2 auf F1NaLWDA1 installiert. Die Einrichtung der meisten, benoetigten Funktionen wurde bereits vorgenommen. Als Vorlage diente dabei der Step by Step Guide Direct Access von Microsoft.

    Leider ist wieder das gleiche Problem aufgetreten, dass der DNS-Server nicht erreichbar waere. Tatsaechlich konnten Konnektvitaetsprobleme festgestellt werden, ein Ping via IPv6 laesst sich nicht realisieren.

    Zunachst wurde der DC als erster DNS auf dem DA-Server eingetragen, brachte aber keinen Eroflg. Eine Ueberarbeitung des DNS brachte auch nichts. Naechste Schritt ist die Installation eines weiteren Doemaenencontroller auf Basis von Server 2008 R2.

    Upgrade ESXi 3.5 auf 4.0

    Remote wurde ein Upgrade des derzeitigen ESXi 3.5 auf die Version 4.0 durchgeführt.

    Dazu wurde zunächst die ESXi-Release-Upgrade.zio von VMware runtergeladen.

    In dem ZIP-Archiv ist auch der neue VSpehre-Client enthalten zu finden unter: VMware-viclient.vibdata.tar.gzdata.tar.4.0.0clientVMware-viclient.exe

    Bei der Installation des Clients sollte natuerlich ausgewaehlt werden, dass vSphere Host Update Utility 4.0 ebenfalls mitinstalliert wird.

    Nach der Installation kann das Programm uber das Start-Menue aufgerufen werden. Dort den Host eintragen, Upgrade auswaehlen und einige Zeit warten.

    Fuer die Aktualisierung muss ich der Host im Maintenance-Mode (Wartungsmodus) befinden. Nach einem NEustart kann man sich mit dem neuen Client verbinden und oben sollte bereits die 4.0 angezeigt werden.

    Nagios Server überarbeitet 12.08.2009

    Zuerst wurde das Shutdown-Script eingerichtet, damit die überwachten Server bei einem Neustart an den Nagios-Server eine Meldung senden, über eine geplante Downtime.  Zunächst gab es Fehler die auf die Nichtbeachtung der Groß-/Kleinschreibung zurückzuführen waren.

    Die Hosts wurden nun alle, in den Nagios-Configs, Großgeschrieben. Außerdem wurde im Script Ucase eingetragen.

     Danach wurde erfolgreich ein Update auf die derzeitige Stable-Version Nagios 3.2.0 durchgeführt. Das Shutdownscript wurde getestet und funktioniert nun Einwandfrei. Auch Kommentare lassen sich nun einfügen.