I’m sure many of you realise that for systems with high value in terms of information held or impact to business due to outage or data breach, you would probably want to crank up the monitoring of such systems. Best practices say you should pretty much monitor all activity associated with local users and groups, but today I want to focus on interactive logins to servers.
This has mainly come about from my own need recently to provide the ability to notify on any interactive login to a particular server, be it using remote desktop or a console session.
My first thought was to create a SCOM Rule that would report on Security Log EventID 4624 and if the Logon Type was 3 (console logon) or 10 (RDP Logon), send an email. As it turned out, this was much harder than I expected, as I found that Logon Type was not getting consistently passed as a parameter, and doing a text search on the entire message is not good practice.
iDRAC firmware 2.40.40 was released on 17th Oct 2016. Details can be found by following this link.
We have recently had the need to upgrade our iDRAC firmware to 2.40.40 on one of our servers while troubleshooting another issue with Dell and found shortly after that this particular server was no longer able to be discovered by Dell OpenManage Essentials.
We found that the TLS protocol the iDRAC set after updating was set to version 1.2, which is not supported by Windows operating systems less than Server 2012 R2 (Our OME server runs on Windows Server 2012). There is a patch available to fix this. This is all covered in the driver release notes.
The other alternative, which we have chosen to do for now as this firmware is only on one device is to set the iDRAC to use the older TLS protocol, which can be found under the iDRAC Network Settings in the services tab:
I’ll apply the Microsoft patch to the system, and then set the TLS back to v1.2
A couple of weeks ago SAGE-AU announced that it was undergoing a name change and rebrand, to become the IT Professional Association, ITPA.
As a long time SAGE-AU and now ITPA member, this has come as little surprise. This has been something that has been on the cards for close to 4 years now. It does however mean good things for the organisation.
What I will say though is that if you are an IT Professional in Australia, your representation to government and industry is weak. Only 5% of people who identify as IT Professionals in Australia are members of a professional body like ITPA, ACS or AISA compared to say, accountants, who have near 100% membership to CPA or ICAA.
One of the tasts I am working on is the configuration of our fleet of Dell servers to use Dell’s Open Manage Essentials monitoring and management platform. One of the servers however had been unwilling to have it’s SNMP configuration changed using the VSphere CLI tools and was generating the following error:
Changing notification(trap) targets list to: myserver.local@162/DELLOME…
Use of uninitialized value $sub in string eq at C:/Program Files (x86)/VMware/VMware vSphere CLI/Perl/lib/VMware/VIMRuntime.pm line 81.
Use of uninitialized value $package in concatenation (.) or string at C:/Program Files (x86)/VMware/VMware vSphere CLI/Perl/lib/VMware/VIMRuntime.pm l
Undefined subroutine &Can’t call method “ReconfigureSnmpAgent” on an undefined value at C:\Program Files (x86)\VMware\VMware vSphere CLI\bin\vicfg-snm
p.pl line 297.
::fault_string called at C:\Program Files (x86)\VMware\VMware vSphere CLI\bin\vicfg-snmp.pl line 299.
Hrm OK fine. Lets try logging in to the Host’s ESX Shell and use esxcli to set the trap:
Community string was not specified in trap target: myserver.local
Clearly something is broken with the SNMP configuration. Luckily the VMware forums were quick to supply a solution.
The SNMP settings for ESX are stored in the XML file /etc/vmware/snmp.xml. You can either clear this file (cat /dev/null > /etc/vmware/snmp.xml) or if you know what the setting should be, modify it. in my case I needed to update the <targets></targets> XML Tag to have a community string:
It’s fair to say that I have not done any scripting for HP iLO since the release of their PowerShell scripting toolkit. I simply didn’t have a need. However in the past week I received a request to update my SSL Signing script for iLO to use the HP toolkit, and so I have.
As the HP cmdlets only support iLO3 and above, this script is also only compatible with iLO 3 and above.
The mechanics of the script depart from my previous scripts, in that they require a list of iLO interfaces in a text file, rather than doing DNS queries – this list should be a trivial thing to compile using Find-iLO HP cmdlet. It also no longer makes attempts to correct issues that may cause the certificate to not install correctly, it will simply note the problem and then list the skipped hosts in an exceptions report as the script completes. This greatly simplifies the script.
I’m making up some code using the HP PowerShell tools and one of the things I discovered is that it does not provide full support of iLO2. I’m not particularly surprised by this – iLO2 technology is nearly 10 years old, and we’re current at iLO4 in the newer model servers.
This may cause issues for some people with older hardware such as me. I was wondering for other HP Server Admins, what’s the iLO version in your environment?