NilsK

Moin, naja, dann wird es schwierig ... Du könntest ein Backup des AD in einer Testumgebung wiederherstellen und nachsehen. Und künftig würde ich dann halt dokumentieren. Für den genannten Fall würde etwa ein geplanter Task reichen, der ein Skript wie folgendes ausführt: csvde -f C:\Daten\AD-Gruppen.txt -u -r "(objectClass=group)" -l sAMAccountName,objectClass,member Vorsicht allerdings: In älteren Windows-Versionen verhält sich csvde fehlerhaft und gibt bei großen Gruppen die Mitglieder nicht zurück. In dem Fall sollte es helfen, denselben Export mit derselben Syntax mit ldifde.exe auszuführen - die damit erzeugte Datei ist dann aber leider weniger gut lesbar. Alternativen: [Wie kann ich die Mitglieder einer Gruppe in eine Datei schreiben? | faq-o-matic.net] http://www.faq-o-matic.net/2004/07/30/wie-kann-ich-die-mitglieder-einer-gruppe-in-eine-datei-schreiben/ Weiterhin würde in deinem Szenario mein altes Tool Werding helfen: [Active-Directory-Daten online wiederherstellen | faq-o-matic.net] http://www.faq-o-matic.net/2006/11/19/active-directory-daten-online-wiederherstellen/ Gruß, Nils

Moin, ja, das waren noch Zeiten ... in einem AD-Migrationsprojekt im Sommer 2002 habe ich bei einem Kunden tatsächlich NT4 auf Alpha in Rente geschickt. Leider hatte ich kein Museum, um das Schätzchen zu retten. ;) Gruß, Nils ... aber wir schweifen ab ...

Moin, um welche Berechtigungen geht es? Im Dateisystem, im AD, in ...? Und: Hast du denn ein Backup, das die Berechtigungen enthält? Gruß, Nils

Moin, wobei du früher auf meiner Seite warst ... SPALTER! Schöne Grüße, Nils ... und wo ist die Judäische Volksfront?

Moin, das würde ich nun wieder nicht so stehen lassen. ;) Auch nach fast zehn Jahren ist die Einrichtung und Pflege von GlobalNames doch eher eine Krücke ohne jede Dynamik. Gruß, Nils Jehova, Jehova ...

Moin, ja, da wird wohl UAC dazwischengehen. [benutzerkontensteuerung (UAC) richtig einsetzen | faq-o-matic.net] http://www.faq-o-matic.net/2008/02/22/benutzerkontensteuerung-uac-richtig-einsetzen/ Gruß, Nils

Moin, Servernamen verbergen sich auch gern in Dokumenten, Vorlagen, Links ... zu 100 Prozent wirst du die wahrscheinlich nicht los. Nicht zuletzt aus diesem Grund rate ich auch heute noch zu WINS. Dadurch tauchen die Server natürlich auch nicht wieder auf, aber es hilft in solchen Umgebungen i.d.R., die Broadcast-Last deutlich zu reduzieren. Gruß, Nils

Moin, sofern ihr Applikationen habt, die mit kurzen Servernamen arbeiten, gleichzeitig aber kein WINS und keine GlobalNames-Zone vorhanden sind, bleibt Windows nichts anderes übrig, als die Namen per Broadcast aufzulösen. Das wäre wirklich nicht das erste Netzwerk, in dem die Absicht bestand, WINS und NetBIOS loszuwerden, und in dem dann Broadcast-Stürme entstanden. Oder um es anders zu sagen: Es ist durchaus wahrscheinlich, dass ein WINS-Server (richtig implementiert) dieses Problem beheben könnte. Gruß, Nils

Moin, Metro-Apps muss jeder User einzeln einrichten. Eine direkte Möglichkeit, sie von einem in ein anderes Profil zu übertragen, gibt es nicht. In einer Unternehmensumgebung gibt es die Möglichkeit, mit zentralen Deployment-Methoden zu arbeiten. Einen Überblick findest du hier: [Deploying Metro style apps to businesses - Windows Store for developers - Site Home - MSDN Blogs] http://blogs.msdn.com/b/windowsstore/archive/2012/04/25/deploying-metro-style-apps-to-businesses.aspx Gruß, Nils

Moin, naja, soweit ich ihn verstanden habe, will er ja genau das in seiner Testumgebung nachstellen bzw. durchspielen ... finde ich schon OK. Gruß, Nils

Moin, mit LIKE funktioniert die Abfrage aber nicht. Das Kommando, das der TO angegeben hat, würde nach den Zeichenketten "VORNAME" bzw. "NAME" innerhalb der E-Mail-Adresse suchen und nicht nach den Inhalten der so benannten Felder. Hier wäre mit Zeichenkettenfunktionen zu arbeiten. Mangels Zeit und SQL Server kann ich das aber grade nicht austüfteln. Gruß, Nils

Moin, aha, eine Firewall ist also auch dazwischen. Gut, dass du das bei der Gelegenheit auch mal erwähnst ... Wie du meinen Hinweisen ja entnehmen kannst, habe ich auch darauf hingewiesen, dass der Sicherheitseffekt bei VLANs nur durch die Firewall entsteht. Da du eine hast - okay, dann kann dadurch ein höheres Sicherheitsniveau entstehen. Aber mach dir nichts vor, damit werden die Anforderungen, die du umsetzen willst, auch nicht leichter, denn all die Komponenten müssen ja auch noch irgendwie miteinander kommunizieren. Gerade in einer Domäne kann eine falsch konfigurierte Firewall echt Ärger machen. Oben hast du gesagt, FQDN wäre nicht OK für deine Situation, jetzt plötzlich soll FQDN sogar besser sein. Naja, musst du wissen. Ich habe beigetragen, was ich beitragen kann und klinke mich dann jetzt mal aus. Gruß, Nils

Moin, wer auch immer dir eingeredet hat, dass VLANs eine Sicherheitsfunktion seien: Das ist nicht so. VLANs dienen in erster Linie der Segmentierung des Netzwerks, meist um Broadcastlasten zu reduzieren. Da du ja aufgrund deines Designs ein Routing zwischen den VLANs einrichten musst, hast du auf Ebene der Sicherheit durch die VLANs allein nichts gewonnen. Hier müsste noch eine Firewall dazukommen, wenn man das denn möchte. Die Beschreibung, die du nun gegeben hast, macht die Situation nachvollziehbar. Bitte gewöhn dir an, solche Informationen gleich mit zu geben, das erspart unnötige Rückfragen und unnötige Ratespiele. Da du nun also ohnehin eine Domäne brauchst, liegt es natürlich nahe, auch die DNS-Namensauflösung darüber zu erledigen. Die wichtigsten Stichworte dazu findest du hier: [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/ DNS hilft dir allerdings nicht bei den kurzen Namen, sondern in deinem Szenario nur für die FQDN-Namensauflösung. In deinem Fall würde ich für die Auflösung "kurzer Namen" tatsächlich WINS empfehlen, das ist am einfachsten zu implementieren und erzeugt praktisch keinen Pflegeaufwand. Installiere also auf deinem DC auch WINS und konfiguriere in allen Domänenrechnern (einschließlich des DC) die DC-IP-Adresse als WINS-Server. Und ganz ernsthaft: Es wäre sinnvoll, wenn du ein produktives Netzwerk erst aufbaust, nachdem du dir die dafür nötigen Grundlagen angeeignet hast. Auch wenn eine AD-Domäne scheinbar einfach einzurichten ist, gibt es sehr viel, was man falsch machen kann. Gruß, Nils

Moin, seit Windows Server 2008 ist der Browserdienst standardmäßig deaktiviert. Auch sonst ist eine Domäne absoluter Overkill, wenn es denn tatsächlich nur um die Namensauflösung mit kurzen Namen gehen soll. Da der TO es zu aufwändig findet, die Namen im DNS seines Routers zu pflegen und per FQDN aufzulösen, käme aushilfsweise eigentlich nur noch WINS in Betracht. Der Aufwand ist dadurch minimal geringer - man muss keine Namen mehr pflegen, aber jeder Rechner muss als WINS-Client konfiguriert werden. Und es braucht eben einen WINS-Server. All das lässt sich aber dann doch besser diskutieren, wenn man die Anforderungen kennt. Daher frug ich danach - vielleicht sollten wir erst mal eine Antwort abwarten ... Gruß, Nils

Moin, aha, OK. Das ist eigentlich nicht das, was man üblicherweise mit "mandantenfähig" meint. Da geht es meist um eine komplette Trennung einzelner Kundenbereiche, wobei von einem Kundenbereich auf einen anderen kein Zugriff bestehen darf. Was du beschreibst, gehört hingegen bei den meisten Ticketsystemen zur Grundfunktion. Ich denke mal, es geht um sowas wie einen IT-Dienstleister, der ein eigenes Ticketsystem für seinen Support betreiben will und dessen Mitarbeiter Tickets einzelnen Kunden zuordnen wollen? Wie gesagt, das können viele Systeme. Ich selbst habe mit OTRS sehr gute Erfahrungen gemacht. Das ist Open Source und gehört zu dem am meisten eingesetzten Ticketsystemen. Man sollte sich aber ausreichend Zeit nehmen, die "Denke" solcher Systeme zu verstehen, das ist schon etwas eigen. Gruß, Nils

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