Viewing Adobe PDFs within Internet Explorer 11 throws the error: “There is a problem with Adobe Acrobat/Reader. If it is running, please exit and try again. (0:104)”

Problem

I was recently involved with an Internet Explorer upgrade for a client with VMware Horizon VIew virtual desktops accelerated with SanDisk’s ioVDI solution where we noticed that after upgrading from Internet Explorer 9 to 11, we were no longer able to open PDFs from within the browser as the following error is presented:

There is a problem with Adobe Acrobat/Reader. If it is running, please exit and try again. (0:104)

Solution

Through the week long troubleshooting process, we were able to identify three possible solutions to the problem.

Solution #1 – Configure Internet Explorer to launch the Adobe PDF in a new seperate window

This was one of the easiest solutions we found through the forums but it was not practical for the environment because we had web applications that required PDFs to be launched from within the Internet Explorer 11 window.

Solution #2 – Configure IE 11 Tab Process Growth to 1 and disable Adobe Protected Mode

The environment we worked in had an application that required the Tab Process Growth for IE 11 to be set to the value of 0. 

User Configuration – Policies – Administrative Templates – Windows Components – Internet Explorer

Set tab process growth

What we noticed was that if we set the value to 1 via the GPO:

… or via the registry:

HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main

REG_DWORD named TabProcGrowth

------------------------------------------------------------------------------------------------------------------------------------------

**Note that if the above registry key does not work, try the following alternate location that also appears to work:

HKEY_CURRENT_USER\Software\Polices\Microsoft\Internet Explorer\Main

------------------------------------------------------------------------------------------------------------------------------------------

… and disable Protected Mode for Adobe Acrobat Reader DC 2015 as demonstrated in my previous post:

Disabling “Enable Protected Mode at startup” and “Enable Enhanced Security” for Adobe Acrobat Reader DC 2015
http://terenceluk.blogspot.com/2016/01/disabling-enable-protected-mode-at.html

… then the error will no longer be presented.

Solution #3 – Disable redirectusertemp for SanDisk ioVDI

The two solutions above would not have met our requirements for the organization and we were left wondering why our virtual desktops exhibited this problem but not our physical desktops.  Through further investigation and a bit of luck, we noticed errors being thrown in the Adobe Acrobat Reader DC 2015 referencing the directory:

C:\Windows\Temp\iotdx-disposable

As demonstrated in one of my previous posts:

VMware Horizon View virtual desktops experience temporary drive space issues with SanDisk Fusion-io ioVDI integration
http://terenceluk.blogspot.com/2015/08/vmware-horizon-view-virtual-desktops.html

I recently noticed that an environment with SanDisk ioVDI redirecting Windows files to a disposable disk could case issues if the drive fills up.  In this situation, the drive did not fill up but Adobe appears to have problems writing to it.  What we noticed was that this issue could be fixed if we iottool command on the VDI and disable the user temp folder from redirecting.

The command to execute would be as follows:

iottool redirectusertmp disable

Once executed, restart the system.

------------------------------------------------------------------------------------------------------------------------------------------

This issue took quite a bit of time and resources and I hope this post will help others who may come across this issue.

Removing duplicate disposable disks assigned to SanDisk Fusion-io ioVDI enabled virtual desktop

Problem

While reviewing the Hard disk configuration of VMware Horizon View ioVDI enabled virtual desktops, you notice that there are several disposable disks assigned to the VDI:

Note the Disk File path: 18/disp0/18disp0.vmdk

Note the Disk File path: 18/disp1/18disp0.vmdk

Note the Disk File path: 18/disp2/18disp0.vmdk

The following are the paths of each Hard disk with the disposable disks highlighted in red:

[datastore01b:view_lun11] 18/18-checkpoint.vmdk

[datastore01b:view_lun11] 18/disp0/18disp0.vmdk

[datastore01b:view_lun11] 18/disp1/18disp0.vmdk

[datastore01b:view_lun11] 18/disp2/18disp0.vmdk

[datastore01a:view_lun11] 4-vdm-user-disk-D-e7fd3c19-ca5e-4c7e-9531-ac6a22830c49.vmdk

[datastore01b:view_lun11] 18/181-internal.vmdk

Solution

As shown in the desktop properties above, we have 3 disposable disks assigned to the VDI but only one is really being used.  To identify which disk is in use, SSH into the ioVDI management appliance and connect to the vCenter via the following commands:

fio3prd:~ # iovdi vcenter -ln -vu sladmin -va vc01.contoso.com

Enter the vCenter password:

Re-Enter the vCenter password:

Logged in to VMP : vc01.contoso.com

Once successfully logged into vCenter, proceed to execute the following command to list the VDI’s Cache Mode properties for each disk:

iovdi guest -dr -np 18 -gu a-tluk -v

An output similar to the follow will be displayed:

fio3prd:~ # iovdi guest -dr -np 18 -gu a-tluk -v
Enter Guest Password :
Re-Enter Guest Password :
Checking vSCSI filter
VM name: 18
scsi0:1.Cache Mode = write_vector
scsi0:2.Cache Mode = hyper_cache  (Write Vector Candidate)
scsi0:3.Cache Mode = hyper_cache  (Write Vector Candidate)
scsi1:0.Cache Mode = hyper_cache
scsi1:1.Cache Mode = hyper_cache
scsi0:0.Cache Mode = hyper_cache
Duplicate write-vector disks found

vSCSI filter status: Not OK

Checking Write Vector status
VM name: 18
Pagefile and temp folder are redirected

Write Vectoring status: OK

1 tests failed
Add failed guests to an ioVDI config to fix the issues. If already present, reapply the config.

fio3prd:~ #

From the output above, the disposable disks that are actually being used are the ones that are labeled as with:

(Write Vector Candidate)

This means that SCSI (0:2):

… and SCSI (0:3):

… are the ones we can delete so proceed to remove them from within the Virtual Machine Properties then re-execute the command again. Output similar to the following will be displayed:

fio3prd:~ # iovdi guest -dr -np 18 -gu a-tluk -v
Enter Guest Password :
Re-Enter Guest Password :
Checking vSCSI filter
VM name: 18
scsi0:1.Cache Mode = write_vector
scsi1:0.Cache Mode = hyper_cache
scsi1:1.Cache Mode = hyper_cache
scsi0:0.Cache Mode = hyper_cache

vSCSI filter status: OK

Checking Write Vector status
VM name: 18
Pagefile and temp folder are redirected

Write Vectoring status: OK

All OK
fio3prd:~ #

If you would like to traverse through all of the desktops rather than doing them independently, the command also accepts wildcards as demonstrated in the following command:

fio3prd:~ # iovdi guest -dr -np VDInamingConvention-* -gu a-tluk -v

VMware Horizon View virtual desktops experience temporary drive space issues with SanDisk Fusion-io ioVDI integration

Before I begin, it’s important to note that I am not an expert with the SanDisk Fusion-io ioVDI product and the only exposure I’ve had was with a client who had another consulting company implement it in their VMware Horizon View 6 environment. With that out of the way, I’ve been troubleshooting issues with the VDIs ever since the the ioVDI product was upgraded from 1.0 to 2.0.  The virtual desktops would exhibit sporadic issues with various applications such as BGInfo not being able to load the customized desktop background or Silverlight web pages not loading at all.  The Silverlight web page issue isn’t as obvious so I’ll use the BGInfo as an example.  The screenshot below displays an error message when we try to manually apply the customized background:

Error during WriteFile():

There is not enough space on the disk.

This behavior lead us to believe that it had to do with the ioVDI cache / disposable disk so we opened up a ticket to work with a support engineer and we noticed that the Non-Persistent / DisposableDisk was indeed low on space with 1.52MB free:

This would sort of explain why the BGInfo couldn’t load the background because the wallpaper would have consumed around 2MB of space which the disposable disk did not have.

Next, we browsed to the folder that ioVDI redirect files to:

\\VirtualDesktopName\c$\Windows\Temp\iotdx-disposable

Lassoing the folders and reviewing the properties shows that only 6.30MB of space is actually consumed:

Having a feeling that perhaps there were hidden files, we went ahead and configured the folder to list all files and folders:

Which immediately revealed a redirected 5GB pagefile.sys file that was just as big as the 5GB disposable disk:

The page file size was expected because the virtual machine was configured with 6GB of memory.

I’m currently still waiting for the ioVDI support engineer to call me back with a recommendation whether to increase the drive space or perhaps do not redirect the page file and will update this post when I get a firm answer.

Update Aug 9, 2015

I received confirmation from the support engineer that the pagefile.sys should be redirected to the disposable disk as it is by design.  The case is currently being escalated to the engineering group because there have been several customers with the same issue.  One of the another engineer I worked with is was able to locate a command to disable the redirection of this file:

iottool redirectpagefile { enable | disable } : Enable or Disable redirection of pagefile.sys. The command

takes effect after reboot.

I haven’t tried this yet because I wanted to wait for engineering to get back to us on a better resolution.

Update Aug 10, 2015

We didn’t get an update from the other support engineer who’s trying to escalate the case so I went ahead and made the change to disable the redirect of the pagefile via the command above, rebooted the VDI and immediately noticed that all the sporadic out of memory, out of disk space error messages and other problems we had went away.  The VDI also feels a lot faster.  Here is a screenshot what the command prompt output looks like when executed directly on the VDI: