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:
- Voltage Security Solutions Portal :: 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
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.
- Outlook Secure Temporary File Folder | Another Tech Blog – Andy at Another Tech Blog
- Attachment Can’t Create File Permission Denied – IT Support Notes.
- Tech Tip #1: The Case of the Vanishing Inline Attachments – Brazenly sassy, Claire M. Jackson’s account of the issue.
- Outlook SecureTemp Files Folder – Slipstick Systems
- Attachments remain in the Outlook Secure Temporary File folder when you exit Outlook 2003 or Outlook 2007 – Microsoft Support Article ID 817878
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.
Cheers!
--Claus V.
0 comments:
Post a Comment