NilsK

Moin, naja, am Ende kommt das darauf an, was du denn erreichen willst. Jeder VM eine eigene physische Karte zu geben, ist sehr unüblich. Kann man machen, braucht man aber nur selten. In deinem Szenario könntest du eine vierte (fünfte, sechste ...) VM ja nur noch unter Bruch des Konzeptes unterbringen. Sollen die VMs in getrennten Netzwerken laufen? Da du nur einen einfachen Switch ohne VLANs hast, vermutlich nicht. Sofern DHCP in dem Netzwerk aktiviert ist und die VM-Gastbetriebssysteme für DHCP konfiguriert sind, bekommen sie natürlich von dort eine IP-Adresse. Was genau meinst du mit "die zwei VMs sind unheimlich langsam"? Gruß, Nils

Moin, was "OK" und was "besser" ist, hängt von den Anforderungen ab. Zu denen hast du nichts gesagt. Technisch ist das grob so möglich. Beachte, dass du für Schulungen die Umgebung auch lizenzieren musst. Die VLANs kannst du dir allerdings sparen - wenn alle VMs auf dem Host laufen, geht der Traffic zwischen denen überhaupt nicht auf die Netzwerkkarte. Gruß, Nils

Moin, mehr als 1 DC, egal ob virtuell oder physisch, ist für Umgebungen mit mehr als, sagen wir, zehn Usern Pflicht. Dass die Replikation Fehler erzeugt, tritt so gut wie nie auf, es sei denn, man legt es mutwillig darauf an. Wenn aber der einzige DC ausfällt, kann niemand mehr arbeiten. Und man verlasse sich da nicht auf "Sicherungen gesamter VMs" - die werden in solchen Umgebungen oft in einer Weise erzeugt, die Zeit und Geld kostet, aber kein Recovery ermöglicht. Und wenn dann der DC nicht wieder hochkommt und man keinen zweiten hat ... dann wird es schwierig für das Unternehmen. Gruß, Nils

Moin, naja, dazu kann man nur den Artikel zitieren, den du oben selbst angeführt hast: Da in den meisten Umgebungen ein solcher Test eher unter "Overkill" laufen dürfte, würde ich entweder nichts ändern (ist am einfachsten) oder auf 64KB gehen (was heute für die meisten Workloads empfohlen wird, weil man es bei fast allen Anwendungsfällen eher mit größeren Datenmengen zu tun hat und dadurch die I/O-Zugriffe dann weniger werden). Früher wurde für SQL Server auch 8 KB empfohlen, weil das der Pagesize der Datenbank entspricht. Hat sich aber wohl als nicht optimal herausgestellt für die meisten Umgebungen. Aber um es noch mal zu betonen: Wenn es keine weiteren Anhaltspunkte gibt (und das bedeutet: belastbare Messergebnisse), dann würde ich mir um diesen Aspekt außerhalb von Enterprise-Szenarien nur geringe Gedanken machen. Gruß, Nils

Moin, ich denke, mit einer einfachen Textdatei wird sich das nicht sinnvoll lösen lassen. Darüber hinaus wäre hier aber auch die rechtliche Frage zu beachten: Diese Form der Protokollierung könnte in Deutschland rechtswidrig sein. Gruß, Nils

Moin, klar geht alles - der Hinweis war wohl auch eher, dass es nicht ausreicht, einfach zwei DHCP-Server im Netz zu betreiben. @bill_mustermann: Mir scheint, als solltest du dir mal einen kundigen Berater ins Haus holen. Verfügbarkeitskonzepte sind nicht trivial. Zuerst sollte man sich über seine Anforderungen im Klaren sein, und die sollten realistisch sein und sich an den Geschäftsprozessen orientieren. Hört man in der IT nicht so gern, ist aber so. Gruß, Nils

Moin, die Frage ist auch, ob auf der Ebene überhaupt Optimierungsbedarf besteht. Die allermeisten Systeme kommen mit dem Standardwert (wo auch immer der liegt, hab ich grad nicht im Kopf) problemlos aus. Nur wenn I/O tatsächlich ein Thema für die Datenbanken ist, kommt die Clustergröße überhaupt ins Blickfeld. Also, was soll die Installation denn leisten? Gruß, Nils

Moin, solche Konstrukte sind in der Theorie zwar möglich, in der Praxis aber meist nicht nutzbar. In deinem Fall würden in der Theorie Schreibrechte für die Nutzer des "Briefkastens" ausreichen (funktioniert auch erst mal). Die praktische Nutzung wird aber meist daran scheitern, dass man es nicht einfach wie gewohnt mit einem Editor, dem Explorer usw. nutzen kann, sondern nur über einen bestimmten (für Endanwender meist umständlichen) Weg die Daten dort abgeliefert bekommt. Dann kommt aber noch dazu, dass der Benutzer, der eine Datei in dem "Briefkasten" abgelegt hat, zwar nicht mehr ohne Weiteres da rankommt. Tatsächlich ist er aber Besitzer der Datei, darf sie also sehr wohl noch ändern. Wenn er also weiß, wie er rankommt, kann er ändern, löschen usw. Auch das kriegt man in der Theorie verhindert, aber damit wird das irgendwann kaum noch real nutzbar sein. Gruß, Nils

Moin, es hilft wenig, irgendwelche Techniken in die Runde zu werfen, wenn die Anforderungen und die Rahmenbedingungen nicht bekannt sind ... Hier ist der TO gefragt. Gruß, Nils

Moin, abgesehen davon, ist DFS für die meisten Dateitypen auch nicht als Verfügbarkeitstechnik geeignet, weil es nach dem "Last Writer Wins"-Prinzip arbeitet: Zwei Replikate "wissen" nichts voneinander. Ändert jemand das Replikat 1 und jemand anders das Replikat 2, so überschreibt einfach die letzte Dateiversion die ältere. Gruß, Nils

Moin, in dem Skript wird ein Netzwerkzugriff versucht. Im Fall eines Computer-Startskripts würde also das Computerkonto diesen Zugriff ausführen. Vermutlich fehlen diesem die Zugriffsrechte auf die Freigabe. Gruß, Nils

Moin, naja, das Schicksal ereilt uns ja alle. ;) Gruß, Nils

Moin, solche Dinge sind immer etwas schwierig, wenn jemand von "drüberklatschen" spricht (ein solcher Vorgang ist mir nicht bekannt) und nicht näher benannte "Seiteneffekte" anführt, die begründen sollen, warum etwas "nicht erwünscht" sei. Geht's etwas genauer? Immerhin ist das Vorgeschlagene ein Verfahren, das sich praktisch überall sonst bewährt. Zudem kommt es eigentlich ohne Aufwand und Fehlerquellen aus. EIne Replikationslösung, wie du sie beschreibst, ist sicher möglich. Sie wird aber tief in die Datenbankstruktur eingreifen müssen und erfordert daher sehr hohen Aufwand. Was man genau machen müsste, lässt sich ohne detaillierte Kenntnis der Datenbank und der Applikation(en) nicht sagen. Gruß, Nils

Moin, wie meinen? Gruß, Nils

Moin, Backup der Datenbank auf Server1 erzeugen und auf Server2 wiederherstellen. Gruß, Nils

Moin, prima, danke für die Rückmeldung! :) Gruß, Nils

Moin, 0180 4 100 100(20 Cent/Verbindung aus dem dt. Festnetz, Mobilfunk max. 42 Cent/Minute) Gruß, Nils

Moin, wieso ist der Dienst dort deaktiviert? Standardmäßig sollte der auf "Manuell" stehen und laufen, wenn ich nicht ganz falsch liege. Ach so, und den Host in die Domäne aufnehmen, ist meistens eine gute Idee (wie Zahni schon sagt). Gruß, Nils

Moin, wenn du die NTFS-Berechtigungen so gelassen hast, wie sie waren, existierten ja wahrscheinlich auch noch Berechtigungen, die zum Schreiben oder Erstellen berechtigten. Die musst du natürlich entfernen. Meist schaltet man auf dem "ersten" Ordner die Vererbung ab und trägt dann nur die wirklich zu berechtigenden Gruppen ein, in deinem Fall also die RW-Gruppen mit Schreibzugriff und die RO-Gruppen mit Leserecht. Zusätzlich kann man noch die Administratoren aufnehmen, damit sie - wenn gewünscht - leichter administrieren können. Verweigern solltest du nur im extremen Ausnahmefall. Da Verweigern die anderen Rechte übersteuert, kommt es sonst schnell zu unerwünschten Effekten. Gruß, Nils

Moin, du sollst ja auch eine normale PowerShell-Konsole nehmen, nicht die EMS. Gruß, Nils

Moin, seit zwei Tagen gibt es für sowas (und verwandte Fragen) ein sehr (!) umfassendes Skript: http://www.jhouseconsulting.com/2015/01/02/script-to-create-an-overview-and-full-report-of-all-group-objects-in-a-domain-1455 Das Skript hat noch einen Fehler in Umgebungen ohne Exchange, aber das trifft bei dir ja nicht zu. ;) Gruß, Nils

Moin, und wenn man schon dabei ist, dann übersetzt man die lokalen Original-Berechtigungen gleich in Berechtigungen für AD-Objekte ... Gruß, Nils

Moin, erstens soll ein DC ja kein RAS-Server sein. Ein DC ist ein DC. Punkt. (Ebenso ist ein Router ein Router. Auch Punkt.) Zweitens ist innerhalb einer AD-Umgebung niemals ein DNS-Server anzugeben, der nicht zu der AD-Umgebung gehört. Natürlich gilt das auch für VPN-Verbindungen. Und auch wenn die Internetverbindung für das LAN über einen Windows-RRAS-Router hergestellt wird, gilt nichts anderes. Den DNS-Server des Providers kann man im internen DNS-Server als Forwarder eintragen. Niemals aber direkt bei Clients oder Servern. Gruß, Nils

Moin, das wirst du dir dann selbst bauen müssen. Wie oben schon gesagt: Da jedes CRM-System seine eigenen Datenstrukturen hat, muss man zumindest die "Leseseite" eines solchen Tools, Skripts oder was auch immer ohnehin eigens entwickeln. Zu der Grundlogik "nimm per SQL die Felder X, Y und Z aus der Tabelle ABC und schreibe sie per Exchange Web Service oder wie auch immer nach Exchange" wird man dann ja auch noch die Frage beantworten müssen, wie denn die Aktualisierung geschehen soll ... also im Detail alles nicht ganz so trivial. Gruß, Nils

Moin, wäre es evtl. ein Ansatz, eine View zu bauen, die die Daten enthält, und eine Abfrage darauf für das DTSX-Paket zu nehmen? Gruß, Nils