We use EV 9.01 in combination with Outlook 2003 clients. Our environment is a mixed fat / thin client, with the thin clients connecting to Citrix / Powerfuse.
All of our fat clients have no problem opening attachments from archived messages, but on our citrix client we receive the dreaded error:
"The item could not be downloaded. [OIOM]".
We receive these errors both when opening the shortcut in Outlook and when opening an item through the Archive explorer.
Does anybody have a clue what I'm doing wrong?
Solved! Go to Solution.
It turns out that Powerfuse was indeed the culprit.
Within Powerfuse you can specify which application is allowed to make changes where. This is why my command prompt (cmd.exe) was able to read/write on the %TEMP% location, but the Outlook application (outlook.exe) was blocked to write to %TEMP%. In Powerfuse this is called Read-Only blanketing.
We created a rule that allowed Outlook.exe to create files in %TEMP% and we have full Vault functionality again!
Check this comment from MichelZ: https://www-secure.symantec.com/connect/forums/901-client-item-could-not-be-downloaded-oiom-80070005
Have you somehow set PSTDisableGrow registry key?
07/12/2010 09:54:26.835[ 196]: Unable to exempt PST's from PSTDisableGrow, make sure that 'PSTDisableGrowAllowAuthenticodeOverrides' registry key has been set...
There is an error in the Client which might enable Vault Cache on the Client, and this requires the PSTDisableGrowAllowAuthenticodeOverrides key to work if the PSTDisableGrow key is set.
This might explain why the 7.5 client is able to open the shortcut, and the 9.0.1 one is not. (It might try to download to the Vault Cache first before opening) This is the only thing I can think of...
Sorry, overlooked that one..
Did you see http://www.symantec.com/docs/TECH49333 ?
What you might want to try is using the ev8.05 client on the citrix-server to see if you then also have that problem. If not, the issue is with the ability to create and grow a temporary pst file (needed by ev9.01)
Thanks for your responce again Gertjan,
The DLL is copied, we ran into that one earlier ;)
I'll try the old client, just to see if that solves anything. What I do think is really strange, is that my fat clients (non-citrix) work perfectly. I've also tried monitoring with proces explorer, but no strange things there either.
On the citrix server, using OL2010, check if you can create a PST file, and if you can add a message to that PST file. If you can, EV-client should work. If you can't, that is the problem.
Here's a client trace log.
I've doublechecked the PSTDisableGrow, and it is not present in the registry. I am now working through the GPO's to see restrictions are set there. I was unaware that this option could be set on Outlook 2003.
The issue is we're unable to determine a path to create a temporary file in :
23/02/2011 13:03:10.187: ~DesktopCommon::GetEVTempPath: 0x80070005 23/02/2011 13:03:10.188: CDesktopPSTHelperBase::OpenNamedPST: 0x0 23/02/2011 13:03:10.188: CDesktopPSTHelperBase::AddService: 0x0 23/02/2011 13:03:10.203: ~CDesktopPSTHelperBase::AddService: 0x0 23/02/2011 13:03:10.204: CDesktopPSTHelperBase::OpenPST: 0x0 23/02/2011 13:03:10.204: CDesktopPSTHelperBase::ClosePST: 0x0 23/02/2011 13:03:10.204: ~CDesktopPSTHelperBase::ClosePST: 0x1 23/02/2011 13:03:10.205: CDesktopPSTHelperBase::ConfigurePST: 0x0 23/02/2011 13:03:10.214: ConfigureMsgService returned: 0x80070005 23/02/2011 13:03:10.215: CPSTHelper::OnError: 0x80070005 23/02/2011 13:03:10.215: ~CPSTHelper::OnError: 0x80070005 23/02/2011 13:03:10.215: ~CDesktopPSTHelperBase::ConfigurePST: 0x80070005 23/02/2011 13:03:10.216: ~CDesktopPSTHelperBase::OpenPST: 0x80070005 23/02/2011 13:03:10.216: CDesktopPSTHelperBase::RemoveService: 0x0 23/02/2011 13:03:10.221: ~CDesktopPSTHelperBase::RemoveService: 0x0 23/02/2011 13:03:10.221: ~CDesktopPSTHelperBase::OpenNamedPST: 0x80070005 23/02/2011 13:03:10.222: ~CPSTHelper::OpenTemporaryPST: 0x80070005 23/02/2011 13:03:10.223: ~CDesktop::CreateTempMsgEx: 0x80070005 23/02/2011 13:03:10.223: ~CDesktop::CreateTempMsg
I think you will need to look at permissions and so forth. Unfortunately we don't trace out where that is (the temporary path location we are using). I can try to find out though ...
So the folder it's looking for is the users temp folder eg :
I don't believe it's that.. it's the temp location. First line of the trace that I showed...and I gave an example of the location.
We need to a) be able to get that from a Win32API call, b) be able to write to it.
yup, so just go to the user, have them open a command prompt (if they can) and do a SET command and see what Temp directory its been set to or do a CD %TEMP% or open a Windows Explorer and in the address bar put %TEMP% or Start -> Run -> %temp% etc
What JW2 said.. but via the thin client who knows .. but there must be something on citrix/powerfuse that provides this temp variable to applications it "remotes" out.
But I've been able to test on a Citrix box without Powerfuse.
Completely solves the problem, so at least we have it located now. From what I can see, whenever you open an item EV creates a "Enterprise Vault" directory in the TEMP location. It seems Powerfuse somehow does not allow this.
Digging further, I'll keep the forum updated.