NilsK

Moin,

vor 11 Stunden schrieb daabm:

Der Explorer verhält sich da nicht hanebüchen, sondern "as designed".

an der Stelle ist "as designed" aber nun mal hanebüchen. Dass Microsoft extra Code gebaut hat, der so funktioniert, macht es doch nicht besser. Der Explorer manipuliert die ACL, ohne darüber ordentlich Auskunft zu geben. 

Und was den Rest betrifft - ja, steht ja auch in meinem Artikel. 

Gruß, Nils

Moin,

löscht Acronis die Checkpoints absichtlich nicht oder ist das eine Fehlfunktion? Falls letzteres - korrigier das oder sag dem Hersteller, er soll das tun.

Ansonsten: Es ist, wie du merkst, keine gute Idee, einfach mal Dateien am System vorbei zu löschen. Wenn du Checkpoints loswerden willst, nimm die Systemfunktion dafür.

Eine Lösung für das akute Problem habe ich nicht, aber ich würde jetzt versuchen, die AVHDX-Dateien als Dummy manuell anzulegen und dann die Systemfunktion zum Löschen zu verwenden.

Gruß, Nils

Moin,

ich mache keinen Betrieb und muss keine Server verwalten, daher habe ich da keine belastbaren Praxiserfahrungen. Total Commander wird aber oft für sowas genannt. 

Eine andere Stelle, an der sich der Explorer hanebüchen verhält, habe ich hier beschrieben:

[Windows-Berechtigungen mit UAC verwalten | faq-o-matic.net]
https://www.faq-o-matic.net/2015/12/23/windows-berechtigungen-mit-uac-verwalten/

Gruß, Nils

Moin,

was heißt denn "die grundsätzlich mit Admin Rechten starten möchten" genau? Kommt eine UAC-Abfrage? Dann wirst du es nicht ändern können, weil es dann im Programm so vorgesehen ist.

Gruß, Nils

Moin,

mag sein, dass der Explorer da nicht gut arbeitet. Das wäre nicht die einzige Stelle im Zusammenhang mit Berechtigungen. Allgemein sollte man den Explorer nicht verwenden, um Dateiserver zu verwalten.

Gruß, Nils

Moin,

zusammenfassend:

• da eine AD-Domäne immer "intern" ist, gibt es keinen direkten technischen Zusammenhang zu einer externen DNS-Domäne. Damit gibt es auch keine "harten" technischen Ausschlüsse für bestimmte Domänennamen. Externe und interne Domänennamen haben weder positiv noch negativ miteinander zu tun.
• dasselbe gilt auch für Maildomains. Eine interne Domäne kann völlig anders heißen als die externe Mail-Domäne.
• es gibt sehr wohl eine ungünstige Auswahl von Namen - aber das ist eher auf der Ebene von kosmetisch oder nervig, praktisch nie auf der Ebene "geht gar nicht"
• eine bestehende AD-Domäne umzubenennen, ist immer sehr großer Aufwand. In der Regel ist aus wirtschaftlichen und organisatorischen Gründen davon abzuraten.
  • scheinbar "einfache" AD-Umbenennungen mit rendom.exe funktionieren nicht, wenn Exchange genutzt wird. Auch ohne Exchange sind sie in Wirklichkeit riskant. Einige Berater (auch ich) raten entschieden davon ab.
  • ein Verfahren ohne rendom.exe ist in Wirklichkeit keine Umbenennung, sondern eine Migration in eine vollständig neue AD-Domäne (bzw. genauer: einen neuen Forest).
• Es gibt in der Tat Empfehlungen für AD-Domänennamen, aber diese gelten vor allem dann, wenn eine Umgebung völlig neu aufgesetzt wird. Es ist nicht empfehlenswert, bestehende Umgebungen zu migrieren oder umzubenennen, nur weil der Name nicht so hübsch ist.
• Um es zu illustrieren: die letzten Kunden, die ich nicht von so einem Vorhaben abbringen konnte, haben fünf- bis sechsstellige Summen für den Umstieg auf einen neuen Domänennamen ausgegeben. Nur für den Namen, ohne dass nennenswert etwas technisch besser wurde. (Das freut mich zwar als Dienstleister, ist aber wirtschaftlich nicht unbedingt sinnvoll.)

Nach dem, was @Horst2 beschrieben hat, sehe ich keinen Grund, die Domäne zu migrieren. Ich würde sie so lassen, wie sie ist.

Gruß, Nils

Moin,

je nachdem, wie groß das Unternehmen ist, kann auch eine einfachere Lösung ausreichen, die es auch oft kostenlos gibt. Oder "praktisch kostenlos", so hatte ich in einer Firma mal eine simple Lösung auf einem ohnehin vorhandenen SharePoint. Das war, meine ich, sogar eine mitgelieferte Beispiellösung, die mit ein paar Klicks eingerichtet war. Nicht super, aber für einfache Zwecke ausreichend.

Da ich in einem anderen Thread auch gerade WordPress als Beispiel für eine einfache und günstige Grundlage herangezogen hatte - selbstverständlich gibt es dort auch Ticketsystem-Plugins.

https://de.wordpress.org/plugins/tags/ticket-system/

Gruß, Nils

Moin,

ich stimme den Kollegen zu: Weder Konzept noch Umsetzung machen einen sinnvollen Eindruck. Auch aus meiner Sicht wäre es empfehlenswert, das mit einer Fachperson neu zu planen und umzusetzen.

Gruß, Nils

Moin,

Ich bin ja kein VMware-Spezi - aber liegt in dem RDM nicht vielleicht der Grund, dass der ganze Cluster ausfällt, wenn man einen Node beendet?

Gruß Nils

Moin,

Und wie hast du das Quorum nun eingerichtet? Vermutlich nicht korrekt, sonst bliebe der Cluster ja online.

Ebenso wäre zu klären, warum der Cluster meint, eine DHCP-Adresse zu verwenden. Da kann ja auch was nicht stimmen.

Also bitte mal die Fragen ordentlich beantworten.

Gruß, Nils

Moin,

was hast du denn als Cluster-IP eingetragen? Im Fall des Falles wäre eine Fehlkonfiguration hier mit Sicherheit ein Problem.

Zu dem Offline-Schalten des Clusters: Wie hast du denn das Quorum konfiguriert? Das ist ja genau dafür da, dass du nicht einfach in ein 50-Prozent-Problem läufst.

Gruß, Nils

PS. es beschleunigt die Antworten in einem Forum nicht, wenn man per Großschreibung "brüllt".

Moin,

okay, dann steinige ich dich mal. Wenn du ein neues Problem hast, mach doch bitte einen neuen Thread auf. Sonst findet sich doch niemand zurecht.

Danke, Nils

Moin,

also, ehrlich gesagt ... die Anforderung klingt für mich, als sei sie für einen Admin recht leicht und schnell umzusetzen. Man braucht eigentlich keine großartige Software dafür, vermutlich reichen sogar Bordmittel einer Linux-Distribution. Sonst wird man schnell auch Plugins für Standardsoftware finden; auf Anhieb finde ich z.B. mehrere Plugins für WordPress, die wie Kandidaten aussehen.

Es braucht doch eigentlich nur eine Dateiablage, eine einfache Userverwaltung und einen Webserver, der das alles zeigt. Je nachdem, welche Flexibilität in der Zugriffsverwaltung man dem Kunden bieten will, besteht der eigentliche Aufwand darin, Benutzerkonten anzulegen, Dokumente passend abzulegen und an den richtigen Stellen Leserechte zu erteilen.

Wenn das eher ein Neben-Goodie ist, würde ich, wäre ich zuständig, das intern mit einem Zeitbudget von ein paar Tagen vergeben und wäre zuversichtlich, dass was Brauchbares dabei rauskommt. Wenn es etwas ist, um damit direkt Geld zu verdienen, ist das was anderes - aber dann ist auch die Budgetfrage eine andere.

Gruß, Nils

Moin,

das hängt ziemlich entscheidend davon ab, was du dir denn unter der "Rechtestruktur" vorstellst.

Gruß, Nils

Moin,

okay, danke für die Rückmeldung!

Gruß, Nils

Moin,

der Microsoft-Link in dem oben verlinkten Artikel funktioniert leider nicht mehr. Daher die Antwort auf deine Frage hier konkret: Der Account braucht gar keine speziellen Rechte und sollte auch keine haben. Leg also einfach einen AD-User an, den du in keine speziellen Gruppen aufnimmst. Es geht nur darum, dass dieser Account der Owner der DNS-Einträge wird.

Noch besser wäre es, DHCP nicht auf einem DC zu betreiben. Microsoft rät mittlerweile ausdrücklich davon ab (und sieht es in Assessments als hohes Risiko an, wenn DHCP auf einem DC läuft).

Gruß, Nils

Moin,

vor vielen Jahren gab es mal einen Aprilscherz, der eine Innovation bei Microsoft ankündigte. Nach "Windows" mit seinen Fenstern und Maus und so sollte es "Doors" geben, das sich viel einfacher bedienen ließe. Statt dass man ständig nach Fenstern und Icons suchen müsse, könne man auf einer einheitlichen Oberfläche mit simplen Textkommandos Programme aufrufen. Das alles, ohne dass man ständig von der Tastatur zur Maus wechseln muss. Der Kurzname für das "Doors Operating System" sei "MS-DOS" ...

Gruß, Nils

Moin,

vor 13 Minuten schrieb testperson:

Es ist ja leider nicht so unüblich, dass man Mails bei Hostern (Strato, 1und1, Host Europe und Co.) einliefert und es ab da "abenteuerlich" weitergeht.

ja, gibt es. Das ist dann aber nicht die Serverkette, die der TO vermutet hat, sondern ein schlechter Aufbau, den es immer irgendwo geben kann (auch wenn man Ende-zu-Ende verschlüsselt). Aus DSGVO-Sicht wäre ein solches Konstrukt wohl dem Empfänger zuzuordnen. Dadurch wäre ich als Sender wahrscheinlich aus der Verantwortung raus (auch wenn das der Person, deren Daten da übermittelt werden, materiell wenig nützt).

Mailrouting unterscheidet sich von IP-Routing, das ist der Punkt, auf den ich hinauswollte. In aller Regel findet die Zustellung nun mal direkt statt, Mails werden nicht wie IP-Pakete irgendwo abgegeben in der Hoffnung, dass sie von da aus schon irgendwie weiterkommen.

Gruß, Nils

Moin,

nein, die Annahme ist in aller Regel falsch. Die Verbindung wird zwischen Quell- und Zielserver direkt aufgebaut, ein Store-and-Forward findet nicht statt.

Der Einwand von @Dukel und @testperson bezieht sich, soweit ich ihn verstehe, auf die Fortsetzung der Mailkette innerhalb der Zielorganisation. Da kann es weitere Mailserver geben, zu denen der Transportweg von außen unbekannt ist und der auch nicht von außen abzusichern ist.

Gruß, Nils

Moin,

das ist korrekt, entkräftet aber nicht das Argument von @comcrypto. Aus Sicht der Datenschutzkonferenz ist ab dem Zeitpunkt, wo die Daten zuverlässig an die Zielorganisation übergeben wurden, diese für den Schutz zuständig. Ob die dann noch weitere Ketten aufbaut, ist dann genauso ihre Sache wie der Schutz dieser Kette. Für den reinen Transport reicht es dann aber aus, dass die sendende Organisation für den sicheren Transport gesorgt hat.

Wenn das nicht ausreicht, dann ist der Grund nicht "pur" die DSGVO, und dann braucht es eben andere Methoden, möglicherweise eine Ende-zu-Ende-Verschlüsselung.

Gruß, Nils

Moin,

dann ist das aber nicht der Systemstate eines DCs.

Gruß, Nils

Moin,

vor 16 Minuten schrieb Nobbyaushb:

Ich habe ... Lars geschrieben ... - ich meinte natürlich Nils

das ist originell, denn einer meiner Brüder heißt Lars. 

Gruß, Nils

Moin,

den Systenmstate von einem Hyper-V-Host sichert man ja auch nicht. Allgemein sichert man Hosts nicht als Hosts, das gilt auch bei anderen Hypervisoren als Best Practice. Man dokumentiert die wichtigen Parameter und installiert im Bedarfsfall den Host neu - das dauert zwischen 15 und 60 Minuten. Da du dann sehr wahrscheinlich eine neue Hardware hast, würde ein Recovery-Versuch der Konfig eines anderen Hosts den Zeitbedarf nur vergrößern und die Qualität reduzieren.

Gruß, Nils

Moin,

vor 4 Stunden schrieb BOfH_666:

Hmmm ... darf ich das anzweifeln?

darfst du, ist ja ein freies Land hier. 

Könnte durchaus sein, wie du es vermutest. Es kann aber auch noch komplizierter sein, denn wie - in dem Fall - ich oben schon anmerkte, kann es ja auch sein, dass die Importfunktion des Clients nicht ordentlich arbeitet und "manchmal" die Strings als Zahlen weitergibt.

Gruß, Nils

Moin,

dann ist Bitlocker nicht die richtige Methode. Du suchst nach einer Verschlüsselung, die benutzerbezogen arbeitet. Dafür kann schon EFS reichen - aber bevor du jetzt dazu greifst, solltest du die Anforderungen genau klären. Aus Erfahrung wird es bei Verschlüsselung sofort kompliziert, wenn Bitlocker Full Disk Encryption nicht passt.

Gruß, Nils