PRTG – Basic Installation

It’s been a while since I’ve worked with PRTG, but need some monitoring in the lab. Also, I’ve had some environments asking me about general monitoring and some software to recommend. While Nagios is nice from a “free” and “can do whatever you want”, it’s not incredibly user friendly. For this, and a predominately Windows shop, I’d often recommend PRTG (http://www.paessler.com/prtg). I’m not going to go very deep into a “sales” presentation on the software, other than to point out that it’s good for Windows and SNMP monitoring.

Things we want it to do for us:

· Monitor all Windows systems for health

· Should be able to have “templates” that overlay by types. For example, we want an “All Windows Servers” group, a “Windows SQL Servers” group, a “Windows Exchange Servers” group, etc. The hope would be that we can overlay these so that a server with multiple roles doesn’t need to be a custom one off, but based on the applications installed, can apply the right monitoring

• VMware monitoring – ESXi and vCenter
• NetApp monitoring – volumes, LUN’s, ports, etc
• Switch monitoring – ports, port channels, bandwidth, fans, power supplies
• UPS monitoring – power load, battery status, etc.

What we’ll need to know to get started:

• A Windows Service account with rights to the systems. I’ve created a “svcPRTGAdmin” account that will get these rights. For now, it’s a copy of the Domain Administrator, but really should be restricted a bit more.
• A common SNMP community, if possible. If not, then a list of the SNMP communities to try when auto-scanning
• NetApp root/admin logins
• Subnet(s) we want to scan.

First, let’s get the software installed. Go to the website, register for the software and download it. Once you have it downloaded, launch the installer, and accept the licence agreements. This is where we will start.

1) Accept the licence agreements and such. You’ll be asked for an e-mail address to get notifications from Paessler on. This is probably not the “Alerts From” or “Alerts To” e-mail address:

Click NEXT

2) Enter the licence key:

You can either go without a key for 10 sensors, or request a 30 day trial key. Click NEXT.

3) Select the installation folder and click Next to start the installation:

4) When the installation completes, a web page will open showing the status, and the GURU setup wizard will start:

Click START GURU.

5) The first option will ask to use SSL, which you should, even if it is self-signed:

Click YES, SWITCH TO SSL.

You will be prompted that the core server will need to restart to make this change effective. Click YES, SWITCH TO SSL NOW.

6) When it restarts, you’ll see a standard SSL prompt to trust as shown above. Then you’ll get the PRTG login:

You may be wondering when it asked you for a password. Don’t worry, it has not. Click on DEFAULT LOGIN to start. Then click START GURU again.

NOTE: The default username/password is in fact “prtgadmin”/”prtgadmin”.

7) You’ll be asked to set up the User Account:

Here you can change the login name if you wish. I use a standard for e-mails of “<system>-alerts@<fqdn>” so that I can easily create rules to sort “*alerts@” into a folder. Change the password, so people can’t login with the defaults. Click SAVE & NEXT.

8) Enter the default credentials for scanning Windows Systems:

This will need a domain name, the username for the service account and the password. I highly recommend a non-default account, so when you see logins in audit logs you can verify if this is a “PRTG” login or a “User” login event. Click SAVE & NEXT.

9) Next we’re asked for default SNMP credentials:

You can either indicate that all devices use default “public” for read or enter your own. I have entered my read community string of “nw-public” which is just modified enough to not be default. A little later on, we’ll tell it to ALSO scan the default and any other options, in case we have a mixed mode environment where some devices were changed and some were not. Click SAVE & NEXT.

10) We now enter credentials for virtualization:

We will do a later configuration to accommodate vCenter Server itself. So this is for the ESXi root accounts. Click SAVE & NEXT.

11) Next, we are prompted for Unix credentials:

I don’t have many Linux systems, but every now and again I do and have virtual appliances that may be Linux based. So I’ll configure at least one account here so it can try to scan those if it finds them. Click SAVE & NEXT.

12) We will now monitor our Internet:

This could likely be a place to enter ISP based DNS servers vs internal. Click SAVE & NEXT.

13) We can now set up LAN Servers:

These will be the DC’s and the Exchange servers. You can add other servers, but I’d like to be able to set that up via auto-discovery, as I don’t want to have to add them manually each time. We’ll configure that a little later. Click SAVE & NEXT.

14) I have no web sites that I want to monitor, so I will ignore this option:

However this may be where you would put www.company.com to check for that. Note, if you put something like a blog in here, it will of course check it, but it may skew your analytics if you’re checking it every 5 minutes. Click SAVE & NEXT.

15) Next, we configure cloud services:

I don’t see anything here I need to worry about. If some of these were critical to your company, you would check them here and follow their advanced configuration, as they’re going to want logins and such. Click SAVE & NEXT

16) Next we configure basic auto-discovery:

This will scan this subnet periodically. Note that if you need more than 1, we do this in a later step. Click SAVE & NEXT.

17) Once complete, you’ll get a thank you. Click “OK! LET ME VIEW MY NEW SENSORS”.

Note the icons highlighted that show NEW LOG ENTRIES, NEW SENSORS, and AUTO DISCOVERY BACKGROUND TASKS. It’s been performing some of this work as you’ve completed the GURU wizard.

18) You’ll see the main screen now, showing the sensors and groups.

Note that you’ll see many are still doing Auto-Discovery, and will pop up with new sensors that are not green while they scan for the first time.

Expect the first pass scan to take a bit, as it tries to do a lot of auto-configuration. I’m going to pause here and come back, as there’s no point fighting the system. We’ll wait to see what it discovers, before we customize the sensors.

19) On the main toolbar, click SETUP -> SOFTWARE AUTO UPDATE:

Then click the SETTINGS tab. Here you can change if you want the system to auto-update to new releases.

20) Click on SETUP -> NOTIFICATIONS:

Click on EDIT next to any of these.

Here you can modify the e-mail address it will send to, as well as the subject lines. You may find you want to modify these subject lines for things like how readable they are by default on your mobile device of choice.

You can also perform additional tasks. Maybe you want to send a syslog message, or update an Event Log or trigger a program (eg: dial a serial attached modem is one I’ve used in my past). This would be how and where you can facilitate the events triggering into other systems.

Click SAVE.

21) Under SETTINGS -> OPTIONAL DOWNLOADS you will find:

The Client App for Windows if you need a non-web based console.

Client Apps for mobile devices

Remote Probe installer. Remote Probes are used like a proxy at a remote site to consolidate and package multiple sensors without latency and bursts across the WAN.

22) Under SETTINGS -> SYSTEM ADMINISTRATION you will find the following:

Check your Notification Delivery to ensure that e-mails are being sent as expected. Note that the default SMTP option uses a built in server, so that even if your Exchange/Mail systems are down, you’ll still get alerts – unless of course you’re sending alerts to your company e-mail on said server J

This covers the basic installation of PRTG. Expect more to come later as I get to some specific configurations such as:

• VMware Monitoring – ESXi and vCenter
• Switch Monitoring – this has a bit more configuration to it
• Monitoring groups and templates.

HOWTO: Configuring ESXi v5.x for use with Dell Open Manage Essentials (OME) v1.2

In order to ensure that the Dell R420 and R620 (and other) based VMware vSphere ESXi v5.x systems can be detected and managed via Dell OME, we need to perform some work to configure ESXi.  Thankfully, Dell has provided a tutorial, inside the application, to assist us.

1) Login to Dell OME and click TUTORIALS and select “Configuring ESXi v4.x and 5.0 for Discovery and Inventory”.

2) As you can see, it requests that we download and install the OMSA VIB.  We already do so as part of our Dell ESXi installation documentation:

3) The “Configuring of SNMP Traps” details are good and accurate:

However, I have previously done a HOWTO: (HOWTO: Use vSphere PowerCLI to control Get-EsxCLI for setting SNMP on ESXi v5.1U1 hosts.) which covers how to perform this procedure en-masse across an entire vCenter installation of hosts and standardize.  As the settings will merge and update, there is no harm running the script from that HOWTO repeatedly on all hosts.  Think of it as a GPO in this manner, used to confirm and apply uniform settings.

4) The Enable CIM OEM is not required as we utilize Dell sourced Customized ESXi ISO’s, and the option is enabled by default.

5) On the Discover the ESXi Server, ensure that the WS-MAN detection is chosen:

Utilizing the ESXi root user and password.

Once the above is completed on all hosts, they will be able to be scanned for in Dell OME with success.

HOWTO: Use vSphere PowerCLI to control Get-EsxCLI for setting SNMP on ESXi v5.1U1 hosts.

So today I had a need to set SNMP parameters for all ESXi hosts in vCenter.  Easily enough done at the SSH command line:

esxcli system snmp set –communities nw_public –enable yes

That’s going to set the community and enable SNMP.   Everything else is default, and we’re not setting up any sort of security.  SNMPv1/v2 don’t have security or encryption, vSphere v5.1 only supports setting a remote IP for a *trap* not a *get*, so we can’t do that, and we’re not using SNMPv3 (which has security and encryption built in).  So this is all we really need to set.

PowerCLI has no equivalent that I’m immediately aware of.  However, since vSphere v4.1, the functionality of “esxcli” at the command prompt has been available via PowerCLI with the “Get-EsxCli” commandlet. However, it’s not really easy to wrap your head around at first.  The best way to describe it is once you start a Get-EsxCli session, you continue to execute commands against it until you exit out.  Think RSH or Remote PowerShell or PSexec in similarity.

So here we have the script at hand.  I’ll break it down after:

===== Set-ESXISNMP.ps1 =====

$esxlist = get-vmhost

$communities = “nw_public”

$enable = $true

$port = 161

foreach($item in $esxlist){

Connect-VIServer -Server $item -User root -Password “<rootpassword>”

$esxcli = Get-EsxCli -VMhost $item

$esxcli.system.snmp.set($null,”$communities”,”$enable”)

$esxcli.system.snmp.get()

}

===== Set-ESXISNMP.ps1 =====

# Get the list of VMhosts in vCenter.  This assumes you’re already done “Connect-VIServer NW-VC1 etc”.  I should have done better here.  Anyway……  this sticks it into an array called $esxlist.

$esxlist = get-vmhost

# next we define some variables, straightforward enough.

$communities = “nw_public”

$enable = $true

$port = 161

# Now we start a “foreach” loop, executing against each $item in the $esxlist

foreach($item in $esxlist){

# the first command we’ll run is connect-viserver –server $item (servername) with user and password added.

# user/password can be exported to saved credentials, but this is just as easy for now.

Connect-VIServer -Server $item -User root -Password “<rootpassword>”

# This is the way the world sets up a Get-EsxCli session, so I did it the same way. 

$esxcli = Get-EsxCli -VMhost $item

# we’re going to use “.” Between the same options used at the SSH command line to move through the command

# in the () we’re going to put values for Field1, Field2, Field3.  How do we know the fields?  I’ll get to that…..

$esxcli.system.snmp.set($null,”$communities”,”$enable”)

# Then we do a quick GET of the same thing.  Here, you’ll see the fields. 

$esxcli.system.snmp.get()

}

Output looks like:  (here you will see how I knew what the fields were)

nw-esxi01.netwise.ca      443   root

true

(field1…) authentication :

(field2…) communities    : {nw_public}

(field3…) enable         : true

engineid       : 00000063000000a10a2000d3

hwsrc          : indications

loglevel       : info

notraps        :

port           : 161

privacy        :

remoteusers    :

syscontact     :

syslocation    :

targets        :

users          :

v3targets      :

nw-esxi02.netwise.ca     443   root

true

authentication :

communities    : {nw_public}

enable         : true

engineid       : 00000063000000a10a2400d3

hwsrc          : indications

loglevel       : info

notraps        :

port           : 161

privacy        :

remoteusers    :

syscontact     :

syslocation    :

targets        :

users          :

v3targets      :

So if you wanted to set $port as well, which is field 8, you would:

$esxcli.system.snmp.set($null,”$communities”,”$enable”,$null,$null,$null,$null,”$port$”)

Where “$port” is now in position8, as spaced out by the $null.  $null means you are not editing that particular spot.  I’m not sure if you could do it with a command line you can at the actual command line where you do “-port=161” or “-communities=”nw_public”, but this way works for now.

This is my first really heavy usage into Get-EsxCli, but I’m sure I can do a LOT more with this now!

Configuring OMSA v7.0.0 on ESXi v5.0 for use with Dell OME

In a previous post (https://vnetwise.wordpress.com/2012/04/23/dell-omsa-v7-0-is-out-for-esxi-v5-0u1/) I had indicated that the OMSA v7.0.0 VIB’s were out, and how to install them.  While this will certainly get you to a usable OMSA web page (via a proxy install with the full OMSA Web server installation), it is not terribly useful beyond an interactive experience.

As I’ve been working on getting my Dell Open Manage Essentials (OME) installation working, I was running into some errors:

• Inability to discover/scan/inventory ESXi systems
• If I was able to discover them, they were being mis-classified.

Working through the issues, I determined:

1) You need to configure SNMP on ESXi.

I found this post – http://en.community.dell.com/support-forums/servers/f/177/t/19442142.aspx which led me into the right direction.  The critical portions here are:

• Ensure you have the vSphere CLI installed.  This is a good idea anyway, and reminded me that I didn’t have it on my management station.
• Make sure you configure SNMP on each host.  The commands below use the root username and password to configure COMMUNITY=”nw_public”, TRAP DESTINATION of 10.0.0.14 (my OME server) and community of “nw_public” and then actually enables the configuration.  Repeat below for each host in your environment.
  • vicfg-snmp.pl –server nw-esxi1 –username root –password <password> -c nw_public
  • vicfg-snmp.pl –server nw-esxi1 –username root –password <password> -t 10.0.0.14@161/nw_public
  • vicfg-snmp.pl –server nw-esxi1 –username root –password <password> –E

After this, I was still getting hung up on authentication.  Seems that ESXi uses something called WS-MAN, which is not IPMI, SNMP, etc.  So a little digging brought be to a Dell TechCenter post (http://en.community.dell.com/techcenter/systems-management/f/4494/t/19436722.aspx) where a poster indicated the settings he used with success:

In the OME Discovery Wizard:

• populated the single IP address of my ESXi Server’s management network (I used my management network range…)
• checked enable WS-Man Discovery
• populated User ID, and Password
• Checked Secure Mode, and Trusted Site
• Left all others default, including the SNMP Config (on)

It took me a bit to confirm that the WS-MAN credentials should be the root login for ESXi.  This was my assumption, but until I was able to use the troubleshooting tool to verify, I couldn’t be sure.

As you can see, I’m now able to see properly classified ESXi hosts in Dell OME:

I am not, however, showing any Service Tags, Warranty info, etc.  I’ll continue to work with it:

What I do find a little frustrating, and similar to IT Assistant is that it classifies non-OMSA instrumented devices as “Unknown”.  I understand why, and there is an option in OME to only detect instrumented devices.  But I don’t think it would be that hard to determine that the scanned system is Windows Server 2008 R2, etc.  Also there is a category for “Microsoft Virtualization Servers” – why not provide the same for vSphere?  Better yet, because of the instrumentation and inventory it knows which “Unknown” systems are living on which vSphere host as a VM – why not nest them under the appropriate vSphere ESXi host?

Ultimately, I understand that Dell OME is only really intended to monitor and inventory Dell hardware devices.  There is no particular need to identify other non-Dell servers, as my goal with OME is to push out firmware/BIOS/driver updates, and be notified of hardware failures, etc.  At at that much, I think I have that working so far.

Another thing that is frustrating – Dell indicates that they won’t have the ability to push updates to ESXi until Q3/Q4 of 2012.  I understand that ESXi has bigger challenges given the lack of service console to install things into, or run the normal Linux based bundle updates.  But ESXi itself isn’t new.  Even if this was just a v5.x thing, I was on the beta team and I’m just ‘a little guy’.  Why wasn’t Dell ready out of the gate with OMSA/OME complaint VIB’s, etc?  You’d think a vendor as large as Dell, with partnerships with VMware, would have been ready on release date.  But that’s a rant for another day…..

Setting Windows SNMP parameters via GPO

Recently, while working on a Dell Open Manage Essentials (OME – the replacement for Dell IT Assistant) installation, I found myself wishing there was a way to set SNMP parameters via GPO.  Over time I’ve found that usually these parameters only get set during first time installation, if at all.  They certainly don’t often get updated.

A little digging found me another post about it – http://www.lucidsolutionsgroup.com/blog/bid/65800/How-To-Configure-SNMP-Settings-With-Group-Policy

I can’t possibly lay claim to it.  But I did have to do a face-palm at how simple it was, and how I overlooked the Registry settings option of GPO’s.  Now that I’ve found it, and tested it, and found it to work, I suspect I’ll need to go through various other scripts I have and see if I can’t find a better way to keep my other tasks up to date.

There is of course a catch – isn’t there always.  You need to have 2008 Domain Controllers.  At least one place where I would like to use this, is in a 2003 based domain to be migrated, and clearly – it won’t work there.