NilsK

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

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. :)