Windows Vista/Windows 7 Prompting from Office when Opening Files from SharePoint

This one has been posted elsewhere but I feel like it is worthy of posting again as it is one of those little annoyances.

The Problem
You have Windows Vista/Windows 7 as an OS you have a SharePoint web site (web application for you SharePoint nerds) you access via Integrated Windows authentication (NTLM).  You have the website listed in your Local Intranet Zone in Internet Explorer and when you browse the site from the web browser it automatically logs you in using your windows domain credentials.  So far so good all is working as expected.
Here are the negative symptoms:
  - When you attempt to edit/open a Word, Excel, PPT, etc... file for the first time from the browser you get prompted for authentication even though Word/Excel etc... should automatically log you in.

  - In Windows 7 you attempt to use one of the handy new jump list recent file shortcuts (is that the feature name?) from the task bar for a file from SharePoint and it does not load the application/file.

Solution
    Follow the steps in KB http://support.microsoft.com/kb/943280  to create a registry entry that will allow the web client service (used by Office applications) to pass your credentials to SharePoint for authentication.

It seems there are lots of these little work arounds these days as more security lock downs are affecting SharePoint communications.  They are a necessary evil I just wish that they were publicized better by Microsoft.

Side Note
    Another very frequent issue I run into in a simliar vein is with Denied Access messages on the SharePoint servers when you attempt to browse or programatically access SharePoint Web Applications whose names are not the same as the NETBIOS or FQDN of the host server.  Which is quite common.  For example from the server you can browse to RICDXX01.yourdomainname.com just fine but if you attempt to browse to customportalname.yourdomain.com it is blocked because of a security patch to prevent malware spoofing of FQDN addresses.  I have seen this on Windows 2003 & 2008... For more information see this KB http://support.microsoft.com/kb/926642  which I know seems like it is unrelated but it is not.

Also please heavily consider using the BackConnectionHostNames option as a preferred (more secure) way to go.  The other option (disable loop back check) is referenced in lots of SharePoint blogs but it turns off all the good checking aspects of the security patch.  Applying the BackConnectionHostNames registry setting has become a standard part of my SharePoint setup instructions these days as the issue is almost bound to creep up if you don't.

Almost forgot one final point where this issue will really bite you is in the Indexing (and perhaps other) server run web traffic browsing programattic jobs.  I mention this because you can be experiencing this issue and not know it because hitting the site from a web browser not on the server will complete just fine.  Meanwhile every time your search & indexing process wakes up (since it runs it's requests from the server) it is failing to crawl content for any of the web applications whose FQDN names (url) are not the same as the machine.