NilsK

Moin,

eine sehr lustige Diskussion, die allerdings nicht für sich in Anspruch nehmen sollte, in irgend einer Weise zielführend zu sein.

@rep: Was du zuerst benötigst, ist ein Plan, wie du die Umgebung künftig aufbauen willst. Das wird aufwändig. Wenn der Kunde nicht bereit ist, die Planung und Umsetzung zu bezahlen und für die Zeit der Umstellung einen größeren Nutzungsausfall in Kauf zu nehmen, dann lass die Finger davon.

In Kürze: Die Domänen zu konsolidieren, wäre absolut sinnvoll, ist aber nochmal ein zusätzlicher Aufwand, der als zweiter großer Schritt geplant werden sollte. Zuerst entwirfst du ein übergreifendes IP-Design für das ganze Netz und legst ein zentrales DNS- und ein zentrales WINS-System fest. DNS richtest du auf mindestens zwei Servern so ein, dass alle wichtigen Hosts gefunden werden. Alle Rechner nutzen diese beiden DNS-Server. Da es sich um mehrere Domänen handelt, arbeitest du entweder mit statischen Einträgen oder mit "insecure updates".

Ebenfalls richtest du zwei WINS-Server ein und trägst diese bei allen Rechnern ein. Stelle sicher, dass keine Einträge in den Hosts- und LMHosts-Dateien stehen.

Gruß, Nils

Moin,

und den Pfad hättest du unter XP wie im Explorer gefunden? Auch dort hättest du wissen müssen, wofür %appdata% steht. Dein Beispiel hat mit deiner Frage herzlich wenig zu tun.

Such dir einen anderen Dateimanager und fertig.

Gruß, Nils

... nicht schon wieder so eine Traditionalistendiskussion ...

Moin,

der Witz besteht darin, dass du auf diese Weise ein rollenbasiertes Berechtigungskonzept umsetzen kannst, die Berechtigungsliste nach der Ersteinrichtung nie wieder ändern musst und schon am Gruppennamen ablesen kannst, wozu sie da ist.

Natürlich fügst du deine Globale Gruppe nicht beiden DL-Gruppen hinzu, sondern nur derjenigen, die das Recht repräsentiert, das die Globale Gruppe erhalten soll. Beispielsweise die Geschäftsleitung in "Full" und die Lehrlinge in "Read".

Im Übrigen diskutieren wir das hier alle Nase lang. Bitte nächstes Mal die Boardsuche verwenden.

Gruß, Nils

Moin,

und noch einmal: Verabschiedet euch von dem Gedanken, dass Zertifikate ohne Praxis irgend jemanden dazu motivieren, eine Person für einen IT-Job einzustellen.

Gruß, Nils

Moin,

es geht um die Ausgabe des DisplayNames des bei den Mitgliedern des Objekts Gruppen.

[...]

Dies brachte jedoch nicht den gewünschten Erfolg.

um das noch eben zu beantworten: Auch das ist mit José nicht möglich, weil er einfach nur den Inhalt des Feldes "member" ausgibt und keine Rückverfolgung der Objekte vornimmt. Für die hier gewünschte Aufgabe wäre evtl. dies ein gangbarer Weg:

faq-o-matic.net Mitglieder einer AD-Gruppe mit Zusatzdaten ausgeben

Gruß, Nils

Moin,

dein Fehler liegt darin, dass die Gruppe eben keine OU ist. José dokumentiert auf OU-Ebene, nicht auf Objektebene.

Wenn du einzelne Objekte dokumentieren oder auswerten willst, wirst du mit anderen Werkzeugen weiterkommen. Ebenso wird es nichts für Dateisysteme usw. geben, weil José genau eine Aufgabe lösen soll (nämlich die, die es löst).

Gruß, Nils

Moin,

was auch immer das Problem war, was auch immer du von uns wolltest, und was auch immer du jetzt gemacht hast ...

Schön, dass es jetzt wieder geht. Für die Zukunft empfehle ich dir aber, deine Fragen sorgfältiger zu stellen. Es war immer noch nicht nachvollziehbar.

How to ask a question

Gruß, Nils

Moin,

schaut mal so in einer Woche auf faq-o-matic.net. ;)

Gruß, Nils

Moin,

sagen wir es so: Ich habe in der Hinsicht noch nie ein Problem beobachtet.

Neben der theoretischen Betrachtung ist doch vor allem relevant, um welches konkrete Szenario es geht. Wenn tatsächlich nur 64 kbit/s zur Verfügung stehen, wird man die Initialreplikation für einen neuen DC bei einer "wirklich großen" Umgebung ja ohnehin kaum über das WAN machen. In dem Fall hat man (mindestens) zwei Verfahren:

1. den neuen DC am Hauptstandort installieren und nach der Replikation in die Außenstelle liefern
   
2. "Install from media": Ein Backup des AD in die Außenstelle liefern und dieses als Grundlage der Erstreplikation nehmen
   

In der laufenden Replikation gelten 64 kbit/s als völlig ausreichend, um einen ordentlichen Abgleich zu gewährleisten. Das ist natürlich nur ein Faustwert, weil in der Praxis noch einiges an Faktoren hinzukommt, aber auf der anderen Seite reden wir heute ja auch nicht mehr von derart schmalbandigen Anbindungen.

Also bleibt wie immer die Frage nach den konkreten Anforderungen ...

Gruß, Nils

Moin,

dein Ehrgeiz in Ehren, aber verzettel dich nicht. FISI ist eine praxisorientierte Ausbildung, und das ist auch gut so.

Gruß, Nils

Moin,

in der Regel ersteres. :cool:

Gruß, Nils

Moin,

ich rede hier auch nicht von "Probleme bekommen", sondern von "Flexibilität einschränken" und "möglicherweise in der Zukunft Probleme bekommen, ohne vorher einen Nutzen zu haben".

Begib dich nicht auf den falschen Pfad, einer VM einfach so Ressourcen zuzuweisen, nur weil sie scheinbar im Überfluss zur Verfügung stehen. Das geht schnell nach hinten los.

Gerade die Multi-CPU-Zuweisung wird in der Praxis oft falsch betrieben und führt zu vermeidbaren Folgeproblemen. In der Virtualisierung gilt der Grundsatz "so wenig wie möglich" - das ist ganz was anderes als die Überdimensionierung, an die man sich in den letzten 5-10 Jahren auf der Hardware-Ebene gewöhnt hat.

Gruß, Nils

Moin,

technisch betrachtet im Wesentlichen ja.

Ich denke, diese Diskussion hier bringt nur dann einen Mehrwert, wenn wir ein anwendbares Rechenmodell entwickeln.

Gruß, Nils

Moin,

wenn du uns Details gibst, warum du nicht weitergekommen bist ...

Gruß, Nils

Moin,

freut mich! :)

Gruß, Nils

Moin,

die "erste NIC" nach deiner Sprachregelung wird durch die Installation von Hyper-V zum virtuellen Switch. Die "zweite NIC" ist die Netzwerkkarte der Parent Partition, also des Verwaltungs-Betriebssystems (technisch betrachtet ist das auch eine VM). Der gibst du eine IP-Adresse aus deinem Verwaltungsnetz (so vorhanden) bzw. aus dem LAN, wenn du den "Host" vom LAN aus erreichen willst.

faq-o-matic.net Hyper-V, Cluster und VMM: Ein paar Detailhinweise zur Installation

Gruß, Nils

Moin,

für allgemeine Sizing-Vorschläge kannst du dir das MAP mal ansehen.

Download details: Microsoft Assessment and Planning Toolkit

Darüber hinaus ist Carlito zuzustimmen.

Gruß, Nils

Moin,

eure Diskussion in Ehren, aber bislang war hier immer die Aussage, dass solche Deutungen nur vom Lizenzgeber kommen können ...

Gruß, Nils

Moin,

ohne separate Software geht das nicht.

Gruß, Nils

Moin,

schalte erst mal den automatischen Neustart ab, damit du den Bluescreen lesen kannst. Mit dessen Nummer kannst du dann recherchieren.

faq-o-matic.net Windows-Crashdumps auswerten

Gurß, Nils

Moin,

So noch ein paar tests gemacht Normale AD Replikation scheint zu funktionieren:

gerade auf dc01 einen ordner test erstellt und dieser ist nach 5 min auf auf Server 2 zu sehen.

von was für einem "Ordner" sprichst du? Im Dateisystem oder im AD?

Mal ne ganz komsiche Theorie ist es möglich DNS zu deinstallieren und anschliessend wieder neu zu installieren? Also auf beiden dcs?

Das willst du nicht. Das wird auch nicht das Problem sein. Wenn es ungültige Einträge im DNS gibt (die ja ohnehin im AD stehen, also würde eine DNS-Deinstallation exakt nichts ändern), kannst du die manuell aufräumen. Wenn DC-Einträge fehlen, starte mal auf dem betreffenden DC die Anmeldedienste neu (net stop netlogon && net start netlogon).

Was sagt "dcdiag /e" (Ausgabe in eine Datei umleiten)?

Gruß, Nils

Moin,

wenn es keinen zwingenden Bedarf gibt, einer VM mehr als eine virtuelle CPU zuzuweisen, dann vergib auf keinen Fall mehr als eine. Sonst kannst du je nach Gesamtumgebung durchaus Nachteile erzeugen, weil der Hypervisor nicht mehr so frei bei der Zuteilung der Ressourcen ist. Wenn du nämlich z.B. vier CPUs an eine CPU zuweist, dann müssen gleichzeitig vier CPU-Kerne frei sein, damit die VM Rechenzeit erhalten kann.

Hyper-Threading hat an der Stelle keine direkte Auswirkung auf die vCPUs:

faq-o-matic.net Zwei Hyper-V-FAQs: Pagefile und Hyper-Threading

Bezüglich des Backup/Recovery kann man auf der derzeitigen Grundlage keine sinnvolle Empfehlung aussprechen. Dazu müssen die Anforderungen detailliert betrachtet werden, was in einem Forum nicht zu leisten ist.

Bedenke, dass "der ganze Server ist kaputt" nur eines von vielen möglichen Szenarien ist - wesentlich häufiger hat man es aber z.B. mit Problemen einer einzelnen Anwendung zu tun. Der Ausgangspunkt sollte also die Frage sein, welche Applikationen du in welcher Qualität wiederherstellen können musst.

Gruß, Nils

Moin,

die Installationssprache hat damit weniger zu tun. Um sicher zu gehen, dass SQL Server dein Datum richtig interpretiert, kannst du in dem Statement die Eingabesprache ausdrücklich auf US-Englisch setzen. Jedenfalls funktioniert folgendes Statement hier mit deinem Datumsformat:

set language us_english
select YEAR('May 23 2010 12:00AM')

Gruß, Nils

Moin,

dem DNS-Fehler würde ich noch mal weiter nachgehen. Prüfe insbesondere, ob die clientseitige Namensauflösung wirklich funktioniert. nslookup umgeht den normalen Resolver und ist kein geeignetes Werkzeug, um solche Sachen zu überprüfen.

Was ist vorher geschehen? Irgendwelche Änderungen an den DCs? Backups eingespielt oder gar ein Image wiederhergestellt?

Gruß, Nils

Moin,

die IP-Adresse des "Hosts" (der Parent Partition) hat mit der VM nichts zu tun. Für die VM ist die Host-Netzwerkkarte ein Switch. Die VM benötigt selbst eine IP-Konfiguration, die die nötige Konnektivität sicherstellt.

Was du mit "Feintuning" meinen könntest, erschließt sich mir nicht. Sowas hängt natürlich immer von den konkreten Anforderungen und den Details der Umgebung ab.

Das Backup-Thema ist für virtuelle Umgebungen im Zweifel sehr komplex. Wenn nichts dagegen spricht, empfehle ich eine klassische Sicherung aus der VM heraus, wie man sie auch für einen echten Server machen würde. Andere Methoden auf Host-Ebene sind zwar durchaus möglich, haben aber so viele Stolperstellen, dass man schon sehr genau wissen sollte, was man da tut.

Gruß, Nils