Tuesday, November 30, 2004

 

Blog moving...

I created this blog as a test and also to try and resolve some problems with our company site.
They have been resolved and the new postings will be at

http://blogs.msdn.com/toml

Thanks
Toml LCS Kid

Friday, November 19, 2004

 

LCS Presence - Aggregate behavior vs Exchange IM

This is an issue one of my team mates Kevin shared with me about the new Aggregate Presence behavior in LCS vs. Exchange IM. For those customers who have used Exchange IM with WM 4.6, 4.7, 5.0 you may have noticed that when you sign in to multiple machines any text IM will be delivered to all end points. Kind of a broadcast approach.

When moving to LCS and using WM5 you may have had someone report that you never replied to their message. Below is a customer reported problem about this.

Reported Problem:
Customer using Windows Messenger from Home, leaves for work but does not recieve any instant messages. Upon returning home the IM client still signed in to had the messages.

Actual Problem:
In Exchange messaging, if a user was logged into two places, a message sent to him would go to both places.In LCS, it only goes to one.

Cause:
Presence and Aggregate Presence
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/rtcsrv/rtc/registrarendpoint.asp

Resolution:
To prevent this, on the machine at home lock the machine or sign-out of IM when finished using it to prevent the buildup of aggregate presence.

Cheers!
toml lcs kid

 

LCS - Messenger through a firewall (TCP or TLS)

Customers using Windows Messenger to connect through a firewall will find this post informative. Please be advised that it is written based on a customer issue with WM5 and LCS 2003.

The issue below was a real customer issue and has a symptom that not all will experience, more likely they will fail to sign-in at all. I am posting this as is because it was a rather good problem summary report.

Reported Problem:
Users could not connect to Live Communications Server with 6 or more contacts in the list. They would receive the error: Signing in to SIP communications service failed because the service is temporarily unavailable. Please try again later.

Actual Problem:
The number of contacts was not the issue but the client server attempting to establish a secondary connection (ephemeral port range above 1024) through a firewall. The firewall saw the particular port range which was defined to be traffic type to disallow.

Recommendation:
TLS
TCP is not secure

Information for TCP implementation (info is aggregation of all who were involved with issue)
Windows Messenger and Live Communication Server will use a secondary connection and this can be controlled through group policy. If the server is listening on TCP, then the client will use a dynamic (source) port on the client, connecting to the (target) 5060. At the same time the client may specify a dynamic port in the registration Contact header indicating its listening port. Consequently server has no choice but to connect back to this port since SIP requires in-dialog messages to be delivered to the location specified in the Contact header. The firewall MUST allow this port for SIP/TCP logons to work, and hence the group policy applies to this port in particular. The server's source port for outbound connections is picked by WinSock and ranges between 1024-5000. Again this connection is only for SIP traffic.
Additionally, size of a message has no impact on whether the server opens a new connection or not – As mentioned above, the server opens a new connection if the Contact header in the registration requires it to.

Specify dynamic port ranges
Disabled
By default, the client application (for example Windows Messenger) will use a randomly selected port between 1024 and 65535 for SIP signaling and media traffic. When enabled, it allows for specifying the minimum and maximum port addresses used for dynamic port allocation. Default is 7100 minimum and 7103 maximum for SIP traffic; 5350 minimum and 5353 maximum for media.

The port range is configured by the system administrator. The values for the port ranges can be set in the registry under the registry key HKLM\Software\Policies\Microsoft\Windows\RTC\PortRange.
The ‘MinSipDynamicPort’ and ‘MaxSipDynamicPort’ values are used for setting the port range for SIP signaling traffic.
The ‘MinMediaPort’ and ‘MaxMediaPort’ values under the above registry keys are used for setting the port range for Audio/Video RTP and RTCP traffic.

No matter the communication is TLS or TCP, if the clients want to do file transfer, A/V, communication, they will negotiate a set of dynamic ports to use for the file transfer or RTP. These will be dynamic on both sides of the communication.

We can use registry setting to limit the range of dynamic port the client software use for communication, but we can’t really control exactly which port to use.

Source port is not a security concern. We know the server only listens to port 5061 (or other selected port) if we use TLS connection. If one is really concern about security, they can actually close all ports except port 5061 and IM will still work. (That is assuming they have other NIC/access to the server for administration and necessary infrastructure access.)
We can limit the client range of dynamic ports for A/V file communication.
If there is any firewall between/in front of the client, it can effective block all dynamic ports traffic, so dynamic port will not be an issue. TLS IM will still work, only advance communication fail.


Monday, November 15, 2004

 

LCS Presence - Outlook, Sharepoint, etc.

Seeing a users presence with other Office applications such as Outlook and Sharepoint.

Quickly let me say that you need Exchange 2003 and Office 2003 for this functionality.
Also the biggest issue we see is customers who have different e-mail and sip-uri aliases. Sharepoint only supports a contact alias and it labels it e-mail. So if they are different you will never see presence information for that user.
834471 A Live Communications Server user's presence information does not appear http://support.microsoft.com/?id=834471


Problem Description
Contacts on a Windows Sharepoint Service page will not correctly reflect presence as shown in Windows Messenger 5.0 or Outlook 2003.
The quick answer to this is almost always that the SIP-URI and Email address are different. Either make them the same or enter two accounts in the Sharepoint site one with each address.

More Information
How does Outlook 2003 lookup presence information?
How does SharePoint lookup presence information?
Outlook is able to resolve SIP addresses via the proxyAddresses attribute in Active Directory (the contents of which are listed on the “Email Addresses” tab of the user object). If a user is mail or mailbox enabled prior to being enabled for LCS, the code which takes care of the LCS provisioning automatically adds a SIP address for the user on the “Email Addresses tab” (i.e. it adds a value to the proxyAddresses attribute of the user).

For example a user is created with a SIP URI of sip:user1@company.com, and a primary SMTP address of user1@exchange.company.com which is different than the SIP URI.

So, for Outlook 2003: when Lori, for example, receives an email from User1, that email will show a FROM: address of user1@exchange.company.com, which is NOT the same as the SIP URI. Outlook, however, is smart enough to initiate a lookup of the proxyAddresses attribute thereby ‘resolving’ to the true SIP URI which is user1@company.com (it, in essence, asks, “What is the SIP URI for the user who has user1@exchange.company.com as one of their proxy addresses?”). From there, the correct request is made to the LCS server (“Show me presence for sip:user1@company.com”), and Lori is able to view User1’s status.

SharePoint is not as forgiving in this functionality. SharePoint will only initiate a lookup for , the result in the above scenario effectively being that if Lori were trying to view User1’s presence information via a SharePoint webpart, she would be unable to do so since – again – the SIP address is different from the SMTP address and a query for sip:user1@exchange.company.com would yield no data (or a negative response from the server).

Resolution:
[HKEY_CURRENT_USER\Software\Microsoft\Office\11.0\Common\PersonaMenu]
"QueryServiceForStatus"=dword:00000002

This registry key is used to customize the new Person Name Smart Tag Menu which is currently not documented. The Person Name Smart Tag and its associated menu is a new feature in Office 11. The Person Name Smart Tag menu is highly customizable but requires further documentation for administrators.

The registry values determine how we treat retrieval of online status for people who are not on a user’s Messenger contact list.
· When the value is set to 0, we only receive status for people that are on the contact list; we do not request information about others.
· When the value is set to 1, we request status from Exchange IM service for people that are not necessarily in person’s contact list.
· When the value is set to 2, we request status from RTC service for people that are not necessarily in person’s contact list.

It is not possible to have this key set so that we request non-buddy status for both Exchange IM service and RTC IM service at the same time. Also note that .NET Messenger using passport accounts inherently disallow querying non-buddies for status.

They will NOT be able to see presence information in WSS for anyone who is not on their contact list unless
1 The QueryServiceForStatus registry key is set and
2 The SIP URI is identical to the SMTP e-mail address

toml lcs kid

Monday, November 08, 2004

 

LCS and Windows Messenger 5 connectivity

LCS 2003 & Windows Messenger 5 Connectivity
Overall the behavior below is applicable for LCS 2005 but given the new feature of Pools there may be some slight/subtle difference, so for now this is about 2003 and I will edit at a later time with 2005 applicable changes (if any).

When establishing connectivity for Windows Messenger 5 (WM5) to LCS for the first time, the following items need to be checked.
1) The user has been enabled, given a SIP-URI and homed on a server.
2) The user sip-uri (e.g. - toml@microsoft.com)
3) The domain in the sip-uri (e.g. -microsoft.com) is listed in LCS. For 2003 you would look on the domain tab under Users Services Global Settings For 2005 you would look at the properties of the Forest
NOTE: Please keep in mind that the domain used for LCS and WM5 does not need to match your Active Directory or DNS namespace. I like to use the example of toml@fuzzybunny.local. It is just an attribute that has to be set and the environment supports. While it does not have to match the DNS namespace, users of Autoconfiguration (discussed below) will have some further considerations.
4) The LCS server is configured to accept connections on TCP and/or TLS.
5) WM5 users in the domain can provide credentials using NTLM: DOMAIN\Toml or Kerberos: toml@domain.com. Again note that this does not have to match my sip-uri. NOTE: For WM5 clients in a workgroup, if the LCS server is configured for both Kerberos and NTLM when the client connects the server will present both options. If the WM5 client is passing the Kerberos style credentials we will attempt to logon using Kerberos as it is more secure but fail as we are in a workgroup. If we try Kerberos and fail we will not try NTLM as we won't try a less secure method. The solution, in this configuration, is to alter the logon credentials to use the NTLM style.

WM5 using TCP
1) Configure the client under Tools, Options, Accounts, Advanced to use TCP as a protocol and use the IP address of the LCS server. This eliminates name resolution problems and also validates connectivity without the overhead of TLS and certificates. If this fails to connect you need to double check all the items above.
Next you will want to change the settings to use the FQDN of the LCS server to test name resolution. If any of this fails, you can enable client side logging by changing the registry keys in the following location.
[HKEY_CURRENT_USER\Software\Microsoft\Tracing\RTCDLL]
"EnableFileTracing"=dword:1
"FileDirectory"= C:You have to EXIT the WM5 client, and when you restart a file with the name RTCDLL*.log

WM5 using TLS
1) The LCS server needs to have requested a certificate for the FQDN of the machine and also the trusted root authority. See my other posting about LCS 2003 and Certificates. http://tomllcskid.blogspot.com/2004/10/lcs-2003-certificates.html
2) LCS needs to be configured for TLS with the above certificate. Any errors here, refer to the url in step 1.
3) You have to have the trusted root authority certificate on the client
4) You have to configure WM5 for TLS and the name must be the same as the name on the certificate used by the LCS server. While there are situations in which it would not be the actual FQDN those are typically one-off situations and if you are doing that you probably don't need much of this info
If the client connection fails you want to refer to the above client side logging information. I also recommend to customers trying to use the IP address with TLS as this will almost always help give a certificate error which can help prove a connection is being established.

WM5 using Autoconfiguration
Autoconfiguration is where DNS and your sip-uri start to matter, so pay attention
WM5 using Autoconfiguration will make the following DNS queries when trying to connect and sign-in. We will use the example of toml@microsoft.com
_sip._tcp.microsoft.com
_sip._tls.microsoft.com
sip.microsoft.com
Notice that the above queries are based on the domain portion of my sip-uri. So for customers that do use a sip-uri that does not match their DNS namespace just have to make sure that they can make an authoritative zone for the namespace. For my wacky example toml@fuzzybunny.local you or your ISP would now need to configure a zone for this. Keep in mind that you only need to create a service record and that the HOST record it refers to could be in another domain (_sip._tls.fuzzybunny.local could refer to HOST lcsserver1.microsoft.com)

For customers who have the WM5 client configured for High Security Mode you will need one other registry key change, or change Group Policy (rtclient.adm is on product CD and called Allow Additional DNS Names)
1. Start, Run, Regedit, navigate to HKLM\Software\Policies\Microsoft
2. Under Microsoft create the following key: Messenger
3. Under the new Messenger key create the following key: Client
4. Under the new Client key create the following key: {83D4679F-B6D7-11D2-BF36-00C04FB90A03}
NOTE: that the {} are required in the key with the GUID (Globally Unique Identifier).
5. Under the new GUID key above create the following key: _Default
6. Create a new DWORD value: DisableStrictDNSNaming Set the value data to 1
7. Sign out and exit Windows Messenger
The reason for this key is that in High Security Mode the client is expecting to recieve a certificate for SIP.DOMAIN.COM which you likely did not name the server and get a certificate for. Enabling the group policy or registry value sets the client to ignore the Host name, in fact it will also ignore child domains - bogus.sales.domain.com would be accepted as it was a certificate for domain.com

Hope this helps.
toml lcs kid




This page is powered by Blogger. Isn't yours?