Workgroups/DMZ/certificates - pulling teeth! RRS feed

  • Question

  • Hi All

    SCOM 2012R2, most client servers in AD but trying to get those pesky DMZ'ers into SCOM!

    I been through every article I can find, yet I still get event log:



    Event ID: 21010

    The OpsMgr Connector negotiated the use of mutual authentication with x.x.x.x:x, but Active Directory is not available and no certificate is installed. A connection cannot be established. 

    So we know we have a connection through FW etc.

    I've run both these test scripts on both the Management Server and client server in the DMZ with positive results confirming certs I've generated are installed correctly:

    Script1: OMv3CertCheck.ps1 

    Examining cert - Serial number 1asdasdasdasdasdasdasd
    Cert subjectname  OK
    Private key OK
    Expiration OK
    Enhanced Key Usage Extension OK
    Key Usage Extensions OK
    KeySpec OK
    Serial number written to registry OK
    Certification chain
            There is a valid certification chain installed for this cert,
            but the remote machines' certificates could potentially be issued from
            different CAs.  Make sure the proper CA certificates are installed
            for these CAs.

    ***This certificate is properly configured and imported for Ops Manager use.***

    Script 2: OpsMgrCertChecker.ps1

    This script will inspect Local Machine certificate
    store and registry settings. This will take several seconds...
    Script will check certificates to match the following requirements:
        Subject equals computer FQDN
        Certificate is time valid
        Certificate has private key and it supposed for computer certificate
        KeySpec is set to 1"
        Certificate Application Policies (in former EKU) contains both Server and Client Authentication

    The existing certificate with SerialNumber:1xxxxxx match all certificate requirements
    and is properly configured and imported for OpsMgr use.
    Root certificate is valid and is located in Trusted Root Certification Authority
    in LocalComputer store.

    1. Does the workgroup server really need an FQDN and if so, how to change the name and which name to use on the cert, the FQDN or the Computer name?  I've created both certs and bonded one at a time using MomCerIMport but still no luck.

    I've used:

    netdom renamecomputer $env:COMPUTERNAME /newname:$hostname /force
    netdom computername $env:COMPUTERNAME /add:”$hostname.$domainname”
    netdom computername $env:COMPUTERNAME /makeprimary:”$hostname.$domainname”

    which adds the appropriate reg keys BUT DMA agent still fails to connect to SCOM MS.

    I can't believe this is so difficult.

    Please help!

    Big thanks


    Thursday, August 15, 2019 4:12 PM

All replies

  • To answer your question : the workgroup server does not require a FQDN, but the certificate name MUST be the same as the workgroup "full computer name. In the following example, it doesn't have one :

    So if the workgroup server has a fqdn, the certificate must reflect that; and same goes if it doesn't have a fqdn.

    Now, given the error message you get ("... no certificate is installed"), my first guess would be that momcertimport didn't run properly.

    A very common reason for that is that you didn't run it with elevated privileges ("run as administrator"), which doesn't trigger any error message (when you run the GUI version) but still prevent it from working. So can you run it again and confirm that you run it as admin this time?

    • Edited by CyrAz Friday, August 16, 2019 9:09 AM
    Thursday, August 15, 2019 8:19 PM
  • Hi Lea,


    Based as I test in my lab, we don’t need to add FQDN for workgroup.


    For the error message, it shows that no certificate is installed. To check this, please go to MMC-> Add/Remove snap-in->Certificates->My computer, check if the certificate is under Microsoft Monitoring Agent\Certificates.



    Meanwhile, check the following register key to see if HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Agent Management Groups\<SCOM management group>\Parent Health Services\Authentication name and network name are SCOM server FQDN.


    In addition, use PortqueryUI to check if the port 5723 between workgroup and management server is opening.


    Please check the above information and if there’s any update , please let us know.


    Best regards.




    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact

    Friday, August 16, 2019 2:08 AM
  • you may be refer to Bob Cornelissen blog SCOM: DMZ or workgroup machines refusing to connect to SCOM.

    Friday, August 16, 2019 7:04 AM
  • Hi All

    And thank you all for your tips and tricks.  I went through everyone yet again and after another 4 hours of bashing my head against the table finally tracked it down to be a PICNIC issue (well sort of).

    The DMZ (WORKGROUP) server cert import was fine, the MS server 'appeared' all good, UNTIL I spotted this in the Event Log:

    OpsMgr Connector

    Event ID: 20052

    The specified certificate could not be loaded because the Subject name on the certificate does not match the local computer name
     Certificate Subject Name : MS01.<spellingerror>.com
     Computer Name            :

    I think this Event ID was triggered either at MOMcertimport or HealthService Restart

    What's interesting is that the Certificate Subject Name was correct in MMC Certificates and everywhere I could visually see, BUT it was the Subject Alternative Name (SAN) entry in the cert inf file which was incorrect and as such subsequently provided an incorrect SAN on the cert, I'm not even sure I need a SAN entry either!

    Signature = $Windows NT$
    [Extensions] = "{text}"
    _continue_ = ""
    _continue_ = "dns=MS01&"

    Oh the joys!

    One other thing to note is to ensure the first SAN entry is the full FQDN followed by the computer name.  Again, note sure why I added these to the inf file in the first place?!

    Thanks to all 

    • Edited by LeaUK Tuesday, August 20, 2019 12:15 PM
    Monday, August 19, 2019 4:08 PM
  • indeed, it's not required to have SANs in SCOm certificates ;)

    Monday, August 19, 2019 6:10 PM
  • Hi.

    In General, the Subject Alternative Name field lets you specify additional host names (sites, IP addresses, common names, etc.) to be protected by a single SSL Certificate, such as a Multi-Domain (SAN) or Extend Validation Multi-Domain Certificate.

    In our environment, if it is with no need, we can remove it and renew the certificate.

    Hope the information can help.

    Best regards.


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact

    Tuesday, August 20, 2019 4:56 AM
  • We're getting off topic but nowadays, SAN is required even for single domain web certificates; otherwise they will get rejected by browser :
    Tuesday, August 20, 2019 6:23 AM
  • No idea why I added a SAN, thinking perhaps to include all the MS servers into one cert perhaps?

    Useful link, cheers:

    • Edited by LeaUK Tuesday, August 20, 2019 12:21 PM
    Tuesday, August 20, 2019 12:16 PM