Welcome to TechNet Blogs Sign in | Join | Help

Please note very carefully that this is an issue for clients that can sign-in to the MSN and AOL services. This could possibly impact those customers running Windows Messenger 5.1 or Mac Messenger which both support multiple "stacks" or services.

http://www.techweb.com/showArticle.jhtml?articleID=181501620

This is one reason we inform customers of the PIC capabilities of LCS Server with Office Communicator.

TomL LCS Kid

Last week (Feb 20-24) we ran into a few problems with 2 of the three partners - MSN and Yahoo!, I will give the details I can of them as well as request some input from you about improvements.

Background - all PIC issues, that is communication to and from a corporate domain to any of the 3 clouds always come to Microsoft support first. The reason is to be sure that it is not something with the customer LCS deployment or configuration and to also buffer the 3 partners from getting questions they are not able to provide support for.

Last week we had MSN be impacted by a change of names by the Root Certificate Authority. So for anyone who had a certificate from Equifax they had to get a new Certificate and Certificate Chain. For anyone that communicates to a site with that authority you would need the new certificate chain also. Any workstation or server with the ability to get to Windows update is ok, but that Access Proxy is in a DMZ usually and only requires 5061 for connections and thus would not get the updated certificate. One of the other partners had this same problem but at the moment of typing I can't remember who.

There was also an upgrade to the MSN Address Book environment which created the problem I mentioned in the Provisioning post - unable to add user to address book. So anyone who tried to add user@domain.com from an MSN client would get that error, however they could still have an IM conversation. This was researched and resolved Thursday night, Friday morning. While I have not been provided root cause I am aware that there was an upgrade to the Address Book environment so we knew what the "last change" was we always customers!

On the Yahoo! side we had lots of reports from customers that were not seeing presence changes or incorrect presence. While there is report that on Friday this was resolved we are still investigating the issue for a few customers still reporting problems. Again I do not have root cause but what I do know is that some additional servers were added to the environment but not added to the list of servers (see even the best of us can forget all the steps necessary) and there was also a value for the subscription time out that was configured for a very high setting.

So, during this time we were sort of scrambling to realize this was happening (more customers calling and reporting) and to try and report them correctly. We obviously don't have the best process for alerting everyone to a situation like this and we are discussing this now. Your ideas would be welcomed.

Tom LCS Kid

I realize it is a technical blog but for a bit of personalization I changed the theme temporarily for my daughter Sophia's 4th birthday. Not like she is monitoring my site :)

NetMeeting FAQ -

 

Information current as of October 4, 2005

 

Q: Will NetMeeting ship in Windows Vista?

A: No.  Microsoft is not developing new versions of the NetMeeting feature and NetMeeting will not ship as part of the next major OS release, Windows Vista.

 

Q: Has Microsoft stopped shipping NetMeeting?

A: NetMeeting shipped as part of Windows XP and Windows Server 2003. NetMeeting has not been shipped as an independent feature since 2000 (when it became part of Windows 2000).  There will be no future versions of NetMeeting and Microsoft does not recommend that customers invest in new deployments of NetMeeting.

 

Microsoft’s real-time collaboration strategy is built using the foundational elements of Office Live Communications Server, Office Communicator, and Office Live Meeting which represent elements of Microsoft’s real-time collaboration platform.

 

The Real-Time Collaboration group is committed to building and shipping new products based on customer feedback and market requirements. To meet the recent industry changes and requirements meant that it was not practical to continue to build on NetMeeting (which was first introduced in 1996) but to focus on an industry standard protocol SIP.

 

Q: Why has Microsoft stopped supporting NetMeeting?

A: NetMeeting is part of Windows 2000, Windows XP and Windows Server 2003 and is still supported. In May, 2004 Microsoft announced extensions to its product support lifecycle and these extended benefits will apply to the NetMeeting feature of Windows XP.  For more information regarding this May 2004announcement please see the following article.

 

Q: When is NetMeeting support ending?

A: According to Microsoft’s May 2004 announced extension of product support, NetMeeting, as part of the Windows XP OS, will be supported for free, until two years after Windows Vista ships, and then will have 5 year’s paid support. NetMeeting on Windows 2000 will be supported until 2005 for free and until 2010 as paid support. NetMeeting on Windows Server 2003 will be supported until 2008 for free and until 2013 as paid support.

For more information regarding this May 2004 announcement please see the following article.

 

Q: What about security?

A: Security is the top priority for Microsoft. Microsoft will continue to deliver hotfixes to resolve security issues in NetMeeting as required.

 

Q: How have customers been using NetMeeting?

A: Most customers have told Microsoft that they use NetMeeting for Remote Assistance in help desk scenarios, Application Sharing in small ad-hoc collaboration scenarios and at times for basic PC to PC based voice and video.  All of these tasks can be more efficiently performed by utilizing Office Live Communications Server 2005, Office Communicator, and Office Live Meeting.

 

Q: What is the future strategy for the customer scenarios where NetMeeting is commonly used today?

A:  In most cases the scenarios where NetMeeting is used today are delivered by real-time collaboration products like, Office Live Communications Server, Office Communicator, and Office Live Meeting.  The Real-Time Collaboration group is committed to building and shipping new products based on custom feedback and market requirements and will continue to do so in the future. 

 

Q: My development team is thinking about using NetMeeting as an element of a new collaboration solution- what should I recommend?

A: There will be no future versions of NetMeeting and Microsoft does not recommend that customers invest in new deployments of NetMeeting. Microsoft’s real-time collaboration strategy is built using the foundational elements of Office Live Communications Server, Office Communicator, and Office Live Meeting which represent elements of Microsoft’s real-time collaboration platform.

 

Q: What is the future for NetMeeting?

A: NetMeeting will be supported as part of Windows 2000, Windows XP and Windows Server 2003. There will be no future versions of NetMeeting and Microsoft does not recommend that customers invest in new deployments of NetMeeting. Microsoft’s real-time collaboration strategy is built using the foundational elements of Office Live Communications Server and Office Live Meeting which represent elements of Microsoft’s real-time collaboration platform.  NetMeeting will not be compatible with Microsoft’s next major OS release, Windows Vista.

 

Q: Will NetMeeting continue to be integrated with Microsoft Office programs once I move to Windows Vista?

A: No, this functionality will not be supported in Windows Vista.  Microsoft’s recommendation is to utilize Office Live Communications Server 2005, Office Communicator and/or Office Live Meeting to collaborate in Microsoft Office programs when deployed on the Windows Vista operating system.

 

Q: Will third party developed applications written for NetMeeting API’s work in Windows Vista?

A: No, NetMeeting API’s will not work within Windows Vista and Microsoft does not recommend that customers invest in new applications or developments using NetMeeting.  Instead Microsoft recommends that developers focus their new efforts on Microsoft‘s long-term real-time collaboration solutions Office Live Communications Server 2005, Office Communicator and Office Live Meeting

 

Q: My business runs applications that were written on the NetMeeting APIs.  Once we deploy Windows Vista, how do you recommend we proceed?

A: Microsoft recommends that businesses communicate with their users that certain applications may run differently once Windows Vista is deployed, and that NetMeeting is not a component of Vista and will no longer be accessible – this includes via third party applications. Therefore, Microsoft encourages developers focus their new efforts on Microsoft‘s long-term real-time collaboration solutions Office Live Communications Server 2005, Office Communicator and Office Live Meeting

 

 

Q: I need backward compatibility from Microsoft Windows Vista users to Microsoft Windows XP users that are using NetMeeting.  How can that be done?

A:  Since NetMeeting is not compatible with Microsoft Windows Vista, there is no backward compatibility with Windows XP.  Microsoft encourages customers to leverage Office Live Meeting in order to collaborate and hold meetings with users needing backward compatibility and businesses that may have deployments of both operating systems within their network environment

 

Q: What common scenarios did NetMeeting not address?

A: NetMeeting is not a presence based IM solution, this is a scenario addressed by Live Communications Server. NetMeeting does not work well across firewalls, in cases where this is a requirement Live Meeting is the recommended solution. Both LCS and LM represent significant advancements in ease of use (for both end users and administrators) over NetMeeting.

 

Q: What is the roadmap developers using NetMeeting?

A: While NetMeeting remains part of Windows 2000, Windows XP, and Windows Server 2003 and will be supported in accordance with Microsoft’s standard support cycle, Microsoft recommends that developers focus their new application efforts in the Real-Time Collaboration space on Office Live Communications Server, Office Communicator and Office Live Meeting, rather than NetMeeting. NetMeeting will not be compatible with Microsoft’s next major OS release, Windows Vista.

 

Q: What about Microsoft’s use of NetMeeting as a platform?

A: Certain elements of Microsoft’s current real-time collaboration products use NetMeeting components e.g. the T.120 application sharing in Windows Messenger and Microsoft Office Communicator. These linkages will not be retained in the Windows Vista versions of such products. Questions about Windows Vista APIs should be addressed to the Windows team (e.g. Windows Vista)

 

Q: Where can I find more information on Live Communications Server and Live Meeting?

A: The best place for information on Live Communications Server is http://microsoft.com/livecomm and the best place for information on Live Meeting is http://Microsoft.com/livemeeting

 

 

2 Comments
Filed Under:

For those of you in the threat protection arena with IM, this might not be new information, however I thought it good information to share

SYMANTEC TO ACQUIRE IMLOGIC
Integrating Instant Messaging Management Software Gives Symantec the Only Comprehensive Solution for Complete Messaging Security and Archiving
0 Comments
Filed Under:

For those of you that have deployed LCS and are now working on your PIC (Public Internet Connectivity) setup, you may want to know what we will be asking you to provide for a reported problem. We are still working on this information so you might see it change based on input from us and the 3 clouds. Do keep in mind that our troubleshooting of these issues is never real time, meaning we don't get an AOL/MSN/Yahoo! engineer on the phone with us when you call. This will be a fact gathering situation for which we will ensure your LCS setup is configured correctly and confirm that the issue appears to be with the cloud itself.

Please forgive the odd numbering but this site supports very limited formatting. Likely some custom html might solve it but I admit to being a novice.

  1. Description of problem.  Please be specific with the description and, if applicable, list a step by step repro of the problem
  2. Has it ever worked?
  3. If it was working, when did it stop working?
  4. Was there any network, DNS, certificate, or other server configuration change made on the customer's side?
  5. Customer's Business name:
  6. Customer's federated domain(s) (eg. sample.com):
  7. FQDN of customer's Access Proxy (eg. Access Proxy.sample.com):
  8. Date when federation was enabled for customer:
  9. A contact from customer (name and contact info):
  10. A customer's LCS user email address that we can add to the AOL/MSN/Yahoo! client, for troubleshooting purposes:
  11. If customer's Access Proxy servers are behind firewall:
  • Verify that the Firewall's outbound rules allow tcp/5061 traffic from customer's Access Proxy (tracert) servers to
  • federation.messenger.msn.com 65.54.227.249
  • sip.oscar.aol.com (205.188.153.55)
  • lcsap.msg.yahoo.com (216.155.207.212)
  • Verify that the Firewall’s inbound rules allow tcp/5061 traffic from
  • both federation.messenger.msn.com (65.54.227.249) and MSN Access Proxy servers (IP range 65.54.227.13 through 65.54.227.30) to the IP address of customer's Access Proxy (determined from step 7 above).
  • sip.oscar.aol.com (205.188.153.55)
  • lcsap.msg.yahoo.com (216.155.207.[196-249]
  1. Does federation work with any of the PIC providers (AOL/MSN/Yahoo!)?
  2. Results of LCSDiag (TCP/TLS Connectivity test) or LCSPing (lcsping /s:<fqdn>) from customer's Access Proxy servers [Success or Fail]:
  • federation.messenger.msn.com
  • sip.oscar.aol.com
  • lcsap.msg.yahoo.com
  1. Lcssiplog (Logging tab on server properties level 4) for the reproduced problem from customer's Access Proxy servers. (Remember to force rollover on Logging tab to flush log to disk.
  2. What else has been done to troubleshoot this issue? 

I do hope that this helps you with narrowing the scope of your problem down and possibly identifying the cause of the problem without requiring a call to us.

TOML LCSKid

 

0 Comments
Filed Under:

Now there are many times we have problems adding contacts so please read this carefully as the problem exposes itself for the user of MSN not Office Communicator (Windows Messenger would likely report the same or similar error, I just didn't test as most customers run OC).

Customer may report that when an MSN user attempts to add them to their contact list they receive the popup stating

user@domain.com has added you to his/her contact list.

Do you want:

Allow this person to see when you are online and contact you

Block this person from seeng when youa re online and from contactig you.

Rememember, you can make yoursel appear offline temporarly to everyone at any time

The checkbox for Add this person to my contact list is already selected (by default)

When you select OK (most folks do as they know the person) the following error message pops up:

user@domain.com cannot be addd to the permission list. The account name may be invald, you may have already added the maximum number of entries allowed, or the server may be temporarly unavailable. If the problem persons, contact your system administrator.

The customer reporting this issue had 2 items that could have contributed to this problem, although is seems practical to assume that the first one is the root cause

1) On the LCS 2005 Server in the LCS 2005 Management Console -

  1. Right click on the Forest object and select properties
  2. On the Federation tab - The checkbox for Enable federation and public IM connectivity was not selected.
  3. Select this check box and populate the network address with the FQDN of the LCS Access Proxy.

2) The Office Communicator client was running on the Access Proxy and pointed to the Access Proxy for the server. This is not recommended as the Access Proxy will typically use the same name for the Public and Private interfaces. The client MUST resolve the FQDN to the Public address in order to work correctly. We pointed Office Communicator to the internal LCS 2005 server.

Well that is 4 posts in 1 day, I can't believe it. If we could only have quarterly breaks like this in our year think of all the things we could do <grin>

I hope you enjoyed celebrating Christmas* and I wish you Happy New Year!

TomL LCSKid

* Kristin - Happy Hanukkah

For all of you that want to gather logs and research yourself or you just really like being prepared when you call for support, here is the necessary tracing information for CWA. Keep in mind that if you get errors when the actual client browser launches, you will also want to enable Flat File Logging on the LCS 2005 server. If the client browser does not launch then you are having problems local to the CWA issue.

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Communicator Web Access}

Create a key called Tracing

Create values under Tracing as follows - (no quotes in the names)

"Enabled"=dword:0

"TraceLevel"=dword:4

"FileRootDirectory"string value =""

"TraceUsage"=dword:0 (this is for future use)

Then do the following:

1. Create a temp folder for storing trace files (e.g., C:\CWA\Logs)

2. Enter that path in the "FileRootDirectory" value

3. Change "TraceLevel" to 4

4. Change "Enabled" to 1

The logs should appear in a folder with the name of the application poolunder logs (example - W3SVC729794345, this can be determined by looking in IIS Admin)

The files created will have file names of -

cwa*

s4*   As a note - S4 stands for Scalable SIP SIMPLE Stack

Are you aware of Communicator Web Access?

Do you have non Windows OS systems without IM today (Macintosh, Linux/UNIX, or older Windows clients even)?

Do you have users traveling that use Kiosks to get e-mail?

http://www.microsoft.com/office/livecomm/communicator/webaccess/prodinfo/default.mspx 

Look for another post on tracing entries to help diagnose problems (rather verbose)

TomL LCSKid

The following issue may occur with a customer using the Public Instant Messaging Connectivity (PIC) feature of LCS 2005, enabling federation with MSN, Yahoo and AOL. Once the customer receives email stating that the provisioning process is complete, Yahoo and AOL contacts work correctly in both directions, and internal clients using Office Communicator are able to successfully add MSN contacts and send instant messages to MSN users.

However, MSN users using the Windows Messenger or MSN Messenger clients are not able to add contacts from the LCS PIC federated domain or initiate instant messages with the PIC customer. External users running Office Communicator do not experience this problem.

When attempting to add a new contact to the .NET service client (Windows Messenger or MSN Messenger) the following error is displayed -

  • Using Windows Messenger 5.1

"Operation could not be completed. Your search failed for an unknown reason. Please try again later."

  • Using MSN Messenger

"We cannot update your address book at this time. Please try making this change later."

or

"(sip-uri) could not be added. Please try again later. "

One other way to validate that this is a provisioning issue is to test adding a known good account to the .NET service client and a known bad. The known bad should be some really odd domain name. The one I test with (which someone will undoubtly steal once put here) is Jenny@jennyjenjen.com. Known (or assumed) bad accounts should result in a dialog box stating: jenny@jennyjenjen.com could not be added to your contact list because its owner has not signed up for a Microsoft Passport account. MSN can automatially send this person an e-mail message with information and instructions for installing MSN Messenger, and an option message from you.

So I hope this helps you diagnose just one of the many PIC issues we see. Most issues we get do require a lot of troubleshooting. I will even put a post up for the information we like (hey great idea lcskid)

TomL LCSKid

 

0 Comments
Filed Under:

I was reading through some old documents today and found this table for differing Archive settings. I believe this is one of those things that is really helpful when compliance is needed and you need to know the net result. For the global customer this is even more important as some countries mandate archiving and others mandate no archiving. I suspect that for those customers you are already working with our partners in the Archiving space. For the rest I hope this is helpful. (by the way I don't know how to clean up the formatting as I pasted this from a word doc, I have found that trying to clean that stuff up takes too long and typically is never 100% so forgive the data).

What happens when there is IM between two users having different settings?

 

The following table gives what happens when two users have different settings

 

From User

To User

Result

Never Archive

Always Archive without message body

The message will not be archived.

Always Archive

The message will not be archived.

Use global setting

The message will not be archived.

Federated user

The message will not be archived

Always Archive

Always Archive Without message body

The message will be archived without message body

Never Archive

The message will not be archived.

Use global setting

The message will be archived

Federated user

The message will be archived

Federated User

Never Archive

The message will not be archived

Always archive without body

The message will be archived without message body

Always archive

The message will be archived

Use global setting

The decision will be taken by the default setting for federated users

Use global setting

Never archive

The message will not be archived

Always Archive Without message body

The message will be archived without message body

Always archive

The message will be archived

Federated user

The decision will be taken by the default setting for federated users

Not sure if I will get another post in before end of year so Merry Christmas!

Toml LCS Kid

In its infancy but it has begun, an official RTC blog with product group involvement. http://blogs.technet.com/rtc/ 

I will continue this blog as it represents the support aspect of our product but I expect to help contribute to posts on that site from time to time also. Thanks for your patience and I hope that you provide the feedback to make it a useful site for your day to day work but also to help you receive a better big picture.

TomL LCS Kid

So there is not an official name for the product so I will refer to it as "Budapest" the code name and in a generic term the LCS web server component or solution.

A tool that I was shown very early in this beta and that I have NOT played with at all beyond the first demonstration was LogParser, such a powerful tool it has its own book. What prompted me to write about this? Well I saw this post about top 10 tools, and they mentioned the tool with some syntax http://blogs.technet.com/mscom/archive/2005/10/19/412745.aspx

This is an IIS 6.0 Resource Kit tool and has been updated to 2.2. http://www.microsoft.com/technet/scriptcenter/tools/logparser/default.mspx

There is also The Unofficial Log Parser Support Site - http://www.logparser.com/

I hope that this will become a tool for which I am able to post more about in the future, when our web component or web solution for LCS ships I would love to hear from folks using the tool with real world issues to which they found a solution. This way we can help others as well.

Toml LCS Kid. 

What I post below comes from my teammate Jason, I have been trying to get him to start blogging with me. If you find this information useful send me an email with the subject: GET JASON A BLOG!

 
Windows Messenger 5.0/5.1 (HKEY_CURRENT_USER\Software\Microsoft\Tracing)
==========================================================
To generate a logfile, you must to set the EnableFileTracing registry value =1, exit and restart Windows Messenger
 
RTCDLL        The tracing registry key for the SIP protocol conversation, limited authentication information, 
and DNS queries made by client during automatic configuration
RTCIMSP      The tracing registry key for the Instant Messaging Service Provider. 
UI API calls. Useful when data on the wire looks correct, but information is not correctly displayed within the application 
 
Office Communicator 2005 (HKEY_CURRENT_USER\Software\Microsoft\Tracing)
==========================================================
To generate a logfile, you must to set the EnableFileTracing registry value =1, exit and restart Communicator.
LCAPI            The tracing registry key for the SIP protocol conversation, limited authentication information, 
and DNS queries made by client during automatic configuration. All the lower level SIP traffic is logged to this file.
LCIMSP         The tracing registry key for the IM Service Provider. This contains logging for IM and Presence activities
 
Toml LCS Kid

Simple post, from the team that gives the authoritative answer on supported vs. not supported -  The statement of supported vs. not supported simply means that our test team set this up and ran sufficient tests to say that there are no reported issues. As with any product, this doesn't mean that you couldn't find a bug, it just means we didn't find it first :) 

SQL 2000 SP4 is supported for use with LCS 2005 SP1

 Toml LCS Kid

1 Comments
Filed Under: