HPE Server Alerts: Gen 10 changes

In an earlier post I explained how to set up alerts for pre-Gen 10 HPE servers so you will know when something bad happens to your server. Things have changed starting with Gen 10. This post will walk through the new process.

Why use HPE server alerts?

One of the most important tools you have as a system administrator is the simple email alert. No matter what the problem is, it’s great to have a head start on fixing it before the phone starts ringing. In the case of HP servers you can get an email alert so you will have a head start on any problems that arise. 

About The iLO

HPE servers up to Gen 9 used management agents on the operating system to monitor and send alerts, but going forward the alerts are sent by the iLO using an agentless service.

iLO is shorthand for “integrated lights-out”. Basically, this is an out of band management system that you can access over the network. It uses a dedicated Ethernet port so you can log in to the iLO from another computer on the network using a web browser. The iLO has its own IP address and you can set it to be static or check your DHCP for the IP it has been given.

Here are some documents from HPE that you may want to have a look at if you run into a problem not covered here:

The iLO User Guide

Configuring iLO Management Settings

If you like you can update the iLO firmware by downloading the installer.Click on Revision History and get newest version (should be the top one).

The iLO Advanced license

Alerts on Gen 10 servers require a special license, the iLO Advanced license. You can check your license by logging in to the iLO with your web browser and going to Information, then Overview. It will probably be the first page that comes up. Look at “License Type”. If yours says “iLO Advanced” you’re good to go. If it says” iLO Standard” you will need to purchase a license.

To quote HPE:

“With the release of Gen10 servers, iLO no longer supports OS-based SNMP agents. The System management Assistant (SMA) is an Agentless Management Service feature for users who want to run applications that obtain SNMP information from the OS. ”

Another advantage of the iLO Advanced license is that you can use the Remote Console in the iLO with no time limit. Without the license you only get like 3 minutes and then it locks you out. The Remote Console is basically Remote Desktop (RDP) through the iLO.

To check your license status log into the iLO by entering the iLO IP address into a web browser.

When you get in, right on the first page, next to “License Type” you should see if you have the license or not. If you already have the iLO Advanced license it will say “iLO Advanced”. Otherwise it would say “iLO Standard”.

You can obtain a license by registering the server with HPE, but you can also request a trial license.

Once you get your license log in to the iLO again and go to Administration, then Licensing.

You can just copy and paste your key into the first box and click the Install button. Easy.

Installing the SNMP Service Feature

To get the emails to us we need to install the System Network Management Protocol (SNMP) service. To do that, open Server Manager (it comes with Windows Server and usually starts automatically every time you log in) go to “Manage”, then “Add Roles and Features”. Choose “Role-based”, Next, select the local server, Next, Next, on the “Select Features” screen check the box next to “SNMP Service” and the one inside it, “SNMP WMI Provider”. You may be prompted to install “SNMP Tools”, too, if you don’t have it installed already. Get it, you’ll need it.

Configuring the SNMP Service

Now we need to configure SNMP to collect information from the server. Open Services.msc by searching in the Start menu or Windows key + R and entering Services.msc. Scroll down to “SNMP Services” and double-click on it to open the properties (or right-click and choose “properties”). In the security tab, click Add button under “Accepted community names”. There are two Add buttons on this tab so click the top one. Select Community rights as “READ ONLY”. Type “Public” for the Community Name and click Add.

If you don’t have the Security tab close Services.msc and restart it.

Click the same Add button again and create another Community Name called “Private”, but this time make the Rights “READ WRITE”.

Now we will tell the SNMP service who to accept packets from. With the “Accept SNMP packets from these hosts” radio button selected, click on the lower Add button now and enter 127.0.0.1 as the IP address. This is the localhost so the SNMP service will only be listening to this server we are working on. Click Add and then Apply.

With this done, go to the Traps tab in SNMP Service properties. You will have to type directly into the drop-down list because it doesn’t populate itself. Type “public” and now the “Add to list” button will be clickable. Click it. The drop-down list now has an entry for “public”. Click the “Add” button lower down the Traps tab and enter 127.0.0.1 and then click the Add button.

Click Apply and Ok.

Installing the Agentless Management Service

HPE’s pitch for this new way of managing server alerts seriously begins with “Tired of installing agents on your servers to monitor them?”, but in reality there is still one more service that you need to install: the “Agentless Management” service. Download it here. Make sure you get the new version under “Revision History”.

Download it and run it as administrator (from the right-click menu).

Click Install.


In this case I am upgrading because I already had an older version installed, but the process is almost identical except for the wording on this screen. Click Install.

Click Yes.


Close.

Make sure the “Agentless Management” Service is running in services.msc

Configuring the iLO Settings

Your settings may end up being different than mine after this point depending on your domain and network settings. Also some older versions of iLO 5 look different or have different names for some of the fields. In these examples I am using version 1.46 of iLO 5.

Log in to the iLO in your browser. Go to “iLO Dedicated Network Port” on the left, then the “General” tab. Fill in your “iLO Subsytem Name (Hostname)”. I use “ILO-<servername>”. Fill in the domain name and check the “Use iLO Dedicated Network Port” checkbox and the “Automatic” radio button.

Click the “Apply” button. You will see a message that tells you to reset the iLO to get the changed to take effect. Do so now. You will be logged out for a minute while the iLO reboots.

Log back in the iLO and go to “iLO Dedicated Network Port” on the left, then the “IPv4” tab.

Turn DHCP off and specify a static IP address, subnet mask, and gateway. The only swtich that can be green is the “Other” switch that says “Ping Gateway on Startup”.

Don’t forget to “Apply” and “Reset iLO”.

Once the iLO comes back up log back in and go to
“iLO Dedicated Network Port”, IPv6 tab. Turn everything off. “Apply” and “Reset”.

Log back in and go to “Management” on the left and then the “SNMP Settings” tab.

Select the radio button next to “iLO Hostname” and click the switches for “iLO SNMP Alerts” and “Cold Start Trap Broadcast”. Click “Apply”.

Lower down on the same page, under “SNMP Alert Destinations, click the “New” button. Specify your SNMP server. I leave the “Trap Community” blank and use the default for the protocol. Click “Add” and leave evertything else on the “SNMP Settings” tab at the default value.

While still in the “Management” area, go to the “AlertMail” tab. Click the “Enable iLO AlertMail” switch and enter the “Recipient” email address that will receive the alerts, the “Sender” email address that has permission to send emails out, and the SMTP Server that will process the email. The port is probably going to be 25, the default SMTP port. I leave everything else off.

Click “Apply”.

Sending a Test Alert

To send a generic test alert, log in to the iLO in your browser and go to “Management” on the left and then the “AlertMail” tab. Click the “Send Test AlertMail” button as seen in the previous image.

You should get an email like this:

If you got this email, then congratulations! If something goes wrong with the server you should get an email that tells you about it. It’s a good idea to log in to the iLO and send a test email once a month or so to make sure everything is still working. Sometimes a service will stop and you have to restart it manually.

If you didn’t get the email, double-check all the settings to make sure everything is correct and has been “applied”. If not, redo them and remember to apply and reset the iLO to save the changes. If that still doesn’t help make sure the SNMP and AMS services are running. It can’t hurt to go ahead and restart them even if they are. Your domain and network will be different than mine so there may also be additional DNS or Exchange settings for you to tweak.

There is a log in the iLO that might be able to tell you what went wrong. Go to “Information” on the left of the iLO browser interface and then the “iLO Event Log” tab.

Have fun and see you next time!

Hybrid Exchange PowerShell Part 2: Creating a New User Account

In the first part of this series, we set up our PowerShell environment for Hybrid Exchange administration. If you haven’t done that, review the other article to make sure you are ready for this one.

Now we will get down to business and create a new user. This is something that can take an annoying amount of time to do using the various web portals and things that Microsoft offers, so PowerShell is going to be very helpful here.

I always use PowerShell ISE. ISE stands for “Integrated Scripting Environment”. One of the good things about ISE is that you can have a text editor next to or above your PowerShell window, like this:

This makes it easier to keep track of your script.

In our scenario we will be assuming this is a brand new user. A new hire. They don’t have an Active Directory account yet so they need one of those and they need an email account.

Gathering the User’s Information

You are going to have to supply certain information about the user in order to create the account. If you leave any of these things out, you will either get an error or it will prompt you to enter the missing information before you can continue. Lets gather this info together now and store it in variables so we can plug them into the New-Mailbox command later.

You will need:

  • First name
  • Last name
  • Your domain
  • The orginizational unit in Active Directory that the user will belong to
  • The Exchange database the user’s mailbox will go into
  • The user’s password
  • The email address
  • The user’s display name, which is usually their first and last names
  • The user’s alias, which is the part of the email address before the @

Create these variables in PowerShell’s Script Pane. It will look something like this:

$last = "Ted"                
$first = "Logan"
$domain = "WyldStallyns.com"
$OU = "CN=Ted Logan,OU=WSUsers,DC=BAND,DC=WyldStallyns,DC=com"
$DB = "DB4"
$pass = "SanDimasHighSchoolF00tBallRules!"
$name = ($first + " " + $last)
$alias = ($first.substring(0,1)+$last)
$UPN = ($first.substring(0,1)+$last+$domain)

If you don’t know, the words with the dollar sign in front of them are variables. Naming them like this and then using an equals sign with words in quotes will assign the words to the variable so you can just type, for example, $domain and it will be as if you typed the words in the quotes. This makes it easy to modify the script later for another user. You would only need to change the names, password, and maybe the OU and the database.

The variables with the parentheses are modifying the previous variables to make new ones. Once you have all of these entered in to the Script Pane, click the green “Run Script” button to save your variables and then type $UPN in the blue bottom pane and press Enter. You’ll see that the $UPN variable is made from some of the other variables, just rearranged into an email address.

This is basic PowerShell, but I want to mention it now so no one gets confused when I add variables later without declaring them. They’ll be created just like the ones above, only off-screen, as they say in the movies.

Creating the Mailbox

Now that we have the user’s information entered into PowerShell (you clicked the green “Run” button, right?), we can plug them into the New-Mailbox command:

New-Mailbox -Lastname $last -FirstName $first -Name $name -DisplayName $name -Alias $alias -userprincipalname $UPN -OrganizationalUnit $OU -database $DB -password (ConvertTo-SecureString -string $pass -AsPlainText -Force) | set-mailbox -singleitemrecoveryenabled $true

This is the command that actually tells Exchange to create the new user account, so make sure everything is correct before you run it! If you named your variables the same as mine, you can literally just copy and paste that New-Mailbox command into PowerShell and run it. To check that it worked, run the following:

get-mailbox $name | fl

That will give you a ton of info about the new user’s new mailbox. Now you can go check in your Exchange Management Center portal and you will see the new user mailbox. If you open Active Directory Users and Computers you will also see the new user there.

Now that the new user account is created we can start adding valuable information to the account like job title, manager, address, phone number, etc. We’ll do that and more in the next article.

Later, in the final part of the series I will give you my complete NewUser.ps1 script that combines all of these steps into one really easy to use process.

Hybrid Exchange PowerShell Part 1: PowerShell Setup For System Administration

A “hybrid” Exchange deployment is when you have on-premise Exchange email servers, but some other aspects of your email system is on Microsoft’s servers. Thus, your deployment is split between “local” and “cloud” servers. There are many reasons to have this type of setup, but a common one is that you are transitioning from on-premise email servers to a completely Office 365 configuration. In other cases you may go hybrid to take advantage of a particular license structure for your Microsoft Office situation.

As you might expect this requires some new approaches to the usual system administration tasks. In the next article I’ll show you how to create a new user account. There are, of course, graphical methods for doing this, but it takes multiple programs across the Windows Server OS and the Exchange and Office 365 administration portals. It frankly takes way too much time to do it that way and it’s not very efficient.

This series will focus on PowerShell for Hybrid Exchange. When I work with user accounts, I use PowerShell to remote into an Exchange server on my domain with the Active Directory PowerShell module installed. You may want to work directly on the Exchange server or something completely different so some of your setup may be different than mine.

The Active Directory Module

The first thing we need to do is to make sure we have the required PowerShell modules installed. PowerShell is most likely going to be installed on your server or computer already, but it probably doesn’t automatically have all of the commands we need right out of the box. For that we need to install the correct module into PowerShell that has all of the stuff we need.

I always use PowerShell ISE. ISE stands for “Integrated Scripting Environment”. One of the many good things about ISE is that you can have a text editor next to or above your PowerShell window, like this:

The upper, white area is the Script Pane. Type this into the Script Pane and then press enter:

get-aduser -filter * | ft

If you already have the Active Directory module installed this will output a table of all Active Directory user accounts. If you don’t have the module installed, you will get an error like this:

get-aduser : The term 'get-aduser' is not recognized as the name of a cmdlet, function, script file, or operable program.

This is because the module isn’t installed so PowerShell doesn’t recognize the command (cmdlet). There are a few ways to install the module depending on the version of Windows you are using.

If you are using the newer (2019 +) versions of Windows 10, the methods have changed and the documentation isn’t very specific yet. What you need to do now is just click the Start button or taskbar search and type “
Manage optional features”. On the “Optional Features” page, click “Add a feature”. Now you will see a long list of features you can install. The one we want is called “RSAT: Active Directory Domain Services and Lightweight Directory Services Tools”. Click “Install” and it will disappear (without any kind of notification?) and go to the previous screen that lists the installed features.

If you are using Windows Server, you can use Server Manager > “Add Roles and Features” > Click through to the “Select Features” list > “Remote Server Administration Tools” > “Role Administration Tools” > “AD DS and LDS Tools”.

For other versions of Windows, this guy here has a really good resource for you.

Now when you run “get-aduser -filter * | ft” again you should get your table of users.

The Exchange PowerShell Module

When you installed Exchange on your server it should have installed the Exchange Management Shell (EMS) which is what it sounds like: a command-line interface for Exchange. The EMS automatically connects to exchange when it opens so you can start running Exchange Powershell commands. If you want, you can use the Exchange modules on the Exchange server, but in regular Powershell by using add-pssnapin:

add-pssnapin Microsoft.Exchange.Management.PowerShell.E2010

You can also use PowerShell to remote into the Exchange server if you don’t want to – or can’t – use Remote Desktop to log into the Exchange server. First, you need to give PowerShell your username and password. This command will prompt for your credentials and store them in a variable:

$UserCredential = Get-Credential

Next, we create a session object for the connection with the Exchange server:

 $Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri http://<FQDN of Exchange server>/PowerShell/ -Authentication Kerberos -Credential $UserCredential

And finally we begin the session:

 Import-PSSession $Session

To end the remote session (this will actually end all sessions):

Get-PSSession | Remove-PSSession

Now you can run this to get a table of all Exchange mailboxes:

get-mailbox | sort alias | ft

In the next article we will create a new Active Directory user account.

Project: Setting Up a Server From Scratch

Lately, I’ve been installing enough new servers (or inheriting newly installed servers) that now seems like a good time to show what it’s like to start from scratch with a brand new server. Obviously, no one will have exactly the same implementation as this, but the idea is to show the basics of what it’s like to set up a new server.

This will not cover everything you can do with a server. It’s basically just a way for me to organize my posts into something fun.

This page right here is going to host links that, if followed chronologically, will show what it looks like to build a brand new server straight out of the box. Basically all I’m doing is reordering some of my existing posts, but this page will corral them into a mighty Voltron of a larger project. I will probably go back and edit the old posts to make more sense in the context of this project (or not depending on how much time I have). Don’t worry, the original posts will work as standalones.

Anyway, here’s what it’s like to buy and implement a server!

(This is a work in progress. All of the steps may not be here yet. I’ll remove this disclaimer when I feel it is more complete)

Unboxing the HPE DL380 Gen10 server

Enabling The Third Drive Box On An HPE DL380 Gen10 Server

Installing Windows Server 2019

New Windows Server 2019 Server: Miscellaneous Setup

Automating Windows Server Updates Part 1: Sconfig

Automating Windows Server Updates Part 2: PowerShell

Automating Windows Server Updates Part 3: Scheduling the Task

HPE Server Hardware Alert Emails: Gen 10 Changes

Automating Windows Server Updates Part 3: Scheduling the Task

Automating Windows Server Updates Part 1: Sconfig

Automating Windows Server Updates Part 2: PowerShell

In the previous post I showed how to use PowerShell to find and install Windows Updates. In this one, we will run our PowerShell script every Sunday afternoon using Task Scheduler. The script will install any available Windows Updates, reboot the computer if necessary, and email us the details of the installation.

The Scheduled Task

Open Task Scheduler. One way to do this is to hold the Windows key and press R. In the Run box type: taskschd.msc. In Task Scheduler, right-click on the Task Scheduler Library and choose “Create Basic Task”.

The “Create Basic Task Wizard” will open. Name your task something descriptive.

In my case I want the task to run on Sundays so I choose “Weekly”. Yours may differ.

Your next screen could look different. In my case I chose Weekly so I choose the day of the week here.

Next we choose “Start a Program” because we want to start PowerShell to run our Windows Update script. We will be sending an email also, but that part is in our PowerShell script so we can ignore the “Send and e-mail” option here. It doesn’t work anymore anyway.

For the “Program/Script” field you will either paste in or browse to the .exe for PowerShell. Chances are good it’s the same as mine below. In the “Add Arguments” field you put the path to your .ps1 script file including the file name. For example if it’s on the same computer you’re running the Task Scheduler on it may be C:\Scripts\WUpdate.ps1 or if the script is on a file share it may look like \\Server1\Share\Scripts\WUpdate.ps1. “Start In” can stay blank unless you really need it.

The last page lets you review the task before you create it. If everything looks ok, click “Finish”.

Double-click on the new task. The only thing you should have left to do in the settings is click the radio button next to “Run whether user is logged on or not.” This is important because we will be at the beach on Sunday when the task needs to be run so we will definitely not be logged in. You may also want to change the user account used to run the task, but that depends on your circumstances. Click OK. You will be asked to give the password for the account that will run the task since it will not be logged in at the time the task will run.

Now, to test it! Right-click on the new task and choose “Run”. If everything was done correctly you will get an email that looks like this:

Moving the Scheduled Task to Other Servers

You can export the task to XML so you can import it into another server. All you need to do is right-click the task in Task Scheduler and choose “Export”. Here is my XML. Yours may differ.

<?xml version="1.0" encoding="UTF-16"?>
-<Task xmlns="http://schemas.microsoft.com/windows/2004/02/mit/task" version="1.2">
  -<RegistrationInfo>
    <Date>2018-09-12T13:42:45.1141389</Date>
    <Author>domain\username</Author>
    <URI>\WindowsUpdate</URI>
  </RegistrationInfo>
 -<Triggers>
   -<CalendarTrigger>
      <StartBoundary>2018-09-16T18:00:00</StartBoundary>
      <Enabled>true</Enabled>
     -<ScheduleByWeek>
       -<DaysOfWeek>
          <Sunday/>
        </DaysOfWeek>
        <WeeksInterval>1</WeeksInterval>
      </ScheduleByWeek>
    </CalendarTrigger>
   -<CalendarTrigger>
      <StartBoundary>2018-09-16T20:30:00</StartBoundary>
      <Enabled>true</Enabled>
     -<ScheduleByWeek>
       -<DaysOfWeek>
          <Sunday/>
        </DaysOfWeek>
        <WeeksInterval>1</WeeksInterval>
      </ScheduleByWeek>
    </CalendarTrigger>
   -<TimeTrigger>
      <StartBoundary>2019-02-23T22:00:00</StartBoundary>
      <Enabled>true</Enabled>
    </TimeTrigger>
</Triggers>
-<Principals>
   -<Principal id="Author">
      <UserId>UserId</UserId>
      <LogonType>Password</LogonType>
      <RunLevel>LeastPrivilege</RunLevel>
    </Principal>
</Principals>
-<Settings>
   <MultipleInstancesPolicy>IgnoreNew</MultipleInstancesPolicy>
   <DisallowStartIfOnBatteries>true</DisallowStartIfOnBatteries>
   <StopIfGoingOnBatteries>true</StopIfGoingOnBatteries>
   <AllowHardTerminate>true</AllowHardTerminate>
   <StartWhenAvailable>false</StartWhenAvailable>
   <RunOnlyIfNetworkAvailable>false</RunOnlyIfNetworkAvailable>
  -<IdleSettings>
     <StopOnIdleEnd>true</StopOnIdleEnd>
     <RestartOnIdle>false</RestartOnIdle>
   </IdleSettings>
   <AllowStartOnDemand>true</AllowStartOnDemand>
   <Enabled>true</Enabled>
   <Hidden>false</Hidden>
   <RunOnlyIfIdle>false</RunOnlyIfIdle>
   <WakeToRun>false</WakeToRun>
   <ExecutionTimeLimit>PT72H</ExecutionTimeLimit>
   <Priority>7</Priority>
</Settings>
-<Actions Context="Author">
  -<Exec>
 <Command>C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe</Command>
       <Arguments>PathToFile</Arguments>
     </Exec>
   </Actions>
</Task>

To import the task into the second server open Task Scheduler on that server and right-click on “Task Scheduler Library”. This time choose “Import Task” and browse to your XML file that you exported. The settings of the task will automatically open so you can review or change them.

Automating Windows Server Updates Part 2: PowerShell

Automating Windows Server Updates Part 1: Sconfig

Automating Windows Server Updates Part 3: Scheduling the Task 

Windows updates can be a blessing and a curse. On the one hand, it’s great that Microsoft is proactive in fixing issues with their operating system. On the other hand many of the issues with their operating system come from botched Windows Updates. Like deleting your files, for example:
https://www.howtogeek.com/fyi/bug-in-windows-10s-latest-update-might-be-deleting-files-back-up-your-data-now/

Another annoying thing about Windows Updates is that they often require a reboot and a long time watching percentages slowly rise (Often we find ourselves staring at 100% complete for a half an hour). This is especially bad when dealing with production servers that can only be rebooted on a Sunday.

Windows does have a built-in scheduling for installing Windows Updates, but it often just doesn’t work and you don’t have much flexibility about the timing of when things end up happening. In the newest version of Windows 10 you can delay updates for up to a week, but that’s it. Working hours can be set so the thing doesn’t reboot during the day, but there are limits to that, too.

Another, more fun way to handle Windows Updates is, of course, PowerShell! In this article we are going to learn how to use PowerShell to install Windows Updates and in the next article we will use Task Scheduler to run the script on Sunday afternoon when no one is at work.

(See my previous post for instructions on setting Windows Updates to manual only with Sconfig. Keep in mind Sconfig is only for Windows Server, not Windows 10.)

Installing the Windows Update PowerShell Module

First we will need to download the PowerShell module that controls Windows Updates. Download the required module here: tp://gallery.technet.microsoft.com/scriptcenter/2d191bcd-3308-4edd-9de2-88dff796b0bc/
It’s small so it won’t take long.

Unzip the file to C:\Windows\System32\WindowsPowerShell\v1.0\Modules\ and then open PowerShell as an administrator (Right-click to find that option). I like to use PowerShell ISE because it’s got the nice “script pane” built in so you can copy and paste my examples in there and modify them to suit your environment.

To make sure it installed correctly and to see what new functions we have run:

Get-Command –module PSWindowsUpdate

If you get an error like: ” FullyQualifiedErrorId : CommandNotFoundException Get-WUInstall : The term ‘Get-WUInstall’ is not recognized as the name of a cmdlet, function, script file, or operable program” then run this:

Import-Module PSWindowsUpdate

This next command will list all of the Windows Updates you can install on your computer, but does not install them.

Get-WUInstall
–WindowsUpdate –ListOnly

You may know that in the Settings GUI version of Windows Update you can use Windows Update to get updates for other things besides Windows, like Microsoft Office. You can do that with PowerShell, too! It just requires one extra step in the initial setup.

The command for the wider search of Microsoft (as opposed to Windows) Updates is:

Get-WUInstall –MicrosoftUpdate –ListOnly

If you run that one now you will get an error:

Luckily, this is easy to fix. Just run this to register the proper service:

Add-WUServiceManager -ServiceID
7971f918-a847-4430-9279-4a52d1efe18d

Now run Get-WUInstall –MicrosoftUpdate –ListOnly again:

As you can see, I now have an update for Silverlight in addition to the Windows Defender updates.

Installing The Updates With PowerShell

Now that you’ve seen what updates are ready to install you can install them simply by running:

Get-WUInstall –MicrosoftUpdate

You will get a popup asking for permission to install the update:

You can click “Yes” or “No” for each indvidual update or click “Yes to All” to install all of them from the first popup. Another approach would be to run this so you don’t have to approve them and they will just install:

Get-WUInstall –MicrosoftUpdate –AcceptAll

You can even add -AutoReboot at the end to have the server automatically reboot after installing the updates if required to do so. This is what we will be doing in our scheduled task so we don’t have to remote in to the server on a Sunday when we’d rather be at the beach:

Get-WUInstall –MicrosoftUpdate –AcceptAll –AutoReboot

This what it will look like as it does its thing. Notice the message displayed above the code window as it goes through the steps of Accepted, Downloaded, and Installed:

And when it’s finished installing it will look like this (assuming everything installed correctly):

There is a chance that an update could fail. If one does you will get output like:

4 Failed                63 KB Microsoft driver update for MS Publisher 

If you have an update that repeatedly fails to install you could download it from the Microsoft Update Catalog (https://www.catalog.update.microsoft.com/Home.aspx ) and install it manually or you could disable installing the one specific update if you decide you don’t need it.

Disabling Specific Windows Updates

One of the other useful commands is Get-WUHistory. This will show you all of the Windows Updates that installed on the computer, their KB, and the date and time of installation. This is handy for finding updates that broke your computer and need to be uninstalled. You can always Google the KB to find out exactly what the update entails.

If you find one that you want to uninstall, here’s how to do it (replace the KB with the one you want to uninstall):

Get-WUUninstall -KBArticleID KB4501375

Sometimes the KB isn’t listed so you have to use the title. Here is a way to disable an update easily assuming it’s the only update left:

$u = Get-WUInstall –WindowsUpdate –ListOnly
$t = $u.title
Hide-WUUpdate –title $t –MicrosoftUpdate –Confirm:$false

To keep Windows from installing that update again you will have to “hide” it or it will install it again later:

 Hide-WUUpdate –KBArticleID KB4501375–MicrosoftUpdate –Confirm:$false

If you change your mind and want to “un-hide” an update:

Hide-WUUpdate -KBArticleID KB4501375-hidestatus:$false

The PowerShell Script

Ok, lets build our script that we want the task to run for us. I’ll give you the whole thing, then break it down into its parts.

$file = "PathToTranscriptFile"  
$from = "from@domain.com"
$to = "to@domain.com"
$subject = "Windows Update Report"
$smtp = "smtpserver.domain.com"
Start-Transcript -path $file
Get-WUInstall –MicrosoftUpdate –AcceptAll –AutoReboot
#Get-WUInstall –MicrosoftUpdate –ListOnly
Stop-Transcript
$body = [IO.File]::ReadAllText($file)
send-mailmessage -from "$from" -to "$to" -subject "$subject" -smtpserver "$smtp" -body "$body"

You can copy and paste this into a text editor and then change the variables in bold to values that make sense for your environment. Save the text file with a .ps1 file extension.

If you don’t need the details of the script explained you can skip to the next section.

$file = "PathToTranscriptFile"  
$from = "from@domain.com"
$to = "to@domain.com"
$subject = "Windows Update Report"
$smtp = "smtpserver.domain.com"

Anything beginning with a dollar sign ($) is a variable in PowerShell. The ones above are our email settings. PowerShell will need to know how to send the email so you will need to swap out your values for the parts in bold.

$file = "PathToTranscriptFile" 

This variable stores the path to the transcript file to simplify adding it into the body of the email.

Start-Transcript -path $file

Start-Transcript does pretty much what you’d think: it saves what happens in the PowerShell window to a file. This is how we’re going to harvest the status of the Windows Updates so we know what got installed.

Get-WUInstall –MicrosoftUpdate –AcceptAll –AutoReboot

This is the command we learned in the last post. It installs all of the available Windows Updates and reboots the computer if necessary.

#Get-WUInstall –MicrosoftUpdate –ListOnly

This line with the “#” in front of it will not run. The “#” tells PowerShell to ignore the line and go to the next line. I have this line in here for testing purposes. When I only want to get an email about the available updates, but I don’t want to install them (and I DEFINITELY don’t want to reboot the server) I will move the “#” up one line to expose this test line and hide the one that does the real update. You might want this line for initial testing just in case the email doesn’t work how you need it to at first. When you get everything how you like it you can move the “#” back down a line.

Stop-Transcript

Then we stop the transcript so we can get the file the transcript created and put it in the body of an email.

$server = $env:COMPUTERNAME

In this line we are creating a variable that holds the name of the server we are running the Windows Updates on. The server name is only useful if you are running this script on multiple computers, which I am.

$env is basically a list of variables that you can use to get (or set) information about your computer. You can run Get-ChildItem Env: to see a list of all of the Environment variables. COMPUTERNAME is the name of the computer, of course, and using the Environment Variable for it enables us to use this same script on any computer; we don’t need to supply the computer’s name because the script gets it for us at runtime!

$body = [IO.File]::ReadAllText($file)

The $body variable reads the $file variable that has our Update info and stores it to use in our email alert.

send-mailmessage -from "lslerts@lslog.com" -to "twood@lslog.com" -subject "Windows Update Report" -smtpserver "xserver.lslog.com" -body "$body"

Finally, we send the email alert. Send-mailmessage is the commandlet that sends an email. It requires a sending email address, a destination email address, a subject line, an email server and the body of the email which contains the details of our Windows Updates.

You can test this script by opening PowerShell ISE as an administrator and loading the script from “File” > “Open” or the folder icon.
Don’t forget to move the “#” up to the -AutoReboot line if you don’t actually want to install and reboot the server. Press the green “play” icon to run the script.

If everything was done correctly you should get an email that looks like this:

In the next post I will show you how to set up a scheduled task that will run Windows Updates every Sunday afternoon.

Automating Windows Server Updates Part 3: Scheduling the Task 

Automating Windows Server Updates Part 1: Sconfig

Automating Windows Server Updates Part 2: PowerShell

Automating Windows Server Updates Part 3: Scheduling the Task

The new versions of Microsoft Windows 10 and and Windows Server have made managing Windows Updates right out of the box kind of a mess. It is not fun for an important server to suddenly reboot itself causing any number of important features to be interrupted. The newest version of Windows 10 as of this writing has only just allowed us to postpone Windows updates and even then they only allow a delay of a week. Windows Server will force a reboot if left with the default settings.

There are a number of ways to fix this such as using Windows Server Update Services (WSUS) or a Long-Term Servicing Channel (LTSC) version of Windows. You can also use Group Policy to control some aspects of Windows Updates.

In this example we will stop Windows Updates from installing using Sconfig and then the next article will be about scripting the updates with Powershell.

Sconfig is built into Windows Server so you don’t even have to go and download it. To start Sconfig run a Command Prompt as an administrator. When it opens simply type: “sconfig” without the quotes and hit Enter.

A new, blue-colored Command Prompt will open:

You can try out the other options, but the one we’re looking for is number 5: “Windows Update Settings”. Set it to “M” for Manual.

You will know it worked when you see this:

Double-check the Sconfig menu to make sure it says Manual there, too:

This will ensure Windows Server will not try to install any updates unless you tell it to. This can be set in Group Policy also, but in my experience it doesn’t always work and a server may still try to update and reboot unless you use Sconfig and set Windows Updates to manual. It’s worth taking a few minutes just to be sure.

Keep in mind that Sconfig is only for Windows Server. It doesn’t work with Windows 10.

For some of you just setting updates to manual with Sconfig will be enough to relieve the stress of unexpected server reboots. If you want to schedule the updates to happen, for example, every Sunday afternoon when no one is working, the Powershell fun is coming up in the next article.

Automating Windows Server Updates Part 2: PowerShell

HP server email alerts in Windows Server

One of the most important tools you have as a system administrator is the simple email alert. No matter what the problem is, it’s great to have a head start on fixing it before the phone starts ringing. In the case of HP servers you can get an email alert so you will have a head start on any problems that arise. It just needs to be set up first, which is not super simple if you haven’t done it before. Luckily for you I have this nice little tutorial to walk you through it.

Some Considerations Before We Start

The first thing I should mention is that there are little differences in the way certain generations of servers (and different versions of the software) handle this process. I have used the methods described below on Gen 6 through Gen 9 servers. For the most part they are pretty similar, but you may see something on your server that doesn’t look quite like what I have here. Keeping that in mind I have tried to point out any discrepancies I have seen and to give you as much information as I can so you can hopefully bridge any gaps you may come across.

Also, you may notice the names Hewlett-Packard, HP and HPE used interchangeably. In fact, HPE (Hewlett Packard Enterprise) is now a separate company from HP (Hewlett-Packard). They split around 2016 and now HP sells computers and printers and HPE handles servers. Doesn’t really matter to us except that HPE is starting to change things and that’s okay because otherwise life would be boring, right? Anyway, let’s get into it.

HPE’s servers use “Insight Management Agents” to monitor the health of their hardware. These are drivers that you need to install on the server. With the agents installed you can set up email alerts to tell you when something goes wrong with the server. On Gen 9 and older servers these are all free downloads. On servers newer than Gen 9 this functionality has been moved into the iLO and requires a paid license. I will cover that in a separate tutorial.

Installing Drivers

The first thing we are going to install is the “iLO Management Controller Driver Package”. The version you want will depend on the server’s iLO version. For example, the download for iLO 3 and 4 for Windows Server 2016 and 2019 which I will be using in the examples below is here: https://support.hpe.com/hpsc/swd/public/detail?swItemId=MTX_e20968c891b444c6b6de68a734

If you need a different one, you can probably find it here: https://support.hpe.com/hpesc/public/km/search#q=Management%20Controller%20Driver%20Package&t=All&sort=relevancy

Once the “iLO Management Controller Driver Package” downloads, right-click it and choose “Run as administrator”. You will see a setup wizard that looks like this:

Click the “Install” button and let the installer run its course.

Next, download and install the “Channel Interface Driver” for your operating system. You should get at least version 3.31.0.0. If you don’t there is a very real chance of random crashes. I have seen it myself. There is a bug in the older versions of the driver (https://downloads.hpe.com/pub/softlib2/software1/sc-windows/p2015029342/v154233/cp036919.exe). The download for the Windows Server 2016 version is here: https://support.hpe.com/hpsc/swd/public/detail?swItemId=MTX-c5e0ed82c4864327bc9b86442c#tab-history. For other versions, just google “iLO 3/4 Channel Interface Driver Server 2008 R2” for example.

You may have to reboot afterwards in order to finish the installation. Hopefully you are doing all of this on a new server so you won’t be interrupting anything important. Otherwise use a scheduled task to reboot the server at a time when no one will notice.

Next we will install the HPE System Management Homepage which will allow you to check the status of your server in the web browser at https://localhost:2381.

Use this link to download it and run the executable as an administrator: https://support.hpe.com/hpsc/swd/public/detail?swItemId=MTX_b36fb879335a41d78ee5e99f7f

Installing the SNMP Service

In order for the HPE tools to communicate with each other (and us!) we need to install the SNMP service. Microsoft describes the SNMP services as follows: “The Simple Network Management Protocol (SNMP) is used to configure remote devices, monitor network performance, audit network usage, and detect network faults or inappropriate access.” Exactly what we want, right?

To install the SNMP service, go to Server Manager, then click “Manage”, then “Add Roles and Features”. Choose “Role-based”, Next, select the local server, Next, Next, on the “Select Features” screen check the box next to “SNMP Service” and the one inside it, “SNMP WMI Provider”. You may be prompted to install “SNMP Tools”, too, if you don’t have it installed already. Get it, you’ll need it.

Click Next, then click Install.

Once the installation of SNMP service is finished, click the Start menu and type services.msc (or Windows key and R key on the keyboard and enter services.msc) to open the Services interface.

Find the SNMP Service and make sure it’s running.

Installing the Agents

Next, we will download and install the HP Insight Management Agents. Here is the link for the newest version at the time of this writing: https://support.hpe.com/hpsc/swd/public/detail?swItemId=MTX_1b0b099098874404adcb5d1d51#tab1

Run the executable as and admin and click Install.

When the install completes, the “Management Agents” window will open.

When the install is finished the “HPE Management Agents” settings will open automatically. You may notice there is a button on the “SNMP Settings” tab that says: “Send Test Trap”. We will come back to this later. It won’t work until we take care a few other things so you can click cancel for now.

Configuring SNMP

Now that we have the HPE agents installed we need to configure the SNMP service to collect information from the agents. Open Services.msc by searching in the Start menu or Windows key + R and entering Services.msc. Scroll down to “SNMP Services” and double-click on it. In the security tab, click Add button under “Accepted community names”. There are two Add buttons on this tab so click the top one. Select Community rights as “READ ONLY”. Type “Public” for the Community Name and click Add.

If you don’t have the Security tab close Services.msc and restart it.

Click the same Add button again and create another Community Name called “Private”, but this time make the Rights “READ WRITE”.

Now we will tell the SNMP service who to accept packets from. With the “Accept SNMP packets from these hosts” radio button selected, click on the lower Add button now and enter 127.0.0.1 as the IP address. This is the localhost so the SNMP service will only be listening to this server we are working on. Click Add and then Apply.

With this done, go to the Traps tab in SNMP Service properties. You will have to type directly into the drop-down list because it doesn’t populate itself. Type “public” and now the “Add to list” button will be clickable. Click it. The drop-down list now has an entry for “public”. Click the “Add” button lower down the Traps tab and enter 127.0.0.1 and then click the Add button.

Click Apply and Ok.

Our New Services

You may notice that you have several new services in your Services.msc window. Their names differ depending on the version you install, but they will be similar to:

  • HP Insight Event Notifier
  • HP Insight Foundation Agents
  • HP Insight NIC Agents
  • HP Insight Server Agents
  • HP Insight Storage Agents
  • HP Smart Array SAS/SATA Event Notification Service
  • HP System Management Homepage
  • HP WMI Storage Providers

The names pretty much tell you what they do, but you can click on them in Services.msc to get a more detailed description.

They should all be started except for the HP Insight Event Notifier service. It needs to be configured before it will start. Let’s do that now. In the Start menu go to “HP Management Agents” and run the “Event Notifier Config” as administrator. The instructions are right there in the wizard for you.

You can also click on the Events button to choose which events trigger the notications. You can have different events selected for different recipients. All of them are selected by default. When you have all of your recipients in there, click finish.

Keep in mind any time you want to change these settings you must open
“Event Notifier Config” as an administrator by right-clicking. Otherwise the settings will all be blank like it was never set up in the first place.

Back in the Services.msc window right-click on “HP Insight Event Notifier” and then click Restart. You can also double-click on it and then click the Start button.

If the “HP Insight Event Notifier” service doesn’t start, check your event viewer and you may see an error that will help you. For example, if you try to start that service without first running through the “Event Notifier Config” you will see two errors:

If that’s the case, set up the “Event Notifier Config” and it should work.

Back in the Services.msc window find the “HP System Management Homepage” service. Right-click it and click “Restart”.

The HP System Management Homepage

Now let’s open the HP System Management Homepage. There is probably a shortcut on your desktop, but if not, you will find it in the Start menu under “HPE Management Agents”. You can also type https://localhost:2381 into your browser. Log in to the homepage with an administrator account. If you are using a domain admin account enter it in the format of DOMAIN\username. If you’ve set everything up correctly you should see something like this:

To see some diagnostics, you can go to Logs > Integrated Management Log:

Explore this to see all of the nice stuff it tells you about your server. However, you can’t always be in here staring at it and waiting for problems to pop up, so we need to get the alert emails coming in. There are a couple of ways to send a test email. One is right here in the System Management Homepage.

The next part is different depending on the version of these programs you have.

To send a test email alert with the System Management Homepage, first click on Settings, then SNMP & Agent Settings.

In here you will find another view of the SNMP settings we saw in Services.msc. On the left side of the page you should find the “Send Test Trap” button. Click that and then click Ok when it asks you if you are sure. This next screenshot is from version 7.5.2.4 of the System Management Homepage. Other versions look a lot different and don’t give you as much control. Also, they are moving this functionality into the iLO starting with Gen 10 servers. More on that in another article.

Some versions of the Homepage have a different area where you can send a test indication, but it doesn’t send an email. It just sends a message to the event viewer. To try that out you can go to Settings, Test Indication, Send Test Indication. This is from version 6.2.0.13:

Here is an example of the “Test Indication” error that was sent to the event viewer:

Sending a Test Alert

The most reliable place to send a test email from is the Control Panel app they’ve given us as part of the HP Management Agent installation. This app seems to be present in all versions of these programs.

Open the Windows Control Panel and find “HP Management Agents”. Click on “View By” and choose “Large Icons” to find it easier. Right-click on it and run it as administrator.

In the first tab that opens you will see all of the types of agents that are working in the background. The important ones should already be set up for you. To send a test email alert click on the “SNMP Settings” tab.

You don’t need to change anything here either. Just click the “Send Test Trap” button. If the “Send Test Trap” button is greyed out, check to make sure the “HP Insight Foundation Agents” service is running in Services.msc and you are running “HP Management Agents” as administrator. If you see the following error after clicking “Send Test Trap”: “The Management Agents Remote Alerter agent has not finished initializing or is not enabled. The test trap was not sent.” then you are probably not running “HP Management Agents” as administrator.

If you’ve set everything up correctly you should get a message box like this: “The following trap has been sent” with the date and time.

And you should receive and email that says “The system has detected the following event:” with the date, time, server name, and the description of the error:

If you get that email, then congratulations! You’re all set to receive an email alert when something goes wrong.

If you don’t get an email you may have to add the server to your Exchange receive connectors or make some other change depending on how you are set up. Also, check the services in Services.msc to make sure they didn’t stop running for some reason.

Here is an example of a dead battery error:

You might want to try sending a test email once a month or so to make sure it’s all still working. Have fun!