LinkedIn Connector for 64-bit Outlook

It took me a bit to find this, for some reason…

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

Maintaining SMTP Relay in Exchange 2010 Migration

During a recent Exchange 2007 to Exchange 2010 migration I discovered that an internal Unix box wasn’t able to send mail through the new Hub Transport. Here is the test and responses seen from that host:

 
 

# sendmail -v user@publicdomain.tld this is a test . user@publicdomain.tld… Connecting to Ex2007HT.corp.com. via relay… 220 Ex2007HT.corp.com Microsoft ESMTP MAIL Service ready at Fri, 21 Jan 2011 11:03:09 -0500 >>> EHLO fred.corp.com 250-Ex2007HT.corp.com Hello [10.2.2.10] 250-SIZE 250-PIPELINING 250-DSN 250-ENHANCEDSTATUSCODES 250-X-ANONYMOUSTLS 250-AUTH NTLM LOGIN 250-X-EXPS GSSAPI NTLM 250-8BITMIME 250-BINARYMIME 250-CHUNKING 250-XEXCH50 250 XRDST >>> MAIL From:<user@corp.com> SIZE=15 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 <201101211603.LAA09969@fred.corp.com> Queued mail for delivery user@publicdomain.tld… Sent (2.6.0 <201101211603.LAA09969@fred.corp.com> Queu ed mail for delivery) Closing connection to Ex2007HT.corp.com. >>> QUIT

# sendmail -v user@publicdomain.tld this is a test . user@publicdomain.tld… Connecting to Ex2010HT.corp.com. via relay… 220 Ex2010HT.corp.com Microsoft ESMTP MAIL Service ready at Fri, 21 Jan 2011 11:05:36 -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 250-X-EXPS GSSAPI NTLM 250-8BITMIME 250-BINARYMIME 250-CHUNKING 250-XEXCH50 250-XRDST 250 XSHADOW >>> MAIL From:<user@corp.com> SIZE=15 250 2.1.0 Sender OK >>> RCPT To:<user@publicdomain.tld> 550 5.7.1 Unable to relay user@publicdomain.tld… User unknown >>> RSET 250 2.0.0 Resetting

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.

Microsoft Lync

Microsoft has released the new name of OCS Wave14 and the Release Candidate bits to TechNet. Microsoft Lync is “a combination of “link” and “sync” – is about connecting people in new ways, anytime, anywhere.” as described by Kirk Gregersen on the UC Group Team Blog HERE.

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

BPOS SSO Client Changing Autodiscover

I’ve finally taken some time today during lunch to fix an issue I created for myself. I installed the SSO client and had it install everything, including creating an Outlook profile for Online Exchange. When I realized I clicked ‘next’ too quickly, I uninstalled everything, but then it was too late. I was simply going to use the SSO features for SharePoint, but was in too much of a hurry to get it installed… which created a learning experience!

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!

Communicator 2007 hangs on shutdown/logoff – FIXED!

I love reading Scott’s blog. I love troubleshooting, but he takes it to a new level…
http://blogs.msdn.com/scottos/archive/2009/03/20/office-communicator-2007-hangs-on-shutdown-logoff-fixed.aspx

“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.“

msRTCSIP-UserDomainList

I’ve recently used the MigrateOcsGlobalSettings VBS script to move the RTC Service schema entries from the System partition to the Configuration partition in preparation for an R2 installation. I wasn’t familiar with the msRTCSIP-UserDomainList attribute needing to be set. Where there are users, there needs to be an entry in this attribute. The CN=Configuration,DC=domain,DC=local and any other DNs of domains where users exist need to be populated here. On a fresh installation, I understand this to be unnecessary.

Microsoft Certified Master training for OCS

Wow! I am honored and humbled to be attending the next rotation of the Microsoft Certified Master training program. I’m sure that I will be even more humbled once I get there. It will be an intense 3 weeks away from the family. It will also be an extremely rewarding experience. I’ll be sure to blog updates during my visit toward the end of April.

Always Check the Routing

I just finished troubleshooting a problem that I should have solved sooner than I did!

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.

route add 192.168.0.0 mask 255.255.0.0 192.168.251.1 if 0×10003 -p

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.

Automatically Strip + on Mediation Server

It might be useful in a Cisco direct SIP environment to automatically strip the + from all outgoing SIP communication from an OCS Mediation server.

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:

<?xml version=”1.0″ encoding=”utf-8″ ?> <configuration> <appSettings> <add key=”RemovePlusFromRequestURI” value=”Yes”/> </appSettings> </configuration>

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

Enable URLs in Communicator

Just a quick note for machines not a member of the domain that want to participate in URL send/receive in the Communicator 2007 client. You will need the following registry setting to enable clickable URLS…

Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Communicator] “EnableURL”=dword:00000001

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.