locked
EdgeSync Errors

    Question

  • Hello all.

    I have a test Exchange 2007 deployment server running in my lab.  The main server (shake-virtual03 with Mailbox, Client Access, Hub Transport, and UM roles) is able to send and receive smtp mail directly but I am running into a problem with the second server (shake-virtual02 running the Edge Transport role) and EdgeSync.  I have followed the instructions to subscribe the Edge Transport Server but when I run EdgeSync manually , I get the following errors in the event viewer:

    Event ID 10104:  Failed to match cert in contacting shake-virtual02.thundercleese.com, connection aborted

    Followed by

    Event ID 1024:  Edge locking server shake-virtual02.thundercleese.com generated exception System.DirectoryServices.Protocols.LdapException: The LDAP server is unavailable.
    at System.DirectoryServices.Protocols.LdapConnection.Connect()
    at System.DirectoryServices.Protocols.LdapConnection.BindHelper(NetworkCredential newCredential, Boolean needSetCredential)
    at Microsoft.Exchange.EdgeSync.Connection..ctor(LdapDirectoryIdentifier directory, NetworkCredential credentials, Boolean toEdge)
    at Microsoft.Exchange.EdgeSync.ConnectionFactory.Connect(String preferredServer, Boolean toEdge)
    at Microsoft.Exchange.EdgeSync.Topology.TryLeaseEdge(TopologyServer server, ConnectionFactory edgeConnectionFactory, Boolean syncNow)

    The two servers are both running Server 2003 R2 x64 in a VMWare Virtual Server Session on the same host machine with bridged network adapters so they each have their own IP address.  The main exhange server is part of a domain while the edge server is stand-alone (as recommended).  The ADC and DNS is the host machine.  Both Exchange Servers are registered in DNS and there is no firewall between the two virtual machines.

    Any Ideas?

     

    --Jeff

    Wednesday, July 26, 2006 6:48 PM

Answers

  • The problem right now is we do not refresh the certificate used by ADAM when issue a new subscription, so if you have created a new cert, we keep presenting the old one.  Ok, so here's what you need to do to get ADAM to present the new one:

    1.     On the Hub, Remove the Subscription

    2.     On the Edge, Remove the cert used by ADAM to establish secure connections. You can do this by following the following steps:

    a.       Open up an empty mmc console (Run -> mmc)

    b.      Select File -> Add / Remove Snap-in

    c.       Hit Add

    d.      Select “Certificates” from the List of Snap-Ins available, and hit Add.

    e.      Select “Service Account” on the “Certificates Snap-In” page, click next.

    f.        Select  “Local Computer” on the “Select Computer” page, click next.

    g.       Select “Microsoft Exchange ADAM” from the list of services, click Finish.

    h.      Close the “Add Snap-in” dialog.

    i.         Navigate to “Certifcates – Service” -> “ADAM_MSExchange\Personal” -> Certificates

    j.        You should see a single certificate here. Remove it.

    3.     On the Edge, Unsubscribe, then create a new subscription file (you should see a new certificate show up at this point on the ADAM cert container from the step above) by calling new-edgesubscription

    4.     Re-start the “Microsoft Exchange ADAM” service.

    5.     Bring the file in and re-subscribe (new-edgesubscription on the hub.)

    That should do the trick. let me know if it works.

    Thursday, August 17, 2006 9:27 PM

All replies

  • Any luck with this Jeff? seeing the same thing here.
    Thursday, July 27, 2006 6:06 PM
  • No luck.  After working with it for quite some time, I have given up on installing an Edge Transport server pending some sort of comment from Microsoft.

    My guess is that the EdgeSync is relying on a cert created during the registration process (and contained in the xml file generated by the Edge Transport server) but that the cert is somehow corrupted, the key generation process is flawed, or something about my environment (not complex excepting the Virtual Server environment) is making the process fail.

    I will run with my smtp exposed on the main server until there is resolution on this.  It's a great feature if it works...

    --Jeff

    Thursday, July 27, 2006 6:41 PM
  • As i understood it, the edge transport was mandatory for getting external SMTP in... you've got it running without it?
    Thursday, July 27, 2006 6:51 PM
  • The Edge Transport server allows for a much better (security-wise) experience with exterrnal SMTP but is not required.  You can use a standard server install to receive external SMTP if you open port 25 on that machine to the outside world.

    The Edge Transport server runs on a non-domain machine and is designed to sit in a DMZ by itself so you don't have to have a domain member potentially available to hacking.  It's an MS way to have a dedicated smart host as your primary SMTP portal.

    There are a few threads on this forum regarding the SMTP receive connector being able to receive SMTP mail from the outside world.  As default-installed, it will reject external mail.  You can either throw a command-line to enable anonymous access or you can do what I did and delete the default SMTP connector and create a new one.  Either option will allow incoming SMTP mail.  See the following links for info:

    http://forums.microsoft.com/TechNet/ShowPost.aspx?PostID=585205&SiteID=17
    http://forums.microsoft.com/TechNet/ShowPost.aspx?PostID=579105&SiteID=17

    --Jeff

    Thursday, July 27, 2006 7:27 PM
  • Hello Jeff,

    Have you tested Mail flow troubleshooter on Hub Transport Rule?

    You should create a new subscription file and try again.. it's not a best way but it's possible..

    Another question.. do you get access on tcp ports 50389 and 50636 from hub transport to edge transport server?

    Probably you don't understand portuguese, but I've made a portuguese tutorial about your issue, you may see the pictures and compare with your environment..

    http://www.andersonpatricio.org/Tutoriais/Tutoriais.asp?tut=817

    Best Regards,

    Thursday, July 27, 2006 7:34 PM
  • I've asked the Test owner for EdgeSync to respond here.  Hopefully we can resolve this for you shortly.
    Thursday, July 27, 2006 9:36 PM
  • I've seen some interesting behavior with VMWare where guests have problems resolving certain aliases on the host, be it FQDNs for the host itself or its domain records.

    I'd go into your guest and try pinging the following names from sheke-virtual03, and attempting to resolve any that don't work:

    1) <hostMachine>

    2) thundercleese

    3) <hostMachine>.thundercleese.com

    4) thundercleese.com

    Friday, July 28, 2006 8:58 AM
  • Hello,

     

     I have the same error here during the sync.

     I have two real servers with 2003 Srv SP1 (no vmware) on the same LAN with no firewall.

     On the main server, all seems to work.  I could send and receive emails.

     After that, i configure a second server, standalone, with Edge Server Role. I encounter no errors during installation.

     I follow the help to export the xml file. I import it on the main server.

     But i have ID Error 10104 Synhcro :

    "Correspondance introuvable pour le certificat lors du contact de sc13srv-edge.SCRIBATEST.LOCAL, abandon de la connexion

    Pour plus d'informations, consultez le centre Aide et support à l'adresse http://go.microsoft.com/fwlink/events.asp." In french :)

     Followed by ID ERROR 1024 Topology

    Le verrouillage du serveur Edge sc13srv-edge.SCRIBATEST.LOCAL a généré une exception System.DirectoryServices.Protocols.LdapException: The LDAP server is unavailable.

    at System.DirectoryServices.Protocols.LdapConnection.Connect()

    at System.DirectoryServices.Protocols.LdapConnection.BindHelper(NetworkCredential newCredential, Boolean needSetCredential)

    at System.DirectoryServices.Protocols.LdapConnection.Bind(NetworkCredential newCredential)

    at Microsoft.Exchange.EdgeSync.Connection..ctor(LdapDirectoryIdentifier directory, NetworkCredential credentials, Boolean toEdge)

    at Microsoft.Exchange.EdgeSync.ConnectionFactory.Connect(String preferredServer, Boolean toEdge)

    at Microsoft.Exchange.EdgeSync.Topology.TryLeaseEdge(TopologyServer server, ConnectionFactory edgeConnectionFactory, Boolean syncNow)

    Pour plus d'informations, consultez le centre Aide et support à l'adresse "

    Any ideas ?

     

    -- NB

    Wednesday, August 02, 2006 1:15 PM
  • What Greg says is something important to check - if the Hub Transport server says it cannot connect to the LDAP server <foo.bar.com>, make sure that you have DNS set up such that the Hub Transport server really can resolve the name that the Edge Transport server thinks it is. 

    Also, when you try it again, make sure you do a get-edgesubscription | remove-edgesubscription on both the Hub and Edge servers before you try the procedure again. 

    We are enhancing the event logs for this situation in later builds to help diagnose these types of issues.  We will get some other people on this forum to see if we can figure out what is happening for you guys.

    Saturday, August 05, 2006 7:59 PM
  • Hey Jeff,

    I'm the tester for EdgeSync, Greg and James mentioned the problem you are having. You are correct in your interpretation, this is a certificate problem. When create a new subscription, the subscription file contains the public key for the edge certificate (which is actually created during installation), and this certificate is used to ensure during synchronization that we are talking to the correct edge.

    Did you happen to run any of the *-exchangecertificate tasks? If you created a new one (or removed the existing one) then it would not match the one on the hub. It is possible there might be another reason why we are failing to validate the cert, but this is definitely a problem with it.  

    Saturday, August 05, 2006 8:45 PM
  • Was anybody able to find a resolution for this?  I have been running into the problem for weeks and have not been able to fix the issue.  I have the same setup that Jeff mentions.  I can import the Edge subscription file just fine but trying to do the manual start-edgesynchonization fails with the LDAP unavailable error in the command shell and the eventvwr logs that have been mentioned in previous posts.

     

    Any possible solutions would be greatly appreciated.

     

    ~Jesse

    Tuesday, August 15, 2006 8:36 PM
  • I second this... please let us know whether or not a suggestion worked, we're listening... there's little "was this post helpful?" voting buttons that can help out other folks that have hit a same or similar issue.
    Wednesday, August 16, 2006 5:51 AM
  • Interesting enough I got my edge sync service to work.  If you look at the xml certificate generated the server name is in all caps. But when I ran the best practice analyzer it told me I had a severname mismatch type. When I checked my computer name it was in lower case. All I did to fix the problem was first rename my server from its origanal lower case (server), to (serverx), then back to (SERVER) all caps. Then I removed the original edge subscription from my internal server. I then created a new subscription which also had the upper case (SERVER) name embbeded. I checked my event log and success edge sync if function properly.

    Hope this helps,

    John

    Thursday, August 17, 2006 2:02 PM
  • Sorry for the delay.  I have been swamped with many other projects and am just getting back to this now.

    I spent some time this morning trying the suggestions in this thread.

    I can ping both the machine name (resolves to the fqdn) and the fqdn and both pings resolve to the right IP address.  I have renamed the edge server to all caps and retried the edge subscription to no avail.  I ran the get-edgesynch | remove-edgesync command and then reran the subscription with the same result.

    As the edge server is getting the domain information with ADAM, am I supposed to be doing something to initialize the ADAM instance?  I remember ADAM mentioned in passing in the documentation but I did not come across any information on how to configure it or if I need to do something else to make it work.  Is it a part of the edge subscription process or am I supposed to set something up prior to what I am doing now?

    I promise to get back with results faster now that I have some more time to work on it.

    --Jeff

    Thursday, August 17, 2006 6:26 PM
  • Jeff,

    Can you run Get-ExchangeCertificate and tell me how many certificates you get back ( do this both on the edge and on the hub). I suspect you will get more than one from the edge. This is a known bug that we have found post beta2, and i know the work around, but i want to make sure this is the problem.

     

     

    Thursday, August 17, 2006 8:30 PM
  • Right you are.  I have multiple certificates.

    Edge Transport Server:

    Thumbprint                                Subject
    ----------                                -------
    28F99BB3E41CB6A01214DD0666E226640A5B5C56  CN=shake-virtual02
    B9D7F3BB4DEA60A7FD666C51F44124C7C2F53138  CN=shake-virtual02
    A0254657783FD3085A358CEDB1B5C20A1C707A3D  CN=msvirtual02
    1FB7DE94ECD570B1AF8A2BBDDC0542F6B9269A02  CN=msvirtual02

    Hub Transport Server:

    Thumbprint                                Subject
    ----------                                -------
    2FA75CAE245D6BFC37B75DF99A8BE5FA180DE3FA  CN=mastershake.thundercleese.com, ...
    68668FA974AD60CDE4A104F5B77EFC794A8CF1EA  CN=shake-virtual03, DC=thunderclee...
    4BB3958303782524D226C9CC05CB59E6EC24711D  CN=shake-virtual03
    CF1E0606052F1AA78E7B0D0786D280D953365A08  CN=shake-virtual03
    CACD26A5683EC5E2295648AE6E06C25BF2E35127  CN=mastershake.thundercleese.com, ...

    So..... now what?

    --Jeff

    Thursday, August 17, 2006 8:51 PM
  • The problem right now is we do not refresh the certificate used by ADAM when issue a new subscription, so if you have created a new cert, we keep presenting the old one.  Ok, so here's what you need to do to get ADAM to present the new one:

    1.     On the Hub, Remove the Subscription

    2.     On the Edge, Remove the cert used by ADAM to establish secure connections. You can do this by following the following steps:

    a.       Open up an empty mmc console (Run -> mmc)

    b.      Select File -> Add / Remove Snap-in

    c.       Hit Add

    d.      Select “Certificates” from the List of Snap-Ins available, and hit Add.

    e.      Select “Service Account” on the “Certificates Snap-In” page, click next.

    f.        Select  “Local Computer” on the “Select Computer” page, click next.

    g.       Select “Microsoft Exchange ADAM” from the list of services, click Finish.

    h.      Close the “Add Snap-in” dialog.

    i.         Navigate to “Certifcates – Service” -> “ADAM_MSExchange\Personal” -> Certificates

    j.        You should see a single certificate here. Remove it.

    3.     On the Edge, Unsubscribe, then create a new subscription file (you should see a new certificate show up at this point on the ADAM cert container from the step above) by calling new-edgesubscription

    4.     Re-start the “Microsoft Exchange ADAM” service.

    5.     Bring the file in and re-subscribe (new-edgesubscription on the hub.)

    That should do the trick. let me know if it works.

    Thursday, August 17, 2006 9:27 PM
  • That did the trick.

    I had an old certificate there from before the machine was renamed and from your description, it looks like ADAM was using the older certificate instead of the new one, which caused the certificate error and the related LDAP failure.  Once I followed your instructions, I was able to get the start-edgesynchronization to complete with no errors.  The next step will be to put the edge transport server out on the edge network and see if it works (SMTP transport, Web mail, ActiveSync, Anti-Spam, all the goodies).

    Thanks very much for your help.  I hope this thread proves useful for others that are having the same issue.

    --Jeff

    Thursday, August 17, 2006 10:03 PM
  • Cool, happy to hear that worked. Hope others find it useful too. Do let us know how your progress goes in deploying your edge server, we are very interested on hearing what people think about the new server role.

    Thursday, August 17, 2006 10:26 PM
  • Well, now that the Edge Transport server is internet-facing and the MX records have propigated, I have run into another issue.  I can send fine but I get a new (to me) error when I try to receive mail.

    I sent a piece of mail from my production server (at a different location) to the new server and received the following error:

    Received-SPF: None (SHAKE-VIRTUAL02: jeff.mcmillen@fakedomain.com does not designate permitted sender hosts)

    Looks like the Sender ID is tagging the message as None (correct, we don't have any SPF details listed with our DNS, register.com doesn't let us do this at the moment) and then passes the message on to the hub transport server which rejects the message, which comes flying back out the Edge Transport server and back to me.

    So, I disabled the Sender ID filter in the Anti-Spam settings of the Edge Transport server but am getting the same results.  I've even restarted the Edge Transport service in case the disable did not take effect until a reboot but that did not help.

    I can start a new thread if needed.

    --Jeff

    Friday, August 18, 2006 1:30 AM
  • Hi Jeff,

    Hub transport is rejecting the message for some other reason and not because SenderId is tagging the message as None. SenderId can reject the message only in case of Fail or TempError. Can you share the NDR that you are getting ?

    Thanks,

    -Bhavin.

    Friday, August 18, 2006 4:50 AM
  • Yes, good catch.  I deduced that myself after some more testing.

    I then used telnet 25 to test the SMTP connector on the Hub Transport machine.  I was able to submit the message with no errors but still received the NDR as if I had sent it normally which leads me to believe the error is on the Hub Transport machine.  I deleted and recreated the connectors (I had two before) but that did not solve the issue.  I now believe it might be related to the fact that the Hub Transport machine was previously internet-facing (due to the fact that the Edge Transport was not working, the real reason for this thread).

    Here is the full NDR.  I am not obscuring the e-mail addresses so you can see the whole data stream.  Please don't use the addresses for any nefarious purpose.  Thanks.  :)

    Sorry, we couldn't deliver your message to the following people or distribution lists. We hope the information below helps you understand what happened. Please read it carefully.

    postmaster@thundercleese.com
    You are not allowed to send e-mail messages to this recipient. Microsoft Exchange will not attempt to redeliver this e-mail message for you. Please ask your system administrator for help.

    To determine which organization rejected your message, please see the domain name of this server name: shake-virtual03.thundercleese.com. For a server name such as edge1.contoso.com, the domain name is contoso.


    Sent by Microsoft Exchange Server 2007





    Diagnostic information for administrators:

    Generating server: thundercleese.com

    postmaster@thundercleese.com
    shake-virtual03.thundercleese.com #550 5.7.1 Client does not have permissions to submit to this server ##

    Original headers:

    Received: from exch02.efundserv.efundllc.com (66.150.173.238) by
     shake-virtual02.thundercleese.com (192.168.84.22) with Microsoft SMTP Server
     id 8.0.605.16; Thu, 17 Aug 2006 19:08:35 -0700
    Received: from exch03.efundserv.efundllc.com ([192.168.5.8]) by
     exch02.efundserv.efundllc.com with Microsoft SMTPSVC(6.0.3790.1830);	 Thu, 17
     Aug 2006 19:08:32 -0700
    X-MimeOLE: Produced By Microsoft Exchange V6.5
    Content-Class: urn:content-classes:message
    MIME-Version: 1.0
    Content-Type: multipart/alternative;
    	boundary="----_=_NextPart_001_01C6C26B.33886CD1"
    Subject: RE: Undeliverable: test mail
    Date: Thu, 17 Aug 2006 19:08:30 -0700
    Message-ID: <D0314F20ED9245409E18B63424B30C56FF4FBB@exch03.efundserv.efundllc.com>
    In-Reply-To: <30ce2feb-2215-4275-a53f-5d6eb633807c>
    X-MS-Has-Attach:
    X-MS-TNEF-Correlator:
    Thread-topic: Undeliverable: test mail
    Thread-Index: AcbCaUa37PwoZXQJS/mcvarB+iLTKgAAAKSdAAB5cZA=
    From: "Jeff C. McMillen" <jeff.mcmillen@efundllc.com>
    To: <postmaster@thundercleese.com>
    Return-Path: jeff.mcmillen@efundllc.com
    X-OriginalArrivalTime: 18 Aug 2006 02:08:32.0938 (UTC) FILETIME=[34C6F0A0:01C6C26B]
    

    --Jeff

    Friday, August 18, 2006 5:20 AM
  • So just to clarify, your edge server is synch'd to your hub server? If so, deleting your connectors might have messed up the authentication settings between the two.

    Do you have a "--" connector on the edge, and do you have the default connectors on the hub transport server?

    Friday, August 18, 2006 5:28 AM
  • The Edge Transport server is sync'd to the Hub Transport server.  I just confirmed again via start-edgesynchronization (completed sucessfully).  I have a -- send connector on the edge server named Default internal send connector.  -- is listed as both the address space and smart host.  I have another send connector called EdgeSync - Default-First-Site-Name.

    As to the default connectors on the Hub Transport server, not so much.  I have one "Default Receive Connector" set up as an internal connector.  The network accepts all connections and the authentication settings are all but the last two in the list.  That's the only one listed.  Am I missing something (I am assuming that I am).

    --Jeff

    Friday, August 18, 2006 5:47 AM
  • Can you do a get-sendconnector | fl on the receive connector on the Hub? I've seen this problem before on hubs if the Permissions Groups on the connector are not set properly. You may need to add a "Exchange Server" since this is what the gateway is comming in as. I'm guessing this may not be set.

     

     

    Friday, August 18, 2006 5:58 AM
  • i meant to say get-receiveconnector | fl.
    Friday, August 18, 2006 6:04 AM
  • Do you people ever sleep?

    Permission groups are ExchangeUsers and ExchangeServers.  See full text below.

    Schema                                  : Microsoft.Exchange.Data.Directory.SystemConfiguration.ReceiveConnectorSchema
    AuthMechanism                           : Tls, BasicAuth, BasicAuthPlusTls, ExchangeServer
    Banner                                  :
    BinaryMimeEnabled                       : True
    Bindings                                : {0.0.0.0:25}
    ChunkingEnabled                         : True
    DefaultDomain                           :
    DeliveryStatusNotificationEnabled       : True
    EightBitMimeEnabled                     : True
    EnhancedStatusCodesEnabled              : True
    ExternallySecuredAsPartnerDomain        :
    Fqdn                                    : shake-virtual03.thundercleese.com
    Comment                                 :
    Enabled                                 : True
    ConnectionTimeout                       : 00:10:00
    ConnectionInactivityTimeout             : 00:05:00
    MessageRateLimit                        : unlimited
    MaxInboundConnection                    : 5000
    MaxInboundConnectionPerSource           : 100
    MaxInboundConnectionPercentagePerSource : 2
    MaxHeaderSize                           : 64KB
    MaxHopCount                             : 30
    MaxLocalHopCount                        : 3
    MaxLogonFailures                        : 3
    MaxMessageSize                          : 10MB
    MaxProtocolErrors                       : 5
    MaxRecipientsPerMessage                 : 200
    PermissionGroups                        : ExchangeUsers, ExchangeServers
    PipeliningEnabled                       : True
    ProtocolLoggingLevel                    : Basic
    RemoteIPRanges                          : {0.0.0.0-255.255.255.255}
    RequireEHLODomain                       : False
    RequireTLS                              : False
    Server                                  : SHAKE-VIRTUAL03
    SizeEnabled                             : True
    TarpitInterval                          : 00:00:05
    AdminDisplayName                        :
    ObjectCategoryName                      : msExchSmtpReceiveConnector
    ExchangeVersion                         : 0.1 (8.0.535.0)
    CurrentObjectVersion                    : 0.1 (8.0.535.0)
    Name                                    : Default Receive Connector
    DistinguishedName                       : CN=Default Receive Connector,CN=SMTP Receive Connectors,CN=Protocols,CN=SHAKE
                                              -VIRTUAL03,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=A
                                              dministrative Groups,CN=thundercleese,CN=Microsoft Exchange,CN=Services,CN=Co
                                              nfiguration,DC=thundercleese,DC=com
    Identity                                : SHAKE-VIRTUAL03\Default Receive Connector
    Guid                                    : cb4a1f0d-6bca-48a9-b5a6-0c30e9021c12
    ObjectCategory                          : thundercleese.com/Configuration/Schema/ms-Exch-Smtp-Receive-Connector
    ObjectClass                             : {top, msExchSmtpReceiveConnector}
    OriginalId                              : SHAKE-VIRTUAL03\Default Receive Connector
    WhenChanged                             : 8/17/2006 7:09:39 PM
    WhenCreated                             : 8/17/2006 6:42:42 PM
    ObjectState                             : Unchanged
    OriginatingServer                       : mastershake.thundercleese.com
    IsReadOnly                              : False
    Id                                      : SHAKE-VIRTUAL03\Default Receive Connector
    IsValid                                 : True

    --Jeff

    Friday, August 18, 2006 6:12 AM
  • Sleep? What's that? ... :-) Must be something in the Redmond water supply or something ... ;-)

    Anway, is the NDR that you posted the one you did through telnet? or was it the one that was delivered direclty through the gateway? I think this you are getting this one because you are sending directly through port 25 through telnet, not throught the edge. You'll notice two properties on the receive connector:

    AuthMechanism                           : Tls, BasicAuth, BasicAuthPlusTls, ExchangeServer

    PermissionGroups                        : ExchangeUsers, ExchangeServers

    What the permission group means is that only entities that qualify as either of those will be able to submit. "ExchangeUsers" permission are assigned to users that have been authenticated as such, and ExchangeServers means it's a server to server communication (either through a hub on your org or an edgesync'd machine.) Since you are opening up a telnet session, your connection will belong to the "Anonnymous" permission group, which leads to the 5.7.1 message.

    is your topology then

    SHAKE-VIRTUAL03 (Hub) <--> SHAKE-VIRTUAL02 (EDGE) <--> EXCH02?

     

     

    Friday, August 18, 2006 6:35 AM
  • Nope.  This is a regular e-mail NDR, not one generated from telnet.  The message came from my corporate production exchange servers (at my office in Bellevue) to the test 2007 servers (at my house in Seattle).  The NDR from my telnet session shows a different source location in the headers, one local to the subnet of the Exchange 2007 servers.

    The topology is:

    Shake-Virtual03 (Hub, Mailbox, and Client) <- Shake-Virtual02 (Edge) <- Internet <- Exch02 (front end server in corporate office)

    From what you are saying, it looks like the communication between the Edge Transport server and the Hub Transport server appears to be via anonymous authentication and that's where the failure occurs.  That makes some sense but I do not know how to force the connection to use ExchangeServer authentication.

    --Jeff

    Friday, August 18, 2006 3:55 PM
  • Can you post the results of running this command on the edge? "get-sendconnector | fl" . I'm curious what the edge settings are for the send connectors.

    Felix

    Friday, August 18, 2006 4:45 PM
  • Here you go.

    [MSH] C:\Documents and Settings\Administrator>get-sendconnector | fl


    Schema                           : Microsoft.Exchange.Data.Directory.SystemConfiguration.SmtpSendConnectorSchema
    DNSRoutingEnabled                : False
    SmartHosts                       : {--}
    Port                             : 25
    LinkedReceiveConnector           :
    ConnectionTimeOut                : 00:10:00
    ForceHELO                        : False
    IgnoreSTARTTLS                   : False
    Fqdn                             :
    RequireTLS                       : False
    Enabled                          : True
    ExternallySecuredAsPartnerDomain :
    ProtocolLoggingLevel             : None
    AuthMechanism                    : ExchangeServer
    AuthenticationCredential         :
    UseExternalDNSServersEnabled     : False
    SourceIPAddress                  : 0.0.0.0
    SmartHostsString                 : --
    AddressSpaces                    : {smtp:--;1}
    MaxMessageSize                   : 10MB
    DeliveryMechanism                : 2
    ConnectedDomains                 : {}
    IsScopedConnector                : False
    IsSmtpConnector                  : True
    Comment                          :
    SourceRoutingGroup               : Exchange Routing Group (DWBGZMFD01QNBJR)
    SourceTransportServers           : {}
    HomeMTA                          :
    HomeMtaServerId                  :
    MinAdminVersion                  : -2147453113
    AdminDisplayName                 :
    ObjectCategoryName               : msExchRoutingSMTPConnector
    ExchangeVersion                  : 0.1 (8.0.535.0)
    CurrentObjectVersion             : 0.1 (8.0.535.0)
    Name                             : Default internal send connector SHAKE-VIRTUAL02
    DistinguishedName                : CN=Default internal send connector SHAKE-VIRTUAL02,CN=Connections,CN=Exchange Routin
                                       g Group (DWBGZMFD01QNBJR),CN=Routing Groups,CN=Exchange Administrative Group (FYDIBO
                                       HF23SPDLT),CN=Administrative Groups,CN=First Organization,CN=Microsoft Exchange,CN=S
                                       ervices,CN=Configuration,CN={67138980-1800-41E9-822B-D30D47FECBFA}
    Identity                         : Default internal send connector SHAKE-VIRTUAL02
    Guid                             : b944a16c-0d09-4c57-b98d-87df58689641
    ObjectCategory                   : CN=ms-Exch-Routing-SMTP-Connector,CN=Schema,CN=Configuration,CN={67138980-1800-41E9-
                                       822B-D30D47FECBFA}
    ObjectClass                      : {top, msExchConnector, mailGateway, msExchRoutingSMTPConnector}
    OriginalId                       : Default internal send connector SHAKE-VIRTUAL02
    WhenChanged                      : 8/17/2006 7:03:24 PM
    WhenCreated                      : 7/25/2006 5:13:23 PM
    ObjectState                      : Unchanged
    OriginatingServer                : localhost
    IsReadOnly                       : False
    Id                               : Default internal send connector SHAKE-VIRTUAL02
    IsValid                          : True

    Schema                           : Microsoft.Exchange.Data.Directory.SystemConfiguration.SmtpSendConnectorSchema
    DNSRoutingEnabled                : True
    SmartHosts                       : {}
    Port                             : 25
    LinkedReceiveConnector           :
    ConnectionTimeOut                : 00:10:00
    ForceHELO                        : False
    IgnoreSTARTTLS                   : False
    Fqdn                             :
    RequireTLS                       : False
    Enabled                          : True
    ExternallySecuredAsPartnerDomain :
    ProtocolLoggingLevel             : None
    AuthMechanism                    : None
    AuthenticationCredential         :
    UseExternalDNSServersEnabled     : False
    SourceIPAddress                  : 0.0.0.0
    SmartHostsString                 :
    AddressSpaces                    : {smtp:*;100}
    MaxMessageSize                   : 10MB
    DeliveryMechanism                : 2
    ConnectedDomains                 : {}
    IsScopedConnector                : False
    IsSmtpConnector                  : True
    Comment                          :
    SourceRoutingGroup               : Exchange Routing Group (DWBGZMFD01QNBJR)
    SourceTransportServers           : {}
    HomeMTA                          :
    HomeMtaServerId                  :
    MinAdminVersion                  : -2147453113
    AdminDisplayName                 :
    ObjectCategoryName               : msExchRoutingSMTPConnector
    ExchangeVersion                  : 0.1 (8.0.535.0)
    CurrentObjectVersion             : 0.1 (8.0.535.0)
    Name                             : EdgeSync - Default-First-Site-Name to Internet
    DistinguishedName                : CN=EdgeSync - Default-First-Site-Name to Internet,CN=Connections,CN=Exchange Routing
                                        Group (DWBGZMFD01QNBJR),CN=Routing Groups,CN=Exchange Administrative Group (FYDIBOH
                                       F23SPDLT),CN=Administrative Groups,CN=First Organization,CN=Microsoft Exchange,CN=Se
                                       rvices,CN=Configuration,CN={67138980-1800-41E9-822B-D30D47FECBFA}
    Identity                         : EdgeSync - Default-First-Site-Name to Internet
    Guid                             : 6fc992e0-9f83-4b8f-b0ef-56af3c20eda7
    ObjectCategory                   : CN=ms-Exch-Routing-SMTP-Connector,CN=Schema,CN=Configuration,CN={67138980-1800-41E9-
                                       822B-D30D47FECBFA}
    ObjectClass                      : {top, msExchConnector, mailGateway, msExchRoutingSMTPConnector}
    OriginalId                       : EdgeSync - Default-First-Site-Name to Internet
    WhenChanged                      : 8/17/2006 2:59:43 PM
    WhenCreated                      : 8/17/2006 2:59:43 PM
    ObjectState                      : Unchanged
    OriginatingServer                : localhost
    IsReadOnly                       : False
    Id                               : EdgeSync - Default-First-Site-Name to Internet
    IsValid                          : True

     

    --Jeff

    Friday, August 18, 2006 5:34 PM
  • I'm more interested in the output of the "--" send connector on the Edge side. Can you echo that?

    The Edge-->Hub connection should be authenticated by default. If edge isn't attempting authentication in the first place due to the connector being deleted and recreated and loosing some of the defaults, this may be your problem.

    Friday, August 18, 2006 7:29 PM
  • Whoops, you did that already ;-)... let me look at that...
    Friday, August 18, 2006 7:32 PM
  • Ok, talked to Felix about this. We think either there is still something up with your cert or the connector settings are not being honored and Edge is trying to submit anonymously to the hub server (which the hub will reject by default).

    Try this:

    1) Recycle the MsExchangeTransport service on your hub. See if the repro goes away. If it does, please let us know.

    2) If that doesn't work, enable protocol logging on the default receiveconnector on your hub server (-ProtocolLoggingLevel:Basic). Cause a repro to happen and look at the SMTP session it generates in the \Program Files\Exchange Server\TransportRoles\Logs\ProtocolLogs\SmtpReceive folder. If you could let us know what you see there, then we'll know if this is a connector configuration issue or a cert issue.

    Thanks for your patience,

    Friday, August 18, 2006 10:08 PM
  • AAAAH!  Can I just rebuild these two servers now please?

    I rebooted the servers (and the host server, they reside in VMWARE virtual machines) to apply some patches and to upgrade VMWARE Server to 1.0.1 and when I restarted the servers, the receive connectors on the Edge Transport server had changed.  Now there was only one receive connector and it only accepted mail from internal clients, not from external clients.  When I sent my test message I got:

    The following recipient(s) could not be reached:

    jeff.mcmillen@thundercleese.com on 8/18/2006 3:33 PM

    The message reached the recipient's e-mail system, but delivery was refused. Attempt to resend the message. If it still fails, contact your system administrator.

    <thundercleese.com #5.2.0 smtp;550 5.2.0 STOREDRV.Deliver.Exception:MapiExceptionNotFound; 6099,5587,6099,5587,6099,5587,23921,24305,23921,23921,21233,6828,21233,6828,13492,5312,21233,3896,5093,5318,10104,6025,5257,4606,10786>

    I checked the SMTP logs on my corporate server and indeed the Edge Transport server was now rejecting the mail.  So, stuck with what to do, I tried to create the External receive connector but the system would not let me, telling me that it conflicted with the extisting connector.  Then, storming off into uncharted territory, I deleted the existing, not working, receive connector and created one with the Internet settings.  Then, on a hunch, I tried sending mail from the 2007 install and got an error.  There's no internal mail receive connector on the Edge Transport server... so I created one of those as well, but it could be now that the subscription is hosed.

    We may be walking down a dead-end street now.  I will continue to work on this if you are getting good data but I may be better served by saying goodbye to these machines and starting from scratch again.

    Thoughts?

    --Jeff 

    Friday, August 18, 2006 11:15 PM
  • OK, nuke 'em (we'll accept the white flag on this one ;-)).

    To help ensure you have something to revert to, when you try this again I would suggest forking the VM image (or enabling undo disks) right after the Exchange 2007 setup procedure completes. That way you can revert and compare initial settings with the settings you derived when you're debugging behavioral differences.

    Good luck, and again thanks for giving us all of this info / feedback on Exchange 2007.

    Saturday, August 19, 2006 12:01 AM
  • Ok.  Shall we try again?

    I started from scratch.  I recreated all machines involved.  I even nuked and recreated the domain and am getting very similar results.  Here's the architecture:

    4 servers running in VMWare sessions on the same physical server.  All 4 have 768MB of RAM and between 32 and 64GB of HD space.  All 4 have a single NIC with an internal IP address.  One-to-One NAT on the firewall allows external access to two of the virtual machines.

    shake-virtual01
    Windows Server 2003 R2 x64
    thundercleese.com domain controller
    domain controller, dns, etc
    192.168.84.21

    shake-virtual02
    Windows Server 2003 R2 x64
    thundercleese.com member server
    web services (unrelated to our project)
    192.168.84.22

    shake-virtual02
    Windows Server 2003 R2 x64
    stand alone machine
    Edge transport server
    192.168.84.23

    shake-virtual04
    Windows Server 2003 R2 x64
    thundercleese.com member server
    Exchange 2007 Client Access, Hub Transport, and Mailbox (default install)
    192.168.84.24

    After the clean install of the above, I tried the Edge Subscription but got the same exact errors I was getting before.  I followed the instructions and removed / recreated the certificate and re-subscribed and it worked.  During that process I noticed that I did not have the DNS entry for the Edge Transport server set correctly (had to be manually added since it is not a domain member) so it could be that the DNS failure was creating my first subscription problem but in any case the subscription is now working.

    I tried sending mail and it worked find but replies are getting a new but equally frustrating problem.  The message hits the Edge Transport server but doesn't get delivered.  The SMTP logs on the Edge Transport Server show that the "Default Internal Receive Connector" is picking up the mail and sending back a "504 5.7.1 Not authorized" message.

    There was no default external receive connector on the Edge Transport server.  I tried creating one but it (of course) conflicted with the existing one (only one IP address available).  I added a new IP address to the single adapter and created an external receive connector bound to the new address (192.168.84.25) and repointed the firewall to map the external IP to the new internal one (trying to create a dual adapter configuration without having two adapters) but I get the same 504 error on the new connector.

    I know that I am running a "non-standard' install with the Edge Transport server only having one NIC.  Could this be part of the problem?

    I am stubborn and want to solve this.  I had lots of time to recreate all this on Saturday while rebuilding a RAID on my production Exchange 2003 server and was hoping to get past this hurdle with a clean install but no luck.

    --Jeff

    Monday, August 21, 2006 10:25 PM
  • Jeff,

    I'm gladd you are still trying to move forward with this. The DNS problem is definitely what caused your initial subscription failure, since it relies on DNS to find the hub (we are working on cleaning up the error messages to be more explicit about this, by the way). I'm suspecting the re-creation of the certs put you back in a bad state. I'm going to follow similar steps to what you have to try and repro the issue here, and i'll let you know once i do how to get you back in a normal state. Stay tuned.....

    Felix  

    Monday, August 21, 2006 10:31 PM
  • Hi Felix,


    Hope all is well is Seattle. I am an engineer in the Bay Area trying to setup MS Exchange 2007 Beta 2, and I'm very stumped on something I can't figure out.

    I thought EdgeSync was supposed to sync user account info, amongst other things, from the Hub Trans. to the Edge Transport? I am having a problem doing the EdgeSync. 

    The Edge Transport box is on a self contained local Workgroup, outside of the domain, but the DNS name for it involves the FQDN for the domain.

    (Edge.Archipelago.us - Exchange would not let me install otherwise) The domain is archipelago.us. My DC is SF-dc. The internal Exchange Hub is SF-Mail.

    Everyone can ping everyone by DNS ...

    Problem: I've created the xml file on the Edge Transport and imported it into the Hub, fine. When I run the command {Start-EdgeSynchronization} on the Hub, I get this msg:


             Welcome to the Exchange Management Shell!

     Get-Alias

    [MSH] C:\Documents and Settings\Administrator.ARCHIPELAGO>Start-EdgeSynchronization


    Result         : CouldNotConnect
    Type           : General
    Name           : CN=EDGE,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF2
                     3SPDLT),CN=Administrative Groups,CN=Archipelago,CN=MicrosoftE
                     xchange,CN=Services,CN=Configuration,DC=Archipelago,DC=us
    FailureDetails : The supplied credential is invalid.
    StartUTC       : 10/3/2006 4:58:22 AM
    EndUTC         : 10/3/2006 4:58:22 AM
    Added          : 0
    Deleted        : 0
    Updated        : 0
    Scanned        : 0
    TargetScanned  : 0


    So I thought, after looking at that, that I needed to open Active Directory Users and Computers, and create the "{Edge} computer Acct. and add it to the Exchange Administrative Group.

    So I did (even though that was confusing - It didn't make sense - to am add a Workgroup Acct. with the FQDN Domain Name into A/D but at the same time not wanting to formally have the computer join the Domain??

    After that dind't work, I tried Cert Surgery (3 TIMES)  - the kind you recommended.  Deleted cert, restarting ADAM, etc.  No go.

    Everyone can ping everyone else by DNS proper ...any ideas?


    <ESRAUsername>cn=ESRA.EDGE,CN=Services,CN=Configuration,CN={C83A9791-38A2-446C-BEDF-EC696855A7F1}</ESRAUsername>
      <ESRAPassword>tpu7gaV67I0=^yO5QwtD</ESRAPassword>
      <EffectiveDate>632954270845625000</EffectiveDate>
      <Duration>144000000000</Duration>
      </EdgeSubscriptionData>


    What I see is that the CN info in the failure after Start-EdgeSynchronization is different than the CN listed in the XMl of the Subscription. Specifically the {ESRA} part.


    EdgeServerName>EDGE</EdgeServerName>
      <EdgeServerFQDN>Edge.Archipelago.us</EdgeServerFQDN>
     
    (Deleted all the cert blah blah)
     
      <ESRAUsername>cn=ESRA.EDGE,CN=Services,CN=Configuration,CN={C83A9791-38A2-446C-BEDF-EC696855A7F1}</ESRAUsername>
      <ESRAPassword>tpu7gaV67I0=^yO5QwtD</ESRAPassword>
      <EffectiveDate>632954270845625000</EffectiveDate>
      <Duration>144000000000</Duration>
      </EdgeSubscriptionData>

    Also,

    If I do a get edge-subscription on the HUB Trans, I see something different than what shows on the Edge:


    HUB:

    [MSH] C:\Documents and Settings\Administrator.ARCHIPELAGO>get-EdgeSubscription

    Name            Site                 Domain
    ----            ----                 ------
    EDGE            Archipelago.us/Co... Archipelago.us


    [MSH] C:\Documents and Settings\Administrator.ARCHIPELAGO>Start-EdgeSynchronizat
    ion

    EDGE:


    [MSH] C:\>get-edgeSubscription

    Name            Site                 Domain
    ----            ----                 ------
    Edge                                 Archipelago.us

    Please - any ideas ? Very stuck ...!

    Thanks to let me know....if you see anything

    Kahele


    Tuesday, October 03, 2006 6:26 AM
  • Hi Kahele,

    Yes, edge sync does update recipient information on the Edge Server. The problem  that you are having is not because of certs, its an issue with credentials. EdgeSync uses ADAM credentials to connect to the edge server, and those are periodically changed by the "Edge Credential Service" running on the edge server. I would guess that service might not be running on your edge box, or a sync didn't happen for whatever reason within the initial 4 hours after you created the subscription. What you'll need to do is

    1. Make sure the credential service is up and running on the edge.

    2. Create a new subscription file by calling new-edgesubscription again.

    3. Reimport the subscription.

    4. Call start-edgesynchronization immediately after you subscribe.

    the CN is expected to be different between the file and what start-edgesynchronization is telling you. The CN in the file is the CN of the ADAM user account Edge Sync will connect with initially, and the CN in start-edgesynchronization is the CN of the representatino of the Edge server in AD (how we keep track of it basically) so they will be different. 

    Let me know if the above works.

     Felix Deschamps

    Tuesday, October 03, 2006 6:48 PM
  • Hi Felix,

    Its working now, thanks! -


    I have a few comments and some questions at the bottom of this thread. I'm not sure that the credentials service wasn't running before, in fact I thought it was...but my clocks definitely were way off, so I did adjust those and I am having success now.

    I did a remove-EdgeSubscription on both the Hub and the Edge and followed your instructions. I then did a new-EdgeSubscription on the Edge. Then I ran the start-edgesynchronization


    Result         : InProgress
    Type           : Configuration
    Name           : CN=EDGE,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF2
                     3SPDLT),CN=Administrative Groups,CN=Archipelago,CN=Microsoft E
                     xchange,CN=Services,CN=Configuration,DC=Archipelago,DC=us
    FailureDetails :
    StartUTC       : 10/3/2006 11:23:15 PM
    EndUTC         : 10/3/2006 11:22:48 PM
    Added          : 0
    Deleted        : 0
    Updated        : 0
    Scanned        : 0
    TargetScanned  : 0

    Result         : Success
    Type           : Recipients
    Name           : CN=EDGE,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF2
                     3SPDLT),CN=Administrative Groups,CN=Archipelago,CN=Microsoft E
                     xchange,CN=Services,CN=Configuration,DC=Archipelago,DC=us
    FailureDetails :
    StartUTC       : 10/3/2006 11:23:15 PM
    EndUTC         : 10/3/2006 11:23:20 PM
    Added          : 0
    Deleted        : 0
    Updated        : 2
    Scanned        : 2
    TargetScanned  : 2

    Here are my questions:

    1.) Queuing capability ?

    I am using my EDGE Server on a perimeter network external to my domain.  Am I understanding this correctly, that the Edge Server more or less acts like a "scrubber" or a relay, so it could accommodate receiving and queueing mail

    - even when a connection to the "inside" Hub Transport Server is otherwise unavailable?  Then when the link between the Edge and the HUB comes back up the mail can be delivered to the mailboxes?

    This is important to know, ( I have a domain at home with Hub Transport that may be powered down for electric conservation sake, but I think this question otherwise applies to legit power outages.

    Would it just refer to local definitions of groups, etc?- "hold" the mail for delivery?)


    2.) Sync to HUB / times /etc ?

    How exactly do I check replication here between the Edge and the Hub ? The Test-EdgeSynchronization command seems to be gone. (with A/D Servers I have replmon) Also the Edge Subscription performs scheduled updates so that the information in ADAM remains current. Is this schedule flexibly configured anywhere?


    3.) Domain membership / outsider status.

    So we don't need to add the {Edge/outside Workstation} to the Domain membership in any way, right? Just verifying. Not listed as a computer, or anything? Interesting - in that it can still receive the "inside" ADAM info. 

    4.) Adam Instance?  The Edge Subscription process establishes one-way replication of recipient and configuration information from Active Directory to ADAM.

    But I never created an ADAM instance ...So...Under what circumstances would I?

    Thanks again for your great help ! 




    Wednesday, October 04, 2006 12:06 AM
  •  

    Ah, clock out of sync would also do it. Basically, the first replication has a 4 hour window for success from the moment the subscription is created on the edge to when the edge server receives the batch of data. (This is for Beta 2, it has been changed to 24 hours for the RTM release), If replication does not occur in that 4 hour window  then the credentials EdgeSync uses become stale, which leads to the problem you got into. For RTM we try to detect the time discrepancy and we fail the subscription creation. (We tell you why of course, so you can go and change the clock.) Now, on your questions:

    1. Correct, the edge does act as a "Relay" in some sense, just like any other mail server: the main thing you have to worry about are the time out, because we will eventually NDR the message if the hub takes long enough. The default time out should be long enough though, so that shouldn't be much of a problem (you should be able to do something like "get-queue | retry-queue" on the monad command line if you know when the hub is up.)

    2. Test-EdgeSynchronization was added after Beta2 was released, so if you are using Beta2 then you won't have it on your build. That will be the best thing to check if things are up to date, as it gives you the exact status for each of the replication categories. (It will also be hooked into MOM, so if you use the Exchange Management Pack, that check will be automatic.) The schedule is currently 1 hour for config information and 4 hours for recipients, and there are no tasks that can be used to configure this schedule.

    3. Also correct, the gateway doesn't have to be listed anywhere as a member. The only real requirement is that the DNS servers inside the org are able to resolve the FQDN of the edge server as listed on the edge itself, as this is what we will use to resolve the Edge, and you'll probably need DNS inside the perimeter to be able to resolve the Hub for mailflow (unless you configure connectors to use smarthosts for inbound mail, in which case you don't even need that) Although we will show the edge as belonging to your org, this is simply a virtual link: the edge is never actually joined to the domain.

    4. An ADAM instance is created for you when the Edge server is installed, and that is the instance that Edge sync talks to. Recipients are hashed, so you don't have to worry about your recipient data being exposed in the clear.

    Hope that answers your questions . Let me know if there is anything else you are curious about.

    Felix Deschamps

    Wednesday, October 04, 2006 5:13 PM
  • Hi felix,

    What's a Smarthost for inbound mail?

    I have a question on a setup. I am testing Exchange 2007 and haven't been able to connect yet or receive mail and just wanted to verify one thing first.

    i was trying to connect with the Outlook 2003 client and I couldn't. I'm not sure where I'm going wrong yet, just had one question though. Heres my setup. I am deploying an Edge Mail Server with the Hub Trans on the inside.

    Internet -> FireW--> # 1 Edge Mail--> FireW --> # 2 Internal Mail Hub --> DC.

    Question: Right now the Edge can resolve the Internal Mail Hub via DNS call. But no one else on the internet can resolve any DNS that points to the Internal mail hub.

    In fact, I am pointing the MX record to #1 the Edge Mail, which is a public IP. Correct?

    Q: Do I need internet DNS to resolve to the # 2 Internal Mail Hub?

    Or is the #1 (Edge) capably and privately resolving the #2 (Hub Server) enough?

    I think if I install the Client access on the Internal Mail Hub then i would need a public IP.

    Im just trying to figure out how to provide the outside DNS to an internal mail hub, what the normal convention is - as you have to config the hostname etc in the Outlook client settings.

    Thanks for verifying I'm on the right track...

    Friday, October 06, 2006 5:31 AM
  • I hit the same error as originally reported and was able to resolve by creating an A record on my DC (which doubles as DNS) and then flushing the cache on my HT server.

    Kev

     

    Monday, October 23, 2006 7:09 PM
  • I also ran into the same issue as Kahele with edgesync and credentials errors, and the solution as quoted below fixed my problem.

    I'm quite sure that the edge subscription was working fine after it was created- I only started having trouble after all the involved Ex2k7 lab servers were turned off for at least a week.  Will the credentials for Edgesync become stale after a certain period of time without communication, even if an initial sync is successful?

    Thanks,
    Mike


     Felix Deschamps - MSFT wrote:

    Yes, edge sync does update recipient information on the Edge Server. The problem that you are having is not because of certs, its an issue with credentials. EdgeSync uses ADAM credentials to connect to the edge server, and those are periodically changed by the "Edge Credential Service" running on the edge server. I would guess that service might not be running on your edge box, or a sync didn't happen for whatever reason within the initial 4 hours after you created the subscription. What you'll need to do is

    1. Make sure the credential service is up and running on the edge.

    2. Create a new subscription file by calling new-edgesubscription again.

    3. Reimport the subscription.

    4. Call start-edgesynchronization immediately after you subscribe.

    the CN is expected to be different between the file and what start-edgesynchronization is telling you. The CN in the file is the CN of the ADAM user account Edge Sync will connect with initially, and the CN in start-edgesynchronization is the CN of the representatino of the Edge server in AD (how we keep track of it basically) so they will be different.

    ...

    Monday, November 13, 2006 6:28 PM
  • Hi, all!

    I have a problem of replication with EdgeSync from Huh to Edge transport server. I've tried all solution that exist in this topic but I have a problem yet.   I ran Start-EdgeSynchronization command and got the reasult


    Result         : CouldNotConnect
    Type           : General
    Name           : CN=Newserv,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF2
                     3SPDLT),CN=Administrative Groups,CN=Archipelago,CN=MicrosoftE
                     xchange,CN=Services,CN=Configuration,DC=Proba,DC=local
    FailureDetails : The LDAP server is anavailable.
    StartUTC       : 11/17/2006 4:58:22 AM
    EndUTC         : 11/17/2006 4:58:22 AM
    Added          : 0
    Deleted        : 0
    Updated        : 0
    Scanned        : 0
    TargetScanned  : 0

    I have Hub Server - Win Server 2003 Ent/x86(DC, NDS)+Exchange2007 Beta2 (Mailbox, Client Access, Hun, Un Mess); and Edge Server Win Server 2003 Ent/x86 (out of domain but in one network with Hub Server)

    Please - any ideas ? Very stuck ...!

    Thanks to let me know....if you see anything

    Roman

    Friday, November 17, 2006 7:52 AM
  • Hello Roman:

    What is the dns suffix of your GWY server? is it resolvable by your hub server? Are any ports blocked between your hub and edge server? If so, you need ldap/SSL open.

    If none of these things help you I suggest you open up a new post.

    Friday, November 17, 2006 8:08 AM
  • Hello, Greg!

    The Dns suffix of my Edge Server the is same as DNS suffix of domain and Hub server. Both servers resolvable from each other and have DNS records. Between hub and edge - nothing (no firewall)? not blocked port. In Trableshooting Assistant reports -  ports 50389 and 50636 responded, and connect whith telnet on those ports from Hub Server.

    Friday, November 17, 2006 8:23 AM
  • Hi,

    I have a same problem with final release of Exchange 2007. I can test this example installation on the virtual machines and then I can install it on the production enviroment. DNS suffix my EDGE server is same as DNS suffix DC and HUB servers. No firewall between HUP - EDGE. I can connect to ports 50389 and 50636 form HUB server - I try it this witch telnet. DNS resolution is correct.

    Result of Start-EdgeSynchronization

    Result         : CouldNotConnect
    Type           : General
    Name           : CN=EDGE,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=Firs
                     t Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=exchtest,DC=local
    FailureDetails : The LDAP server is unavailable.
    StartUTC       : 13.1.2007 20:51:01
    EndUTC         : 13.1.2007 20:51:02
    Added          : 0
    Deleted        : 0
    Updated        : 0
    Scanned        : 0
    TargetScanned  : 0

    Event Log on HUB contain this errors:

    Event Type: Error
    Event Source: MSExchange EdgeSync
    Event Category: Topology
    Event ID: 1032
    Date:  13.1.2007
    Time:  21:55:39
    User:  N/A
    Computer: EX2007
    Description:
    No credential was found for EDGE.exchtest.local

    Event Type: Error
    Event Source: MSExchange EdgeSync
    Event Category: Topology
    Event ID: 1024
    Date:  13.1.2007
    Time:  21:55:40
    User:  N/A
    Computer: EX2007
    Description:
    Failed to connect to the Edge Transport server ADAM instance with exception "The LDAP server is unavailable.".  This could be caused by a failure to resolve the Edge server name EDGE.exchtest.local in DNS, a failure trying to connect to port 50636 on EDGE.exchtest.local, network connectivity issues, an invalid certificate, or an expired subscription.  Please verify your network and server configuration.

    Event Type: Error
    Event Source: MSExchange EdgeSync
    Event Category: Topology
    Event ID: 1032
    Date:  13.1.2007
    Time:  21:55:39
    User:  N/A
    Computer: EX2007
    Description:
    No credential was found for EDGE.exchtest.local

    any guesses?

     

    Saturday, January 13, 2007 9:02 PM
  •  

    Sounds like I have the same problem as Roman Zryumov

    I have tried everything in this forum.

    Something interesting though... Could be related or maybe not, on my edge server I am getting Warnings in my system event viewer "Event ID 40960- The Security System detected an authentication error for the server DNS/serverexchange.mydomain.org. The failure code from authentication protocol Kerberow was "There are currently no logon servers available to service the logon request.""

     

    I wold assume that would be the culprit but I can't figure out how to make it go away. Because the DNS(Same Server as Exchange) server is able to communicate fine with my edge server.

     

    Roman did you ever figure your issue out? Thanks

     

    Blake

     

    Tuesday, August 07, 2007 10:32 PM
  • Actually I don't think that warning on my edge server is related because I've been getting it way before, the edge synch broke down. Something else I did find though on my exchange server is, on the day that windows update installed rollup 3 for exchange 2007 is the same day tha edgesynch stopped working.

     

     

    Wednesday, August 08, 2007 5:27 PM
  • This looks like our exact problem.  Step 3 - Unsubscribe - please elaborate?  We have been unable to find any unsubsribe or remove subscription feature/command on the Edge box.

    Thursday, September 13, 2007 7:25 PM
  • Weirdly enough, after fighting the "LDAP Server is unavailable" error for a few days I also tried simply renaming the edge server from all lowercase to uppercase and that solved the problem.  Everything works fine now.

    Friday, October 12, 2007 6:39 PM
  • I receive this error message on my exchange server periodically

     

    Event Type:      Error

    Event Source:   MSExchange EdgeSync

    Event Category:            Synchronization

    Event ID:          10107

    Date:                9/8/2008

    Time:                10:07:28 AM

    User:                N/A

    Computer:         EXCHANGE2007

    Description:

    The Microsoft Exchange EdgeSync service failed to renew the EdgeSync credentials because of The Microsoft Exchange EdgeSync service could not save the updated changes that were made to the local Hub Transport server object to the Active Directory directory service.. The exception message for this failure is Active Directory operation failed on alakai-pdc2003.alakaimech.com. This error is not retriable. Additional information: Insufficient access rights to perform the operation.

    Active directory response: 00002098: SecErr: DSID-03150A45, problem 4003 (INSUFF_ACCESS_RIGHTS), data 0

    .

     

    For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

     

    Your attention is greatly appreciated.

     

    Monday, September 08, 2008 9:36 PM
  • Thanks alot it worked for me.

     

    Regards,

    Gerhard

    Monday, October 20, 2008 2:07 PM
  • Hi,

    I have the same problem that jgarce_angel, I have two Hub Transport Servers in the enterprise and the error is show only in one.
    Please, some ideas?

    Thanks in advance

    Tipo de suceso:                Error

    Origen del suceso:          MSExchange EdgeSync

    Categoría del suceso:    Sincronización

    Id. suceso:          10107

    Fecha:                  21/08/2009

    Hora:                    9:25:52

    Usuario:                              No disponible

    Equipo:                BMSSEMHC02

    Descripción:

    El servicio de Microsoft Exchange EdgeSync no pudo renovar las credenciales de EdgeSync debido a The Microsoft Exchange EdgeSync service could not save the updated changes that were made to the local Hub Transport server object to the Active Directory directory service.. El mensaje de excepción para este error es Active Directory operation failed on cmssds01.cajacaminos.scc. This error is not retriable. Additional information: Insufficient access rights to perform the operation.

    Active directory response: 00002098: SecErr: DSID-03150A45, problem 4003 (INSUFF_ACCESS_RIGHTS), data 0

    Thursday, August 27, 2009 12:47 PM
  • Hello Anderson,

    I have just seen you site, it was really helpful, while i was working in Exchang Server 2010. But there is an Exception i.e Please mention all those detais in ENGLISH. I could not understand the Explanation.

    The following link. i have visited..

    http://www.andersonpatricio.org/Tutoriais/Tutoriais.asp?tut=817

    Thursday, December 02, 2010 11:08 AM
  • Hey Guys,

    I was having the same prob LDAP was not being founded by Edge, before i made a single change.
    Just Add a DNS MX record ``EdgeServer`` to your DNS server. Than go on Exchange Server machine and restart IIS. Than come back again on Edge Server and proceed Test-Edge.... command again and you ll be done with the msg Syn=Normal :) Cheers....


    Aatif
    Wednesday, December 07, 2011 12:16 AM