NilsK

Moin, in der Regel geht das auf Smartphones nicht. Gruß, Nils

Moin, an systemeigenen Diensten würde ich so gut wie nie etwas ändern. Die haben mittlerweile schon ein hohes Optimierungsniveau, richtige "nutzlose Ressourcenfresser" gibt es da nur im Ausnahmefall. SIehe dazu auch die schon zitierte Webseite "DerFisch.de", wo es einiges zu solchen Dienste-Mythen gibt. Zudem, wie schon angemerkt, gibt es oft versteckte Abhängigkeiten. Unter XP beispielsweise war der DHCP-Client dafür zuständig, die DNS-Registrierung für AD-Clients durchzuführen - auch bei statischer IP. Auch Optimierungen à la "brauchen meine User nicht" sehe ich mittlerweile sehr skeptisch, seit ich selbst erlebt habe, wie eine übereifrige interne IT Rechner verschlimmbessern kann. Die "adaptive Helligkeit" etwa finde ich sehr praktisch und würde mich ärgern, wenn ein Admin mir die wegnimmt, weil er persönlich damit nicht arbeitet. (Hier bei mir hatte die IT lange Zeit alle Rechner in den Energie-Modus "Höchstleistung" gezwungen - als Notebook-User finde ich das eine ganz unnötige Idee, und auch bei Desktop-PCs ist das meist kontraproduktiv.) Gruß, Nils

Moin, korrekt, ein Client benötigt nur für sehr wenige Vorgänge einen direkten Kontakt zum DC. Eigentlich nur für die Anmeldung. Beim Öffnen von Dateien, auch von einem Server, jedenfalls nicht. Dafür dienen ja das Access Token und das Kerberos-Ticket. Die Netzwerkaussetzer haben also sicher nicht ursächlich mit der DC-Kommunikation zu tun. Gruß, Nils

Moin, eine einfache Antwort und eine einfache Lösung gibt es nicht. Die Transportverschlüsselung sichert nur den Transportweg von auslieferndem und annehmendem Server ab. Wie Dukel schon richtig sagt, kann es davor (im eigenen LAN) oder dahinter (im LAN des Empfängers) noch weitere Transportinstanzen ohne Verschlüsselung geben. (Es ist sogar der Normalfall.) Nach dem Transport liegen die Daten dann sowieso unverschlüsselt vor (solange keine Mailverschlüsselung im Spiel ist). Mailverschlüsselung wiederum funktioniert nur, wenn beide Partner das auch können (sowohl die Technik als auch die beteiligten Personen) und vorab eine gegenseitige Infrastruktur dafür eingerichtet haben. Da das nicht trivial ist, trifft man es immer noch sehr selten an. In der Praxis unterscheiden die meisten Kunden daher zwischen "normalem" und "vertraulichem" Mailverkehr. Für letzteren treiben sie dann je nach Möglichkeit höheren Aufwand. Die Entscheidung und Zuordnung übernimmt dann i.d.R. der Absender. Gruß, Nils

Moin, das ist i.d.R. auf Missverständnisse zurückzuführen. Manche glauben, dass durch den Umstieg von "32 Bit" auf "64 Bit" ja logischerweise die doppelte Speichermenge nötig sei, weil 64 ja nunmal das doppelte von 32 ist. Da es hier aber eigentlich um Pointer geht und nicht etwa alle Werte im Speicher einfach mal umgerechnet werden, ist das so Unsinn. Ein Byte hat auch weiterhin 8 Bit. Nur in wenigen Bereichen ist "mehr Speicher" nötig - klar, 64-Bit-Pointer belegen nun mal bis zu 64 Bit ... und vielleicht mag die eine oder andere Optimierung von 32-Bit-Systemen nicht greifen. Aber da man ein 64-Bit-System ja nun mal einsetzt, um mehr vorhandenen Speicher anzusprechen (und es dazu schlicht keine Alternative gibt), ist der Hinweis mindestens irreführend. Ein evtl. wichtiger Nachteil von x64: 16-Bit-Software funktioniert nicht mehr. Aber die hat man auf normalen Rechnern auch nicht mehr. Der Vorteil, auch bei weniger als 4 GB auf x64 zu setzen: Eine einheitliche Basis. Gruß, Nils

Moin, ich würde solche Tools auch nicht anwenden. Bereits seit Vista führt Windows selbst einiges an guten Optimierungen im laufenden Betrieb durch. Das hat den Vorteil, dass es voll supportet ist, und darüber hinaus muss man sich nicht drum kümmern. Bei solchen "Tools" läufst du immer Gefahr, dass einiges an Schlangenöl dabei ist und dass manche "Optimierungen" Stabilität, Sicherheit oder Performance beeinträchtigen. Schon dass du nicht sagen kannst, was die Software denn eigentlich tut, sollte dich skeptisch machen. Ich finde diesen älteren Artikel da immer noch aufschlussreich: [TuneUp: Wundermittel oder Placebo? | DerFisch.de] http://www.derfisch.de/tuneup-wundermittel-oder-placebo-html/ EDIT: Oh, ich sehe gerade ein Update dazu: [TuneUp: Wundermittel oder Placebo Reloaded | DerFisch.de] http://www.derfisch.de/tuneup-wundermittel-oder-placebo-reloaded/ Gruß, Nils

Moin, ich denke, die Nachfrage nach dem "Sehen" bezieht sich darauf, dass viele Admins erwarten, dass alle Computer von selbst in der Netzwerkumgebung auftauchen. Tun sie das nicht (was auch in normal funktionierenden Netzwerken immer mal vorkommt), dann vermuten sie, dass die Rechner einander nicht "sehen". Dabei hat die Anzeige in der Netzwerkumgebung nichts damit zu tun, ob die Rechner miteinander kommunizieren können (das können sie in den beschriebenen Situationen meist sehr wohl). Gruß, Nils

Moin, hm. Die bislang gegebenen Hinweise sind sicher richtig. Für eine Laborumgebung ohne Last erklären sie aber trotzdem das beschriebene Verhalten nicht. Erfahrungsgemäß sollte ein Labor mit der gegebenen Ausstattung durchaus flüssig laufen. Ich selbst habe hier ein lokales Labor auf meinem Notebook, in dem keine der VMs so zäh läuft, wie du es beschreibst. Und ich habe nur eine einzige Platte, bislang war es sogar nur eine Notebook-SATA-Disk. Noch dazu läuft Hyper-V bei mir in "Nested Virtualization", also selbst als VM. Ich vermute also, dass in deinem Labor noch irgendwas Weiteres faul ist. Einen heißen Tipp habe ich ohne nähere Analyse aber leider nicht. Gruß, Nils EDIT: Tippfehler korrigiert.

Moin, Mit "Clt" könnte "Client" gemeint sein. Abgesehen davon, stimme ich meinen Vorrednern zu. Ich wundere mich allerdings etwas über den Titel des Threads. Gruß, Nils

Moin, ich stimme Dukel zu. In dem Fall ist es sehr einfach: Neu anlegen nach Vorbild der Altdaten. Je nach Menge geht das manuell oder (bei 500) mit sehr einfachen (Batch-) Skripten. Bei 500 Usern würde ich im Leben nicht darauf kommen, mit lokalen Accounts zu arbeiten. Aber bitte, muss ja jeder selbst wissen. Gruß, Nils

Moin, lokale Benutzer und Gruppen wirst du nicht ohne Weiteres übernehmen können. Dafür gibt es im Betriebssystem keine Werkzeuge. Es gibt kommerzielle Programme für sowas, die kosten aber ziemlich viel Geld (jedenfalls die, die ich kenne). Aber vielleicht ist das ja auch gar nicht nötig. Was genau soll denn übernommen werden? Benutzerkonten - mit welchen Eigenschaften? (Insbesondere: Darf auf dem neuen System ein neues Kennwort gesetzt sein?) Gruppen? Wie viele Benutzer und Gruppen sind es denn? Daten? Was für welche? Berechtigungen? Wie komplex? Was noch? Gruß, Nils PS. Der Hinweis von Dukel ist schon berechtigt - wie du ja gerade merkst, haben lokale Konten zahlreiche Nachteile.

Moin, OK, und was ist nun genau die Frage? Gruß, Nils

Hm, viermal derselbe Fragetyp, aber nach zwei Tagen keine Antwort. Scheint also nicht so dringend zu sein. Gruß, Nils

Moin, wie sieht denn die Netzwerkverbindung zwischen den Hosts und dem Target genau aus? Und was für Disks laufen da in welcher Konfiguration? Gruß, Nils

Moin, äh ... warum so kompliziert? Und warum das Routing? Eigentlich müsst ihr auf den Hosts nur jeweils einen "externen" vSwitch anlegen, an den ihr die jeweiligen VMs anbindet. Die VMs bekommen Adressen aus demselben IP-Segment (hier also das 172-er Netz). Sofern die Hosts miteinander auf Layer 2 verbunden sind (also über denselben physischen Switch oder über zusammenhängende physische Switches), können die VMs auch von Host zu Host miteinander kommunizieren. Die IP-Adressen der Hosts und der VMs haben nichts miteinander zu tun. Hosts und VMs können in unterschiedlichen IP-Segmenten sein. In der Aufgabe steht ja auch nicht, dass die VMs mit den Hosts kommunizieren sollen. Oder übersehe ich hier gerade etwas? Gruß, Nils

Moin, einen Fehler solltest du aber nicht machen: Eine Replikation ist eine Replikation, kein Backup. Änderungen und Löschungen können versehentlich sein, werden bei einer Replikation aber auch übertragen. Gruß, Nils

Moin, wenn dir ein DC wegen defekter Netzteile aussteigt, ist das ja auch kein Grund, die FSMO-Rollen zu seizen. Am nächsten Tag hast du ja ein neues Netzteil und kannst den DC wieder starten. Solange laufen die anderen weiter. Es ist in deinem Szenario auch nicht zwingend das Seizen nötig. Das Metadata Cleanup wird vermutlich den größeren Anteil daran gehabt haben, dass es wieder lief. Eigentlich hätte es auch ohne solche Maßnahmen wieder anlaufen müssen. Warum das so nicht war (und wie man es ggf. trotzdem hinbekommen hätte), kann ich ohne nähere Untersuchung nicht sagen. Gruß, Nils

Moin, Exchange geht nicht mit Dynamic Memory. Unter 8 GB (fest zugewiesen) wirst du damit nicht arbeiten können. Punkt. Gruß, Nils

Moin, es ist mir gerade zu spät, um es zu testen, aber ich würde mal annehmen, dass man auch die Objektklasse "organizationalUnit" in dsacls angeben kann. Übrigens sollte man den Aufwand für eine produktive Umsetzung nicht unterschätzen. Es geht bei dir ja offenbar um eine Hochschule mit IdM-Integration (oder sowas), da habe ich für sowas schon Projekte mit hoher zweistelliger Anzahl an Projekttagen zugebracht. Es treten bei sowas schnell einige Besonderheiten zutage. Gruß, Nils

Moin, hier stehen die dokumentierten Limits: [Active Directory Maximum Limits Scalability Capacity] http://technet.microsoft.com/de-de/library/active-directory-maximum-limits-scalability%28v=ws.10%29.aspx Bei sehr großen Objektzahlen ist das GUI oft überfordert, weil es dafür nicht gemacht ist. Die Gruppe "Domain Users" ist eine spezielle Gruppe, deren Mitgliedschaft i.d.R. anders gehandhabt wird. Daher stehen dort normalerweise "direkt" gar keine Mitglieder drin. [AD: “Domänen-Benutzer” per LDAP abfragen | faq-o-matic.net] http://www.faq-o-matic.net/2009/01/17/ad-domnen-benutzer-per-ldap-abfragen/ Gruß, Nils

Moin, ist schon OK. Spricht ja auch nichts dagegen, mit einer Multi-Domain-Umgebung zu experimentieren. Gruß, Nils

Moin, kann man machen. Ist aber auch nicht interessanter, als das innerhalb einer Domäne zu tun. Spannender ist da schon, sich in die Berechtigungsvergabe in einer Multi-Domänen-Umgebung einzuarbeiten. Da geht es dann nämlich sinnvoll nicht mehr ohne A-G-DL-P. Gruß, Nils

Moin, auch in einer Testumgebung läuft Exchange (2010 oder 2013) unter 12 GB nicht rund. Unter 8 GB brauchst du es gar nicht erst zu versuchen, selbst dann musst du dich aber darauf gefasst machen, dass nach Neustarts usw. nicht alle Dienste von selbst laufen. Die Anleitungen im Technet sind i.d.R. schon sehr zuverlässig. Sie setzen aber natürlich sorgfältiges Vorgehen voraus, das man in einer Laborumgebung nicht immer anwendet. Gruß, Nils

Moin, naja, was soll man dazu sagen. Du gibst ja nicht an, welchen Sinn das alles hat. Ich vermute mal, es ist eine Laborumgebung zum Lernen? Dann muss man mit solchen Seltsamkeiten leben, die sind aber dann auch nicht aussagekräftig für eine echte Umgebung. Im wahren Leben hätte man ja in Ruhe geplant und auch nicht alles in zwei Stunden durchgehechelt. (Das finge dann schon damit an, dass man geprüft hätte, ob man überhaupt mehr als eine Domäne braucht ...) Also keine falschen Schlussfolgerungen ziehen. Es ist wie immer: Kaum macht man's richtig, klappt's auch. Was zum Richtigmachen gehört, muss man eben erst lernen. Das ist ganz normal. Gruß, Nils PS. Falls du jetzt mit Exchange weitermachen willst, solltest du dir dringend mehr Geduld zulegen. Exchange braucht noch mehr (Warte-) Zeit.

Moin, die AD-Standorte eines AD-Forest haben mit einem anderen Forest erst mal nichts zu tun. Der Trick mit den gleichnamigen Sites funktioniert meist trotzdem - ich würde mich aber nicht darauf verlassen, dass das auch in küftigen Versionen so ist. Und es erfordert natürlich auch Änderungen an der AD-Konfiguration, die vielleicht nicht ohne Weiteres möglich sind. Ob es am Ende euer Problem löst, lässt sich auf Basis dieser Diskussion hier nicht sagen. Es ist allerdings, wie gesagt, gar nicht nötig, dass "alle" DCs mit "allen" sprechen. Es muss halt "ein" DC im Moment der Abfrage erreichbar sein. Die Verzögerungen, voin denen du sprichst, können durchaus daran liegen, dass die vertrauende Domäne versucht, DCs anzusprechen, die sie nicht erreichen kann. Das wäre übrigens mit Wireshark oder so relativ schnell rauszufinden. Ein einfacher Weg, das Problem zu umgehen, wäre, das DNS in der vertrauenden Domäne so einzurichten, dass die nicht erreichbaren DCs der anderen Seite dort gar nicht drinstehen. Ob und mit welchem Aufwand das machbar ist, kann ich nach deinen Angaben aber nicht einschätzen. Gruß, Nils