NilsK

Moin, abgesehen von der technischen Frage stellt sich auch ein Lizenzproblem. Du darfst Client-Windows nicht einfach so als VM installieren. Dafür sind spezielle Lizenzen erforderlich (VDA oder Software Assurance). Ansonsten wäre Variante 1 sicher möglich. Gruß, Nils

Moin, rekursive Abfragen sind m.W. per LDAP nicht möglich, jedenfalls nicht mit einem einzelnen Suchstring. Warum fragst du nicht Domäne A ab, wenn da sowieso die User gepflegt werden sollen? Gruß, Nils

Moin, das ist aber auch ein anderes Produkt, das noch mal eine ganz andere Infrastruktur aufmacht. Vor allem hat es (zumindest derzeit) eine andere Zielrichtung als der TO. Und nein, es ist nicht das gleiche wie ein herkömmliches lokales AD. Gruß, Nils

Moin, das Problem bei ADFS ist, dass es sehr viel Infrastruktur braucht und es ca. 1000 Stellen gibt, an denen es haken kann. Daher kann man da keine sinnvollen "probier mal dies"-Hinweise geben. Du möchtest also Webzugriffe von extern testen? Was ist das Ziel - die Technik kennenlernen? Oder soll eine produktive Installation dabei rauskommen? Falls Letzteres, was sind die Anforderungen, und warum soll diese Standardaufgabe mit ADFS und WAP gelöst werden und nicht über einen Reverse Proxy? Nur mal ein Schuss ins Blaue: Deinen öffentlichen URL mit test.de können die beteiligten Systeme korrekt auflösen? Gruß, Nils

Moin, nein, so kann man das nicht. Erstens wäre das sehr komplex, zweitens ist nicht ganz klar, was du da eigentlich vorhast. Weder Exchange noch RDS brauchen ADFS, also wäre das schon mal zu klären. Beschreibe bitte noch mal, was genau dein Ziel ist und was du vorhast. Gruß, Nils

Moin, das sagt ungefähr so viel aus wie "bis auf Ihre Krankheit sind Sie kerngesund". Ein Bluescreen tritt nicht von selbst auf und ist auch keine Sache von irgendeiner Konfiguration. Auch Hyper-V "kann" solche Fehler nicht "verursachen", allenfalls könnte Hyper-V eine Treiberfunktion aufrufen, die selbst fehlerhaft ist oder die an einem Hardwarefehler scheitert. Du hast ganz oben angegeben, dass kein Dump geschrieben würde. Ist das System denn so konfiguriert, dass es Dumps schreiben sollte? Falls nein - einschalten. Dann hast du einen Dump, der durchaus oft wertvolle Hinweise geben kann. Gruß, Nils

Moin, was erscheint denn da für ein Fehler? Ich kann mir kaum vorstellen, dass bei diesen 15 Usern Berechtigungen fehlen, denn dann sollte der anfragende Client keine Fehler bekommen, sondern schlicht die Objekte nicht sehen. Wäre also vermutlich was anderes, vielleicht Attributwerte, mit denen die Applikation nicht klarkommt. Um die Berechtigungen der beteiligten Objekte und Container trotzdem zu prüfen, empfehle ich LIZA: http://ldapexplorer.com/en/liza.htm Gruß, Nils

Moin, danke, Franz. Mal wieder interessant, dass in erläuternden Webseiten eine Einschränkung steht, die in den vertragsrelevanten Dokumenten nicht zu finden ist. Also, meiner Interpretation nach dürfte das auf den Einsatzfall meines Kunden passen. Danke für eure Unterstützung. Schöne Grüße, Nils

Moin, trotzdem führt der ganze Ansatz doch in die Irre. Das Skript simuliert quasi einen Rechtsklick auf die jeweilige Datei und ruft aus dem Kontextmenü die Funktion "Drucken" auf. Nun ist es auf deinem Testrechner so, dass die Office-Dateien ohne weitere Rückfrage gedruckt werden, die Bilder aber eine Bestätigung des Druckdialogs brauchen. Wenn du jetzt eine Logik implementierst, die die ID des anzeigenden Programms raussucht, um da dann einen Tastendruck zu simulieren, wird das sehr wahrscheinlich nur mit genau dem Bildbetrachter funktionieren, den du auf deinem Testrechner hast. Bei Elke Müller könnte es sein, dass kein Tastendruck erforderlich ist, und dein Skript sendet einen Tastendruck irgendwo hin, wo er vielleicht ganz was anderes auslöst. Oder bei Ute Meyer muss man nicht Return drücken, um zu drucken, sondern erst noch D ... und bei Ulla Schmidt ist ein anderes Office installiert, wo die Druckfunktion noch mal ganz andere Parameter braucht. Solche Basteleien sind immer sehr vom konkreten Kontext abhängig und fast nie auf andere Situationen übertragbar. Also eben ein schlechter Ansatz. Gruß, Nils

Moin, ah, okay, die Interpretation ergibt Sinn. Vielen Dank, das ist ein guter Anhaltspunkt. Am Ende muss der Kunde (also hier: unser Kunde) das ohnehin selbst klären, aber so können wir ihm eine Orientierung geben. Schöne Grüße, Nils

Moin, nein, das siehst du nicht falsch. Aber deine Methode, das Programm zu starten, gibt dir diese ID nicht zurück. Und statt jetzt zusätzliche Klimmzüge einzubauen, die die ID irgendwie rausfinden, um damit den Klimmzug mit SendKeys zu implementieren (der aus zahlreichen anderen Gründen fehlschlagen kann) ... du verstehst? Gruß, Nils

Moin, OK, nachvollziehbar, aber doch ziemlich von hinten durch die Brust ins Auge ... wie wäre es denn, wenn du anstelle der SendKeys-Akrobatik einen Bildbetrachter suchst, der direkt auf einen Standarddrucker druckt, statt einen Druckdialog zu zeigen? SendKeys ist sehr problematisch und geht bei sowas oft in die Hose. Mal ganz davon abgesehen, dass die Methode, die du hier brauchst, um den Druckbefehl zu senden, eben keine Process ID zurückgibt. Gruß, Nils

Moin, die einfachste Variante für Nicht-Skripter ist AdFind (http://joeware.net/freetools/tools/adfind/). adfind.exe -b OU=Dein,OU=Container,DC=deine,DC=domain,DC=tld -c Um nur User zu finden: -f "(&(objectClass=user)(objectCategory=person))" anhängen. Gruß, Nils

Moin, die kurze Antwort ist "nein", für alles Nähere müsste man tief einsteigen. Gruß, Nils

Moin, wie so oft widersprechen sich verschiedene Quellen hier im Detail. Falls also niemand den betrachteten Fall beantworten kann, werden wir auf den Lizenzgeber zugehen müssen. Einstweilen vielen Dank, Nils PS. @zahni - Seite 9 in einem Vierseiter?

Moin, ja, das "er" war natürlich falsch, entschuldige. Mir ist jetzt aber auch überhaupt nicht mehr klar, was dein Skript nun eigentlich macht und welche Process ID du hast. Zunächst dachte ich, dass dein Skript die Pfade zu ausführbaren Dateien ausliest und diese dann ausführt - darauf bezog sich mein Hinweis. Anscheinend ist das aber gar nicht der Fall. Also beschreib doch noch mal genauer, was da eigentlich passiert bzw. passieren soll. Dann haben wir vielleicht eine bessere Idee davon, was wir vorschlagen können. Gruß, Nils

Moin, ja, das ist bekannt und wird parallel evaluiert. Es spräche aber eben einiges für AD bzw. AD LDS, und das einzige, was dem wirklich entgegensteht, ist die unklare Lizenzfrage. Gruß, Nils

Moin, @MurdocX: er möchte nicht die ID des Skriptprozesses, sondern die von der Applikation, die er im Skript aufgerufen hat. @lynnv: Soweit ich sehe, gibt ShellExecute keine Informationen zurück, da dürftest du also schlechte Karten haben. Eine andere Methode sollte hier helfen: Set objShell = CreateObject("WScript.Shell") comspec = objShell.ExpandEnvironmentStrings("%comspec%") Set objExec = objShell.Exec(comspec & " /c ipconfig") WScript.Echo objExec.ProcessID Aber mal ganz grundsätzlich: Es scheint mir keine gute Idee, einen "beliebigen" Wert aus einer Datenbank einfach mal so zum Ausführen eines Prozesses zu nutzen ... das öffnet Angriffen Tür und Tor. Gruß, Nils

Moin, hab ich auch überlegt, aber ich verstehe dort die Regel "who benefits" nicht recht. Vielleicht hat da jemand mehr Einblick ... sonst muss der Kunde den langen Weg gehen, beim Hersteller jemanden zu finden, der das versteht und eine Aukunft geben kann. Edit/Ergänzung: In den Erläuterungen (aber auch nur dort) finde ich Formulierungen wie diese: (Quelle: https://www.microsoft.com/de-de/licensing/produktlizenzierung/windows-server.aspx#tab=2) In den Product Terms scheint das überhaupt nicht erläutert zu werden. Was ist aber nun so ein Zugriff "ausschließlich zugunsten des Lizenznehmers"? Im konkreten Fall nutzen die "Kunden" Leistungen der Applikationen, für die sie aber nicht direkt bezahlen. Die Bezahlung erfolgt von Dritten. (Genauer kann ich das hier nicht beschreiben.) Passt das nun zu der Bedingung oder nicht? Am Ende verdient das Unternehmen Geld, indem es die Applikationen bereitstellt - aber die Nutzer dieser Applikationen sorgen nur indirekt für die Einnahmen. Gruß, Nils

Moin, eine etwas spezielle Lizenzfrage: Ein Kunde betreibt eine Reihe Web-Applikationen, die über eine gemeinsame Authentisierungslösung von ca. 150.000 Kunden verwendet werden. Man erwägt nun, an diese Authentisierungslösung ein neues Daten-Backend für die Anmeldekonten anzubinden und würde dafür gern Active Directory nutzen. Rein technisch ergäbe das in dem Fall durchaus Sinn, möglicherweise nicht mit dem "echten" AD, sondern mit AD LDS. Schwierig scheint mir da aber die Lizenzfrage zu sein. Kann mir jemand sagen, was für Lizenzen der Kunde dafür bräuchte? Es ginge ja dann um 150.000 Benutzer, die sich über Windows-Server anmelden, aber keine Mitarbeiter des Unternehmens sind. Die Applikationen selbst laufen nicht auf Windows, auch sonst sind keine Windows-Dienste an den Applikationen beteiligt. Schönen Dank, Nils

Moin, muss denn die Anwendung das selbst per LDAP rausfummeln? Kann sie nicht einfach das Access Token des Users auswerten? Gruß, Nils

Moin, wie erwartet. :D Danke für die Rückmeldung! Gruß, Nils

Moin, in aller Regel hat der Domänen- bzw. Forest-Betriebsmodus keine Auswirkungen auf Benutzer oder Anwendungen. Die Tücke liegt dort aber im Detail. Besonders Exchange muss man im Blick haben, möglicherweise aber auch andere Applikationen, die intensiv mit dem AD zusammenarbeiten. Ist Exchange im Einsatz, wenn ja in welcher Version? Gruß, Nils

Moin, mach den Host neu. Da sowieso unbekannt ist, was dort geschehen ist, ist das der einzige sichere Weg und vermutlich auch schneller als alle Reparaturversuche. Gruß, Nils

Moin, @Otaku: so seh ich das auch. :) Gruß, Nils