Sophos End Point AV in a VMware View Linked Clone Environment

[JayArr]

I just wanted to chime with my experiences in VMware View  with Sophos End Point Protection 9.5 - yep we've been there and through upgrades and have come up with a decent process for deploying Sophos End Point Protection on VMware View snapshot clones without installing the entire EPP product on each machine after it's created to reduce the size of the linked clones and reduce management overhead on both sides.

I'm also looking at feedback from other Sophos customers, and I strongly recommend posting questions on Sophos' forum and send feedback to your account manager about supporting the vShield product.

---

I'm patiently waiting for Sophos to support vShield protection so it's one less step I need to do when I prep a master image for deployment in View. They previewed a vShield appliance in Februrary... so I'm optimistic. I hate that they won't answer any vShield questions in their forum.

---

Short version:

I install and update the sophos agent on the master to ensure the newest ides are installed. Then I run a batch file I created to delete machine specific xml files and registry keys to sanitize the machine (see Sophos references below). Then when I create snapshot clones, the machines have generic sophos files, ide's, and services - no machine name specific files are on the cloned machine. After the clone and synchronization is complete, I have VMware View run a post synchronization script that runs a specific command sophos provided to launch the sophos install MSI to finish the sophos customization on the vDesktop.

Step By Step version:

1. On the master VM: Install sophos end point protection (without firewall or NAC)

2. On the master VM: Install a batch file in a folder like C:\Temp\DeploySophos\install.bat

3. On the master VM: In the install.bat, have this line of code:

MsiExec.exe /i "c:\Program Files\Sophos\AutoUpdate\cache\savxp\Sophos Anti-Virus.msi" REINSTALL=ALL REINSTALLMODE=voums UPDATEDRIVERS=0 /l*v c:\msi.log /qb

4. On the master VM: Run the attached batch file (Prep_Sophos.zip) which calls the included reg keys on the master VM to prep the machine for deployment right before you shut down the master for your deployment snapshot. This will sanitize your VM.

5. In your View pool, call your batch file in your Post-synchronization script. For Example if you placed the install.bat in C:\Temp\DeploySophos\ you would put "C:\Temp\DeploySophos\install.bat" and then every VM created for that pool will finish the sophos customization without doing a full reinstall right after the machine is on the domain and synchronized.

• This reduces the size of each snapshot clone (linked clone) in storage
  
• Reduces the amount of time to spin up more desktops.
  
• This process has NOT been tested with NAC or Firewall options enabled with VMs - there WILL be more changes required to sanitize a machine with the Firewall and NAC agents installed.
  
• Each machine reports to the Sophos Enterprise Console properly, even through recomposition, refreshes, or deletions and recreations.
  

Resources:

Sophos Anti-Virus for Windows 2000+: incorporating current versions in a disk image, including for use with cloned virtual machines

http://www.sophos.com/support/knowledgebase/article/12561.html

Best Practice for running Sophos on virtual systems

http://www.sophos.com/support/knowledgebase/article/110507.html

[chulerico]

Thanks for the info,

we are using sophos and a bit disappointed that they don't have a solution that integrates with vshield.

Thanks again.

will definitely use this.

oh by the way, how you are handling the disk scanning schedule?

Sam

[six4rm]

Hi JayArr,

I started a discussion on Sophos and Linked Clones a little while ago - http://communities.vmware.com/message/1707837

If you read the discussion you'll see that I started off using the same KB article that you reference but ran in to a few issues, I'm guessing because I was missing that MsiExec post sync script. The VMs would check in to Enterprise Console ok but then would fail to pick the correct policies. I ended up going down the OU sync route and having Sophos monitor for new machines in the OU that View places its desktops. It works well, but as you've rightly pointed out it means that each Linked Clone has to have Sophos installed seperately rather than it being incorporated within the master image.

The next time I work on my master template I shall explore your very well documented option.

Out of interest, how do you handle the scheduling of updates within your VM environment?

We've elected to turn off auto updating entirely for our VM policy and use a Windows Scheduled Task to update each VM. These are setup using a script, which has to be run manually, so not especially efficient.

[JayArr]

We allow updates to run normally, every 5 minutes. When it becomes a concern, we'll break up the update schedule using slightly modified clones of the original update policy with different times.

We also use DFS file shares to balance update distribution.

[six4rm]

I've been playing with this deployment method today and thought I'd update you on my progress, so here goes.

First of all I had to change a few things in relation to the preparation script. The file locations are slightly different as my VMs are Windows 7 based, so the delete files part of the script is as below:

del /F /Q "C:\ProgramData\Sophos\AutoUpdate\data\status\status.xml"
del /F /Q "C:\ProgramData\Sophos\Sophos Anti-Virus\Config\Machine.xml"
del /F /Q "C:\ProgramData\Sophos\AutoUpdate\data\machine_ID.txt"

I'm hoping the above is correct anyway. I added the "machine_ID.txt" file purely because it mentions it in the Sophos KB article. Is there a reason why you've not got that in your prep script? Maybe that's why I'm running into a few issues later on!

The next change I made was within the services part of the prep script. Because I'm using a Customisation Specification within vCenter to prep my VMs rather than the View QuickPrep there is a brief period where the new VM has the machine name of the template. With the services set to automatic this was causing issues within Enterprise Console and all the machines would have a "Comparison Failure" error. I have set the three services to disabled as well as stopping them and then set a post-customisation script to change them back to automatic once the machine has its unique name. It also states in the Sophos KB about making sure the services are disabled until the machine has it's unique name. This was accomplished by adding the following to the services section:

sc config "Sophos Message Router" start= disabled

sc config "Sophos Agent" start= disabled

sc config "Sophos AutoUpdate Service" start= disabled

And the post-sync script:

sc config "Sophos Message Router" start= auto
sc config "Sophos Agent" start= auto
sc config "Sophos AutoUpdate Service" start= auto

Pretty simple really. After the services are set to auto your install script is run. The install script had to be changed slightly as the MSI location is within ProgramData, although the sub-folder structure remains the same. The machine is then rebooted so the services all start up upon reboot and it checks in to Enterprise Console for the first time.

With the above in place the machines appear to be checking in correctly, but they're stuck with "Awaiting policy transfer" and a warning to say that the machine requires a reboot. I've rebooted the machines multiple times but neither the warning nor the "Awaiting policy transfer" will go away. When you look at the machine details within Enterprise Console they don't appear to be checking in properly apart from immediately after reboot.

Any suggestions would be very welcome as I've been working on this for a few days now.

[JayArr]

Fantastic timing. I've just been handed a deadline to deploy our first pool of win7. Thanks for your detailed addition to this thread.

[VMMikeC]

I've been using the Sophos on my linked clones without any policy issue by following the exact steps in the link that's in this thread.

I stop the message router, agent and autoupdate service.....then delete the reg keys, and finally delete the machine_id.txt file. Every time I make a change the parent, that I plan to take a snapshot of for as recompose....i repeat these steps.

The only weird thing that I noticed today is 5 of my linked clones were showing me alerts in vcenter for CPU utilization, and in the Sophos console they were "awaiting policy"....Once I restarted them, they were "Same as policy". The weird thing is, they were spare clones....they have never been logged in by any user.I have Windows Updates disabled via GPO, so I'm wondering if it was something with Sophos that caused it?

[six4rm]

Hi, VMMikeC

How are your linked clones prep'd, Sysprep or QuickPrep? Do you set your services to disabled too? Also, how do you assign your VMs a policy within Enterprise Console? Win7 or XP? Apologies for all the questions.

I've never witnessed Sophos using lots of CPU resources within any of my VMs, linked clone or full. I guess it would have been good to look at Windows Task Manager to pin it down specifically to Sophos.

[VMMikeC]

I'm actually using Quickprep. I only stop the services. I do not set them to disabled. I'm running XP(32bit) and Win 7(64bit) clones. I have an OU in active directory for all my clones, and then I have a View policy within Sophos Enterprise Console and I assign that View policy to that particular AD OU

A good thing to note that I picked up along the way...prior to making the snapshot on the parent, I checked into Sophos to see if everything looked ok on the Parent VM. To clarify, originally my parentvm in sophos said "different from policy"...then once I made my clones, all of them said the same thing. To resolve, I updated the parentVM (update now) and restarted....once I did that, parentvm within sophos looked good. I took a new snapshot, then recomposed....and sure enough, all the clones were good to go from that point on.

Mike

Sent from my Verizon Wireless BlackBerry

[six4rm]

Thanks for the reply.

Good work replying from your Blackberry, that's some excellent forum dedication!

In terms of AD OU placement and Enterprise Console, that's exactly the same as me. All our View machines go into a particular OU which is then sync'd every 5 minutes into Enterprise Console. I originally had EC install Sophos automatically as soon as it found a new machine upon each AD sync. This worked well, but I really want to incorporate Sophos within the template, and of course each machine then required a reboot after install too.

I installed Sophos on my template VM through Enterprise Console. After a reboot it appears completely error free and complies to all policies. The only thing to note here is that my template sits within a different OU in AD and therefore a different container within EC, although the policies applied to the template OU and the View OU are the same. I might try moving my template into the View OU to see if that makes a difference.

[JayArr]

I keep my master vm's in a dedicated OU that is assigned the same policy as the snapshots.

Re: machineid.txt - I'll need to check my batch file - I could have sworn it was removing that file, but I have have missed it in my original post above. I'll look tomorrow and see what going on.

Thanks for pointing that out!

---

Jason

[VMMikeC]

I would have used the browser, but the internet on my blackberry stinks and this was just faster haha

Hmmm interesting. My parentVM actually sits in the same OU as my clones....however, since your policy is the same for both OUs, it should be a non issue. I will be moving my parents to a new OU soon enough, so I'd be interested in seeing if you notice any difference by having them in the same OU.

I actually have a batch file that I use to install Sophos. I do not install from the EC. I can paste the contents of the batch file if you'd like to see.

Sent from my Verizon Wireless BlackBerry

[six4rm]

A little update for you, so here's what I've found...

The prep of the image is the same, stop services and set to disabled, delete the registry keys and delete the machine_ID.txt file only.

Template in seperate OU to VDI Desktops

Post-customisation process: Set services to auto & reboot.

Result: Machine checks in but shows "Comparison failure" warning.

Post-customisation process: Run MSI & set services to auto & reboot.

Result: Machine checks in but shows "Awaiting policy transfer" and never complies with policy.

Template in same OU as VDI Desktops

Post-customisation process: Set services to auto & reboot.

Result: Machine checks in but shows "Comparison failure" warning.

Post-customisation process: Run MSI & set services to auto & reboot.

Result: Machine checks in and complies with policy. There is a warning to say that it requires a reboot, but I can live with that.

I find this rather weird as the policies within EC are the same for the two OU's. Interesting though.

[VMMikeC]

When they were in separate OUs, did you try to log into any of the clones? How long did you leave them there? I'm just wondering if it was a timing issue for EC to catch up

I forget, is this XP or Win 7? Are you using VMwares customization wizard for sysprep or importing your own?

Sent from my Verizon Wireless BlackBerry

[six4rm]

I left the clones for quite some time as well as logging in to them and rebooting multiple times, it didn't seem to make any difference.

They are Windows 7 VMs and I'm using a Customisation Specification within vCenter to Sysprep my machines. The post-customisation script is run via the "Run once" section.

[JayArr]

I used a Windows 7 master desktop that is joined to the domain and has a full, up-to-date sophos installation on it (and rebooted).

I use snapshot clones, so I didn't use a customization specification - I use QuickPrep to join the clones to the domain.

My batch file is called in the Post-synchronization script and I placed it in C:\programdata\sophos\scripts\deploy.bat to get it out of the root of the C drive.

I also left the services set on automatic, only stopped them to delete the files and reg keys before shutting it down to create the final snapshot needed.

So far, all of my Win 7 desktops have been arriving in the Enterprise Console in compliance or awaiting policy update while the services start. I do have a reboot warning - but I can easily fix that.

[VMMikeC]

six4rm,

Would it be possible to create a test pool using Quickprep just to see if you still experience the same issue? Try to narrow it down to a sysprep issue.

Not that it should matter but whenever I sysprep, I always import a custom script. That's the only reason why I asked.

[six4rm]

Funnily enough I binned my Sysprep customised pool last night and changed to Quickprep to test this Sophos deployment. I'll test out a few scenarios and get back to you.

[six4rm]

So here's what I've found using Quickprep as my customisation tool.

In each instance the prep work has involved the following:

• Set services to disabled
• Delete the two registry keys
• Delete machine_ID.txt

Template & Desktops in same OU

Post-customisation steps

• Services set to auto & started
• Reboot

Result

• Checks in to EC
• Complies to policies

Post-customisation steps

• Set services to auto.
• Run MSI
• Reboot

Result

• MSI didn’t run fully due to default 20 second script timeout.      Changed to 60 seconds.
• VM checks in to EC
• VM complies to policies

Template & Desktops in different OU

Post-customisation steps

• Services set to auto & started
• Reboot

Result

• Checks in to EC.
• Awaiting policy transfer. [Right click -> Comply with -> All group policies] resolves the issue.

Post-customisation steps

• Set services to auto.
• Run MSI
• Reboot

Result

• Checks in to EC.
• Awaiting policy transfer. [Right click -> Comply with -> All group policies] resolves the issue.

So it would appear that running the MSI makes no difference to the overall result. I've not tested simply stopping the services and leaving them on auto, that's one for next week, I've spent three days on this already!

I'm thinking that I'll have my template in a different OU and deal with the "Awaiting policy transfer" message. At least this time around you can force the compliance which I couldn't before using Sysprep. I'd like to have my script run before the snapshot is created using the "Power-off script" field. That way when the machine powers on for the first time after the snapshot the services are all ready to go and no post-customisation script is required. Or you could have a post-customisation script to force Sophos to check for updates (a script I already have) or something similar. This also means that I could start using the "Refresh on logoff" option.

What do people think?

[JayArr]

Could you share your Sophos update script? I plan on deploying kiosks with instant refresh on logout - that would be very handy!

I think you'll have better luck leaving the services set to auto.

---

Jason Thoms

Sent from a mobile device.