NilsK

Moin, wie praktisch immer bei Leerzeichen sollten auch hier Anführungsstriche helfen. Fasse also das %%G in dem Do-Zweig mal in Anführungsstriche ein, dann sollte es gehen. Gruß, Nils

<Popcorn hol /> Gruß, Nils ... SCNR ...

Moin, für neue Dokumente kann man den Benutzernamen in den Office-Optionen ändern. Darunter gibt es (zumindest in der aktuellen Version) ein Häkchen, mit dem man Word anweist, diese Werte auch dann zu verwenden, wenn man mit einem anderen Namen an Office 365 angemeldet ist. Word verwendet ab da den "neuen" Namen (also auch bei der Information, wer zuletzt gespeichert hat). Damit sollte sich zumindest eine Vorgabe für die Zukunft umsetzen lassen. Wenn allerdings diese Metainformationen sowieso nicht verwendet werden, dann wäre es evtl. eine sinnvollere Option, diese komplett aus den Dokumenten zu entfernen. Rechtliche Angreifbarkeit sehe ich da nicht, denn es gibt keinen Anspruch, in den Metainformationen eines Dokuments ausgewiesen zu werden. Das müsste im Zweifel aber ein Rechtsanwalt beurteilen. Gruß, Nils

Moin, bitte wärme keine uralten Threads wieder auf! Eröffne einen neuen. @Mods, bitte abtrennen. Inhaltlich: Ein Non-authoritative Restore braucht man eigentlich nie, es ist nur von theoretischem Wert. In der Praxis geht es schneller, einen DC neu zu installieren, sofern noch weitere laufen. [Video-Tutorial: Active Directory Object Recovery | faq-o-matic.net] https://www.faq-o-matic.net/2009/09/07/video-tutorial-active-directory-object-recovery/ Gruß, Nils

Moin, in aller Regel bekommt man das so konfiguriert, dass das AD nutzbar und von da aus ein weiterer Restore möglich ist. Was da genau zu tun ist, ist anhand der vorliegenden Informationen schwer zu beurteilen und möglicherweise für ein Forum zu aufwändig. Bezüglich des DNS etwa kann es durchaus sein, dass eine Art Deadlock vorliegt: Die DNS-Daten stehen im AD, aber das AD kann nicht angesprochen werden, weil DNS keine Antwort gibt. Außerdem kann es natürlich sein, dass die Sicherung einen "Hau" hat. Nicht zuletzt aus solche Gründen empfehle ich immer, vom AD mindestens zwei Sicherungen zu machen, davon eine per Systemstate. Damit hat man im Zweifel eine Sicherung, die auch von Microsoft unterstützt wird. Da es sich um einen Test handelt, würde ich jetzt: eine zusätzliche Sicherung per Systemstate einrichten das AD im "Normalbetrieb" auf korrekte Funktion und Konfig überprüfen die Veeam-Sicherung noch mal genau prüfen ein Recovery-Szenario entwerfen das Recovery mit den neuen, möglicherweise korrigierten Konfigurationen neu testen, mit beiden Methoden (Veeam und Systemstate) Gruß, Nils

Moin, je nach Umgebung kann es eben erforderlich sein, die Konfiguration eines DCs nach dem Recovery anzupassen. Das ist völlig normal. Ein Forest Restore ist ganz gewiss keine Plug-&-Play-Angelegenheit. Nicht umsonst empfiehlt man, die nötigen Schritte regelmäßig zu erproben und zu dokumentieren. Welche das sind, kann wiederum von der Situation abhängen - welche Teile der Umgebung sind wiederhergestellt worden, was funktioniert noch? Da sollte man sich genügend Zeit nehmen. Gruß, Nils

Moin, da widerspreche ich. OEM-Installationen bei Business-Rechnern sind durchaus oft in Ordnung, pauschal würde ich da nicht zum Neumachen raten. Was das Problem angeht: In der Tat sollte eine Deinstallation des Programms helfen. Ergänzend könntest du mal in den Geplanten Aufgaben nachsehen, vermutlich sind da Tasks definiert, die solche Dell-Programme aufrufen. Wenn da nichts ist, kann ein Blick mit Autoruns von Sysinternals (= Microsoft) Aufschluss bringen. Gruß, Nils

Moin, ich habe den TO so verstanden, dass es nur einen DC gibt. Replikationsprobleme können es dann nicht sein. Gruß, Nils

Moin, welche GUIDs haben denn die anderen beiden Varianten? Wahrscheinlich bekommt man das in den Griff, aber ich würde da weder über ein Forum eine Anleitung geben noch es über ein Forum ausprobieren. Dafür ist das Risiko von Missverständnissen zu hoch. Wenn ich was daran täte, dann nur direkt. Daher der Vorschlag, einen Case bei Microsoft zu eröffnen oder sich einen Spezialisten ins Haus zu holen. "Default Naming Context" bzw. die deutsche Übersetzung sind einfach nur andere Begriffe für die Domänen-Partition des AD. Und "hartkodiert" meint, dass die DDP und die DDCP die einzigen Policies sind, die vorinstalliert werden und die immer dieselben GUIDs haben, in jeder Umgebung. Eine echte, harte technische Abhängigkeit gibt es nicht, aber durchaus Prozesse im System, die darauf aufsetzen. https://www.gruppenrichtlinien.de/index.php?id=31&tx_ttnews[tt_news]=162&cHash=2b6b1bfe8644de808622128630a0cb8b Gruß, Nils

Moin, deine Probleme deuten für mich auf Kommunikationsprobleme im Netzwerk oder sowas hin. Ist die DNS-Konfiguration korrekt? Gibt es evtl. Probleme beim Zeitabgleich in der Domäne? Gruß, Nils

Moin, auch eine Einzeldomäne ist immer ein Forest ... Du hast jetzt aber zwei getrennte Forests vor dir. Gruß, Nils

Moin, bitte beschreibe dein Vorgehen noch mal genauer. Was exakt tust du und wann kommt dieser Fehler? Mit was für einen Account bist du in dem Moment selbst angemeldet? Was heißt "Dieser Fehler tritt nicht bei allen Usern auf. Andere User kann ich problemlos hinzufügen."? Du fügst mehrere User im selben Schritt hinzu, einige werden akzeptiert, andere nicht? Du fügst in mehreren Schritten, aber in derselben Session mehrere dieser Vorgänge aus? Du machst das an verschiedenen Rechnern, zu verschiedenen Zeitpunkten, ...? Gruß, Nils

Moin, naja ... wenn die Developer auf Systemebene entwickeln oder Dinge kontrollieren müssen, dann ist es schlicht nicht zu umgehen, dass sie lokale Adminrechte haben. Das heißt aber noch lange nicht, dass sie lokale Adminrechte auf ihrem produktiven Client haben müssen, der sich in der Unternehmensdomäne befindet. Virtualisierung existiert schon eine Weile. Gruß, Nils

Moin, nein, wenn man oft genug auf die Bilder klickt, bekommt man sie irgendwann lesbar. ;) Gruß, Nils

Moin, SharePoint? Wobei das für mich eher nach einer Organisations- und Prozessfrage klingt, die man mit Technik üblicherweise nicht lösen, sondern bestenfalls unterstützen kann. Daher würde ich die Aussage "es reicht eigentlich ..." noch mal hinterfragen und mit den Prozess-Ownern im Detail betrachten. Meist kommt dann doch hier noch was und da noch was, und plötzlich ist die vorhandene Lösung keine mehr, weil das Problem sich verändert hat. Gruß, Nils

Moin, sicher, dass du die "Default Domain Policy" genommen hast und nicht die "Default Domain Controllers Policy"? Mit den Benutzerrechten kenne ich mich im Detail ncht aus, aber zumindest gibt es welche, die man für den jeweiligen Prozess erst aktivieren muss. Vielleicht ist das hier auch so. Ansonsten kann ich dazu jetzt nicht mehr viel beitragen. Gruß, Nils

Moin, naja, das ist eine Anforderung. Als "normalerweise" würde ich das noch lange nicht bezeichnen. ;) Gruß, Nils

Moin, dies hier geht nicht? https://support.microsoft.com/en-us/help/4027670/windows-10-add-and-switch-input-and-display-language-preferences Gruß, Nils

Moin, trotzdem bleibt der Ressourcenmonitor ja ein Mittel - zu welchem Zweck? Vielleicht gibt es ja alternative oder bessere Wege zum Ziel. Gruß, Nils

Moin, vermutlich hast du die Einstellungen im AD gemacht? Dann hast du den User den betreffenden lokalen Gruppen auf den DCs zugewiesen (denn nur dort gelten die Gruppen aus dem Container "Builtin"). Wenn du jetzt auf deinem Client ein whoami ausführst, siehst du die Gruppenmitgliedschaften für lokale Gruppen auf dem Client, nicht die vom DC (und dort bestehen die Mitgliedschaften eben nicht). Dasselbe gilt für die Userrechte: Die hat dein User dann auf dem DC, nicht auf dem Client (wodurch du sie auf dem Client auch nicht siehst). Du müsstest aber beides auf dem Client ausführen, d.h. dort als Admin anmelden und den User über "lusrmgr.msc" in die betreffenden Gruppen aufnehmen. Aber ziehen wir das Ganze doch mal von der richtigen Seite auf: Was ist denn das eigentliche Problem, das du lösen willst? Gruß, Nils

Moin, über solche Verfahrensfragen informiert der Betriebsrat, sobald er dazu in der Lage ist. Zunächst wird der intensiv mit der Unternehmensleitung abstimmen, was und wie usw. Also abwarten. Sobald es für dich relevant wird, wirst du offizielle Informationen dazu bekommen. Gruß, Nils

Moin, https://blogs.technet.microsoft.com/russellt/2016/06/03/custom-ldap-certs/ dort unter "Important Note". Ist keine offizielle Aussage, aber mit dem Hinweis könnte man eine bekommen. Gruß, Nils

Moin, kurz gesagt: Solange der TO kein leitender Angestellter ist, hat er nichts zu "befürchten". Die Mitbestimmung übt der Betriebsrat gegenüber der Unternehmensleitung aus, nicht gegenüber einzelnen Mitarbeitern. Einzelne Mitarbeiter sind dem Betriebsrat gegenüber auch nicht verantwortlich. Ich würde erst mal abwarten. Ein Betriebsrat muss nicht per se etwas Schlechtes sein, und sobald er sich und seine Arbeitsweise gefunden hat, wird man mit ihm klarkommen. Gruß, Nils

Moin, Loadbalancer vor einem DC ist nicht supported, aber Microsoft hat eine Anleitung, wie man in dem Fall ein Zertifikat für LDAPS baut. Gruß, Nils

Moin, warum sollte es? Das Prinzip gilt unabhängig vom Anmeldeprotokoll. Sicher, aber das ist nicht das Szenario, nach dem der TO gefragt hat. Durch ungünstigen Aufbau kann man schon einiges tun, um Abhängigkeiten von bestimmten DCs zu erzeugen, die es eigentlich nicht geben müsste. In dem von dir genannten Szenario hilft es meist, nicht einen bestimmten DC anzugeben, sondern einfach den Domänennamen. Die DNS-Auflösung gibt dann alle DCs zurück, in quasi-zufälliger Reihenfolge. Meist sind Applikationen dann in der Lage, einen DC anzusprechen, der auch antwortet. Gruß, Nils