• 22.07.2025, 19:52
  • S’inscrire
  • Connexion
  • Vous n’êtes pas connecté.

 

Thomas_Haindl

God

Q: DCOM-Fehler gesucht (... und gefunden)

mardi 20 septembre 2005, 23:45

An die Windows-Profis,

Ich habe hier einen Fehler, den ich nicht zuordnen kann:

Source= DCOM, Event= 10016
Durch die Berechtigungseinstellungen (Anwendungsspezifisch) wird der SID (S-1-5-18) für Benutzer NT-AUTORITÄT\SYSTEM keine Startberechtigung (Lokal) für die COM-Serveranwendung mit CLSID {9DA0E10D-86CE-11D1-8699-00C04FB98036} gewährt.


... eine Suche in der Registry ergibt:

HKEY_CLASSES_ROOT\Exoledb.StoreGuidFromUrl
Exchange Store GUID from URL, 9DA0E10D-86CE-11D1-8699-00C04FB98036


Dazu auch MSDN-Library.

Das Problem ist: Ich finde diese Anwendung in den Komponentendiensten (comexp.msc) garnicht - wo könnte ich denn noch suchen?

TIA, Thomas

Chewy

Moderator

Re: Q: DCOM-Fehler gesucht

mardi 20 septembre 2005, 23:57

versuchs mal in den OLE Objekten ...

http://msdn.microsoft.com/library/defaul…hsel_tech_6.asp

ExOLEDB is an unmanaged component. Using the ExOLEDB provider is supported under the COM Interoperability layer of Visual Studio .NET and the .NET Framework. ExOLEDB can only be run on a computer where Exchange has been installed.

edit : clientseitig outlook 2003 ?


edit 2 :

Überprüfen, ob ein Registrierungsschlüssel, der mehr als 259 Zeichen enthält, in der Registrierungsstruktur HKEY_CLASSES_ROOT vorhanden ist
Die Fehlermeldung "503 Service Unavailable" kann angezeigt werden, wenn ein Registrierungsschlüssel, der mehr als 259 Zeichen enthält, in der Registrierungsstruktur HKEY_CLASSES_ROOT vorhanden ist. Während der Initialisierung überprüft der OLE-Datenbank-Anbieter für Exchange (ExOLEDB) die Struktur HKEY_CLASSES_ROOT, um registrierte Dateitypen zu identifizieren. Wenn ein Unterschlüssel einen Standardwert von mehr als 259 Zeichen hat, oder wenn eine DACL (Discretionary Access Control List) vorhanden ist, die auf einem der Unterschlüssel nicht gültig ist, wird ExOLEDB möglicherweise unerwartet beendet.

Wenn ein Unterschlüssel mehr als 259 Zeichen enthält, oder wenn eine DACL vorhanden ist, die nicht gültig ist, werden die folgenden Ereignismeldungen im Ereignisprotokoll der Anwendung protokolliert, wenn Sie die Exchange 2003-Dienste neu starten.

komplett hier : http://support.microsoft.com/?kbid=823159

ohje, meine technet schmeisst mich mit ergebnissen zu

;D ;D

gibts da noch weitere infos zu deinem system oder der umgebung oder seit wann das auftritt ?

also je öfter ich das lese, desto eher siehts nach nem versuch aus, einen ordner zu öffnen, den es eigentlich nicht gibt. ist dir beim einrichten des exchange das systemkonto als diensteverantwortlicher vorgegeben worden ? die registrierung der object-url scheint bei dieser prozedur zwar public und private folder zu unterstützen, kann aber nicht auf server-weite objekte erweitert werden. Daher kommt wohl auch die Vorgabe, daß es ein exchange admin sein muss, der diese objekte registrieren kann und nicht ein systemkonto.

Thomas_Haindl

God

Re: Q: DCOM-Fehler gesucht

mercredi 21 septembre 2005, 15:00

Zuerst mal herzlichen Dank für Deine Mühe.

Citation de "Chewy"

versuchs mal in den OLE Objekten ...
http://msdn.microsoft.com/library/defaul…h_6.asp[/quote]
... mit meinen "Hausmitteln" (msinfo32) nicht überprüfbar - exoledb.dll wird aber als geladenes Modul angezeigt.

Citation

edit : clientseitig outlook 2003 ?

Verschiedene Versionen ab XP (10.x)

Citation

Überprüfen, ob ein Registrierungsschlüssel, der mehr als 259 Zeichen enthält, in der Registrierungsstruktur HKEY_CLASSES_ROOT vorhanden ist
Die Fehlermeldung "503 Service Unavailable" kann angezeigt werden, wenn ein Registrierungsschlüssel, der mehr als 259 Zeichen enthält, in der Registrierungsstruktur HKEY_CLASSES_ROOT vorhanden ist. Während der Initialisierung überprüft der OLE-Datenbank-Anbieter für Exchange (ExOLEDB) die Struktur HKEY_CLASSES_ROOT, um registrierte Dateitypen zu identifizieren. Wenn ein Unterschlüssel einen Standardwert von mehr als 259 Zeichen hat, oder wenn eine DACL (Discretionary Access Control List) vorhanden ist, die auf einem der Unterschlüssel nicht gültig ist, wird ExOLEDB möglicherweise unerwartet beendet.

... scheint in Ordnung.

Citation

komplett hier : http://support.microsoft.com/?kbid=823159

Das isses nich - der OWA funktioniert und hat auch keine Zugriffs-Probleme. Die müsste er IMHO aber haben, wenn ".StoreGuidFromUrl" tatsächlich nicht laufen würde.
Lustigerweise scheint ja alles zu funktionieren. Der EBPA ist auch "glücklich". Mich irritiert nur diese Meldung.

Citation

gibts da noch weitere infos zu deinem system oder der umgebung oder seit wann das auftritt ?

Sorry - hab' ich vergessen
NTDS (2003 only), 2 DCs (2003 EE, jeweils mit GC)
1 Server 2003 STD mit Exchange 2003 (6.5.7226), MS-IMF 6.5.7202, MAPIlab-POP3 2.1.6, F-Secure 6.40
Patch-State: Alles bis auf KB888619 (hab' ich gerade erst genehmigt).

Aufgefallen ist das beim letzten mal Booten.
Der Neustart war auch nur zur "Beruhigung des Systemes", weil hier ein paar Maschinen bei der Übernahme der GPOs etwas herumgezickt haben (ich hab' die SMB-Verschlüsselung entfernt/verboten, weil's mit Linux/Samba und MACs im Netz mehr Ärger als Nutzen bringt).

Citation

also je öfter ich das lese, desto eher siehts nach nem versuch aus, einen ordner zu öffnen, den es eigentlich nicht gibt. ist dir beim einrichten des exchange das systemkonto als diensteverantwortlicher vorgegeben worden ? die registrierung der object-url scheint bei dieser prozedur zwar public und private  folder zu unterstützen, kann aber nicht auf server-weite objekte  erweitert werden. Daher kommt wohl auch die Vorgabe, daß es ein exchange admin sein muss, der diese objekte registrieren kann und nicht ein systemkonto.

Der Domänen-Admin und der Exchange-Admin sind identisch (das ist mein "Privat-Netz". Die Verwaltung der Produktiv-Systeme habe ich outgesourced).
Ich grase gerade alle Schema-Einträge ab - bei der Gelegenheit hab' ich gerade noch ein paar verwaiste OUs gefunden.
Als Nächstes werde ich die öffentlichen Ordner checken. Dein Tip mit dem "Griff ins Leere" sieht sehr vielversprechend aus.

... außerdem habe ich gerade entdeckt, daß das Ding noch im Mixed-Mode (5.5-kompatibel) läuft - das will ich aber nicht ändern solange Benutzer angemeldet sind.
Das wird heute Abend zusammen mit KB888619 erledigt.

TNX, Thomas

P.S.: mit SP2 wird alles besser ;D

Chewy

Moderator

Re: Q: DCOM-Fehler gesucht

mercredi 21 septembre 2005, 15:21

;D - nimm SP2 und du bist dabei

*tüteSP2aufreiss*

*einwerf*

*kau*

Spass beiseite. ich habe mich dem problem heute morgen noch 2 stunden hingegeben und ich finde in der dll-routine den eindeutigen hinweis auf die ordnerstruktur und die registrierung von GLOBALEN events.


dim igetSG
dim regURL
dim WshShell
dim Return

set igetSG=CreateObject("Exoledb.StoreGuidFromUrl.1")
'Get the GUID for the registration process
guid = igetSG.StoreGuidFromUrl("file://./backofficestorage/" + Anystoreitem)
'Anystoreitem is just that. Any store item in the store will get you the
'store url. It might be something like:
' "theserver.example.com/MBX/user1/inbox"

'Build the registration URL (using "theserver.example.com")
regURL = "file://./backofficestorage/ADMIN/theserver.example.com/MBX/SystemMailbox" & guid & "/StoreEvents/GlobalEvents/my_event"

set WshShell=WScript.CreateObject("WScript.Shell")
Return = WshShell.Run ("cscript c:\regevent.vbs add onsyncsave mysink.sink " & regURL & " -m ANY", 4 , TRUE)

WScript.Echo Return



Soweit also die Analyse des Scripts, daß durch die Prozedur angestossen wird. "Aufgestossen" ist mir der Hinweis, dass "serverbezogene" events NICHT unterstützt werden - das würde den Hinweis mit dem User "NT-Authority" unterstützen. Meine Annahme, daß es einen internen User gibt, auf dessen Pfade der Exchange - aus welchen Gründen auch immer - keinen Zugriff hat, verdichtet sich dadurch.

Global events can only be registered in the following folders:

For private mailbox stores:

file://./backofficestorage/ADMIN/%userdnsdomain%/MBX/SystemMailbox{GUID}/Storeevents/GlobalEvents

For public folders:

file://./backofficestorage/ADMIN/%userdnsdomain%/Public Folders/Non_ipm_subtree/StoreEvents{GUID}/GlobalEvents


ICH würde noch was (wohl mehr aus Experimentierfreude) ausprobieren (frag mich nicht wieso *gg*)

Such den Dienst des Exchange und lege unter "Start" einen echten Admin-Account als Berechtigung zum Starten an.

starte neu.

jetzt würde mich die eintragsmeldung interessieren, die DA dabei rauskommt....

Thomas_Haindl

God

Re: Q: DCOM-Fehler gesucht

jeudi 22 septembre 2005, 01:50

Citation de "Chewy"

Spass beiseite. ich habe mich dem problem heute morgen noch 2 stunden hingegeben und ich finde in der dll-routine den eindeutigen hinweis auf die ordnerstruktur und die registrierung von GLOBALEN events.

Uuups
Sooooo viel Zeit für ein Problemchen, das irgendwie garkein echtes Problem ist (Näheres s.u.)


Citation

ICH würde noch was (wohl mehr aus Experimentierfreude) ausprobieren (frag mich nicht wieso *gg*)

Mach' ich - aber erst, wenn ich ein verifiziertes Backup habe.

Ich habe festgestellt, daß bei einigen öffentlichen Ordnern der Eintrag für den Replikationsspeicher fehlte - nachgetragen.

Neu Booten ...
Hochinteressant - der gleiche Fehler, aber eine andere CLSID
Diesmal der F-Secure Hook-Manager (irgendwie kann das Alles nicht sein - die DCOM-Einträge stimmen, und das Ding läuft)

AD-Frühjahrsputz (Orphans und veraltete Trustees löschen, Replikation abwarten).
Anschließend Datei-Sicherheitsbeschreibungen "putzen" (chkdsk /f).

Jetzt ist Ruhe - keine Fehler mehr.
Ob nun die Sicherheitsbeschreibungen oder die "unbekannten Konten" der Auslöser waren, kann ich nicht beantworten.

Die fehlenden Verweise auf den öffentlichen Speicher waren auf jeden Fall (meine) Schlamperei.

nochmal herzlichen Dank für Deine Mühe
mfg, Thomas