VMware Horizon Community
Ray_handels
Virtuoso
Virtuoso
Jump to solution

Issue with adding attachments in Outlook 2010 with Agent 2.12.1

Hey Guys,

Just wanted to ask you for some information. We recently updated to version 2.12.1 Appvolumes and are facing the following issue.

If we add an attachment to an e-mail (we are using Outlook 2010 installed in the golden image) we sometimes receive en error message stating "Could not open "filename UNC path"". If we copy the file to a local drive we are able to add the exact same attachment to the mail. So it does not seem to be related to just the name of the file. We are also using writable volumes but if we disable it and log in without writable we see the exact same issue popping up.

I was wondering if anyone else of you has the exact same issue. We did off course create an SR with VMWare. Will keep you guys posted.

1 Solution

Accepted Solutions
Raymond_W
VMware Employee
VMware Employee
Jump to solution

Hi,

I think we identified the problem and are working on a solution.

In the meanwhile, can you please try this workaround from engineering:

cd /d %SVAgent%
copy c:\windows\system32\cmd.exe
md en-US
copy c:\windows\system32\cmd.exe.mui en-US
.\cmd /c rd C:\Users\<username>

The rd command deletes a symbolic link from the system volume to the UIA+Profile writable volume, where the user folder actually exists. The command deletes only the symbolic link. The folder on the writable volume is unaffected.

The symbolic link will be created every time you login, but if you put it in the appvolsattached.bat it will be done automatically,

Regards,

Raymond

Kind regards, Raymond Twitter: @raymond_himself

View solution in original post

12 Replies
techguy129
Expert
Expert
Jump to solution

I have a similar issue with Office 2016 and 2.12.1. I have had an open case with VMware for about 3 weeks but almost no headway on a resolution. I rolled back to 2.12.

Reply
0 Kudos
Ray_handels
Virtuoso
Virtuoso
Jump to solution

Okay, do you happen to have the SR for it? If you had the exact same issue on a newer Outlook version thay should state it as a bug.

We did found a bit more info though. It seems to be something related to security because it only happens with "unsafe" files on a network share.

When we right click the file and click unblock we are able to add it as an attachment. The problem is that it is more than just adding an attachment. It seems to be an issue all along the board with security and office files. I'm trying to put on some pressure becaus rolling back to 2.12.0 is not soemthing I'm really willing to do as it has quite a few bugs in it. We went from 2.9.1 to 2.12.1. It might be an option to go back there but also not something I'm willing to do already. 2.12.1 fixed quite a few issues that we had with 2.9.1.

Reply
0 Kudos
techguy129
Expert
Expert
Jump to solution

SR: 17464806305

You are correct its a security thing. Any files downloaded off internet or outlook have this issue. I've also seen the issue outside of office applications as well. All that is noted in the SR.

Reply
0 Kudos
Ray_handels
Virtuoso
Virtuoso
Jump to solution

Hey Techguy,

This is very very frustrating. They new that there was an issue with the 2.12.1 agent in regards to adding attachments apparently, otherwise you wouldn't have had the issue. Is the SR still open or did you eventually throw in the towel?

Because we have a lot of users that are getting frustrated my guess is we will go back to the old agent.

We did find out a bit more info after digging into a little deeper. It doesn't seem to be a security issue but more of an issue the way Appvolumes in combination with a Profile writable volume handles the %LOCALAPPDATA% folder. It seems as if for some strange reason it tries to add a file from the %TEMP% directory or the Temp internet Files but can't use or cope with the name it creates. Both folders are under the C:\Users\%username%\Appdata\Local folder.

When attaching the file into Outlook we saw the following error. As you can see between username and Appdata there is no \. And it tries to create it within the writable volume, not the local drive which off course is correct if you use a writable.

9:58:58,1233886             
OUTLOOK.EXE  3028    
CreateFile         
C:\SnapVolumesTemp\MountPoints\{610729b8-5656-11e7-a441-005056b24a62}\SVROOT\
Users\myusernameAppData\Local\Microsoft\Windows\Temporary Internet
Files\Content.MSO\filename.zip\:Zone.Identifier:$DATA  NAME
INVALID              
Desired Access: Generic Write, Read Data/List Directory, Disposition:
OverwriteIf, Options: Sequential Access, Synchronous IO Non-Alert, Attributes:
n/a, ShareMode: Read, Write, Delete, AllocationSize: 26

If we get any more info I will let you guys now. Thing is that it seems to boil down to the writable as users that don't have a writable are using the 2.12.1 agent happily.

Ray_handels
Virtuoso
Virtuoso
Jump to solution

Hey Techguy,

Just out of curiosity, when did you raise this SR?? And why did you eventually decided to go back (other than users being angry for not being able to do stuff Smiley Happy).

Reply
0 Kudos
techguy129
Expert
Expert
Jump to solution

The SR was created on 05/18/2017. Its still open but haven't heard back from support in two weeks. Going to ping him now.  I rolled back mostly because of the users but also app volume support is terrible. We use sql reporting services and none of reports were opening for any of my users. I went to 2.12.1 to fix the 400 errors when users logged in but so far that hasn't been much a problem since I left my management servers on 2.12.1.

Reply
0 Kudos
Ray_handels
Virtuoso
Virtuoso
Jump to solution

Thanks for your reply and this seems to be indeed the exact same issue as we are seeing. The inability to open up (or create) files anywere in the LOCALAPPDATA. My guess is that SQL reporting creates these files within the Temporary Internet Files directory and IE cannot find the file.

Our SR is 17493231206 and we are pushing support for a solution as we now have to go back to an older version and to be honest. Up until this bug I was quite happy with the fixes in 2.12.1 and our users were as well. But now it's back to the drawing board and yet again a painfull testing procedure.

I hope to have a PR asap. I would indeed suggest pinging support and we might be able to get it fixed seeing you have the exact same issue as we are having..

Reply
0 Kudos
Raymond_W
VMware Employee
VMware Employee
Jump to solution

Hi,

I think we identified the problem and are working on a solution.

In the meanwhile, can you please try this workaround from engineering:

cd /d %SVAgent%
copy c:\windows\system32\cmd.exe
md en-US
copy c:\windows\system32\cmd.exe.mui en-US
.\cmd /c rd C:\Users\<username>

The rd command deletes a symbolic link from the system volume to the UIA+Profile writable volume, where the user folder actually exists. The command deletes only the symbolic link. The folder on the writable volume is unaffected.

The symbolic link will be created every time you login, but if you put it in the appvolsattached.bat it will be done automatically,

Regards,

Raymond

Kind regards, Raymond Twitter: @raymond_himself
Ray_handels
Virtuoso
Virtuoso
Jump to solution

Yep, works like a charm. The issue fixes the error message "on the fly" so the moment you remove the symbolic link it works.

Reply
0 Kudos
techguy129
Expert
Expert
Jump to solution

Running it manually fixes my issue. I believe the appvolsattached.bat  runs as User and my users don't have administrative privileges to copy and remove the slink. Any other .bat files I can use to execute it as System?

Reply
0 Kudos
techguy129
Expert
Expert
Jump to solution

I have a bat file that I can run as admin that works.

@echo off

cd /d %SVAgent%

copy c:\windows\system32\cmd.exe

for /f "usebackq skip=1 tokens=*" %%i in (`wmic COMPUTERSYSTEM GET USERNAME ^| findstr /r /v "^$"`) do set str=%%i

set str=%str:Domain\=%

.\cmd /c rd C:\Users\%str%

Reply
0 Kudos
techguy129
Expert
Expert
Jump to solution

FYI - I received a hotfix from VMware for this issue that resolves it. Version 2.12.13.11

Reply
0 Kudos