NilsK

Moin,

und du möchtest jetzt einen Weg beschrieben bekommen, wie es geht? (Ernst gemeinte Frage, damit wir in die richtige Richtung diskutieren.)

Falls ja, fangen wir mal einfach an: Auf das Pre-staging (Computerkonto vorher anlegen) zu verzichten, ist in dem Szenario keine Option?

Gruß, Nils

Moin,

was ist der Hintergrund deiner Frage? Geht es darum, dass du das ermöglichen möchtest? Oder geht es darum, das zu verhindern?

Die Updates, die der Artikel beschreibt, betreffen nur ein bestimmtes Szenario, nämlich das (Wieder-)Verwenden eines bestehenden Computerkontos im AD. Sie betreffen nicht den üblichen Vorgang, einen Computer erstmalig ins AD zu bringen. Das funktioniert, soweit ich das sehe, immer noch so wie vorher.

Gruß, Nils

Moin,

Also, in Oberbayern haben wir diese Marke weit verfehlt. Warm, manchmal freundlich, manchmal Regen. Aber schon hübsch hier.

Gruß, Nils 

Moin,

Sagen wir es so: Frank Carius ist sehr seriös und sehr gründlich, aber nicht unfehlbar.  In diesem Fall hat er aber eigentlich auch keinen Fehler gemacht, sondern sich nur etwas ungeschickt ausgedrückt.

Sein Szenario ist die Wiederherstellung eines DCs ohne vorherige Grundinstallation. Dafür reicht das System State Backup in der Tat nicht aus. Um dieses wiederherzustellen, muss man erst ein vollständig laufendes Windows haben. Warum er diesen Fall in seinem Artikel nicht durchspielt, weiß ich nicht. Die Aussage, es ginge generell nicht, ist so aber nicht richtig.

Eine Sache, die aber sehr wichtig ist: das AD wiederherzustellen, kann erheblich mehr Aufwand sein, als man erst denkt. Es gibt eine ganze Menge Dinge, die zusätzlich erforderlich sein können. Das hängt von der Umgebung ab. Daher ist es, wie Frank ja sagt, eine sehr gute Idee, diesen Fall regelmäßig zu proben und die Erkenntnisse in seinen Prozess aufzunehmen.

Dazu könnte es dann durchaus gehören, lieber mit einem Bare Metal Recovery zu arbeiten. Es gehören aber auch Schritte dazu wie das Entfernen der ehemaligen Replikationspartner und vieles andere. Das meiste davon kann man aber erst in dem Moment festlegen, in dem man das Recovery durchführt, weil jede Situation andere Bedingungen erzeugt.

Gruß, Nils

Moin,

auch keine direkte Lösung, nur den Hinweis, dass sich alles, was mit "Kalender synchronisieren" zu tun hat, schnell zum Fass ohne Boden entwickelt. Kalenderdaten sind zickig, weil sie sehr viele Varianzen haben, an denen diverse Dinge scheitern können. Dazu kommt, dass Kalendereinträge so ziemlich die einzigen Daten in der Mailbox sind, die sich nach dem Erzeugen noch ändern können und die regelmäßig parallel mit unterschiedlichen Clients bearbeitet werden, die ihrerseits sehr eigene Vorstellungen davon haben, wie das richtig geht.

Wenn man den Sync organisatorisch weglassen kann, ist das oft die bessere Lösung.

Gruß, Nils

Moin,

vor 2 Stunden schrieb Nobbyaushb:

Eloy

"ohne Scorpions, Jane, Eloy in die 80er Jahre!"

(aus dem Klappentext von "Wie der Punk nach Hannover kam")

Gruß, Nils

Moin,

das Szenario kommt mir ausgesprochen seltsam vor. Das sollte sich aber - wenn man es denn wirklich will - über eine Client-Regel machen lassen. Das hätte auch die hübschen Nebenwirkung, dass dann nicht der Admin schuld ist ...

Gruß, Nils

Moin,

in der Aufgabenplanung selbst wird das bei dem jeweiligen Task angezeigt. Reicht das nicht aus?

Gruß, Nils

Moin,

dann gute Besserung.

Schöne Grüße, Nils

Moin,

nur der Vollständigkeit halber:

Am 13.7.2023 um 18:48 schrieb Nobbyaushb:

die Umlaufprokokollierung aktivieren, dann werden die Logs nahezu sofort in die DB geschrieben

das Circular Logging ändert nicht die Schreibvorgänge in die Datenbank. Wie praktisch jede relationale Datenbank macht auch die ESE "Lazy Writing", was zu einem parallelen Logging zwingt. Dieser Vorgang ist immer derselbe. Das Circular Logging sorgt nur dafür, dass die Log-Dateien, deren Transaktionen schon in die Datenbank geschrieben worden sind, gelöscht werden. Damit stehen sie nicht mehr für Recovery-Zwecke zur Verfügung, belegen aber auch keinen Platz mehr.

Gruß, Nils

Moin,

vor 17 Minuten schrieb daabm:

Ping ist kein valider Test - Du mußt schon nslookup/Resolve-DnsName verwenden.

das kommt sehr darauf an, was man denn testet. Das müsste der TO vermutlich auch noch mal für sich klären.

nslookup etwa gibt Aufschluss, was im DNS steht, aber nicht darüber, was die Namensauflösung auf dem Client macht. (Ja, ich weiß, du weißt das, aber dem TO ist das evtl. nicht so klar.)

Gruß, Nils

Moin,

ja, genau. Was das "Projektverwaltungstool" oder "ERP" da macht - was das genau ist, weiß der TO vielleicht besser -, wäre herauszufinden. Wobei ich mir bei sowas immer nicht ernsthaft vorstellen kann, dass die paar hundert Euro für eine ordentliche Lizenzierung den Kohl wirklich fett machen würden ...

Gruß, Nils

Moin,

vor 22 Stunden schrieb testperson:

Meiner Meinung nach sind das doch "internal purposes" also "interne Zwecke".

Das schon, aber dann darf man eben nur die genannten Funktionen nutzen und keine anderen, die von einer zusätzlichen Software bereitgestellt werden. Für mich ist das eindeutig und legitim.

Gruß, Nils

Moin,

das steht doch da recht deutlich drin:

vor 1 Stunde schrieb testperson:

solely to use the following software features for personal or internal purposes

man darf ausschließlich die genannten Dienste nutzen. Nix anderes.

Gruß, Nils

Moin,

schön, dass es jetzt geht. Danke für die Rückmeldung.

Generell gilt: Alle Gruppen, die du im AD im Container BUILTIN findest, gelten nicht für die ganze Domäne, sondern nur für die Domänencontroller - dort aber für alle. Das wird sehr oft falsch gemacht. Falls du den User dort also noch drin hast, nimm ihn da wieder raus.

Gruß, Nils

Moin,

ohne das Skript zu kennen, werden wir hier kaum sinnvolle Hinweise geben können.

Gruß, Nils

Moin,

vor 21 Stunden schrieb daabm:

Stuttgart <--> Hannover

Ja, und?

Gruß, Nils

Moin,

Oder auch nicht - als Dienstleister kann es einem recht sein. Es ist eine Frage der Aufrichtigkeit, ob man solche Kunden einfach machen lässt und kassiert oder ob man noch den Versuch einer Beratung macht.

Gruß, Nils

Moin,

danke dir. Und danke an alle hier im Board. 

Gruß, Nils

Moin,

und, was sagt das Eventlog zu dem Thema? Was sagen eure IT-Admins?

Besteht das Problem nur bei diesem Account auf diesem Rechner?

Hier haben sich schon mehrere Personen engagiert, da wäre ein bisschen mehr Mitwirkung beim Troubleshooting möglicherweise hilfreich.

Gruß, Nils

Moin,

um mal Daumen in den Ring zu werfen: Bei solchen Projekten reden wir schnell von Laufzeiten von vielen Monaten und von externen Kosten im deutlich fünfstelligen oder sechsstelligen Bereich - bei mittelständischen Unternehmen. Kann man alles machen, aber wenn kein technischer Vorteil entsteht, darf man als Dienstleister schon so deutlich die Sinnfrage stellen, wie es Norbert hier tut.

Gruß, Nils

Moin,

hinter der Eigenschaft verbergen sich zwei Berechtigungseinträge. Die muss man also setzen können.

[“Objekt vor zufälligem Löschen schützen” per Skript setzen | faq-o-matic.net]
https://www.faq-o-matic.net/2010/05/21/objekt-vor-zuflligem-lschen-schtzen-per-skript-setzen/

Tatsächlich ist das aber auch eher ein Versteckspiel, den Effekt könnte man auch einfacher erreichen. Nur dann ist er eben nicht über das Häkchen im GUI sichtbar.

Um zu prüfen, wie die Berechtigungen im AD tatsächlich aussehen, ist immer noch LIZA ein gutes Hilfsmittel:

http://ldapexplorer.com/en/liza.htm

Gruß, Nils

Moin,

also, ich würde das Verhalten genau so erwarten, wie du es beschreibst. Dass es früher anders gewesen sein soll, erstaunt mich.

Ist aber am Ende auch egal - wenn du den Vorgang regelmäßig durführst, warum automatisierst du ihn dann nicht einfach mit einem Skript? Dann hast du keine Klickerei und musst auch keine Dateinamen korrigieren.

Gruß, Nils

Moin,

vor 2 Minuten schrieb DL_Alex:

Wir hatten auch nochmal einen neuen User für mich angelegt - auch dieser ist wieder nur temporär.

ihr habt wahrscheinlich ein neues Profil angelegt, keinen neuen User. Wie gesagt, der Unterschied ist wichtig.

Wenn ihr eine IT-Abteilung habt, dann wäre die doch sicher die richtige Ansprechpartnerin, oder? Sowas müssen Anwender ja nun nicht auf eigene Faust lösen.

Ich würde jetzt als nächstes im Eventlog schauen, denn sicher gibt es dort Hinweise, was beim Zugriff auf das Profil das Problem ist. Damit sollte sich das dann durch die IT-Administration lösen lassen.

Gruß, Nils

Moin,

Nicht dein Benutzerkonto ist weg, sondern das Profil. Das ist ein großer Unterschied.

Sowas passiert normalerweise, wenn man ein servergespeichertes Profil konfiguriert hat und der Client dies aus irgendeinem Grund nicht laden kann oder wenn der Client die lokale Kopie nicht überschreiben kann.

Abhilfe: nimm den Eintrag mit dem servergespeicherten Profil aus dem Konto im AD raus und arbeite mit einem lokalen Profil. Servergespeicherte Profile machen nur Probleme.

Und: solange ein temporäres Profil aktiv ist, speichere dort nichts. Es wird danach auf jeden Fall weg sein. 

Gruß, Nils