http://download.linkedin.com/desktop/osc/en/latest/bin/LinkedInOutlookConnector_x64.exe

Reading Christian Schindler’s Sidebar in the Exchange Server 2010 Best Practices book led me to the solution.

It is a permissions issue. These permissions were revealed in the Management Console in Exchange 2003, but are now set in the Shell. The following Exchange Management Shell command revealed the current permissions for the Receive Connectors on the system:

Get-ReceiveConnector | ?{$_.Name -like “*Default*”} | Get-ADPermission | ?{$_.ExtendedRights -like “*Accept-Any*”} | ?{$_.user -like “*Anon*”} | fl *

For those not familiar with PowerShell: The ‘|’ sends the information from the previous cmdlet to the next action. In this case the action after Get-ReceiveConnector is Where-Object (‘?’ for short). The code snipet in the curly brackets then filters for a Name that contains ‘*Default*’. Once the two Receive Connectors that contain the characters ‘Default’ somewhere in their name, I ask for its AD Permissions. Those permissions are then filtered for ExtendedRights that contain the characters ‘Accept-Any’. Then those results are filtered yet again for any users that contain the characters ‘Anon’.

Lastly, the ‘fl’ formats the output into the following list format. However, without the ‘*’, you will only get a subset of the attributes displayed below:

PSComputerName : Ex2010HT.corp.com
RunspaceId : d402fc47-4e1d-4e56-85ef-acb28a5257ce
AccessRights : {ExtendedRight}
ExtendedRights : {ms-Exch-SMTP-Accept-Any-Sender}
ChildObjectTypes :
InheritedObjectType :
Properties :
Deny : False
InheritanceType : All
User : NT AUTHORITY\ANONYMOUS LOGON
Identity : Ex2007HT\Default Ex2007HT
IsInherited : False
IsValid : True
 

PSComputerName : Ex2010HT.corp.com
RunspaceId : d402fc47-4e1d-4e56-85ef-acb28a5257ce
AccessRights : {ExtendedRight}
ExtendedRights : {ms-Exch-SMTP-Accept-Any-Recipient}
ChildObjectTypes :
InheritedObjectType :
Properties :
Deny : False
InheritanceType : All
User : NT AUTHORITY\ANONYMOUS LOGON
Identity : Ex2007HT\Default Ex2007HT
IsInherited : False
IsValid : True
 

PSComputerName : Ex2010HT.corp.com
RunspaceId : d402fc47-4e1d-4e56-85ef-acb28a5257ce
AccessRights : {ExtendedRight}
ExtendedRights : {ms-Exch-SMTP-Accept-Any-Sender}
ChildObjectTypes :
InheritedObjectType :
Properties :
Deny : False
InheritanceType : All
User : NT AUTHORITY\ANONYMOUS LOGON
Identity : Ex2010HT\Default Ex2010HT
IsInherited : False
IsValid : True

The results above list 2 entries for the 2007 Hub Transport, but only 1 entry for the 2010 Hub Transport. Anonymous is missing for the ability to send to any recipient. The following command will add the permission for that Receive Connector:

Get-ReceiveConnector “Ex2010HT\Default Ex2010HT” | Add-ADPermission -User “NT AUTHORITY\ANONYMOUS LOGON” -ExtendedRights “ms-Exch-SMTP-Accept-Any-Recipient” 

You should see the following results:

Identity                                User                                                   Deny     Inherited
——–                                   —-                                                     —-         ———
Ex2010HT\Default …     NT AUTHORITY\ANON…        False     False 

Now when running the first command to view the Receive Connectors permissions, this entry is now listed in addition to the original three:

PSComputerName : Ex2010HT.corp.com
RunspaceId : d402fc47-4e1d-4e56-85ef-acb28a5257ce
AccessRights : {ExtendedRight}
ExtendedRights : {ms-Exch-SMTP-Accept-Any-Recipient}
ChildObjectTypes :
InheritedObjectType :
Properties :
Deny : False
InheritanceType : All
User : NT AUTHORITY\ANONYMOUS LOGON
Identity : Ex2010HT\Default Ex2010HT
IsInherited : False
IsValid : True 

Rerunning the test from the Unix host now produces the desired results:

# sendmail -v user@publicdomain.tld
here is another test…
.
user@publicdomain.tld.. Connecting to Ex2010HT.corp.com. via relay…
220 Ex2010HT.corp.com Microsoft ESMTP MAIL Service ready at Wed, 26 Jan 2011 14:03:48 -0500
>>> EHLO fred.corp.com
250-Ex2010HT.corp.com Hello [10.2.2.10]
250-SIZE
250-PIPELINING
250-DSN
250-ENHANCEDSTATUSCODES
250-STARTTLS
250-X-ANONYMOUSTLS
250-AUTH NTLM LOGIN
250-X-EXPS GSSAPI NTLM
250-8BITMIME
250-BINARYMIME
250-CHUNKING
250-XEXCH50
250-XRDST
250 XSHADOW
>>> MAIL From:<user@corp.com> SIZE=24
250 2.1.0 Sender OK
>>> RCPT To:<user@publicdomain.tld >
250 2.1.5 Recipient OK
>>> DATA
354 Start mail input; end with <CRLF>.<CRLF>
>>> .
250 2.6.0 <201101261903.OAA23002@fred.corp.com> [InternalId=113247] Queued mail
for delivery
user@publicdomain.tld … Sent (2.6.0 <201101261903.OAA23002@fred.corp.com> [Int
ernalId=113247] Queued mail for delivery)
Closing connection to Ex2010HT.corp.com.
>>> QUIT
221 2.0.0 Service closing transmission channel
# 

The only other thing I would do differently is to create a new Receive Connector for this relay function to maintain separation from default configuration and clarify of purpose.
I hope this helps someone.

I’m excited about the TONS of enhancements and added features. The Mediation server becomes a part of the Front End, SBA allow branch office survivability, integration of LiveMeeting client into the Communicator Client, now called Lync 2010.

Much more can be discovered on Next Hop or by following Dr. Rez
Some of the upcoming qualified devices can be found HERE

My Exchange Web Services (EWS) weren’t working. I couldn’t get OOF to work for calendar sync on OCS.

There are a few directories and registry changes that were made that I had to remove:
HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Outlook\AutoDiscover

• I deleted the dyntek.com entry that points Autodiscover to a local XML file.
• I changed the above REG_DWORD entries from 1 to 0
• Deleted this key: HKEY_CURRENT_USER\Software\Microsoft\MOCHA
• Deleted the above referenced ‘Sign In’ directory under my profile
• And, of course, deleted the Online Profile it created

Outlook and OCS are now happy!

“Customers running Office Communicator 2007 + Office 2007:

This issue is fixed by applying the hotfix referenced in KB 961752 (http://support.microsoft.com/kb/961752), and although the KB article does not specifcally call out this issue, we are working on both creating a new KB to address this, as well posting this blog entry to increase its visibility.

Customers running Office Communicator 2007 + Office 2003:

Our Office Development Team is moving forward with creating corresponding official hotfix for Office 2003.  Although it’s a bit early to discuss timeframes in terms of when you can expect the public hotfix, we have a private copy of the fixed MSMAPI32.DLL.  If you would like to test this build, please engage Microsoft Customer Support Services via http://support.microsoft.com.  Premier customers: please leverage your Technical Account Manager to initiate the case creation process.“

A very simple installation of OCS 2007: a single standard pool and a single consolidated edge server. They didn’t have a PKI structure and oddly didn’t want one, so we used GoDaddy for the internal certs and Thawte for the public certs. After the implementation, everything seemed to work fine…

…until we tested one of the internal company users trying to make a Communicator call to another company user that was connected from the Internet. The invite was sent and the other client would ring, but the call would not connect. I began to narrow the scope of the failure by running the validation on pool and edge and taking Snooper traces of both servers. There were no errors and only this message in the Snooper trace, “Call terminated on media connectivity failure“, for the reason the call was terminated. As it turns out, inside to inside calls worked, outside to outside calls worked. The part that confused me, and still does to some degree, is that Federated calls succeeded.

Knowing that peer-to-peer calls don’t use the AVMCU, I decided to test LiveMeeting to ensure the MCU was OK…and it was. I was able to get full voice and video from a LiveMeeting hosted from the pool server.

Typically, I will install a consolidated edge with three public IPs on one NIC, an internal IP on a second NIC, and have the default gateway on the external NIC. Most smaller installation don’t have internal firewalls and have the edge installed directly on the internal LAN. I had overlooked the internal NIC configuration in assuming that communication was good to the internal network. It wasn’t until a ping from a workstation failing to the edge that reminded me to check the routing table on the edge server. Sure enough, the ping response was not able to be routed back since there were different subnets between the internal IP of the edge and the internal network. Once I added the internal persistent route, everything worked fine.

In this case the internal network was 192.168.11.0/24 and the internal interface of the edge was 192.168.251.0/24. The other office locations on the MPLS are other 24 bit masks of the 192.168 networks and are all reachable through the 192.168.251.1 gateway address. The funky part of the route add statement is getting the interface ID from the top of an ipconfig command and using the 0x1xxxx number. Lastly, the –p makes the route persistent (i.e.: after a reboot).

Now, back to the Federated call working when the route statement wasn’t there…

It appears that for Federated calls, the AVMCU is utilized. I’m researching that now. Someone please enlighten me.

To do this, create a text (XML) file called MediationServerSvc.exe.config and place it in the location of the MediationServerSvc.exe file. It should be in the ‘C:\Program Files\Microsoft Office Communications Server 2007\Mediation Server’ directory. The contents of this file should be:

Now, you are free to normalize to E.164 without having to worry about your Cisco devices getting confused!

The above text can be copied into notepad and named with a .REG extension and run on non-domain machines not getting the group policy to allow URLs.