New Sophos Support Phone Numbers in Effect July 1st, 2023

Gold image methods clarification

I appreciate this has already effectively been asked in the following post.

 set up gold image to be deployed 

The case I'm looking to use this on is for a VMware template, so having the server template VM with the goldimage option. When new VMs are deployed from this template and get sysprep etc. with a rename as part of that (expected to happen within the timeout period). Then my understanding is that when they register in Sophos Central they will be seen as NEW devices with no link back to that original templated device in Central. Is that correct? So they would be the same as if someone had just created a new server VM and installed Sophos Central from scratch? For this use case I'm not doing any VDI, or non-persistent related work, it is for simple server VM deployment use (that will be live for many years).

Please can someone confirm that after a successful rename and new identity, that the server then doesn't do any "check for identity" timeout? That this is limited to just the template "goldimage" device?

Or given the above use case, would I be better using the older scripted method, rather than the "--goldimage" option method?

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. Thanks.



Edited TAGs
[edited by: Gladys at 5:58 AM (GMT -7) on 30 May 2023]
  • Been doing some testing - I think I've answered some of my own questions.  It does look like they do get a new identity OK with no link back.

    For the "after a successful rename and new identity, that the server then doesn't do any "check for identity" timeout" question - in the log it shows as "Endpoint cloned from gold image named SERVERNAME" and that is the last time it references it.

    However I have now noticed that the way tamper protection is dealt with (at least for me) needs more specific guidance.  It is this that has caused me most trouble - with the "Windows could not finish configuring the system. To attempt to resume configuration, restart the computer." message in the majority of cases, as tamper protection has ended up being back on during those initial boots.  Still doing some more testing and will post back later.

  • 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?

    RichardP

    Program Manager, Support Readiness | CISSP | Sophos Technical Support
    Support Videos | Product Documentation | @SophosSupport | Sign up for SMS Alerts
    If a post solves your question use the 'Verify Answer' link.

  • 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."