Hi!
I use some patch (found somewhere on this forum) to revision 136 with some changes cause I was supposed to use IWbemLocator instead of WbemScripting.SWbemLocator. The later requires some changes in registry and it was out of the question.
So . . everything had worked nice until I tried to connect to IIS server which demands PacketPrivacy (6) level of authentication. I just get 0x80041003.
Other tools configured not to use PacketPrivacy failed with the same error but previous implemenentation using WbemScripting.SWbemLocator succeeds even with no authentication (JISession.useSessionSecurity(false); whereas the patched version fails all the time with no security...).
After digging a bit I found that 2 different constructors of JIComServer are used(one with CLSID and second with Progid) and the patched version uses NtlmConnection instead of basic DefaultConnection and some things work differently. Unfortunately I can't compare them because of my poor knowledge of what's happening under the hood.
Is there a chance that there is sthg wrong with e.g.
JIComServer(JIClsid clsid, String address, JISession session)
compared to
public JIComServer(JIProgId progId, String address, JISession session)
which breaks everyting or maybe it's about NTLMlogin?
To get it straight: everything works fine until i get to the query to this specific Namespace. It's possible that the patch messess sthg but it seemes that problem lies in authentication and it's fully implemented it unpatched library . .
And the second issue:
JICallBuilder.readResult() contains line:
if ( hresult != 0) {
shouldn't it be like:
if (( hresult & 0x80000000) != 0) {
only the first bit signals the error . . I get 0x00000001 very often and it seems all right
Sorry for my chaotic writing.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi!
I use some patch (found somewhere on this forum) to revision 136 with some changes cause I was supposed to use IWbemLocator instead of WbemScripting.SWbemLocator. The later requires some changes in registry and it was out of the question.
So . . everything had worked nice until I tried to connect to IIS server which demands PacketPrivacy (6) level of authentication. I just get 0x80041003.
Other tools configured not to use PacketPrivacy failed with the same error but previous implemenentation using WbemScripting.SWbemLocator succeeds even with no authentication (JISession.useSessionSecurity(false); whereas the patched version fails all the time with no security...).
After digging a bit I found that 2 different constructors of JIComServer are used(one with CLSID and second with Progid) and the patched version uses NtlmConnection instead of basic DefaultConnection and some things work differently. Unfortunately I can't compare them because of my poor knowledge of what's happening under the hood.
Is there a chance that there is sthg wrong with e.g.
JIComServer(JIClsid clsid, String address, JISession session)
compared to
public JIComServer(JIProgId progId, String address, JISession session)
which breaks everyting or maybe it's about NTLMlogin?
To get it straight: everything works fine until i get to the query to this specific Namespace. It's possible that the patch messess sthg but it seemes that problem lies in authentication and it's fully implemented it unpatched library . .
And the second issue:
JICallBuilder.readResult() contains line:
if ( hresult != 0) {
shouldn't it be like:
if (( hresult & 0x80000000) != 0) {
only the first bit signals the error . . I get 0x00000001 very often and it seems all right
Sorry for my chaotic writing.