zahni

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

Hm, auch darüber kann man trefflich diskutieren. Natürlich sind NTFS-Berechtigungen führend. Bei uns stellen die Freigabe-Berechtigungen nur sicher, dass sich ein User nicht verirrt. Vermutlich kann man das auch weglassen. Auf jeden Fall ist die höchste Berechtigung "Ändern". Wir hatten in der Vergangenheit zu viele Probleme mit dem Besitz-Recht, bei dem der User dann doch wieder NTFS-Rechte verstellen darf.

Nö, rw Everyone macht man auch unter Windows nicht. Besonders nicht, wenn Du die Kontrolle über die NTFS-Rechte behalten willst. Aber wie gesagt, mit dem Powershell-Teil kann man vermutlich was bauen. Schaue ich mit demnächst an. Soweit ich das sehe, gibt es CMDLets zum Erstellen von Freigaben auf der Netapp...

Als ich ELO mal in ein Abnahmesystem kopieren musste bin ich auch fast verzweifelt. Nicht das man den Server-Namen nur in ein paar Config-Files verdrahtet hat, nein, der steht auch noch in der DB an allen möglichen und unmöglich Stellen. Richtig dokumentiert war das damals auch nicht. Kerberos war auch zum "Haare raufen".

Hm, Du meinst wohl https://shop.quest.com/682/purl-Secure-Copy . Die verkaufen echt eine "30 Tage Lizenz" ;) Ich habe mir noch die Powershell-Erweitung von Netapp heruntergeladen. Mal sehen, was damit geht.

Hi, vielleicht hat jemand mal einen Tipp. Ich suche gerade nach einer Lösung, wie ich Windows-Freigaben inkl. der ACL auf eine Netapp (cDot 8.3/9) übertragen kann. Dabei geht es mit nicht um die NTFS-Rechte. Das macht Robocopy ganz gut. LANMANSERVER auf der Registry kann ich schlecht exportieren ;) -Zahni

Mag sein. Bei uns hat die Software den Spitznamen "Hobbythek" Das mag auch am aktuellen Business-Partner liegen.

Hm, das gehört eigentlich zur "Grundausstattung". Laufwerke kann man entweder per GPP oder Logon-Script zuweisen. Google hilft da.

Nur beim Customizing wird ELO schnell kompliziert und fertige Lösungen lassen sich derzeit nicht als Paket von einem Abnahme- oder Testsystem auf ein Produktionssystem übertragen. Hier ist "Bastelstunde" angesagt und erneutes Testen. Ohne http://www.solutions-for-elo.de/produkte/uds-for-elo/uebersicht.html kann man auch kaum auf andere Daten zugreifen. Aber um Mails im großen Stil zu archivieren? K.A. Sollte man da nicht was nehmen, was sich direkt im Mailclient einklinkt?

So, das Problem lässt sich auf den HPE CIM-Provider bzw. auf dem VMWare CIM-Service eingrenzen. Wer genau Schuld ist, lässt sich derzeit nicht sagen. Im Moment habe ich den HPE-Provider mit esxcli system settings advanced set -o /UserVars/CIMvmw_hpe-smx-providerProviderEnabled -i 0 deaktiviert. Wenn der eingeschaltet ist, wird die vmkernel.log mit 2017-01-20T11:24:13.964Z cpu18:39228)User: 3820: wantCoreDump:sfcb-CIMXML-Pro signal:11 exitCode:0 coredump:disabled zugemüllt. Außerdem werden dann die Sensoren "Physical Memory Module" entweder überhaupt nicht angezeigt oder mit "Warning". "Physical Memory Module" kommt aus dem HPE-Provider. Ist eigentlich doppelt, da VMWare die Module auch selber anzeigt. Mal sehen, was der VMWare-Support noch zu sagen hat.

Wie ich schrieb, alles Aktuell. Ticket ist schon raus. Ich schreibe dann kurz, was es gebracht hat. Kurze Rückmeldung: Der Fehler scheint jetzt weg zu sein. Ich musste im RBSU 1x Default -Werte laden. K.A. was da vermurkst war. Kommando zurück: Nachdem es kurz "Grün" war, wieder "Warning"...

Der Server ist neu und dementsprechend aktuell. Ich wollte nur wissen, ob jemand rein zufällig aktuell diese Macke hat. Das ESXI 6 bei unseren älteren Servern nach dem Reboot gelegentlich mal einen RAM-Fehler meldet (ohne das der Server davon was weis), kenne ich ich schon. Doch bisher konnte man den Sensor zurücksetzen und dann was Ruhe. Nun muss ich ein Ticket ziehen.

Hi, kurze Frage an die Praktiker: Ich habe hier einen neuen Server HPE DL 360 G9 mit 256 GB RAM. Installiert wurde er mit dem neusten HPE ESXI-6.0-ISO vom Dezember. Danach wurde auf dieses Build (4600944) aktualisiert. Nun macht der Health-Monitor 12 von 16 Module "Gelb" und das VCenter schickt lustige Warnungen. "Sensor-Reset" hilft nicht. Und natürlich hat ILO & Co keine Kenntnis von RAM-Fehlern. Der Server ist 1. mit diesem Build, daher kann ich nicht sagen, ob der Fehler "mitwandert". "Memtest" findet auch nichts. Kennt jemand das Problem aus der aktuellen Praxis? Ansonsten wird es morgen dann ein Ticket bei VMWare geben.

Richtiges 2012? 2012 <> 2012R2

Du musst das aktuelle Profile zum Default Profile machen, schau mal hier: https://msdn.microsoft.com/de-de/windows/hardware/commercialize/manufacture/desktop/customize-the-default-user-profile-by-using-copyprofile

Wie ich schon weiter oben schrieb: Die IP-Adresse des Routers muss in jedem Fall per ARP aufgelöst werden. Daher klappt der Zugriff. Da es die Router-IP ist kann der Client sie nicht zu einem Router schicken ;)

Kann man mit Sharepoint machen. Da müsste man nicht mal viel anpassen. Der Rest müsste im Lastenheft stehen.

https://en.wikipedia.org/wiki/Proxy_ARP Wird wohl hauptsächlich für VPN genutzt. Damit kann man ein Remote-Gerät so einbinden, als ob es sich im lokalen Netz befindet.

Kurzfassung: Wenn das Gerät, aus welchen Gründen auch immer, per ARP für eine beliebige IP-Adresse nach der MAC zu fragen, kann er mit dieser IP kommunizieren, wenn er per ARP eine Antwort erhält. Denn dann haben wir Layer 2.