Alex Pound

Hey Phil - Could be permissions - I was using WBEMTEST to isolate problems with permissions/DCOM from our code/jinterop, see Troubleshooting WMI. Good luck, aep

Hey Guys - Sorry, the SF notifications were buried in my spam folder, just ran across them this weekend. @Hrvoje - that's the right idea - I moved the entire section from init() if (session.isSessionSecurityEnabled()) { super.getProperties().setProperty("rpc.ntlm.seal", "true"); super.getProperties().setProperty("rpc.ntlm.sign", "true"); super.getProperties().setProperty("rpc.ntlm.keyExchange", "true"); super.getProperties().setProperty("rpc.ntlm.keyLength", "128"); super.getProperties().setProperty("rpc.ntlm.ntlm2",...

Hi Guys - We had a similar problem with KB5004442 in some legacy code. Looks like it's a bug in JIComServer - the session security flags need to be set before the call to JIComServer.init(). I was only interested in a quick patch, so I copied the seal and sign flags set by session.isSessionSecurityEnabled() to JIComServer.initialize(...) just before the call. The flags are actually used in NTLMConnection.outgoingRebind(). Seemed to fix the problem, bought us some time so we can remove the COM access....

Hi Guys - We had a similar problem with KB5004442 in some legacy code. Looks like it's a bug in JIComServer - the session security flags need to be set before the call to JIComServer.init(). I was only interested in a quick patch, so I copied the seal and sign flags set by session.isSessionSecurityEnabled() to JIComServer.initialize(...) just before the call. Seemed to fix the problem, bought us some time so we can remove the COM access. Hope that helps, aep