Daim

Hier kannst du noch die Besonderheiten bei einem SBS nachlesen ;) : Yusuf`s Directory - Blog - Die Besonderheiten eines Small Business Server`s (SBS)

Nein, dann nicht. Den Dienst hast auch sicherlich nicht du deaktiviert, sondern ein Assistent vom SBS. Da der SBS ohnehin ein etwas anderer Server im Verhalten (bezgl. der Assistenten), als der normale Server ist, hat einer der Assistenten den Dienst wegen "nicht notwendig" deaktiviert. Du musst nur darauf achten, wenn ein weiterer DC an einem anderen Standort aufgestellt werden soll, dass dieser Dienst aktiviert wird.

Servus, Ismserv steht für "Intersite Messaging Service", zu deutsch "Standortübergreifender Messagingdienst".

Dieses ist --> technisch <-- in einem Single-Domänen Forest nicht zwingend notwendig. Der Benutzer kann sich auch ohne einen GC anmelden. Erst wenn es mehrere Domänen im Forest gäbe, ist es zwingend notwendig das GCs existieren. Yusuf`s Directory - Blog - Globaler Katalog (Global Catalog - GC) Nein, natürlich nicht. Das macht der DC von alleine.

Servus, du könntest es mit WINK aufzeichnen: Wink - [Homepage] Das ganze sieht dann wie folgt aus: http://72.15.222.142/blogs/faq-o-matic/artikel/roeder/roeder-abe.swf Du musst nochmals überprüfen ob mit WINK der Sound aufgezeichnet wird, denn bei den Elfen ist das sicherlich gewünscht

Bonjour, dann verschiebst du zum einen Die Rolle "mit Gewalt" und zum anderen, entfernst du den gecrashten DC mit NTDSUTIL oder ADSIEdit aus dem AD. Ausser dem RID-Master können alle weiteren Rollen auch über die GUI gewaltsam verschoben werden. Wenn du es über NTDSUTIL machen möchtest, dann geht das mit "seize". Siehe: Yusuf`s Directory - Blog - Die FSMO-Rollen verschieben Ich denke schon ;) . Wenn der PDC-Emulator fehlt, dann funktioniert z.B. dieses nicht mehr: - Zeitabgleich - Kein Zugriff bzw. bearbeiten der GPOs - Kennwort-Änderung der Benutzer wird zum Problem - Externe Trusts

Servus, aber natürlich doch. Deshalb sollte man doch zwei DCs in jeder Domäne einsetzen, genau aus gründen der Redundanz. Du könntest zwar das System State vom anderen DC auf den defekten DC einspielen, bekommst aber dann erstmal weitere Probleme wegen der Registry. Denn mit sichern des System States, wird auch die Registry mitgesichert in der bekanntlich auch Hardware- sowie Treiberinformationen enthalten sind. Das kann man zwar mit einer Reparaturinstallation wieder gerade biegen, ich persönlich würde einen anderen Weg gehen. Stelle zuerst sicher, dass der "gesunde" DC die FSMO-Rollen hat. Trägt er diese nicht, dann liegen diese auf dem "defekten" DC und diese solltest du zuerst mit Gewalt auf den gesunden DC verschieben. Yusuf`s Directory - Blog - Die FSMO-Rollen verschieben Auf dem gesunden DC sollte auch der globale Katalog aktiviert sein: Yusuf`s Directory - Blog - Globaler Katalog (Global Catalog - GC) Auf dem defekten DC entfernst du das AD mit DCPROMO /FORCEREMOVAL: Yusuf`s Directory - Blog - Das Active Directory gewaltsam vom DC entfernen Anschließend entferne den defekten DC mit NTDSUTIL oder ADSIEdit aus dem AD: Entfernen von Daten aus Active Directory nach fehlgeschlagener Domänencontroller-Herabstufung Zum Schluss kannst du den Server erneut zum DC stufen: Yusuf`s Directory - Blog - Einen zusätzlichen DC in die Domäne hinzufügen

Ich hoffe das das nicht ironisch gemeint war ;) . OK, dann wurde das also genauer untersucht. Ich zitiere mich mal selbst: "...dann ist das mit dem Replkationsaufkommen schon genauer zu prüfen." Wenn Leitungen die > 1 GBit bestehen, dann ist das AD-Replikationsaufkommen völlig egal. Da bei dieser Bandbreite die AD-Replikation kaum auffallen wird. Wenn das WAN eine Geschwindigkeit wie ein LAN zur Verfügung stellt (100 M/Bit), braucht man die AD-Replikation schon nicht mehr zu berücksichtigen. Die Möglichkeiten wann der Infrastrukturmaster zusammen mit einem GC auf einem DC liegen darf, habe ich bereits in meiner ersten Antwort erläutert. Brauchst du nicht für mich. Und um nichts anderes ging es mir ;) . Wie gesagt, die Möglichkeiten hatte ich bereits erläutert.

Salut, Wie kann ich den Pfad zum Home-Folder mehrerer Benutzer (oder auch andere Werte) ändern? - faq-o-matic.net Die Bezeichnung (welche eigentlich?) kannst du mit DSMOD oder ADMOD ändern. Active-Directory-Massenoperationen mit AdMod und AdFind - faq-o-matic.net Zum verschieben der Benutzer kannst du z.B. DSMOVE oder ADMod verwenden.

Servus, na na na... so pauschal ist das aber auch nicht ganz korrekt. Es kommt auf die Größe des Netzwerks an und wie viele Änderungen im AD durchgeführt werden. Existiert ein weltweiter Forest (wie z.B. bei großen Konzernen) in dem des öfteren Änderungen im AD durchgeführt werden oder zusätzliche Attribute in den GC repliziert werrden etc., dann ist das mit dem Replkationsaufkommen schon genauer zu prüfen.

Buenos dias, @Squire das muss aber genauer spezifiziert werden. Wenn die Gesamtstruktur lediglich aus einer Domäne besteht, quasi ein Single-Domänen Forest, dann gibt es für den Infrastrukturmaster keine Arbeit und es spielt keine Rolle, ob der DC auch GC ist oder nicht. Denn es existieren ja keine weiteren Domänen von denen Objekte repliziert werden, die der Infrastrukturmaster vergleichen müsste. Existieren in einer Gesamtstruktur mehrere Domänen (Multi-Domänen-Forest), darf der Infrastrukturmaster einer Domäne, nicht auf einem DC liegen, der auch die Funktion des globalen Katalogs trägt, es sei denn, man deklariert jeden DC dieser Domäne zum GC. Siehe: Yusuf`s Directory - Blog - Die FSMO-Rollen verschieben @Porki Seit Windows 2000 existieren die FSMO-Rollen. Ausgeschrieben steht das FSMO für "Flexible Single Master Operations". Diese sind also flexibel und können auf andere DCs übertragen werden. Aber auch dabei gibt es einiges zu beachten, denn manchen Rollen sollten zusammenbleiben. Wobei in den meisten Umgebungen die FSMO-Rollen ohnehin auf einem DC liegen sollten. Näheres erfährst du aus dem o.g. Link. Weiterhin sind ab Windows 2000 alle DCs gleichberechtigt. Wenn das aber bis ins kleinste Detail so wäre, dann gäbe es fatale Probleme in einer Gesamtstruktur. Denn manche kritische Operationen darf dann eben doch nicht jeder DC ausführen, sondern lediglich ein DC der die entsprechende FSMO-Rolle trägt. Denn unter NT konnte lediglich der PDC Änderungen durchführen und der BDC hatte lediglich Lese-Zugriff. Ab Windows 2000 ist das eben anders geregelt. Das Schema kann nur von dem DC geändert werden, der die Rolle des Schema-Masters innehat. Die Änderungen finden dabei in erster Linie in der Schemapartition, die sich auf jedem DC befindet, statt. Fällt nun der Träger der Rolle des Schema-Masters aus, so ist lediglich der DC der die Änderungen am Schema durchführen darf, nicht verfügbar. Das Schema aber schon. Denn das befindet sich wie bereits erwähnt in der Schemapartition das in der Gesamtstruktur auf alle DCs repliziert wird. Fällt nun der DC auf dem der Schema-Master liegt aus, verschiebst du die Rolle "mit Gewalt" (seizen) auf einen anderen DC. Den gecrashten DC musst du dann noch händisch mit NTDSUTIL oder ADSIEdit aus dem AD entfernen. Entfernen von Daten aus Active Directory nach fehlgeschlagener Domänencontroller-Herabstufung

Off-Topic: Sag ich doch ;) .

Einfach den Treiber auf einen USB-Stick oder CD packen und von der Kommandozeile das Setup aufrufen. Die Installation erfolgt wie auf einem vollwertigen Server durch den Assistenten. P.S. Am kommenden Sonntag veröffentliche ich einen Artikel über den Server Core ;) .

Hi Edgar, ich mach einfach mal einen Schuss ins Blaue. Ich habe auch eine Intel on-Board (keine Ahnung welche genau) und ich hatte mir diesen Triber heruntergeladen (für Vista) und das hatte mir geholfen. Evtl. hilft es - auch wenn deine Bezeichnung dort nicht auftaucht - dir ebenfalls. Â*LAN: Treiber für Intel® PRO LAN-Schnittstellen

Servus, da gibt es keine fertige GPO. Du musst dazu ein ADM-Template verwenden und auf den Clients den Schlüssel DefaultDomainName im Pfad HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\ setzen. Siehe: Windows Article - Welcome Allgemeine Infos zum Thema ADM erfährst du aus diesem Artikel, wobei du die rote Schrift beachten solltest. Gruppenrichtlinien - Übersicht, FAQ und Tutorials Du könntest auch das Feld "Anmelden an" komplett ausblenden. Dann müssen sich die User aber mit ihrem UPN anmelden.

Moin, dito. Die zweite Sufe ? :p Support (Dienstleistung - Wikipedia) Wie immer, da gibt es keine Richtlinie. Das hängt vom Alter, Berufserfahrung, welcher Bereich (Netzwerk, Firewall oder...), welche Region usw. Man muss sich eben wie immer - gut verkaufen. Keine. Das Know-How würde ausreichen. Das man damit alleine nicht zum Vorstellungsgespräch eingeladen wird, steht auf einem anderen Blatt. Um den Job auszuführen, brauchst du aber keine Prüfung.

Mein eigenes Firmen-Laptop steht bei mir seit über einem halben Jahr auf dem Wohnzimmer-Tisch und war in dieser Zeit nicht einmal in der Domäne (auch kein VPN). Das Computerkonto handelt bei der nächsten Domänen-Anmeldung direkt ein neues Computerkonto-Kennwort aus. @guybrush Yepp, dass hast du ;) . Bei Benutzerkonten kann man das Flag des ablaufens setzen, aber so etwas gibt es nicht für das Computerkonto.

Servus, warum möchtest du das ändern des Computerkontokennworts deaktivieren? Deaktivieren kann man das unter: Computerkonfiguration -> Windows-Einstellungen -> Sicherheitseinstellungen -> Lokale Richtlinien -> Sicherheitsoptionen: - DomänenController: Änderung von Computerkennwörter verweigern - DomänenMitglied: Änderung von Computerkennwörtern deaktivieren Die letzte Einstellung muss sowohl auf Clients, als auch DCs angewendet werden. Wenn dann ein Mitglied doch versucht das Kennwort zu ändern, verweigert spätestens die erste Einstellung die Änderung. Aber wie gesagt, dazu würde ich nicht raten und ist auch nicht notwendig. Nichts besonderes. Wenn bei der nächsten Domänen-Anmeldung etwas schief gehen sollte, kann man es dann immer noch richten. Ausser das das Kennwort des Benutzers abgelaufen wäre, fällt mir nichts ein.

Bonjour, na das wird aber auch langsam mal Zeit ;) . Scheinbar nicht... Du hast folgende Migrationsmöglichkeiten: 1. Die einfachte Vorgehensweise wäre ein Inplace-Upgrade. Wenn die PDC-Hardware 2000/2003 tauglich ist, schiebst du die CD rein und aktualisierst auf das neue OS und installierst anschließend das AD. Somit bleiben dir die Benutzer- sowie Computerkonten erhalten. Das bedeutet, dann musst du keinen Benutzer neu einrichten bzw. Client in die Domäne bringen. Alles ist weiterhin mit den gleichen Kennwörtern vorhanden. 2. Wenn die PDC-Hardware für das Inplace-Upgrade nicht mehr tauglich ist, besorge dir eine aktuelle Maschine, installiere darauf das NT und bringe diesen als BDC zur NT-Domäne. Anschließend stufst du diesen im Server-Manager zum PDC, wobei dabei der aktuelle PDC automatisch zum BDC gestuft wird, und führst anschließend darauf das Upgrade durch. Die Problematik die dabei oftmals entsteht ist, dass man für die aktuelle Hardware keine NT-Treiber findet. 3. Genau wegen den Treiber-Problemen die ich im Punkt 2 angesprochen habe, biete sich eine Migration über eine Virtual Machine (VM) an. Du installierst auf einer Maschine eine virtuelle Maschine bei gleicher Vorgehensweise wie im Punkt 2 (zuerst als BDC -> dann PDC) und führst mit dieser VM die Migration durch. Das hat den großen Vorteil, dass du dir um Treiber-Probleme keine Gedanken machen musst. 4. Die letzte Möglichkeit ist die Migration, in eine ganz neue Domäne. Dabei ist dir das Tool ADMT hilfreich. Du erstellst mit einer anderen/neuen Maschine die neue 2000/2003er Domäne und migrierst mit ADMT die Benutzer- sowie Computerkonten (Clients sowie Memberserver) in die neue Domäne. Yusuf`s Directory - Blog - Benutzermigration mit ADMT v3: How-To Bei den o.g. vier Migrationsmöglichkeiten, bleiben dir ALLE Benutzerprofile erhalten. Du bekommst keinen Stress damit. Hier noch einiges zum lesen, unter anderem mit einem Webcast: Support WebCast: Microsoft Windows Server 2003: Upgrading Windows NT 4.0 Domains to Windows Server 2003 Migrating Windows NT Server 4.0 Domains to Windows Server 2003 Active Directory Migration von Windows NT 4.0 Domänen auf Windows Server 2003 Domain Consolidation and Migration Implementation Guide

Servus, der Domänencontroller wurde hoffentlich ordnungsgemäß mit DCPROMO aus der Domäne entfernt. Falls das nicht so geschehen ist, musst du noch die Leiche aus dem AD, mit NTDSUTIL oder ADSIEdit, händisch aus dem AD entfernen. Entfernen von Daten aus Active Directory nach fehlgeschlagener Domänencontroller-Herabstufung Und ja, du kannst das DC-Objekt aus "Standorte und -Dienste" einfach löschen. Wenn der DC sauber aus der Domäne mit DCPROMO entfernt wurde, ist das im Snap-In lediglich die Hülle des DCs. Das erkennt man daran, da das NTDS Settings Objekt (unterhalb des DCs) nicht mehr existiert. Daher kannst du den DC dort direkt entfernen.

Was soll das bringen? Vorallem behebt das nicht deinen Fehler. Dort sollte der Router eingetragen werden. Gehe dann den Vorschlägen von Eventid nach...

Servus, steht der SBS mit seiner echten IP-Adresse (nicht der Localhost Adresse) in seinen TCP/IP-Einstellungen drin und nicht etwa ein DNS-Server des ISPs oder gar der Router? Ansonsten ist der Fehler 1054 leider sehr vielschichtig. Daher bleibt dir nichts anderes übrig, wie den Vorschlägen bei Eventid nachzugehen: EventID.Net

Lesen ist immer gut ;) . Danke, dir auch.

Das können sie auch so. Sie müssen sich lediglich mit dem lokalen Administrator neu anmelden. Das sollte einem die Sicherheit wert sein. Jetzt lies dir diesen Satz nochmal selbst durch. Worauf ich hinaus ziele, habe ich dir Fett markiert. Was denkst du, wie darauf meine Antwort lauten wird? Das ist keine Entschuldigung. Wenn sich der Kunde mit lokalen Admin-Rechten irgendetwas einfängt, ist der Virus/trojaner lokal mit Admin-Rechten unterwegs. Dadurch kann es dann noch vieles mehr in der Domäne anrichten. Daher würde ich das für die Zukunft abstellen. Du bist aber nicht nur auf Aufträge aus, sondern auch auf die Zufriedenheit sowie Sicherheit des Kunden? Wenn der Fall X Eintritt, dankt dir das keiner.

Servus, das AD sucht sich seine Wege selbst. Anhand der Informationen (Kosten, Standortverknüpfung) die in "Standorte und -Dienste" konfiguriert sind, erstellt das AD dann die Verbindungsobjekte. Dann könntest Du die Option "Brücken zwischen allen Standortverknüpfungen herstellen" deaktivieren. Dadurch wird verhindert, dass der KCC Verbindungen erstellt, die mehrere Standorte überbrücken. Damit hält sich die AD-Replikation explizit an deine erstellten Standortverknüpfungen. Das macht z.B. Sinn, wenn das WAN nicht voll geroutet wäre, sondern eine Hub-and-Spoke Topologie bestehen würde. Es kommt auch auf die bestehenden Bandbreiten an. Du könntest alle Standorte in einer einzigen Standortverknüpfung hinzufügen oder eben, bei bestehen einer Hub-and-Spoke Topologie, zwei Site-Links erstellen wo einmal Zentrale mit StandortA und Zentrale mit StandortB repliziert. Lange Rede kurzer Sinn, die erstellten Verbindungsobjekte vom AD sind korrekt. Wenn dem nicht so wäre, würde dir das Eventlog diesen Fehler melden, dass z.B. mit DCxy nicht repliziert werden konnte. Wenn du es anders haben möchtest, musst du mit o.g. Hinweisen, Hand anlegen.