Saturday, May 22, 2010

OSTff revisited

In the last post (gosh has it been that long ago?) Blasting the blasted Outlook Secure Temporary file folder… I outlined a number of free utilities that would assist with deletion of the contents of that folder.

The user who had the issue leading us on this learning adventure eventually called back with the same problem again.  Additional monitoring of the user as well as the processes she was doing illustrated to me that some kind of Outlook error and/or interaction with Voltage was causing the opened attachments to remain “orphaned” even when closed out “properly.”

We then were faced with deploying one of the solutions noted.  I was leaning heavily towards OutlookTempCleaner and calling it at startup via a scheduled task or simple bat-file in the Startup folder.

However, in the end, the suggestion was made to just do a batch-file that cleaned it up without any additional third-party code.  OK, I’m game.

There were a number of approaches I could have taken, primarily just making a direct, hard-coded identification to the user’s particular Outlook Secure Temporary file folder location, but if that “randomly” generated location ever got changed, say if Outlook had to be reinstalled, then it might break.

Instead after a bit of research I found a suggested solution offered by GuruGary in this Experts-Exchange post: Outlook Secure Temp Folder Full : outlook, folder, temp, secure.

For a solution how about this in a batch file (that can be run as a scheduled task, or at logoff, etc.:
@echo off
for /f "tokens=3 delims=      " %%a in ('reg.exe query hkcu\Software\Microsoft\Office\11.0\Outlook\Security /v OutlookSecureTempFolder ^|findstr REG_SZ') do rd "%%a" /q /s

Depending on which version of Outlook she is running, you may need to change the 11.0 in the registry key.

However, try as hard as I could in testing, it just didn’t seem to execute correctly.

It was very clever; using the reg.exe utility to query the registry and obtain the key value holding the actual path to the user’s Outlook Secure Temp folder location, then doing a deletion of it.

I then proceeded to rework the batch file using Rob van der Woude’s link: Batch files - Reading NT’s Registry with REG.EXE.

In the end I crafted the following batch file that did work perfectly on our own XP Pro SP3 systems for the problem at hand.

@ECHO OFF

::Place batch file in C:\Windows\32 location so it can find the reg.exe utility.

::Place shortcut to this batch file in the user's Startup folder to run upon login.

::Will auto-clean the user's Outlook Secure Temporary File folder location of all "orphaned" files so gets a clean-slate.

::Queries registry location of that folder location, then uses information to delete all the files present.

:: Note: delims is a TAB followed by a space

FOR /F "tokens=2* delims=     " %%A IN (' REG QUERY "HKCU\Software\Microsoft\Office\11.0\Outlook\Security" /v OutlookSecureTempFolder') DO SET Location=%%B

DEL /s /f /q "%Location%\*.*"

Depending on which version of Outlook you have, you will have to modify the “11.0” number according to this Microsoft Support article 817878 --Attachments remain in the Outlook Secure Temporary File folder when you exit Outlook 2003 or Outlook 2007.

Yes, just having the end user periodically run a free utility when needed probably was much easier, but this will run almost silently in the background at each login and clean things out.  Also, because it queries the actual registry key location each time before running, if that does ever get changed, it can adjust, rather than had I simply “hard-coded” that specific path to begin with.

Rob’s website contains a wealth of detailed and helpful information for CLI junkies and batch-file writers:

He also has lots of great WMI Scripting information as well as an added bonus: Getting Started with WMI Scripting

Wayne Martin has another collection of lots of useful command-line models over at his WWoIT – Wayne’s World of IT blog.

Lots of inspiring commands and operations here…

Cheers.

--Claus V.

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.

Cheers!

--Claus V.

In the trenches…

Been burning extra time working out a nagging Remote Desktop issue.  Still unresolved but I am stubbornly pressing on to solution it.

At the local house of worship, there is a pretty nice LAN setup.  At the sound/video desk we recently installed two Windows 7 Ultimate systems.  These are brawny multi-core systems, x64 bit OS, 8GB RAM systems.  More than enough muscle to power video/sound editing and projection work.

However the desk area itself is very limited.  So we dropped one box (with no monitor) under the desk. Then we use the second workstation on the desk to do a Windows RDC session to the 2nd (headless) workstation as needed.

Only the RDC sessions are a bit “wonky”.

Typically after the first RDC session is started, the login goes through, the remote system desktop is displayed, then the following error message appears on the workstation I am initializing the RDC session from:

“Microsoft Visual C++ Runtime Library
Program C:\Windows\system32\mstsc.exe
R6025
-pure virtual function call”

And the RDP session terminates.

If I try again, each time the connection gets briefly established, then kicks off, and the error appears.

After about 7-10 attempts, I am then able to get a “stable” RDC session established with no more kick-offs or errors.  So it does “work”.

I checked the remote system logs and found the following errors noted:

“Event ID: 9015
Desktop Windows Manager was unable to start because the remote client does not support desktop composition remoting.”

and

“Event ID:9003
Desktop Window Manager was unable to start because a composited theme is not in use.”

I’ve already made sure RDC exceptions are enabled on both systems in Windows Firewall.

I have tried reducing the headless system’s theme to “Classic” and disabling all Aero effects as far as I can tell.

I’ve made sure all the theme management services are running “automatic”.

I’ve tried disabling the various extra RDC “experience” options before connecting.

Same behavior.  Only after seven or more aborted RDC connections is a stable RDC session established.

I’ve tried using the RD client files from a “portable” build based on another system’s Win7 RDC files but same thing, so it doesn’t appear to be a corruption issue with the mstsc executable.

I’m still trying to research the root cause.  Other things I need to pursue this weekend:

  • I did have to turn off “Aero peek” on the system I am RDC’ing from as that was pulling “system focus” away from running presentations if accident hovered over.  Not cool during a service…  I’ve not yet re-enabled it to see if that has any bearing.  I don’t think so as the other geek seems to have the same issue from his own independent Win7 system RDC’ing to the target box.
  • I’ve seen lots of forum threads on similar issues.  In many of those cases the posters felt the issues was a bug in the Win7 RDP client itself.  They felt that way as connecting with a “portable” older set of RDP files from, say, XP SP3 didn’t demonstrate the issue.  I think they are using Remote Desktop Connection (Terminal Services Client 6.0).  I need to grab a set of that version to try to see if that makes a difference.

The facts that I see the error start just after the remote system’s desktop get displayed, that the event logs all mention “composition theme” in some fashion even though all settings seem to support a compatible rendering experience, and that with enough attempts, it eventually “works” suggests to me that it might, in fact, be some kind of network issue.  Could it be that the systems are “talking” too fast to keep up with each other as the different services interact and link-up?  I did find this tantalizing post on tweaking RDP network performance: Remote Desktop slow problem solved which tweaks the Receive Windows Auto-Tuning settings in Windows Vista…need to make sure it carries over to Win 7 as well first.

And yes, of course, we could go with a TVNC based remote desktop solution…or one of many others.  However, connection establishment error excepted, RDC fits the internal need just fine.

It doesn’t look like I am the only one wrestling with this issue.

When I finally get it resolved, I’ll post an update.

BTW, one early bonus from this “project” has been the discovery of the Remote Desktop Services (Terminal Services) Team Blog.  Lots of good info there for you Remote Desktop fans….

Cheers!

--Claus V.