zahni

Ich würde mal sagen: Da die ADMX viel neuer als die deutsche ADML passen die nicht mehr zusammen. Hast Du die englische ADML probiert? Ansonsten ist die Lösung da auch nur eine Krücke. Nimm lieber Chrome, da gibt es echte GPO's.

Bearbeite die GPOs einfach an einem Windows 10-Client: https://www.microsoft.com/de-DE/download/details.aspx?id=45520 BTW: Wo ist ist die Mozilla ADMX her?

Hm, das Backup hat lt. Protokoll 4h gedauert. Ein Restore von einem Verzeichnis (mit vielen Dateien, 93 GB) 4h 40 min. Das muss ich nicht verstehen... Ein Restore-Versuch von Tape habe ich nach 1h abgebrochen, da hatte er erst 6 GB geschafft. Edit: Restore einer einzelnen Datei geht flott (4 min von Maglib). ich frage mich, ob Commvault das NDMP-image für jeder Datei oder Ordner neu durchsucht. Das würde die Laufzeit erklären. Jetzt teste ich ein Restore mit der Option "use direct access restore" = OFF.

Versuch eines Reboots einer VM: Bei mir ist es System-Log, Event 1074, Quelle User32: The process wininit.exe ([remote_ip_adress]) has initiated the restart of computer TESTVM on behalf of user Domain\user for the following reason: Legacy API shutdown Reason Code: 0x80070000 Shutdown Type: restart Comment:

Darf ich fragen, warum "FTP" genutzt wird? Zumal sich "zu Hause" die Heimnetzwerk-Funktion anbietet.

Nein, die Maglib nutzt derzeit kein Dedup. Das Backup wurde aber auf dem MA komprimiert (so haben wir zur Maglib normalerweise einen höheren Durchsatz) Die Frage ist, warum es ewig dauert das lokal gespeicherte Image zu durchsuchen. In der Zeit habe ich 1,5 TB 100x hin- und her kopiert. Wenn der MA irgendwas sucht, sind immer 6 Chunks gleichzeitig geöffnet und es wird richtig I/O in der Maglib produziert. Wenn er dann wohl was gefunden hat, sind es nur 1-2 Chunks, deren Daten dann zur Netapp geschickt werden. Das verstehe ich irgendwie nicht. Ich werde morgen mal was von der Auxcopy zurücksichern. Mal sehen, ob das auch so lange dauert (es läuft immer noch, 3h 10min).

Hier kann ich auch nur wieder empfehlen, sich einen DL zu suchen, der sich damit auskennt. Womit man sich mal beschäftigen kann: Duplizierung (die schafft bei den Dateitypen sicher viel weg), Komprimierung (die Dateien sind nicht ständig im Zugriff). Kann mit Windows machen oder einem geeigneten Storage. Mit einer geeigneten Backup-Lösung kann man Inhalte auch so archivieren, dass man sie manuell durch eine Datenbankabfrage wiederfindet bzw. das dazugehörige Tape. Die einfachste Lösung: Anwender sollen Löschungen von alten Daten dokumentieren (Datum und Pfad). Dann findet sie mit jeder guten Backup-Software wieder... Da Tape extern gelagert werden sollten, finde ich persönlich eine HSM-Lösung unpraktisch. Aber damit kenne ich mich nicht wirklich aus.

Hi, da unserer Spezi gerade nicht erreichbar ist, mal eine Frage: Kennt sich jemand mit den NAS-Agenten via NDMP an eine Netapp aus? Ich teste gerade Backup&Restore der Filer SVM. Dazu konnte ich nun erfolgreich alle Volumes des Filers per NDMP in eine Commvault Maglib sichern (Full Backup). Nun will ich zum Test einen größeren Ordner zurücksichern. Im Prinzip klappt das auch, es ist aber elend langsam. Im Restore-Job ist die Option "use direct access restore" eingeschaltet. Lt. Doku sollen so nur selektieren Files aus dem NDMP-Backup gelesen werden und zur Netapp geschickt werden. Wenn ich mir DISK-I/O (Maglib) und die Netzwerk-Auslastung zu anschaue, klappt das auch so. Allerdings sucht Commvault nun schon seit 2h die Dateien zusammen. Insgesamt hat die Sicherung rund 1,5TB (auf der Maglib komprimiert) bei rund 2,5 Millionen Dateien. Kann man das irgendwie beschleunigen? Das ganze NDMP-Image zur Netapp schicken dauert vermutlich noch länger. Das Backup lief rund 4h (der Media Agent ist derzeit nur mit 1Gbit/s angebunden, ist ein Blade und ich kann die Switche jetzt nicht tauschen). -Zahni

"Die lokalen Administratoren haben"... Das ist wohl Dein Hauptproblem. Unsere PCs haben keine lokalen Administratoren bzw. sind die Konten alle deaktiviert und mit einem Sinnlos-Password belegt. Wenn ein PC remote heruntergefahren wird, steht das hinterher im Eventlog (u.U. auch unter "Security"). Da sollte die Quelle gefunden werden. Und vermutlich solltet Ihr Euch fachmännische Hilfe im Bereich IT-Security holen.

/B steht für "Backup Mode". Was Ihr da jede Nacht wie spiegelt, verstehe ich nicht ganz. Ich könnte jetzt sagen: Man macht sich im Vorfeld um ein vernünftiges Backup & Recovery-Verfahren Gedanken und testet, ob das Recovery auch funktioniert.

Virenscanner temporär abschalten. /MT gibt es beim Robocopy aus 2008R2 noch nicht. Wir migrieren gerade auch versuchsweise Daten mit Robocopy. Unter 2012R2 läuft es wirklich schneller. Du solltest noch "/B" benutzen. Sonst fehlen hinterher u.U. NTFS-Rechte.

Probiere es doch mal mit der Angabe der OU bzw. der Basis in die Du suchen willst: Get-ADUser -Filter * -SearchBase "OU=Finance,OU=UserAccounts,DC=FABRIKAM,DC=COM" So ganz ohne Angabe eines Servers...

450 PC per Recovery-DVD? Wer macht den sowas?

Teilweise sind es die vielen Microsoft-Jobs im Task Scheduler...

Die Netapp ist produktiv (mit FCP-Volumes). Ontap-Migration ist beim DL angefragt. Das lasse ich mal lieber den kaputt machen (einer muss ja "Schuld" haben ;) ) Gleichzeitig sollen noch die FC-Switche eine aktuelle Firmware bekommen. Der kann mir dann gleich noch die wichtigsten Neuerungen zeigen.

Ich würde mich Nils anschließen. Solche Sachen werden am Anfang immer klein geredet. Geht man ins Detail, kommen ganz kleine Zusatzanforderungen, die einen unheimlichen Aufwand verursachen. Gerade die Entwicklung der Formulare ist nicht trivial, besonders, wenn man mit den Daten hinterher auch was anfangen will. Sharepoint kann es vielleicht. Allerdings hört sich das ein wenig nach DMS an (das kann Sharepoint auch irgendwie). Da wir das gerade hatten: ELO wäre hier eine Möglichkeit. Aber bitte nicht ohne Konzept.

Ich Domain-Admin, habe alle Rechte ;) Egal, dann halt so. Später probiere ich es noch mit einem Restore vom Band. Mal sehen, was schneller geht.

So, ich habe jetzt noch ein wenig probiert und konnte den Effekt reproduzieren, ganz ohne Netapp. Lösung scheint der Schalte "/B" in Robocopy zu sein, warum auch immer. Es hat aber den Anschein, dass damit auch die Multithread-Funktionen abschaltet werden, jedenfalls wird nur noch ein einen Ordner gleichzeitig geschrieben. Noch eine weitere Anomalie: Ich habe zuerst versucht über das Root-Volume zu kopieren (C$-Share). Dort sind die Volumes als "Junction Point" eingehängt. Kopiere ich auf so einen Junction Point loggt Robocopy komische Fehler: 2017/01/26 11:40:33 ERROR 2 (0x00000002) Creating Destination Directory y:\junction point\mydir\ The system cannot find the file specified. Angelegt werden die Ordner später aber trotzdem, wenn die Dateien kopiert werden. Erzeuge ich auf "junction point" ein Share und benutze es, verschwindet der Fehler.

Im privaten Bereich verzichte ich unter Windows 10 auf einen separaten Virenschutz. Zumal Avira "Kostenlos" auch nicht mehr das Wahre ist. Virenscanner erkennen aktuelle Ransomware zu 98% eh nicht oder erst 2 Tage später.

Das mit dem Rechte klappt schon so und kopieren ein paar Pfade an neue Orte. Ich denke mal, ich spiele sicherheitshalber mal Patch 9 ein (Ontap 9.1 machen wir später). Gründe sind u.a. CVE-2016-4341 (SMB Share Information Disclosure Vulnerability in Clustered Data ONTAP) und "Poor performance due to SMB directory enumeration"

Hi, ok - ich glaube, ich habe hier noch ein anderes Problem. Beim genauen Hinsehen fehlen auch noch andere Rechte und teilweise ganze Ordner. Muss ich mal genau untersuchen. Eventuell ist Robocopy irgendwie mit dem normalen Backup-Job auf dem Windows-Server ins Gehege gekommen. Habe leider kein Log erstellt und es lief 10 Stunden. Nicht dass cDot wieder irgendeinen Bug hat. Ich muss morgen mal die Release Notes der nachfolgenden Patch-Versionen lesen...

Hi, ich versuche gerade einen für uns optimalen Migrationsweg unserer Filer von Windows 2008R2 auf eine Netapp mit cDot 8.3.2P6 herauszufinden. Die Netapp ist per Kerberos zur Domain "gejoined" Bei einem Versuch mit Robocopy unter (und aus) Windows 2012R2 bin ich auf ein Problem gestoßen: Wir haben aus irgendwelchen Gründen einige wenige Berechtigungen für Domain Local Groups vergeben. Bei der Kopieroption /COPYALL ist es nun so, dass aus mit unbekannten Gründen diese Rechte hinterher fehlen. Globale Gruppen und einzelne User klappen. Ich kann sie zwar manuell neu anlegen, doch das ist nichts das Ziel. Hat da jemand eine Idee? PS: Ich sehe gerade: Wenn ich mit unserer Backup-Software auf die Netapp als CIFS-Share zurücksichere, klappt es. Wahrscheinlich kann mich Robocopy dann mal... ;) -Zahni

Hallo, was muss man denn unter "hängt sich auf" verstehen? Wenn die HDD richtig voll ist, kann ein chkdsk ein paar Stunden dauern.

Hast Du denn eine auch eine Domäne eingerichtet? Das geht bestimmt in dem Foundation-GUI-Gedöns (sorry, das habe ich mir noch nie angeschaut) oder im Server Manager. Für mich hört sich das so an, als ob das AD noch nicht eingerichtet wurde.

Hallo und willkommen im Forum. Du möchtest uns doch sicher zuerst ein wenig über den Server, die eingesetzte Software und was Du zuletzt gemacht hast erzählen...