Jump to content

Medings

Members
  • Gesamte Inhalte

    42
  • Registriert seit

  • Letzter Besuch

Alle erstellten Inhalte von Medings

  1. Hallo Günther, danke für die Info. Ich werde mir den Blog mal genauer durchlesen, damit ich tiefer in die Materie komme. Grüße Medings p.s. hat übringens geklappt. Der neue DC läuft jetzt wieder zuverlässig wie der alte. Werd gleich mal ne Sicherung fahren :)
  2. Hallo Nils, danke für die Info. Ist es an dem besagten Standorten anschließend nötig, die Clients neu in die Domäne zu heben, damit diesen dann der "neue" DC bekannt ist? Grüße Medings
  3. Hallöchen, ich bin grade mit der Aufgabe konfrontiert einen DC wiederherstellen zu müssen. Wir haben insgesamt 4 Domain-Controller in unserer Server 2008 R2 Umgebung. Insgesamt 3 Sites, während in Site 1 ein prim. und ein sek. DC existieren. In Site 3 ist nun der DC irreparabel beschädigt und Backups sind auch keine vorhanden. Wie verhalte ich mich bei der Wiederherstellung jetzt richtig? Muss ich das alte DC-Konto aus dem AD entfernen und den neuen Server unter einem neuen Namen joinen lassen? Hat evtl. jemand ein HowTo oder sowas, da ich ugern die bestehende Domäne schädigen will. Habe sowas vorher noch nicht machen müssen, daher bin ich grad etwas ratlos und dachte ich frage lieber, bevor ich etwas falsch mache. Ich danke Euch schon im Voraus für Eure Hilfe. Beste Grüße Medings
  4. Hallo Friesenjunge, ein Exchangeserver bringt ab 2007 keine Outlook-Lizenzen mehr mit sich, diese müsste Dein Kunde zusätzlich erwerben. Siehe auch: MSXFAQ.DE - Pakete und Lizenzierung von Exchange Grüße Medings
  5. Einen wunderschönen Guten Morgen, ich möchte nochmal vielen Dank für die Tipps sagen. Ich hab das Problem eben lösen können. Die Berechtigungsstruktur auf dem Active Directory war verhunzt. Ich hab unter Erweiterte Einstellungen die Berechtigungen auf Standard zurückgesetzt und anschließend hat es geklappt. Grüße Medings
  6. Hallo Samsam, danke für die Antwort. Leider hab ich diesen Link schon mehrmals durchgelesen und die Einstellungen überprüft. Daran liegt es auch net. Grüße Medings
  7. Hallöchen, leider bin ich mit meinem Problem noch nicht wirklich weitergekommen. Kann es evtl. auch damit zu tun haben, dass zwischen der aktuellen Domäne (Ebene 2008 R2) und einer anderen Domäne (Ebene 2003) eine Vertrauensstellung besteht? Eigentlich kann ich es mir nicht vorstellen, aber inzwischen suche ich den Fehler an Ecken, wo ich normalerweise sagen würde, dass es damit nix zu tun haben kann. :D Grüße Medings
  8. Servus, hat der User evtl. ein manuell verbundenes Netzlaufwerk mit seinen Credentials eingerichtet? Dort müsste er nach der PW-Änderung sein neues PW hinterlegen, da Windows ansonsten versucht mit den alten Credentials das Laufwerk zu verbinden und dadurch kommt es dann zur Sperrung. Grüße Medings
  9. Hallo Dukel, der neue Server steht in der Tat an einem anderen Standort, da dieser wiederum physisch in Spanien liegt, geht das erstellen eines neuen DC um zu Testen, hier am Standort DE deutlich schneller. Habe eben einen weiteren DC in DE erstellt und auch diesen kann ich nicht hochstufen. Kommt auch wieder der Fehler mit den Berechtigungen des NTDS-Objektes. Grüße Medings
  10. Ich auch net, aber was man so in seiner Verzweiflung alles anstellt. ^^ Gut dann werd ich jetzt mal "schnell" einen neuen virtuellen DC im Standort von DC1 anlegen und gucken, obs geht. Meld mich dann nachher nochmal und werde berichten. Grüße Medings
  11. Ich glaub ich hatte Dich falsch verstanden. Meintest Du mit neuinstallieren, den neuen DC der in die bestehende Domäne hochgestuft werden soll, oder den bestehenden?
  12. Sowas in der Art hatte ich schon befürchtet. Wie sollte ich hier am besten vorgehen!? - AD Replikation zwischen den Standorten anhalten - AD sichern - Server neu aufsetzen und anschließend AD wiederherstellen - Replikation starten oder geht man anders vor? Hab sowas noch nicht machen müssen ^^ Grüße Medings
  13. Hallo Zahni, ich hatte den Server vorher in eine Testdomäne gehoben, um zu gucken, ob mit dem Server irgendwas nicht hinhaut. Hatte in sauber rein und auch wieder rausbekommen. Ich führe dcpromo mit dem Domain-Admin aus, welcher standardmäßig das Rechte für die Delegierung hat. Testweise hatte ich aber auch die Default Domain Controller Policy angepasst und dem Admin explizit eingetragen. Leider auch ohne Erfolg. Grüße Medings
  14. Hallöchen, ich beschäftige mich nun seid einer geschlagenen Woche mit der Thematik, einen weiteren DC in meine Domäne einzubinden. Erstmal zu meiner Umgebung: - virtuelle Win Server 2008 R2 Ent mit neuesten Updates - Funktionseben auf 2008 R2 - bestehende Domäne mit 2 Standorten und 3 DCs - Standort 1 (STD1) hat 2 Server (DC1 und DC2) von denen einer alle FSMO Rollen hält - Standort 2 (STD2) hat einen einzelnen Server (DC3) - Replikation unter den Servern läuft ohne Probleme Als erstes hab ich einen neunen Standort (STD3) unterhalb meiner Site angelegt und das entsprechende Subnetz angelegt und verknüpft. Wenn ich nun auf dem neuen Server (DC4) dcpromo ausführe, bekomme ich folgende Fehlermeldung: Einen Ausschnitt aus den Logdateien auf dem neuen DC hab ich angefügt. Das dcpromo wurde mit dem Domain-Administrator-Konto, welches auch die anderen Standorte eingebunden hatte, durchgeführt. Was habe ich bisher getestet bzw. überprüft: - dem Administratorkonto als auch dem Computerkonto via GPO das Recht für Delegierungszwecke anvertraut - dcpromo ausgeführt als der Server Mitglied der Domäne war und ohne - dcpromo ausgeführt als die AD-Rolle bereits installiert und nicht installiert war - DNS-Auflösung von DC1 zum DC4 und andersrum - dcdiag auf dem dc1 ausgeführt <- alle Tests bestanden Ich habe ebenfalls ausschließen können, dass es an einer Firewall o.Ä. liegt, da ich selbst einen DC im selben Netz auf der selben VM nicht hochstufen kann. Die Einträge im DNS macht er auch selbstständig. Inzwischen bin ich echt verzweifelt und weiß nicht mehr weiter. Kann mir evtl. jemand einen Tip geben, an welcher Stelle ich noch gucken könnte!? Grüße Medings dcpromo.txt dcpromoui.txt
  15. Den meisten hier im Forum geht es wohl genauso wie mir!? :D Grüße Medings
  16. Hallöchen, ich habe gerade leichte Probleme meine Backup-Teststellung vernünftig in Betrieb zu nehmen. Genauer gesagt schlagen die inkrementellen Sicherungsvorgänge fehl (kein anhängbares Medium gefunden). Habe selber schon gegoogelt wie nen Weltmeister, allerdings nichts passendes gefunden. Unser System: - Win Server 2008 R2 SP1 Ent - aktuellster Patchlevel - Backup Exec 2010 R3 - aktuellster Patchlevel Sicherungsvorgang: - Backup 2 Disc Ordner, testweise auf die zweite Partition des Servers angelegt - Mediensatz definiert (Überschreibschutz 0h; Anhängezeitraum unbegrenzt) - 1xwöchentlich ein Vollbackup <- funktioniert auch - 4xwöchentlich inkrementelles Backup <- funktioniert nicht Ich komm irgendwie nicht dahinter, warum er das Medium des Vollbackups als nicht anhängbar markiert, da ich ja im Mediensatz was anderes angegeben hab und das Medium auch mit diesem verknüpft wird. Ist evtl. jemandem dieses Verhalten bekannt und kann mir einen Tipp geben!? Grüße Medings
  17. Sch****... :cry: Manchmal sieht man den Wald vor lauter Bäumen nicht. Danke für Deine schnelle Hilfe. :D Grüße Medings
  18. Hallöchen, bin mir grade nicht ganz sicher, ob ich im Exchange- oder doch eher Outlookbereich richtig bin. Zu meinem Problem: Wir setzen im Unternehmen einen als Server einen Exchange 2010 ein. Auf den Clients befindet sich Win 7 Outlook 2010. Beide Seiten sind auf dem aktuellen Updatestand. Wir haben einige Raumpostfächer auf dem Exchange erstellt, welche ansich auch funktionieren (autom. Annahme von Besprechungen etc.). Wir haben nun das Problem, dass der Betreff der Besprechung im Kalender des Raumpostfachs durch den Namen des Organisators überschrieben wird. Bisher habe ich es wie folgt nachvollziehen können: Client schickt Besprechung ab <- korrekter Betreff Eintrag im Kalender Client <- korrekter Betreff Anfrage am Raumpostfach kommt an <- korrekter Betreff Mail bezgl. Annahme der Besprechung <- korrekter Betreff Eintrag im Kalender des Raumpostfachs <- falscher Betreff Selbst wenn ich auf dem Kalender die Berechtigung für Standard auf "Besitzer" stelle, wird der Betreff überschrieben, daher würde ich ein Berechtigungsproblem seitens des Kalenders des Raumpostfachs ausschließen. Hat jemand schon das selbe Problem gehabt und kann mir sagen was da falsch läuft!? Grüße Medings
  19. Manchmal sieht man den Wald vor lauter Bäumen nicht. Da ist es dann hilfreich nen gutes Forum zu kennen, wo die Leute Ihr Wissen und Ihre Erfahrungen auch mit einem teilen. ;) Grüße Medings
  20. Hallo Norbert, sorry für die späte Antwort, hatte Deinen Post aber erst jetzt gesehen. Der RPC-Schlüssel und der Eintrag haben wirklich gefehlt und seit ich bei diesen den Wert 1 gesetzt habe funktioniert es auch. Die Geschichte mit dem Autodiscover werd ich mir aber trotzdem angucken. Bin noch dabei den richtig einzustellen und an der Stelle den Durchblick zu bekommen. :D Grüße Medings
  21. Hi, kam das selbe bei raus... Würde mich an Möglichkeit 1 machen. Kennst Du evtl. ein gutes HowTo? Auf jeden Fall erstmal nen fettes Danke für Deine Hilfe. Auch an Norbert natürlich. ;) Grüße Medings
  22. Servus, beim ping passiert gar nix... beim nslookup löst er den zuständigen domain-controller auf, aber es kommt zum Time Out... Den Domain-Controller hingegen kann ich aber anpingen
  23. Hab RPC over HTTP rausgenommen und der Fehler tritt noch immer auf. Jap NB ist im selben LAN wie der Exchange.
  24. Hallo Steven, hab das Profil komplett entfernt und neu von Hand eingerichtet. Wenn Outlook startet verbindet er den Benutzer mit dem Exchange und fängt an die Kopie des Postfachs zu ziehen. Nachdem er das komplette Postfach gezogen hat und der Status auf "Alle Ordner sind aktualisiert" springt, kommt nen paar Sekunden später wieder die Eingabeaufforderung für BN und PW. Folgende Einstellungen hatte ich vorgenommen: Cached Modus aktiv, Netzwerksicherheit bei der Anmeldung: Kennwauth (NTLM), Verb. mit Exchange über HTTP (externe URL für Zugriff auf OWA <- ohne /owa), Haken bei Nur SSL..., Haken bei Verbindung nur mit Proxy (msstd:externe URL ...), Haken bei Bei langsamen Netzw. üner HTTP und Proxyauth (NTLM) Exchange sowie Client haben bereits die neuesten Updates. Grüße Medings
×
×
  • Neu erstellen...