I had to change ip addresses on my external network card and after that my clients cannot login externally and federation do not work either. We can see traffic arriving to edge server but then nothing on the other side no inbound traffic to frontend pool.

I can chat to external contact but they cannot answer to me.  

I cannot say if federation worked before but external clients worked before.

What we checked I followed this list http://blogs.technet.com/b/nexthop/archive/2011/12/07/useful-tips-for-testing-your-lync-edge-server.aspx

and everything checked out okay DNS entrys, SRV records and ports, I tried RUCT and that to cannot find anything wrong cert okay to. Microsoft connectivity analyzer is broken at the moment but returns an error in last test something about login error(sorry cant remember exactly).

All my findings pointing to edge server do not forward traffic inbound outbund things seems okay. What can I do? Is my only option to scrap this one and start over? 

Best regards

Conny

You will need to update the IP address for the Edge server in your Lync Topology using Topology Builder.

Make the change and the publish it - wait for it to replicate (run Get-CsManagementStoreReplicationStatus and make sure everything is set to True.)

Restart the Lync services on the Edge and you should be good.

As far as I recall you don't have to re-run the Deployment Wizard on the Edge if you change the IP, but if what I described above fails, try that too - it won't

No, don't scrap it.  There are a lot of basic things to check:

• DNS access to internal.  Can the Edge server resolve the internal Front End pool name?  Sometimes this isn't the case when using external DNS servers on the Edge.
• Routing.  Can the edge server route to the internal Front End pool still?  Did a default gateway addition change your routing layout?  Did you have persistent routes to get to the inside network prior?  Can you telnet to port 5061 from the Edge to a Front End server?
• Topology.  Does the Edge server point to that Front End in the topology for a next hop?  If so, is it's configuration current?  Run get-csmanagementstorereplicationstatus to see if it's in sync.  If not, you may need to "export-csconfiguration -filename export.zip" from a front end and run "import-csconfiguration -filename export.zip -localstore" from the edge (and of course fix whatever if preventing configuration replication over port 4443).
• Certificates.  Does the Edge still trust the certificates of the Front End, I presume so in this case as you're getting outbound traffic.

What's going to be your real friend here is the Lync logger from the debugging tools download.  Run the logger and watch SIPStack, watch for an inbound failure and see what sort of issues it shows you in the messages section.

Hi Conny,

I tested in lab, and there are my steps for your reference.

1. Change the IP in topology.

2. Publish topology.

3. Run Export-Csconfiguration to export the Lync server topology, policies, and configuration settings to a file.

4. Copy this file to Edge Server.

5. Run Deployment Wizard on Edge server.

6. Re-run step 1 & step 2 .

After doing the above steps, everything went well.

Hope it can be helpful.

Best regards,

Eric

Georg

Yes i did those things and I have restarted several times, and yes replication is good. And I did try Import-CsConfiguration for good measure but no go.

Anthony

-DNS. Edge server do not have internal DNS only external it relay in host file, but yes can access front end pool with ping and telnet to 5061. Is that enough I have seen different examples for DNS on edge but think the official solution is to use hostfile for internal servers pool, cert and DC.    

-Routing. We never touched internal network card so no no change to routing layout, and yes I can telnet to internal pool on 5061.

-Topology. Yes edge point too correct next hop pool and yes it is current has always been but as I mentioned to Georg I tried exporting and importing too just in case.

-Certificate Yes thats still okay.

So I log the crap out of it and se if can find anything related to this.

/Conny

 

Well tried to capture external login from client and this is what I get on edge server nothing at all on frontend pool as these lines hints

Text: Routing error occurred; check Result-Code field for more information

Result-Code: 0xc3e93c7e SIPPROXY_E_ROUTING_MSG_SEND_EXPIRED

Below every error I get when I try to login with external client, for me it looks like edge serer somehow dont know hove to reach frontend pool server.

/Conny

 

 

 

 

TL_ERROR(TF_PROTOCOL) [0]06EC.0E48::01/30/2015-06:17:43.806.0005e005 (SIPStack,SIPAdminLog::TraceProtocolRecord:SIPAdminLog.cpp(115))$$begin_record

Trace-Correlation-Id: 3414605250

Instance-Id: 00006411

Direction: no-direction-info;source="external edge";destination="internal edge"

Peer: saas095.personal.sundsvall.se:5061

Message-Type: request

Start-Line: REGISTER sip:sundsvall.se SIP/2.0

From: <sip:cxxxx@xxxx.se>;tag=41286587f0;epid=1c1690c41b

To: <sip:cxxxx@xxxx.se>

CSeq: 1 REGISTER

Call-ID: 5dc1f12c5c98404ea6d02a4d4bb7e091

Max-Forwards: 69

Contact: <sip:192.121.161.20:51311;transport=tls;ms-opaque=2e318a0b92;ms-received-cid=18ED00>;methods="INVITE, MESSAGE, INFO, OPTIONS, BYE, CANCEL, NOTIFY, ACK, REFER, BENOTIFY";+sip.instance="<urn:uuid:F3EB1A54-2D60-53D0-96B2-5F8F35BF1378>"

Via: SIP/2.0/TLS 10.16.151.13:51311;received=192.121.161.20;ms-received-port=51311;ms-received-cid=18ED00

User-Agent: UCCAPI/4.0.7577.4398 OC/4.0.7577.4398 (Microsoft Lync 2010)

Supported: gruu-10, adhoclist, msrtc-event-categories

Supported: ms-forking

Supported: ms-cluster-failover

Supported: ms-userservices-state-notification

ms-keep-alive: UAC;hop-hop=yes

Event: registration

Content-Length: 0

ms-edge-proxy-message-trust: ms-source-type=InternetUser;ms-ep-fqdn=sdas024.personal.sundsvall.se;ms-source-verified-user=verified

Message-Body:

$$end_record

 

 

TL_WARN(TF_DIAG) [0]06EC.0E48::01/30/2015-06:17:43.806.0005e006 (SIPStack,SIPAdminLog::TraceDiagRecord:SIPAdminLog.cpp(145))$$begin_record

LogType: diagnostic

Severity: warning

Text: Routing error occurred; check Result-Code field for more information

Result-Code: 0xc3e93c7e SIPPROXY_E_ROUTING_MSG_SEND_EXPIRED

SIP-Start-Line: REGISTER sip:sundsvall.se SIP/2.0

SIP-Call-ID: 5dc1f12c5c98404ea6d02a4d4bb7e091

SIP-CSeq: 1 REGISTER

Peer: saas095.personal.sundsvall.se:5061

$$end_record

 

 

TL_WARN(TF_PROTOCOL) [0]06EC.0E48::01/30/2015-06:17:43.806.0005e007 (SIPStack,SIPAdminLog::TraceProtocolRecord:SIPAdminLog.cpp(120))$$begin_record

Trace-Correlation-Id: 3414605250

Instance-Id: 00006411

Direction: no-direction-info;source="external edge";destination="internal edge"

Peer: saas095.personal.sundsvall.se:5061

Message-Type: request

Start-Line: REGISTER sip:sundsvall.se SIP/2.0

From: <sip:cxxxx@xxxx.se>;tag=41286587f0;epid=1c1690c41b

To: <sip:cxxxx@xxxx.se>

CSeq: 1 REGISTER

Call-ID: 5dc1f12c5c98404ea6d02a4d4bb7e091

Max-Forwards: 69

Contact: <sip:192.121.161.20:51311;transport=tls;ms-opaque=2e318a0b92;ms-received-cid=18ED00>;methods="INVITE, MESSAGE, INFO, OPTIONS, BYE, CANCEL, NOTIFY, ACK, REFER, BENOTIFY";+sip.instance="<urn:uuid:F3EB1A54-2D60-53D0-96B2-5F8F35BF1378>"

Via: SIP/2.0/TLS 10.16.151.13:51311;received=192.121.161.20;ms-received-port=51311;ms-received-cid=18ED00

User-Agent: UCCAPI/4.0.7577.4398 OC/4.0.7577.4398 (Microsoft Lync 2010)

Supported: gruu-10, adhoclist, msrtc-event-categories

Supported: ms-forking

Supported: ms-cluster-failover

Supported: ms-userservices-state-notification

ms-keep-alive: UAC;hop-hop=yes

Event: registration

Content-Length: 0

ms-edge-proxy-message-trust: ms-source-type=InternetUser;ms-ep-fqdn=sdas024.personal.sundsvall.se;ms-source-verified-user=verified

Message-Body:

$$end_record

 

TL_WARN(TF_DIAG) [0]06EC.0E48::01/30/2015-06:17:43.807.0005e009 (SIPStack,SIPAdminLog::TraceDiagRecord:SIPAdminLog.cpp(145))$$begin_record

LogType: diagnostic

Severity: warning

Text: Message or one of its headers caused SIP transaction processing error

Result-Code: 0xc3e93c09 PE_E_TRANSACTION_DOES_NOT_EXIST

SIP-Start-Line: SIP/2.0 504 Server time-out

SIP-Call-ID: 5dc1f12c5c98404ea6d02a4d4bb7e091

SIP-CSeq: 1 REGISTER

Data: Transaction ID: 0x2d99a31323ff, Branch ID: 0x0, Seconds since last hour: 0x427, Current tick count a3acfb20

$$end_record

 

 

TL_WARN(TF_PROTOCOL) [0]06EC.0E48::01/30/2015-06:17:43.807.0005e00a (SIPStack,SIPAdminLog::TraceProtocolRecord:SIPAdminLog.cpp(120))$$begin_record

Trace-Correlation-Id: 3414605250

Instance-Id: 0000641A

Direction: no-direction-info;source="local";destination="external edge"

Message-Type: response

Start-Line: SIP/2.0 504 Server time-out

From: <sip:cxxxx@xxxx.se>;tag=41286587f0;epid=1c1690c41b

To: <sip:cxxxx@xxxx.se>;tag=1499D6D2C8BED2FB56C0ED35FE0D256E

CSeq: 1 REGISTER

Call-ID: 5dc1f12c5c98404ea6d02a4d4bb7e091

Via: SIP/2.0/TLS 10.16.151.13:51311;received=192.121.161.20;ms-received-port=51311;ms-received-cid=18ED00

Message-Body:

$$end_record

 

TL_WARN(TF_DIAG) [0]06EC.0E48::01/30/2015-06:17:43.807.0005e00f (SIPStack,SIPAdminLog::TraceDiagRecord:SIPAdminLog.cpp(145))$$begin_record

LogType: diagnostic

Severity: warning

Text: Unable to route the response

Result-Code: 0xc3e93c09 PE_E_TRANSACTION_DOES_NOT_EXIST

SIP-Start-Line: SIP/2.0 504 Server time-out

SIP-Call-ID: 5dc1f12c5c98404ea6d02a4d4bb7e091

SIP-CSeq: 1 REGISTER

$$end_record

 

TL_WARN(TF_PROTOCOL) [0]06EC.0E48::01/30/2015-06:17:43.807.0005e010 (SIPStack,SIPAdminLog::TraceProtocolRecord:SIPAdminLog.cpp(120))$$begin_record

Trace-Correlation-Id: 3414605250

Instance-Id: 0000641A

Direction: no-direction-info;source="local";destination="external edge"

Message-Type: response

Start-Line: SIP/2.0 504 Server time-out

From: <sip:cxxxx@xxxx.se>;tag=41286587f0;epid=1c1690c41b

To: <sip:connyh@sundsvall.se>;tag=1499D6D2C8BED2FB56C0ED35FE0D256E

CSeq: 1 REGISTER

Call-ID: 5dc1f12c5c98404ea6d02a4d4bb7e091

Via: SIP/2.0/TLS 10.16.151.13:51311;received=192.121.161.20;ms-received-port=51311;ms-received-cid=18ED00

Message-Body:

$$end_record

Well yesterday we fixed it, as in so many cases it was the firewall. So this had nothing to do with change of IP addresses but change in firewall that happened month earlier and went unnoticed.

If you have Checkpoint firewall be aware that if you add a roule for TCP port 5061 you get something like this TCP:sip_tls_authentication and that dont work have to add this TCP:sip_tls_not_inspected. So now federation and external client logon work for me. 

• Marked as answer by Connyh_svl 4 hours 47 minutes ago

Well yesterday we fixed it, as in so many cases it was the firewall. So this had nothing to do with change of IP addresses but change in firewall that happened month earlier and went unnoticed.

If you have Checkpoint firewall be aware that if you add a roule for TCP port 5061 you get something like this TCP:sip_tls_authentication and that dont work have to add this TCP:sip_tls_not_inspected. So now federation and external client logon work for me. 

• Marked as answer by Connyh_svl Thursday, February 12, 2015 7:00 AM

Well yesterday we fixed it, as in so many cases it was the firewall. So this had nothing to do with change of IP addresses but change in firewall that happened month earlier and went unnoticed.

If you have Checkpoint firewall be aware that if you add a roule for TCP port 5061 you get something like this TCP:sip_tls_authentication and that dont work have to add this TCP:sip_tls_not_inspected. So now federation and external client logon work for me. 

• Marked as answer by Connyh_svl Thursday, February 12, 2015 7:00 AM

Well yesterday we fixed it, as in so many cases it was the firewall. So this had nothing to do with change of IP addresses but change in firewall that happened month earlier and went unnoticed.

If you have Checkpoint firewall be aware that if you add a roule for TCP port 5061 you get something like this TCP:sip_tls_authentication and that dont work have to add this TCP:sip_tls_not_inspected. So now federation and external client logon work for me. 

• Marked as answer by Connyh_svl Thursday, February 12, 2015 7:00 AM