PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Geschlossen Clients nachträglich zu SOA hinzufügen - wie?



noobadmin
15.05.14, 16:06
hallo forengemeinde,
mein problem klingt trivial und das ist es vermutlich auch.

ich möchte die SOA-konsole auf einem server neu installieren (wegen seltsamer konfiguration und neuer programmversion) und danach alle clients wieder der konsole hinzufügen. auch habe ich einige clients manuell installiert (kein rollout-job) und diese mangels kenntnis der SOA-IP nicht hinzugefügt, weshalb ohnehin mal ordnung geschaffen werden muss. allerdings finde ich auf teufel komm raus keine option zum nachträglichen angeben der SOA-adresse...

bin für jegliche hilfe dankbar :)

/edit: es handelt sich um EPS 8.0 auf Win7 Pro SP1 x64 und SOA 1.2.2 auf SBS2008 (letzerer ist AD-controller)

Merlin
16.05.14, 15:51
Hallo,

erstmal solltest du auf die aktuelle Version upgraden: http://forum.avadas.de/threads/4246-avast!-Endpoint-Protection-Download-Informationen

Du kannst meines Wissens nach erstmal Clients im Netzwerk suchen lassen und diese dann verwalten, indem du die Clients nochmal automatisch verteilen lässt.

noobadmin
19.05.14, 15:12
vielen dank erstmal, das lässt hoffen :)

nun stehe ich allerdings vor dem Problem, dass ich die SOA weder deinstallieren noch upgraden kann, da ich auf den "Could not access VBScript run time for custom Action"-fehler stoße. ich finde es gelinde gesagt unverschämt, so etwas bei kommerzieller Software zu erleben, zumal Microsoft ausdrücklich von der Verwendung solcher methoden abrät...

Merlin
19.05.14, 15:23
Hallo,

vielleicht hilft dir das weiter: http://blogs.msdn.com/b/heaths/archive/2007/05/31/windows-installer-errors-2738-and-2739-with-script-custom-actions.aspx

noobadmin
19.05.14, 23:19
Hallo,

vielleicht hilft dir das weiter: http://blogs.msdn.com/b/heaths/archive/2007/05/31/windows-installer-errors-2738-and-2739-with-script-custom-actions.aspx

habe ich natürlich längst probiert, als ich hierdrauf (http://blogs.msdn.com/b/robmen/archive/2004/05/20/136530.aspx) stieß und hat erwartungsgemäß nicht geholfen

Merlin
20.05.14, 12:51
Hallo,

die beiden Schlüssel existieren bei dir also unter HKEY_LOCAL_MACHINE, aber NICHT unter HKEY_CURRENT_USER, richtig? Beide Schlüssel enthalten auch einen Unterschlüssel InprocServer32, der als Standardwert auf C:\Windows\system32\vbscript.dll (oder C:\Windows\SysWOW64\vbscript.dll) verweist?

Funktionieren denn normale .vbs Dateien auf dem Server?

noobadmin
20.05.14, 22:26
Hallo,

die beiden Schlüssel existieren bei dir also unter HKEY_LOCAL_MACHINE, aber NICHT unter HKEY_CURRENT_USER, richtig?

ja



Beide Schlüssel enthalten auch einen Unterschlüssel InprocServer32, der als Standardwert auf C:\Windows\system32\vbscript.dll (oder C:\Windows\SysWOW64\vbscript.dll) verweist?


verweisen auf die jeweiligen 32er-versionen der vbscript.dll und jscript.dll, änderungen an den werten sind auch nicht möglich
oder müssen BEIDE auf vbscript zeigen?



Funktionieren denn normale .vbs Dateien auf dem Server?


keine ahnung, ist dem server in seiner position als fileserver aber auch herzlich egal

übrigens habe ich nach der oben verlinkten anleitung auch JEWEILS die 32 und 64bit-versionen neu registriert...es klang allerdings nicht, als würden die sich gegenseitig behindern.

Merlin
20.05.14, 23:14
Hallo,


keine ahnung, ist dem server in seiner position als fileserver aber auch herzlich egal

ich wusste gar nicht, dass der Fileserver ein Bewusstsein hat :) Meine Frage ging auch eher in die Richtung, ob du mal einen Testscript ausführen kannst (was z.B. nur eine Meldung ausgibt), um zu sehen, ob VBScript überhaupt funktioniert. Das sollte es nämlich.

noobadmin
21.05.14, 14:41
Hallo,


ich wusste gar nicht, dass der Fileserver ein Bewusstsein hat :) Meine Frage ging auch eher in die Richtung, ob du mal einen Testscript ausführen kannst (was z.B. nur eine Meldung ausgibt), um zu sehen, ob VBScript überhaupt funktioniert. Das sollte es nämlich.

das tut es:
http://abload.de/img/vbstestizssy.jpg

(ich weiss nicht, wie viel Aussagekraft das hat, aber für mich sieht es nach Funktion aus :P)

Merlin
21.05.14, 19:32
Hallo,

gibst du bei der Installation des Pakets eventuell ein anderes Benutzerkonto an, mit dem die Installation ausgeführt werden soll?

War vorher eine andere Antivirenlösung auf dem Rechner installiert?

Du könntest auch mal dieses Tool ausprobieren: http://go.microsoft.com/?linkid=9804433

noobadmin
22.05.14, 00:02
Hallo,

gibst du bei der Installation des Pakets eventuell ein anderes Benutzerkonto an, mit dem die Installation ausgeführt werden soll?

War vorher eine andere Antivirenlösung auf dem Rechner installiert?

Du könntest auch mal dieses Tool ausprobieren: http://go.microsoft.com/?linkid=9804433

1. der installer will eine UAC-elevation, die ich natürlich gewäre - vllt biegt das den aktiven user auf admin um
2. da lief vor jahren mal ein CA, was lt. admin aber vor der installation sauber deinstalliert wurde (und irgendwie muss die SOA ja auch installiert worden sein)
3. hast du bitte einen informativen link zu dem tool? möchte nicht einfach eine .exe unbesehen auf den kundenserver loslassen ;)

Merlin
22.05.14, 19:10
Hallo,

das Tool habe ich auch im Netz gefunden und es soll den genannten Fehler beheben. Genauere Informationen dazu habe ich bei Microsoft leider nicht gefunden.

noobadmin
22.05.14, 21:26
Hallo,

das Tool habe ich auch im Netz gefunden und es soll den genannten Fehler beheben. Genauere Informationen dazu habe ich bei Microsoft leider nicht gefunden.

es bricht ohnehin mit der fehlermeldung ab, dass es für meine betriebssystemversion nicht geeignet ist.

Merlin
25.05.14, 00:39
Hallo,

hast du regedit.exe als Administrator gestartet, um den Schlüssel unter HKEY_CURRENT_USER zu löschen? Das Tool läuft anscheinend nur unter Desktopbetriebssystemen.

noobadmin
26.05.14, 12:00
Hallo,

hast du regedit.exe als Administrator gestartet, um den Schlüssel unter HKEY_CURRENT_USER zu löschen? Das Tool läuft anscheinend nur unter Desktopbetriebssystemen.

ja, habe ich. die schlüssel sind trotzdem nicht in HKCU zu finden.

muss der unterschlüssel "InProcServer" auf die 32er- oder 64er Version der jeweiligen .dlls verweisen?

Merlin
26.05.14, 17:37
Hallo,

die 64-bit Version.

noobadmin
26.05.14, 18:06
Hallo,

die 64-bit Version.

es geht wieder mit der 64bit-version noch mir der 32er (habe letztere mal probiert, da der schlüssel InProcServer32 heisst

ausserdem funktioniert ja mein testscript.

Merlin
27.05.14, 20:44
Hallo,

ich kann dir da leider nicht wirklich weiterhelfen. Bei vielen anderen Nutzern hat die genannte Methode zur Behebung des Fehlers geführt.

Du könntest mal den Produktsupport fragen: https://support.avast.com/Tickets/Submit/RenderForm

Eventuell hat man dort noch eine Idee.

noobadmin
31.05.14, 11:46
Hallo,

ich kann dir da leider nicht wirklich weiterhelfen. Bei vielen anderen Nutzern hat die genannte Methode zur Behebung des Fehlers geführt.

Du könntest mal den Produktsupport fragen: https://support.avast.com/Tickets/Submit/RenderForm

Eventuell hat man dort noch eine Idee.

habe jetzt ein supportticket aufgemacht.

noch mal vielen dank für deine mühen :)

Merlin
31.05.14, 18:44
Hallo,

es kann immer eine Weile dauern bis es beantwortet wird, daher Geduld mitbringen :)

Merlin
14.06.14, 01:38
Hallo,

da keine Rückmeldung mehr kam, schliesse ich das Thema. Wenn noch Bedarf besteht, bitte eine PN an die Moderatoren.