Note: Forums will be making significant UX changes to address key usability improvements surrounding search, discoverability and navigation. To learn more about these changes please visit the announcement which can be found HERE.
Install Agent on Forefront TMG server that is in a DMZ

Respondida Install Agent on Forefront TMG server that is in a DMZ

  • jueves, 21 de junio de 2012 2:00
     
     

    Hi,

    My normal method for monitoring servers that are in our DMZ is via a certificate install and manual Agent install.

    Works fine for a few dozen servers.

    However, for the first TMG server I have ever seen, the agent will not talk with a mangement server. Gives the old 21016 and 20070 events........"The OpsMgr Connector connected to x.x.x.x, but the connection was closed immediately after authentication occurred.  The most likely cause of this error is that the agent is not authorized to communicate with the server, or the server has not received configuration. "

    I think the problem is on the TMG server.

    Are there special ports that need opening beside 5723

    Any other tips for getting this working??

    Thx very much,

    John Bradshaw


    • Editado bradje jueves, 21 de junio de 2012 23:04
    •  

Todas las respuestas

  • jueves, 21 de junio de 2012 3:32
    Moderador
     
     

    Hi John,

    have you approved this agent in OpsMgr (administration\device management\pending management)? Are you using a certificate on that server or kerberos?


    http://OpsMgr.ru/

  • jueves, 21 de junio de 2012 3:35
     
     

    Hi Alexey,

    It is a certificate on the remote server and the Root cert is on the SCOM Management server.

    Works fine for dozens of boxes

    The server doesn't appear in pending Mgmt

    Thx,

    John

  • jueves, 21 de junio de 2012 4:30
    Moderador
     
     

    The OpsMgr Connector connected to <hidden address>

    it looks like a public address, is this a real opsmgr server's address or you're using some publishing method?  


    http://OpsMgr.ru/


  • jueves, 21 de junio de 2012 6:34
    Moderador
     
     

    Make sure:

    - the dns name of the management server you entered can be resolved and reached (dns name resolving and the route/network card it follows should be alright).

    - in TMG you go into the firewall policy -> system rules. There is an Operations Manager entry there. It has some predefined computer groups there. Just create another computer group in the TMG from that point and add your SCOM servers with name and ip address to that group. The group should be in that rule. Click Apply. This is all you need. i am typing this from memory, but you will find it now. its very easy.

    - If the TMG is in the domain in a domain in the forest where scom is at as well, you do not need a certificate. Otherwise you do. and activate the certificate.


    Bob Cornelissen - BICTT (My Blog about SCOM) - MVP 2012 and Microsoft Community Contributor 2011 Recipient

  • jueves, 21 de junio de 2012 7:16
    Moderador
     
     

    To extend a bit Bob's answer: make sure your agent machine is able to resolve the real management server's name. Management server will send its name as a part of config data and agent will cache that name into a OpsMgrConnector.Config file.


    http://OpsMgr.ru/

  • jueves, 21 de junio de 2012 23:03
     
     

    Update:

    I can do an nslookup no problems. It returns the FQDN of the MS

    The following is in the System log of the TMG server:

    A fatal error occurred when attempting to access the SSL server credential private key. The error code returned from the cryptographic module is 0x8009030d. The internal error state is 10001.

    Some suggest that C:\ProgramData\Microsoft\Crypto\RSA\   needs to have permissions changed. Is that the case perhaps?

    All my other servers with certs, done in exactly the same way are having no problems at all. Just this pesky TMG server.

    Thx,

    JB

  • viernes, 22 de junio de 2012 0:55
    Moderador
     
     

    OPen a certificates mmc on your TMG server, open your certificate and ensure the certificate you're using for a OpsMgr agen does contain a private key.


    http://OpsMgr.ru/

  • viernes, 22 de junio de 2012 0:57
     
     

    Yes it does

    JB

  • viernes, 22 de junio de 2012 2:44
    Moderador
     
     Respondida

    You may want to follow this blogpost: http://www.zerohoursleep.com/2010/11/a-fatal-error-occurred-when-attempting-to-access-the-ssl-server-credential-private-key/

    Are you using a LocalSystem or a custom service account for an OpsMgr Agent?


    http://OpsMgr.ru/


  • viernes, 22 de junio de 2012 2:55
     
     

    Thx Alexey.

    • Yes, we had seen that article, but it didn't fix our problem.
    • Using LocalSystem

    We have raised a case with Microsoft. I'll post back what happens, though at the moment they are scratching their corporate heads too.

    Cheers,

    JB

  • jueves, 28 de junio de 2012 23:21
     
     

    It was a cert issue on a particular MS.

    Thx again,

    JB

  • martes, 10 de julio de 2012 6:44
     
     
    We are having the exact situation here, what was the cert issue exactly?
  • martes, 10 de julio de 2012 6:52
    Moderador
     
     
    Usually that would be the wrong name on the cert (not the fqdn of the server), non trusted CA giving out the certificate (import ca root cert chain), certificate not having private key, momcertimport not run yet. If you restart the system center management service on the management server (agent is the same) you will see in the operations manager event log that a certificate is loaded and such notifications. Check for errors there as well.

    Bob Cornelissen - BICTT (My Blog about SCOM) - MVP 2012 and Microsoft Community Contributor 2011 Recipient

  • martes, 10 de julio de 2012 6:56
    Moderador
     
     

    Hi,

    you may want to use this script to check your certs

    http://en-us.sysadmins.lv/Lists/Posts/Post.aspx?ID=6


    http://OpsMgr.ru/

  • martes, 10 de julio de 2012 11:00
     
     

    Mine turned out to be a bit dumb. I was using the wrong Management Server to point my Agent install at. Out of 3 MS I could only point the manually installed agent at one of them.

    JB