Start a Conversation


This post is more than 5 years old



June 4th, 2015 07:00

2 questions about OS Images Deployment and Patching

2 questions about OS Images Deployment and Patching

We use an HQ server on a datacenter to store images and serve linked sites.
At this time, we have only 1 linked site - our central office, where we create images and use it to serve our Cloud PCs (and more linked sites in the future).

Now, the logical process to create a new image would be:
- Prepare an image at my LS (can't work in the datacenter)
- Upload the file at HQ and import it
- Delete the original image at LS
- Assign the image at HQ to the correct site template
- Wait for the image to be transferred back to the LS (that could be more than one).
- Serve thin clients

I wonder what happens if I assign the image to the site template at HQ without prior deleting the original image at LS. Will the LS receive another copy of the same image or does WSM "recognize" that this is the same image?

Then, when I need to patch an image I work on the reference device at Linked Site.
There is an option (Allow HQ Image Patch at Linked Site) that allows to patch HQs images at linked sites. I wonder if, after committing the changes, delta file is automatically uploaded to the headquarter and image is automatically updated or if I need to manually upload the delta file and do some other operation.

Thanks to all

(P.S. --> As I'm using only 1 WSM site, in real life I do not use HQ at all, and I'm keeping my images on the linked site, applying patches using the standard procedure. I'm asking this questions because the link between my central office and the datacenter is not that fast, so I never really tested HQ -> LS transfers, keeping the image defined only at LS, as it was a standalone installation...)

200 Posts

June 15th, 2015 06:00


Your use case of having the HQ Core server in a remote Datacenter with no local clients for OS Image creation or patching available was the reason for a couple of enhancemments we already implemtented in WSM 3.6 

The procedure depends on whether you want to use the OS Image only in the Linked site it is created/patched, or if you want to deploy these to other sites too.

On the Systems Settings / Site Configuraion pag is an option called "Locally managed sites" which allows full flexibility at a remote site. The Administrator can create OS and Application patches at any remote site as if it were a standalone site. If this option is selected, then the option "Preserve Linked Site Local Data" is automatically selected too. A Site Template is required for this option, but it can be empty. If the Site Template is not empty, then its configuration is applied to the Locally Managed Site. If you do not want to use this OS Image in any other site, you just keep it locally and do not have to modify the Site Template at all.

If you want to deploy this OS Image to other sites you need to enable the "Allow HQ Image Patch at Linked Site" option on the System Settings page of the HQ Core server first. 
Next you have to copy the Image manually to the StreamingDir of the HQ Core server and then register it with the same name as used at the Linked site it has been created at (this will ensure the Image will not been copied down to the source site again, so this is important!). 
Then you need to assign the OS Image to the Site template schedule its deployment and publish the template afterwards.
When the source site now syncs up with Headquarters it will know that it should download the OS Image, but as it is already present at it’s local StreamingDir, it will just do a checksum comparison. Other sites will download the OS Image to be in sync with the template.

So the logical process to create a new image in a Linked site and roll it out to other Sites would be:
- Enable the options for "Locally managed sites" and "Allow HQ Image Patch at Linked Site"
- publish the template so the above changes are deployed
- Prepare the image in the source site
- Upload the file at HQ and import it
- Assign the image to the site template
- publish the site template and wait until the synchronization has been finished and the OS Image has become enabled.
- Serve thin clients

The procedure to patch an HQ Managed Image at a Linked site is included below:

- Patch the OS Image at the source Linked site. 
- You will be able to finalize and activate this patch at the locally managed linked site, but the patch will not be enabled. Patch will also not be distributed to Edge servers of this linked site, nor will the patch be pre-processed. 
- Manually copy the patched Image and corresponding delta file to HQ Core Servers StreamingDir directory. 
- Register this OS Image Patch with existing delta on HQ. Make sure that name of OS Image Patch registered at HQ exactly matches with name of OS Image patch that was registered at Linked site.
- After patch is validated at HQ, it will be pre-processed and enabled for distribution. 
- Any Linked site assigned to the template will schedule patch for deployment after their content scheduling sync period. Please note that the linked site where patch was originally generated will also schedule patch for deployment.
- After patch has been deployed/enabled on Linked site core servers, it will be scheduled to be deployed to linked site streaming servers.

200 Posts

June 15th, 2015 08:00

The transfer will be skipped if the name is the same and the CRC Check is successfull.
It is the same logic as deploying Images to Edge servers from an USB Stick and not doing the copy over the network: if the file in the disk has the same name, copy will be skipped and CRC will kick in immidiately.

June 15th, 2015 08:00


Thanks a lot! 

June 15th, 2015 08:00

Hello mhaase, and thank you very much for your detailed explanation! 

About this point: 

Originally Posted by mhaase 
Please note that the linked site where patch was originally generated will also schedule patch for deployment.

I do not understand if the patch will be deployed and transferred to the Linked Site where it was created too, or if this transfer will be skipped because it has the same name. 
Thanks again! 

No Events found!