daabm

Das Problem dürfte sich bei den meisten hier nicht stellen - "Wartung" macht man doch nicht per RDP. Vielleicht hilft es, wenn Du erklärst, was genau Du machen willst in diesem Moment.

Weiß ich doch, alter Mann Man kann heute kaum genug Awareness haben... Ich hab kürzlich eine Mail einer Spedition bekommen - NACHDEM schon geliefert worden war, tagsüber natürlich wo ich nicht zuhause war. Die Lieferung kam im Auftrag des Herstellers, der wiederum vom Verkäufer beauftragt wurde, ich wußte also nicht, daß diese Spedition mir was liefern würde. Aber lest selbst: Da hing dann noch netterweise ein PDF dran. "Näher an Spamverdacht" kann man gar nicht sein. Und wie gesagt, die Mail kam unerwartet, da ich von XYZ im Vorfeld keine Nachricht bekam, vom Hersteller oder Verkäufer auch nicht.

Naja, dann zeig doch mal einen vollständig aufgeklappten Screenshot von dssite.msc Und von jeder Site dann bitte noch die zugeordneten Subnetze. Und die Inhalte der Site Links.

Mode oder nicht - wo Not am Mann ist, muß gehandelt werden... Und zwar sofort, nicht erst hinterher

Au weia, das wird ein Augenöffner... Woher ich das weiß? Pfeiff...

Nachdem das grad in einem anderen Thread hier auch aufkam: Ich empfehle, die Stadt-OUs wegzulassen. OUs sind dazu da, das AD zu organisieren - nicht das Unternehmen abzubilden.

Ich könnte ein Buch dazu empfehlen, da hab ich das glaub mehr als einmal reingeschrieben: OUs bilden nicht die Organisation des Unternehmens ab - sie dienen dazu, das AD zu organisieren. Es sind keine "Organisationseinheiten", sondern "Organisierungseinheiten" (ja, ich weiß wie b***d dieses Wort klingt ). OUs haben genau 2 Zwecke: Verlinkung von GPOs und Delegation von Berechtigungen.

Ich kanns nicht nachvollziehen... Wenn Sites und Subnetze korrekt sind, dürfte NIE ein DE-Client nach China wollen. Und wenn Sysvol per DFS repliziert wird und nicht per NTFRS, dürfte auch NIE ein Client auf Sysvol in China zugreifen wollen (bei NTFRS war das noch schwierig).

Nimm %DomainName% - ich hab %LogonDomain% noch nie verwendet, bin mir grad unsicher was da drin steht

Mit Deinem Befehl versucht er das direkt auf dem Druckserver... Und korrekterweise stellst Du dort in den Standard-Druckeinstellungen auch das korrekte Format ein. Lokal auf dem Client geht es einfach, indem Du fertige Settings von einem passend konfigurierten Drucker (auf einem Referenzclient) exportierst und auf allen anderen Clients wieder importierst. Ich hab das immer mit printui gemacht, weiß leider nicht ob es ein Powershell-Pendant dazu gibt.

Dem ist kaum was hinzuzufügen Nach mehreren Fusionen und Umbenennungen landet unser interner Namensraum jetzt auch in einer DNS-Zone, die mit dem Firmennamen nichts zu tun hat. Für Großunternehmen ist ein Ändern des DNS-Namensraums eine mittlere Katastrophe...

Du erwartest jetzt aber nicht, daß ich 1058/1129 auswendig weiß oder suche? Da wäre der Event-Text schon nett... Und der von Dir verlinkte Artikel ist keine Lösung, sondern - siehe @NorbertFe - nur ein kruder Workaround. Bei Dir stimmt was nicht im Gesamtsetup - Kerberos scheint nicht zu funktionieren, möglicherweise asynchrone KDC-Kennwörter oder fehlende SPNs, vielleicht auch Fehler im DNS, aber das kann über ein Forum niemand beantworten.

Das ist die Krux bei den meisten MS-Lizenzen - der Nachweis muß beim Audit ggf. erbracht werden können, daß keine fehlen. Das Stück Papier mit den erworbenen Lizenzen reicht als Lizenznachweis, wenn Du "irgendwie" auch nachweisen kannst, daß nicht mehr User/Clients zugreifen.

SMB alleine bringt bei DCs wenig, da gibts noch DFSR/NTFRS, RPC, LDAP, KDC usw. Rein technisch funktioniert das mit IPSec, die Frage ist halt nach dem Nutzen. Wenn ich nur zwischen den DCs nen Tunnel habe, was mache ich mit Anwendungen, die nicht Site-aware sind?

Mark Heitbrink hatte da mal ein Tool dafür. Die Firma hat aber leider zugemacht und das Tool ist nicht mehr zu finden... Und ich brauch's nicht, sonst hätte ich schon längst ein Skript gebaut, das den Export und Import übernimmt und dabei on the fly gleich passende Migtables inkl. GPP erstellt. Aber es gibt bei GPP genügend Möglichkeiten, mit Variablen zu arbeiten, so daß man gut ohne Migtables auskommt.

Für Dich ja, für mich war das weit weg... BTT: DC Locator - https://blogs.technet.microsoft.com/askds/2008/09/24/domain-locator-across-a-forest-trust/ Da stimmt was mit den Sites nicht, wenn die Clients in DE nach China wollen. Hatte Norbert schon drauf hingewiesen.

Das ist jetzt vielleicht fies von mir, aber: Grütze bleibt Grütze... LW-Mappings mit IP-Adresse - geht gar nicht.

Ich verstehe schon die Anfangsbeschreibung nicht: "Ich habe 2 Root-DC s und 2 Child DCs". Was ist denn ein Root DC und was ist ein Child DC?

Das bringt jetzt zwar niemand weiter und auch das BSI wäre mit mir nicht konform, aber: Wofür bitte ist ein Virenscanner auf einem DC hilfreich, der nur DC ist? Ich weiß es nicht... Edit: Unsere DCs können nicht ins Internet, und iexplore.exe sowie firefox.exe und chrome.exe sind per AppLocker gesperrt. Was nutzt mich ein Virenscanner auf diesen Systemen?

dsquery user -samid <Accountname> | dsget user -memberof -expand Access Token gibt es in einer funktionierenden AD-Umgebung nicht, das heißt inzwischen Ticket granting ticket http://technet.microsoft.com/library/cc772815.aspx "klist purge" macht vermutlich, was Du möchtest.

XML läßt sich recht gut skripten. Das XML-Schema der Group Policy Preferences ist gut dokumentiert. Das läßt sich also prima skripten, wenn man den Bedarf hat

Vielleicht hilft der Hinweis: "Jeder" ist im Standard nicht wirklich jeder, sondern nur "Authentifizierte Benutzer". Nur wenn der Gast-Account aktiviert wurde, ändert sich das, aber der ist normalerweise deaktiviert.

Naja, man könnte mal oben rechts mit "Mein Konto" anfangen und landet dann bei https://account.activedirectory.windowsazure.com/passwordreset/Register.aspx Und da klickt man dann auf "Ändern" hinter der Telefonnummer.

LOL - stimmt, das wäre dann "Äpfel und Birnen" Und ich vergesse MS16-072 inzwischen gerne, weil das schon so ewig her ist...

[OT] Dir fehlt das Gen, mir die Ialität. Wir sollten uns zusammentun [/OT]