Daim

Hallo, beim Firefox stehen z.B. die Proxy-Einstellungen nicht in der Registry (leider), sondern in der prefs.js. Schau mal, ob Dir das hier hilft: "Automated deployment of Firefox with extensions, themes, and pre-configuration" http://firefox.dbltree.com/ Bzw. such mal im Internet nach Firefox ADM-Dateien.

Nur keine Scheu... ;) Mit dem Longhorn Server wird der Read-Only Domain Controller (RODC) eingeführt und dieser ist genau für diesen Fall in diesem Thread prätesteniert. In einer Aussenstelle wo der DC physikalisch nicht sicher steht/stehen kann, ist der RODC dafür gedacht. Dieser hat nur eine Lese-Berechtigung auf der Active Directory-Datenbank "NTDS.DIT". Deshalb wird auch nur einseitig repliziert, da der RODC eben nichts schreiben darf. Wenn der RODC geklaut werden würde, kann man diesen ganz einfach aus dem AD löschen und stellt danach keine Gefahr mehr da. Mit 2003 kann ein Dieb über das wochenende einen DC klauen, kompromitiert diesen DC und stellt ihn wieder zurück und keiner hat davon etwas gemerkt. Das geht mit Longhorn zum Glück nicht mehr. Hier was zum lesen: Windows Server “Longhorn”: Identity and Access Microsoft Windows Server code name "Longhorn" Home

Dann fasst Du das ganze falsch auf. Hier wurde keiner "zerpflückt". Ich betone nochmals ganz stark, ich bin hier zu jederzeit nur auf Lösungen aus. Mir ist Deine Situation schon klar und natürlich hängt vieles am Geld, man sich aber auch weitesgehend mit den zur Verfügung stehenden Mitteln behelfen. Wenn das Gebäude abbrennt, dann hilft erstmal sowieso nichts mehr... aber auch dabei kann man dann nur hoffen, dass das Backup (Bänder) ausser Haus gelagert werden. Du brauchst Dich doch nicht dafür zu entschuldigen, wir diskutieren doch sachlich. Aber dieses Thema ist wie bereits erwähnt ein Abend füllendes Thema, dass hier den Rahmen sprengen würde und mir die Finger schon weh tun ;) Ich denke zumindest, dass "etwas" rüber kam.

Cool... jetzt muss ich schon meine Antwort splitten, wegen dieser Meldung ;) Natürlich ist das reine AD Hardware unabhängig. Es ist schließlich eine Datenbank. Siehe: How to perform a disaster recovery restoration of Active Directory on a computer with a different hardware configuration Und genau hier liegt doch Dein Denkfehler. Natürlich geht das und da gebe ich Dir recht, wenn es nicht so wäre, dann wäre dies fatal. Aber es funktioniert genau so. Folgendes Beispiel: Ich habe eine Firma mit 5 Mann, diese setzen einen einzigen Server, nämlich SBS ein. Was natürlich gegeben sein muss, der SBS muss ordnungsgemäß gesichert werden, dass bedeutet, Daten müssen gesichert werden, Mailboxen, System State und was weiss ich noch alles... Wenn der SBS nun geklaut werden würde, ist es mit bestehendem Backup möglich, alles wieder herzustellen. Es ist vielleicht etwas aufwendiger durch andere Hardware, aber der Mehraufwand wäre ca. 1 Std. Aber es würde erneut laufen. Da gibt es doch so vieles.... und wenn ich den Server ankette... Das muss nman sich dann vor Ort überlegen. Ich denke das hier durch zu diskutieren würde den Rahmen sprengen. Das sollte man diskutieren.

Nee, nur ein weiterer Diskussions-Partner ;) Hier geht es nicht um verlieren oder gewinnen, ich möchte nur verstehen was Du meinst um Dir den Unmut der sich anscheinend angesammelt hat evtl. wegzuräumen und Dir eine Lösung zu präsentieren. Da stimme ich Dir zu das man das "Live" diskutieren sollte, bis auf das mit dem Bier... da bevorzuge ich eine Cola :cool: Das ist klar, bei dieser Größe ist das die Regel. Bisher alles kein Problem mit dem SBS sowie Active Directory. Nein, warum? Der SBS ist doch genau der Server für diese Größe, um aber eben auch in solchen Firmen eine Ausfallsicherheit zu bieten, ist halt ein weiterer Server/DC sehr hilferich. Wie bereits erwähnt, im Falle eines DCs reicht sogar Virtual PC. Das sollte man wirklich mal durchdiskutieren. Du solltest zur ICE (\\ice:2007 - intelligent communities for europe) erscheinen, dort werde ich höchstwahrscheinlich dabei sein. ....

Computerkonto hin oder her, die Tombstone Lifetime gibt es nur im AD und bekanntermaßen kennt NT kein AD.

Die Besonderheiten eines SBS kann man hier nachlesen: Yusuf`s Directory - Blog - Die Besonderheiten eines Small Business Server`s (SBS)

Du schreibst es selbst, mit rücksichern des System States spielt man ebenfalls die Registry zurück und genau da liegt der Hase im Pfeffer begraben. Oftmals oder besser gesagt, fällt einem natürlich erstmal auf, dass z.B. der RAID-Controller Probleme bereitet oder was weiß ich was. Danach macht man noch eine Reparatur-Installation und das System wird schon irgendwie wieder laufen Das kann man so machen und kann ja auch wunderbar funktionieren. Ich könnte damit aber nicht Leben, denn wie bereits im anderen Post geschrieben, ein Backup-Konzept sowie Disaster Recovery Plan braucht sowieso jedes Unternehmen und dieses beiden Dinge, sollten solch einen Fall abfangen. Bei Deinen beiden aufgeführen Punkten, sehe ich es genauso. Ein weitere DC her, sei es auf Client-Hardware oder Virtual PC und die Welt sieht schon besser aus. Das erläuterst Du bitte mal näher. Das wird ja immer interessanter... Bitte auch dieses erläutern und ich lasse alle meine Erfahrungen beiseite ;) Ahaa... erst aufblasen und dann kommt so etwas. Ist klar, auf Microsoft hakt man gerne rum... Ich sag nur soviel, bei einem richtig konzeptionierten Recovery Plan, ist man in wenigen Stunden wieder voll arbeitsfähig. Die Kunst ist es, genau dieses zu erarbeiten. Ein Crash kann immer und jederzeit passieren, dass lässt sich nicht verhindern. Was sich aber verhindern lässt, dass die Rücksicherung länger dauert, denn dann hat der Admin seine Hausaufgaben nicht richtig gemacht. Auch bei einem Diebstahl kann man einiges dagegen tun.

Ohauuaa... aber Hallo, hier geht es ja auch noch um einen SBS ;) Dieser muss natürlich alle Rollen inne haben.

Servus, @Urmel nicht richtig, es heißt "glauben, tut der Pfarrer" ;) Na wenn Du mich so freundlich bittest, da mich ich mich mal ein ;) @chrismasterlu Warum fügst Du dann nicht einen weiteren DC hinzu ? Die Hardware für den weiteren DC muss noch nicht einmal gut sein, ein Client-PC reicht oftmals aus, denn dieser soll nur die Domäne "sichern". Du könntest Dir natürlich auch mit Virtual PC behelfen... aber ich würde eher min. einen Client-PC - falls kein Geld für Hardware da sein sollte - als zusätzlichen DC verwenden. Ganz genau. Falsch, Du kannst weitere DCs in einer SBS-Domäne haben, diese dürfen bzw. können eben keine SBS sein, sondern z.B. Windows Server 203 Standard. Es ist sogar empfehlenswert eben einen Windows Server 2003 Standard als zusätzlichen DC in einer SBS Domäne zu haben. Wie bereits erwähnt, eine Client-Hardware bzw. Virtual PC würden es auch tun. Fakt ist, jedes Unternehmen brauch ein Backup-Konzept sowie Disaster-Recovery Plan. Diese beiden Punkte muss jedes Unternehmen für sich ausarbeiten und dabei ist es immer hilfreich, in jeder Domäne einen weiteren DC zu haben. Nur ist gut. Darum dreht sich doch alles. Jedes Unternehmen setzt seine Prioritäten. Wenn Dein Unternehmen sagt, dass bei einem Crash es nichts ausmacht, dass keine Domäne für 1-2 Tage verfügbar ist, dann ok, da brauchen wir nicht drüber zu diskutieren. Du kannst natürlich auch nur das System State sichern und bei einem crash den SBS reparieren (wenn es noch geht) und das System State zurück sichern. Z.B. sieht das bei einem Standard Server wie folgt aus: Yusuf`s Directory - Blog - Einen Server mit rücksichern des System State zum DC stufen Fakt ist, Du tust Dir und dem Unternehmen einen gefallen, wenn noch ein weiterer DC verfügbar wäre. Genau das darf eben nicht eintreffen. Klar kann man es nicht verhindern, aber man kann das ganze erschweren. Das eben der DC nicht mitten im Raum steht und das auch noch samt Backup, sondern in einem verschlossenen Raum wo nur eine begrenzte Zahl Zutritt hat usw. Aber das alles gehört zum Konzept und muss erarbeitet werden. Zum Glück entschärft sich die physikalische Sicherheit eines DCs mit Longhorn enorm. Ja, dass muss man auch. Jetzt könnte man noch Romane schreiben, aber erstens bin ich nun müde und zweitens tuen mir langsam die Finger weh ;) Hier noch einiges zum lesen: Support WebCast: Microsoft Active Directory Disaster Recovery How to perform a disaster recovery restoration of Active Directory on a computer with a different hardware configuration http://www.microsoft.com/technet/community/events/windows2003srv/tnt1-94.mspx

Buenos tardes, Das stimmt zwar, aber auch bei der Aufteilung der FSMO-Rollen, gibt es Vorgaben. Z.B. sollte der Schemamaster sowie Domänennamenmaster zusammen auf einem DC liegen (und dieser sollte auch ein GC sein). Der RID-Master sowie PDC-Emulator sollten ebenfalls auf dem gleichen DC liegen. Yusuf`s Directory - Blog - Die FSMO-Rollen verschieben

Nein. Wie denn auch ohne AD.

Hallo, wäre das nicht eine Alternative ? Active-Directory-Double als Testumgebung - faq-o-matic.net

OK, bei Windows 2000 kann man nicht das Attribut LastLogonTimestamp nutzen und auch nicht dsquery (das es nur unter 2003 gibt). Schau Dir die Skripte sowie das Tool an.

Moin, richtig, entweder im Modus "Windows 2000 pur" oder "Windows Server 2003". Ganz nach dem A - G - DL - P Prinzip. Du steckst die Benutzer (A) in den jeweiligen Domänen in eine globale Gruppe (G) und fügst diese in die Domänen Lokale Gruppe (DL) dort wo sich die Ressource befindet und vergibst auf die DL die Berechtigungen. Eine globale Gruppe kann nur Mitglieder der eigenen Domäne enthalten. Yusuf`s Directory - Blog - Gruppen

Diesen Satz liest Du bitte nochmal. Sollen wir DIR nun sagen, wie Du die DCs aus der Domäne genommen hast ? Spieglein, spieglein an der Wand .... ;) Also wenn wir hier von Domänencontrollern sprechen, dann sollten diese natürlich mit DCPROMO aus der Domäne entfernt werden. Hast Du sie ohne DCPROMO auszuführen entfernt, dann solltest Du das AD von diesen beiden Leichen, händisch mit NTDSUTIL entfernen und somit das AD bereinigen. Entfernen von Daten aus Active Directory nach fehlgeschlagener Domänencontroller-Herabstufung

Dann liegt Deine Aufgabe in "Klärungsarbeit" sowie "Überzeugungsarbeit". Versuche mit Fakten den Leuten die Augen zu öffnen und wenn Du alles erläutert hast, ist es ihnen überlassen.

Yepp, wir haben das vor einem Jahr durchgeführt. Planung ist wie immer das Ahhh und Oohhh. Allein der Transport der Server hat schon einen Tag gedauert. Jedes Umzugs-Auto, max. 3 Server (von 30) wegen Unfall-Gefahr auf der Straße.

Schau Dir trotzdem unter dem Punkt "Weitere Informationen" auf meinem Blog, die ersten fünf Artikel an.

Servus, oohhaauuuaaa.... da besteht dringend Handlungsbedarf. Bringe Deinen Usern Disziplin bei (jajaa ich weiß, sind alle resistent usw.). Wecke in ihnen das Gefühl, dass das Kennwort wie Ihr Hausschlüssel ist. Wenn Du an einem Client eine Software installierst und danach soll sich der User anmelden zum testen, drehe Dich bei seiner Kennwort-Eingabe bewusst um, damit er merkt das die Kennwort-Eingabe ein sensibler Vorgang ist. Du musst mit den Benutzern darüber reden und sie aufklären. Dann solltest Du die Kennwortrichtlinien einsetzen falls Du es noch nicht tun solltest. Dabei solltest Du auch alle Option konfigurieren, natürlich auf humane Art. Gruppenrichtlinien - Übersicht, FAQ und Tutorials Wie oft das Kennwort geändert sollte, hängt von den Anforderungen ab. Ich kenn Unternehmen die lassen wie Microsoft es empfiehlt, alle 6-8 Wochen ändern. Andere wiederum alle 3 Monate und wieder andere alle 6 Monate. Die Hauptsache ist, es wird auf alle Fälle regelmäßig geändert und entspricht einer gewissen Komplexität.

Auch falsch ;) Nennen wir es teilweise Herausforderungen, teilweise Aufgaben. Denn nicht immer ist es eine (neue) Herausforderung, sondern eine Aufgabe die man schon x-mal durchgeführt hat.

Servus, das brauchst Du nicht zwingend händisch zu machen. Du kannst das Attribut LastLogonTimeStamp nutzen. Dazu muss sich die Domäne in dem Domänenfunktionsmodus "Windows Server 2003" befinden. Das Verhalten von LastLogonTimeStamp kann im Attribut msDS-LogonTimeSyncInterval gesteuert werden. Du kannst z.B. dsquery nutzen (wobei dsquery ebenfalls LastLogonTimeStamp nutzt): Wie finde ich inaktive Computerkonten? - faq-o-matic.net Oder z.B.: Wie bekomme ich heraus, wann ein User sich zuletzt ans AD angemeldet hat? - faq-o-matic.net Entfernen kannst Du die Computerkonten, entweder mit diesem Skript: How to detect and remove inactive machine accounts Oder mit dem Tool OldCmp: OldCmp oder mit diesem Skript: Move Old Computers

Aloha, dieses hast Du bereits ausgeschlossen ? WD: Das Öffnen von Word-Dokumenten dauert sehr lange Ansonsten forste Dich mal durch die hier genannten Artikel durch: Yusuf`s Directory - Blog - Langsame Netzwerkverbindung

Merke: In der IT gibt es keine Probleme, sondern nur Aufgaben die gelöst werden müssen :p Das kommt ganz auf die Anforderung an. Im Prinzip würde ich eher zu verschiedenen Subnets tendieren. Standorte haben eben diverse Vorteile (Replikation findet komprimiert statt, Zeiten konfigurierbar usw.). Yusuf`s Directory - Blog - Domänencontroller am Standort Im MMC Snap-In „Active Directory-Standorte und –Dienste“ muss zuerst ein Standortobjekt erstellt (mit einem Rechtsklick auf Sites) und eine Standortverknüpfung für diesen Standort ausgewählt werden. Beim Einrichten des ersten Domänencontrollers in der Gesamtstruktur wird ein Standortobjekt mit dem Namen Standardname-des-ersten-Standorts erstellt, sowie die Standortverknüpfung DEFAULTIPSITELINK, allerdings ohne ein Subnetzobjekt. Beide Objekte können jederzeit umbenannt werden. Danach verschiebst Du das DC-Icon an seinen jeweiligen Standort. Wie gewünscht, kannst Du die Standortverknüpfungen konfigurieren. Dazu siehe diesen Artikel: Yusuf`s Directory - Blog - Einen Domänencontroller an einen anderen Standort verschieben Ein Standort brauch nicht zwingend einen DC vor Ort (siehe o.g. ersten Link). Die Authentifizierung kann auch über die Leitung vollzogen werden. Du kannst aber in die jeweiligen Standorte einen DC hinstellen, der die Dienste wie DNS und DHCP anbietet. Aber dieser sollte vor Ort physikalisch gesichert stehen. Ja, entscheidend dabei ist "Standorte und Dienste" und dadurch das DNS. Die Erklärung findest Du ebenfalls im o.g. ersten Link. Alles halb so schlimm ;)

Najaa... raus kam es bereits am Montag Abend (DE-Zeit). Datum vom 12.03. http://www.microsoft.com/downloads/details.aspx?familyid=95AC1610-C232-4644-B828-C55EEC605D55&displaylang=en Stimme zu.