NilsK

Moin, ich würde eine Zahl von 40 Windows-Rechnern nicht ohne AD verwalten wollen. Dadurch wird vieles einfacher und besser handhabbar. Gerade als "One-Man-Show" wäre das einer rein lokalen Verwaltung deutlich vorzuziehen. Ein AD einzuführen, ist rein technisch betrachtet erst mal nicht weiter wild. Es wird aber natürlich so einiges ändern, sowohl auf technischer als auch auf organisatorischer Ebene. DNS und IP-Adressen sind da schon eher einer der einfachen Aspekte. An deiner Stelle würde ich mal mit dem RZ sprechen, ob sie dich da konzeptionell und technisch unterstützen können. Auch wenn es kein riesiges Netz ist, solltest du ausreichend planen, damit es hinterher nicht unnötig viele Probleme und Fehler gibt. Falls das RZ dich da nicht unterstützen kann, hol dir anderweitig externe Beratung - nur Forenhilfe ist da nicht ausreichend. Gruß, Nils

Moin, erstens: Den Logoff protokolliert Windows nirgends. Zweitens: Da du dich hier in einem rechtlich heiklen Bereich bewegst (solche Protokolle sind i.d.R. mitbestimmungspflichtig und können u.U. rechtliche Probleme aufwerfen), darfst du sowas nicht einfach so umsetzen. Drittens: Die Frage ist hier schon oft diskutiert und beantwortet worden, nutze bitte die Boardsuche. Gruß, Nils

Moin, S2D erfordert eine Domänenintegration. Das gilt für nahezu alle Cluster-Konstrukte. Workgroup-Cluster, neu in Windows Server 2016, sind nur für wenige Applikationen zugelassen und für noch weniger empfohlen, S2D gehört nicht dazu. https://blogs.msdn.microsoft.com/clustering/2015/08/17/workgroup-and-multi-domain-clusters-in-windows-server-2016/ Du willst dir vielleicht den Webcast von Carsten Rachfahl ansehen: [Webinar Storage Spaces Direct Deep Dive am 20. März 2017 - Hyper-V Server Blog] https://www.hyper-v-server.de/webinar/webinar-storage-spaces-direct-deep-dive-am-20-maerz-2017/ Gruß, Nils

Moin, passt schon. ;) Gruß, Nils

Moin, man kann mit DFS-R durchaus sinnvolle Konstrukte aufbauen. Aber da DFS-R nun mal eine Reihe gravierender Einschränkungen hat, eignet es sich bei weitem nicht für jedes Szenario. Immerhin sprechen wir hier von Technik, die bald 20 Jahre alt ist und seither nur gering weiterentwickelt wurde. Und ich bleibe dabei: Es ist weder als Verfügbarkeitslösung noch als Backup gedacht. Der TO hat auch nichts von Verfügbarkeitsanforderungen geschrieben, sondern er möchte Daten auf zwei Server verteilen und diese über einen gemeinsamen Namensraum bereistellen. Das ist DFS-N. Gruß, Nils

Moin, Moment, zumindest ich habe hier nur von DFS-N (Namespace) gesprochen. DFS-R (Replikation) ist ein ganz anderes Thema. Aus verschiedenen Gründen würde ich das, wenn überhaupt, nur sehr selektiv und nach sorgfältiger Prüfung nutzen. Vor allem sollte man DFS-R nicht für einen Backup- oder Verfügbarkeitsmechanismus halten - das ist es beides nicht. Gruß, Nils

Moin, ich finde das hier ziemlich eindeutig und sehe meine Vermutung bestätigt, dass Office eine vollständige Desktop-Sitzung braucht. Auch wenn wir hier nicht direkt von einem Server-Szenario sprechen, scheint mir die fehlende vollständige Desktop-Sitzung der springende Punkt zu sein. https://support.microsoft.com/en-us/help/257757/considerations-for-server-side-automation-of-office Gruß, Nils

Moin, wenn du das so siehst, können wir das ja für die Zukunft beenden. Freunde wirst du dir damit nicht machen. Plonk. Gruß, Nils

Moin, in der Tat, der Beschreibung nach sollte es so sein, dass diese Option ein Log-Backup ausführt. Ich habe mit dem DPM nichts zu tun, bin daher damit nicht vertraut. Dann wäre es denkbar, dass bei dem TO durchaus ein Log Backup stattfindet und also die nicht mehr benötigten Teile des Logs gelöscht werden. Anders als bei Exchange führt dies aber nicht dazu, dass die Log-Datei schrumpft. Sie behält "von selbst" immer ihre Größe oder wächst bei Bedarf an. Sie verkleinert sich aber nicht von selbst, sondern hat nur "freien Platz" innerhalb der Datei. Das müsste man bei Bedarf selbst machen, siehe meinen ersten Link. Gruß, Nils

Moin, ist denn die Ende-zu-Ende-Konfiguration per IPv6 mit dem Provider abgestimmt? Zumindest solange kein IPv6-Know-how verfügbar ist, würde ich empfehlen, intern mit IPv4 zu arbeiten. Es hängt zu viel an Spezialitäten dran, um das in einem Forum zu klären. Gruß, Nils

Moin, Vermutung: Word und die Office-Applikationen brauchen eine vollständige Desktop-Sitzung. Gruß, Nils

Moin, so ist nun mal der Mechanismus in Hyper-V 2016. Man wird sein Update-Management darauf anpassen müssen. Gruß, Nils

Moin, Speedport Hybrid klingt nach einem Privatanschluss. Oder handelt es sich um eine Firma? Tatsächlich hat DHCP in IPv6 eine ganz andere Funktion als in IPv4. Die typische Adressvergabe erfolgt dort über den Router. Gruß, Nils

Moin, ... dafür muss man unter Windows 7 sicherstellen, dass der Integrationsdienst "Datenaustausch" läuft. Falls der sich nicht einschalten lässt, muss man einmal manuell die Integrationsdienste aktualisieren. https://technet.microsoft.com/windows-server-docs/compute/hyper-v/manage/manage-Hyper-V-integration-services Gruß, Nils

Moin, daher die Empfehlung, das "Full"-Revcovery-Model nur dann einzusetzen, wenn man es wirklich braucht. Und wenn man es braucht, richtet man einmalig die passenden Jobs ein. Gruß, Nils

Moin, "revisionssicher" ist keine einfach definierte Eigenschaft. Das Wort bedeutet zunächst nur, dass etwas "eine Revision", also vereinfacht eine Überprüfung, übersteht. Dahinter können sich sehr unterschiedliche Anforderungen verbergen. https://de.wikipedia.org/wiki/Revision https://de.wikipedia.org/wiki/Interne_Revision https://de.wikipedia.org/wiki/Revisionssicherheit Das hören die Marketingabteilungen diverser Hersteller natürlich weniger gern, aber es läuft am Ende eben hinaus auf "kommt drauf an". Gruß, Nils

Moin, DFS-N ist dafür schon gut geeignet. Es wäre daher sehr empfehlenswert, jetzt einmal diesen Wechsel in der Namensstruktur zu vollziehen. Zwar kann man theoretisch auch mit Aliasnamen arbeiten, aber damit verschiebt man das Problem nur in die Zukunft und verschärft es damit. Gruß, Nils

Moin, anders als Exchange schneidet SQL Server das Log nicht automatisch beim Full Backup ab. Dazu muss man ein Log-Backup machen. Hat mit DPM nix zu tun. https://www.faq-o-matic.net/2014/08/27/sql-server-transaktionsprotokoll-verkleinern/ [sql Server: Wie Datenablage, Backup und Recovery funktionieren | faq-o-matic.net] https://www.faq-o-matic.net/2011/01/03/sql-server-wie-datenablage-backup-und-recovery-funktionieren/ Gruß, Nils

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

Moin, nein. Was ich sage, hat Beweiskraft. :D Gruß, Nils

Moin, erwischt! :D Gruß, Nils

Moin, die Isolation des Schemamasters ist von Microsoft mindestens "not recommended", möglicherweise mittlerweile auch unsupported. Und seid euch bei dem Snapshot-Verfahren im Klaren, dass dies ausdrücklich nicht supported ist und ihr im Fall eines Falles ein "selbstgebautes" Forest Recovery machen müsstet. Gruß, Nils PS. Solche Schnellschüsse sind es, warum ich von Panikmache beim Schema-Upgrade abrate ...

Moin, hundert Euro wären ebenso wenig wahrscheinlich wie hunderttausend. Für genauere Aussagen musst du dich mit einem Anbieter ausführlicher unterhalten, vielleicht auch mit mehreren. Gruß, Nils

Moin, korrekt. Das ging noch nie und es wird auch nie gehen. Und kommt bitte nicht auf die Idee, einen Klon oder Split eurer Root-Domäne zu machen, um die Sub auszugliedern. Das ist heftigst unsupported und birgt viele fiese Fehlermöglichkeiten. Wenn es also eine Loslösung sein soll, dann muss in einen neuen Forest migriert werden. Um wieviele User geht es denn? Gruß, Nils

Moin, der Schema Index ist nur der Index auf dem Schema. Nicht der AD-Index. Es mag ja auch durchaus sein, dass es zu solchen Situationen kommen kann. Das ist aber eindeutig die Ausnahme und betrifft i.d.R. auch "mittelgroße" Umgebungen nicht in der geschilderten Art. Vorsichtig sollte man sein, klar. Vielleicht war in eurer Situation ja auch ein Index auf Attributen betroffen, die eben schon Daten hatten. Was ich nur ungern stehen lassen möchte, sind pauschale Warnungen, die noch mehr Administratoren davon abhalten, nötige Updates einzuspielen. Das Thema betrifft ja nicht nur AD-Updates, sondern vor allem Exchange, und da gern mal alle drei Monate. Gruß, Nils