Harrison 
Windows and reboots – Many candles have been lit on both ends to understand and resolve this relationship. Like it or not, despite Microsoft’s efforts, Windows is the fastest rebooting operating system.
I have to write a lot of code related to this, but is it possible to add new contributions of real value?
I think I accomplish this by striving for compactness while concisely explaining my unique context of automating DevOps software deployments in the cloud.
Get-PendingReboot tradition and new reboot detection
A long time ago I wrote an earlier version of this code using some of the core reboot conditions extracted from bcwwilhite’s long-standing Get-PendingReboot solution. The code has been significantly compressed to optimize it for my scenario.
Recently, the goal behind an automation I was creating was to detect when a restart was pending because I removed Windows Defender while installing an alternative solution, so I needed to access it again. did. I found that Get-PendingReboot does not detect this type of pending reboot. The code included here has been updated to detect restarts by file contents. (Note that this can also be detected by running uninstall-windowsfeature for a feature that you know has already been removed, and the return value will indicate whether a previously triggered reboot is pending. (but it’s hard to write this as a general solution) Never do anything wrong. )
What does “automating DevOps deployments” mean?
When designing DevOps solutions, I focus on writing code that is compact enough to reside. At the inner In fact, the central goal is often a single script. This gives you flexibility such as being able to easily run it directly from your source code repository, and we support this because having to push files can add a whole new level of complexity to your automation. It can be easily distributed as inline code in your orchestration system.
In most cases, DevOps Software Deployment Automation runs directly on the nodes being automated. Therefore, as part of the compaction, we eliminated the remote execution functionality of Get-PendingReboot. As a general solution, remote operation is a great feature, but it adds a significant amount of code.
Additionally, Get-PendingReboot contained critical code that handles SCCM restart checks. This is also a great feature for general solutions, but he had never seen SCCM used for software deployment in a DevOps toolchain, so it was removed.
Code compression: smallness and embedding over style and readability
Compressing code forces size beyond general style and readability guidelines. I do this because:
- Because code is so often included in so many things,
- Due to its simplicity, updates are rare.
Compressing and including also avoids shared code hell by testing and isolating the code in each solution that uses the template code. If the code is embedded (a type of isolation) and operates under the test of a particular automation solution, updating the template code will not be used by previous solutions that utilized it, thus breaking existing automation. this is not allowed. Even if the code is not embedded, it must be separate. If the code is in a script file it must be dot sourced, or if it is a module it must be loaded by filename from a local location. This separation method avoids installing modules into a shared module folder on the target machine.
Not sharing code between automation solutions truly unlocks freedom and flexibility from backward compatibility engineering and regression testing.
Remember, I’m building developer automation tools for a SaaS company with tens of thousands of instances, thousands of developers, and hundreds of products. You can’t afford to assume or manage every instance to a standard set of runtimes. You also don’t have the luxury of knowing what additional tools your code depends on.
However, I’ve taken the same “prefer separation” approach in an environment where I have more control, and there were still significant benefits to preferring code separation.
code
The Test-PendingReboot code below is a compressed function. You can remove comments if you want to make it more compact. A usage example is also provided.
Function Test-PendingReboot
Select -Expand 'ComputerName')) -OR
#Domain Join Pending
((Test-Path "HKLM:SYSTEMCurrentControlSetServicesNetlogonJoinDomain") -OR (Test-Path "HKLM:SYSTEMCurrentControlSetServicesNetlogonAvoidSpnSet"))) -OR
#WindowsFeature install or uninstall has a pending reboot
((test-path c:windowswinsxspending.xml) -AND ([bool](get-content c:windowswinsxspending.xml
# Sample Usage
If (Test-PendingReboot)
Write-Host "Shutting down in 10 seconds (giving time for orchestrating automation to close out)..."
shutdown.exe /r /t 10
Else Write-Host "A reboot is not pending, no action taken"
CompactDevOpsRebootWindowsIfNeeded.ps1
