RSA Conference 2020 takes place at the Moscone Center in San Francisco February 24 – 28. The Conference offers five full days of educational training from experienced industry practitioners and is widely regarded as the world’s leading forum for cybersecurity professionals. Therefore, I would like to request approval to attend so I can gain an understanding of the latest industry issues and best practices that will help keep our organization ahead of the latest cyberthreats.
If I attend, I will have an unparalleled opportunity to learn about critical and emerging cybersecurity issues facing our organization through:
Hundreds of expert-led sessions and keynotes covering a wide range of topics
An in-depth look at the latest trends from industry leaders, plus end-user experiences shared by seasoned practitioners
Hands-on demos of the latest products and solutions from more than 700 exhibitors
High-level networking opportunities that will allow me to develop important relationships and contacts with vendors and other experts while raising our company’s profile
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.