Jump to content

dsquery auf der WS ausführen


Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

Hallo Gemeinde,

 

in zwei Domänen wird auf per Startskript(Benutzerknoten) ausgeführt:

for /f "tokens=* delims=," %%a in ('%logonserver%\netlogon\dsquery user -name %username%') do echo %%a

Dieser Satz dient nur dem Test.

 

In einer Domäne bringt er an allen Usern und WS das gewünschte Ergebnis:

"CN=LefgruenE,OU=Dozenten,OU=Dozenten,DC=1Lubeca,DC=loc" 

Das Ergebnis eines ähnlichen Satzes wird für das Mapping verwendet.

 

In einer zweiten Domäne wird nur beim Administrator(Domäne) an der WSdas Ergebnis angezeigt, bei anderen Benutzern, auch Domänen-Admins nichts.

 

Ich habe keine Erinnerung mehr, ob und wo ich was gedreht habe dafür.

 

Hat bitte jemand einen Tipp für mich?

 

Habt Dank für Aufmerksamkeit und Rat.

 

Edgar

Link zu diesem Kommentar
was hat dsquery im netlogon-Verzeichnis zu suchen? Mach dochmal %windir%\system32
Der Befehl "dsquery" ist entweder falsch geschrieben oder konnte nicht gefunden werden.

Moin,

 

sind vielleicht auf der dsquery-Kopie der zweiten Domäne die Berechtigungen eingeschränkt?

 

Gruß, Nils

Moin,

 

Tscha, der Befehl selbst wird ausgeführt, keine Fehlermeldung. Ob es etwas mit dem Auslesen des AD zu tun hat?

Link zu diesem Kommentar

Moin,

 

was hat dsquery im netlogon-Verzeichnis zu suchen?

 

wenn man es aus dem Logonskript aufrufen will, ist das irgendwie die beste Stelle. ;-)

 

Mach dochmal %windir%\system32

 

Als User? Ziemlich aussichtslos.

 

@lefg: Wie unterscheiden sich die beiden Domänen? Ich habe aber richtig verstanden, dass es um zwei völlig getrennte Domänen geht, die jeweils von Usern derselben Domäne abgefragt werden?

 

Gruß, Nils

Link zu diesem Kommentar

Hallo Nils,

 

es handelt sich um völlig (physikalische Netze) getrennte Domänen. Auch die User sind andere.

 

Bei der ersten, der älteren Domäne hab ich es (damals) so hinbekommen, ein User kann mit dsquery die Zugehörigkeit zur OU auslesen, diese hat die selbe Bezeichnung wie die Sicherheitgruppe und das Gruppenverzeichnis. So wird dann das Gruppenlaufwerk mapped.

 

::map UserGroup

for /f "tokens=2 delims=," %%a in ('%logonserver%\netlogon\dsquery user -name %username%') do set ou=%%a

set group=%ou:~3%

 

net use * /delete /yes

 

set FS=1Server

if /i %logonserver% equ \\1server (

if exist \\%FS%\%group% net use G: \\%FS%\%group% /persistent:no

if exist \\%FS%\%group%\%username%Home net use H: \\%FS%\%group%\%username%Home /persistent:no

if exist \\%FS%\%group%\1Aufgaben net use I: \\%FS%\%group%\1Aufgaben /persistent:no

if exist \\%FS%\%group%\1Austausch net use J: \\%FS%\%group%\1Austausch /persistent:no

exit

)

 

Bei der anderen, neueren Domäne, wurde das mit dem Mapping bisher anders gemacht. Ich bin dabei, einige Dinge zu egalisieren.

Link zu diesem Kommentar

Um feststellen zu können, ob es an dsquery oder an was anderem liegt, könntest du ja mal eine Abfrage mit AdFind ausprobieren:

 

faq-o-matic.net » Active-Directory-Massenoperationen mit AdMod und AdFind

 

Wenn es damit geht, liegt das Problem irgendwie an dsquery. In dem Fall sollte ein Wechsel auf AdFind das Problem einfach lösen.

 

(In der konkreten Situation wären natürlich auch noch andere Techniken denkbar, z.B. ifmember oder die Abfrage der OU per VBS.)

 

Gruß, Nils

Link zu diesem Kommentar
Moin,

 

wenn man es aus dem Logonskript aufrufen will, ist das irgendwie die beste Stelle. ;-)

 

Gruß, Nils

 

 

Ok, kann man so sehen, wenn's netlogon nicht zu gross wird. Ich halte mein Netlogon möglichst frei von exe'n und anderen Files und leg benötigte Programme auf zentrale Fileserver bzw. halt die Programme gleich lokal vor. Deswegen ist's mir komisch vorgekommen. Aber das ist Geschmackssache.

 

cu

blub

Link zu diesem Kommentar

man sollte dann darauf achten, dass man bei vielen Files keine Journal_Wraps erzeugt und evtl. die Journalgrösse hochschrauben

 

cu

blub

 

 

Microsoft Corporation

Ntfs Journal Size in MB

Registry path

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters

 

Version

Windows Server 2003 and Windows 2000

 

Controls the size of the update sequence number (USN) journal. In Windows Server 2003, the default journal size is 128 megabytes (MB); in the pre-SP1 release of Ntfrs.exe, the default USN journal size is 512 MB. This setting applies to all volumes hosting an FRS replica tree. When the USN journal is set to 128 MB on a server that contains more than 100,000 files (or 400,000 files if the server is running the pre-SP1 release of Ntfrs.exe), we recommend that you increase the USN journal size by 128 MB per 100,000 additional files managed by FRS on the server.

 

To increase the size of the USN journal, you must stop and restart the NTFRS service. To decrease the size of the USN journal, you must reformat all volumes containing FRS replicated content.

 

Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...