Routine patching of systems and software is a crucial piece of any business’ information security strategy. Even so, many systems go unnoticed and unpatched for months, even years until an external threat forces the organization into action (e.g. the recent WannaCry ransomware outbreak).
When that happens, server administrators need to be prepared for irregularities they’re likely to encounter, such as a hang prior to reboot.
In this scenario, we’re going to assume that you’ve just finished patching and clicked the “Restart Now” button. You begin a continuous ping (ping -t [hostname/IP address]) and wait for the server to restart.
Let’s assume a normal reboot takes 5-10 minutes for this machine, and that 25+ minutes have passed.
You check the console, and are greeted by the “‘Preparing to Configure Windows. Do not turn off your computer” message. Time continues to pass while your maintenance window dwindles like falling grains in an hourglass… pressure is mounting, the business won’t wait. Time for action!
Logged in as an Administrator from your workstation check the Windows Module Installer service on the remote system…
Right-click “Services (Local)” and select “Connect to another computer …”
Make sure the “Another computer” radio button is selected and enter the hostname of the stuck server and click “OK”
Search for “Windows Module Installer” service and verify its status. If it’s “stopping,” then you will need to force it to stop. This can’t be done here, so we’ll need to query its PID and use our old friend TaskKill to manually kill the service
Query the Process ID (PID) of the Windows Module Installer (TrustedInstaller) service…
Open Command Prompt as an Administrator
Run the following command: sc \\[hostname of the server] queryex trustedinstaller
This will return (among other information) the PID of the stuck service, write it down as you’ll need it for the next step
Kill the hung service remotely using TaskKill…
From the Command Prompt already opened, run the following command:taskkill /s [hostname of the server] /pid [PID recorded above] /t
Revisiting an old friend as some date format junk was needing adjustment and leading 0s from txt file were being dropped. Script originally brought txt into xlsx and all data was “General” format. Tweak noted below brought all data into xlsx as “Text” format.
Needed to manage disks on 2019 Server Core. Received errors. Needed to modify firewall config on both target server and source server. Required to enable the following 3 rules on both target server that you want to manage and source server running the MMC.
Resolution was found in KB note from Exclaimer. Specifically the note to select the “Stop processing more rules” option to force the Exclaimer rule to run and to prevent Office 365 from running the *VENDOR* rule until the email is returned from Exclaimer Cloud with a signature attached. At this point, the Exclaimer Transport Rule will have its exception triggered by the Exclaimer message header once it returns, and the *VENDOR rule will be used instead.
Nice tip for Notepad from weekly email from Veeam’s Gostev.
How to Use Notepad to Create a Log File
Microsoft Notepad is a word processing tool included with Windows and is installed by default under the Accessories program group. You can use it to create a log-type file that adds the current date and time each time the Notepad file is opened. This article describes how to create a log file with Notepad.
To create a log file in Notepad:
Click Start, point to Programs, point to Accessories, and then click Notepad.
Type .LOG on the first line, and then press ENTER to move to the next line.
On the File menu, click Save As, type a descriptive name for your file in the File name box, and then click OK. When you next open the file, note that the date and time have been appended to the end of the log, immediately preceding the place where new text can be added. You can use this functionality to automatically add the current date and time to each log entry.
Good stuff to lock down access to Amazon WorkSpaces…
Amazon WorkSpaces now provides you with the ability to control the IP addresses from which your WorkSpaces can be accessed. Using IP address-based control groups, you can define and manage groups of trusted IP addresses, and only allow users to access their WorkSpaces when they’re connected to a trusted network. This feature helps you gain greater control over your security posture.