We have a client who manages multiple accounts for different identities under one Outlook instance.  He was running into an issue where Identity 1's name was showing up in replies sent from Identity 2. So, he'd click reply on something sent to Identity 2, Identity 2 was selected in the accounts selector at the top of the message, but in the body of the message was:

-------------------------
ORIGINAL MESSAGE

FROM:  Sender <sender@example.com>
TO: IDENTITY 1 <identity2@hisdomain.com>

etc...

It was a simple fix once we found it (and we looked everywhere, since Identity 1 is the name the Mac was registered to, we didn't know where it was grabbing the name from).

There was a contact card in Outlook that had Identity 2's email address associated with Identity 1's name; so Outlook "resolved" the name incorrectly - instead of taking it from the account properties, like we assume it should have; it took it from the contact card.

Once we deleted the Identity 2 address from the Identity 1 contact, all was right in the world, and our replies went back to looking like:

-------------------------
ORIGINAL MESSAGE

FROM:  Sender <sender@example.com>
TO: IDENTITY 2 <identity2@hisdomain.com>

etc...

We've got a client who recently upgraded their Windows Server 2008 Remote Desktop Services box from Office 2003 to Office 2010.  In doing so, they ran up against Internet File Blocking which Office 2010 seems to take seriously, where Office 2003 ignored it.

In a nutshell, any file you download from an "insecure" location, like say, your email, gets a tag injected in its Alternate Data Stream marking it as potentially unsafe, so when you try to open it using Office 2010, you get this helpful dialog:

File permissions are fine and disk space and memory is plentiful, so what's the glitch?  It's the alternative data stream, a hidden feature of NTFS that allows, well, alternate data to be stored along with your file; so in our case, every downloaded file has a Zone Identifier in its ADS, and Office will hemorrage with an unhelpful dialog if it comes across something.  Internet Explorer at leasthas the decency to tell you the score:

So, the question is how does one open these files in Office?

One way is to right click on the file, go into the properties tab and click the UNBLOCK button

But that can get tedious.

You can use SYSINTERNALS's streams.exe file to strip the ADS out of a bunch of files.

Or, you can turn the behavior off, which is what we did for our client.

A quick trip to the Google brought us to Dixin's Blog (which is where we cribbed the "file properties" screenshot from) and the steps are laid out very clearly there.

In a nutshell, go to Group Policies and edit or create a policy to enable a single setting in User Configuration > Administrative Templates > Windows Components > Attachment Manager > Do Not Preserve Zone Information in File Attachments.  

Log off and log back on, and you're good to go.

(We also forced the "Notify Antivirus Programs When Opening Attachments" setting, just to be on the safe side).

Anyway, you should really just go read the article over at Dixin's Blog and read Understanding The Internet File Blocking and Unblocking, it's much better than this one.  Lots of screenshots and explanatory text in an easy to read manner.

I've been asked by folks and have seen on FB about the "Internet shutting off" tomorrow -- here's my stock reply:

The malware which infected some machines is old, actually. These aren't new infections. The malware changed your computer's DNS servers to ones that the bad guys controlled, which is the equivalent of someone switching your 411 operator with their own nefarious operator, so when you tried to get the number for Domino's, they'd give you the number for Pizza Hut.

The bad guys' servers were seized back in 2011 and were reset to be benign, but under a court order, the FBI and other law enforcement agencies have to turn off the servers tomorrow, July 9, 2012.

Google, Facebook and others are able to detect if you're using those servers and have been putting up messages to those users whose machines have still not been cleaned, months after the fact.

So, if you haven't seen a message from Google or Facebook, you're fine, nothing to see here.

Facebook posted a blog entry about their efforts.

Geek News Central said this about it:

The most interest part of this story of course was not the DNSChanger bot, itself, but how the FBI and the court handled it. They could have shut it down immediate and the results would have been the same for those 300,000 plus 270,00 more. By delaying the shut down they did allow those 270,000 to recover. However it seems to me they dropped the ball in getting the word out. This didn’t become big news until the past week. I am not sure if the court and the FBI is to be blamed for this, or is it the media’s fault for not getting the word out. Whose ever fault it is, communication was lacking.

With Windows XP now pretty much impossible to get preloaded on new machines, our clients are finally moving to Windows 7 as their hardware refreshes.

A segment of our clients uses an application built upon Filemaker Pro, and they're running  v9.03 which isn't the most Windows 7 friendly version of Filemaker (that honor is reserved for any of the versions released in the last 3 years).  As we roll out Windows 7, we have found that databases hosted on remote servers don't show up in their Open Remote... dialog box.  The server appears, but the available databases do not populate.

Finally, after much searching, we have found the answer, thanks to a thread over at Filemaker Today forums which suggests copying the SERVER.PEM file out of a working machine's Filemaker Pro directory and copying it onto the failed machine will solve the issue, and lo and behold, we can confirm that does indeed work.

Thanks, Internets!