Gold image methods clarification

Couple of points for awareness that I think are valid, but happy for Sophos to tell me otherwise.

When using the new method (goldimage parameter) the VM starts with a random name while it does the initial generalization/sysprep work. I think when the "Sophos MCS Client" starts, it then notices that the name has changed, logs "Endpoint cloned from gold image named SERVERNAME" in the McsClient.log, at which point it registers as a new device in Central. Then the VM gets renamed, rebooted etc. and the proper name ends up in Central.

When using the old scripted method, as the "Sophos MCS Client" service is set to delayed auto-start, it likely doesn't start until the VM has the expected new name, so gets registered in Central with the expected name from the outset. This delayed auto-start state persists on clones, but I expect that with product updates that might end up getting set back to default auto start rather than delayed (at some point).

The tamper protection side of things

Tamper protection with the script method. The enable tamper protection at the end of the script means that when booting a VM deployed from a template, it gets the "Windows could not finish configuring the system. To attempt to resume configuration, restart the computer." behaviour. I'm sure I remember reading somewhere that this is because the generalization/sysprep process is trying to update registry keys that Sophos isn't allowing if tamper protection is enabled. If tamper protection is turned off from the Central portal itself, and the line in the script is commented out, then it does seem to work. New VMs cloned from this automatically get tamper protection enabled again by default as they are new devices and get the base policy. So effectively the lines in the script to do with tamper protection could be removed, on the assumption that it is going to be turned off via the Central portal instead.

Tamper protection with the goldimage parameter is effectively the same. But there isn't anything in the guidance to say about disabling tamper protection for this method. I appreciate that VDI/Citrix behaviour might be different to the scenario here, but the goldimage parameter documentation is being pushed as the replacement for the script method. It would be good to include something in the documentation about this to help people avoid this issue. From testing, if disabling tamper protection from the endpoint itself, that only lasts 4 hours, and means that you can deploy from the template OK for 4 hours. But then the Sophos components on the clone must have the date/time of when "Central management has been suspended" and if it is 4 hours after, then for new deployments from the template you get the "Windows could not finish configuring the system..." behaviour again. I expect the same issue would be seen with the script method if tamper protection was turned off on the endpoint itself. I've found the best way is to disable tamper protection on the template via the portal, make sure it has taken effect, and then power down and convert to template. New VMs cloned from this automatically get tamper protection enabled again by default as they are new devices and get the base policy.

HI pat-sc8383

You're correct on al these points. I will take a look at the article again.

The way the goldimage parameter works is it stores the name of the endpoint when you do the prep into the registry. It checks the name of the system for a time after boot and it the name isn't what is marked in the registry it knows its a clone and needs to register with Central again.

Tamper protection is a harder issue. I can understand your thought that it shouldn't apply to syspreping machines with the goldimage - but there isn't any secure way for us to know that. You found our current solution - turn on Tamper Prot for new machines and then apply it after the prep is done. 

I will talk to the PM about maybe having a tamper prot disable switch in the gold image prep - to give a prepping image a while to go through its stuff before we enforce the policy.

Do you have any other questions?

Hi Richard,

Thanks for the confirmation. The whole tamper protection issue might be specific to VMware are doing the generalization/sysprep steps, as I've not tested how it behaves with SCCM or anything else.

No further questions, other than just repeating my point about it being useful for KB's and other docs to have both last modified and created date. Thanks.

"Also I see in the post above, the statement "The older content remains for reference purposes should customers have a need for it." - it would be useful if KB's and pages on docs.sophos.com could have both the last modified date AND the created date. This way it is easy to see whether you are looking at an old method that has recently had an update/modification to the content, or just newer content in general."

Hi Richard,

Thanks for the confirmation. The whole tamper protection issue might be specific to VMware are doing the generalization/sysprep steps, as I've not tested how it behaves with SCCM or anything else.

No further questions, other than just repeating my point about it being useful for KB's and other docs to have both last modified and created date. Thanks.

"Also I see in the post above, the statement "The older content remains for reference purposes should customers have a need for it." - it would be useful if KB's and pages on docs.sophos.com could have both the last modified date AND the created date. This way it is easy to see whether you are looking at an old method that has recently had an update/modification to the content, or just newer content in general."