NilsK

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

Moin, lass mich raten, du bewegst dich hauptsächlich im oberen Enterprise-Segment? :D Da mag das durchaus richtig sein. Bei SMB-Kunden wird der prozessuale Aufwand nicht wirtschaftlich sein, da muss dann das Ergebnis reichen (das ja dasselbe ist). Gruß, Nils

Moin, Kunde oder intern? Neben aller Schönheit ist ja durchaus entscheidend, wer die Brötchen bezahlen soll. Wenn "nur so, sonst gar nicht" dazu führt, dass man den Auftrag nicht bekommt, dann hat ja auch niemand was davon. Ich würde da also eine Weile argumentieren und auf Einsicht hoffen, zumal "Wartung" ja nun keinen messbaren Unterschied bringt - wenn ich auf einem Server 12 Anwendungen warten muss oder auf einem Server 10 und auf dem anderen 2, dann ist das gehupft wie gesprungen. Wenn ich so nicht weiterkomme, würde ich schauen, ob es "echte" No-gos gibt (wahrscheinlich nicht). Dass es nicht supported sei, trifft ja so nicht zu, es ist nur nicht schön. Gruß, Nils

Moin, wenn ich nicht ganz falsch liege, musst du das auf einem RODC über die Local Security Policy einstellen. Empfehlung: Prüfen, ob das mit dem RODC wirklich sinnvoll ist. Ich habe seit zehn Jahren noch keinen Kunden getroffen, bei dem das wirklich passte. Gruß, Nils

Moin, m-hm. Lassen wir das einstweilen dahingestellt. Ich bin kein Freund von RODCs, und meist werden sie auch falsch implementiert. Heißt "ich habe 2 DCs", dass es nur einen schreibbaren DC gibt? Das wäre dann dringend zu ändern. DCs sollte niemals in andere OUs verschoben werden, das gilt auch für RODCs. Das wird mit deinem Problem nicht direkt zu tun haben, ich würde es aber trotzdem ändern, weil es künftiges Troubleshooting erschweren und auch für seltsame Probleme sorgen kann. Ich habe jetzt noch nicht ganz verstanden, was wo eingetragen wurde. Kannst du das bitte noch mal genau beschreiben? Relevant wäre dabei auch, von welchen Konten die Rede ist - wer ist "der Dom-Admin"? Gruß, Nils

Moin, bevor wir ans Detail gehen: Warum ein RODC? Gruß, Nils

Moin, ja, natürlich gibt es Lösungen für das LUN-Problem. Aber hier ist doch das Szenario vorgegeben. Gruß, Nils

Moin, wenn ich es richtig sehe, sammelt die Software nicht nur die Metadaten der Druckvorgänge, sondern auch die Dokumente ein und speichert sie. Da sehe ich Konfliktpotenzial mit Betriebsräten und Mitarbeitern - nur um darauf hingwiesen zu haben. Noch heftiger ist das natürlich bei der Cloud-Variante. Gruß, Nils