Saturday, May 01, 2010

Blasting the blasted Outlook Secure Temporary file folder…

Despite the challenge of the RDC issue last posted about, we did have one small but significant Windows system troubleshooting victory last week.

One of our end-users was working with Voltage to pull mail out of a shared mailbox into the local Outlook client.

When she attempted to open the attached file, the following error was seen:

Can't create file: message_zdm.html. Right click the folder you want to create the file in and then click properties on the shortcut menu to check your permissions for the folder

Several field techs attempted to resolve the issue during multiple site visits, to no avail.

So crack network analyst “Mr. No” and I dropped by while in the neighborhood on an unrelated special project to take a look.

Based on the error message, we doubly-checked the permissions on the user’s Outlook folders. We reloaded different versions of Voltage and fiddled with the enrollment certifications. Checked disk space. Ensured no permission or size limits found on the folders.  Purged the IE temp cache location. Nothing seemed to work.  Comparing this user’s settings in Voltage/Outlook to a co-worker who was similarly configured but not having the issue found nothing different.

So, in a brilliant move, Mr. No decided to Google the error message…and found this:

Turns out the user’s “Outlook Secure Temporary file folder” was filled up and needed to be flushed.

Once those steps were followed, the attachments could be opened again with no fuss.

Problem solved.

However, that wasn’t enough for Mr. Valca here.  What was going on and why was this user, out of the thousand-plus we support, having this particular problem?

Greetings Outlook Secure Temporary File Folder…Nice to meet you.

When I got back to the office I did more research and while not an unknown issue (and not limited to Voltage users by the way), it does seem to be rather uncommon.

I found a few posts in particular that described the issue and potential solutions.

These (and other forum posts) referenced the root-cause as Andy well summarizes from his above-linked post:

“…outlook has a limit on the number of files of the same name that it can store.  If you have 99 “orphaned” files in the temp folder whose source attachment have the same name, when you try to open the 100th, you will get an error saying you can not open any attachments.”

Only my mind was a bit confused.  How you you have up to 99 files with the same name in the same folder location?  That didn’t seem to make sense. And what was our particular user doing so well to cause that many to accrue in the first place?

And how were they being “orphaned” in the first place? The user stayed in Outlook all day long with no Outlook crashes found or reported.

The Experiment

I fired up my own system, dove into Regedit, burrowed down to the location (Outlook 2003) HKEY_CURRENT_USER\Software\Microsoft\Office\11.0\Outlook\Security and copied the folder location found in the Value Name: OutlookSecureTempFolder key.

Then I pasted it into the address-bar of Windows Explorer and was taken to that folder location.

I had a few items in there, but none indicating duplicate names.  So I deleted them all to get a fresh slate.

I then popped into Outlook and sent myself a simple Outlook email with a dummy text file attachment called…wait for it…”dummy.txt”

With Windows Explorer still open to my Outlook Secure Temporary (OST) file folder location on the left, I double-clicked the test message to open it in its own window.  Then I double-clicked the attachment to open it.  Voilla!  the file dummy.txt was showing in the OST folder.  I closed the attachment and then closed the message and the file disappeared, automatically removed as expected by Outlook.

Next I repeated the process.  But this time I kept the attachment open but closed the message.  Then I closed the attachment.  To no surprise, the dummy.txt file was left behind and not deleted.

Then I repeated the process…only this time the file in the OST was automatically re-named to dummy_(1).txt (or something like that…I’m having trouble reading my notes).  Repeated testing found that if the email message Window was closed before the attachment, I could quickly add many more dummy_(#).txt files and leave them “orphaned” and preserved in the OST location.

So it seems that while “technically” the file names are not duplicate names…the attachment name is a duplicate and diff’ed by the addition of the “_(#)” name portion.  When the same file-name is present but the counter reaches “_(99)” then upon reaching the 100th instance, the error happens and the file attachment cannot be opened.  Now that made sense.

What I didn’t test, (and am curious as to) is what would have happened if I just created a file “dummy_(99).txt” in an otherwise emptied OST folder (that’s the only file present) and then tried to open my “dummy.txt” attachment, if the error would trigger due to the “_(99)” counter presence, and not an actual count of files really present.  I’ll try that one on Monday back in the shop but I’m pretty sure I already know the answer…

Knowing this, it is easy to understand the process by which this particular user was tripping over the error when almost nobody else is.

The user is receiving a high volume of inbound messages in the shared mailbox to process as part of her job duty.  These messages include a standard internal form attachment.  That attachment is frequently NOT renamed to something different by the sender. So even though the content of the form attachment is different, the file name is the same.

This end user opens the message, opens the attachment, closes the message (with the attachment still open…now “orphaned”) and proceeds to process the information in the form into another application.  Once done, the attachment gets closed.  This works fine for a while but eventually, enough identically named forms are processed/orphaned and the error trips upon #100.

Again, in our case it was Voltage attachments.  It could easily be PDF files/forms, Excel sheets, Word documents, whatever in your shop.  The attachment type isn’t the issue, it is the attachment “name” and how many times the attachment gets “orphaned” due to Outlook crash or (more likely) closure of the message body Window before the opened attachment itself gets closed.

Mitigation and Utilities

Because the default OST file folder location is typically “super-hidden”, it’s not easy to instruct most end users to browse into the registry and do a copy/past of the key value into Windows Explorer to empty things out.

In this case, it just required showing the end-user that she should either “save as” the attachment first before opening into a different location with an amended name before opening, or consider leaving the email message open, then when done with the attachment, close it, then the message body.

However, there are also some cool utility “toys” that can automate the process to various degrees as well:

  • OutlookTempCleaner -- (freeware) -- HowTo-Outlook. This simple exe file automatically finds and cleans the folder out when run.  What is particularly nice is that it supports CLI options for use in a login batch-file for automated cleaning if needed.  Also cool is the “big-brother” Outlook utility OutlookTools (also free) which brings extra Outlook support options to the table. NYC Tech Guys mentioned OutlookTempCleaner in their Empty Outlook’s secure temp folder post.

  • CleanAfterMe -- (freeware) –NirSoft.  This power-cleaning tool for Windows also has an option in it to clean that folder location, among many other deep-level things. 

  • CCleaner -- (freeware) -- Piriform.  More than one forum post also recommended use of CCleaner (newest versions) to clean this location.  I didn’t see it specifically noted/identified in the options, so maybe it falls into one of the general cleaning options.  Not sure.

  • Outlook Temporary File Cleaner – MSDN by anthonyrsc.  very small exe file (23K) with source-code provided.

So now I and our team are all much wiser to the Outlook Secure Temporary file folder and its solution.

Too bad the error message couldn’t be a bit clearer. I’m sure more than one sysadmin called in on this one has taken a while to check folder sizes and permissions in both Outlook and the local system before eventually associating the issue/solution with the blasted Outlook Secure Temporary File folder.


--Claus V.


Absoblogginlutely! said...

I've had something like this happen a couple of times to my users. It's weird and confusing to the user when you try and explain why (as they always want to know). The fact that the folder is in some weird location and often hidden makes it just that harder to find and troubleshoot. I normally find an attachment, open it and then go to save. Then when the save dialog box defaults to the temporary file location I open an explorer window and proceed to delete the rest of the old files in that directory.

Anonymous said...

I know this is two years later but this post helped lead me in the correct direction for resolving an issue was recieving when trying to open or Save As an attachment sent by the Voltage. Turns out the user had a shared mailbox in their Outlook profile. When they would open the attachment the file is created in C:\Documents and Settings\username\Local Settings\Temporary Internet Files\Content.Outlook\XXXXXXXX. However when they closed the attachment or the email, the file is not automatically deleted. Once the files build up its game over. Just delete or consolidate files in the directory above and restart the Outlook client. You should be able to open or Save As the attachment. Hope this helps someone out there.

Claus said...

@ Anonymous - Thanks for the comment and extra feedback for your particular configuration. That's good to know.

A new "issue" with Voltage SecureMail I had to troubleshoot regarded a user (me!) who suddenly wasn't able to get Voltage to send a new Outlook 2010 message with a standard MS Office attachment. It just failed, but others would go though just fine. Stumped me for close to an hour until I figured it out.

Turns out that if the attachment filename is over a certain number of characters, Voltage refuses to process it!

I haven't found (but haven't looked to hard) what the limit is. I figured it out by realizing this particular filename was super-duper long. I shortened it and tried again and it went fine.

Go figure....


--Claus V.

Karl Fisher said...

Thanks for the in depth explanation. I had been using Ccleaner to resolve this issue and was looking for a permanent solution. I guess there isn't one since Ccleaner is one of the solutions listed! I cannot believe this issue still occurs in Outlook 2013 as well!