locked
Add-ODBCDsn Remote Procedure Call Error RRS feed

  • Question

  • Hello,

    I am trying to add a system dsn with the Add-ODBCDsn cmdlet. I am using the following script.

    Add-OdbcDsn -Name "CellNoteData" -DriverName "Microsoft Access Driver (*.mdb, *.accdb)" -DsnType "System" -Platform "64-bit" -SetPropertyValue 'Dbq=C:\Users\micha\Desktop\Notes.accdb','Description=Basic Notes'

    The script creates the DSN and I can see it in the ODBC Administrator. So everything seems to work except that I get the following error. I'd like things better if the DSN were created without the error. Can anyone offer a suggestion?

    Add-OdbcDsn : The remote procedure call failed. 
    At E:\imp\xxx\xxx\Admin\System\PowerShell\Make-DSN.ps1:4 char:1
    + Add-OdbcDsn -Name "CellNoteData" -DriverName "Microsoft Access Driver ...
    + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        + CategoryInfo          : NotSpecified: (MSFT_OdbcDsnTask:Root/Microsoft/...SFT_OdbcDsnTask) [Add-OdbcDsn], CimException
        + FullyQualifiedErrorId : HRESULT 0x800706be,Add-OdbcDsn


    Saturday, September 29, 2018 2:38 PM

All replies

  • I can suppress the error message with -ErrorAction Silently continue but that seems like cheating. I'd prefer to understand why the error is being raised and avoid it if possible
    Saturday, September 29, 2018 7:05 PM
  • Finding the source of the RPC problem with only that freaking generic "0x800706be" status code is a crap-shoot.

    I'd start with verifying the necessary RPC services are running. Then verify (use portqry - you should receive a long list of UUIDs) that access to port 135 is operational. Local firewalls and anti-virus scanners many also be interfering with RPC access.

    For what it's worth, I used your code (only modifying the Dbq value) and was able to create a system DSN for a MS-Access 2017 database (once I remembered to 'run as administrator') without receiving any errors or warnings.


    --- Rich Matheisen MCSE&I, Exchange Ex-MVP (16 years)

    Sunday, September 30, 2018 6:53 PM
  • There should be no RPC calls when the DSN parameters are validated.  It is most likely some kind of bad exception handling. The following may be the tie-breaker.  If this works then I will tell you what is the likely cause of the exception.

    $splat = @{
        Name = 'CellNoteData'
        DriverName = 'Microsoft Access Driver (*.mdb, *.accdb)'
        DsnType = 'User'
        Platform = '64-bit'
        SetPropertyValue = @('Dbq=C:\Users\micha\Desktop\Notes.accdb','Description=Basic Notes')
    }
    Add-OdbcDsn @splat

    Notice I changed the type to "user".

    Splatting makes the params easier to manage.


    \_(ツ)_/



    • Edited by jrv Sunday, September 30, 2018 7:10 PM
    Sunday, September 30, 2018 7:08 PM
  • Thanks for the suggestion. I couldn't make it work however.

    PS C:\Users\micha> $splat = @{
        Name = 'CellNoteData'
        DriverName = 'Microsoft Access Driver (*.mdb, *.accdb)'
        DsnType = 'User'
        Platform = '64-bit'
        SetPropertyValue = @('Dbq=C:\Users\micha\Desktop\Notes.accdb','Description=Basic Notes')
    }
    Add-OdbcDsn @splat
    Add-OdbcDsn : The remote procedure call failed. 
    At line:8 char:1
    + Add-OdbcDsn @splat
    + ~~~~~~~~~~~~~~~~~~
        + CategoryInfo          : NotSpecified: (MSFT_OdbcDsnTask:Root/Microsoft/...SFT_OdbcDsnTask) [Add-OdbcDsn], CimException
        + FullyQualifiedErrorId : HRESULT 0x800706be,Add-OdbcDsn

    Sunday, September 30, 2018 9:17 PM
  • That is a more informative error. It seems to indicate that there is an issue with WMI.

    I would contact MS to get a resolution for this.  I have found that the Access ODBC drivers have issues when Office 2016 one-click is installed before the ODBC drivers are installed.


    \_(ツ)_/

    Sunday, September 30, 2018 9:24 PM
  • I appear to have all the RPC services running and running PortQry did indeed return a long list of UUIDs. Still no joy though.
    Sunday, September 30, 2018 9:45 PM
  • Thank you for your help.

    I am not noticing that the error is more informative. It looks like the same 0x800706be error. Can you help me see what I am missing please?

    I am running Office 2016 64 bit. It is a one-click installation which was installed before the Access ODBC drivers as you say.


    Sunday, September 30, 2018 10:19 PM
  • I know of no fix for this.  As  I noted you will have to open an incident with MS Support.


    \_(ツ)_/

    Sunday, September 30, 2018 10:24 PM
  • I don't know if this will help you figure out what's causing the error, but you could try examining the $Error variable's data after the Add-ODBCDsn cmdlet runs. Maybe there's a clue in one the error records.

    If you add "-EA STOP" to the AddODBCDsn and wrap it in a try/catch you'll at least not create a potentially unusable DSN in the registry that you'll have to delete before rerunning the script.


    --- Rich Matheisen MCSE&I, Exchange Ex-MVP (16 years)

    Monday, October 1, 2018 2:23 AM
  • Thank you for your help. 

    The DSN gets added and it works so the error seems to be a false error. I wasn't able to learn anything further by examining the $Error variable's data.

    Currently, I'm cheating and telling PowerShell to continue silently after the error. Not my preferred way to go, but if the DSN is created correctly, which it is, I'm ignoring the error, albeit tentatively.

    I'm currently testing on a Windows 10 box. I will try on a machine running Windows Server 2012 and report back if anything interesting happens.

    I will also report to MS as was suggested.

    Update: I was not able to reproduce the error on a machine running Windows Server 2012. It is only happening on my Windows 10 box. 
    Monday, October 1, 2018 5:18 PM