Recently, I saw a Nintex Workflow user comment on a Nintex Connect – How many black balloons ? forum, about how their company has an initiative, that every must turn their computers off at night. Less electricity, means less greenhouse gases, means less bills and better for the environment.
The idea was, that they had some process which pings all the computers and reported the results into a SharePoint list. This list contains a workflow which would run and and perform some sort of calculation, and I assume would then email the appropriate owner of the computer that they forgot to turn it off..etc..etc.
For those that don’t know what Ping is : Ping on Wikipedia
Well I think this is a great idea. Most computers are kept for completely unnecessary reasons. I wish I had some statistics to show how many computers are actually kept on around the world, which actually do nothing.
So I thought, rather than separating the process of pinging from the workflow, I want to make my workflow do the pinging as well. We could use the workflow scheduling to schedule it to run every day at a certain time.
One small problem. How do you ping? Nothing came to mind. As in most cases, I had a few options :
1. Create a Nintex Workflow Inline Function – no reason why we couldn’t, but it’d be fiddly to configure in a Build Dynamic String action, then convert the Ping time to a number variable…..blah blah blah
2. Create a Web Service – I think that had similar issues as the Inline Function
3. Create a Custom Nintex Workflow Action – I’m a geek, so this was my choice
The Ping Action
The cut and dry of it, is that it sends a 32 byte text string as the ping message, sends the message to the IP Address or Host Name, gets a response and stores it in a Nintex Workflow Number variable. This number is the number of milliseconds it took to respond.
Configuration of the Ping Action
Once installed, the action will reside in the Vadims Actions group in the workflow designer.
For those that don’t know why I have a picture of Table Tennis rackets for this action, in other parts of the world Table Tennis is called Ping Pong.
You’ll notice I have the other action in Vadims Action. The “VT List Item Get Attachment” action was described here : Nintex Workflow – Get List Item Attachment in Base64 Custom Action (Happy Thanksgiving)
The actual configuration of the action is quite straight forward. You need to first create a Nintex Workflow Number variable to store the Ping Time. Configure the VT Ping action, by providing either a Host Name (eg. vadimtabakman.com), an IP Address (eg. 220.127.116.11) or a reference to a Workflow variable or metadata that contains one of those.
Fingers crossed nothing completely bad happens, but just incase, I have added an Error Handling section to the configuration so that you can make your workflow more robust by capturing the error and building some Workflow logic around it.
The action will either return the Ping time (greater than or equal to 0), if the computer responds, or a -1 if for whatever reason, we do not get a successful response.
I am going to keep my example simple as I think this is a fairly straightforward action.
A simple list with a Title and a Number column named Ping Time. I create a new item and in the Title field, I put in either a Host Name or IP Address.
I then create a workflow that will take the Title field as the input and store the Ping Time in my number variable.
I then use a Set Field Value action to update the “Ping Time” field of my list item, to record how long it look that computer to respond.
The Workflows looks like this :
The resulting list ends up looking like this :
You can see from the results, that the machine “ntx-vadimdesk”, which is the server I’m running the workflow on, returns a Ping Time of 0. This is expected, as it should be almost instantaneous as it’s all happening on the one server.
I then tried to ping “www.google.com”. The result of which is a 99ms response time. Not the best, but not the worst.
My last attempt is for an IP Address I know is not used by any machine. This returns a -1. This is the same as if that was a server name for a machine that isn’t on at the moment.
You could potentially, have a list on machine name (or IP Address) the user who owns each machine. In your workflow, if you continuous got a response from that server, but you are sure it should be turned off, then you can email the owner and tell them. If it continute, you can email their manager. The complexity of your workflow to handle this situation is up you.
Download VTPingAction.wsp SharePoint Solution
To install this solution, run the following command line :
stsadm -o addsolution -filename VTPingAction.wsp
You can then go into SharePoint Central Administration->Operations and click on Solution Management. Here you can deploy the solution.
This deploys into the following folder :
c:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\TEMPLATE\LAYOUTS\NINTEXWORKFLOW\VadimsActions\VTPingAction
One of the files that gets deployed is the NWA (Nintex Workflow Action) file. You use this to add the action to Nintex Workflow via the NWAdmin.exe utility, located :
c:\Program Files (x86)\Nintex\Nintex Workflow 2007
The command line would be :
NWAdmin -o AddAction -nwaFile VTPingAction.nwa
You will probably need to perform an IISRESET, so that the new assembly gets loaded. Then, in Central Administration->Application Management, in the Nintex Workflow Management section click on Manage Allowed Actions. Here you should scroll down to the VT Ping action and enable it.
The action should now appear in the workflow designer.
The irony of this, is that this needs to run on a server and use electricity, in order to tell other people that they are running the machines and should turn them off. The upside is, I don’t know of any production SharePoint server that is turned off at night, so you might as well utilize it by telling your staff to stop being lazy and turn their machines off before they head home.
Let try to help the environment in our own little way. Every little bit counts.
I had to add this link, as it seems quite related to this issue : Computers and overnight usage
A desktop CPU running idle with Screensaver consumes about 0.082 Kwh
Energy Usage for overnight, 5pm-9am, 16 hours (Given an eight hours work day) = 0.082 x 16 = 1.312 Kwh
Energy Usage over five working day overnights = 1.312 x 5 = 6.56 Kwh
Energy Usage over the weekend = 0.082 x 48 = 3.936 Kwh
One working week Energy Usage = 6.56 + 3.936 Kwh = 10.496 Kwh
Energy usage over one year = 10.497 x 52 = 545.792 Kwh
Average Energy cost per Kwh = 11 cents.
Annual Energy Cost for the Desktop CPU = 545.792 x .11 = $60.04
The above stats are for a specific computer, but we can use them to generalize a few things.
Lets say you had 500 staff, with 500 computers on their desks, all leaving them running every day 24/7.
10.496 Kwh * 500 = 5298 Kwh (wasted electricity)
$60.04 * 500 = $30,020 the company could be saving
Imagine bigger companies like IBM, Microsoft, Oracle etc. They probably have their own energy user reduction schemes, but it’s something to think about.