Citrix Provisioning & Webroot
Can anyone provide some assistance or at least a direction to look in? TIA
For virtural machines that get provisioned every time on login you need to use "-uniquedevice" or you will likely get a new instance every time the machine loads up.
Let me know if you have futher questions or need futher calrification.
1. Build the base image (without WSA)
2. Create vDisk from base image
3. Provision VMs from PVS template (configured to use the new vDisk)
4. Install WSA with -uniquedevice on the vDisk in private mode
If I'm not asking that right, please bear with me - we're not new to virtulization, but we're brand new to VDI.
@ wrote:
I'm not super familiar with provisioning virtural envrioments. My experience wih Webroot though tells me that the -uniquedevice switch will resolve the issue with not syspreping the VM deployment. The process I'd suggest is deploy image the VM and install Webroot with -uniquedevice after the imaging.
We ended up trying that yesterday with no success. Our basic process:
- build a master image
- use Citrix provisioning target agent to build a vDisk
- deploy given number of VMs, all booting form the target vDisk
- install Webroot to the vDisk using -uniquedevice
- ensure newly created VMs are booting from the vDisk that Webroot was installed on
The end result is the same - the Webroot console will see the last VM that checked in prior to loading the console page. The hostname will typically change upon a refresh.
@ wrote:
What is the result if you just install Webroot without any switches?
We haven't tried that but we certainly can. I'll post back here after we've run through that scenario.
Can Webroot verify that WSA uses the computer SID to check in with the admin console? (this would be the SID that is identified by using the "psgetsid" tool from PStools). If so, that's going to be a big problem.
Thoughts on workarounds, thoughts on what we can do?
I'll try to grab the ticket, feel free to put attn: Johnny S. in it.
Was this issue resolved ?
We´re planning a similar installation.
All I got from support was to use the -clone paramater when installing. But as I understand it that doesn´t really solve the issue ?
Also are you running webroot on the provisioning hosts ? If so how is the performance any issues ? Wich policy settings do you use ?
I´ve opened a ticket but support doesn´t seems to understand wich citrix product I asked about all I got was a link to this:
http://download.webroot.com/Citrix/Citrix.pdf
Wich I believe doesn´t really apply.
No, this issue is still present. After further investigation the current workaround is to deploy Webroot on boot using group policy or another deployment solution. This causes a new instance of the machine to show up in the console every time the VM boots from the master image. You can deploy Webroot to a special group in the console for these VM's to keep them separate from the others by using the /group= deployment switch, more info can be found on the Deployment Guide.
Because of this issue I have created a user story for development to investigate. What I proposed is to generate the back end identifiers based off the Microsoft SID (which should be the same for all the VM's, since they are booting from the master image) and the hostname of the VM instance. This should mean that each time the VM boots from the master image it should sync up with the correct back end identifiers. Please correct me if I'm wrong about the SID or the hostnames, I'm no expert in VDI environments.
I welcome discussion and criticism of the proposed fix.
I´ve checked with our citrix professional and you´re on the right track with the proposed fix according to him.
Regarding installing webroot on the provisioning host it self. Do you have any experience ? I don´t feel confortable just installing it and hoping for the best, since this could potentialy make the guest systems crash.
Here is citrix best practices for running antivirus on the host:
http://support.citrix.com/article/ctx124185
We have the same problem. We have installed WebRoot on our Citrix Provisioning image with -uniquedevice.
But it looks like we only get 1 device in the WebRoot admin console.
Do you have a update on the fix?
Regards,
Marius Andresen
I will contact support, thanks.
I just wanted to chime in here as this thread pops up from time to time, the original poster managed to find a solution for his environment by having Webroot installed everytime a user logs into a virtual desktop. In this case it was without either of the clone or uniquedevice command line arguments. The customers endpoints fill the same record instance each day and so the Webroot management console does not have overlapping records, or a new record for each end user each day. These are the two most common symptoms of an incorrect provisiong / virtualisation deployment with SecueAnywhere.
Our development team are continuously looking into how best to identify endpoints within our console as the landscape changes, ie more and more virtualisation or OS migration such as to Windows 10.
In general the golden rule for provisioning from golden images (pun intended) is to not install Webroot on them, but to install Webroot as users log into their desktops. We most often see success with the uniquedevice switch, but as this customers experience points out, each environment is different and might require some trial and investigation to find the best solution.
You can also find these instructions in our pdf guide here
If anyone else has a similar query please do not hesitate in opening a support ticket with us here
Thanks
Jack
![Product Help: Posted 1 comment! Badge](https://uploads-us-west-2.insided.com/webroot-en/attachment/1e1b4ba4-59ff-4b53-925a-1b4899e872c9_thumb.png)
Hello, does anyone monitor this forum any longer?
Hello, does anyone monitor this forum any longer?
I hope you realize that you are responding to a 4 year old thread. Besides your post the last post was 8 months ago. It would probably be recognized a lot quicker if you started a new thread and in the new thread put this 4 year old thread down as a reference.
HTH,
Dave.
Hello, does anyone monitor this forum any longer?
I hope you realize that you are responding to a 4 year old thread. Besides your post the last post was 8 months ago. It would probably be recognized a lot quicker if you started a new thread and in the new thread put this 4 year old thread down as a reference.
HTH,
Dave.
Why would I start a new thread when all of the history is here? Its not like anything has changed since then and it gets bumped to the top.
The thread is still relevant because nothing has changed. You have someone replying to the thing from 9 months ago. Should I just clog up the forum with the exact same question as the OP?
I see that a moderator saw the post, but instead of finding an answer, she just liked your post. Nice!
Just remember that you have clients with a lot of business that are heavily invested in webroot, but they dont have to be.
HTH,
Trav.
Hello
Us moderators are only volunteers, we’re not Webroot employees. I’ll ping our Community Specialist who is a Webroot employee
HTH,
Dave.
Hello
Welcome to the Webroot Community,
I apologize if I did not respond to your question. I did not understand what you were asking and I am not that familiar with the business side of Webroot. I know very little.
Kindest regards,
Sherry
Hey
I just reached out to our product team and this is their response:
“It is not recommended to install Webroot to a non-persistent VM environment as the console doesn't display endpoints in a way that is easily manageable and makes it difficult to report on. Will it work yes, but again, reporting and display are difficult to deal with. Also, Webroot does not work when installed as part of a golden image. Webroot will need to be installed as a post image process after sysprep is run. If you are looking for more info, we would recommend opening a case and working with support directly.”
Hope that clears things up
-Keenan
Reply
Login to the community
No account yet? Create an account
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.