Intermediary EEM scripting: more fun with Power-over-Ethernet

In my last post I described how you can power off PoE on a range of switchports at certain times. But what if you’re lazy like me and don’t want to spend time figuring out which ports are utilizing Power-over-Ethernet? Can’t mr. switch do this himself? Well yes he can! Here you go:

event manager applet SelectivePowerOff
 action 0.0 cli command "enable"
 action 0.1 cli command "show power inline"
 action 0.2 foreach line "$_cli_result" "\n"
 action 1.1  regexp "^([^[:space:]]*)[[:space:]]*[^[:space:]]*[[:space:]]*on.*$" "$line" temp interface
 action 1.2  if $_regexp_result eq 1
 action 1.3   cli command "conf t"
 action 1.4   cli command "interface $interface"
 action 1.5   cli command "power inline never"
 action 1.6   syslog msg "Turned off PoE on $interface"
 action 1.7  end
 action 2.1 end

Basically what we’re doing here is using the “show power inline” command and processing it line by line. If we find an interface where the PoE operational status (column “Oper”) is on, we run the command “power inline never” on that interface. We also log a message to syslog telling we’ve turned off the power on that interface.

event manager applet SelectivePowerOn
 action 0.0 cli command "enable"
 action 0.1 cli command "show power inline"
 action 0.2 foreach line "$_cli_result" "\n"
 action 1.1  regexp "^([^[:space:]]*)[[:space:]]*off.*$" "$line" temp interface
 action 1.2  if $_regexp_result eq 1
 action 1.3   cli command "conf t"
 action 1.4   cli command "interface $interface"
 action 1.5   cli command "no power inline never"
 action 1.6   syslog msg "Turned on PoE on $interface"
 action 1.7  end
 action 2.1 end
 exit

Here we go through the same “show power inline” and check if the PoE administrative status (column “Admin”) is off. If it is, we run the command “no power inline never” on that interface. We also log a message telling we’ve turned on the power.

If you combine this with the event timer, you’ll have a fully automated solution.

Advertisements

Turning off Power-over-Ethernet ports at night to save power

Goal

Turn off Power-over-Ethernet on selected switch ports at selected times using the Cisco IOS EEM (Embedded Event Manager). Ultimately we want to reduce the energy consumption by turning off equipment that’s not being used at selected times.

In this example we have 7 switchports (FastEthernet 1/0/12 through 1/0/18) that have PoE equipment (phones) attached to them. As the company is not expecting calls to be conducted before 7:00 and after 22:00, there’s no need to keep the phones on, so we can power them off.

Prerequisites

For this configuration you’ll need one switch or router that:

  • has Power-over-Ethernet ports
  • supports EEM
  • has a correctly configured clock

Basically almost anything that runs Cisco IOS will have EEM. The configuration steps below are being done on a Catalyst 3750-48PS-S running IOS 12.2(55)SE8. As the events are time-based, your switch should have an accurate clock. Configure NTP first if you haven’t.

Configure the switch

The event manager works by way of applets: you define an applet which contains:

  • What to do: an action (or actions)
  • When to do it: an event (or events)

We’re going to need two applets: one that turns off the PoE at 22:00 and one that turns on the PoE at 7:00.

Start by defining a new applet, the one that’ll turn off the PoE. Let’s call it “PowerOff”:

l3s1(config-applet)#?
Event Manager Applet Entry Configuration Commands:
  action       Add or modify an action statement
  description  Add or modify an applet description
  event        Add or modify event information
  exit         Exit from Event Manager applet configuration submode
  help         Description of the interactive help system
  no           Negate a command or set its defaults
  trigger      Enter applet trigger configuration submode

l3s1(config-applet)#

As we look in the help we see two things that are important to us: “action” defining a set of actions this applet will execute, “event” which will describe when “action” will take place, the event being “time”.

Defining the actions

Notice the use of the label. The label dictates in which order the actions will be executed, in an ASCII sorted manner. You don’t have to use these particular labels, but how I’m using them seems to be a common way.

l3s1(config-applet)#action 0.0 cli command enable
l3s1(config-applet)#action 1.0 cli command conf t
l3s1(config-applet)#action 1.1 cli command interface range FastEthernet 1/0/12 - 18
l3s1(config-applet)#action 1.2 cli command power inline never
l3s1(config-applet)#action 2.0 cli command end

warning-145066_640 If you’re thinking about just turning off PoE on every port, keep in mind that “power inline never” can flap the port. So always exclude ports that link to devices that should not be disturbed (like as servers, uplinks to other switches, etc…).

Defining the events

Now that’s we’ve told the PowerOff applet what to do, now we need to tell it when to do it. The event we’re basing on is “time”, and the time specification is in cron format:

l3s1(config-applet)#event timer cron cron-entry "0 22 * * *"
l3s1(config-applet)#end
l3s1#

Let’s verify the result:

l3s1#show event manager policy registered
No.  Class     Type    Event Type          Trap  Time Registered           Secu  Name
1    applet    user    timer cron          Off   Sun Aug 24 12:23:16 2014  none  PowerOff
 cron entry {0 22 * * *}
 maxrun 20.000
 action 0.0 cli command "enable"
 action 1.0 cli command "conf t"
 action 1.1 cli command "interface range FastEthernet 1/0/12 - 18"
 action 1.2 cli command "power inline never"
 action 1.3 cli command "end"

l3s1#

We’re going to need to power on the equipment again. We’ll do that by way of a PowerOn applet:

l3s1#conf t
l3s1(config)#event manager applet PowerOn
l3s1(config-applet)#action 0.0 cli command "enable"
l3s1(config-applet)#action 1.0 cli command "conf t"
l3s1(config-applet)#action 1.1 cli command "interface range FastEthernet 1/0/12 - 18"
l3s1(config-applet)#action 1.2 cli command "no power inline never"
l3s1(config-applet)#action 2.0 cli command "end"
l3s1(config-applet)#event timer cron cron-entry "0 7 * * *"
l3s1(config-applet)#end
l3s1#

Verify:

l3s1#show event manager policy registered
No.  Class     Type    Event Type          Trap  Time Registered           Secu  Name
1    applet    user    timer cron          Off   Sun Aug 24 12:23:16 2014  none  PowerOff
 cron entry {0 22 * * *}
 maxrun 20.000
 action 0.0 cli command "enable"
 action 1.0 cli command "conf t"
 action 1.1 cli command "interface range FastEthernet 1/0/12 - 18"
 action 1.2 cli command "power inline never"
 action 1.3 cli command "end"

2    applet    user    timer cron          Off   Sun Aug 24 12:23:41 2014  none  PowerOn
 cron entry {0 7 * * *}
 maxrun 20.000
 action 0.0 cli command "enable"
 action 1.0 cli command "conf t"
 action 1.1 cli command "interface range FastEthernet 1/0/12 - 18"
 action 1.2 cli command "no power inline never"
 action 1.3 cli command "end"

l3s1#

Full configuration

event manager applet PowerOff
 event timer cron cron-entry "0 22 * * *"
 action 0.0 cli command "enable"
 action 1.0 cli command "conf t"
 action 1.1 cli command "interface range FastEthernet 1/0/12 - 18"
 action 1.2 cli command "power inline never"
 action 1.3 cli command "end"
event manager applet PowerOn
 event timer cron cron-entry "0 7 * * *"
 action 0.0 cli command "enable"
 action 1.0 cli command "conf t"
 action 1.1 cli command "interface range FastEthernet 1/0/12 - 18"
 action 1.2 cli command "no power inline never"
 action 1.3 cli command "end"

A more advanced time schedule

What if you wanted to turn off the PoE equipment on sundays, for the entire day?

As PoE is already being turned off every day at 22:00, we only need to prevent the PowerOn sequence on sundays. We can do this by adding a day-of-week to the cron schedule of the PowerOn applet:

l3s1(config)#event manager applet PowerOn
l3s1(config-applet)#event timer cron cron-entry "0 7 * * 1-6"
l3s1(config-applet)#end
l3s1#

Verify:

l3s1#show event manager policy registered
No.  Class     Type    Event Type          Trap  Time Registered           Secu  Name
1    applet    user    timer cron          Off   Sun Aug 24 12:23:16 2014  none  PowerOff
 cron entry {0 22 * * *}
 maxrun 20.000
 action 0.0 cli command "enable"
 action 1.0 cli command "conf t"
 action 1.1 cli command "interface range FastEthernet 1/0/12 - 18"
 action 1.2 cli command "power inline never"
 action 1.3 cli command "end"

2    applet    user    timer cron          Off   Sun Aug 24 12:26:51 2014  none  PowerOn
 cron entry {0 7 * * 1-6}
 maxrun 20.000
 action 0.0 cli command "enable"
 action 1.0 cli command "conf t"
 action 1.1 cli command "interface range FastEthernet 1/0/12 - 18"
 action 1.2 cli command "no power inline never"
 action 1.3 cli command "end"

l3s1#

Full configuration

event manager applet PowerOff
 event timer cron cron-entry "0 22 * * *"
 action 0.0 cli command "enable"
 action 1.0 cli command "conf t"
 action 1.1 cli command "interface range FastEthernet 1/0/12 - 18"
 action 1.2 cli command "power inline never"
 action 1.3 cli command "end"
 event manager applet PowerOn
event timer cron cron-entry "0 7 * * 1-6"
 action 0.0 cli command "enable"
 action 1.0 cli command "conf t"
 action 1.1 cli command "interface range FastEthernet 1/0/12 - 18"
 action 1.2 cli command "no power inline never"
 action 1.3 cli command "end"

Cron time format

A helpful reminder from wikipedia how cron time is specified:

cron

Rv-on-web & Isabel authentication cards: “The page cannot be displayed”

Today I came across an issue where a customer could not login to Rv-on-web (Belgian withholding tax administration website) using an Isabel card. After countlessly checking the certificate chain, I tried to log in to the Isabel webservices, and that didn’t work either. But I was redirected to a troubleshooting site which led me to this article: Error: “The Isabel 6 software cannot be accessed with Internet Explorer 64 bit” when trying to access Isabel 6. After following the instructions step 2 (setting TabProcGrowth in the registry), the magic pincode entering applet finally appeared and login to Rv-on-web was working.

This is the registry change in question:

Windows Registry Editor Version 5.00 
[HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main]
 "TabProcGrowth"="1"

More information on TabProcGrowth: Opening a New Tab may launch a New Process with Internet Explorer 8.0 (also applies to Internet Explorer 11). I suspect the pincode applet fails to load when its started in a new process after clicking the “login” button on Rv-on-web, leading to “The page cannot be displayed”, because the selected certificate cannot be decoded without the pincode. Setting TabProcGrowth to 1 changes this interaction. It’s not immediately clear to me why this trick works though.

Disable Pervasive Notification Viewer

If you’re using the Pervasive PSQL engine, you’ll probably have the Pervasive Notification Viewer in the systray. It’s a small application that notifies you of anything related to the PSQL engine. The application itself uses about 20 MB of RAM, which can lead to a lot of wasted memory if running on a remote desktop server. The application launches from a shortcut in the global startup start menu folder, which is buried here:

C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp

The file is called “Run Notification Viewer in background.lnk”.

You can delete it, but it’s better to move this file to your own personal startup folder, for example as Administrator:

C:\Users\Administrator\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup

That way the notification viewer only runs when the Administrator logs in, so you’ll still be apprised of any licensing or other Pervasive PSQL troubles that run through the notification viewer.

Improve the Windows Server 2012 Remote Desktop experience by using UDP

Server 2012 (and in turn Windows 8) has a nifty new feature in its Remote Desktop component, namely the ability to use UDP as transport for its data. The great thing about it, is you don’t have to do anything to enable it. And indeed, with a default remote desktop deployment we can see the server is already listening to UDP port 3389 and a firewall rule is present:

rdp-udp

rdp-udp-3

The client will automatically attempt to use UDP and will fall back to TCP if it can’t (note that authentication, etc… still happens using TCP). We can tell if the client is connected using UDP by clicking the quality icon:

rdp-udp-2

Adjusting the network

You will need to modify any firewall policies/port forwardings on other devices to allow connections to UDP destination port 3389. If you’re used to forwarding port TCP port 3389, include UDP port 3389 as well.

Windows 7

These changes come with Remote Desktop Protocol version 8.0, so you need at least that version of the client too to be able to use this feature. Windows 8 already ships with the 8.0 Remote Desktop client, if you’re running Windows 7 you can download version 8.1 of the Remote Desktop client here:

If you are a home user running Windows 7 and you are connecting to it using Remote Desktop you can also take advantage of this new feature:

  • Install this update: “Description of the Remote Desktop Protocol 8.0 update for Windows 7 SP1 and Windows Server 2008 R2 SP1” http://support.microsoft.com/kb/2592687
  • Follow the steps (in the same article) in the “How to enable RDP 8.0 on a remote computer that is running Windows 7 SP1” paragraph.
  • Install the latest Remote Desktop Client on any computers you use to connect to your own.

Unfortunately this does not work for Windows Server 2008 R2, you will need to upgrade to Server 2012 for that.

End result

By my testing, the ability to use UDP did increase responsivity and screen rebuild time when accessing the server over the internet. It is actually quite an improved experience, the typical RDP lag you used to notice is almost entirely gone and the animations are much more fluent. By using UDP we get rid of the time it takes to acknowledge the transceived data by the client and allowing it to immediately flow to the user.

Redirect Autodiscover URL’s using .htaccess

There are several ways an emailclient can perform autodiscover to detect its settings, however, most clients do not implement all methods. One example is the iPhone, which works as follows:

E-mail address entered: bob@example.com

  1. Connect to https://example.com/Autodiscover/Autodiscover.xml
  2. Connect to http://example.com/Autodiscover/Autodiscover.xml

This works if the root of your e-mail hosting domain points to an Exchange Client Access Server. However, most of the time it doesn’t. A common case would be that the website is hosted elsewhere on for example an Apache HTTPD server. Of course, when the iDumbPhone connects to either URL’s above, it fails because the file doesn’t exist.

If both methods fail, the iPhone bugs out and asks the user to manually enter the server address, username, domain, etc… Well they won’t be entering it, as IT guy, you will be. What you can do is redirect the iPhone’s request to your mailserver using a HTTP 302 Temporary Redirect status code. To do so:

Create a file called .htaccess in your DocumentRoot with the following content:

RedirectMatch 302 (?i)^/Autodiscover/(.*)$ https://yourcas.example.com/Autodiscover/$1

Adjust where necessary. If your Client Access Server is mail.example.com:

RedirectMatch 302 (?i)^/Autodiscover/(.*)$ https://mail.example.com/Autodiscover/$1

This will cause all requests to http://example.com/Autodiscover/Autodiscover.xml to be redirected to https://mail.example.com/Autodiscover/Autodiscover.xml, thus allowing iPhones to correctly autodiscover all server information needed to configure the account.

Hint: to make this work, your webhosting provider must support .htaccess files and has not blocked the RedirectMatch directive

Hint2: if autodiscover still fails and you are sure the iPhones are being correctly redirected, set the user’s UPN to loginname@example.com (example.com being the e-mail domain being used – resolvable on the internet) and have your users enter that as “E-mail Address” when the iPhone asks for it.

References

The mysterious black box that popped up every minute

So a customer called me up with a complaint that his screen didn’t automatically turn off anymore after 5 minutes and every minute or so a black box comes up and disappears immediately. I logged in via Teamviewer to take a look at what the problem could be and yes, a black box did turn up every minute.

The hunt

At first, I tried pressing print screen when it came up but the window just disappeared too fast and kept eluding me. After a few more tries I gave up and looked for another way (I’m sure gamers would persist until they got it right – I felt the urge too). I quickly found the “record session” feature in Teamviewer (“Extras” -> “Record”) and waited until the window popped up. After the recording was completed, playing it back with the built-in Teamviewer player was totally useless as you could only navigate through the video with a precision of 10 seconds. Luckily enough, Teamviewer does allow you to export the recording to an AVI file, which I played back with VLC giving me fine-grained navigation through the video. Success! The culprit was found.

The return of an old enemy

This was the window in question that kept popping up:

blackberry_crap

Hum. What’s that? Research In Motion? It looks like I’m not done yet eradicating every last piece of BlackBerry crap off of my customer base.

For Googlers:

tunmgr.exe

There was an error deleting C:\ProgramData\Research In Motion\Tunnel Manager\rimtun-2013-07-11-07-29-47.2388.bugz

Unknown arg ‘-Embedding’

The fix The workaround

Further investigation, this was caused by the “BlackBerry Link Communication Manager” service. I disabled the service and the window stopped popping up.

Of course, the actual cause is some developer that made a mistake programming this, calling some program with the wrong arguments. Maybe the version of “some program” is different from the one he expected. But anyway, the “fix” I applied to the client (disabling the “BlackBerry Link Communication Manager” service) sufficed, as my customer only connected his BlackBerry to put files on it, not having this service working wasn’t a problem.