Berechtigungsstufe funktioniert nicht in AD-Domäne

[bugblatterbeast 0]

Hallo,

 

  beim Versuch Autodesk zu installieren, ist es auf einer unser Arbeitsstationen zu einem bereits bekannten Fehler gekommen. Die Registrierung einer dll schlug wegen nicht ausreichender Rechte fehl (obwohl ich als Administrator angemeldet war).

 

Anscheinend sind die Administrator-Accounts nicht mehr das, was sie mal waren, denn es wurde mir empfohlen, die Kommandozeile mit dem Kontext-Menu-Eintrag "als Administrator ausführen" zu starten und dann die Registrierung der dll manuell vorzunehmen. Das macht jedoch keinen Unterschied...

 

Ich habe also eine Verknüpfung mit cmd erstellt und versucht die Berechtigungsstufe zu ändern und den Haken bei "Programm als Administrator ausführen" zu setzten - die Checkbox ist aber leider inaktiv, wie auch alle anderen Einstellungsmöglichkeiten unter Eigenschaften > Kompatibilität.

 

Kann man das mit GPO-Einstellungen in den Griff bekommen? Macht es einen Unterschied, ob ich so eine Installation als lokal angemeldeter Administrator oder über die Domäne angemeldeter Domänenadministrator ausführe?

Ich arbeite seit beinahe zwei Jahrzehnten mit UNIX-basierten Systemen und habe leider nur wenig Erfahrung mit dem komplizierten Rechtesystem von Windows.

 

Gruß

 

Nachtrag: auf dem Client läuft Windows 7 (64 Bit) + SP1

bearbeitet 17. Dezember 2013 von bugblatterbeast

[lefg 276]

Hallo und ein Willkommen am Board .)

 

- um welches Produkt von Autodesk handelt es sich?

- tritt das Problem nur an dem einen Client auf oder auch an anderen?

- wurde schon bei Autodesk beim Support nachgefragt, in der FAQ nachgeschaut?

 

Gruß

 

Edgar

[Sunny61 807]

Mit der Einführung von VISTA gibt es die Benutzerkontensteuerung: http://de.wikipedia.org/wiki/Benutzerkontensteuerung Deshalb mußt du als User mit Adminrechten immer noch explizit als Administrator vieles starten.

 

Und nein, es macht 'fast' keinen Unterschied ob Du als lokaler Admin oder als Domain Admin anmeldest. An den lokalen Rechten ändert das nichts.

[bugblatterbeast 0]

Vielen Dank für Eure Antworten.

 

@lefg:

Es handelt sich um die "Building Design Suite Premium" und das Problem tritt bei der Installation von AutoCAD auf.

Das Problem besteht nur bei einem Client

Wir haben einen Support-Vertrag und das Problem ist unter der Adresse http://upandready.typepad.com/up_and_ready/2011/07/error-2738-installation-could-not-access-vbscript-run-time-for-custom-action.html dokumentiert. Jedoch funktioniert die dort beschriebene Lösung nicht.

 

@Sunny61:

Vielen Dank für den Link und die Antwort auf die generelle Frage, das ist schon mal gut zu wissen.

 

super-ausführliche Beschreibung:

 

In der oben genannten Lösung wird beschrieben, wie ich die betreffende dll mit Admin-Rechten registriere und ggF. die bereits unter falschen Rechten ausgeführte Registrierung der dll aufhebe.

Ich habe also zuerst mit dem Befehl "regsvr32 /u vbscript.dll" die bestehende Registrierung aufgehoben und dann mit "regsvr32 vbscript.dll" wieder eingerichtet. Das habe ich in beiden relevanten Verzeichnissen gemacht. Kam mir zwar komisch vor, dass der Befehlsname explizit auf eine 32Bit-version hinweist und auch für die 64Bit-dll verwendet werden soll aber das scheint schon seine Richtigkeit zu haben - ist ja auch nur eine Registrierung...

 

Die Installation funktionierte trotzdem nicht. Also habe ich, die Registry manuell bearbeitet. Dabei fiel mir auf, dass ich, obwohl ich regedit mit dem Kontextmenu-Eintrag "als Administrator ausführen" gestartet habe, nur in der Lage war, meinen eigenen LOCAL_USER-Bereich der Registry zu verändern, was für mich darauf hinwies, dass das mit dem "als Administrator ausführen" nicht richtig geklappt hat - es kam auch nicht die gewohnte Bestätigungsabfrage. Daher habe ich mir eine Verknüpfung zur Kommandozeile cmd auf dem Desktop angelegt und versucht im Eigenschafts-Menu unter Kompatibilität einzustellen, dass der Befehl immer im Administrator-Modus ausgeführt werden soll aber die Checkbox war inaktiv und konnte nicht gesetzt werden.

 

Unsere Clients sind in einer Active-Directory-Domäne verbunden und ich weiß, dass man über die Gruppenrichtlinien steuern kann, ob es möglich ist, Administratorrechte anzufordern. Der Punkt Richtlinien – Windows-Einstellungen – Sicherheitseinstellungen – Lokale Richtlinien – Sicherheitsoptionen war aber in unseren Gruppenrichtlinien nicht aktiviert. Um sicherzugehen, dass es nicht am Default-Wert liegt, habe ich testweise mal die Richtlinie aktiviert und den Wert so eingestellt, dass eine Anforderung von Administratorrechten im sicheren Desktop-Modus möglich sein sollte (ich weiss den genauen Wortlaut nicht mehr). Der Zustand blieb jedoch unverändert.

 

Daher habe ich den oberen Beitrag geschrieben. Ich glaube, dass es in unserer Domäne ein Problem mit der Anforderung von Administratorrechten bzw. mit der Festlegung der Berechtigungsstufe gibt. Das könnte ja durchaus noch weitere Probleme bereiten als nur diese Schwierigkeiten bei der Installation von AutoCAD.

 

Gruß, bbb

bearbeitet 17. Dezember 2013 von bugblatterbeast

[Daniel -MSFT- 129]

Hi bbb,

 

drück mal die Windows-Taste, gib cmd ein und danach STRG+ENTER. Das ruft die CMD-Shell mit administrativen Rechten auf. Du solltest die UAC-Abfrage bekommen, bestätigen und dann siehst Du eine CMD-Shell mit dem Titel Administrator:Eingabeaufforderung und stehst im %WINDIR%\system32-Ordner.

 

Have fun!
Daniel

[bugblatterbeast 0]

Hallo Daniel, vielen Dank für den Hinweis. Was mir besonders geholfen hat, war die Information, dass im Fenstertitel der CMD-Shell auf die Administratorrechte hingewiesen wird. Das hatte ich bisher gar nicht bemerkt.

 

Meine Vermutung war falsch. Es gibt kein Problem mit der Berechtigungsstufe... es ist wohl normal, dass man heutzutage auch mit Administrator-Berechtigungen bestimmte Einträge in der Registry nicht bearbeiten/löschen kann.

 

Das eigentliche Problem war, dass ich ganz selbstverständlich davon ausging, dass ich die Installation von einem Netzlaufwerk aus starten könnte... nach einem kurzen Test mit einer auf ein Netzlaufwerk kopierten cmd.exe musste ich jedoch feststellen, dass dort einfach keine Admin-Rechte zugeteilt wurden. Ich habe diesen unbequemen Umstand jetzt dadurch in den Griff bekommen, dass ich bei der Laufwerkzuordnung die Option "Im Sicherheitskontext des angemeldeten Benutzers ausführen..." gewählt habe.

 

Da die Installation mehrere Stunden dauert, kann ich erst morgen sagen, ob es auch das Problem mit der AutoCAD-Installation behoben hat.

 

Danke an alle und Gruß, bbb

[Daniel -MSFT- 129]

Hi bbb,

 

eine per UAC mit höheren Rechten versehene Instanz kann nicht im Namen der niedrigeren Instanz auf das Netzwerk zugreifen. Weiterhin gibt es auch noch einen Schutz gegenüber dem Ausführen von Dateien über Netzwerk, wenn sie nicht vertrauenswürdig sind. Das alles solltest Du dabei berücksichtigen.

 

BTW: Es ist immer einfacher, wenn Du beschreibst, was Du erreichen willst und nicht die Probleme Deines Lösungswegs :-) Warum installierst Du Autodesk nicht automatisch? Z.B. über eine Gruppenrichtlinie? Dann musst Du Dich da gar nicht so verbiegen. Schau mal hier rein (ich weiß nämlich nicht, welches Autodesk-Programm und -Version Du meinst): http://www.itninja.com/software/autodesk/browse.

 

Have fun!
Daniel

[bugblatterbeast 0]

Hallo Daniel,

 

kann das mit der Einstellung, die ich gesetzt habe, zu anderen Problemen führen? Gäbe es noch einen eleganteren und systemkonformeren Weg, ein Netzlaufwerk oder einen ganzen Server in der Domäne als vertrauensvoll zu deklarieren?

 

Gruß, bbb

 

Ich verstehe Deinen berechtigten Einwand. Mit den anfangs gegebenen Informationen wäre es wohl kaum möglich gewesen, auf die Lösung meines Hauptproblems zu kommen... Allerdings habe ich auf diese Art gleich sehr viel gelernt, was mir mit Sicherheit noch hilft, da ich mit meiner Kenntnis über AD-Domänen und Gruppenrichtlinien noch nicht so weit bin. Ich hoffe ja schließlich, mit etwas Hilfe von Leuten wie Euch, die auf dem Gebiet einfach mehr Erfahrung haben, zu lernen, wie ich mir in Zukunft selbst helfen kann.

 

Bevor ich mit Installationen über Gruppenrichtlinien anfange, müsste ich erstmal mehr Erfahrung über den AD-Betrieb sammeln. Ich hätte Angst, sonst den laufenden Betrieb zu stören. Wir haben sehr viel Spezialsoftware und verschiedene Konfigurationen. Es wäre zwar schon sehr schön, da einiges über automatische Software-Installationen per Gruppenrichtlinie zu regeln. Ich dachte aber, dass das nur mit .msi Dateien geht und nicht mit den so oft ausschließlich zur Verfügung gestellten ausführbaren Installern.

[Daniel -MSFT- 129]

Hi bbb,

 

Du kannst darüber alles installieren, was über einen einzeiligen Aufruf automatisch ausgeführt wird und keine Rückfragen stellt. MSI-Pakete sind eine Möglchkeit. Die meisten Installationsprogramme (setup.exe & Co.) unterstützen Schalter, die die Installation automatisiert. Die Seite, die ich verlinkt hatte, stellt ein Archiv für die verschiedensten Programm-Installer mit den jeweiligen Parametern bereit.

 

Um Netzwerkserver als vertrauenswürdige Ablage zu erklären, schau mal hier rein: http://technet.microsoft.com/de-de/library/bb496428.aspx

 

Have fun!
Daniel

[Sunny61 807]

Zusätzlich zum Hinweis von Daniel bezüglich Installation per GPOs sei dir der WSUS Package Publisher in Kombination mit dem WSUS ans Herz gelegt. Hier findest Du ein paar HowTos zu dem Thema: http://www.wsus.de/lup Einfach in einer ruhigen Stunde eine passende Umgebung aufsetzen und ein wenig testen, lohnt sich auf alle Fälle.

[lefg 276]

Moin

 

Warum ein Autodeskprodukt über ein Netzlaufwerk installieren? Wurde es schon mal per UNC-Pfad probiert?

 

Warum es überhaupt über das Netzwerk installieren und nicht von den Installationsdatenträgern?

 

Wurde der Support von Autodesk schon kontaktiert?

 

Falls dieses Problem tatsächlich nur speziell bei der Installation auf diesen einen Rechner auftritt, sonst bei anderen Rechnern so funktiont hat, und das Problem auch bei einer Installation mit eingelegtem Datenträger auftritt, dann installierte ich den Rechner wahrscheinlich neu, denn ich fragte mich, ob an dem Rechner etwas verbogen wurde. Es ist natürlich die Frage, wobei verbogen? Bei einer anderen Installation? Installation von was? Im Zweifelsfall versuchte ich es mit einem quasi jungfräulichen Rechner.

 

An eine Berechtigungsstufe als wirkliche Ursache zweifele ich mal, denn Autodesk baut ein Deploy normalerweise funktionierend.

bearbeitet 19. Dezember 2013 von lefg