Monday, May 22, 2006


Using Trillian

I forgot all about this blog as I moved over to and thus I failed to upload the occasional image. So I posted recently about the removal of Trillian from the Google Pack.

Anyway here is a screen shot of the client with the GuiStyle theme. Notice the transparency (70%). This client also lets you dock to the left or right which is kind of cool.
I collapsed my groups to be sure as not to expose anyone's alias but you can see if I have hotmail, aol, yahoo (pic is a corporate customer through one of those 3 (usually MSN)) and SIP which seems to only work inside and not through the AP (assuming an NTLM problem).

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

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.

Presence and Aggregate Presence

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.

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.

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

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, and a primary SMTP address of 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, 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 (it, in essence, asks, “What is the SIP URI for the user who has as one of their proxy addresses?”). From there, the correct request is made to the LCS server (“Show me presence for”), 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 would yield no data (or a negative response from the server).


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. -
3) The domain in the sip-uri (e.g. 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: 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.
"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.
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
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

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 - would be accepted as it was a certificate for

Hope this helps.
toml lcs kid

Monday, October 04, 2004


LCS 2003 - Certificates

LCS 2003 - Certificates
* For those looking for LCS 2005 data, information will be documented and does vary slightly due to the use of a pools (collection of Home Servers), which will require the use of SUBJECT_ALT_NAME

One of the main calls received for Live Communications Server is around the topic of Certificates. It is recommended for customers to deploy LCS and Windows Messenger 5 (WM5) using TLS which is certificate based.
What we will discuss here is the part that if you get right, the client connections fall into place: Server to Server communications using (required) a Mutual TLS (MTLS) connection. Mutual TLS is used as the servers can be the "client" or "server" depending on which establishes/calls/initiates the connection to the other. This requires a certificate with Client Authentication and Server Authentication.

The challenge for customers is how to get the actual certificate they need. You can use a 3rd party like Verisign or you can use the Windows Certificate Authority. If you have to ask for the certificate you need:
1) X.509c3 version certificate
2) Enhanced Key Usage field for client and server authentication
3) The FQDN for which this server will respond (this may not always be the actual FQDN so read further)

We will be focusing on the Windows Certificate Authority configuration and I want to point out those things that can surprise you if don't read up on it first, like myself :)

I am NOT endorsing one CA type over another. Two references you can consider: The MSPRESS book for Windows 2003 PKI and Certificate Security and from MSDN -

There are two main types of Certificate Authorities - Standalone and Enterprise Root CA (not going to talk about subordinate CA's). Let me suggest running adminpak.msi to install the admin tools and then run pkmgmt.msc for the Public Key Management MMC.

The Standalone CA does not use templates the way the Enterprise Root CA does. There is a flexibility in the Standalone as I can request a type of Other: allowing me to type the OID values for what authentications I need -
- using the web enrollment page (http:///certsrv/)
- Request a certificate -> advanced certificate request -> Create and submit a request to this CA
- Fill out the certificate name (should be fqdn of the lcs server). For certificate type, select “Other …” from the dropdown menu, and input “,” in the “OID” textbox (note that there’s a comma between the two oids and NO space(s)). Check “Store certificate in the local computer certificate store” checkbox. Leave everything else as is. Click “Submit”.
- You’ll see a page telling you the certificate request ID number and that it’s now pending admin’s approval.
- Go back to the certificate server, open CertificateAuthority’s mmc, right-click “Pending Requests”, you’ll see the certificate request from the client. Right-click it (based on request ID) and choose “All Tasks -> Issue”.
- Go back to the client machine, open the web enrollment page as in step 2) above, click “View the status of a pending certificate request”, click the certificate and install it.
- On the web enrollment page on the client machine, download the RootCA and install it on the client machine. Note that by default it’ll be installed in the current user store. So to get it installed on the Local Machine store, in downloading CA you need to choose “Save” instead of “Open”, and specify a file name for it. Then open the certificate mmc, Local Computer/RootCA store, import the root CA from the file.

For the Enterprise Root CA, open PKMGMT.MSC and in the Template location highlight the Computer certificate, right click and choose duplicate.
HUGE NOTE: This will not work on Windows 2000 Advance Server or Windows 2003 Standard Edition. You will need Windows 2003 Enterprise or Datacenter as they support V2 templates. For the Windows 2000 AS and 2003 Standard customer your choices include using the Domain Controller cert as it has both Client and Server authentication, an upgrade to 2003 Enterprise, or 3rd party cert (Verisign, Thawte, other).
Any name will work, some suggestions would be MTLS or LCS or Client Server Auth.
Additional items to select -
Request handling Tab click on Allow private key to be exported
Subject Name Tab click on Supply in the request.
When selecting a certificate in this manner you should be prompted to download it after completing the request. If not you will need to look into the enrollment privileges.

The last piece of help I would offer is that customers occassionaly report that when selecting the certificate in the LCS UI for the MTLS definition they receive an error - implying the wrong certificate selected or a certificate missing key details or the certificate isn't showing. When receiving an error thus far it details the exact problem which can be resolved by going through the process of requesting a new certificate with the missing detail. For a certificate that does not show, it likely was not imported into the correct location. Above it is stated to select the ooption for Store certificate in local computer certificate store. Also if it failed the first time go ahead and save it the second time so you can open the Certicate MMC for local computer and by selecting Personal and Certificates you can import and browse to the certificate location.

I hope that this has been helpful. Incorrect, misleading, or incomplete information? please comment the post.

Toml LCS Kid


Live Communications Server (introduction)

Why view/read this blog?

I provide support for Live Communications Server and will use this as a place to put lessons learned while playing with the product, trying various configurations and also those lessons learned from the customers who call.

I am by no means an expert in SIP/SIMPLE so for those that are also in that boat, you can learn as I do. So RFC 3261 will be the base, but I find you never know something until you have been tested and challenged by an issue that forces you to dig deep.

I would hope to post something at least once a week so that this doesn't go stale but also that it isn't too much so it becomes overwhelming.


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