I’ve been working on installing Windows Server 2019 Core into my network to be able to look at new features for Windows Administration and learning how Server Core works. I was able to install a virtual machine with Server Core and get it activated. I then wanted to place my custom PowerShell script for loading PowerShell into the Server Core Environment.
So, I added the Server Core Server to the Windows Admin Center and copied my custom scripts for PowerShell into the proper directory:
I then logged on remotely to the server and started PowerShell. When I did that, I got this error with the script load:
At first, I tried using the -UseBasicParsing as a switch to see if that would repair the issue in the script. It did not because, IE is not installed by default on the default installation of Server Core. That is so there is less of a footprint that can be attacked by a hacker. I needed this installed though so that the Invoke-WebRequest cmdlet would load my script parameters properly.
I started looking for answers to how to install IE onto the Server Core box and found the following article. I had to run the Add-WindowsCapability cmdlet on the server to install the optional components. When I did, I received an error:
So I found out that there is a block that WSUS does keeping the cmdlet from going to the online source to download the software package and producing this error. After researching, I found this article. I setup a Group Policy to make sure this setting is propagated to my Server Core machine. I also setup in the same policy the ability to turn off the First-Run for IE so that you do not get that message and have to open IE to “set it up”
I then ran a gpupdate /force on the Server and was able to download the components for IE and App Compatibility.
I then rebooted the server and now my PowerShell loads successfully:
I learned a few different new things here and was able to get Server Core working more the way that I like it. I will keep posting updates when I run into issues with this type of installation. I would definitely give the Windows Admin Center a try as it has more robust features than Server Manager has, especially for Server 2019 and Server Core.
CONQUER THE UNCOMFORTABLE TO GROW! POSITIVE ATTITUDE ABIDES!
I had recently had this error in WSUS where my Windows Server 2016 servers would NOT report into the WSUS Server. I would get an error stating 0x8024401c when manually performing a report now to the WSUS Server using:
WSUS Fix for 2016 Servers Not Reporting
Go to IIS Manager on the WSUS Server
Goto Advanced Settings of WsusPool.
Make sure following settings are present/configured on the Pool, if not change it to below:
WSUS AppPool Settings
Make sure, the WSUS Entry in the Registry is having fully qualified domain name of WSUS Server.
NOTE: If you have Group Policy managing the WSUS Settings, then make sure you change the settings in the WSUS Policy to use the FQDN of the WSUS Server and run a gpupdate /force on the clients.
Stop IIS on the WSUS Server
Edit the web.config located at following location on WSUS Server:
I had an issue last night where a server lost Secure Channel Connection to the PDC Emulator (NETLOGON Event IDs 5719 and 5783). All tests to test the secure channel via PowerShell were failing. (i.e. nltest or Test-ComputerSecureChannel cmdlets) The server essentially needed to be rebooted. I had a dumb dumb in my brain and forgot to check to see if there were any pending Windows Updates, because those need to be installed at the proper time and to a schedule. So, when I ran the following command to reboot:
shutdown.exe/r/t000/c"Rebooting DC01 Due To NETLOGON Errors"
The Windows Updates were installed inadvertently which could have caused even more issues if they were NOT approved or caused another failure on the server. TO NOT DO THIS IN THE FUTURE, remember to run the following command to shut off the Windows Update Service BEFORE initiating the reboot of the server:
net stop wuauserv
But, the deed was done. NOW, I had to find out quickly what updates WERE installed via PowerShell so that I could alert the proper folks and give them a heads up on possible issues. Luckily, the server did NOT have any issues and the initial problem with NETLOGON was resolved. Here is the command I ran to find out the installed hotfixes filtered by today’s date:
wmic qfe where"InstalledOn = '2/26/2019'"list full
Since there were no issues, I was able to resolve the incident. I did notify the account team though of the inadvertent installation so that they could revert the changes if necessary.
Remember, troubleshooting to resolution is a methodical process, and when in an enterprise environment, you MUST be aware of all factors of change process, even when the resolution is a simple reboot of the affected server.
HAPPY TROUBLESHOOTING! I LOVE COMMENTS! THANKS FOR READING!