COM Object verwenden mit eingeschränkten Rechten

[alzaimar]

Hi

Ich habe hier ein Programm, das im Tray sitzt ('Dispatcher') und eine verdammt große Tabelle verwaltet. Weiterhin habe ich diverse Clients, die alle ab und zu auf diese Tabelle zugreifen müssen. Im Dispatcher habe ich ein COM-Objekt (TAutoObject) als Schnittstelle zu den Clients. Bevor jetzt einer meint, die Tabelle könne doch in die DB... Nee, da kommt sie gerade her. Die Tabelle ist die Basis für eine ultraschnelle inkrementelle Suche.

Funktioniert auch prima, nur beim Kunden haben die Anwender eingeschränkte Rechte (kein Schreibzugriff auf die Registry).

Der Dispatcher (mit dem COM-Objekt) wird per Autostart gestartet und meckert nun, das er nicht in die Registry schreiben darf. Ich denke, das COM-Objekt will sich irgendwie registrieren.

Meine Frage lautet nun: Reicht es, den Dispatcher als Administrator einmalig zu registrieren (mit /REGSERVER), oder muss ich andere Klimmzüge machen, also z.B. den Dispatcher als Service registrieren (geht das?) oder permanent im Autostart mit Admin-Rechten zu starten, oder wie?

Für Vorschläge wäre ich dankbar.

[shmia]

Zitat von alzaimar:

Reicht es, den Dispatcher als Administrator einmalig zu registrieren (mit /REGSERVER)

Das ist die Mindestvorraussetzung.
Es muss einmal mit Adminrechten gestartet werden, damit es sich in der Registry verewigen kann.
EXE-Programme mit einer TLB versuchen sich grundsätzlich bei jedem Start zu registrieren.
Wenn das nicht gelingt, läuft das Programm stillschweigend weiter.
Ist die TLB und die CoClasses in der Registry verankert ist das kein Problem.

[alzaimar]

Cool. Danke.

[peschai]

Hallo

Ergänzende Hinweise:

Bei COM bzw. DCOM werden im Betriebssystembereich Informationen gespeichert, damit die verschiedenen COM/DCOM-Objekte interagieren können. Diese werden u.a. in der Registry unter LocalUser gespeichert und dazu muß dieser seit Windows2000 mindestens Hauptbenutzerrechte haben. Früher ging das auch mit Normalen Benutzterrechten. Aus Sicherheitsgründen hat das Microsoft aber verschoben. Viele Anwender kennen nur die Gruppen "NormalAnwender" und "Administratoren". Es gibt aber dazwichen noch weitere Gruppen u.a. auch die Gruppe der "Hauptbenutzer" (engl. PowerUser).

Damit ergibt sich folgendes:
1.) Falls möglich oder erlaubt, sollte der Benutzer auf dem entsprechenden Rechner der Gruppe der Hauptbenutzer zugeordnet werden. Falls die IT-Security dies verweigert, so besteht eventuell die Möglichtkeit, daß diese nur kurzfristig unter Aufsicht einer IT-Administrators erfolgt, mit dem Ziel das Programm einmal laufen zu lassen, damit alles richtig registriert wird. Danach können wieder die Normalen Benutzerechte eingestellt werden und es sollte funktionieren. Dieses Verfashren hat allerdings den Nachteil, daß bei einer Softwareänderung, dies wiederholt werden muss.

2.) In Firmen wo Anwedner mit nur mit normalen Benutzerrechten arbeiten dürfen, gibt es zumeist eine Art Softwareverteil-Dienst. Lass deine software paketieren und offiziell verteilen. Die Paketiereungssoftware erkennt die Registryänderungen und führt diese automatisch mit Admirechte bei der Installation via der Softwareverteilung durch.