magheinz

komischerweise machen das mittlerweile alle so. Wo sollte auch das Problem sein? Selbst Microsoft schreibt ja nichts anderes: https://blogs.msdn.microsoft.com/webdav_101/2015/06/01/about-exchange-vss-writer-exchange-backup-and-restore/ Darauf setzt Netapp mit seinen Snapmanagern auf. genau so wie es Veeam, comvault, arkaia und so gut wie alle anderen auch machen.

was nutzt ihr als Backuplösung?

steht das Adressformat schon fest? Ginge such sowas wo support+16113@example.com? Also ein Plus als Trennzeichen zwischen dem statischen und dem variablen Teil?

dir scheinen doe absoluten Grundlagen zu fehlen. pack doch mal eine Ausgabe in die Schleife un zu sehen wann die if-abfrage überhaupt true ist.

Und wenn der User existiert soll er angelegt werden?

Was bitte hat die Unternehmensgröße mit der Anforderung an die Verfügbarkeit zu tun? Stell dir einfach den Unterschied zwischen einer 200Mann Gebäudereinigungsfirma und einem 1Mann Onlinebroker vor. Die Verfügbarkeit an der Anzahl der Mitarbeiter festzumachen ist doch recht eigenwillig. Dem Rest deines Postings stimme ich zu... Ich glaube bei Fujitsu gibts ähnliche Techniken. Eigentlich ist das ja der Gedanke von Cisco+Netapp. Den Flexpod fertig konfiguriert bestellen und der läuft nach einer halben Stunde. Finanziell wird das aber für viele nicht machbar sein.

Meine IT-Kollegen denken das unsere User davon überfordert sind...

Es ist halt immer eine Frage WIE baugleich die Server wirklich sind. Bei traditionellem Blech unterscheiden sich ja z.B. MAC-Adressen. Bei Cisco USC z.B. ist das wechseln der virtuellen Platte von Blech zu Blech sogar explizit vorgesehen. Hir ziehen dann MAC-Adressen und alles andere mit um.

spätestens wenn einer die Platte während des laufenden Rebuilds zieht ist eh Schicht im Schacht da es irgendwann mal die falsche Platte ist. Abgesehen davon: je nach Rebuildzeit ist ja quasi ne eine echte Redundanz da!

ich weiss. und irgendwann erkennt sich mal ein Kunde in diesen Anfragen wieder...

dann lass aber gleich den zweiten DC durchlaufen. auch bei exchange würde ich über eine zwei-node dag nachdenken. die lizenzen brauchst du ja eh.

Auch kleine Datenbanken können ordentlich IOs erzeugen. Das hat erst mal nichts mit der Größe zu tun. Aber ob das dein Problem ist...

vpn hat mit dyndns erst mal nix zu tun. Bin mir nicht sicher ob bei dieser Ausgangslage das ganze eine gute Idee ist. Hoffentlich gibts irgendwann sowas wie eine Gefährdungshaftung für Computer genau wie für Autos...

On "geht nicht" ausreicht hängt vor allem davon ab wer das sagt. Solange best practices zu einem Thema bestehen sollte man sich dran halten oder sie Abweichung gut begründen können. Viel Zeit ist auch viel Geld... Ich habs übrigens noch mal nachgelesen: Im ersten post willst du aus deiner Testumgebung den DC später produktiv nehmen oder zumindest wissen ob das geht. Die einhellige Antwort hier im Forum lautet: Blöde Idee. Akzeptiers oder bring neue Argumente.

Ich glaube ehrlich gesagt du trollst oder das ist eine schulaufgabe oder so. Was sollen denn das bitte für serverkurse gewesen sein bei denen das als "fortgeschrittenes Thema" zählt? Seid ihr ein Linuxsystemhaus?

Das nutzen des Images ist doch schon ein Rollback. Ich denke dir fehlen ein bisschen die Grundlagen über die AD. Das du Probleme mit einem zweiten DC hattest zeugt davon denn wenn man das richtig macht ist es kein Problem.

Wenn du keine Zeit hast in einer Testumgebung rumzuspielen, wann willst du die Bücher lesen? Nix für ungut, es gibt gute Bücher, aber ohne "spielen" zu können nützt das beste Buch nix. Da du schon Probleme bei den Grundlegenden Dingen hast solltest du unbedingt weiter versuchen Schulungen zu bekommen. Wenn du das verbockst, wozu die chancen echt gut stehen, dann ist doch dein Job in Gefahr.

Wir haben so kleine Schildchen an einer roten Kordel. Das ist Bockmist da die immer von den Lüftern angezogen werden und sich dann verknoten.

Es kommt natürlich immer auf den Anwendungsfall an. Bei uns werden Ordner Mit Berechtigungen IMMER durch ein Powershellscript erzeugt. Dabei werden auch immer die Domainlokalen Gruppen gebaut. Ein Admin muss sich dann nur zum Mitglied von dat_l_foobar_FU machen und hat adminrechte. Das Rechte setzen geschieht genau ein mal. Danach ist es nur noch eine Frage der Gruppenberechtigungen ws man sogar problemlos delegieren kann.

Wir lassen die User auf die Kopien RO zugreifen. Dann können die User datein per copy&paste zurückholen. Allerdings mit netapp im Hintergrund. Ich denke das geht mit Windows genauso.

Hier mal wie wir das machen #die notwendigen Rechte $rechte = @{} $rechte.add('CH',@("","Synchronize,Modify","ContainerInherit,ObjectInherit","None","Allow")) $rechte.add('FU',@("”,”FullControl”,”ContainerInherit,ObjectInherit”,”None”,”Allow”)) $rechte.add('RO',@("","ReadAndExecute",”ContainerInherit,ObjectInherit","None","Allow")) foreach ($folder in Get-ChildItem('\\data.FOOBAR\data\') -Directory) { #ACL bereinigen $acl = get-acl -path "\\data.FOOBAR\data\Abteilungen\S\$folder" $foo = $acl.Access | %{$acl.RemoveAccessRule($_)} $foo = Set-Acl "\\data.FOOBAR\data\Abteilungen\S\$folder" $acl #neue ACL setzen $acl = get-acl -path "\\data.FOOBAR\data\Abteilungen\S\$folder" foreach ($recht in "RO","CH","FU") { $GruppeL = 'DAT_L_data_'+"$folder"+'_'+"$recht" "$GruppeL" New-ADGroup -Name $GruppeL -GroupCategory Security -GroupScope domainlocal -Path "ou=,ou=Gruppen,dc=FOOBAR" $rechte[$recht][0] = $GruppeL $accessRule = new-object System.Security.AccessControl.FileSystemAccessRule($rechte[$recht]) $foo = $acl.AddAccessRule($accessRule) } $foo = Set-Acl "\\data.FOOBAR\data\$folder" $acl } Da musst du nur entsprechend Filtern wo dir Rechte gesetzt werdens sollen. Ohne Musterordner oder ähnliches. Die eigentliche Rechtevergabe geht dann über die AD-Gruppen. Das ist dann sauber und übersichtlich. DIe OUs und Pfade müssen natürlich stimmen.

Sind das wirklich lokale User oder sind das edirectory-User? Ich glaube du suchst an der falschen Stelle nach einer Problemlösung...

Das mit der Vererbung würde ich nicht so machen. Setzte doch im root alle auf RO und nur in den Spezialfällen RW. Sie Rechte addieren sich und du musst die Vererbung nicht unterbrechen.

Der vswitch von vmware kann meines Wissens nach kein LACP. Das kann nur der dvswitch was eine Enterprise plus Lizenz voraussetzt. Ich denke die ganze bondinggeschichte mit zweibaktivwn ports wird so nicht funktionieren

Klare, eindeutige Problembeschreibungen sind schon was feines... Mal um die Ecke gedacht. Müsste man nicht eine Gruppe von Computern bauen können welche die LaufwerksGPO nicht lesen darf? Die Computer müssen doch seit kurzem auch die UserGPOs lesen können...