Posts made by GeorgeBells

I have accidentally deleted some files from the Plugins folder, is there a way to get these back?
Thanks

@george1421 Hey. Finally got around to looking at this again. Is it possible you have made any updates to the plugin since?

@george1421

Do you have any other advice on this? Haven’t had much chance to play around with it lately but hoping to revisit it soon

@george1421

Interesting…

I’ve been going to the fog web management > plugins > installed plugins and uninstalling persistent groups…

I have then gone into install plugins, and reinstalled it.
I have also tried going to install plugins, deleting it, back to activate plugins, activating it and installing.

@george1421

Makes sense - Edited my previous response because I immediately realised this is likely the case, just to clarify incase I did word it wrong, I had been reinstalling just the plugin through the UI, not fog itself.

@george1421

It does, it has todays date.

@george1421

This is the output for mysql - After inserting that file, restarting the apache server, uninstalling and reinstalling the plugin

Hi

I’ve just tested this an it worked without issues - Thank you. I will try to post the contents of those files shortly. My question is, is this new init file good to be made the default somehow?

Hi

I’ve just tested this an it worked without issues - Thank you. I will try to post the contents of those files shortly. My question is, is this new init file good to be made the default somehow?

@george1421 Any progress on this? Sorry to pest, I do appreciate the work you are putting into this

Re: Error trying to restore GPT Partition tables (restorepartitionTablesAndBootLoaders)

Sorry if this has been answered elsewhere but I’ve had trouble finding any mention.
I’ve ran into the same issue as the post above - I have a 20H2 image, trying to deploy to a machine with a smaller drive with the following error

Error trying to restore GPT partition tables (restorePartitionTablesAndBootLoaders)
Args Passed : /dev/sda 1 /images/IMAGE_NAME 9 all
CMD Tried : sgdisk -gl /images/IMAGE_NAME/d1.mbr /dev/sda
Exit returned code : 4

As I’ve read from the crosspost thread, ‘The developers have discovered with v2004 Microsoft changed something causing the recover partition to not relocate correctly when deploying to a smaller disk than the golden image disk’ - Appears to be an issue with the recovery partitions of Windows 2004 and onwards.

Has there been any movement/update on this since a year ago? Again apologies if I’m missing something but the most recent mention of this is August 2020.

@george1421 Yeah that’s all good - I’ve not touched the groups since making your change.
The snapins do get associated to the new host, just not tasked to installed.

@george1421 I’ve just tried that new plugin file, unfortunately it doesn’t seem to have made any difference.

I’ve renamed the original file, downloaded and placed new one in the same location and uninstalled/reinstalled the plugin through FOG.

Then imaged a machine, it hasn’t created any queued tasks under the host and I can’t see that the snap-ins have been installed or are being installed

@george1421 Hi George, sorry to pester. Have you any update for this?

@george1421 Alright no worries - Let me know.

I should have time to test today

@george1421

Brilliant, thanks for that. I’m not in a position to test it out today but will be tomorrow, I’ll give it a try and get back to you.

@george1421 Thanks for looking into this - The changed code you’ve mentioned earlier, did you get a chance to fix whether this would work? It would be fantastic if it possible to have the persistent groups also task the host to deploy any snap-ins/printers etc etc.

@Tom-Elliott The general point is to register a brand new host, assign it to a group, which is linked to a host via persistent groups and not only have it assign snap-ins etc to the host but also create a task to deploy them… Registering, imagining and deploying all assigned snap-ins as part of the initial register process. We have a few pieces of software which I would like to be on every machine installed, but not included in the image due to the way they work, it being best to install after the machine name has changed and etc etc.

Thanks to both of you for the time you’ve spent on this so far.

As far as I can tell, as mentioned previously the persistent groups plugin does apply the settings to the host but does not deploy them

I don’t know if it is possible to request any ‘fix’ for this?

Re: Associate all new hosts with Snapin

I read through the linked thread above, and it seems there may be a known issue with settings applied to a host via the use of the persistent group plugin are not actually deployed when imaging.

I’ve set up the plugin and my templates. Assigned a snap in and image - When registering a host it picks up the correct image and deploys, Snapins however are not. I cannot see any events under snapin history for the new host either

Is this something unavoidable? I can manually task snapins to be deployed via the group after imaging, but ideally snapins would be deployed as part of the imaging process