LAN booster & RPC error 06ba

LAN booster & RPC error 06ba

• kgooding

  But, our VSS DB is running on Windows2000 server and I think RPC extended error information policy is available only on Windows2003 or XP. So let me know, if you still want to send netmon trace without extended info or I'm wrong and this policy is available in W2k too..

  The good news is we’ve got new server, installed 2003 server and everything is now working ok and the troubles are out... :-)
  But if you are still interested in this problem, we can continue in further investigation.
  
  thanks.. ales

  
  

• Steve Whitford

  I have the same settings as orid, ie. Default Authentication Level=Connect & Default impersonation Level=Identify.

  I didn't install whole VS.NET on server, but I have tested on server utility SSSServiceTest . Result is still the same, ie. RPC error 00000005 = RPC_S_ACCESS_DENIED. (and it doesn't matter how I address server - if it is hostname, localhost, IP adress or 127.0.0.1)

  a.

   

  
  

• mrlace2

  > are there any errors in the error log related to service or RPC In general
  no, there are no errors related to RPC or VSS LAN service itself

  > is there any firewall software on the server
  no, no installed firewall or antivirus or TCP/IP protocol filtering

  > is your client and server machine in the same domain
  yes

  > is your RPC service running on the server (you can check this by running net start rpcss on your command line)
  yes, RPC service is running, RPC locator service not

  thank you... a.

  
  

• Uncle Davy

  Finally, with the great help of Alin and Grigori (Microsoft people), I found the problem.

  The code page of the client machine was different than the code page of the VSS server.

  Changing the client codepage (Start/Settings/ControlPanel/ RegionalAndLanguageOptions/Advanced/LanguageForNonUnicodePrograms) of the client to match the server's did the trick.

  This is taken from Alin's email:

  RPC_S_CALL_FAILED (0x6be) - returned by VSS code if the service was successfully accessed, the user was impersonated, but the service failed to open the VSS database. Possible reasons are: the codepage on the client machine is different than the codepage on the server machine, failure to initialize VSS internal structures (SSAPI layer), or failure to login into the database (e.g. invalid database path, access denied to files or share, etc.)

  Ori.

  
  

• Ganesan R

  sorry, it took me a while to repond.

  i suspect it is our rpc security not happy enough with the security settings on the rpc channel coming from the client.

  Could you please run dcomcnfg.exe on your server machine and find 'Distributed COM configuration' properties dialog On the default properties tab it should be specifying 'Default Authentication Level' and 'Default impersonation Level'. Could you reply with the setting that are currently set there

  one other thing to try is to run the client right on the server machine and see whether this would make a difference.

  let me know what you find out.

  thanks,
  -grigori

  
  

• REspawn

  I'm having the same problem, too.

  Only my server is running on Windows 2003.

  Can anyone help

  Ori.

   

   

  
  

• Bob54

  Couple of things to look at:

  • are there any errors in the error log related to service or RPC In general
  • is there any firewall software on the server
  • is your client and server machine in the same domain
  • is your RPC service running on the server (you can check this by running net start rpcss on your command line)

  =grigori

  
  

• David Ballard

  We will probably need to gather RPC extended error information to figure this out.

  First, you will need to enable RPC tracing on the server (i am assuming this error is server specific). Please refer to MSDN article right here to see how to do it: http://msdn.microsoft.com/library/default.asp url=/library/en-us/rpc/rpc/extended_error_information_for_the_server_or_application.asp. For simplicity, i recommend just enabling full error information and propagation of all errors.

  Second, you will need to run the netmon sniff between the client and the server machines (you can run the actual netmon application on the client machine). You should be able to download temporary version of Netmon from here: http://support.microsoft.com/default.aspx scid=FH;EN-US;aspsupvis. Please filter your network packets to keep only those between your client and server. Start the capture.

  Third, run Alin's ssservicetest.exe application, see it fail. Now, stop the netmon trace and make sure that you have MSRPC packets going between the machines. Some of the packets should indicate a failure with MSRPC: Extended error information nodes parsed. Please save the capture and send it to me.

  Hopefully, this will help. Let me know if you have any questions.

  -grigori

  
  

• Zeuss

  Unfortunately, I cannot install the client (VC++2005) on the server machine.
  But checking the DCOM configuration results:
  Default Authentication Level=Connect
  Default impersonation Level=Identify
  
  
  

• BobP1339

  Thanks Ori for the post.

  Both VSS Server-side compoenents (Web Service and LAN booster service) require the codepage of the client machine to match the codepage on the server. In this case the limitation is because the client machine can pass in strings (database path, user names, filenames in the database, etc) containing characters with client's specific codepage, that the server will not be able to understand and use.

  Anyway, it turned out that Ori did not have exactly the same problem as initially reported by Ales. Since the initial report was talking about different error codes, I'll add a short description for them, too.

  RPC_S_SERVER_UNAVAILABLE (0x6ba) - this really means the server is unavailable. I think possible causes are: server down, firewall blocking access, database on DFS share \\server\share and "server" resolves to a different machine than the one actually hosting the database, etc.

  RPC_S_ACCESS_DENIED (0x5, different from RPC_E_ACCESS_DENIED!) - this is returned by VSS code for any failure in the rpc security callback of the SSService.exe. This error code (when returned by VSS code) means that service was actually accessed, but the authentication failed for some reason (e.g. obtaining caller's security token failed, or impersonation failed, or the user was not authenticated by the server, etc). I'm not sure whether Windows can also return RPC_S_ACCESS_DENIED for other reasons. We'll need to instrument the service to get exact information why this error is actually returned (if it's returned by VSS). The reason VSS does not return more detailed error info is that it could potentially cause information disclosure threats.

  Alin

  
  
• LAN booster & RPC error 06ba