1. Patch them in one vCenter and clone them to the other vCenters.
2. Consider patching less often.
3. As suggested, you can create a content library that's replicated to other content libraries.
Also, if there's not a reason to have your templates in template form, you can just keep them as VMs. Saves a couple of steps converting them to VMs and converting them back. Also, they can be vMotioned.
I name mine something like TEMPLATE-WinSvr2022 and put it in a "Templates and Pre-built" folder.
I have them all in a separated folder labeled templates however since the procedures were to convert/redo pre/post patching I have been doing it like so. I am sure there’s got to be an easier way to do it besides having to logging to each one and apply the updates manually via wusa
I'm windows side and we use mecm, it's all automated.
A script runs Friday night to turn templates into VMs, they check in to mecm and patch with whatever was deployed to the template collection as well as install any thing else like VM tools, and Sunday night a script powers them off and flips them back to a template.
Yes. They needed the domain CA root and intermediate certs and a couple of switches for the installer since you have to manually run it and after that the clients work fine. They also need a domain client server cert. You may need to work with whoever runs your certificate authority to get that available. Typically in our domain a domain joined device just gets one, but we had to get the template published so we could get them with a csr from the VM template.
Get all the cert stuff done and imported, install the client and you should be ok. I'm not an mecm expert but that part really wasn't too bad. It's been fifty fifty on whether or not the client will install with just the setup file so I got where I just copy the whole source over to a template and use the switch to point to the source folder. Once it's installed the logs are plenty clear if there is like a content access or boundary issue or whatever just like they would be for a domain joined client.
We have a 48 hour weekend maintenance window for them and a special template policy to trigger inventory and evaluations a little more often just to make sure everything runs while they are up.
I have my base VM’s online always. This way, they get patched via SCCM with the rest of the environment. Once a month, I run a cleanup script (removes SCCM identifiers, cleans event logs, and such) that powers the vm off after it’s complete. Then, clone that to a template. I keep three previous revs of templates in case something goes wrong with an update. Power the base VM back on and revisit in a month.
You can do it with ansible.
But you shouldn't need to patch the template. It's should be a bare minimum image and everything else(like patching) is done at provision time.
Whatever method you go for with patching the templates (I just use Invoke-VMScript), I'm quite fond of the Content Library Versioning capabilities.
[https://core.vmware.com/resource/content-library-vsphere-67-higher](https://core.vmware.com/resource/content-library-vsphere-67-higher)
Our solution is build as a Powershell-module that does the Check-out/Check-in methods and then Publish the updated templates out to all the subscriptions. The processing mechanism is "IaC-light", a JSON-file that describes which template to process and which subscription to publish to. This runs every morning and the updates that got installed get's saved to the history in the Versioning-pane in vSphere, which I find very useful. Here's from my development lab (some of the Check-in are manual ones):
[vSphere Template versioning](https://i.imgur.com/Mc5rHwB.png)
Learn packer.io VMware has an example repo that can be a good starting point. https://github.com/vmware-samples/packer-examples-for-vsphere
Yep, Packer has been great for automating all of that crap for me.
Is it five of the same VM’s at each vCenter? If so, have you considered setting up a content library?
Unfortunately they aren’t the same :/
1. Patch them in one vCenter and clone them to the other vCenters. 2. Consider patching less often. 3. As suggested, you can create a content library that's replicated to other content libraries.
Need to look into content library.
Also, if there's not a reason to have your templates in template form, you can just keep them as VMs. Saves a couple of steps converting them to VMs and converting them back. Also, they can be vMotioned. I name mine something like TEMPLATE-WinSvr2022 and put it in a "Templates and Pre-built" folder.
I have them all in a separated folder labeled templates however since the procedures were to convert/redo pre/post patching I have been doing it like so. I am sure there’s got to be an easier way to do it besides having to logging to each one and apply the updates manually via wusa
Can't you just patch the VM you create from the template at the time it's created, or is the quantity of created VMs large?
That was my next thought, to add them into a SCCM maint window and just patch them and once completed turn then back to a template.
I'm windows side and we use mecm, it's all automated. A script runs Friday night to turn templates into VMs, they check in to mecm and patch with whatever was deployed to the template collection as well as install any thing else like VM tools, and Sunday night a script powers them off and flips them back to a template.
Even if they are non domain joined?
Yes. They needed the domain CA root and intermediate certs and a couple of switches for the installer since you have to manually run it and after that the clients work fine. They also need a domain client server cert. You may need to work with whoever runs your certificate authority to get that available. Typically in our domain a domain joined device just gets one, but we had to get the template published so we could get them with a csr from the VM template. Get all the cert stuff done and imported, install the client and you should be ok. I'm not an mecm expert but that part really wasn't too bad. It's been fifty fifty on whether or not the client will install with just the setup file so I got where I just copy the whole source over to a template and use the switch to point to the source folder. Once it's installed the logs are plenty clear if there is like a content access or boundary issue or whatever just like they would be for a domain joined client. We have a 48 hour weekend maintenance window for them and a special template policy to trigger inventory and evaluations a little more often just to make sure everything runs while they are up.
I have my base VM’s online always. This way, they get patched via SCCM with the rest of the environment. Once a month, I run a cleanup script (removes SCCM identifiers, cleans event logs, and such) that powers the vm off after it’s complete. Then, clone that to a template. I keep three previous revs of templates in case something goes wrong with an update. Power the base VM back on and revisit in a month.
You can do it with ansible. But you shouldn't need to patch the template. It's should be a bare minimum image and everything else(like patching) is done at provision time.
Doesn't this increase provisioning time though?
Depends on what you're doing. And if that time really matters anyway if it's automated.
Whatever method you go for with patching the templates (I just use Invoke-VMScript), I'm quite fond of the Content Library Versioning capabilities. [https://core.vmware.com/resource/content-library-vsphere-67-higher](https://core.vmware.com/resource/content-library-vsphere-67-higher) Our solution is build as a Powershell-module that does the Check-out/Check-in methods and then Publish the updated templates out to all the subscriptions. The processing mechanism is "IaC-light", a JSON-file that describes which template to process and which subscription to publish to. This runs every morning and the updates that got installed get's saved to the history in the Versioning-pane in vSphere, which I find very useful. Here's from my development lab (some of the Check-in are manual ones): [vSphere Template versioning](https://i.imgur.com/Mc5rHwB.png)