Skip to content
blue pawn

Live Messenger/MSN Messenger doesn’t connect on Vista behind a SonicWall TZ170

Sometimes you run into a problem that’s really just too much to figure out.  It involves multiple groups, multiple vendors, and multiple headaches.  One of my recent challenges has been getting Live Messenger to work from Vista.

I built a new Vista Ultimate machine with the x64 release bits.  Everything was fine until I realized that none of my MSN messenger buddies ever appeared like they were online.  I dug a little and realized that I could login from the Windows XP system sitting next to me but Vista wouldn’t work  I’d get an error during the sign in process.  I opened a support case with SonicWall who told me that it was a Microsoft Windows problem – and oh by the way, they don’t support Vista yet.  They were seeing a TCP ReSeT from the client.  It was a client problem.

I travel out to Redmond, WA on business and guess what … my MSN contacts work fine from the vista box.  Now I’m really confused.  It works when the system is remote but not when it’s on my network.

I’m already frustrated as I try to understand why for firewall functionality the client OS mattered – however, I opened a case with Microsoft.  After fighting to get the issue landed in the Vista Networking queue instead of the MSN queue… we started working on the resolution.

The net of it – after dozens of hours wasted – was that I updated my SonicWall to the latest firmware (3.2.0.3-54e).  I then went in and UNCHECKED the option under Firewall-Advanced labeled  ‘Enable support for Windows Messenger’.  That’s right, I turned it off.  Unchecked it.  Said, I don’t want it.

Live Messenger fired up immediate on the Vista Machine.

Arg.  It should have been easier than this.

Special thanks to my friends in Microsoft PSS who stayed with me to help find the resolution.

[Keywords: Sonicwall, Windows Live Messenger, Error 81000306, Sudden disconnect Added 06-12-20]

 

Article: Open-Eyed Offshored Development

In the United States there is an array of responses when you mention the word offshoring.

Offshoring is the process where by less expensive resources are sought out from a different geography. It’s not a new concept. The industry has seen both successes and failures in the implementations of outsourcing. For some it creates solutions, and for others it creates headaches.

There is no one formula for success; however, there are a few key approaches that you can take to improve you odds for a successful implementation of outsourcing.

http://www.developer.com/design/article.php/3646336

InvalidOperationException “The event receiver context for Workflow is invalid” Problems with onTaskChanged in a SharePoint Workflow

If you’re dropping a onTaskChanged activity and you’re finding an event in the ULS like the following …

11/30/2006 08:56:04.12  OWSTIMER.EXE (0x05D4)                    0x0B48 Windows SharePoint Services    Workflow Infrastructure        72er Medium   System.InvalidOperationException: The event receiver context for Workflow is invalid.     at Microsoft.SharePoint.SPEventReceiverDefinition.ValidContext()     at Microsoft.SharePoint.SPEventReceiverDefinition.ValidReceiverFields()     at Microsoft.SharePoint.SPEventReceiverDefinition.GetSqlCommandToAddEventReceivers(IList`1 erds)     at Microsoft.SharePoint.Workflow.SPWinOESubscriptionService.CommitNewSubscriptions(Transaction txn, IList`1 erds)

The problem may no with the event receiver, rather that in the CreateTask activity you didn’t associate properties for TaskID, TaskProperties, or CorrelationToken.  Thus there’s no context for the event to call back to.