daabm

Bin bei Jan. Wenn man skripten kann, sind Skripts nach wie vor die einzige tragbare Lösung für das Zuordnen/Trennen von Laufwerken und Druckern. Wenn Du das per GPP lösen willst: Immer 2 Preferences erstellen, eine die den Drucker verbindet, eine die ihn löscht. ILT dazu "ist nicht". Und da das das Problem vermutlich noch nicht lösen wird- GPP Debug Logging aktivieren und schauen - https://techcommunity.microsoft.com/t5/ask-the-directory-services-team/enabling-group-policy-preferences-debug-logging-using-the-rsat/ba-p/395555 Du hast aber die Windows-Verwaltung des Standarddruckers deaktiviert?

Ich würde dringend empfehlen, das wegzuwerfen und asap auf AppLocker umzustellen. Für diese Einstellung interessiert sich nur der Explorer... Und ja, ich weiß daß das die Frage nicht beantwortet. Aber die Ursache der Frage ist schon die falsche

Unkraut vergeht nicht? Spaß beiseite, Edgar: Wenn Du darüber reden kannst, gibt es einige hier, die sich Sorgen gemacht haben (oder noch machen). Magst Du was zu Deiner Auszeit sagen? Wenn nein, ist das für mich komplett in Ordnung... Und jetzt Licht aus, ab in die Federn! Gute Nacht, Board.

Manuell macht man da gar nichts... GPP Registry, Zielgruppenadressierung auf die Computerrolle, und der "aktuelle" PDCe bekommt die externe Zeitquelle. Oder wenn man's mit mehreren GPOs machen möchte, WMI-Filter, Win32_Computersystem.DomainRole (4=DC, 5=PDC). Damit sind dann auch FSMO-Transfers kein Thema mehr.

"Connect before logon" kennst Du? Im übrigen stimme ich den Vorrednern zu.

....und scheitern in einer gut verwalteten Umgebung dann daran, daß lokale Ausnahmen (genau wegen sowas) abgeklemmt sind

Nein, das geht nicht. Du kannst mit dem reinen Exe-Namen arbeiten, aber in Verbindung mit einem Pfad bist Du auf Umgebungsvariablen als einzigen variablen Bestandteil festgelegt. Du kannst das aber mit einem etwas "quirky" Trick dynamisch lösen Group Policy Preferences Registry und Zielgruppenadressierung. Mit der Zielgruppenadressierung kannst Du den Installationspfad in eine Variable schreiben, die Du in einem Reg-Wert verwenden kannst.

Ah, da bleibt das Licht vermutlich öfter mal aus 😘

Ich glaub ich kann das Licht ausmachen Feierabendbier ist auch schon alle, gute Nacht Board!

Das lief über's Wochenende - ich hab also leider keine Ahung Hab jetzt mal nen Perfmon drauf angesetzt (nach Dienstneustart), hätte ich auch gleich machen können... Wirklich schnell ist es immer noch nicht, aber das mag an der Anwendung liegen, die das nutzt - die ist etwas "verschachtelt" aufgebaut mit ACLs und Delegationen und etlichen Objekt-Querbeziehungen.

So, kurzes Feedback - nach einer hinreichend langen Wartezeit: Jetzt sind wir also "irgendwie" da gelandet, daß dsamain so viel Speicher braucht wie seine adamntds.dit. Eine Erklärung, warum das so lange gebraucht hat, habe ich nicht.

Ich bin beim Feierabend-Bier. Was ein -Tag...

Produktmäßig fällt mir da FirstAttribute an - oder OpenIAM, s.o. Aber Benutzeranlage im Selfservice ist ein sicherer Schuss ins Knie

Immer die frühen Vögel, die das Licht ausschalten, kaum daß die Sonne untergegangen ist

Antworten tut's weiter, aber langsamer - viiiiel langsamer... "Andere VM" - also andere Hülle/anderer Host - schon mehrfach. Update der VM auf 2016 oder 2019 wird auch diskutiert. Konkret zum I/O: Soll heißen: Solange der Speicher noch wächst, hab ich brutto knapp 300 MB I/O. Danach noch 180 kB.

Ein fröhliches "Moin!" in die Runde Viel Whitespace kann nicht drin sein - oben die originale, unten nach "ntdsutil file compact to" - stolze 13 MB kleiner geworden: Ich habe die defragmentierte DIT dann verwendet, aber wir sind unverändert ratlos: Die Diagramme decken einen Zeitraum von 30 Minuten ab. Memorywachstum stoppt, I/O stoppt auch. Memory insgesamt sieht in dem Moment so aus: Ich sehe da nichts, was auch nur ansatzweise an irgendeinem Limit wäre.

Nein, ich seh schon 128 GB RAM und 97 GB verfügbar Punkt 1: Steht jetzt ganz oben auf der Liste - Offline-Defrag. Nur dauert der ein paar etliche Stunden, bisher noch nicht dazu gekommen. Danke für den Denkanstoß! Punkt 2: Da läuft in dem Moment ein Check-Skript, das wirklich durch den kompletten Datenbestand durchgeht. Und "komplett" meint genau das, rekursiv durch die gesamte Containerstruktur. Edit: Das Check-Skript ist in dem Moment, wo die 28 GB Memory erreicht werden, bei weitem nicht zur Hälfte fertig. Ich bin gespannt... Und werde berichten.

Da fängt der Fehler im System glaub schon an

Hallo zusammen. Ich habe hier ein AD LDS mit einer adamntds.dit von 85 GB. Fragt nicht warum - ist so Der Server dazu (2012R2 Standard auf 2016 HyperV) hat 1 vSocket, 4 vCPU und 128 GB Hauptspeicher, und nach allem, was ich weiß und bei MS dokumentiert ist, sollte dsamain.exe (der LDS-Serverdienst) sich deshalb im Lauf der Zeit auch gut 85 GB RAM genehmigen. Tut es aber nicht: Anders formuliert: Bei 28 GB gibt es ein Plateau, die vorher stetig steigende Speichernutzung stagniert und CPU/IO fallen in den Keller. Reproduzierbar auch nach Reboot, immer das gleiche Spiel - Speicher steigt kontinuierlich, Plateau bei 28 GB und Performance im Keller. Hat jemand eine Erklärung, warum das so ist und was ich dagegen tun kann? Braucht der Server mehr vCPU? (Obwohl die Auslastung da gerade mal um die 30% liegt). Gibt es irgendwelche hardcoded Limits in dsamain.exe? Liegts an der aktuellen Luftfeuchtigkeit? (Obwohl, gestern war es trockener, da war das aber auch schon so...) Wenn Infos fehlen, einfach kurz Bescheid geben. Und ja, Google/MSDocs hab ich durch - da geht's aber immer nur um das Gegenteil, "AD braucht zu viel Speicher". Bei mir ist es "AD braucht zu wenig Speicher"

Mir ist die Anforderung nicht ganz klar, da geht es mir wie @Dukel. Geht es um die Produkthistorie oder um die Kundenhistorie oder um was genau? Die Formulierung "direkt am Produkt tätig" ist ein wenig diffus... Wenn's einfach sein soll, wäre ein WIki vielleicht nicht ganz falsch, aber da sind zu viele Anforderungen unklar.

for /? und dann schau Dir mal %~dp0 an.

Such mal nach "delayed expansion"; das ist was Dir hier fehlt... Der Set in der For-Schleife kommt im Rest vom Batch nicht an, %xml% enthält "nichts". PS: Das XML eines geplanten Tasks so zu parsen wäre mir nie eingefallen - Powershell kann das deutlich besser.

So aus dem Bauch: Du hast eigentlich kein DNS-Problem (bzw. nicht nur), sondern (auch) ein Kerberos-Problem. So ist das jedenfalls immer, wenn IP geht, Hostname aber nicht. Aber um da was zu sagen, hast Du zu wenig über Deine Infrastruktur erzählt. Der "Access denied" bei der DNS-Verwaltung kommt ja nicht daher, daß der DNS-Server nicht erreichbar wäre, sondern daß Du kein TGS dafür hast.

....und die Hoffnung stirbt zuletzt

Weiß leider niemand... :-(