none
VMWare Server Not Connected - Data Protection Manager Error ID: 33623 RRS feed

  • Question

  • I have been trying to set up SCPDM to provide VMWare protection.  The certificate is the one issued by VMWare for setting up secure communication.  That makes the Issuer VMware.  Otherwise, we use a Microsoft Certificate Authority for our domain based machine certificates.  I have exported the certificate and imported it into the Trusted Root Certificate Authority.  Opening up a browser and going to our vCenter location shows a secure connection.

    Using the FQDN, the VMWare version reports back correctly.  Using an IP address (for testing purposes), no VMWare version is reported.  I have set up a VMWare local account to do backups, and have also tried using a domain account with VMWare Administrator credentials - no change.

            

    VMware version: 6.0.0
    Error: Data Protection Manager Error ID: 33623
    Unable to communicate with VMware Server vcenter6.sunrise.lan.
    Detailed error code: Internal error code: 0x80990EF2
    Recommended action:
                Please ensure that the specified VMware server is up and running and reachable from DPM Server.
                Also, ensure that right credentials are specified for interacting with specified VMware Server.

    Has anyone else figured out how to correct for this?

    Thanks.


    • Edited by Jim_Work Wednesday, October 31, 2018 5:11 PM
    Wednesday, October 31, 2018 4:58 PM

All replies

  • Hi,

    You will receive the 0x80990EF2 or 0x8099DEF2 errors when trying to add the ESX server to DPM, if the credentials are incorrect, of if there is no valid trusted certificate, or if the ESX server has the lockdown option enabled because it’s being managed by vCenter.

    For DPM to be able to communicate securely with a VMware server, a certificate is used. 
    DPM connects to VMware via the HTTPS protocol, so the certificate that is installed on VCenter or ESX host must be trusted by the DPM server.

    Each ESX server will have its own certificate, however if the vCenter server is added as a protected server, you do not have to deal with the certificates of all the other ESX servers that are managed by that vCenter server.

    You can export the vCenter certificate from the browser (View certificate > Details > Copy to file) and add it to the Trusted Root Certification Authorities of the DPM server.


    Best regards,
    Leon


    Blog: https://thesystemcenterblog.com LinkedIn:

    • Proposed as answer by Leon Laude Tuesday, June 25, 2019 6:26 AM
    Wednesday, October 31, 2018 5:10 PM
  • I've done the export from a browser and imported it into the Root Certificate authority.  That made no impact on the situation.  Is it possible that the certificate needed is the one being issued to the machine from our domain based certificate authority instead of the one being supplied via VMWare that is being used for communicating securely to the web interface?
    Wednesday, October 31, 2018 5:14 PM
  • You mentioned that "Opening up a browser and going to our vCenter location shows a secure connection." if this is from the DPM server then it looks like the certificate is OK.

    I would suggest you to check the DPMRACurr.errlog for any more clues.
    You can find it here: C:\Program Files\Microsoft System Center\DPM\DPM\Temp


    Blog: https://thesystemcenterblog.com LinkedIn:

    Wednesday, October 31, 2018 5:19 PM

  • In my DPMRACurr.errlog  i saw 

    Exception:System.Net.WebException:The underlying connection was closed: An unexpected error occurred on a send. ---> System.IO.IOException: Authentication failed because the remote party has closed the transport stream.

    Aha! what rhymes with transport stream? 

    TLS 

    https://support.microsoft.com/en-gb/help/4022913/how-to-resolve-azure-backup-agent-issues-when-disabling-tls-1-0-for-pc

    Wednesday, October 31, 2018 6:59 PM
  • Are you the same user from before? Just checking because of another user account :)

    Btw which version & build of DPM are you running?


    Blog: https://thesystemcenterblog.com LinkedIn:

    Wednesday, October 31, 2018 7:12 PM
  • Just checking to see if you have any update on this?

    Blog: https://thesystemcenterblog.com LinkedIn:

    Sunday, November 4, 2018 5:14 PM
  • Did you ever get this solved?

    Blog: https://thesystemcenterblog.com LinkedIn:

    Friday, August 9, 2019 6:31 AM