NilsK

Moin, das stellst du dir zu einfach vor. Eine Domäne ist nicht dazu da, um subnetübergreifende Namensauflösung zu gewährleisten. Sie dient zur einheitlichen Verwaltung der Benutzer und Geräte in einem Netzwerk. Ganz im Gegenteil musst du die Namensauflösung sicherstellen, damit die Domäne überhaupt funktioniert. Mir ist nun noch nicht ganz klar, was du überhaupt erreichen willst und was die Rahmenbedingungen sind. Warum sind die Subnetze aufgeteilt? Warum müssen die verteilten Geräte zusammenarbeiten? Warum muss eine Namensauflösung mit Computernamen funktionieren? usw. Gruß, Nils

Moin, was genau meinst du mit "mandantenfähig"? Je nachdem, was da gewünscht ist, kommt u.U. ein Großteil der am Markt befindlichen Systeme nicht in Frage (zumindest nicht ohne Anpassung). Daher bräuchten wir da eine nähere Einordnung. Gruß, Nils

Moin, zwei Produkte, die ich für empfehlenswert halte: Zertificon Z1 enQsig Gruß, Nils

Moin, ja, du musst wie immer dazu die Domäne aktualisieren. Das ist, wenn man es in Ruhe macht, aber unkritisch. Der Server-Manager macht das ab Windows Server 2012 auch von selbst, es sind keine manuellen Vorarbeiten nötig. Prüfe allerdings vorher, ob deine Applikationen mit einem W12R2-DC klarkommen. Zwar gibt es nur sehr selten Supporteinschränkungen durch neue DC-Versionen, und tatsächliche Probleme gibt es noch seltener. Man sollte das aber natürlich trotzdem vorher wissen. Exchange etwa ist ein Kandidat, der sich erstaunlicherweise seit einigen Versionen da ziemlich anstellt: [Exchange Server Supportability Matrix: Exchange 2013 Help] http://technet.microsoft.com/library/ff728623%28v=exchg.150%29.aspx Lizenzrechtlich dürfte es unproblematisch sein, denn mit CALs für Windows Server 2012 dürfen die Anwender bzw. Endgeräte auch auf Windows Server 2012 R2 zugreifen. Gruß, Nils

Moin, auch in diesem Jahr wird es in Lingen eine IT-Veranstaltung aus der Community und für die Community geben: [CIM Lingen | community in motion - Start] http://www.cim-lingen.de/ Twitter: @cimlingen Ja, ich bin dabei. ;) Schöne Grüße, Nils

Moin, auch weiterhin gilt die Empfehlung, mindestens einen DC pro Domäne physisch zu halten oder zumindest unabhängig von der zentralen Virtualisierungsumgebung. Sonst hat man genau das "Henne-und-Ei-Problem", wenn die Virtualisierungsumgebung mal komplett ausfällt. Für ein schnelles (oder schnelleres) Recovery sollte das AD unabhängig von der VM-Umgebung verfügbar sein. Das gilt auch weiterhin, unabhängig von der Virtualisierungsplattform oder deren Version. Alle "weiteren" DCs kann man gut virtualisieren, solange man ein paar Dinge nicht tut (vor allem Snapshots und P2V). Im Wesentlichen hat sich hieran nichts geändert: [Darf man einen Domänencontroller virtualisieren? | faq-o-matic.net] http://www.faq-o-matic.net/2011/02/28/darf-man-einen-domnencontroller-virtualisieren/ Gruß, Nils

Moin, sorry, aber das ist nicht recht nachvollziehbar. Durch deine Beschreibung steigt man nicht ganz durch. Daher nur eine allgemeine Antwort: Das Trennen einer Datenbank entfernt diese aus der Verwaltung durch den SQL Server. Sie wird also quasi aus dem SQL Server gelöscht, aber nicht von der Platte entfernt. Gruß, Nils

Moin, mag sein, hat aber immer noch nix mit dem Problem zu tun. ;) @Navy: Ich bezweifle, dass deine Interpretation richtig ist. Der Standby-Speicher wird rein als Cache verwendet und freigegeben, sobald ein Prozess gezielt Speicher anfordert. Dass dies zu einer Verzögerung im Sekundenbereich oder gar in der von dir vermuteten Größenordnung führt, ist ausgesprochen unwahrscheinlich. Ich würde die Ursache woanders vermuten. EIne Verögerung von einer halben Minute in Outlook spricht eher für I/O-Timeouts oder sowas. Dass erst nach dieser Zeit RAM angefordert wird, dürfte einfach auf die Verarbeitungsreihenfolge zurückzuführen sein (Outlook fordert erst dann Speicher an, wenn es soweit ist, ihn zu nutzen) als auf eine Verzögerung im Memory Management. Am Ende ist das aber auf dieser Ebene nur Kafeesatzleserei. Wenn du intensiv mit Anwendungen wie Outlook arbeitest, können 2 GB in der Tat heute zu knapp bemessen sein. Möglich aber eben auch, dass das Problem woanders liegt und "mehr RAM" an dieser Stelle keine Lösung gibt. Gruß, Nils

Moin, grundsätzlich kannst du per GPO einzelne Laufwerksbuchstaben ausblenden. Das ist dann aber reine Kosmetik - der Explorer zeigt sie halt nicht an, auf anderem Weg (direkte Pfadeingabe im CMD etwa) kommt man noch ran. Wenn es um Sicherheit geht, musst du das mit Zugriffsberechtigungen regeln. Gruß, Nils

Moin, schön, dass es wieder geht. Hier noch ein paar Hinweise zu DNS - ohne korrekte DNS-Konfiguration kann AD nicht ausfallsicher arbeiten. [Was muss ich beim DNS für Active Directory beachten? (Reloaded) | faq-o-matic.net] http://www.faq-o-matic.net/2007/01/09/was-muss-ich-beim-dns-fuer-active-directory-beachten-reloaded/ Eine Bitte aber an die Diskussionsteilnehmer: Bitte nicht einfach mal so das "Seizen" oder Übrtragen der FSMO-Rollen empfehlen, wenn die Situation noch gar nicht geklärt ist. Nicht erreichbare FSMO-Rollen sind für so gut wie kein Problem verantwortlich, dafür kann das unkoordinierte Übertragen aber echt fiese Probleme erzeugen. Gruß, Nils

Moin, ja, das ist so. Das ist allerdings keine Besonderheit von Hyper-V, sondern eine grundsätzliche Betrachtung bei der Virtualisierung. Aufgrund der Bedeutung des AD für den Netzwerkbetrieb sollte immer eine Instanz des AD außerhalb des (einzigen) Virtualisierungssystems laufen. Das ist so natürlich nicht richtig. Gruß, Nils

Moin, Ich würde vor allem sagen, dass man auf Grundlage der vorliegenden Informationen kaum Sinnvolles zu dem Problem beitragen kann. Beim SQL Server kann "mangelnde Performance" an ca. Tausend Sachen liegen. Wir wissen ja noch nicht mal, was die Datenbank da eigentlich macht. Da kann man schlicht keine Einschätzung abgeben, wo das Problem liegen könnte und was der TO falsch macht. Gruß, Nils

Moin, selbst wenn jemand den Datenträger noch hat, darf er ihn dir natürlich nicht zur Verfügung stellen ... Aber vielleicht kommst du hiermit weiter, ganz unten sind manuelle Schritte genannt. [MSXFAQ.DE:Deinstallation] http://www.msxfaq.de/server/e2kremove.htm Gruß, Nils

Moin, eine knappe, aber aussagekräftige Darstellung hab ich auf die Schnelle nicht gefunden. Im folgenden Link lässt sich aber das Wichtigste ablesen. [How Interactive Logon Works: Logon and Authentication] http://msdn.microsoft.com/de-de/library/cc780332%28v=ws.10%29.aspx Ich stelle es hier noch mal kurz (und stark vereinfacht) dar: Der User beginnt die interaktive Anmeldung im Anmeldebildschirm des Windows-Clients und gibt dazu seinen Anmeldenamen und sein Kennwort ein. Die Local Security Authority (LSA) bildet einen Hash über das Kennwort und sendet den Usernamen und den Hash an den zuständigen DC zur Überprüfung. Wichtig: Das Kennwort selbst wird nie übertragen. Der DC prüft die Anmeldung (Konto und Kennwort-Hash). Ebenso prüft er, ob für das Konto Anmeldebeschränkungen vorliegen (Zeit, Rechner usw.). Wenn die Anmeldung gestattet ist, stellt er ein Kerberos-Ticket aus und sendet es an den Client. Ebenso stellt der DC die Liste der anzuwendenen Gruppenrichtlinien zusammen und übermittelt diese ebenfalls an den Client. Die LSA stellt das Access Token für den User aus, in dem seine Security ID (SID) und die SIDs aller Gruppen enthalten sind, denen der User angehört. (Die AD-Gruppen sind ebenfalls vom DC übermittelt worden.) Sofern ein Roaming Profile für den User definiert ist, wird dieses von seinem Speicherort geladen. Der User-Desktop wird aufgebaut. Gruppenrichtlinien und Anmeldeskripte werden ausgeführt. Dies läuft in großen Teilen parallel zum Aufbau des Desktops. Gruß, Nils

Moin, äh ... ja. Ich glaube, mittlerweile haben wir uns soweit in die Tiefen der Windows-Berechtigungskomplexität vergraben, dass kein Durchblick mehr ist. ;) Gruß, Nils

Moin, welche Nachteile hat man, wenn man was macht? Gruß, Nils

Moin, dann hat man dem Dienstkonto der Backup-Software nicht die richtigen Rechte gegeben. Anders als oft angenommen, muss das Konto nicht Adminrechte haben, sondern das Benutzerrecht (Privileg) "Sichern von Dateien und Verzeichnissen". Dann kann es immer sichern, auch wenn ihm die Zugriffsberechtigung verweigert wurde. Gruß, Nils PS. Ja, wird mal wieder Zeit für ein Grundsatz-FAQ. :)

Moin, hm - jetzt verstehe ich nicht. ;) Nach meinem Verständnis schrobst du, du würdest auf Freigabe-Ebene nicht "Jeder: Vollzugriff setzen, sondern Nicht-Admins nur "Ändern". Darauf bezog ich mich und meinte, dass ich die Regel, auf Freigabe-Ebene "Null-ACLs" zu setzen, nur dann einschränken würde, wenn es konkreten Bedarf dafür gibt. Sonst wundert man sich - ähnlich dem TO hier - später drüber, warum die NTFS-Berechtigungen nicht so greifen, wie sie da stehen. Gruß, Nils

Moin, das würde ich nur dann tun, wenn es Bedarf dafür gibt. Wenn man es nicht braucht, fällt es einem sonst auf die Füße. "Jeder" ist seit Windows XP SP2 identisch mit "Authentifizierte Benutzer". Vorher galt die Empfehlung, auf die du dich beziehst (Ausnahme: Freigabeberechtigungen, siehe oben), seither nicht mehr. Und "Benutzer" sind in Wirklichkeit auch "alle" ... wenn man also etwas einschränken will, entfernt man "Jeder", "Authentifizierte Benutzer" und alle anderen Pauschalgruppen und trägt nur noch die (selbst erzeugten) Gruppen ein, die für die gezielte Berechtigung notwendig sind. Und ganz bestimmt: Für die Verhaltensänderung im hier diskutierten Fall kann ein Ersatz von "Jeder" durch "Benutzer" nicht sorgen. Gruß, Nils

Moin, äh - nö. "Jeder" enthält auch die Domänen-Benutzer, diese Änderung kann es also nicht gewesen sein. Schauen wir uns deine Zugriffsberechtigungen mal an, dann wird aber klar, woran es liegt. Du hast dir mit den Freigabeberechtigungen selbst ein Bein gestellt. Wenn man sowohl auf Freigabe-Ebene als auch auf NTFS-Ebene Berechtigungen setzt, dann gilt immer die daraus entstehende stärkste Einschränkung. Auf Freigabeebene hat "Jeder" nur Leserechte, also kann kein höherer Zugriff als "Lesen" erfolgen - egal, wieviel auf NTFS-Ebene gewährt ist. Aus diesem Grund rät man dazu, dass auf Freigabe-Ebene immer "Jeder: Vollzugriff" gelten sollte (auch bekannt als "Null-ACL", weil es effektiv keine Einschränkung gibt) und alle Berechtigungen nur auf NTFS-Ebene gesetzt werden. Nur so hat man die Gewähr, dass die NTFS-Berechtigungen 1:1 und in jeder Situation gelten. Gruß, Nils

Moin, klar, gern :) Für ein "ausführliches" Training kannst du dich gern an meinen Arbeitgeber wenden (oder mir eine PM senden). Für Kurztrainings gibt es im Herbst neue Termine, die Zeitschrift IT-Administrator (www.it-administrator.de) setzt eine neue Folge der Eintagestrainings auf. Da werden wir allerdings natürlich nicht so tief ins Detail gehen können. Gruß, Nils

Moin, naja ... hier wäre es irgendwie hilfreich zu wissen, wie die Berechtigungen aussehen und mit welchen Konto der Zugriff erfolgt - meinst du nicht? Gruß, Nils

Moin, das wird dann wohl ein Missverständnis gewesen sein. Hyper-V erlaubt kein Memory Overcommit, daher kann man gar nicht mehr Speicher verteilen, als der Host wirklich hat - im Unterschied zu (fast) allen anderen Virtualisierern. Gruß, Nils

Moin, mit der Menge an RAM im Host hat das nichts zu tun. Es geht hier um die NUMA-Anbindung der RAM-Bänke an bestimmte Prozessoren. Lässt man hier den RAM-Zugriff über "NUMA-Grenzen" hinweg zu, dann lassen sich tendenziell mehr VMs auf dem Host betreiben. Es kann aber eben sein, dass einzelne Speicherzugriffe nicht mit maximaler Geschwindigkeit laufen - so wie bei dir. Wenn dir die Performance ausreicht (was meist der Fall ist), dann kannst du das in der Tat so lassen. Wenn nicht, dann kannst du die NUMA-Konfiguration auf der Host-Ebene (nicht auf der VM-Ebene) so anpassen, dass keine NUMA-Knoten-übergreifenden Zugriffe erlaubt sind. Nebenbei: Du weißt, dass du mit einer Standard-Lizenz nur zwei Windows-Server-VMs betreiben darfst? Gruß, Nils

Moin, ich meine damit die Adressen aus dem DHCP-Scope, die der DHCP-Server aus irgendeinem Grund überspringt, statt sie zu vergeben. Vielleicht werden die ja in Wirklichkeit benutzt und sind nicht frei. Gruß, Nils