NilsK

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

Moin, anders wird ein Schuh draus: NIEMALS den Wizard nehmen, der ist völlig untauglich. Wenn es ohne kommerzielle Tools sein soll und eher "einmalig" eingerichtet werden soll (sich also nicht ständig was ändert), ist die Kombination von dsacls und LIZA meist brauchbar. Auf jeden Fall braucht man ein separates (!) Testlabor. Wenn die Anforderungen noch nicht geklärt sind, sollte man so ein Projekt auch noch nicht anfangen. Auch die Auswahl eines Tools ist erst sinnvoll, wenn die Anforderungen klar sind. Da wirklich nützliche Tools meistens fünfstellig kosten (oder mehr), sollte man hier schon ziemlich gut wissen, was man denn braucht. Gruß, Nils

Moin, unter anderem deshalb fragte ich ja, wer auf was zugreifen soll. Wenn es nur ganz bestimmte Ressourcen sein sollen (also z.B. nur wenige Servernamen betroffen sind), könntet ihr z.B. nur einen Teil der DNS-Daten übertragen, beispielsweise manuell in eine Standardzone. Dann kommt die B-Domäne gar nicht auf die Idee, dass es in der A-Domäne mehr als zwei DCs geben könnte. Wenn es um "irgendwelche" Ressourcen an beiden Standorten gehen soll und sich an den Namen oder IP-Adressen oft was ändert, ist das aber u.U. nicht praktikabel. Gruß, Nils

Moin, na, wenn die Kommunikation zu dem Standort, der nicht erreicht werden soll, gar nicht möglich ist, dann braucht ihr auch nichts weiter zu machen. In einer Vertrauensstellung ist es nicht erforderlich, dass auf jeden AD-Standort zugegriffen werden kann. Wichtig ist, dass die Domäne als solche erreicht wird, sprich mindestens ein DC. Gruß, Nils

Moin, was ist die Anforderung dahinter? Und wer soll am Ende von wo nach wo auf Ressourcen zugreifen können? Sind alle Standorte per Routing untereinander erreichbar? Gruß, Nils

Moin, naja, das einzige Problem, das ich dort technisch vermuten würde, träte auf, wenn jemand über den gezeigten DNS-Server Namen auflösen will, die der DNS-Server über die nicht funktionierende Delegierung abfragen muss. Da würde dann halt keiner antworten. Wie wahrscheinlich das ist, kann ich aufgrund der Schwärzungen in dem Bild nicht einschätzen. Gruß, Nils

Moin, das ganze DNS-Design solltet ihr noch mal überprüfen. Mir wird aus den Beschreibungen und der Grafik nicht ganz klar, was der Aufbau soll: Wieso eine Single-Label-Zone namens "local"? Warum überhaupt Delegierungen? Wie ist das Konstrukt gedacht? usw. - das ist in einem Forum nicht sinnvoll, das sollte man intern klären, ggf. mit externer Beratung. Rein technisch betrachtet, kannst du das Ziel einer Delegierung natürlich auch ändern, indem du einen anderen Server dort einträgst. Ob das Sinn ergibt, hängt vom Konzept ab, siehe oben. Gruß, Nils

Moin, naja, etwas wollten wir den GPO-MVPs ja auch noch übrig lassen. Gruß, Nils

Moin, verabschiede dich von dem Gedanken, dass "Sicherheit" in der IT nur etwas mit externem Zugriff zu tun habe. Die meisten Angriffe kommen technisch gesehen "von innen". Und es müssen ja auch gar nicht unbedingt bewusste Angriffe sein - wenn es du*m kommt, reicht ein bisschen falsches Klicken schon aus. Also, auch wenn es wie großer Umstand aussieht: Richte dir (wie du es ja anscheinend jetzt auch vorhast) jeweils eine VM als DC und als Terminalserver ein. Das ist für Stabilität und Sicherheit deutlich besser. Gruß, Nils

Moin, aus Sicherheits- und Stabilitätsgründen. Bei einem Terminalserver haben die User lokale Sessions, sie arbeiten also direkt auf dem Server. Alle Funktionen, an die User nicht randürfen, verbieten sich also auf einem Terminalserver. Umgekehrt ist ein AD-Domänencontroller die zentrale Sicherheitsinstanz. Dort haben nur Administratoren etwas zu suchen, aber keine User. Stabilität: Da auf einem Terminalserver Anwender arbeiten und dort "Client-Software" läuft, kann es schon mal vorkommen, dass der Server ausfällt oder Fehler entstehen. Hier will man die Abhängigkeit zum AD möglichst gering halten, damit nicht auch die zentrale Anmelderessource ausfällt. Ab Windows 2012 kommt hinzu, dass man auf einem Domänencontroller die RDS-Dienste (Terminalserver) nur noch mit argen Klimmzügen überhaupt installiert bekommt. Stabil läuift es dann hinterher i.d.R. nicht. Gruß, Nils

Moin, sieht völlig normal aus. Die "grauen" Ordner sind Delegierungen: Der Ordner existiert nur als Verweis (wie ein Link im Dateisystem), der Inhalt wird von einem anderen DNS-Server verwaltet. Bei _msdcs ist das schon seit mehreren Versionen so, die anderen Delegierungen sind aufgrund eurer DNS-Struktur so. Dürfte dem Eindruck nach aber völlig korrekt sein. Gruß, Nils

Moin, oh, in einem Notebook wäre das schnell. ;) Gruß, Nils

Moin, musst du das regelmäßig machen oder einmalig? Falls regelmäßig: Soll das automatisiert geschehen oder ist es eher eine manuelle Aufgabe? Falls es um manuelle oder einmalige Ausführung geht, würde ich ein Skript schreiben, das die erste Tabelle ausliest und mit Stringverkettung SQL-Kommandos generiert. Diese lässt du dir ausgeben, kopierst sie in die Zwischenablage und fügst sie als neue Abfrage ein, die dann die eigentlich gewünschten Daten liefert. Prinzip: select 'SELECT ' + [Tab1Feld2] + ' FROM ' + [Tab1Feld1] + ' WHERE ' + [Tab1Feld2] + ' = ''Mein Wert''' from [dbo].[Tab1] Gruß, Nils

Moin, korrekt. Wir hatten mal einen Fall, da hat ein Kunde "nur" alle vier Stunden ein DB-Backup erzeugt. Das Backup dauerte vier Stunden ... der Server war also immer unter unnötig hoher Last. Manchmal lief ein Backup noch, wenn das nächste starten sollte, was jedes Mal zu Fehlern geführt hat. http://www.faq-o-matic.net/2011/01/03/sql-server-wie-datenablage-backup-und-recovery-funktionieren/ Gruß, Nils

Moin, schau dire mal den Datenbankoptimierungsratgeber im SQL Server Management Studio an. Dass der Entwickler einer Datenbank gute Hinweise zur Optimierung geben kann, ist zwar richtig. Das Anlegen und Warten von Indizes gehört aber zu den Kernaufgaben eines Datenbankadministrators (DBA), weil diese Rolle mit der tatsächlichen Infrastruktur mehr zu tun hat. Gruß, Nils

Moin, gemäß lefgs Hinweis die pauschale Zuordnung des Benutzerrechts entfernen. Das reicht in dem Szenario schon aus. Dann bei Bedarf in den entsprechenden OUs der passenden Gruppe das Recht geben, Computerkonten zu erzeugen. Gruß, Nils

Moin, ich habe auch schon mal bei Hardware einen Manipulationseffekt gesehen: Da war es das Management-Modul von Bladeservern, das den Blades jeweils beim Reboot eine falsche Zeit gegeben hat. Windows hat das zwar korrigiert, aber immer erst nach ein paar Minuten. Gab lustige Effekte. Gruß, Nils

Moin, zumindest dürften Leseberechtigungen für den Ressourcenkalender kein Problem sein, dann können die betreffenden Personen auch die Details sehen. Man kann in der Buchungsautomatik ja auch eintragen, dass der Organisator in den Betreff übernommen wird. Dann wird das eine runde Sache. Gruß, Nils

Moin, grundsätzlich ist es ja überhaupt kein Problem, wenn der verfügbare Speicher genutzt wird. Dafür ist er ja schließlich da. Sieh dir dazu mal diesen älteren, aber im Kern immer noch zutreffenden Artikel von Daniel Melanchthon an: [Die grösste Angst des PC-Nutzers... - .: Daniel Melanchthon :. - Site Home - TechNet Blogs] http://blogs.technet.com/b/dmelanchthon/archive/2007/02/08/die-angst-des-pc-nutzers.aspx Kurz gefasst: Moderne Betriebssysteme nutzen den Speicher für eine ganze Reihe von Dingen, auch (bzw. gerade) wenn dieser nicht von Applikationen belegt wird. Da sie das sehr intelligent und dynamisch tun, entsteht daraus kein prinzipielles Problem. Wichtiger wäre also die Frage, was denn "zicken" und "spinnen" in deinem Fall bedeutet. Dass es ursächlich an einer Belegung des RAM liegt, kann man nahezu ausschließen. Gruß, Nils

Moin, ja, sofern es sich um die technisch passende Version und das passende Installationsmedium handelt. Gruß, Nils

Moin, steht in der Situation im Hyper-V-Manager noch etwas weiteres zum Zustand? In der ganz rechten Spalte (hab gerade den Spaltentitel nicht im Kopf) gibt es oft noch weitere Hinweise. Was sagt das Eventlog des Hosts und der betreffenden VMs? Gruß, Nils