We are seeing issues with Windows 7 desktops connecting to a Citrix session with their printers.

Yeah i'm starting to notice that adding my users to use the universal printer driver is not completely fixing the issue.  Still having issues and printers going offline on some users (yet others are issue free).
 
I may have to turn that setting off to get rid of this issue.
 

Let us know if anything comes of it.
I have had a ticket open with them for several months. They stated they weren't able to reproduce the issue on their environment, asked us to do packet capturing and process monitoring, and then directed me back to our own forum post.
 
We are beginning to look into alternative software as it doesn't seem like they are taking the issue seriously.

I may be experiencing this issue as well.  At one office, all printers are network except for two stations that have usb printers (but autocreated in session).  We implemented Citrix Xenapp 7.9 a couple of months ago.  All has been fine.  On these two stations I installed webroot last week.  Today I am told for several days the citrix print jobs stop in the middle and the printer in Xenapp session shows offline.  Printing locally to the printer works fine.  I will try disabling the feature in webroot you mentioned and see what happens.

I would like to contact someone from the Webroot team on behalf of Citrix regarding this issue. Do we have anyone on this thread?

Thanks ?! Our product manager will contact you about this. We really appreciate you reaching out!

@Has there been any update here on this issue?  Like i've stated previously using a universal print driver within the citrix enviroment helped a little bit but i'm still having issues with my users having a printer go "offline" through citrix only.  This is especially troublesome as my citrix enviroment is not controlled by my company but another third party.
 
Thanks,
Ryan

All - I just noticed this thread and would kindly ask that anyone on this thread privately PM me diretly with contact information and I'll get with our esclation team to schedule a call. If it's a bug or problem with our agent, we should be able to isolate it and get it resolved. If it's configuration, we can find out which shield or setting is conflicting with the print drivers and get it fixed.
 
Thanks,

Shane, 
 
This issue has been going on a while, and it's costing us customers. We have opened tickets with support on it and the support was entirely useless. They keep asking for the same trace logs that they gathered the first few times, blaming the printer drivers and claiming it's a "networking issue", and it's gotten to the point where we can't keep asking the users to let us take over their machines to run the logging. We have open tickets with Citrix on the issue as well but they're at a loss as to why it's happening.
 
I'll be sending a PM with my contact info.

We are about done with Webroot unfortunately. I started this thread in January, and we have made zero headway, and clearly we are not the only ones seeing the issue. We ended up turning off real time scan to stop the issue from happening and doing scans every 2 hours instead, not the ideal solution for protection...
 
We will be deploying a new product shortly with a better support experience and will part ways with this product. I wish you all luck (sincerely) with trying to find a resolution to the this issue.

Since we are an MSP we now have 3 clients who are using the same software vendor which uses Citrix.  So obviously that means I have three client who are not using real time sheilds.  This has actually lead to one of those endpoints experiencing a ransomware attack.  
 
I really love this product, but we might have to start looking at other options as crippled security is not good enough. :/ 

A possible resolution to the issue will require File/Path overrides on the following files:
 
%programfiles(x86)%CitrixICA ClientCDViewer.exe 
%programfiles(x86)%CitrixICA Clientconcentr.exe 
%programfiles(x86)%CitrixICA ClientMediaEngineService.exe 
%programfiles(x86)%CitrixICA Clientwfica32.exe 
%programfiles(x86)%CitrixICA ClientAuthManagerAuthManSvr.exe 
%programfiles(x86)%CitrixICA ClientSelfServicePluginSelfService.exe 
%programfiles(x86)%CitrixICA ClientSelfServicePluginSelfServicePlugin.exe 
%systemroot%system32spoolprinters*.tmp 
%systemroot%system32spoolprinters*.spl 
%systemroot%system32spoolprinters*.shd
 
To create Overrides, log into the Site Console and click on the Overrides tab. Here’s a link to the Overrides guide - http://live.webrootanywhere.com/content/1384/Creating-Whitelist-Overrides

1. Click the Create button[list=1]
2. The system displays the Create override window.

In the Override Namefield, enter a name for the override

In the Override Type field, select Path/File

In the File Mask field, enter the file name

In the Path Mask field, enter the file path

For the setting Detect if Malicious, select No

When done, click the Save button and enter the next override[/list] 
Once all overrides have been entered, force the Endpoint agent to poll.
- Method 1 -

1. Locate the SecureAnywhere icon in the system tray.
2. Right-click the icon and select "Refresh Configuration".

 
- Method 2 -
To poll via command line option, use the appropriate command for the OS.
 
For 32bit Operating Systems, type:
        "C:Program FilesWebrootWRSA.exe" -poll
  
For 64bit Operating Systems, type:
        "C:Program Files (x86)WebrootWRSA.exe" -poll
 
Please let us know if you have a chance to try these steps and what the result is afterwards.

Has anyone been able to confirm if creating overrides for the Citrix client and spooler makes a difference? Even so, I suspect this is just another band aid for a seriously broken security product.
 
I've only been with Webroot for a few months and it's been a very painful ride. We've been fighting Citrix printing issues as described in this thread, BSODs on our servers, locked up Citrix servers, etc. since rolling it out to all of our customers. Some of these issues were identified over a year ago, but still have not been addressed to this day. Webroot updates have been very hit or miss, causing new issues to magically appear from one day to the next. This software has done more to damage our customer relationships than any virus or malware could ever do. If major improvements are not made fast, we will have no choice but to abandon it for good,
 
Webroot, please make progress on these issues. You've had more than enough time to do it.

I worked with Webroot Support on this issue and wanted to share their recommendation. 
 
They "...suggest setting up a policy with the "Scan files when written or modified" under the Realtime shield turned off."
 
I questioned the safety of this recommendation and was told:
 
"When you ask are there risks in turning off Scan Files When Written or Modified; short answer is, yes. You're turning off WSA's ability to stop threats as they write to or modify files on the machine. However, this is the only workaround from the Webroot side. So you'll need to weigh the pros and cons of changing this setting.
 
To be honest, our escalation and dev team have gone over the issue several times. What they've found, is that this is ultimately a problem with the way that Citrix files get created while spooling. When the Realtime shield scans the spooled file it holds it for a fraction of a second. But this is long enough for the process to fall over. The file it generates cannot be touched, which is in direct opposition of what the Realtime shield does.
 
Please note that an override does not equal exclusion. We do not have true exclusions. And the override you've created for this is working by design, but is most likely making matters worse. When you create overrides, WSA will hold onto the file for a fraction longer as it overrides the backend determination and writes to logs that the override was respected. This is one of the reasons we stress not to make overrides for whitelisted files (This being one of them). 
 
The only way to exclude files is to turn off settings within the Realtime shield. This is inherently risky as it's one of our most powerful shields against malware."
 
This answer did not sit well with me, and it's the first time I've ever had a security vendor make a recommendation like this for a production environment. It's as if we need to choose between the reliability of our application(s) or using Webroot.
 
This is the nail in the coffin for us. I wanted to this post response for anyone else that is still wondering if Webroot is working to resolve this issue.

Forgot to mention in my last post that Webroot Support's reference to "And the override you've created for this is working by design, but is most likely making matters worse" refers to the Citrix and Windows Spooler exclusions recommended by "JP" from Webroot in this same discussion. So if you followed that recomendation like we did, then you may have made your problem worse.

Hi all,
 
Is there any update on this recently? We're in the process of deploying Webroot and haven't hit servers, but we have many Citrix environment and have already ran into this issue with workstations.
 
Thanks,

@ I've been told by our Business Support Team that the only resolution is to leave scan files written/modified turned off. You will also want to make sure that you are using the Citrix universal print driver.

Unfortunately, the Citrix UPD is simply not an option. For many of our printers, the UPD simply doesn't work. I have to say that I'm severly disappointed in the support Webroot is supplying. 

Hello and welcome @,

I've created a case on your behalf with our Support Team. Please watch your inbox so our Team can get in contact with you shortly.

I am checking in on a resolutions as well.  I've a small office of 10-15 computers.  I added a policy in the console with scan files when written or modified disabled.  I only had to implement this policy for two citrix client workstations.  Difference being, all other workstations print to two canon network printers (driver installed on client, print directly to newtork printer).  Those computers have had no issues printing since implementation, well over a year.  The two that had issues printed locally to attached usb printers.  When I have time, i'll take them back off this policy and see if the issue comes back.  Just checking to see if it was ever resolved in Webroot.

@ there has been no update in regards to this that I'm aware of. 
 
Please send our Team a support ticket for further assistance/explanation.