ComputerManagementDsc
ComputerManagementDsc copied to clipboard
xComputer: postpone computer restart
Sometimes a configuration performs several changes that require a reboot, but not immediately (changing computer name being one of them)
It would be useful for xComputer to be able to raise one of the flags checked by the xPendingReboot
instead of simply setting $global:DSCMachineStatus
, in order to enable configuration to control when a reboot occurs.
This might be possible I think - but we'd want a new config entry to specify the behavior so that this wasn't a breaking change.
e.g.
[ClassVersion("1.0.1.0"), FriendlyName("xComputer")]
class MSFT_xComputer : OMI_BaseResource
{
[key] string Name;
[write] string DomainName;
[write] string JoinOU;
[read] string CurrentOU;
[write,EmbeddedInstance("MSFT_Credential")] String Credential;
[write,EmbeddedInstance("MSFT_Credential")] String UnjoinCredential;
[write] string WorkGroupName;
[write] boolean FlagPendingReboot;
};
The FlagPendingReboot would default to false. But if set to true would set one of the other flags indicating a reboot is required.
I'll see what I can do - got a bit of a back log to get through at the moment.
@PlagueHO I'm currently on holiday, but I'd be more than happy to implement this when I get back. Just let me know which reboot flag would you prefer to use (it'd probably best to use the same one when making the change from GUI - I just need to find which one it is :-)
I've had a bit more of a look into this to try and figure out which is the best flag to use for triggering a reboot (based on what xPendingReboot looks for). The best one to use would have been the test to see if the computer needs to be renamed, but the problem is that it won't work when a machine is added or removed to a domain or workgroup.
I'm not completely happy using one of the ComponentBasedServicing or WindowsUpdate keys either as this feels like it could be unreliable.
The ideal solution to this would be to actually update xPendingReboot to also detect when a reboot is required for domain join/unjoin. But changing xPendingReboot, although easy, will require a fair amount of cleaning up before I'll be happy working on it.
Would it make sense to separate the problem? If xComputerManagement changes the computer name, it will change HKLM:\System....\ComputerName\ComputerName value. xPendingReboot will honour that.
I assume there's a similar registry flag or value for domain (un)join and workgroup name change. If xComputerManagements sets it properly, we can say that xPendingReboot should/will support it in the future...
Or maybe make FlagPendingReboot flag support only computer name change for now (and document it, of course)?
(Full disclosure: I only need xComputerManagement to support flagging computer change events, so I'm being a bit selfish here :-)
Oh right - well theoretically making the change is reasonably trivial then if you're not needing the change to xPendingReboot.
I still plan on working on xPendingReboot because it is really out of date and doesn't meet current standards, but if you don't specifically need xPendingReboot to respond to a domain (un)join then I don't see why we can't just add a SupressRebootFlag
parameter to this resource.