Some of you will know that Sophos is my, ahem, favourite anti-virus product. However it was the product of choice at the time (they are now moving to McAfee) for a large school district I deal with hence I had no choice but to remain acquainted with it irrespective of it’s poor performance (Sophos have advised to leave real-time scanning *off* for performance reasons?!?), it’s poor management console (customer had to write their own deployment scripts for reliable deployment) and poor customer service from Sophos.
I wrote a small script to prepare Sophos for PVS deployment on XenApp and XenDesktop machines, run this script just prior to shutting down your Private mode image and switching back to Standard.
REM Script by Daniel Marsh
REM run at shutdown to prep Sophos on Citrix XenApp/VDI machines.
REM refer to https://www.sophos.com/en-us/support/knowledgebase/12561.aspx
net stop "Sophos Agent"
net stop "Sophos Anti-Virus"
net stop "Sophos Anti-Virus status reporter"
net stop "Sophos AutoUpdate Service"
net stop "Sophos Message Router"
net stop "Sophos Web Control Service"
net stop "Sophos Web Intelligence Service"
reg delete "HKLM\SOFTWARE\Wow6432Node\Sophos\Remote Management System\ManagementAgent\Private" /v pkp /f
reg delete "HKLM\SOFTWARE\Wow6432Node\Sophos\Remote Management System\ManagementAgent\Private" /v pkc /f
reg delete "HKLM\SOFTWARE\Wow6432Node\Sophos\Messaging System\Router\Private" /v pkp /f
reg delete "HKLM\SOFTWARE\Wow6432Node\Sophos\Messaging System\Router\Private" /v pkc /f
When I have a spare few minutes I may even see if I can another feature – it could be run via GPO as a machine shutdown script that only executes if the image is in private mode, which would save you having to run it manually. I haven’t figured out how to do this yet, if you do know please drop me a comment below.
Refer to https://www.sophos.com/en-us/support/knowledgebase/12561.aspx for more detail on what each key/service etc does.
A client was trying to setup a lab of HP T610 thin clients to stream Windows 7 from Citrix Provisioning Services 6.1. The T610 they used to create the image worked flawlessly, they captured the image, and could then stream it back fine in private or standard mode. The issue appeared when they went to stream it to more than one T610 – while the original machine worked fine, on every other T610 they tried it would blue-screen on startup with the dreaded 0x0000007B error.
“It’s probably something really simple” I said – famous last words – and set about checking for differences between the T610s in the BIOS settings, firmware versions and so on, deleting and recreating machines in the PVS console, recreating the AD accounts and more. I was already familiar with the “ghosted network card” issue (CTX133188) but this was not the issue. A couple of hours later and no “simple” fixes in sight – I eventually stumbled across this thread and on page 4 one of the posters references MS hotfix KB2550978. I booted the VHD in Hyper-V, removed the PVS Target Device software, installed this hotfix and reinstalled the PVS Target device – problem solved!
The issue is the T610 clients support a feature called “PCI Express Serial Number Capability” so from PVS’s point of view, the network card in every individual T610 is seen as a new NIC and needs the driver installed before it can boot successfully. But as it’s trying to boot across the network, this causes the 0x0000007B error. Not many clients I have come across stream to physical desktops, so this probably won’t impact too many people, but I hope this info helps someone out!
I had a previously stable XenDesktop farm start having issues today, with the client saying they could not connect to any of the Windows 7 desktops in their farm. A quick investigation revealed most of the desktop VMs had been placed in maintenance mode by the Desktop Delivery Controller. It will do this automatically if the VMs do not register after several reboots, see CTX126704 for the registry entries that control this behaviour.
After much investigation looking at the PXE and TFTP services on the Provisioning Servers, checking DHCP scopes weren’t full, confirming switch ACLs and VLANs were correct and more, I found the setting on the DHCP server for Conflict Detection had been recently enabled. It was set to 2 attempts, but it seems this setting caused enough of a delay that the VMs would time out trying to PXE boot. Once the setting was reverted to zero everything was back to normal.
Note that this client’s XenDesktop setup was XenServer 6.0.2, and the XenDesktop VMs were in the same VLAN as the Provisioning Servers so the client VMs could just broadcast to receive the PXE settings. This is one of the preferred options for enabling TFTP high availablility as per Citrix Blog post by Nick Rintalan last year here (option 4 in his post).
I haven’t yet checked to see if this issue manifests itself in all environments, but now that I’ve seen it I recall having similar issues at another site where we couldn’t get PXE boot behaving reliably and we ended up handing out the TFTP server via DHCP options 66 & 67. Hopefully this helps if you are troubleshooting a similar issue, and I’d be keen to hear from anyone that has the same issue and whether my fix above worked for you.