Sign in
Microsoft.com
 
Microsoft
 
 
 

locked
Edge Server Post Installation Issues RRS feed

 > 

  • Question

  • Question
    Sign in to vote
    0
    Sign in to vote

    Here is our current setup:

     

    Our environment consists of a split dns, externally company.com, internally corp.company.com

    We have an internal cert server which we are using to provide certs for all servers in the testing phase.

     

    Standard Edtion Server         :  Standard.corp.company.com   single nic IP 192.168.1.1

    Archive Server:                        Archive.corp.company.com     single nic IP 192.168.1.2

    Edge Server:                           Edge.corp.company.com        single nic in DMZ 10.0.0.1 

                          External FQDN: im.company.com                                      1.2.3.4

     

    The Edge server is single NIC attached in its own workgroup in our DMZ. 

     

    *This server will eventually encompass both access edge and Web Conferencing server, but for now all we want is External IM.

     

    External DNS records are: 

    (A)  im.company.com 1.2.3.4 Nat'd to im.corp.company.com 10.0.0.2 on edge server

    (srv)  _sip._tls.company.com resolves to im.company.com

    (srv) _sipfederationtls._tls.company.com resolves to im.company.com

    (A) sip.company.com resolved to im.company.com

     

    Internal DNS records: 

    (A records for each server listed above in company.com and corp.company.com zones)

    (A) im.company.com and im.corp.comany.com   10.0.0.2

    (SRV) _sipinternaltls._tcp.company.com  Standard.corp.company.com 192.168.1.1

    (SRV) _sipinternaltls._tcp.corp.company.com  Standard.corp.company.com 192.168.1.1

     

    Here are our issues:

     

    1.)  We have two externally available servers in our DMZ that were working fine until the edge server installation.  Clients were able to use the communicator on those servers to connect using autologin.  Once the edge server was installed, both servers ceased connecting to the standard.corp.company.com.  Communicator is logging errors that it cannot connect to sip.company.com on 5060(?) or 443.  It is also attempting connection to SipInternal.company.com and sipexternal.company.com

    Why is the communicator all of the sudden attempting connections differently than before the edge server was installed?  Is it due to the server living on a subnet other than the standard server?  Any Ideas?

     

    2.) I'm confused about the External IM ability.  We have asked our MS rep for information regarding the licensing of this via our MVLS page, but have not had phone calls and emails returned.  Can anyone provide information on this?

     

    3.)  We're using an internal Cert authority for all cert issuance, including the external facing edge server.  If the remote client running the MSN live messenger or Yahoo Messenger trusts our internal CA as an authority is this going to work for testing?  We will purchase a public cert for production if we decide to go this route.

    Thanks!

     

     

    _

     

     

     

    Monday, November 19, 2007 3:01 PM

All replies

  • Question
    Sign in to vote
    0
    Sign in to vote

    Scott,

     

    1. I've come to the conclusion that you just can't run the Edge Server behind a single NIC regardless of what services you are running.  Take a look at my blog entry as well as my colleague's blog regarding Edge network configurations.

     

    3. See my post in this thread:

    http://forums.microsoft.com/unifiedcommunications/ShowPost.aspx?PostID=2411885&SiteID=57

    Monday, November 19, 2007 3:23 PM
    Moderator
  • Question
    Sign in to vote
    0
    Sign in to vote

    I have added another NIC to the machine and moved all of the external nat'd addresses to the new nic.  However, this does not resolve my internal DMZ attached machine thinking it's external to our network and attempting a connection where it worked before the published Edge server was implemented. 

     

    I used the logging tool, and it looks like we've got a TLS issue, but I'm not finding any documentation on troubleshooting the log tool output.  See below for exerpts from the log file from a connection from the DMZ attached machine:

    ________________________________________________________________________________________________________

    TL_ERROR(TF_CONNECTION) [0]0198.01E4::11/19/2007-17:31:30.187.0000001d (SIPStack,SIPAdminLog::TraceConnectionRecord:1224.idx(157))$$begin_record
    LogType: connection
    Severity: error
    Text: The connection was closed before TLS negotiation completed. Did the remote peer accept our certificate?
    Local-IP: 10.0.0.1:1157
    Peer-IP: 192.168.1.1:5061
    Peer-FQDN: standard.corp.company.com
    Connection-ID: 0x2C00
    Transport: TLS
    $$end_recordText: The connection was closed before TLS negotiation completed. Did the remote peer accept our certificate?________________________________________________________________________________________________________

    TL_ERROR(TF_PROTOCOL) [0]0198.01E4::11/19/2007-17:31:30.187.0000001f (SIPStack,SIPAdminLog::TraceProtocolRecord:1224.idx(112))$$begin_record
    Instance-Id: 0000001D
    Direction: no-direction-info;source="external edge";destination="internal edge"
    Message-Type: request
    Start-Line: REGISTER sip:company.com SIP/2.0
    From: <sip:User.Name@company.com>;tag=cb179051d3;epid=d9835b2ed0
    To: <sip:User.Name@company.com>
    CSeq: 1 REGISTER
    Call-ID: 04ca0359a31a4291832175db02d75df7
    Max-Forwards: 69
    ms-edge-proxy-message-trust: ms-source-type=InternetUser;ms-ep-fqdn=edge.corp.company.com;ms-source-verified-user=verified
    Contact: <sip:10.0.0.253:4356;transport=tls;ms-opaque=643edb1e5e;ms-received-cid=2B00>;methods="INVITE, MESSAGE, INFO, OPTIONS, BYE, CANCEL, NOTIFY, ACK, REFER, BENOTIFY";+sip.instance="<urn:uuid:69F54ABC-D7B5-5F7C-B984-36181BFDE380>"
    Via: SIP/2.0/TLS 10.70.0.253:4356;ms-received-port=4356;ms-received-cid=2B00
    User-Agent: UCCP/2.0.6362.0 OC/2.0.6362.0 (Microsoft Office Communicator)
    Supported: gruu-10, adhoclist, msrtc-event-categories
    Supported: ms-forking
    ms-keep-alive: UAC;hop-hop=yes
    Event: registration
    Content-Length: 0
    Message-Body: –
    $$end_record

    ________________________________________________________________________________________________________

     

    To me, it looks like my certs are not trusted, or are invalid.  The Certs look like this:

     

    Edge.Corp.company.com

    SN edge.corp.company.com

    SAN=sip.company.com

    SAN=sip.corp.company.com

    SAN=EDGE

     

    im.company.com

    SN=edge.company.com

    SAN=sip.company.com

    SAN=sip.corp.company.com

    SAN=EDGE

     

    External Web Farm:

    SN=IMEXT.company.com

    SAN=Standard.corp.company.com

    (This is working fine through ISA Server 2006, Group Expansion and ABS Pages are normal)

     

    Any other thoughts?

    Monday, November 19, 2007 6:00 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    If requests appear to be going to the wrong interface, I would take a serious look at your name resolution configuration and make sure that everything is set correctly.  Can you at least telnet to all the ports for each location in both directions?

    Monday, November 19, 2007 6:18 PM
    Moderator
  • Question
    Sign in to vote
    0
    Sign in to vote

    Jeff!

     

    Can you please clarify this for me ?

     

    The A/V traffic going out the external interface to an internal client 10.X.X.X should be routed through the internal firewall or the external firewall ?

     

    thanks

     

     

    Tuesday, November 20, 2007 8:01 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Diego,

     

    I'm not sure exactly what traffic you are referring to, but ny communcations between hosts on the internal network should be routed through the internal interface of the A/V Edge Server.  In a well-configured network, requests from an internal client looping out the firewall and back into an external interface via a public IP address would be dropped by the firewall.

     

    Wednesday, November 21, 2007 1:01 AM
    Moderator
  • Question
    Sign in to vote
    0
    Sign in to vote

    Thanks for the verification Jeff. That was exactly what I was refering to.

     

    I am having this problem with my OC setup and have somebody from Microsoft on the Case. I will let you know once I find what the problem is.

     

    thanks

     

    Wednesday, November 21, 2007 8:44 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi Scott,

     

    Were you able to figure out your problem with the certs not being accepted? I am having exactly the same problem. In my case we have a local CA issued certs. I am getting the error message:

     

    Text: The connection was closed before TLS negotiation completed. Did the remote peer accept our certificate?

    Any help is appreciated.

     

    San

     

     

     

    Thursday, April 17, 2008 9:41 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Diego and San,

    I was having exactly the same problem (error: "The connection was closed before TLS negotiation completed. Did the remote peer accept our certificate?" and no connectivity issues between the pool and the av auth server).  We determined that the issue was that the pool certificate did not have the "Client Authentication" usage enabled.  We created a new certificate for the pool with that usage (as well as Server Authentication) and the problem is resolved.

    I hope this helps.

    James

    James Denavit MCSE, TS:OCS 2007
    Wednesday, May 27, 2009 11:07 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    Hello.

    James Denavit,
    would you be so kind to explain how     you did created Client Authentication usage enabled certificate for you pool?
    Wednesday, July 29, 2009 7:35 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    Prinzc,

    We were using a Windows 2003 CA, but we did have some trouble with the process and had to use a workaround.  I believe, theoretically, you can copy the web server certificate and rename it, then check the box for Client Authentication within that template.  Due to some rights issues, we were unable to do that, so we just used the Ops Manager certificate template that had been created as I described by someone else and had the properties we required.

    There is also a box to check in the OCS Certificate Wizard when creating the certificate request for enabling the Client Authentication EKU.  If you are using online certificate request, that should work.

    Sorry I dont have a clearer answer for you.
    James Denavit MCSE, TS:OCS 2007
    Wednesday, July 29, 2009 9:15 PM